UDP의 작동 방식: 단순함과 속도

영상 통화를 하거나 온라인 게임을 플레이할 때, 우리가 원하는 것은 완벽한 전달이 아니라 빠른 전달입니다. 패킷이 손실될 때마다 영상 통화가 멈추고 프로토콜이 재전송을 요청해야 한다면, UDP가 왜 존재하는지 바로 이해하게 될 것입니다.

사용자 데이터그램 프로토콜(User Datagram Protocol)은 TCP와는 근본적으로 다른 방식을 취합니다. 데이터를 보내고 앞으로 나아가는 것입니다. 보장도 없고, 재시도도 없고, 군더더기도 없습니다. 이 겉보기에 무모해 보이는 방식이 바로 UDP를 인터넷에서 가장 중요한 프로토콜 중 하나로 만드는 이유입니다.

비연결 지향의 철학

UDP에는 기억이 없습니다. 3-방향 핸드셰이크도, 연결 수립도, 연결 종료도 없습니다. 애플리케이션이 데이터를 보내고 싶을 때, 데이터그램을 만들어 전송합니다. 그게 전부입니다.

각 데이터그램은 완전히 독립적입니다. 다른 어떤 데이터그램과도 관계없는 독립적인 메시지입니다. 송신 애플리케이션은 목적지 IP 주소와 포트 번호로 각 데이터그램의 주소를 지정하고, UDP의 역할은 패킷을 아래의 IP 계층에 넘기는 순간 끝납니다. 그 다음에 무슨 일이 일어나는지—데이터그램이 도착하는지, 전송 중에 손실되는지, 순서가 바뀌어 도착하는지—는 UDP가 신경 쓸 일이 아닙니다.

무책임하게 들릴 수 있지만, 이것이 무엇을 없애는지 생각해보면 납득이 됩니다. 추적할 시퀀스 번호도 없고, 대역폭을 소비하는 확인 응답 패킷도 없고, 응답을 기다리는 타이머도 없습니다. TCP가 전달을 보장하기 위해 사용하는 복잡한 메커니즘이 통째로 사라집니다. 그 결과, 아무것도 약속하지 않기에 오히려 빠른 프로토콜이 됩니다.

최소한의 헤더

UDP의 철학은 헤더에서 잘 드러납니다. 네 개의 필드로 구성된 단 8바이트입니다. TCP의 헤더는 최소 20바이트(옵션 포함 시 최대 60바이트)입니다. 헤더에서 절약되는 모든 바이트는 실제 데이터에 쓸 수 있는 바이트입니다.

출발지 포트 (16비트): 송신 애플리케이션을 식별합니다. 단방향 통신에서는 선택 사항이지만, 응답을 원한다면 필요합니다.

목적지 포트 (16비트): 수신 측 장치에서 이 데이터그램을 받아야 하는 애플리케이션을 지정합니다. DNS 리졸버, 동영상 스트리밍 앱, 또는 게임 클라이언트 등이 해당됩니다.

길이 (16비트): 헤더를 포함한 데이터그램의 전체 크기입니다. 이론상 최대 크기는 65,535바이트이지만, 네트워크 제약으로 인해 실제 한도는 더 작습니다.

체크섬 (16비트): 전송 중에 비트가 손상되었는지 감지합니다. 솔직히 말하자면, UDP는 오류를 수정하지 않습니다. 손상된 데이터그램을 그냥 버립니다. 체크섬은 IPv4에서는 선택 사항이고, IPv6에서는 필수입니다.

시퀀스 번호도 없습니다. 확인 응답 번호도 없습니다. 윈도우 크기도 없습니다. 연결 관리 플래그도 없습니다. 이 최소한의 헤더 덕분에 UDP는 이토록 낮은 지연 시간으로 데이터를 전달할 수 있습니다.

UDP가 의도적으로 생략한 것들

