Обновлено 1 месяц назад
모든 TCP 연결은 하나의 의식으로 시작됩니다. 장치가 SYN을 보냅니다. 서버가 SYN-ACK로 응답합니다. 클라이언트가 ACK로 답합니다. 실제 데이터가 오가기 전에 이미 한 번의 왕복이 지나갑니다. 여기에 TLS 암호화를 추가하면 더 많은 메시지와 또 한 번의 왕복이 필요합니다. 같은 도시의 광섬유 연결에서는 거의 느끼지 못합니다. 하지만 인도 농촌 지역의 모바일 네트워크에서는 실제 요청 데이터가 단 1바이트라도 전송되기 전에 400밀리초를 기다려야 합니다.
QUIC은 이 의식을 없앱니다. 단 한 번의 왕복으로 암호화된 연결을 설정합니다—때로는 왕복이 전혀 필요 없기도 합니다. 그리고 그것은 UDP 위에서 신뢰할 수 있는 전송을 처음부터 다시 구축했을 때 달라지는 것들의 시작에 불과합니다.
TCP의 문제점
TCP는 1974년에 설계되었습니다1. 오랫동안 훌륭하게 기능해왔지만, 인터넷이 발전하면서 세 가지 한계가 점점 더 뚜렷하게 드러났습니다.
핸드셰이크 세금. 모든 새 TCP 연결에는 3방향 핸드셰이크가 필요합니다. 암호화를 위한 TLS까지 추가하면 또 한 번의 교환이 필요합니다. 애플리케이션 데이터가 흐르기 전에 최소 두 번의 왕복을 치러야 합니다. 지연이 높은 네트워크에서는 새 연결마다 수백 밀리초가 추가됩니다.
헤드 오브 라인 블로킹. TCP는 바이트가 순서대로 도착하도록 보장합니다. 패킷 5가 손실되면, 패킷 6, 7, 8은 전혀 관련 없는 데이터를 담고 있어도 기다려야 합니다. HTTP/2는 하나의 TCP 연결에서 여러 요청을 다중화하려 했지만, 오히려 문제를 악화시켰습니다. 패킷 하나를 잃으면 모든 요청이 멈춥니다.
취약한 신원. TCP는 네 개의 숫자로 연결을 식별합니다: 출발지 IP, 출발지 포트, 목적지 IP, 목적지 포트. 이 중 하나라도 바뀌면—예를 들어 스마트폰이 WiFi에서 셀룰러로 전환될 때—연결이 끊어집니다. 처음부터 다시 시작해야 합니다.
이것들은 버그가 아닙니다. 50년 전에 내려진 결정들의 결과이며, 전 세계 운영체제 커널에 깊이 박혀 있습니다. 인터넷의 모든 장치를 업데이트하지 않고는 TCP를 고칠 수 없습니다.
QUIC이란 무엇인가
QUIC은 TCP처럼 신뢰할 수 있고 순서가 보장된 전달을 제공하지만, UDP 위에서 동작하는 전송 프로토콜입니다. Google이 2012년에 개발을 시작했고, IETF가 2021년에 표준화했습니다.
UDP 기반이 중요한 이유가 있습니다. UDP는 단순합니다. 보장 없이 패킷을 전송합니다. 핸드셰이크도, 순서 보장도, 신뢰성도 없습니다. QUIC은 이러한 기능 모두를 UDP 위에 구축하지만, 커널이 아닌 애플리케이션 코드에서 처리합니다. 이는 QUIC이 운영체제 업데이트를 기다리지 않고 발전할 수 있음을 의미합니다.
TCP는 땅속에 묻힌 인프라입니다. 변경하려면 수천 개의 조직이 관리하는 수십억 개의 장치—스마트폰, 서버, 라우터, IoT 센서—를 업데이트해야 합니다. 작은 TCP 변경도 확산되는 데 수년이 걸립니다. QUIC은 애플리케이션이 자체 업데이트를 제어하는 사용자 공간에서 실행됨으로써 이 문제를 우회합니다.
한 번의 왕복으로 연결하기
QUIC은 전송 핸드셰이크와 TLS 핸드셰이크를 단일 교환으로 결합합니다. 클라이언트가 hello 메시지와 암호화 매개변수를 전송하면, 서버가 hello로 응답하고 연결이 설정됩니다. 단 한 번의 왕복으로 암호화된 데이터를 전송할 수 있습니다.
재방문하는 경우에는 더욱 좋습니다. QUIC은 왕복 없이 이전 세션을 재개할 수 있습니다. 클라이언트가 첫 번째 패킷에 암호화된 애플리케이션 데이터를 담아 보냅니다. 서버는 즉시 응답할 수 있습니다. 이 0-RTT 모드가 재방문 시 QUIC을 즉각적으로 느끼게 만드는 이유입니다.
서로 블로킹하지 않는 스트림
단일 QUIC 연결 안에서 여러 독립적인 스트림을 열 수 있습니다. 각 스트림은 자체적인 순서 보장을 가집니다. 스트림 4에 속한 패킷이 손실되면, 스트림 4만 재전송을 기다립니다. 스트림 1, 2, 3은 중단 없이 계속됩니다.
이것이 HTTP/2의 다중화 문제를 해결합니다. 브라우저가 HTTP/2로 TCP를 통해 이미지, 스타일시트, 스크립트를 요청하면, 이것들은 하나의 순서 있는 바이트 스트림을 공유합니다. 이미지에서 패킷을 잃으면 스타일시트와 스크립트도 기다려야 합니다. QUIC에서는 각 리소스가 자체 스트림을 갖습니다. 패킷 손실은 그 패킷을 잃은 리소스에만 영향을 미칩니다.
이것이 HTTP/3—QUIC 위에 구축된 HTTP—이 존재하는 이유입니다. TCP 위에서는 이 프로토콜이 잠재력을 발휘할 수 없었습니다.
연결 마이그레이션
TCP는 여러분의 위치로 여러분을 기억합니다: IP 주소와 포트. 이동하면—네트워크를 전환하면—TCP는 여러분의 존재를 잊습니다. 연결이 끊어집니다. 핸드셰이크 의식을 처음부터 다시 시작해야 합니다.
QUIC은 연결에 ID를 부여합니다. 스마트폰이 WiFi에서 셀룰러로 전환될 때 IP 주소는 바뀌지만, 연결 ID는 바뀌지 않습니다. QUIC 연결은 중단 없이 새 네트워크 경로로 이전합니다. 화상 통화가 계속됩니다. 다운로드가 재개됩니다.
우리는 수십 년 동안 거실에서 주방으로 걸어가는 순간 끊어지는 기반 위에 신뢰할 수 있는 인터넷을 구축해왔습니다. 연결 마이그레이션이 이것을 고칩니다.
암호화는 선택 사항이 아니다
TCP는 암호화를 별도의 관심사로 취급합니다. TLS 없이 TCP를 실행할 수 있습니다. 많은 애플리케이션이 의도적으로든 잘못된 설정으로든 그렇게 합니다.
QUIC은 초기 핸드셰이크를 제외한 모든 것을 암호화합니다. 암호화되지 않은 모드는 없습니다. 실수로 암호화 없이 QUIC을 배포할 수 없습니다. 프로토콜 자체가 그것을 지원하지 않기 때문입니다.
이것은 기본적으로 인터넷을 더 안전하게 만듭니다. 또한 QUIC을 방해하기 더 어렵게 만듭니다—미들박스는 읽을 수 없는 것을 검사하거나 수정할 수 없습니다.
HTTP/3: QUIC의 주요 응용
HTTP/3은 QUIC 위에 구축된 최초의 주요 인터넷 프로토콜입니다. HTTP/1.1과 HTTP/2가 TCP에서 실행되는 반면, HTTP/3은 오직 QUIC에서만 실행됩니다.
이 조합은 HTTP/2가 직면했던 모든 성능 문제를 해결합니다. 요청 간 헤드 오브 라인 블로킹이 없습니다. 다중 왕복 연결 설정도 없습니다. 네트워크가 바뀌어도 연결이 끊어지지 않습니다. HTTP/3은 HTTP/2가 되고 싶었던 모습이며, 전송 계층이 협력하기에 비로소 가능합니다.
배포 현실
QUIC 도입은 빠르게 증가했습니다. Chrome, Firefox, Safari, Edge 모두 HTTP/3을 지원합니다. Cloudflare, Fastly, 주요 클라우드 제공업체들이 QUIC 엔드포인트를 제공합니다. 2025년 기준으로 약 30~36%의 웹사이트가 HTTP/3을 지원하며, Chrome 브라우저 트래픽의 약 40%가 QUIC을 사용합니다2.
하지만 과제도 남아 있습니다. 일부 기업 방화벽은 특정 포트를 제외한 UDP를 차단합니다. 딥 패킷 검사 장비가 QUIC을 제대로 처리하지 못할 수도 있습니다. 브라우저들은 폴백을 구현합니다: 먼저 QUIC을 시도하고, 실패하면 TCP를 통한 HTTP/2로 전환합니다.
이 폴백 패턴은 QUIC 도입이 점진적으로 이루어질 수 있음을 의미합니다. 사이트들은 호환되지 않는 네트워크도 여전히 작동한다는 것을 알면서 HTTP/3을 활성화할 수 있습니다. 시간이 지나면서 네트워크 장비가 QUIC을 인식하게 되면, 더 많은 연결이 더 빠른 프로토콜을 사용하게 될 것입니다.
왜 중요한가
QUIC은 TCP와 동일한 보장—혼잡 제어를 갖춘 신뢰할 수 있고 순서 있는 전달—을 제공하지만, 50년 전에 그 보장과 함께 묶여온 제약은 없습니다. 핸드셰이크 의식도 없습니다. 관련 없는 데이터 간의 헤드 오브 라인 블로킹도 없습니다. 네트워크 위치에 묶인 신원도 없습니다.
성능 이점은 실재하며 측정 가능합니다. 특히 모바일 네트워크, 높은 지연 연결, 손실이 많은 무선 링크에서 두드러집니다. 하지만 더 깊은 교훈은 아키텍처에 있습니다: 사용자 공간에서 UDP를 기반으로 구축함으로써, QUIC은 커널 업데이트 속도가 아닌 애플리케이션 업데이트 속도로 발전할 수 있습니다.
TCP는 사라지지 않을 것입니다. 하지만 인터넷은 마침내 이동한다고 해서 불이익을 주지 않는 신뢰할 수 있는 전송을 가질 수 있게 됩니다.
QUIC에 관한 자주 묻는 질문
QUIC은 왜 새로운 프로토콜을 만드는 대신 UDP를 사용하나요?
미들박스—방화벽, NAT, 로드 밸런서—는 UDP를 이해하고 통과시킵니다. 완전히 새로운 전송 프로토콜은 이를 인식하지 못하는 장비에 의해 차단될 것입니다. UDP는 QUIC이 그 위에 나머지 모든 것을 구축하기에 충분한 기능(기본 패킷 전달)을 제공하면서도, 현재의 인터넷에 배포 가능한 상태를 유지합니다.
QUIC은 항상 TCP보다 빠른가요?
보통은 그렇지만, 항상 그런 것은 아닙니다. 오래 유지되는 연결의 신뢰할 수 있고 지연이 낮은 네트워크에서는 차이가 줄어듭니다. QUIC의 장점은 높은 지연 네트워크, 모바일 연결, 그리고 연결 설정이 빈번한 시나리오에서 가장 두드러집니다. 0-RTT 재개와 스트림 독립성은 조건이 어려울 때 가장 큰 힘을 발휘합니다.
HTTP 이외의 애플리케이션에도 QUIC을 사용할 수 있나요?
예. HTTP/3이 가장 눈에 띄는 QUIC 응용이지만, 프로토콜 자체는 범용입니다. DNS-over-QUIC이 존재합니다. 게임 프로토콜, 실시간 통신, 맞춤형 애플리케이션 모두 QUIC의 신뢰할 수 있는 스트림을 활용할 수 있습니다. IETF는 QUIC을 웹 트래픽만을 위한 것이 아닌 전송 계층으로 설계했습니다.
TCP를 업데이트해서 이런 기능들을 추가할 수 없는 이유는 무엇인가요?
TCP는 운영체제 커널에 구현되어 있습니다. 변경하려면 모든 장치의 모든 OS—스마트폰, 서버, 라우터, IoT 기기—를 업데이트해야 합니다. 수천 개의 조직이 관리하는 수십억 개의 시스템입니다. 작은 TCP 변경도 확산되는 데 수년이 걸립니다. QUIC은 애플리케이션이 자체 업데이트를 제어하는 사용자 공간에서 실행됨으로써 이 문제를 우회합니다.
출처
Была ли эта страница полезной?