HTTP의 버전별 특징(0.9, 1.0, 1.1, 2.0)

HTTP는 인터넷 상에서 가장 많이 사용되고 있는 애플리케이션 프로토콜입니다. HTTP는 웹에서 데이터를 주고 받는

프로토콜로 클라이언트-서버 구조입니다. HTTP를 사용하여 HTML 문서, 이미지, 동영상을 주고 받을 수 있습니다.

HTTP 헤더에는 메세지의 속성 정보, 상태 정보가 있고 HTTP 바디에는 실제로 전송하려는 데이터가 들어갑니다.

이러한 HTTP는 1991년부터 시작하여 지속적으로 발전해왔습니다.

이번 글에서는 HTTP의 버전별 특징에 대해 알아보겠습니다.

HTTP/0.9

처음부터 존재하던 버전은 아니었고 초기 버전으로 구분하기 위해 이후에 붙여진 버전입니다.

요청은 단일 라인으로 구성되며 리소스에 대한 메소드는 GET만 존재합니다. 
HTTP 헤더도 없고 HTML 파일만 전송 가능했던 버전입니다.

위 그림과 같이 제한된 방식으로만 요청이 가능했었습니다.

HTTP/1.0

1996년에 등장한 버전으로 HTTP 헤더, Content-Type이 도입된 것이 특징입니다.

HTTP 헤더의 도입으로 요청과 응답이 추가되며 메타 데이터를 주고 받고 프로토콜을 유연하고 확장 가능하도록 개선하였습니다.

버전 정보와 요청 메소드(GET, POST)가 함께 전송되기 시작하였으며 Status Code도 응답의 시작 부분에 추가되어

브라우저 요청의 성공과 실패 파악이 가능해졌습니다. 또한 Content-Type의 도입으로 HTML 이외의 문서 전송이 가능해졌습니다.

아래 그림과 같이 이미지도 보낼 수 있게 되었습니다. HTML을 주고 받기 위해 시작된 HTTP는 현대의 네트워크에서

거의 모든 데이터를 전송할 수 있는 프로토콜로 가장 많이 사용하는 애플리케이션 프로토콜로 자리 잡게 되었습니다.

하지만 이때까지는 커넥션 하나당 요청 하나와 응답 하나만 처리할 수 있다는 단점이 있었습니다.

즉 HTTP는 요청할 때마다 새로운 TCP 연결을 생성하고 응답을 마치며 연결을 종료하는 방식으로 동작했습니다.

HTTP/1.1

HTTP/1.0의 단점을 해결하기 위해 1997년에 등장하였습니다. 커넥션 하나당 요청 하나와 응답 하나만 처리하는 방식은

사용자가 많아지며 문제가 제기 되었고 HTTP/1.1에서 이 문제를 해결하기 위한 Persistent Connection 개념이 추가 되었습니다.

(HTTP/1.0 버전도 정식 스펙은 아니지만 지원하는 서버도 있었습니다) 

Persistent Connection은 지정한 timeout 동안 커넥션을 닫지 않는 방법으로 기존에 연결한 TCP 커넥션을 재사용합니다.

 

다음으로 HTTP 요청은 기본적으로 순차적으로 전송됩니다. 이전 요청의 응답을 받은 후에 다음 요청을 보낼 수 있었다는 것입니다.

하지만 이 방식은 네트워크 지연을 발생시켰습니다. 이 문제를 해결하기 위해 Pipelining이 추가 되었습니다. 

Pipelining은 위 그림처럼 앞선 요청의 응답을 기다리지 않고 하나의 커넥션을 통해 여러 요청을 순차적으로 보낸 다음

응답을 순차적으로 받는 방식입니다. 이때 요청과 응답이 모두 순차적으로 진행된다는 것에 주목해야 합니다.

왜냐하면 이것이 HOL(Head Of Line Blocking) 문제를 발생시키기 때문입니다.

첫 번째 요청에 대한 응답이 지연된다면 아무리 두 번째 요청을 빠르게 했더라도 두 번째 요청에 대한 응답을 할 수 없는 것입니다.

Pipelining은 이러한 한계가 존재하기 때문에 HTTP/2의 멀티 플렉싱 기술로 대체되어 현재는 거의 사용되지 않습니다.

 

또한 HTTP/1.1은 연속된 요청의 헤더가 중복된다는 문제도 있습니다. 연속된 요청이라면 헤더가 중복될 확률이 높은데 

이 부분이 공통적으로 계속 전송된다면 불필요하게 헤더의 크기가 커질 수 있습니다.

HTTP/2.0

HTTP/2.0는 2015년에 등장하였습니다.

HTTP/1.1에서는 각 요청이 메세지 단위로 구성되었는데 HTTP/2.0에서는 Binary Framing Layer의 등장으로 데이터를

바이너리 형식으로 주고 받아 전송 속도가 올라가고 오류 발생 가능성을 줄였습니다.

 

HTTP/2.0에서는 스트림, 프레임이라는 개념이 등장하는데 스트림은 클라이언트와 서버 사이에 맺어진 커넥션을 통해 양방향으로

주고 받는 메세지 흐름을 말하고 프레임은 HTTP/2 통신에서 HTTP 헤더, 바디 데이터가 저장되는 가장 작은 단위를 말합니다.

HTTP/1.1에서는 요청과 응답이 메세지라는 하나의 단위로 묶였는데 HTTP/2 에서는 스트림이라는 단위로 요청과 응답을

하나의 단위로 묶습니다.

스트림, 프레임 구조로 각각의 프레임에 스트림 번호를 매겨 서로 연관된 요청, 응답 프레임을 구분할 수 있습니다.

이러한 방식으로 요청의 순서에 상관없이 클라이언트에 바로 바로 전달할 수 있게 되었습니다.

하나의 TCP 연결에서 여러 요청과 응답이 비동기 방식으로 이뤄지는 멀티 플렉싱이 사용되어 HTTP/1.1의 HOL 문제를

해결하였습니다. 하지만 HTTP/2.0도 TCP를 기반으로 동작하기 때문에 신뢰성을 유지하기 위한 TCP 고유의 HOL은 여전히

존재한다는 문제가 있습니다.

 

HTTP/1.1 에서는 헤더 중복의 문제가 있었는데 HTTP/2 에서는 Huffman code를 사용하여 name: value 헤더 쌍을

압축합니다. 미리 정의된 static table과 클라이언트와 서버가 서로 공유하는 dynamic table을 이용하여 저장합니다.

이외에도 스트림 우선 순위도 설정할 수 있게 되었는데 우선 순위를 설정하여 중요한 자원을 먼저 빨리 전달할 수도 있게 되고

서버 푸쉬를 이용하여 클라이언트가 요청을 할 때 이후 추가될 요청을 미리 예상하여 함께 응답할 수도 있습니다.

 

참고로 구글에서 개발한 오픈 소스 원격 프로시저 호출 시스템인 gRPC가 있는데 이 프로토콜은 HTTP/2 기반으로

프로토콜 버퍼를 사용하여 직렬화하여 데이터를 주고 받아 대용량, 실시간 데이터 처리를 할 때 사용합니다.

 

참고한 자료

HTTP의 역사

Evolution of HTTP