HTTP 2, HTTP 3

참고자료

https://evan-moon.github.io/2019/10/08/what-is-http3/

HTTP/3는 왜 UDP를 선택한 것일까?

https://ykarma1996.tistory.com/86

HTTP3 란 무엇일까

https://http3-explained.haxx.se/ko/h3/h3-h2

HTTP/3과 HTTP/2의 비교

https://www.whatap.io/ko/blog/38/

HTTP/2 알아보기 - 1편 | 와탭 블로그

---

HTTP 1.1의 단점

HTTP 1.1의 파이프라이닝은 하나의 커넥션에서 한 번에 순차적인 여러 요청을 연속적으로 하고 그 순서에 맞춰 응답을 받는 방식으로 지연 시간을 줄인다.

그러나 먼저 받은 요청이 끝나지 않으면 뒤 요청이 끝나도 먼저 온 요청이 끝날때까지 기다려야 한다. 이를 HOLB(Head Of Line Blocking) 문제라고 한다.

이 문제로 인하여 대부분의 모던 브라우저들이 파이프라이닝 사용을 막았다.

따라서 HTTP1.1에서 병렬로 통신하기 위해서 클라이언트가 여러 개(6~8)의 커넥션을 이용해 데이터를 가져온다(병렬 커넥션). 이는 다시 연결비용의 증가를 초래하게 되었다.

참고 : HTTP에서의 HOLB와 TCP에서의 HOLB

https://seokbeomkim.github.io/posts/http1-http2/#%EB%8B%A8%EC%A0%90-1-holhead-of-line-blocking---%ED%8A%B9%EC%A0%95-%EC%9D%91%EB%8B%B5%EC%9D%98-%EC%A7%80%EC%97%B0

HTTP/1.1과 HTTP/2의 차이점

HTTP에서의 HOLB가 Pipelining으로 해소가 되지 않는 이유

RFC 2016 :

8.1.2.2 Pipelining

A client that supports persistent connections MAY "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server MUST send its responses to those requests in the same order that the requests were received. -> 서버는 반드시 응답을 요청 순서에 맞춰서 보내야 한다

Clients which assume persistent connections and pipeline immediately after connection establishment SHOULD be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it MUST NOT pipeline before it knows the connection is persistent. Clients MUST also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses.

Clients SHOULD NOT pipeline requests using non-idempotent methods or non-idempotent sequences of methods (see section 9.1.2). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to send a non-idempotent request SHOULD wait to send that request until it has received the response status for the previous request.

HTTP2

출처 : https://developers.google.com/web/fundamentals/performance/http2?hl=ko

Stream 개념의 등장

HTTP2는 바이너리 프레이밍 계층을 사용해 요청과 응답의 멀티 플렉싱을 지원한다.

멀티플렉싱은 한 개의 TCP 연결에서 여러 개의 데이터를 섞이지 않게 보내는 기법이다. 이 각각의 데이터 흐름을 stream 이라고 한다.

요청과 응답이 동시에 이루어지니 여러 요청과 응답이 뒤섞여 있다. 이를 이용해 여러 개의 연결 없이도 병렬 처리도 할 수 있고, HOLB 문제도 해결한 것이다.

 

그러나 HOLB의 완전한 문제 해결은 되지 않았다. TCP 프로토콜을 사용하는 이상, TCP 패킷이 네트워크 경로에서 손실되면 스트림에 공백이 생겨 그 다음에 오는 바이트들도 재전송으로 인해 전달이 되지 않아 지연이 생긴다. 

특히 HTTP2는 여러개의 HTTP 스트림을 하나의 TCP 커넥션으로 처리해 더 크게 영향을 받는다.

HTTP3

가장 큰 특징은 TCP가 아닌 UDP를 사용한다는 것이다.

정확히 말하면 HTTP3는 QUIC라는 프로토콜 위에서 돌아가는 HTTP인데, QUIC는 Quick UDP Internet Connection의 약자로 UDP를 사용하는 프로토콜이다.

정보통신기획평가원, 웹페이지 로딩시간 개선을 위한 IETF HTTP 표준화 개발 동향, 김평수

TCP는 3 way hand shake, 끝날 때 4way hand shake 등 오버헤드와 HOLB 등의 문제를 피할 수 없다.

QUIC는 TCP hand shake 과정을 최적화하는 것에 초점을 맞추어 설계되었다.

UDP는 데이터그램 방식을 사용하는 프로토콜이기에 각각의 패킷 간 순서가 존재하지 않는 독립적인 패킷이다.

UDP는 TCP에 비해 헤더가 많이 비어있기에, 커스터마이징할 수 있는 여지가 많고 이를 이용해 개발자가 구현을 어떻게 하느냐에 따라서 신뢰성을 확보할 수 있다.

QUIC Overview

이 블로그에 너무 잘 나와있다. 밑은 블로그 글의 요약

연결 레이턴시 감소

RTT : Round Trip Time. 클라이언트가 요청하고 서버가 처리해 다시 응답해주는 사이클

HTTPS over TCP + TLS 소요 레이턴시 : 1RTT(TCP) + 2RTT(TLS) = 3RTT

HTTPS over QUIC 소요 레이턴시 : 1RTT

첫번째 hand shake를 할 때 연결 설정에 필요한 정보와 데이터를 함께 보내 RTT를 것이다. TCP+TLS는 데이터 보내기 전 신뢰성 있는 연결과 암호화에 필요한 정보를 교환 후 데이터를 교환한다.

패킷 손실 감지에 걸리는 시간 단축

TCP는 송신 측이 패킷을 보낸 후 타이머를 사용해 일정 시간 동안 응답이 오지 않으면 패킷이 손상되었다고 판단해 재전송한다. 이때 문제는 TCP가 타임아웃을 언제 낼 것인가를 동적으로 계산해야 한다. 패킷 재전송시 ACK을 받았을 때 첫 번째로 보낸 패킷의 ACK인지 두 번째로 보낸 패킷의 ACK인지 확인해야 한다. 이를 재전송 모호성이라고 한다.

QUIC는 헤더에 별도의 패킷 번호 공간을 부여해 패킷 손실 감지에 걸리는 시간을 단축한다.

멀티플렉싱 지원

여러 개의 스트림을 사용하면 특정 스트림의 패킷이 손실되어도 해당 스트림에만 영향을 미치고 나머지 스트림은 멀쩡히 사용할 수 있다.

HTTP2와 마찬가지로 멀티플렉싱을 지원해 이점을 그대로 가져간다

클라이언트의 IP가 바뀌어도 연결 유지

TCP는 발신지 IP, 발신지 port, 수신지 IP, 수신지 port로 연결을 식별해 클라이언트 IP가 바뀌면 연결이 끊어져 버린다. 이는 다시 연결을 생성하기 위해 3 way hand shake를 다시 해야하고, 레이턴시가 또 다시 발생된다.

요즘같이 모바일로 인터넷을 사용하는 경우 wifi에서 셀룰러로 전환될 때 클라이언트 IP 전환되는 경우가 많아 문제가 심각해진다.

QUIC는 connection ID사용해 서버와 연결을 생성한다. 이는 클라이언트 IP와는 전혀 무관하기 때문에 클라이언트 IP가 변경되더라도 기존의 연결을 계속 유지할 수 있다.