UDP편집자 확인

UDP는 연결 설정 과정 없이 데이터를 전송하는 비연결성 프로토콜이다. 이는 통신을 시작하기 전에 3방향 핸드셰이크와 같은 사전 연결 설정 절차를 거치는 TCP와 근본적으로 다른 특징이다. UDP를 사용하는 응용 프로그램은 수신자의 상태나 가용성을 확인하지 않고 즉시 데이터그램을 보낸다. 따라서 각 데이터 패킷은 독립적으로 취급되며, 이전이나 이후 패킷과의 논리적 연결 관계를 유지하지 않는다.

이러한 비연결성으로 인해 UDP는 매우 낮은 지연 시간과 오버헤드를 가진다. 연결을 설정하고 유지하는 데 필요한 제어 패킷과 상태 정보를 교환할 필요가 없기 때문이다. 이는 실시간성이 중요한 애플리케이션에서 큰 장점으로 작용한다. 그러나 반대로, 패킷이 성공적으로 도착했는지 확인하거나 순서를 재조정하는 메커니즘이 없으므로, 신뢰성은 상위 계층의 애플리케이션에서 책임져야 한다.

비연결성의 또 다른 결과는 통신 세션의 상태를 서버 측에서 유지할 필요가 없다는 점이다. 이는 무상태성을 의미하며, 특히 많은 수의 클라이언트를 동시에 처리해야 하는 서버에 유리한 구조를 제공한다. 서버는 들어오는 각 요청을 독립적인 트랜잭션으로 처리하면 되며, 복잡한 세션 관리 로직이 필요하지 않다.

UDP는 데이터 전송의 신뢰성을 보장하지 않는 비연결형 프로토콜이다. 이는 데이터그램이 전송된 후, 그 도착 여부나 순서, 중복을 확인하거나 재전송을 시도하지 않는다는 것을 의미한다. 송신 측은 단순히 데이터를 보내고, 수신 측의 확인 응답을 기다리지 않는다. 따라서 패킷이 손실되거나 중복되어 도착하거나, 순서가 바뀌어 도착할 가능성이 있다.

이러한 신뢰성 부재는 체크섬 필드를 통한 데이터 무결성 검사만을 제공한다. 헤더에 포함된 체크섬은 데이터가 전송 중 손상되었는지를 검출할 수 있지만, 손상된 패킷을 복구하거나 재전송하는 메커니즘은 존재하지 않는다. 수신 측은 체크섬 검증에 실패한 패킷을 단순히 폐기한다.

신뢰성 부재는 단점이자 동시에 핵심 설계 특징이다. TCP와 같은 신뢰성 있는 전송을 위한 핸드셰이크, 확인 응답, 재전송, 흐름 제어, 혼잡 제어 등의 복잡한 절차를 생략한다. 이로 인해 프로토콜 오버헤드가 매우 작고, 전송 지연이 낮으며, 네트워크 자원을 적게 소모한다.

결과적으로 UDP는 속도와 실시간성이 신뢰성보다 더 중요한 응용 프로그램에 적합하다. 일부 패킷 손실이 전체 서비스 품질에 치명적이지 않은 환경, 예를 들어 실시간 비디오 스트리밍이나 음성 통화에서는 약간의 데이터 손실이 지연이나 버퍼링보다 더 나은 사용자 경험을 제공할 수 있다.

UDP 헤더는 매우 단순한 구조를 가지며, 총 8바이트로 구성되어 있다. 이 헤더는 전송 계층에서 필요한 최소한의 정보만을 담고 있어 오버헤드가 적다. 헤더는 네 개의 필드로 이루어져 있으며, 각 필드는 16비트(2바이트) 크기를 가진다.

헤더의 구조는 다음과 같다.

체크섬 필드는 IP 헤더의 일부 정보, UDP 헤더, 데이터를 기반으로 계산된다. 이는 데이터 무결성을 일부 보장하지만, 계산 자체가 필수가 아니며 오류가 발견되더라도 패킷을 자동으로 재전송하지는 않는다. 이처럼 UDP 헤더는 연결 설정이나 신뢰성 보장을 위한 시퀀스 번호, 확인 응답 같은 필드를 전혀 포함하지 않는다. 그 결과, TCP 헤더에 비해 처리 속도가 빠르고 네트워크 부하가 적다.

