HTTP1/HTTP2/HTTP3

HTTP/1 & HTTP/2 & HTTP/3

HTTP/1

HTTP/1: HTTP/1을 사용하면 클라이언트가 서버에 같은 요청을 할때마다 개별적인 TCP connection이 필요했다. 즉 실제 요청을 하기전 3-way-hand-shake 하는 과정이 필요하다.

RTT(round-trip-time): 클라이언트가 HTML 파일을 서버측에 요청하고 HTML 파일이 클라이언트한테 도달할때 까지의 시간 이다.

위 사진은 HTTP/1 을 사용할때 발생하는 요청의 흐름이다. 데이터 요청을 하기위해 3-way-handshake 과정을 거치며 1 RTT 가 소요되고, 그후 실제 요청을 하고 받는데 1 RTT 총 2 RTT 가 필요하다.

이런 연결을 비지속 연결(non-persistent-connection) 이라 한다. HTTP/1 의 이런 한계를 극복하기 위해 나온것이 지속 연결(persistent connection) 을 사용하는 HTTP/1.1 이다.

 

HTTP/1.1

HTTP/1.1: keep-alive라는 매커니즘을 통해 서버에 요청을 할떄마다 TCP connection이 필요한게 아닌 connection을 재사용할수있도록 했다. 이렇게 함으로서 request latency를 줄일수 있었는데 이 이유는 TCP연결을 시작할때 해야하는 3-WAY-Handshake 과정을 매번 하지 않아도 되기 때문이다. 즉 최초 요청을 하고나선 1 RTT 의 request latency 로 응답을 받을수 있다.

 

HTTP/1.1에서 새롭게 추가된 pipelining 기능을통해 Client는 서버로부터 응답이 오기전 여러개의 요청을 할수있게 되었다.

하지만 pipelining기능을 사용했을때, 서버가 하나의 response를 보내는데 많은 시간이 소요되면 그이후에 보내는 응답들또한 지연이되는 현상이 발생했다. 이때 먼저 전송이되야하는 response가 blocked되면 (ex) packet loss) 같은 connection에 존재하는 다른 요청들에게도 영향이 가는 현상이 발생했다. 이러한 현상을 HOLB (Head-of-line Blocking) 라고 한다. (TCP는 패킷을 순서대로 처리해야하기때문에 HOLB가 발생한다.)

HOLB때문에 여러웹브라우저들이 pipelining사용을 막았으며, 여러 통신을 하기위해선 병렬적으로 여러개의 connection을 사용해 데이터를 가져와야했다.

HTTP/2

HTTP/2: HTTP/2부터는 하나의 TCP connection을 통해 여러개의 request를 stream의 형태로 보낼수 있게되었다.

이로인해 HTTP/1.1 pipelining을 사용하지 못해 여러개의 connection을 사용하여 병렬적으로 데이터를 가져와야하는 문제를 해결했다.(각각의 stream은 서로 독립적이기 때문에 하나가 block되더라도 다른 하나에 영향을 주지 않는다) 즉 HOLB가 Application layer에서는 해결이 되었지만 TCP를 사용하는 transport layer에서는 HOLB문제를 해결하지는 못했다.

결론적으로 HTTP/2 는 요청과 응답을 프레임단위로 나워 인터리빙하고, 반대편 시스템 (클라이언트, 혹은 서버)에서 재조립한다.

 

HTTP/3

HTTP/3: 새로운 protocol QUIC이 등장한다. QUIC은 UDP를 base로 만들어졌으며 TCP가 가지고있던 HOLB와 같은 문제점을 해결하며 레이턴시의 한계를 뛰어넘고자 구글이 개발한 UDP기반의 protocol이다.

QUIC는 위에서 말했듯 UDP를 기반으로 만들어졌다. 따라서 TCP보다 속도가 빠르며, handShake과정또한 필요로 하지않는다(따라서 레이턴시가 감소한다). 하지만 UDP가 TCP에비해 신뢰도가 떨어진다는 사실을 알것이다. 그럼 QUIC는 신뢰도를 떨어뜨리는 대신 빠른 UDP를 사용하냐? 이건 아니다. 왜냐하면 UDP의 장점중 하나가 바로 커스터마이징이다.

커스터마이징, 말그래도 UDP를 커스터마징을 통해 신뢰도를 TCP와 비슷한 수준으로 높일수 있다.

그외에도 패킷 손실 감지에 걸리는 시간을 단축시키며, 멀티플렉싱을 지원... 등 여러 장점들이 있다. 자세한건 HTTP/3는 왜 UDP를 선택한 것일까? 이 블로그를 참조하자.

 

• Reference

  • 소켓 관련 영상
  • 3-way HandShake
  • HTTP/1 & HTTP/2 & HTTP/3