TCP vs UDP 완전 정복 — 연결, 신뢰성, 순서 보장, `QUIC`까지
TCP와 UDP, 왜 따로 알아야 하나요?
네트워크 계층 글, HTTP 버전 글, IPv4 vs IPv6 글까지 읽고 나면 이런 질문이 남습니다.
- 웹은 왜 보통
TCP위에서 동작할까요? UDP는 연결을 안 맺으니 무조건 더 빠르다고 해도 될까요?- 게임, 음성 통화, 스트리밍은 왜
UDP를 많이 쓸까요? HTTP/3는UDP위에서 동작하는데, 그럼 신뢰성이 없는 걸까요?
핵심은 이것입니다.
TCP와UDP의 가장 큰 차이는 단순히 "빠르냐 느리냐"가 아니라, 애플리케이션에게 어떤 전송 계약을 제공하느냐에 있습니다
즉:
TCP는 신뢰성 있는, 순서 보장 바이트 스트림UDP는 최소 기능의, 비연결형 데이터그램 전송
에 가깝습니다.
이 글에서는 TCP와 UDP를 "둘 다 포트 번호를 쓰는 전송 계층 프로토콜"에서 끝내지 않고, 연결, 신뢰성, 순서, 흐름 제어, 혼잡 제어, 메시지 경계, QUIC과의 관계 를 기준으로 정리하겠습니다.
기준: 이 글은
TCP는RFC 9293,UDP는RFC 768,UDP사용 지침은RFC 8085를 기준으로 설명합니다.
먼저 선택 기준부터 보면
실무에서는 보통 아래 기준으로 보면 크게 틀리지 않습니다.
| 상황 | 먼저 볼 선택지 | 이유 |
|---|---|---|
| 정확한 전달과 순서 보장이 중요함 | TCP |
재전송, 순서 보장, 흐름 제어가 기본 제공됩니다 |
| 일부 손실보다 지연이 더 중요함 | UDP |
연결 설정과 재전송 대기 없이 빠르게 보낼 수 있습니다 |
| 메시지 경계 자체가 중요함 | UDP |
한 번 보낸 데이터그램 경계가 유지됩니다 |
| 바이트 스트림으로 길게 주고받음 | TCP |
메시지 경계 대신 연속 스트림 처리에 적합합니다 |
QUIC처럼 신뢰성과 혼잡 제어를 직접 얹고 싶음 |
UDP 위의 상위 프로토콜 |
필요한 기능을 상위 프로토콜 쪽에서 설계할 수 있습니다 |
가장 짧게 줄이면 이렇습니다.
- 정확하게 도착해야 하면
TCP부터 봅니다 - 조금 잃어도 실시간성이 더 중요하면
UDP를 봅니다 UDP가 항상 더 빠른 것은 아니고, 빠져 있는 기능을 누가 대신 구현할지가 더 중요합니다
Phase 1. 전송 계층은 무엇을 맡을까?
먼저 큰 그림부터 다시 잡아야 합니다.
전송 계층의 핵심 역할은:
- 어떤 프로세스와 통신할지 포트로 구분하고
- 애플리케이션 데이터를 네트워크에 실어 보내며
- 상대에게 어떤 형태로 전달할지 계약을 정하는 것
입니다.
즉, 같은 IP 통신이라도:
TCP를 쓰면 애플리케이션은 연결된 스트림처럼 느끼고UDP를 쓰면 애플리케이션은 독립된 메시지 묶음처럼 느낍니다
이 차이가 상위 프로토콜 설계에 매우 크게 영향을 줍니다.
Phase 2. TCP는 무엇을 보장할까?
RFC 9293는 TCP를 reliable, in-order, byte-stream service 로 설명합니다. 이 한 문장에 핵심이 거의 다 들어 있습니다.
1. TCP는 연결형이다
TCP는 데이터를 주고받기 전에 연결을 맺습니다. 흔히 말하는 3-way handshake가 여기서 나옵니다.
아주 단순하게 그리면:
Client -> Server : SYN
Client <- Server : SYN + ACK
Client -> Server : ACK
이 과정을 거쳐 양쪽은:
- 서로 통신할 준비가 되었는지 확인하고
- 초기 시퀀스 번호를 맞추고
- 연결 상태를 만듭니다
즉, TCP는 "그냥 보내면 된다"가 아니라 연결 상태를 만든 뒤 그 위에서 데이터를 흐르게 하는 프로토콜입니다.
2. TCP는 신뢰성과 순서를 보장한다
TCP가 중요한 이유는 단순히 연결을 맺기 때문이 아닙니다.
- 시퀀스 번호로 순서를 관리하고
ACK로 도착 여부를 확인하며- 손실이 나면 재전송하고
- 중복 세그먼트를 걸러냅니다
즉, 애플리케이션은 보통:
- 일부 패킷이 중간에서 빠졌는지
- 순서가 뒤바뀌었는지
- 다시 보내야 하는지
를 직접 다루지 않아도 됩니다.
이 때문에:
- 파일 전송
- 데이터베이스 연결
- 로그인/결제 같은 API 요청
처럼 정확도가 먼저인 작업과 잘 맞습니다.
3. 하지만 TCP는 메시지 프로토콜이 아니라 스트림이다
이 부분이 가장 자주 헷갈립니다.
TCP는 메시지 경계를 보장하지 않고, 연속된 바이트 스트림을 전달합니다
예를 들어 애플리케이션이 두 번 send() 했다고 해서, 상대가 반드시 두 번 recv()로 정확히 같은 단위로 받는 것은 아닙니다.
보낸 쪽:
"HELLO"
"WORLD"
받는 쪽:
"HELLOWORLD"
또는:
받는 쪽:
"HEL"
"LOW"
"ORLD"
처럼 보일 수 있습니다.
즉, TCP 위에서는 애플리케이션이:
- 길이 프리픽스
- 구분자
- 자체 프레이밍 규칙
으로 메시지 경계를 따로 정의해야 합니다.
4. TCP는 흐름 제어와 혼잡 제어도 함께 본다
TCP는 단순히 "다시 보내 주는 프로토콜"이 아닙니다.
- 흐름 제어로 상대 수신 버퍼가 감당할 수 있는 양을 넘기지 않으려 하고
- 혼잡 제어로 네트워크가 감당하지 못할 만큼 무작정 밀어 넣지 않으려 합니다
즉, TCP는 단일 애플리케이션의 편의만이 아니라 네트워크 전체의 안정성도 같이 고려하는 전송 계층 프로토콜입니다.
Phase 3. UDP는 무엇을 제공할까?
RFC 768은 UDP를 minimum of protocol mechanism 을 제공하는 프로토콜이라고 설명합니다. 그리고 delivery와 duplicate protection이 보장되지 않는다고 명시합니다.
1. UDP는 비연결형이다
UDP는 TCP처럼 연결을 맺는 절차가 없습니다.
즉, 개념적으로는:
메시지 하나를 바로 보냄
에 가깝습니다.
그래서:
- 연결 설정 지연이 없고
- 상태가 단순하며
- 짧은 요청/응답이나 실시간 트래픽에 유리할 수 있습니다
2. UDP는 메시지 경계를 유지한다
UDP의 중요한 장점 중 하나는 데이터그램 단위가 유지된다는 점입니다.
예를 들어 100바이트를 한 번 보내면, 받는 쪽은:
- 그 데이터그램 전체를 한 묶음으로 받거나
- 너무 큰 버퍼 부족 등으로 일부만 보더라도
- 기본 개념 자체는 "하나의 메시지"입니다
즉, UDP는 TCP와 달리 메시지 지향적입니다.
이 차이는 다음 같은 경우에 특히 중요합니다.
- 실시간 게임 입력 이벤트
- DNS 질의/응답
- 음성 프레임
- 센서/텔레메트리 샘플
3. 대신 순서, 재전송, 중복 제거는 기본 제공이 아니다
UDP는 애플리케이션에 이런 보장을 기본 제공하지 않습니다.
- 안 도착할 수 있습니다
- 순서가 바뀔 수 있습니다
- 중복 도착할 수 있습니다
즉, 애플리케이션이 필요하다면:
- 시퀀스 번호
- 타임아웃
- 재전송
- 중복 제거
를 직접 구현해야 합니다.
그래서 UDP를 쓴다는 말은 종종:
전송 계층이 안 해 주는 일을 상위 프로토콜이나 애플리케이션이 대신 떠안는다
는 뜻이기도 합니다.
4. UDP에는 혼잡 제어가 내장되어 있지 않다
이 부분도 매우 중요합니다.
RFC 8085는 UDP가 no inherent congestion control mechanisms 를 가진다고 설명합니다.
즉, 마음만 먹으면 애플리케이션이 매우 빠르게 UDP 데이터그램을 밀어 넣을 수 있습니다. 하지만 그렇게 하면:
- 경로 용량을 초과할 수 있고
- 혼잡 붕괴에 기여할 수 있으며
- 다른 트래픽과의 공정성도 해칠 수 있습니다
그래서 인터넷에서 UDP를 쓰는 애플리케이션은 혼잡 제어를 따로 고려해야 합니다.
Phase 4. 왜 UDP가 항상 더 빠르지는 않을까?
실무에서 가장 흔한 오해가 이것입니다.
UDP는 단순하니까 무조건TCP보다 빠르다
이건 절반만 맞습니다.
UDP가 유리할 수 있는 이유
- 연결 설정이 없습니다
- 재전송 대기가 기본 동작에 없습니다
- 헤더가 단순합니다
- 메시지 단위 전송이 쉽습니다
그래서 짧고 빠른 단방향 전송이나 실시간성 높은 트래픽에서는 유리할 수 있습니다.
하지만 손실이 생기면 이야기가 달라진다
패킷 손실이 있는 환경에서 애플리케이션이 결국:
- 재전송을 직접 구현하고
- 순서를 다시 맞추고
- 혼잡 제어도 추가하고
- 연결 생명주기도 추적한다면
처음의 "단순함"은 빠르게 사라집니다.
즉, UDP 자체가 빠르다기보다:
- 버릴 수 있는 것을 버릴 수 있을 때
- 또는 필요한 기능을 더 잘게 직접 설계할 수 있을 때
강점이 생깁니다.
반대로 정확히 도착해야 하는 데이터를 UDP로 보내면서 위 기능을 다시 다 구현한다면, TCP를 쓰는 것보다 복잡하기만 할 수 있습니다.
Phase 5. 그럼 언제 TCP, 언제 UDP를 쓸까?
실무에서는 보통 아래처럼 판단하면 크게 틀리지 않습니다.
TCP가 잘 맞는 경우
- 웹 API 요청/응답
- 로그인, 결제, 주문 생성
- 데이터베이스 연결
- 파일 업로드/다운로드
- 메일, SSH, 일반적인 백엔드 간 통신
이런 경우는 대체로:
- 순서가 중요하고
- 일부 손실을 허용하기 어렵고
- 애플리케이션이 전송 신뢰성을 다시 구현할 이유가 적습니다
UDP가 잘 맞는 경우
- 실시간 음성/영상
- 온라인 게임 상태 업데이트
- DNS 같은 짧은 질의/응답
- 일부 텔레메트리, 모니터링 이벤트
이런 경우는 대체로:
- 늦게 도착한 데이터가 쓸모없어질 수 있고
- 일부 손실을 허용할 수 있으며
- 지연을 더 민감하게 봅니다
다만 여기서도 "무조건 UDP"라고 말하면 과합니다. 예를 들어 오늘날 스트리밍과 실시간 통신은 UDP 위의 상위 프로토콜 설계, 적응형 비트레이트, 혼잡 제어까지 함께 봐야 하기 때문입니다.
Phase 6. QUIC은 왜 UDP 위에서 동작할까?
HTTP/3 글과 연결되는 지점입니다.
많은 분이 여기서 이렇게 생각합니다.
UDP는 신뢰성이 없는데- 왜
HTTP/3는 굳이UDP위에 올라갈까?
핵심은 이것입니다.
QUIC은UDP위에 올라가지만,UDP의 빈 기능을 그대로 방치하지 않고 그 위에 신뢰성, 순서, 혼잡 제어,TLS 1.3통합을 다시 설계한 프로토콜입니다
즉, QUIC은:
UDP의 데이터그램 전송을 바탕으로- 필요한 재전송과 혼잡 제어를 직접 구현하고
- 스트림 단위 다중화도 제공하며
TCP위HTTP/2에서 남던 전송 계층 병목 일부를 다르게 풀려는 접근입니다
그래서 "UDP = 신뢰성 없음"이라는 문장을 그대로 HTTP/3에 적용하면 틀립니다. 정확히는:
UDP자체는 신뢰성과 혼잡 제어를 보장하지 않고QUIC이 그 위에 필요한 기능을 다시 얹습니다
핵심만 다시 정리하면
마지막으로 TCP와 UDP를 한 번 더 비교하면 이렇게 볼 수 있습니다.
| 구분 | TCP |
UDP |
|---|---|---|
| 전송 성격 | 연결형 바이트 스트림 | 비연결형 데이터그램 |
| 순서/재전송 | 기본 제공 | 기본 제공 안 함 |
| 메시지 경계 | 유지 안 됨 | 유지됨 |
| 흐름/혼잡 제어 | 기본 제공 | 애플리케이션이 고려해야 함 |
| 대표 사용처 | 웹, DB, 파일 전송 | DNS, 게임, 음성, QUIC |
핵심 포인트는 다섯 가지입니다.
TCP와UDP의 가장 큰 차이는 속도 그 자체보다 전송 계약의 차이에 있습니다.TCP는 신뢰성 있는, 순서 보장 바이트 스트림이고, 메시지 경계는 애플리케이션이 직접 만들어야 합니다.UDP는 메시지 지향 데이터그램 전송이지만, 전달 보장, 중복 제거, 혼잡 제어를 기본 제공하지 않습니다.UDP는 단순해서 유리할 수 있지만, 빠진 기능을 다시 구현해야 하면 반드시 더 좋은 선택이 되는 것은 아닙니다.HTTP/3의QUIC처럼, 현대 프로토콜은UDP위에 필요한 신뢰성과 혼잡 제어를 다시 설계해 사용하는 경우도 많습니다.
결국 TCP vs UDP는 "UDP가 더 빠른가?"의 문제가 아니라, 우리 애플리케이션이 순서와 신뢰성을 어디까지 필요로 하고, 그 비용을 전송 계층이 맡을지 애플리케이션이 맡을지 를 고르는 문제에 가깝습니다.