UDP는 패킷을 독립적인 단위로 취급하여 전송한다. 각 패킷은 데이터그램이라고 불리며, 전송 전에 연결 설정 과정 없이 바로 목적지 IP 주소와 포트 번호를 지정하여 보낸다. 송신 측은 애플리케이션에서 내려받은 데이터를 UDP 헤더와 함께 패킷으로 구성한 후, 네트워크 계층으로 전달한다.

패킷의 전송 경로나 순서는 보장되지 않는다. 각 데이터그램은 네트워크를 통해 독립적으로 라우팅되며, 중간에 손실되거나 순서가 바뀌어 도착할 수 있다. 수신 측은 패킷이 도착하면 UDP 헤더의 목적지 포트 번호를 확인하여 해당 포트를 대기 중인 애플리케이션 프로세스에 데이터를 전달한다.

이 방식은 헤더 오버헤드가 작고 전송 지연이 매우 짧다는 장점이 있다. 그러나 패킷 손실, 중복, 순서 뒤바뀜과 같은 문제는 상위 계층(애플리케이션 계층)의 프로토콜이나 애플리케이션 자체가 처리해야 한다.

UDP 통신에서 데이터를 전송하고 수신하는 대상은 IP 주소로 식별되는 호스트(컴퓨터) 자체가 아니라, 해당 호스트 내에서 실행 중인 특정 프로세스 또는 애플리케이션이다. 이 특정 대상을 식별하기 위해 사용되는 주소 체계가 포트 번호이다.

포트 번호는 0부터 65535까지의 16비트 정수로 표현된다. 이 중 0부터 1023번까지는 잘 알려진 포트(Well-Known Ports)로, IANA에 의해 주요 서비스에 할당되어 있다[4]. 1024번부터 49151번까지는 등록된 포트(Registered Ports), 49152번부터 65535번까지는 동적/사설 포트(Dynamic/Private Ports)로 구분된다. 송신 측 애플리케이션은 일반적으로 운영체제로부터 임시로 동적 포트를 할당받아 사용한다.

IP 주소와 포트 번호의 조합을 종단점(Endpoint)이라고 하며, 통신의 출발지와 목적지 양쪽에 각각 존재한다. 운영체제의 네트워크 스택은 이 종단점을 추상화한 인터페이스인 소켓을 애플리케이션에 제공한다. 애플리케이션은 소켓을 생성하고 특정 포트에 바인딩(binding)함으로써 데이터를 송수신할 수 있다. UDP 소켓은 비연결형(unconnected) 특성을 가지므로, 하나의 소켓을 통해 여러 다른 목적지 주소로 패킷을 전송하는 것이 가능하다.

UDP는 헤더 구조가 단순하고 처리 오버헤드가 적어 전송 효율이 높다. 패킷을 전송하기 전에 연결을 설정하는 핸드셰이크 과정이 필요 없으므로, 통신 시작 지연 시간이 거의 없다. 이는 짧은 요청과 응답이 반복되거나 빠른 응답이 요구되는 환경에 적합하다.

또한, UDP는 혼잡 제어나 흐름 제어와 같은 복잡한 메커니즘을 구현하지 않는다. 이로 인해 네트워크 상태에 따라 전송 속도가 변하지 않고, 애플리케이션이 자체적으로 데이터 전송률을 결정할 수 있다. 대역폭을 일정하게 사용해야 하는 실시간 스트리밍 서비스나 VoIP에서 이 특징은 중요한 장점이 된다.

UDP는 단일화된 전송을 지원한다. 하나의 패킷이 여러 수신자에게 동시에 전달되는 브로드캐스트나 멀티캐스트 통신을 기본적으로 가능하게 한다. 이는 네트워크 내에 여러 클라이언트에게 동일한 데이터를 효율적으로 배포해야 하는 서비스에 유용하다.

