HTTP는 왜 0.9부터 시작할까

오늘처음해요·2024년 8월 23일

HTTP

목표

이 글을 읽으시고 HTTP 1.0과 2.0의 차이점을 알게 되셨으면 좋겠습니다 :)

HTTP의 아버지

팀 버너스 리는 CERN에서 일하면서 정보 시스템을 만들었습니다. 그는 연구자들 간에 정보를 쉽게 교환할 수 있는 인트라넷 서비스의 필요성을 느꼈습니다. 이를 위해 문서의 구조를 표현할 수 있는 HTML을 개발했고, 서버와의 통신을 위한 프로토콜로 HTTP를 설계했습니다. 이 시스템은 이후 월드 와이드 웹(WWW)의 기초가 되었습니다.

시작 전 간단 상식(1)

에러 코드 404는 요청한 리소스를 서버에서 찾을 수 없을 때 반환되는 코드입니다.
팀 버너스 리는 4가 손바닥의 모양과 비슷해 사과의 제스쳐를 취하는 느낌으로 404로 지었습니다.

시작 전 간단 상식(2)

URL의 아버지인 팀 버너스 리는 사실 URL의 //는 아무런 쓸모가 없다고 실토했습니다. (겉멋용)

HTTP 0.9버전

왜 1.0 버전이 아니라 0.9부터 시작인지 궁금하지 않으신가요?
초기에는 버전이 붙지 않았는데, 이후 나오는 버전과 구분을 하기 위해 0.9가 붙게 되었다고 합니다.

가장 큰 특징으로는 [HTTP Method][Request Target]의 형식으로 한 줄로 요청합니다.
또한, 하이터 텍스트에 참조된 링크를 타고 웹 사이트를 접속하던 시대여서 메서드도 GET밖에 없었습니다.

한계 : HTML 코드만 받을 수 있었음

HTTP 1.0버전

보통 단점이나 한계가 있으면 다음 버전에서 개선하기 마련이죠!
1.0버전부터는 시작줄에 HTTP버전을 명시하고, 응답 첫 줄에는 상태코드를 반환합니다.
이전 버전의 한계인 HTML 코드만 받을 수 있었던 것도 Content-Type을 통해 다른 데이터 타입도 전송 가능하게 변경됩니다.

한계
- 기본적으로 요청을 하고 응답을 받으면 연결이 해제되었습니다.
- 계속 새로운 연결을 해줘야 해서 성능이 저하됐습니다.
- keep-alive 옵션을 따로 설정해줘야 지속적인 연결이 가능했습니다.

HTTP 1.1버전

변경점
Persistent Connection이 표준화 되면서 기본적으로 지속적인 연결이 가능해졌습니다.
파이프 라이닝을 통해 여러 요청을 보내고 순서에 맞춰 응답하게 변경이 되었습니다.

기존에는 요청1 - 요청1 응답 - 요청2 - 요청2 응답과 같이 요청과 응답이 끝나야 다음 요청을 수행할 수 있었습니다. 그러다보니 앞선 요청의 크기가 크거나 패킷 손실로 인한 지연이 발생하면 뒤에 온 요청들이 계속 지연되는 문제가 있었습니다. 파이프 라이닝을 통해 여러 요청을 받을 수 있게 되었지만, 여전히 순서에 맞춰 응답하여 요청1의 응답이 지연되면 나머지들도 지연이 되는 것은 개선되지 못했습니다.

한계
- 여전한 HOLB(Head Of Line Blocking) 발생 가능성
- HTTP는 중복되는 내용을 가진 요청이 많이 올 수 있는데, 헤더의 데이터를 줄일 수 있는 방법이 필요

HTTP 2.0버전

왜 1.2가 아니라 2.0버전인지 궁금하지 않으신가요?
메이저 버전의 경우는 보통 대규모로 새로운 기능이 추가되거나 기존 버전과 호환되지 않는 경우입니다. 이번 경우는 기존과 호환되지 않는 바이너리 프레이밍이 추가되며 메이버 버전이 커지게 되었습니다.

바이너리 프레이밍을 통해 시작줄, 헤더를 HEADERS 프레임에 담고, 바디를 DATA 프레임에 담은 후 바이너리로 인코딩합니다.

멀티 플렉싱은 여러 요청을 보내고, 동시에 여러 응답을 받는 형태입니다.
연속적으로 데이터를 받는 방식인 스트림을 활용하고, 스트림은 프레임 단위로 정보가 이동됩니다. 요청된 순서와 상관없이 프레임 단위로 응답을 받습니다.

TCP의 HOLB 발생 가능성
다만 TCP로 단일 연결이 되어있고, 스트림이 다중으로 연결되어 있다보니 패킷이 손실되거나 오버헤드가 발생하면 HOLB가 발생됩니다. 쉽게 예로 들면, 1차선에서 맨 앞 차량이 고장이나 멈추게 되면 뒤에 있는 모든 차량들이 움직이지 못하고 정체되어 있는 거라고 생각하면 됩니다. TCP는 패킷의 손실이 발생하면 Stop and Wait 방식으로 손실된 번호의 패킷이 제대로 도착할 때까지 멈추게 됩니다. 이로 인해 HOLB가 발생합니다.

헤더 압축
테이블 참조 압축 알고리즘과 허프만 코딩으로 헤더의 크기가 85%가량 줄어들었다고 합니다.

요약

Quic과 HTTP/3

Quic은 구글에 만든 프로토콜입니다.
Quic은 UDP 프로토콜을 기반으로 만들어졌는데, 실시간 스트리밍이나 동영상 전송에 유리한 프로토콜입니다. (Youtube가 생각나죠?)

왜 UDP를 기반으로 만들었을까?
인터넷 연결의 60% 이상이 무선이라고 할만큼 핸드폰, 태블릿 등의 보급으로 작은 단위의 연결이 많아졌습니다. 다만 TCP는 데이터의 안정성 및 순서를 보장하는 기능들이 들어가 있어서 상대적으로 무겁고 연결 속도가 비교적 느립니다. 이를 개선하기는 어렵다고 판단합니다. 따라서 데이터의 안정성을 보장하지는 않지만 속도가 빠르고 TCP에 비해 기능이 안들어간 UDP에 기능을 추가하는 선택하게 됩니다.