HTTP/1에서 2.0 그리고 3.0 으로

HTTP/1에서 2.0 그리고 3.0 으로

몇 년 전 부터 HTTP/3 이야기가 많이 나왔었다. 그때마다 UDP, QUIC이라는 키워드를 접해 언뜻 알고 있었지만 올해 6월 해당 기술이 표준화 되면서 그에 따른 변화들을 제대로(?) 팔로우해보았다. 다음은 최근 HTTP/3 관련 소식들이다.

• 2022년 6월 6일 HTTP/3는 IETF RFC 9114로 표준화되었다
• Amazon CloudFront, HTTP/3 지원 시작
• chrome, edge, firefox, safari(optional) 등 브라우저에서 HTTP/3 지원
• 2022년 8월 기준 웹 브라우저중 HTTP/3 현재 25% 정도 사용중

HTTP는 90년대부터 사용되기 시작했다. 다음은 HTTP가 진화해 온 과정이다. HTTP/1 → HTTP/1.1 → HTTP/2.0 → HTTP/3.0 각 버전에 대해서 자세히 살펴보자. 해당 글은 내가 요즘 좋아하는 유튜브 영상의 영향을 받아 작성되었다.

 

 

HTTP/1

HTTP/1.0

1996년에 HTTP/1.0이 등장했다. TCP 위에 설계되었는데 같은 서버에서 오는 요청들은 각 TCP 연결을 필요로 했다. 그래서 연결에 대한 비용이 상당히 부담되는 구조를 지니게 되었다.

HTTP/1.0

 

HTTP/1.1

1997년에 HTTP/1.1이 나오면서 TCP 연결을 재사용할 수 있는 기능인 keep-alive라는 메커니즘이 소개되었다. 그래서 TCP 연결을 하나의 요청이 아닌 여러 요청에 대해서도 사용을 할 수 있게 되었다. 연결의 지속성은 요청마다 TCP 3-way handshake를 하지 않아도 되기 때문에 요청시간을 대폭 감소시켜주었다.

HTTP/1.1

 

HTTP/1.1 Keep-Alive

 

HTTP pipelining

HTTP/1.1에 도입된 또 다른 재밌는 기능은 HTTP pipelining이다. 이는 이론적으로 클라이언트는 각 response를 기다리기 전에 여러 request를 보낼 수 있다. response는 request 요청 순서와 동일하게 수신되어야 했는데, 이에 대한 구현은 꽤나 까다로웠고 client와 server 사이에 있는 많은 프록시 서버가 pipelining을 제대로 처리하지 못했다. 그래서 이는 많은 웹 브라우저에서 지양되게 되었다.

HTTP/1.1 pipelining

 

HOL(head of line) blocking

또한 HTTP/1.1 pipelining은 HOL(head of line) blocking으로 고통을 받았다. align blocking 없이 같은 연결에 대한 후속 요청들은 이전 요청이 처리될 때까지 기다려야 했다. 만약 요청이 패킷 손실과 같은 어떠한 이유로 인해 차단이 된다면 같은 연결로 그 뒤에 오는 후속 요청들은 이에 대해 영향을 받을 수 밖에 없었다.

HOL(head of line) blocking

상용할 수 있는 수준의 성능을 유지하기 위해서 브라우저는 일반적으로 하나의 서버에 여러 개의 TCP 연결들을 유지한 채 요청을 병렬로 처리했다.

요약

HTTP/1.0

• TCP 연결을 통해 서버와 클라이언트 간에 request/response 통신을 함

HTTP/1.1

• keep-alive 기능 도입으로 TCP 연결 재사용
• pipelining을 추가하여 요청/응답 레이턴시 낮춤
  • 그러나 요청/응답 순서 동기화를 이뤄야 하는데 프록시 서버에서 많은 문제가 발생함
  • 또한 HOL blocking 문제로 고통 받음. 앞의 요청이 block되면 그 뒤에 있는 후속 요청들에게 영향을 끼침.
• 상용할 수 있는 수준의 성능을 유지하기 위해서 브라우저는 일반적으로 하나의 서버에 여러 개의 TCP 연결들을 유지한 채 요청을 병렬로 처리

 

HTTP/2

