HTTP/3 이 나온지도 좀 되었겠다 간단히 정리 해보았다.
QUIC이 HTTP/3 스펙으로 확정된 것도 오래되지 않아서, 사실 아직 실서비스에 도입하기에는 무리가 있지만
언젠가 도입할 때가 되면 뭐라도 알아야 할 것 같아서 살펴보았다.
[TCP / UDP]
HTTP/2 와 HTTP/3 의 가장 큰 차이점은 기존 HTTP/2가 TCP 위에서 동작한 것과 달리 HTTP/3 은 UDP 에서 동작한다는 것이다.
구글에서 TCP로 인해 생긴 병목을 해결하기 위해 만든 UDP 기반의 QUIC 이 HTTP/3 으로 들어오면서 생긴 변화이다.
세부적으로는 QUIC과 많은 차이가 있지만, UDP 위에서 돌아가게 된 것은 QUIC의 영향력이 크다.
구글에서 크롬 등으로 서비스하며 QUIC 의 시장성을 검증해 낸 것에 힘입어 HTTP/3 (이하 h3) 으로 QUIC이 들어올 수 있었던 것으로 보인다.
[HTTP-over-QUIC to be renamed HTTP/3 | ZDNet](https://www.zdnet.com/article/http-over-quic-to-be-renamed-http3/)
아래에 기술하게 될 변화들은 TCP와 UDP의 차이에서 기인한 것들이 많다.
[ TCP 상에서의 HOL Blocking ]
HOL (Head Of Line) 은 주로 HTTP/1 에서 발생하는 문제점을 이야기했다.
HTTP/1 에서는 multiplexing을 지원하지 않아 HTML 파일 초입에 크기가 큰 이미지 파일이나 js 파일이 있을 경우, 이를 로딩해야만 그 뒤의 콘텐츠들도 전송되었기 때문에 페이지 로딩 시 필요 이상으로 느려지는 문제가 있었다.
HTTP/2 (이하 h2) 에서는 multiplexing 을 지원해 동시에 여러 콘텐츠가 전송될 수 있도록 개선되어 이러한 문제를 피할 수 있었다.
다만 h2 에서는 단일 TCP 연결 방식에 의해 TCP 연결에서 packet loss가 일어나는 등 네트워크의 상태가 좋지 않으면, 최대 6개의 TCP 연결을 허용한 HTTP/1 보다 품질이 좋지 않은 경우도 있었다.
[https://http3-explained.haxx.se/ko/why-tcphol.html] (https://http3-explained.haxx.se/ko/why-tcphol.html)
https://www.akamai.com/us/en/multimedia/documents/technical-publication/http2-performance-in-cellular-networks.pdf
h3에서는 다수의 연결 스트림을 만들어 전송하므로서 HOL Blocking 을 피했다고 한다.
서로 다른 스트림은 독립적으로 동작하여 출발지에서 전송한 순서대로 도착한다는 것을 보장하지는 못하지만, Packet loss로 전체 전송 속도가 떨어지는 현상은 줄어들게 된다.
[ Connection ID (연결 ID) ]
각 connection 별로 연결 ID 를 부여하는 것이 특징이다.
엔드포인트에서 연결 ID를 선택하여 사용해 패킷 손실을 방지한다.
TCP 에서는 wi-fi 연결이 변경될 때 연결을 끊었다가 다시 처음부터 establish 했던 것과 달리 연결 ID 를 사용하면 최초 연결에 드는 비용없이 연결을 유지할 수 있다.
다만, 네트워크 장비에서 UDP 위에 connection ID 를 지원해야 하며, 이 때문에 비용이 생길 수 있다.
[https://tools.ietf.org/html/draft-ietf-quic-transport-11#section-4.7](https://tools.ietf.org/html/draft-ietf-quic-transport-11#section-4.7)
[ 0-RTT ]
TLS를 사용했을 때, 0-RTT라는 이야기인 것 같은데 사실 h3 에서 기본적으로 TLS 1.3을 지원해서 생기는 이득인 것 같다.
따라서 h3 에서의 특징이라기보다는 TLS1.3 의 특징이라고 생각하는 것이 맞는 것 같다.
TLS 1.3 에 대해서는 아래 링크에서 더 자세히 알 수 있다.
[Luavis’ Dev Story - 알아두면 쓸데없는 신비한 TLS 1.3] (https://b.luavis.kr/server/tls-1.3)
[ HPACK과 QPACK ]
h2 에서 http header를 압축하기 위해 사용되었던 HPACK 이 QPACK으로 개선되었다.
기존에 TCP 위에서 HPACK을 사용하다보니 순서에 의존적인 부분이 있었는데,
QUIC이 UDP 위에서 돌아가다보니 순서 의존적인 부분을 사용할 수 없어서 순서에 상관없이 도착해도 돌아갈 수 있도록 개선되었다고 한다.
https://tools.ietf.org/html/draft-ietf-quic-qpack-09 QPACK 에 대한 IERF 문서
[ 지원 상황 ]
Nginx 는 1.17부터 지원한다고 한다. 현재 최신 버전은 1.16인 듯.
HAProxy 는 2.x 이상에서 지원하려나… “지원 계획은 있다” 정도인 것 같다.
apache 는 아직 이야기 나온 것이 없는 듯.
[ 기타 참고 링크 ]
[번역 On The Merits of QUIC for HTTP] (https://tech.ssut.me/on-the-merits-of-quic-for-http/)
이 링크도 흥미로웠다.
책은 러닝 HTTP/2 를 참고했다. http://www.hanbit.co.kr/store/books/look.php?p_code=B1303249964
h3 에 관해서는 나와있지 않지만, HTTP 전반적인 관점에 대해서 도움이 되었다.
'Tech Note' 카테고리의 다른 글
글로벌 비디오 서비스가 가능하게 한 넷플릭스의 Microservice 아키텍쳐 구조 분석 (1) | 2021.01.24 |
---|---|
Consistent Hashing 일관된 해싱 (0) | 2020.12.27 |
Group by 에 대해서 (0) | 2019.05.05 |
Spring 4.x 에서 HttpServletRequest 의 params 를 변경하고 싶을 때 (0) | 2017.08.03 |
git 커밋 시간 변경하기 (0) | 2017.05.08 |