HTTP/3와 QUIC 알아보기

HTTP/3와 QUIC 알아보기

HTTP/3는 현재 개발중인 HTTP의 세번째 메이저 버전이다. HTTP/3와 QUIC를 알아보기 전에 HTTP/1.x와 HTTP/2에 대해서 알면 좋은데 HTTP/1.x와 HTTP/2 알아보기를 읽으면 도움이 될 것이다. HTTP/3는 HTTP/1.x, HTTP/2와 다르게 UDP 기반의 QUIC 프로토콜을 사용한다. 그럼 왜 HTTP/3는 TCP 대신 UDP를 선택했고 QUIC는 무엇일까?

 

1. TCP의 한계

1-1) 불필요한(?) 레이턴시 발생

TCP는 연결을 시작(초기화)할 때 3 Way Handshake를 연결을 종료할 때 4 Way Handshake 과정을 거친다.

 

 

HTTP/1에서는 하나의 TCP 연결에 하나의 요청만 처리가 가능했다. 그래서 매 연결마다 핸드쉐이크 과정을 거쳤다. 핸드쉐이크를 최소화 하기위해 HTTP/2에서는 Stream 개념을 도입하여 하나의 TCP 연결에 데이터를 병렬로 보내도록 개선하였다. 핸드쉐이크 횟수를 줄인것이다.

 

하지만 HTTP+TLS+TCP에서는 이야기가 다르다. TLS와 TCP가 각각 핸드쉐이크가 발생한다. TCP는 서버와 클라이언트 간의 세션을 설정하기 위해 핸드셰이크가 필요하고 TLS는 세션 보안을 보장하기 위해 자체 핸드셰이크가 필요하다. 이렇게 불필요한 레이턴시가 발생하는데 QUIC에서는 이걸 단일 핸드셰이크로 처리한다.

 

 

1-2) HOL(Head-of-Line) Blocking

HTTP/2에 파이프라이닝(PIPELINING)이 도입되었다. 파이프라이닝은 keep-alive를 전제로하여 하나의 커넥션에서 한번에 순차적인 여러 요청을 연속적으로 하고 그 순서에 맞춰 응답을 받는 방식으로 지연 시간을 줄이는 방법이다. 하지만 순차적으로 데이터를 요청하고 받아야 하다 보니 먼저 받은 요청이 끝나지 않으면 다음 요청의 처리가 빨리 끝나도 먼저 들어온 요청이 끝날때까지 기다려야한다. 이렇게 패킷이 중간에 유실되거나 수신 측의 패킷 파싱 속도가 느리다면 통신에 병목이 발생하게 된다. 이를 HOL(Head Of Line) Blocking이라고 부른다.

 

 

1-3) 확장성 부족

TCP는 70년대 개발된 이래 인터넷의 중추적인 전송 프로토콜 역할을 하고있다. 하지만 오래전에 설계된 프로토콜인 관계로 확장성이 부족하다.

 

 

위 그림은 TCP 헤더 포맷이다. TCP의 기능 확장을 위해서는 Options 필드를 사용해야 하는데 이미 MSS, Window Scale, Selective ACK, TCP timestamp 등 거의 기본으로 사용되는 옵션들이 모두 사용 중이다.

 

 

 

반면에 UDP는 데이터를 실어 보낼 수 있을 뿐 그 이외의 기능은 아무것도 정의해 놓지 않았다. 오직 데이터 전송 자체에만 초점을 맞추고 설계했기 때문이다.

보통 TCP는 신뢰성이 높지만 전송이 느리고, UDP는 신뢰성이 없지만 전송이 빠르다고 많이 알고 있다. 하지만 이건 반은 맞고 반을 틀린 이야기이다. UPD의 약자 User Datagram Protocol에서 알 수 있듯이 사용자가 정의하면 UDP에도 신뢰성을 부여할 수 있다.

 

그럼 아예 새로운 프로토콜을 만들면 되지 않을까?

가능은 하지만 현실적 문제가 존재한다. 실제 인터넷 트래픽은 거의 TCP와 UDP가 차지하고 있다. 가령 HTTP는 TCP 위에서 동작하고 DNS는 UDP나 TCP위에서 동작한다. TCP나 UDP가 아니면 아예 통과하지 못하는 라우터나 방화벽들도 존재한다. 그리고 방화벽 설정을 할 때 TCP나 UDP 트래픽이 아니면 모두 막도록 설정하는 경우도 있다. 또한 가정용 라우터와 같이 NAT환경을 기본적으로 만드는 경우 TCP나 UDP가 아니라면 제대로 주소 변환이 안 될 수도 있다. 만약 새로운 프로토콜을 만들었다 하더라도 실제 인터넷상에서 사용할 수 있는지 보장이 안된다.

 

 

2. QUIC (Quick UDP Internet Connection)

QUIC(Quick UDP Internet Connection)는 구글에서 설계한 UDP 기반의 프로토콜이다. 위의 TCP의 한계를 극복하기 위해 UDP 기반으로 새로운 프로토콜을 만들게 되었다. 퀵이라고 발음한다. QUIC에서 개선된 점과 현재 점유율 그리고 단점은 없는지 알아보자

 

2-1) 레이턴시 감소

기존 TLS+TCP에서는 TLS 연결을 위한 핸드셰이크와 TCP를 위한 핸드셰이크가 각각 발생했다. QUIC에서는 이를 한단계로 줄였다.

 

 

TLS+TCP는 세션키를 주고 받고 암호화된 연결을 성립한 후에 세션키와 함께 데이터를 교환한다. 반면에 QUIC는 프로토콜 내에 TLS를 포함하여 데이터 전달과 암호화 절차가 동시에 수행된다.

 

 