UDP는 신뢰성 메커니즘을 제공하지 않습니다. 데이터그램이 손실되면—혼잡한 라우터에서 버려지거나, 불량 케이블로 인해 손상되거나, 잘못 라우팅되거나—UDP는 알아채지도 않고 신경 쓰지도 않습니다. 재전송도 없고, 중복 감지도 없고, 전달 보장도 없습니다.

UDP는 순서를 보장하지 않습니다. 세 개의 데이터그램을 순서대로 보내도 어떤 순서로든 도착할 수 있으며, 일부는 아예 도착하지 않을 수도 있습니다. 각 데이터그램은 네트워크를 통해 독립적인 경로를 택합니다.

UDP에는 흐름 제어가 없습니다. 수신자가 처리에 벅차더라도 속도를 늦추지 않습니다. 수신자가 처리할 수 있는 속도보다 빠르게 전송하면, 초과 패킷은 그냥 버려집니다.

UDP에는 혼잡 제어도 없습니다. 네트워크 혼잡을 감지하거나 전송 속도를 조정하지 않습니다. 잘못 설계된 UDP 애플리케이션은 네트워크 상태가 나빠진 상황에서도 대역폭을 가득 채울 수 있습니다.

이러한 생략은 한계가 아니라 바로 핵심입니다.

생략이 곧 기능인 이유

연결 수립, 확인 응답, 재전송이 없기 때문에 UDP는 최소한의 지연 시간으로 데이터를 전달합니다. 영상 통화에서는 200밀리초 전의 오디오 프레임이 결국 도착하는 것보다 최신 오디오 프레임을 빠르게 받는 것이 훨씬 중요합니다. 재전송된 패킷이 도착할 때쯤이면 이미 쓸모가 없어집니다.

8바이트 헤더 덕분에 더 많은 대역폭을 실제 데이터에 쓸 수 있습니다. 작은 메시지를 많이 보내는 애플리케이션에서는 이 차이가 상당히 쌓입니다.

UDP는 브로드캐스트와 멀티캐스트에 탁월합니다. 유지해야 할 연결 상태가 없기 때문에, 단일 데이터그램이 여러 수신자에게 동시에 전달될 수 있습니다. 여러 시청자에게 스트리밍하거나 서비스를 탐색할 때 필수적인 기능입니다.

가장 중요하게도, UDP는 애플리케이션에 제어권을 줍니다. UDP가 제공하는 것이 워낙 적기 때문에, 애플리케이션은 자신에게 필요한 신뢰성, 순서 보장, 혼잡 제어를 정확히 구현할 수 있습니다. 그 이상도, 그 이하도 아닙니다.

데이터그램 모델

UDP 용어에서, 각 패킷은 데이터그램입니다. 독립적이고 자기 완결적인 메시지입니다. 이것은 TCP의 스트림 지향 방식과 대조됩니다. UDP를 통해 데이터를 보낼 때는 개별 데이터그램을 보내며, 그 경계가 그대로 보존됩니다. 100바이트 데이터그램 세 개를 보내면, 수신자는 300바이트짜리 스트림 하나가 아니라 100바이트 메시지 세 개를 받습니다.

이 메시지 경계의 보존이 중요합니다. DNS 쿼리는 본질적으로 독립된 메시지입니다. 게임 상태 업데이트는 특정 순간의 스냅샷입니다. 음성 패킷에는 특정 시간 구간의 오디오가 담겨 있습니다. 이러한 애플리케이션들은 스트림이 아닌 메시지 단위로 동작합니다. UDP의 데이터그램 모델은 이들이 실제로 작동하는 방식과 잘 맞아떨어집니다.

UDP가 진가를 발휘하는 곳

DNS는 UDP를 사용합니다. 이름 조회가 빠르게 이루어져야 하고, 손실된 쿼리는 단순히 다시 시도하면 되기 때문입니다. 대부분의 DNS 메시지는 단일 데이터그램에 담깁니다.