마지막으로, UDP는 애플리케이션 계층에서 필요한 신뢰성 메커니즘을 자유롭게 설계할 수 있는 유연성을 제공한다. 전송 계층에서 강제하는 재전송이나 순서 보장이 없으므로, 개발자는 손실 허용이나 낮은 지연과 같은 특정 요구사항에 최적화된 프로토콜을 UDP 위에 구축할 수 있다.

UDP는 신뢰성을 보장하지 않는다. 데이터그램이 손실되거나 중복되거나 순서가 바뀌어 도착하더라도 프로토콜 수준에서 이를 복구하거나 알려주지 않는다. 이는 애플리케이션 개발자에게 오류 검출 및 복구 책임을 전가한다.

데이터의 정확한 전달보다는 속도가 중요한 상황에서는 장점이 될 수 있지만, 파일 전송이나 웹 페이지 로딩과 같이 데이터의 완전성이 필수적인 응용 분야에서는 큰 단점으로 작용한다. 패킷 손실이 발생하면 애플리케이션 계층에서 이를 알아차리고 재전송을 요청하는 별도의 메커니즘을 구현해야 한다.

또한 혼잡 제어 메커니즘을 제공하지 않는다. 송신자는 수신자의 처리 능력이나 네트워크 상태를 고려하지 않고 가능한 최대 속도로 데이터를 전송할 수 있다. 이는 네트워크에 과도한 부하를 일으켜 혼잡을 유발하고, 결과적으로 다른 정상적인 트래픽까지 성능 저하를 초래할 수 있다.

UDP는 기본적으로 헤더에 최소한의 정보만 포함하기 때문에, 데이터 그램의 출처를 검증하는 데 어려움이 있다. 이는 IP 스푸핑을 이용한 공격에 취약하게 만든다.

UDP는 패킷 손실이나 순서 재배열에 대한 복구 메커니즘 없이 데이터를 전송하는 특징을 가지고 있다. 이는 지연 시간을 최소화해야 하는 실시간 스트리밍 서비스에 매우 적합한 특성이다. 스트리밍에서는 모든 데이터의 완벽한 수신보다도, 끊김 없는 지속적인 재생이 더 중요하기 때문이다.

주요 스트리밍 프로토콜인 RTP는 전송 계층에서 UDP를 기반으로 동작한다. RTP는 타임스탬프와 시퀀스 번호를 제공하여 수신 측에서 재생 타이밍을 조정하고 패킷 손실을 감지할 수 있게 하지만, 손실된 패킷의 재전송은 요구하지 않는다. 이는 버퍼링 지연을 줄이고 실시간성을 보장하는 데 핵심적이다.

따라서 UDP는 네트워크 상태가 양호할 때 최상의 실시간 경험을 제공하지만, 혼잡한 네트워크에서는 화질 저하나 끊김이 발생할 수 있다. 이를 보완하기 위해 FEC나 적응형 비트레이트 전송과 같은 기술이 함께 사용된다.

DNS는 도메인 이름을 IP 주소로 변환하는 시스템이다. 이 과정에서 UDP는 기본적인 질의-응답 통신에 주로 사용된다. DNS 쿼리는 일반적으로 매우 작은 데이터 패킷(512바이트 이하)으로 구성되며, 빠른 응답 시간이 요구된다. UDP의 비연결성과 낮은 오버헤드는 이러한 단일 요청과 응답 패턴에 매우 적합하다. 대부분의 표준 DNS 조회는 단일 UDP 요청과 단일 응답으로 완료된다.

DNS가 UDP를 선호하는 주요 이유는 성능과 효율성에 있다. TCP를 사용할 경우 연결 설정을 위한 3방향 핸드셰이크가 필요하며, 이는 단순한 주소 변환 요청에 비해 상대적으로 큰 지연을 유발한다. 반면 UDP는 이러한 연결 설정 과정 없이 즉시 데이터를 전송할 수 있다. 또한 DNS 응답은 대부분 매우 빨리 도착하므로, 패킷 손실이나 재전송과 같은 신뢰성 메커니즘의 필요성이 상대적으로 낮은 편이다.

