1. UDP란?
✨ 기본 정의
UDP(User Datagram Protocol)는 '보내는 사람(User)'이 '데이터 덩어리(Datagram)'를 단순히 '던지는(Protocol)' 방식이다.
⭐ 데이터그램(Datagram): 독립적인 관계를 지니는 패킷으로, 각 패킷이 서로 독립적으로 전송된다. 마치 편지를 보낼 때 각 편지가 독립적으로 배달되는 것과 비슷하다.
- 비연결형(Connectionless): 상대방이 받을 준비가 되었는지 확인하지 않고 보낸다.
- 비신뢰성(Unreliable): 데이터가 중간에 사라지거나 순서가 뒤바뀌어도 신경 쓰지 않는다.
- 초경량(Lightweight): 확인 절차가 없으므로 속도가 매우 빠르고 헤더가 가볍다.
쉽게 비유하자면,
- TCP는 전화 통화이다.
"여보세요?"(연결 확인) ➡️ "네, 들립니다"(응답) ➡️ 대화(데이터 전송) 과정을 거친다.- UDP는 종이비행기 날리기이다.
일단 날리면(전송), 상대가 잘 받았는지 확인할 수 없지만 날리는 속도는 훨씬 빠르다.
2. TCP & UDP 탄생 배경
✨ 문제 1: 프로세스 구분 불가
IP 주소는 네트워크 상에서 특정 컴퓨터(Host)를 찾아가는 데 사용된다. 하지만 컴퓨터 안에는 카카오톡, 유튜브, 게임 등 여러 개의 프로그램(Process)이 동시에 인터넷을 사용하고 있다.
- 문제점: 택배(데이터)가 아파트(컴퓨터) 앞까지는 잘 도착했는데, 경비실에서 "이게 어느 집(프로그램)으로 가는 건가요?"라고 물었을 때 대답할 정보가 없는 것과 같다.
- 해결책 (포트 번호): 각 프로그램마다 고유한 '방 번호(Port Number)'를 부여했다.덕분에 IP로 컴퓨터를 찾고, 포트 번호로 그 안의 정확한 프로그램을 찾아갈 수 있게 되었다.
✨ 문제 2: 오류 처리 미흡
IP는 데이터를 보내는 데만 집중하는 '비신뢰성' 프로토콜이다. 전송 중에 데이터가 사라지거나 망가져도 IP 스스로는 아무것도 할 수 없다.
- ICMP의 한계: ICMP는 도로 위의 '전광판'이나 '교통 방송' 같은 역할이다. "앞에 사고 났어요!"라고 알려주기는 하지만, 사고 난 차를 견인하거나 짐을 다시 보내주지는 않는다.
⭐ ICMP(Internet Control Message Protocol): 네트워크 장비에서 오류 메시지를 전송받는 프로토콜 (예: ping 명령어)
- 해결책 (TCP와 UDP)
- TCP (꼼꼼한 관리자): 데이터가 잘 도착했는지 일일이 확인하고, 순서가 바뀌면 바로잡고, 잃어버리면 다시 보내달라고 요청한다.
- UDP (빠른 배달원): 복잡한 확인 절차 없이 일단 빠르게 던져준다. 오류 처리는 필요하다면 사용하는 프로그램(애플리케이션)이 직접 하도록 맡긴다.
✨ 한눈에 보는 프로토콜 계층 구조
3. TCP vs. UDP: 오류 처리 방식
✨ TCP의 오류 처리 방식
TCP는 데이터가 목적지에 안전하게 도착할 때까지 모든 과정을 감시한다.
- 순서 번호(Sequence Number): 데이터 조각마다 번호를 붙인다. 덕분에 조각들이 뒤섞여 도착해도 원래 순서대로 조립할 수 있다.
- 확인 응답(ACK): 데이터를 받은 쪽에서 "잘 받았어!"라고 신호를 보낸다. 만약 이 신호가 안 오면 보낸 쪽은 "문제가 생겼구나"라고 판단하고 자동으로 다시 보낸다(재전송).
- 흐름 제어 & 혼잡 제어: 받는 쪽이 감당할 수 있을 만큼만 보내고, 네트워크가 막히면 속도를 줄여서 오류 발생 가능성을 미리 차단한다.
⭐ TCP는 신뢰성이 중요한 파일 전송, 이메일 등에 적합하다.
✨ UDP의 오류 처리 방식
UDP는 복잡한 확인 절차를 생략하고 오직 '데이터 무결성'만 최소한으로 확인한다.
- 체크섬(Checksum): 헤더에 포함된 체크섬을 통해 데이터가 전송 중에 깨졌는지만 확인한다.
- 오류 발견 시 대응: 만약 체크섬 확인 결과 데이터가 망가졌다면? UDP는 그냥 그 데이터를 버린다. 다시 보내달라고 요청하거나 고치려 하지 않는다.
- 애플리케이션의 역할: "데이터가 하나쯤 없어져도 괜찮아(예: 실시간 영상)"라면 그대로 두고, "그래도 이건 중요해"라고 판단되면 개발자가 직접 프로그램 코드에 재전송 로직을 짜넣어야 한다.
⭐ UDP는 0.1초가 중요한 온라인 게임, 실시간 스트리밍, DNS 조회 등에 사용된다. 조금 손실되더라도 끊김 없이 빠르게 전달하는 게 더 중요하기 때문이다.
4. UDP의 핵심 성격
(1) 비연결형 (Connectionless)
- TCP처럼 연결(3-way-handshake)을 만들고 유지하지 않는다.
- 보낼 때 "그냥 보냄", 받을 때 "그냥 받음"에 가깝다.
(2) 메시지 지향 (message-oriented)
- TCP는 바이트 스트림(byte-stream), UDP는 메시지(데이터그램) 단위이다.
- "한 번 send한 덩어리 = 한 개 UDP 데이터그램"이라는 경계가 유지되는 편이라서 요청/응답형에 잘 맞는다.
(3) 비신뢰성 (Unreliable)
- UDP는 전달 보장, 순서 보장, 중복 방지를 보장하지 않는다.
- 단, 체크섬으로 손상(corruption) 검출은 할 수 있다.
5. UDP 헤더 구조
UDP 헤더는 총 8바이트(64비트)로 고정되어 있다.
✨ 헤더 필드
각 필드는 16비트(2바이트)씩 할당되어 있다.
- Source Port (송신 포트): 데이터를 보내는 프로그램의 번호이다. 16비트이므로 포트 번호의 범위가 0~65,535가 되는 것이다.
- Destination Port (수신 포트): 데이터를 받을 프로그램의 번호이다. 역시 16비트를 사용하여 목적지 프로그램을 식별한다.
- Length (길이): 'UDP 헤더(8바이트) + 데이터'의 전체 길이를 바이트 단위로 나타낸다. 최솟값은 8(데이터가 없을 때)이며, 이론상 최대 65,535바이트까지 표현 가능하다.
- Checksum (체크섬)
- 전송 중에 데이터가 변형되지 않았는지 확인하는 최소한의 안전장치이다.
- 송신 측에서 헤더와 데이터를 특정 계산법으로 합산해 기록하면, 수신 측에서 똑같이 계산해 값이 맞는지 대조한다. 틀리면 가차 없이 버린다.
- IPv4 시절에는 네트워크 계층(IP)과 전송 계층(UDP) 모두에서 이중으로 에러를 체크할 수 있었다.
- IPv4 헤더 체크섬: IPv4 헤더 자체에 체크섬 필드가 있어, 라우터들이 이동 중에 IP 주소가 변형되지 않았는지 확인했다.
- UDP의 선택: "IP 계층에서 이미 헤더를 검사하고 있으니, 데이터가 조금 깨져도 상관없는 실시간 서비스라면 UDP 체크섬 계산은 생략해서 속도를 높이자"라는 논리가 가능했다.
- 0의 의미: UDP 헤더의 체크섬 필드에 0을 채워 보내면, 수신 측은 "아, 체크섬을 계산하지 않았구나"하고 검사 없이 데이터를 수락한다.
- IPv6로 넘어오면서 인터넷 설계 철학이 크게 바뀌었다. 라우터가 매번 체크섬을 계산하는 시간을 줄여서 전송 속도를 극대화하기로 한 것이다.
- IP 헤더 체크섬 삭제: IPv6 헤더에는 체크섬 필드가 아예 없다. 라우터는 이제 헤더 검사를 하지 않고 패킷을 훨씬 빠르게 전달한다.
- UDP 체크섬의 필수화: IP 계층에서 에러 검사를 하지 않기 때문에, 만약 UDP에서도 체크섬을 안 하면 IP 주소가 오염되어 엉뚱한 곳으로 배달된 패킷을 걸러낼 방법이 아예 사라진다.
- 강력한 규칙: 따라서 IPv6에서 UDP 체크섬은 무조건 필수이다. 만약 체크섬이 0인 패킷이 도착하면, 수신 측은 이를 오류로 간주하고 즉시 폐기(Discard)한다.
✨ TCP 헤더와 비교
| 비교 항목 | UDP 헤더 | TCP 헤더 |
|---|---|---|
| 크기 | 고정 8바이트 | 최소 20 ~ 최대 60바이트 |
| 주요 필드 | 포트, 길이, 체크섬 | 순서 번호, 확인 응답 번호, 윈도우 크기, 플래그 등 |
| 오버헤드 | 매우 낮음 (가벼움) | 높음 (무거움) |
| 비유 | 주소만 적힌 포스트잇 | 수십 장의 계약서가 담긴 서류 봉투 |
✨ UDP가 단순한 이유
UDP의 철학은 "복잡한 건 위(애플리케이션 계층)에서 알아서 해라, 나는 오직 빠르게 전달만 한다"이다.
- 속도 최우선: 헤더가 작을수록 네트워크 장비(라우터 등)가 처리해야 할 양이 줄어들어 전송 속도가 빨라진다.
- 효율성: 아주 작은 데이터를 보낼 때(예: DNS 쿼리), 배보다 배꼽이 더 큰 상황(데이터보다 헤더가 더 큰 상황)을 방지한다.
6. UDP를 사용하는 이유
✨ UDP의 핵심 장점
- 극강의 전송 효율 (Low Overhead)
- 연결 과정 생략: TCP처럼 통신 전 "준비됐니?"라고 묻는 3-way handshake 과정이 없다. 데이터를 보내고 싶을 때 즉시 던질 수 있어 초기 지연 시간(Latency)이 거의 없다.
- 가벼운 헤더: TCP 헤더(20~60바이트)에 비해 UDP는 단 8바이트만 사용한다. 전송하는 데이터가 작을수록 이 차이는 상대적으로 더 커진다.
- 실시간성 보장 (No Head-of-Line Blocking)
- TCP는 중간에 패킷 하나만 사라져도 그걸 다시 받느라 뒤에 오는 데이터들이 줄줄이 대기해야 한다(HOL Blocking).
- UDP는 뒤를 돌아보지 않는다. 패킷 하나가 사라져도 다음 패킷을 즉시 처리하므로, 실시간 서비스에서 화면이 멈추는 현상을 최소화한다.
- 일대다 통신 가능 (Multicast / Broadcast)
- TCP는 1:1 연결(Unicast)만 가능하지만, UDP는 한 번에 여러 명에게 데이터를 뿌리는 것이 가능하다. 사내 방송이나 대규모 네트워크 장비 설정에 필수적이다.
✨ 구체적인 사용 사례와 이유
- 실시간 서비스
- 온라인 게임: 내 캐릭터의 위치 정보가 0.1초 늦게 전달되는 것보다, 중간에 한 번 정보가 누락되더라도 최신 위치를 바로 받는 게 게임 플레이에 훨씬 유리하다.
- 화상 회의 (Zoom/Skype): 목소리가 1초 뒤에 들리는 것보다, 아주 잠깐 '치직' 소리가 나고 대화가 이어지는 것이 자연스럽다.
- 짧은 요청과 응답
- DNS (도메인 네임 시스템): "google.com 주소가 뭐야?"라는 짧은 질문을 위해 TCP의 복잡한 연결 과정을 거치는 것은 낭비이다.
- 다만, 데이터가 512바이트를 넘거나 서버 간 동기화(Zone Transfer) 시에는 TCP를 쓰기도 한다.
- 네트워크 인프라 관리
- DHCP: 컴퓨터가 처음 켜졌을 때 IP 주소를 할당하는 과정이다. 아직 내 IP도 모르는 상태에서 1:1 연결(TCP)을 맺을 수는 없기에, 전체 네트워크에 뿌리는 UDP 브로드캐스트를 사용한다.
✨ TCP vs. UDP 선택 기준 가이드
7. DNS가 UDP를 사용하는 이유
✨ UDP를 선택한 이유
- 오버헤드 최소화 (No Connection)
- TCP: 데이터를 주고받기 전 "안녕? 나 데이터 보내도 돼?"(3-way handshake)라는 절차가 필요하다.
- UDP: 이런 절차 없이 바로 질문("google.com 주소 뭐야?")을 던진다.
- 결과: 단 한 번의 요청과 응답으로 끝나기 때문에 서버의 부담이 적고 응답 속도가 매우 빠르다.
- 패킷 하나에 쏙 들어가는 크기
- 대부분의 DNS 질문과 답변은 매우 짧다. UDP 패킷 하나에 충분히 담길 정도(보통 512바이트 이하)이기 때문에 굳이 복잡한 TCP를 쓸 이유가 없다.
- 똑똑한 애플리케이션 계층
- UDP는 신뢰성이 없지만, DNS 프로그램 자체가 '타임아웃'과 '재전송' 기능을 가지고 있다.
- 만약 응답이 안 오면 DNS가 알아서 다시 물어보기 때문에 전송 계층의 도움 없이도 충분히 안정적이다.
✨ DNS가 TCP를 사용하는 경우
하지만 모든 상황에서 UDP가 만능은 아니다. 다음과 같은 특수 상황에서는 53번 포트 그대로 TCP를 사용한다.
| 상황 | 설명 | 이유 |
|---|---|---|
| Zone Transfer | DNS 서버끼리 전체 주소록 데이터를 동기화할 때 | 데이터 양이 방대하고, 단 하나의 정보라도 틀리면 안 되기 때문 |
| 응답 크기 초과 | 응답 데이터가 512바이트를 넘을 때 | UDP의 제한 용량을 넘어서면 데이터가 잘림(Truncation) 현상이 발생하기 때문 |
| 보안 강화 (DNSSEC) | 디지털 서명 등이 포함되어 응답이 길어질 때 | 보안 정보는 용량이 크고 정확한 전달이 필수적이기 때문 |
8. TCP vs. UDP 비교표
| 특성 | TCP | UDP |
|---|---|---|
| 연결 방식 | 연결형 (Connection-oriented) | 비연결형 (Connectionless) |
| 신뢰성 | 높음 (재전송, 순서 보장) | 낮음 (보장 없음) |
| 속도 | 상대적으로 느림 | 빠름 |
| 헤더 크기 | 20~60바이트 | 8바이트 |
| 순서 보장 | 보장됨 | 보장 안 함 |
| 전송 단위 | Stream (바이트 스트림) | Datagram (데이터그램) |
| 오류 제어 | 강력함 (자동 재전송) | 기본적 (Checksum만) |
| 흐름 제어 | 있음 | 없음 |
| 혼잡 제어 | 있음 | 없음 |
| 사용 예시 | 웹(HTTP), 이메일(SMTP), 파일 전송(FTP) | 스트리밍, 게임, DNS, VolP |
9. UDP 동작 원리 예시
✨ 온라인 게임
온라인 게임(FPS, MOBA 등)에서는 0.1초의 지연이 승패를 결정짓는다. 여기서 UDP는 '최신 상태 유지'에 집중한다.
게임 서버는 1초에 수십 번씩 플레이어들의 위치 정보를 보낸다.
- 정상 상황: (10, 10) → (11, 11) → (12, 12) 순서로 위치 정보가 도착한다.
- 패킷 손실 발생: (11, 11) 정보가 중간에 사라졌다면?
- TCP라면: (11, 11)을 다시 받을 때까지 (12, 12) 정보를 처리하지 않고 기다린다. 화면이 멈추는 '렉(Lag)'이 발생한다.
- UDP라면: (11, 11)은 무시하고 바로 도착한 (12, 12) 정보를 사용한다. 캐릭터가 아주 살짝 순간이동한 것처럼 보일 수 있지만, 게임은 끊김 없이 계속된다.
✨ 영상 스트리밍
유튜브 라이브나 Zoom 화상 회의 같은 실시간 스트리밍에서도 UDP의 진가가 발휘된다.
영상은 수많은 '프레임(장면)'의 연속이다.
- 패킷 손실 발생: 영상 데이터 조각 하나가 사라지면 화면의 특정 부분이 깨지거나(깍두기 현상) 아주 잠깐 지연된다.
- UDP의 선택: "깨진 조각을 다시 받느라 전체 영상을 멈추게 할 순 없어!"라며 다음 장면을 계속 재생한다.
- 결과: 시청자는 "어? 방금 화면이 살짝 깨졌네?"라고 느끼지만, 방송은 실시간으로 계속 이어진다. 만약 TCP를 썼다면 화면이 뱅글뱅글 돌며(버퍼링) 실시간 흐름을 놓치게 될 것이다.
10. 최신 트렌드: UDP의 화려한 부활 (HTTP/3 & QUIC)
UDP가 '신뢰성 없는 프로토콜'이라는 오명을 벗고, 현대 웹의 주인공으로 화려하게 부활한 배경에는 QUIC과 HTTP/3가 있다.
✨ 왜 다시 UDP인가? (TCP의 한계)
인터넷 속도는 비약적으로 빨라졌지만, 30년 넘은 TCP의 구조적 문제가 발목을 잡기 시작했다.
- 연결 지연 (Handshake Latency): TCP는 연결을 맺을 때(3-way handshake)와 보안 연결(TLS)을 설정할 때 여러 번 왔다 갔다 해야 한다. 이 과정에서 발생하는 지연 시간이 현대 웹에서는 너무 길게 느껴져게 된 것이다.
- HOLB (Head-of-Line Blocking) 문제: HTTP/2는 하나의 TCP 연결에 여러 데이터를 실어 보낸다. 하지만 TCP는 '순서'를 너무 엄격히 따져셔, 패킷 하나만 유실되어도 나머지 데이터가 모두 멈춰버리는 치명적인 단점이 있다.
- 느린 개선 속도: TCP는 운영체제(OS) 커널 수준에서 구현되어 있어, 새로운 기능을 추가하거나 수정하려면 전세계의 OS를 다 업데이트해야 하는 어려움이 있다.
✨ QUIC: UDP의 날개에 TCP의 지능을 달다
구글은 "차라리 아무 기능 없는 UDP를 가져다가, 그 위에 우리가 필요한 기능을 직접 만들자!"라고 결정했다. 그것이 바로 QUIC이다.
QUIC의 핵심 혁신 기능은 다음과 같다.
- 빠른 연결 설정 (0-RTT / 1-RTT): 첫 연결 시 보안 설정과 데이터 전송을 동시에 진행한다. 한 번 연결했던 서버라면 기다림 없이(0-RTT) 바로 데이터를 전송할 수 있다.
- 독립적인 스트림 (HOLB 해결): 여러 파일을 보낼 때, 패킷 하나가 사라져도 해당 파일만 영향을 받고 나머지는 정상적으로 전송된다. UDP의 독립적인 특성을 활용한 것이다.
- 연결 마이그레이션 (Connection ID): TCP는 IP 주소가 바뀌면(Wi-Fi에서 LTE로 전환 시) 연결이 끊긴다. 하지만 QUIC은 고유한 'Connection ID'를 사용하므로, IP가 바뀌어도 끊김 없이 통신을 이어갈 수 있다.
✨ HTTP/1.1 vs. HTTP/2 vs. HTTP/3
| 구분 | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|
| 기반 프로토콜 | TCP | TCP | UDP (QUIC) |
| 연결 방식 | 여러 개의 TCP 연결 | 하나의 TCP 연결 (멀티플렉싱) | 하나의 UDP 연결 (QUIC) |
| HOLB 문제 | 발생 (애플리케이션 계층) | 발생 (전송 계층) | 해결 (독립적 스트림) |
| 보안 (TLS) | 별도 설정 필요 | 별도 설정 필요 | 기본 내장 (TLS 1.3) |
