UDP가 어울리는 곳

UDP는 단순한 도구입니다. 단순한 도구가 복잡한 도구보다 더 잘 맞는 자리가 있습니다. UDP가 빛나는 세 가지 상황을 살펴봅니다.

브로드캐스트와 멀티캐스트

TCP는 연결 지향입니다. 연결을 맺으려면 상대방이 한 명이어야 합니다. 한 대의 서버가 천 명에게 동시에 같은 데이터를 보내려면 천 개의 TCP 연결이 필요합니다. 각각에게 따로 보내야 합니다.

UDP는 연결이 없으므로 브로드캐스트(동일 네트워크의 모든 장치에게)와 멀티캐스트(특정 그룹에게)가 가능합니다. 패킷 하나를 보내면 그 그룹의 모든 수신자에게 동시에 전달됩니다. IPTV, 증권 시세 실시간 배포, 네트워크 자동 설정(DHCP)이 이 방식을 씁니다.

간단한 요청-응답

앞서 DNS 예를 들었지만, 같은 패턴은 많습니다. NTP(Network Time Protocol)도 UDP를 씁니다. 시간을 묻고 시간을 받는 단순한 교환에서 TCP의 연결 수립 과정은 낭비입니다. SNMP(Simple Network Management Protocol)로 네트워크 장비의 상태를 조회하는 것도 마찬가지입니다.

요청이 작고 응답도 작다면, 요청 자체에 "재전송 가능한 요청 ID"를 넣어 애플리케이션 수준에서 처리하는 것이 TCP를 쓰는 것보다 효율적입니다.

QUIC — UDP 위에 세운 현대적 전송

흥미로운 사례가 있습니다. 구글이 만들고 지금은 IETF 표준이 된 QUIC 프로토콜입니다. HTTP/3의 기반 전송 프로토콜입니다.

QUIC는 UDP 위에서 동작합니다. 그러면서도 TCP가 제공하는 신뢰성, 순서 보장, 혼잡 제어를 모두 구현합니다. 거기에 TLS 암호화를 연결 과정에 통합하고, 헤드오브라인 블로킹(하나의 스트림 지연이 전체를 멈추는 문제)을 해결했습니다.

"왜 TCP를 개선하지 않고 UDP 위에 새로 만들었나요"라는 질문이 자연스럽게 생깁니다. TCP는 운영체제 커널 안에 구현되어 있습니다. 수십 억 대의 장치에서 돌아가는 커널 코드를 바꾸는 것은 수년이 걸립니다. UDP는 단순한 통로만 제공하고, 그 위에서 라이브러리로 동작하는 QUIC은 브라우저나 앱 업데이트만으로 배포할 수 있습니다. 이것이 UDP를 선택한 실용적인 이유입니다.

UDP를 쓸 때 고려할 것

UDP를 직접 사용한다면 몇 가지를 애플리케이션이 직접 처리해야 합니다. 패킷 순서가 뒤바뀔 수 있으므로 순서 번호를 직접 넣어야 합니다. 중요한 패킷이 누락됐을 때 재시도 로직이 필요하다면 직접 구현해야 합니다. 혼잡을 알아채고 속도를 조절하는 로직도 마찬가지입니다.

UDP는 운영체제가 해주던 것을 애플리케이션이 가져오는 대신, 더 세밀하게 상황에 맞게 조율할 수 있는 권한을 주는 것입니다.

다음 장에서는 네트워크가 혼잡해질 때 TCP가 어떻게 반응하는지, 혼잡 제어의 원리를 살펴봅니다.