웹 통신을 위한 네트워크 이해하기 3 - QUIC (UDP)

우리는 보통 TCP와 견주어 UDP를 많이 학습합니다. UDP의 대표적 특징으로는 아래 항목들이 있습니다.

• 비연결형 프로토콜이다.
• TCP와 달리 handshake를 하지 않아 속도'는' 빠르다.
• 하지만 패킷의 유실 관리나 순서 보장을 하지 않아 신뢰성 있는 통신이 불가능하다.
• 주로 DNS에 IP 주소 요청할 때, DHCP에 사용된다.

개인적으로는 오늘날에는 인터넷 속도도 빠르다보니 신뢰성 있는 통신의 가치가 더 높다고 생각하여 현대 사회에서 대부분의 통신은 TCP 기반으로 이루어질 것이라 생각하였습니다. 실제로 웹 통신에서는 HTTP 통신이 가장 많이 쓰이는데 이게 기본적으로 TCP 기반으로 알려져 있죠. 근데 다시 네트워크를 공부하다가 신기한 사실을 알아냈습니다.

충격적이게도 모든 HTTP가 TCP로 이뤄지진 않는다는 것입니다!

 

엥? HTTP/1.1과 HTTP/2까지는 분명 TCP로 이뤄진다고 알고 있었습니다. 참고

 

근데... HTTP/3부터는 QUIC 기반으로 통신을 한다고 하는 걸 알게 되었고, 이 QUIC가 UDP 기반이라고 합니다. 이는 이미 우리도 모르는 사이에 많이 쓰이고 있는 것 같더라고요! (사실 엄밀히 말하면 QUIC가 등장하고, 이를 사용하는 HTTP를 HTTP/3로 칭하기로 했다고 합니다.)

 

위 사진은 유튜브 사이트에서 영상을 눌러 개발자 도구를 통해 확인한 모습인데요. 유튜브 영상을 시청할 때에도 QUIC를 통해 통신하고 있음을 알 수 있었습니다.

 

근데 또 유튜브 영상은 실시간 스트리밍도 아니라서 굳이 속도에 집착할 필욘 없을 것이거든요. 신뢰성 있는 통신을 통해 설정한 고화질을 제공해야 하기도 하구요.

 

넵 맞습니다. QUIC 프로토콜은 UDP의 빠른 통신 속도와 TCP의 신뢰성을 보장하는 통신 두 가지 장점을 둘 다 챙긴 프로토콜입니다. 그럼 이게 어떻게 된 일인지 한번 확인하시죠.

 

QUIC (Quick UDP Internet Connections) 란,

UDP를 베이스로 하고 멀티플렉스와 보안을 지원하는 전송 계층 프로토콜로, 구글의 짐 로스킨가 처음 설계하여 2012년 구현되었습니다. 이후 2021년에 표준화되어 현재 크롬에서부터 구글 서버에 이르는 모든 연결의 절반 이상에 QUIC가 사용된다고 하며, 현존하는 대부분의 브라우저들 또한 기본적으로 QUIC를 사용하여 통신하고 있습니다.

 

위 사진은 QUIC를 검색하면 쉽게 보이는 HTTP/2와 HTTP/3를 비교하는 사진입니다. 이를 통해 알 수 있는 사실은 다음과 같습니다.

• HTTP/2에서 지원하는 기능은 대체로 전부 지원한다. (header compression, server push, session resumption, congestion control, connnection oriented, etc.)
• stream multiplexing을 UDP 기반으로 구현하여 HTTP/2까지 존재하던 HOLB문제를 해결하였다.
• TLS가 TCP와 별도의 레이어로 구분되어있던 것과 달리, HTTP/3에서는 TLS를 QUIC의 기본 스펙으로 지원된다.

 

QUIC의 핵심적인 장점은 다음과 같습니다.

멀티플렉싱

이게 뭔지, 뭐가 좋은지 알기 위해서는 HTTP/1.1로 거슬러 올라가서 통신 방식을 이해해야 합니다.

 

HTTP/1.1에서는 통신 성능 향상을 위해 하나의 커넥션 안에서 이전 요청에 대한 응답을 기다리지 않고 다음 요청을 연속적으로 보내는 파이프라이닝을 지원하고 있었습니다. 하지만 TCP 프로토콜의 구조상 응답 순서는 보장되어야 하기 때문에 첫 번째 요청에 대한 응답이 너무 오래 걸리면, 이후 요청에 대한 응답도 무작정 대기되는 비효율이 발생하게 됩니다. 이걸 Head Of Line Blocking (HOLB) 문제라고 칭합니다.

 

이를 해결하고자 기존에는 Domain Sharding(도메인 샤딩)이라는 방법을 사용하였습니다. 도메인 명을 여러개로 설정하여 같은 서버에 이미지나 css, js와 같은 static files를 병렬로 요청하여 각 도메인 명에 여러 커넥션을 맺어서 리소스를 병렬적으로 수신하겠다는 목적으로 고안된 방법입니다. 즉, 성능 개선을 위해 여러 TCP 연결을 수립하여 사용한 겁니다. 하지만 브라우저별로 도메인 커넥션 갯수 제한이 존재하였고, 결국 근본적인 해결은 하지 못했습니다.

 

