HTTP/3에 대해서

HTTP/2도 이제야 막 알아가던 시점인데 벌써 3이라니!

HTTP3.0이 2020년 10월에 추가되었습니다. 어떻게 이렇게 소문도 없이 나왔는지 모르겠습니다. 그래서 이제서라도 알아보려고 정리해봅니다.

 

이전의 HTTP

https://marrrang.tistory.com/38?category=925235
이것도 한번 참고해보시면 좋을 듯합니다 ㅎㅎ

HTTP/3을 보기 이전에 HTTP/2에 대해서도 잘 모르니 짚고 넘어가겠습니다. HTTP1.1을 사용하던 때와 다르게 리소스들이 증가하였고 점점 더 병렬 수행하는 것이 중요해짐에 따라서 개선이 필요했습니다.

 

기존에는 Plain Text(평문)을 사용했지만 2.0부터는 바이너리 포맷으로 인코딩 된 Message, Frame으로 구성되었습니다.

 

1.0에 비해서 여러 개념들이 도입되었는데 아래와 같습니다.

• Frame : HTTP/2에서 통신의 최소 단위
• Stream : 연결된 통신에서 전달되는 데이터의 흐름
• Message : 요청 또는 응답에 매핑되는 프레임의 전체 시퀀스, 프레임 묶음

위의 그림에서 큰 특징 중 하나를 보면 HEADERS frame, DATA frame이 있습니다. 기존에는 Header와 Data를 구분하는 것은 개행밖에 없었지만 이제는 Frame으로 구분됩니다.

 

HTTP/2 특징

• HTTP헤더 데이터 압축
  • 기존에는 평문이었지만 Huffman Coding을 사용하는 HPACK이라는 압축 방식으로 압축
• Server Push
  • 클라이언트가 요청하지 않은 데이터지만 같이 필요할 거라 판단되는 JavaScript, CSS, Font, 이미지 등 특정 파일들을 서버에서 단일 요청에 함께 전송할 수 있게 됐습니다.
• HOL Blocking 문제 해결
  • 기존 1.0에서는 한 번에 하나의 파일만 보낼 수 있어서 파일 전송이 느린 파일이 앞 순서에 있다면 뒤의 파일들의 전송이 늦어졌습니다. 이것이 HOL Blocking 문제입니다. 2.0부터는 파일을 병렬 전송하여 문제를 해결했습니다.
• Stream 우선순위 지정
  • HTTP/3에서는 프레임의 묶음으로 데이터가 전송됩니다. 따라서 많은 개별 프레임으로 분할될 수 있고 다중화할 수 있게 되었습니다. 이와 함께 스트림들의 순서를 지정해야 할 상황이 있었고 필요가 생겼습니다. 따라서 Stream의 우선순위를 클라이언트가 정할 수 있게 되었습니다.

HTTP/3의 특징

HTTP/3는 기존과는 기반부터 다릅니다. 기존에는 TCP를 사용했지만 3부터는 UDP 기반의 QUIC를 사용합니다.

웹 프로토콜의 기반이 바뀐다면 너무나 큰일 아닌가!

그럼 QUIC가 무엇일까요? 그리고 TCP를 왜 UDP로 변경했을까요?

 

QUIC

QUIC는 구글에서 2013년에 발표한 프로토콜입니다. QUIC는 기존의 TCP 기반 연결의 성능을 개선하고자 하는 프로젝트였고 여기에서 UDP를 채택했습니다. 주요 특징은 아래와 같습니다.

• 기본적으로 보안 기능 내장
  • 기존 TLS의 핸드 셰이크와 3-way 핸드쉐이크를 합쳐서 인증과 암호화 파라미터 조절 기능 제공
  • 기존의 TCP, TLS에서는 2번의 왕복 통신이 필요한 반면 1번의 왕복만으로 처리된다.