하지만 UDP를 사용하는 DNS에는 한계도 존재한다. 512바이트를 초과하는 대용량 응답(예: DNSSEC 레코드를 포함하는 경우)을 처리할 수 없다. 이 경우 프로토콜은 자동으로 TCP로 전환하여 통신한다[6]. 또한 UDP는 스푸핑 공격에 취약할 수 있어, DNSSEC와 같은 확장 기능이 보안을 강화하기 위해 도입되었다.

온라인 게임은 UDP의 주요 활용 분야 중 하나이다. 특히 빠른 반응 속도가 게임 플레이의 핵심인 실시간 전략 게임, 1인칭 슈팅 게임, 대규모 다중 사용자 온라인 게임 등에서 UDP가 선호되는 프로토콜이다.

이러한 게임들은 플레이어의 입력(이동, 공격 등)과 게임 세계의 상태 변화를 극도로 빠른 속도로 교환해야 한다. TCP의 경우 패킷 손실 시 재전송과 순서 보장을 위해 지연이 발생할 수 있어, 0.1초의 지연도 승패를 갈라버리는 게임 환경에서는 치명적일 수 있다. 반면 UDP는 이러한 신뢰성 메커니즘을 생략함으로써 최소한의 지연(레이턴시)을 보장한다. 게임 클라이언트와 서버는 주기적으로 상태 업데이트 패킷을 빠르게 주고받으며, 일부 패킷이 유실되더라도 다음 업데이트 패킷이 곧바로 전송되어 전체 게임 흐름에는 큰 영향을 미치지 않도록 설계된다.

많은 현대 온라인 게임 엔진과 네트워크 라이브러리는 UDP를 기반으로 하여 신뢰성이 필요한 메시지와 신속성이 필요한 메시지를 구분하여 처리하는 하이브리드 방식을 사용한다. 예를 들어, 채팅 메시지나 아이템 구매 정보는 TCP로, 캐릭터의 위치와 동작은 UDP로 전송할 수 있다. 또한 QUIC과 같은 UDP 기반의 새로운 프로토콜은 게임 데이터 전송의 효율성을 더욱 높이기 위한 연구가 진행되고 있다.

VoIP는 UDP를 주된 전송 프로토콜로 활용하는 대표적인 응용 분야이다. VoIP 서비스는 음성 데이터를 작은 패킷으로 나누어 네트워크를 통해 실시간으로 전송하는데, 이 과정에서 낮은 지연 시간과 일정한 전송 속도가 가장 중요하다. TCP가 패킷 손실 시 재전송을 통해 신뢰성을 보장하는 메커니즘은, 재전송으로 인한 추가 지연과 패킷 도착 순서의 뒤섞임을 초래하여 음성 통화의 자연스러운 흐름을 심각하게 방해할 수 있다. 반면, UDP는 이러한 재전송이나 순서 보정을 수행하지 않기 때문에, 일부 패킷이 손실되더라도 전체 통화의 지연을 최소화하면서 실시간 스트림을 유지할 수 있다.

VoIP 시스템은 RTP와 같은 상위 계층 프로토콜을 UDP 위에서 동작시켜 음성 데이터의 실시간 전송을 관리한다. RTP는 패킷에 시퀀스 번호와 타임스탬프 정보를 추가하여, 수신 측에서 패킷의 순서를 재구성하고 적절한 재생 타이밍을 조절할 수 있도록 돕는다. 일부 패킷이 유실되면, 수신 측은 인터폴레이션이나 패킷 손실 은닉 기술을 사용하여 잡음이나 끊김을 최소화하면서 음질을 보완한다. 이는 통화 품질에 치명적인 전체적인 지연이나 버퍼링보다는, 미미한 음질 하락을 선택하는 전형적인 트레이드오프에 해당한다.

따라서 VoIP와 같은 실시간 미디어 애플리케이션에서는 완벽한 전송보다는 시의적절한 전송이 더 중요하며, UDP의 단순하고 빠른 특성이 이러한 요구사항에 부합한다. 그러나 UDP 기반 VoIP는 방화벽이나 NAT 트래버설 문제에 직면할 수 있으며, 이를 해결하기 위해 SIP와 같은 시그널링 프로토콜이 세션 설정 및 관리에 함께 사용된다.