HTTP/2에서는 HTTP/1.1과 달리 한 개의 TCP 연결에서 여러 요청과 응답을 동시에 전송할 수 있게 하는 멀티플렉싱을 지원하였습니다. 즉, 클라이언트와 서버 사이에 TCP 연결이 수립되면 하나의 TCP 연결 안에 여러 개의 독립적인 양방향 데이터 흐름을 확보할 수 있는 멀티 '스트림'을 생성하는 방식입니다. 각각의 스트림은 요청이나 응답을 담은 HTTP 메시지를 주고 받습니다. 이 메시지는 네트워크를 통해 전송하는 단위인 '프레임'으로 분할되어 서로 다른 스트림을 타고 시퀀스 넘버를 바탕으로 병렬적으로 타고 갈 수 있게 되었습니다. 전송 과정에서도 스트림에 정수 가중치를 설정하여 스트림 우선순위를 부여할 수 있어서 수신 측에서는 우선순위가 높은 응답을 먼저 받을 수 있게 됩니다. 이를 통해 전체 요청 및 응답에 대한 다중화를 구현하였고, 기존 HTTP/1.1에서 발생했었던 HOLB를 해결할 수 있게 됩니다.

 

하지만, HTTP/2에서도 TCP 통신 방식에 따라 피할 수 없는 다른 HOLB 이슈가 존재했습니다. TCP 통신은 신뢰성 있는 통신을 구현하고자 유실된 패킷을 재전송하는 기능을 제공하고 있는데, 만약 TCP 통신에서 하나의 커넥션 내에서 패킷 유실이 발생하면, 결국은 하나의 TCP 연결 안에서는 스트림 1개가 유실 패킷을 재전송할때까지 나머지 N개의 스트림이 대기 상태로 돌입되는 문제입니다.

출처:  FAUN (HTTP/2 and HTTP/3)

 

QUIC는 기본적으로 UDP 기반으로 데이터를 전송하므로 TCP 방식으로 인해 발생하는 고유의 HOLB 문제를 해결하였습니다. QUIC는 수립한 커넥션 안에서 통신을 수행할 때 각 스트림을 UDP 방식으로 독립적으로 다중화하여 전송하므로 패킷 유실이 발생하였을 때 다른 스트림의 데이터 전달을 차단하지 않아 HOLB 이슈가 발생하지 않습니다. 이로써 성능 좋은 멀티플렉싱을 이뤄냈습니다.

 

0 RTT 통신

TCP는 기본적으로 TLS와 별개로 고안된 보안 프로토콜이므로, HTTP/2까지는 TCP 위에서 동작하였습니다. 즉, HTTP/2 까지는 TCP 핸드셰이크를 통한 연결 수립과 TLS 핸드셰이크를 통한 보안 연결 수립이 별도로 이뤄져야 했으므로 N번의 round trip을 수행해야만 했습니다.

 

하지만 QUIC에서는 연결 수립을 하는 과정을 한 번의 통신으로 하고자 했으며, 어차피 연결이 되지 않으면 암호화된 메세지를 읽을 수 없을 테니 바로 enciphered data(통신의 목적이 되는 데이터)를 쏴버립니다.

 

출처 : Medium (what is HTTP/3?)

 

따라서 이론상 0 RTT만으로 통신이 이뤄질 수 있도록 구현된 방식이 QUIC입니다.

 

마무리

위 사항 외에도 Connection migration을 지원한다는 것도 제 입장에서는 신기한 포인트였습니다. 이건 HTTP/2에서 이미 지원한 기능이라고 하는데, 간단하게 말하면 패킷 헤더에 Connection ID를 갖고 있어서 클라이언트의 IP 주소가 달라져서 커넥션을 재수립 하더라도 이전에 전송중이던 데이터를 받을 수 있게 하는 기능이라고 합니다. 오늘날 인터넷 연결이 케이블로만 되지 않고, 셀룰러 데이터와 와이파이를 오가는 형태가 빈번하다보니 반드시 필요한 기능인 것 같은데, 이를 알기 전까진 IP가 변경되는 상황에 대하여 네트워크 통신이 어떻게 유지되는지 깊게 고민해보지 않았기에 신기했습니다.

 

TCP는 헤더를 가득가득 이용하여 신뢰성 있는 통신을 제공하다보니 더 최적화하기에 한계점을 느끼고 있었다 합니다. 이에 반하여, UDP는 처음엔 홀대받았지만 사실은 개척되지 않은 노다지 땅과 같은 영역이었던 거죠. 그래서 이를 기반으로 신뢰성 있는 통신을 구축하여 기존 통신 방식에서 더 최적화된 솔루션을 도출할 수 있었다고 합니다. 세상엔 참 스마트한 사람이 많은 것 같습니다.

 

정리하자면,

QUIC는 강력한 장점으로 인해 이미 HTTP 통신의 주인공으로 자리매김하고 있지만, (언제나 그렇듯) 아직 지원하지 않는 서버가 좀 있어서 브라우저는 HTTP 이전 버전들의 사용까지 모두 지원하고 있다!

 

이제는 TCP만이 신뢰성 있는 통신을 한다고 말하기 어려울 것 같다(?)!!

 

 

 

 

참고 :

https://truesparrow.com/blog/http2-will-stay-even-after-http3-and-quic/

https://ko.wikipedia.org/wiki/QUIC

https://bentist.tistory.com/36

https://appleg1226.tistory.com/61