기타 Lobsters · 1일 전

구글이 TCP 버리고 UDP로 웹 갈아엎으려고 만든 'QUIC' 프로토콜 정리

핵심 요약
  • 구글이 기존 웹 통신의 핵심인 TCP의 느린 초기 연결 및 지연 문제를 해결하기 위해 UDP 기반의 차세대 프로토콜 QUIC을 개발했습니다.
  • 단 1~2회의 패킷 왕복만으로 보안 연결을 끝마치며, 패킷 손실 시 전체 전송이 멈추는 TCP의 병목 현상(Head-of-line blocking)을 원천 차단합니다.
  • 운영체제 커널 수정이 필요한 TCP 대신 UDP 상에서 빠르게 기술을 검증했으며, 훗날 독자적인 IETF 표준이자 HTTP/3의 핵심 기술로 채택되었습니다.
요약 인터넷 웹 환경의 근간을 이루던 TCP 대신 UDP를 활용해 속도와 효율을 끌어올리려는 구글의 차세대 프로토콜 'QUIC(Quick UDP Internet Connections)'이 개발자들 사이에서 주목받고 있습니다. 일부에서는 이를 두고 농담조로 'TCP/2'라고 부르기도 합니다. 현재 대부분의 웹 통신은 데이터 전송의 신뢰성을 보장하는 TCP 기반으로 구축되어 있습니다. 하지만 TCP는 연결을 시작할 때 패킷을 주고받는 '3-way 핸드셰이크' 과정을 거쳐야 하며, 여기에 보안 암호화 통신인 TLS(HTTPS) 협상까지 더해지면 다수의 패킷 왕복이 발생해 초기 접속 지연(latency)이 커질 수밖에 없습니다. 반면 UDP는 패킷 도달 여부를 일일이 확인하지 않고 전송하는 '발송 후 방치(fire and forget)' 방식이라 지연 시간이 거의 없지만, 신뢰성을 확보하기 위해 상위 계층에서 별도 제어가 필요합니다. 구글의 QUIC은 바로 이 점에 착안해 UDP의 압도적인 속도 및 유연성에 TCP 수준의 신뢰성을 결합했습니다. QUIC을 사용하면 신규 서버 또는 기존 접속 서버에 따라 단 1~2개의 패킷 왕복만으로 초기 연결과 TLS 보안 파라미터 협상을 모두 완료할 수 있어, 웹페이지 최초 로딩 속도를 획기적으로 개선합니다. 또한 TCP 환경에서 심각한 병목을 유발하던 'Head-of-Line Blocking(앞선 패킷이 손실되면 뒤따르는 모든 패킷 처리가 지연되는 현상)'도 해결했습니다. HTTP/2나 SPDY처럼 단일 연결로 여러 리소스를 동시에 주고받을 때, TCP는 패킷 순서가 엄격해 특정 패킷이 유실되면 전체 연결이 멈춥니다. 그러나 QUIC은 UDP 기반의 비차단 전송 방식을 취해 패킷 하나가 손실되더라도 해당 단일 파일(CSS, JS 등)에만 영향이 갈 뿐 전체 연결 흐름을 방해하지 않습니다. TCP 스택을 직접 개선하는 것은 윈도우나 리눅스 커널, 스마트폰 OS, 각종 네트워크 중계 장비 등을 모두 수정해야 하므로 수년에서 수십 년이 걸릴 만큼 까다롭습니다. 반면 UDP 위에 프로토콜을 올리면 빠른 실험과 업데이트가 가능해 개발 속도를 극대화할 수 있었습니다. 이후 QUIC은 단순 실험을 넘어 IETF 표준화 및 HTTP/3의 기반 기술로 자리 잡게 되었습니다.
Sponsored · 광고