DDoS 공격은 UDP의 특성을 악용하는 대표적인 공격 유형 중 하나이다. UDP는 연결 설정 과정 없이 패킷을 전송하는 비연결성 프로토콜이기 때문에, 공격자는 출발지 IP 주소를 위조한 UDP 패킷을 쉽게 생성하여 대상 서버에 대량으로 전송할 수 있다. 이때 서버는 해당 패킷에 대한 응답을 출발지로 보내려 시도하지만, 출발지 주소가 위조되었기 때문에 응답은 존재하지 않는 호스트로 전송되거나 다른 무고한 서버를 향하게 된다. 이 과정에서 서버의 자원이 소모되고, 정상적인 요청을 처리할 수 있는 능력이 저하된다.

UDP를 이용한 대표적인 DDoS 공격으로는 UDP 플러드와 증폭 공격이 있다. UDP 플러드는 단순히 대량의 UDP 패킷을 대상 서버의 특정 포트로 직접 전송하여 대역폭과 시스템 자원을 고갈시키는 방식이다. 증폭 공격은 공격자가 출발지 IP를 공격 대상의 IP로 위조한 후, 작은 요청 패킷을 DNS 서버나 NTP 서버와 같이 응답 패킷이 훨씬 큰 서비스에 보내는 방식이다. 이 서비스들은 위조된 출발지 주소(즉, 공격 대상)로 큰 응답 패킷을 보내게 되어, 공격자는 적은 양의 트래픽으로 대상에게 막대한 트래픽을 유발할 수 있다[9].

이러한 공격을 완화하기 위한 방어 기법이 다수 개발되었다. 네트워크 경계에서는 위조된 출발지 IP를 가진 패킷을 차단하는 Ingress Filtering이 적용될 수 있다. 또한, UDP 기반 서비스를 운영하는 서버 측에서는 불필요한 UDP 포트를 닫고, 예상치 못한 대량의 UDP 트래픽을 탐지 및 차단하는 시스템을 구축하는 것이 중요하다. 최근에는 클라우드 기반의 DDoS 방어 서비스를 통해 정상적인 트래픽과 공격 트래픽을 분리하고, 대규모 대역폭으로 공격 트래픽을 흡수하는 방식이 널리 사용된다.

스푸핑은 UDP 기반 통신에서 특히 취약한 보안 위협 중 하나이다. 공격자가 패킷의 출발지 IP 주소나 포트 번호를 위조하여 정상적인 출처인 것처럼 속이는 행위를 의미한다. UDP는 연결 설정 과정(3방향 핸드셰이크)이 없고, 전송된 패킷의 출처를 검증하는 기본 메커니즘이 부재하기 때문에 이러한 위조가 상대적으로 쉽게 이루어진다.

주요 스푸핑 공격 유형은 다음과 같다.

스푸핑 공격의 결과는 다양하다. 서비스 거부(DoS) 공격의 일환으로 사용되거나, DNS 캐시 포이즈닝을 통해 사용자의 트래픽을 악성 서버로 리다이렉트할 수 있다. 또한, 인증이 취약한 네트워크 서비스에 대한 무단 접근을 획득하는 데 이용되기도 한다.

이러한 위협을 완화하기 위한 대책이 존재한다. 네트워크 경계에서 인그레스 필터링을 구현하여 외부에서 들어오는 패킷의 출발지 IP가 내부 네트워크 대역인지를 차단하는 것이 기본이다. 또한, DNSSEC을 도입하여 DNS 응답의 무결성과 인증을 보장하거나, 애플리케이션 수준에서 강력한 암호화 및 인증 메커니즘(예: DTLS)을 사용하는 방법이 있다.

DTLS(Datagram Transport Layer Security)는 UDP 상에서 TLS 프로토콜의 보안 서비스를 제공하기 위해 설계된 통신 프로토콜이다. TLS는 신뢰성 있는 전송을 전제로 하는 TCP에 최적화되어 있어, 패킷 손실, 재전송, 순서 변경이 빈번한 UDP 환경에서는 직접 사용할 수 없다. DTLS는 이러한 UDP의 특성을 고려하여 TLS의 핵심 보안 기능(예: 암호화, 인증, 데이터 무결성)을 유지하면서, 패킷 손실이나 지연에 강인하도록 프로토콜을 수정했다.