• 메타데이터 암호화
• HOL Blocking 해결
  • QUIC는 HTTP/2와도 다르게 QUIC 전송 스트림을 각각의 HTTP스트림과 매핑하고 동시에 QUIC 연결은 하나만 유지한다.
  • 연결이 하나이므로 추가적인 핸드쉐이크 불필요, 혼잡 상황이 전파되지도 않음
• QPACK 압축
  • 초기 QPACK은 HTTP요청/응답의 헤더를 같은 QUIC 스트림으로 직렬화 함. 이 때문에 헤더의 도착 순서가 보장되지만 HOL Blocking 문제가 다시 발생
  • 최신 HTTP/QUIC 맵핑과 QPACK 스펙에 따르면 HTTP요청/응답을 양방향 QUIC 스트림을 바꿔가며 사용하기 때문에 HOL Blocking이 발생하지 않는다.
• 반사 공격에 취약

TCP는 왜 변경되었나

	TCP	UDP
연결 방식	연결형 서비스	비연결형 서비스
패킷 교환	가상 회선 방식	데이터그램 방식
전송 순서 보장	보장	보장하지 않음
신뢰성	높음	낮음
전송 속도	느림	빠름

TCP와 UDP의 차이점이라고 한다면 간단하게 위와 같습니다. 여기서 눈에 띄는 것은 전송 속도가 UDP가 빠르다는 거죠.

그럼 신뢰성이 낮다는 것과 전송 순서가 보장되지 않은 점, 기존의 TCP 방식에 익숙해져 있는 하드웨어들과 호환성 문제도 해결한다면 우리가 가장 민감한 속도를 얻게 됩니다.

 

HTTP/3로 변경

TCP를 포기하고 QUIC를 선택하면서 얻게 된 장점들을 보겠습니다.

• 프로토콜 자체에 암호화 기능이 포함되어 있다.
• 모든 핸드 셰이크가 단일 요청/응답으로 끝난다.
• UDP는 TCP 보다 커스터마이징에 용이하다. 기존 TCP는 단점을 보완하기 위해 옵션 필드를 거의 사용할 수 없지만 UDP는 많은 옵션을 추가할 수 있다.
• 패킷이 개별적으로 암호화되어, 다른 데이터 부분의 패킷을 기다릴 필요가 없다.
• 통신이 병렬적으로 수행되며 이를 통해 HOL Blocking을 해결할 수 있다.
• QUIC는 운영체제 커널과 독립적으로 응용 프로그램 공간에 구현할 수 있어서 데이터 이동과 콘텍스트 전환에 의한 오버헤드가 없어진다.
• Source Address와 무관하게 연결 식별자가 포함되어 있어서 IP 주소가 변경되더라도 커넥션을 유지할 수 있다.

정리해보자면, 핸드 셰이크로 인한 지연, 패킷 손실로 인한 지연 없음, 편리한 암호화, 콘텍스트 전환에 의한 오버헤드 없어짐 등의 장점을 얻게 됩니다.

 

많이 사용하는가?

이미 HTTP/2 버전도 충분히 잘 사용하고 있고 나온 지 1년밖에 안된 기술이라 변화하기에는 무리가 있어 보입니다.

하지만 통신이 중요한 서비스에서는 이미 적용하고 있는 것 같습니다. 대표적으로는 CDN 같이 데이터를 빠르게 전송해주는 것이 중요한 서비스가 발 빠르게 HTTP/3을 적용하고 있다는 소식이 보이기도 합니다.

 

그리고 구글에서 개발한 것이다 보니 이미 구글 크롬에서는 HTTP/3을 지원하는 카나리 빌드를 배포했고 이것을 크롬에 적용해볼 수 있게 추가되었는데요. 터미널에서 아래의 옵션 코드를 추가하여 실행할 수 있습니다.

 open -a Google\ Chrome --args --enable-quic --quic-version=h3-23

이외에도 Mozila Firefox, Linux도 HTTP/3에 대응하는 업데이트를 준비 중이거나 이미 적용된 것으로 보입니다.

이것만 보아도 앞으로 HTTP/3이 메인 프로토콜로서 역할을 할 것이란 게 보이는 것 같습니다.