2015년에 HTTP/2가 나오면서 하나의 TCP 연결에서 같은 서버로 여러 요청 stream을 보낼 수 있는 Multiplexed Streams을 소개했다. HTTP/1.1의 pipelining과는 달리, 각 stream은 서로에 대해 독립적으로 동작했다. 그래서 요청을 보낼 때 순서를 보장해 줄 필요가 없게 되었다. 이렇게 HTTP/2는 HOL(head of line) blocking 문제를 애플리케이션 계층에서 해결했다. 그러나 TCP 전송 계층에서는 바이트로 데이터를 처리하기 때문에 TCP HOL 문제까지는 해결하지 못하였다.

• TCP HOL 차단 문제: TCP는 엄격한 순서로 데이터를 처리한다. TCP 스트림에서 패킷이 손실되거나 지연되면 후속 패킷은 해당 후속 패킷이 이미 대상에 도착했더라도 누락된 패킷이 재전송 및 수신될 때까지 기다려야 한다. 

HTTP/2 multiplexed streams

또한 HTTP/2는 새로운 데이터를 사용할 수 있을 때 마다 클라이언트가 폴링할 필요없이 서버가 클라이언트에 업데이트를 보낼 수 있도록 하는 푸시 기능을 도입하였다.

요약

HTTP/2.0

• 하나의 TCP 연결에서 여러 요청 stream을 보낼 수 있는 Multiplexed Streams을 소개
  • HTTP/1.1에 있는 pipelining의 문제들을 개선시켜줌
  • 각 stream은 독립적이어서 순서 보장 필요 없고 서로에게 영향을 끼치지 않아 HOL blocking 문제가 발생하지 않음
• 서버 푸시 기능 도입

 

HTTP/3

2020년에 소개된 HTTP/3는 2022년 6월 6일, IETF RFC 9114로 표준화되었다. 이는 전송 계층 프로토콜을 TCP 대신 QUIC이라는 새로운 프로토콜을 사용한다.

QUIC은 UDP기반이다. 해당 프로토콜에서는 전송 계층에서 stream을 일급 시민으로 취급한다. QUIC stream들은 빠르게 연결된 하나의 통로를 공유한다. 그래서 많은 요청이 발생해도 추가적인 handshake는 필요하지 않는다.

QUIC steram은 독립적이다. 만약 한 stream에서 패킷 손실이 발생한다고 하더라도 대부분의 경우 다른 stream에는 영향을 주지 않는다. 그래서 QUIC은 전송 계층에서 head of line blocking 문제를 겪지 않게 된다.

HTTP/3 QUIC

QUIC는 모바일에서의 많은 인터넷 사용량을 위해 설계되었다. 스마트폰을 들고 다니는 사람들을 하루종일 이동하면서 한 네트워크에서 다른 네트워크로 끊임없이 전환(5G → 3G → 4G → WiFi → •••)한다. TCP를 사용하면 한 네트워크의 연결을 끊고 다른 네트워크로 재연결하는 과정이 오래걸릴 수 밖에 없다. 그래서 QUIC은 연결이 [IP 주소]와 [네트워크 인터페이스]간에 빠르고 안정적으로 이동할 수 있도록 하는 connection ID라는 개념을 구현하였다.

connection ID

이러한 장점들로 인해 HTTP/3가 표준화된지는 얼마되지 않았는데도 현재 웹사이트의 25%에서 사용되고 있으며 구글, 유튜브, 페이스북, 인스타그램 등 많은 웹 브라우저에서 지원하고 있다.

Usage of HTTP/3

다음 차트는 가장 인기 있는 사이트와 비교하여 인기도 및 트래픽 측면에서 HTTP/3의 market position을 보여준다.

Market Position of HTTP/3

 

요약

HTTP/3.0

• UDP 기반. 각 stream을 일급 시민으로 취급해서 하나의 연결로 많은 요청들을 처리함
• stream은 독립적이라 패킷 손실이 되어도 HOL block 문제가 발생하지 않음
• 모바일에서의 많은 인터넷 사용량을 위해 설계
  • connection ID라는 개념을 도입하여 네트워크 전환을 빠르게 이루게 해줌
• 22년 6월 표준화되었는데 8월인 지금 웹사이트 25%에서 사용되고 있음