DTLS의 핵심 설계 목표는 TLS와의 최대한의 호환성을 유지하면서, 비연결성 전송에 적합하게 만드는 것이다. 이를 위해 핸드셰이크 과정에서 발생할 수 있는 패킷 손실이나 재배열 문제를 해결했다. 예를 들어, DTLS는 재전송 타이머를 도입하여 응답이 없는 핸드셰이크 메시지를 재전송할 수 있게 했다. 또한, 암호화된 레코드 계층에는 명시적인 시퀀스 번호를 포함시켜, UDP로 인해 도착 순서가 뒤바뀐 패킷을 올바르게 재조립하고 재생 공격을 방지한다.

DTLS는 실시간성이 중요한 애플리케이션에 널리 적용된다. 대표적인 예로 VoIP(예: WebRTC), 실시간 비디오 스트리밍, IoT 기기 간 안전한 메시징, 그리고 일부 VPN(예: OpenVPN의 UDP 모드) 프로토콜이 있다. 특히 QUIC 프로토콜의 초기 버전은 DTLS를 보안 계층으로 채용하기도 했다[10]. DTLS는 신뢰성보다는 낮은 지연 시간이 더 중요한 통신 환경에서 필수적인 보안 계층을 제공한다.

QUIC(Quick UDP Internet Connections)는 구글이 개발한 전송 계층 네트워크 프로토콜로, TCP와 TLS의 기능을 결합하여 UDP 위에서 동작하도록 설계되었다. 기본 목표는 TCP/TLS/HTTP 스택의 연결 설정 지연을 줄이고, 다중화 성능을 개선하며, 연결 마이그레이션을 지원하는 것이다. 초기에는 구글의 실험적 프로토콜로 시작했으나, 이후 IETF에 의해 표준화 작업이 진행되어 HTTP/3의 기반 전송 프로토콜로 채택되었다.

QUIC의 핵심 설계 철학은 UDP의 경량성과 낮은 지연 특성을 유지하면서, TCP가 제공하는 신뢰성과 혼잡 제어, 그리고 TLS가 제공하는 보안을 단일 통합 프로토콜 내에서 제공하는 것이다. 이를 위해 다음과 같은 주요 특징을 가진다.

* 통합된 암호화와 핸드셰이크: TCP는 먼저 3방향 핸드셰이크로 연결을 설정한 후 별도로 TLS 핸드셰이크를 진행한다. 반면 QUIC는 연결 설정과 암호화 키 협상을 하나의 과정으로 통합하여, 일반적으로 1-RTT(왕복 1회) 내에 보안 연결을 수립할 수 있다. 0-RTT 재연결도 지원한다.

* 스트림의 독립적 다중화: 하나의 QUIC 연결 내에서 여러 개의 독립적인 논리적 데이터 스트림을 병렬로 전송할 수 있다. TCP의 경우 순차적 전송으로 인한 HOL 블로킹 문제가 발생할 수 있지만, QUIC의 스트림은 서로 차단되지 않는다. 하나의 패킷 손실이 다른 스트림의 데이터 전달을 지연시키지 않는다.

* 향상된 연결 마이그레이션: 사용자의 네트워크가 Wi-Fi에서 셀룰러 네트워크로 변경되는 등 IP 주소가 바뀌는 상황에서도 기존 연결을 유지할 수 있다. 이는 연결 식별자로 IP 주소와 포트가 아닌 연결 ID를 사용하기 때문에 가능하다.

QUIC는 웹 브라우징 경험 개선을 위해 태동했으나, 그 이점으로 인해 점차 더 넓은 범위의 애플리케이션에 적용되고 있다. 표준화된 QUIC 프로토콜은 HTTP/3의 필수 구성 요소이며, 실시간 미디어 스트리밍, 모바일 애플리케이션, 그리고 높은 지연 시간이나 패킷 손실이 빈번한 불안정한 네트워크 환경에서 특히 유용한 것으로 평가받는다.