QUIC는 연결 식별자(Connection Identifier)로 Connection ID를 사용한다. (TCP는 IP, Port를 사용) 클라이언트는 Connect ID를 사용하여 Initail Key를 생성하고 이를 데이터와 함께 전송한다. 그러면 클라이언트에 토큰과 서버의 공개 Diffie-Hellman 값을 반환하여 서버와 클라이언트가 Inital Key에 동의한다. 클라이언트와 서버는 즉시 데이터 교환을 시작할 수 있으며 동시에 최종 세션키를 설정한다. 한번 연결에 성공했다면 이후 그 값을 저장해놓고 다음 연결부터 저장해놓은 값을 데이터 패킷과 함께 서버로 전송한다. 이러면 바로 연결을 성립되기 때문에 0 RTT만으로 통신을 할수 있다. (좀 어려운 내용이라 러프하게 이정도까지만 이해했다.)

 

2-2) HOL(Head-of-Line) Blocking 최소화

 

TCP의 바이트스트림 추상화는 모든 데이터를 단일 파일의 일부로 간주하기 때문에 단일 TCP 패킷 손실은 여러 전송 중인 리소스에 대한 데이터를 지연시켰다. 위 첫번째 두번째 스트림 그림처럼 한개의 손실만 일어나도 뒤에 있는 모든 데이터들이 지연되거나 전송이 안될 수 있다. 반면에 QUIC는 여러 개의 동시 바이트스트림이 있고 스트림별로 손실을 처리하기 때문에 해당 손실외에 다른 데이터들은 정산적으로 전달된다.

 

2-3) 네트워크가 바뀌어도 연결이 유지된다.

TCP는 연결을 4-tuple(Source IP, Source Port, Destination IP, Destination Port)로 식별했다. 우리가 스마트폰으로 인터넷을 하다가 네트워크가 셀룰러에서 와이파이로 바뀌면 클라이언트의 IP가 바뀌기 때문에 연결이 끊어진다. 다른 조건이 동일하더라도 새 연결을 설정하려면 새로운 TCP(및 TLS) 핸드셰이크를 실행해야 한다. 네트워크가 바뀌면 일시적으로 지연이 발생하는 이유가 이 이유이다.

 

 

 

반면 QUIC은 Connection ID를 사용하여 서버와 연결을 생성한다. Connection ID는 랜덤한 값일 뿐, 클라이언트의 IP와는 전혀 무관한 데이터이기 때문에 클라이언트의 IP가 변경되더라도 기존의 연결을 계속 유지할 수 있다. 이는 새로 연결을 생성할 때 거쳐야하는 핸드쉐이크 과정을 생략할 수 있다.

 

 

Connection ID가 동일한건 아니다.

단일 Connection ID만 사용한다면 해커와 도청자가 네트워크를 통해 사용자를 추적하고 확장하여 그들의 (대략적인) 물리적 위치를 추론하는 것이 매우 쉬워질 것이다. 이 개인 정보 보호 악몽을 방지하기 위해 QUIC은 새 네트워크가 사용될 때마다 Connection ID를 변경한다.

 

 

내부적으로 클라이언트와 서버가 모두 연결을 위해 무작위로 생성한 Connection ID에 대해 인지하고 있고 네트워크가 바뀔때 Connection ID를 바꾸더라도 이게 이전 Connectin ID와 동일하다고 인지하여 연결을 유지하는 것이다.

 

 

3. HTTP/3에 대한 걱정들

TLS 1.3은 여전히 ​​TCP 위에서 독립적으로 실행할 수 있지만 QUIC는 대신 TLS 1.3을 캡슐화한다. 달리 말하면 TLS 없이 QUIC를 사용할 방법이 없다. QUIC는 기존에는 암호화하지 않던 헤더 필드도 암호화한다. 네트워크 중개자가 기존에 암호화하지 않던 헤더 필드 영역들을 읽을 수 없게 되는데 기업들이 이 이유로 도입을 주저하고 있다.

 

 

 

 

 

그리고 53 포트가 아닌 UDP 트래픽이 최근에는 주로 공격에 사용되기 때문에 많은 서비스들에서 차단하거나 속도를 제한하고 있다. 특히 기존의 UDP 프로토콜과 잘 알려진 서버 구현체 중 일부는 증폭 공격에 대한 취약점이 있으므로 공격자가 무고한 대상 피해자에게 대량의 트래픽을 보낼 수 있다. QUIC에서는 초기 패킷이 최소 1200바이트여야 한다는 조건과 서버가 클라이언트로부터 응답 패킷을 받지 않으면 요청 크기의 3배 이상은 절대 보내면 안 된다는 프로토콜의 제약사항으로 증폭 공격을 완화하는 기능이 들어있다.

 

 

 

전체 웹사이트 중에 25.2% 정도가 HTTP/3를 사용하고 있다. 대표적으로 구글, 유튜브 등이 있다. 얼마나 오래 걸릴진 모르겠지만 HTTP/3도 점점 발전해 나갈것이고 HTTP는 TCP라는 이야기도 언젠간 바뀌지 않을꺼라 생각된다.

 

 

참고

• https://blog.cloudflare.com/http3-the-past-present-and-future/
• https://blog.cloudflare.com/head-start-with-quic/
• https://www.smashingmagazine.com/2021/08/http3-core-concepts-part1/
• http://ktccs.kips.or.kr/digital-library/full-text/view?doi=10.3745/KTCCS.2021.10.5.137
• https://evan-moon.github.io/2019/10/08/what-is-http3/
• https://http3-explained.haxx.se/ko/criticism
• https://www.hamadevelop.me/http3/
• https://medium.com/codavel-blog/quic-vs-tcp-tls-and-why-quic-is-not-the-next-big-thing-d4ef59143efd