음성 및 영상 통화는 UDP에 의존합니다. 오디오를 빠르게 전달하는 것이 완벽하게 전달하는 것보다 중요하기 때문입니다. 몇 밀리초의 오디오가 빠져도 사람들은 거의 알아채지 못합니다. 하지만 재전송을 기다리느라 음성이 끊기는 것은 누구나 바로 알아챕니다.

온라인 게임은 UDP를 통해 플레이어 위치를 전송합니다. 0.5초 전의 위치가 아니라 지금 이 순간의 위치가 중요하기 때문입니다. 게임은 보통 중요한 이벤트(아이템 획득, 점수 변경)에는 자체적인 신뢰성 메커니즘을 구현하면서, 끊임없이 흘러오는 위치 업데이트에는 신뢰성 없는 UDP를 사용합니다.

RTP 같은 스트리밍 프로토콜은 UDP 위에 구축되어 실시간 영상과 오디오를 전달합니다. SNMP 같은 네트워크 관리 프로토콜은 모니터링 데이터 수집에 UDP를 사용합니다. 심지어 HTTP/3를 구동하는 현대 프로토콜인 QUIC도 UDP 위에 구축되어, UDP의 낮은 지연 시간을 활용하면서 자체적인 신뢰성을 구현합니다.

UDP에 대해 자주 묻는 질문

전달을 보장하지 않는 프로토콜을 왜 사용하나요?

많은 애플리케이션에서 보장된 전달이 오히려 아무것도 전달하지 않는 것보다 더 나쁠 수 있기 때문입니다. 영상 통화 중에 패킷이 손실됐을 때, 재전송을 기다리느라 통화 전체가 멈추는 것보다는 20밀리초의 오디오를 그냥 건너뛰는 것이 낫습니다. 오래된 패킷이 뒤늦게 도착할 때쯤이면 이미 쓸모가 없습니다. 대화는 이미 다음 순간으로 넘어갔으니까요.

애플리케이션은 손실된 UDP 패킷을 어떻게 처리하나요?

애플리케이션의 목적에 따라 다릅니다. DNS는 응답이 오지 않으면 쿼리를 다시 시도합니다. 영상 통화는 오류 은폐(error concealment) 기법을 써서 누락된 프레임을 감춥니다. 게임은 누락된 위치 데이터를 보간합니다. 어떤 애플리케이션은 중요한 메시지에 대해서는 UDP 위에 자체적인 신뢰성 계층을 구현하고, 나머지는 손실을 감수합니다.

UDP가 TCP보다 빠른가요?

UDP는 연결 수립을 건너뛰고 확인 응답을 기다리지 않기 때문에 지연 시간이 낮습니다. 그런데 "빠르다"는 것은 상황에 따라 다릅니다. 모든 바이트가 반드시 도착해야 하는 대용량 파일 전송이라면, TCP의 신뢰성 기능이 애플리케이션 수준의 재시도를 하는 UDP보다 오히려 더 효율적일 수 있습니다. UDP는 최대한 낮은 지연 시간이 필요하고 일부 손실을 감수할 수 있는 상황에서 빛을 발합니다.

UDP 패킷이 순서 없이 도착할 수 있나요?

네. 각 데이터그램은 네트워크를 통해 독립적인 경로를 택합니다. 서로 다른 라우터, 서로 다른 큐, 서로 다른 지연이 발생할 수 있습니다. 순서가 필요한 애플리케이션은 직접 시퀀스 번호를 추적해야 합니다.

오류를 수정하지 않는데 왜 체크섬이 있나요?

체크섬은 손상을 감지합니다. 전송 중에 뒤집힌 비트를 찾아냅니다. 손상에 대한 UDP의 대응은 간단합니다. 데이터그램을 통째로 버립니다. 손상된 데이터보다는 데이터가 없는 편이 낫습니다. 재시도를 요청할지, 아니면 그냥 넘어갈지는 애플리케이션이 결정합니다.