(CS/컴퓨터공학) TCP vs UDP 어떤 상황에서 쓸까?
✨ 개요
“이 서비스는 지연이 더 중요할까, 신뢰성이 더 중요할까?”
TCP와 UDP 선택은 이 질문에서 시작됩니다. 두 프로토콜의 특성과 대표 사용 시나리오를 한 번에 정리합니다.
1. 한 장 요약 표
- TCP: 신뢰성·순서 보장·혼잡제어 → 파일/결제/로그인/DB 복제/API 호출
- UDP: 경량·낮은 지연·손실 허용 → 실시간 미디어(RTP), 게임 상태 동기화, DNS, 브로드캐스트
핵심 트레이드오프:
TCP = 정확성 우선(Head-of-Line 차단 수용)
UDP = 최신성·지연 우선(일부 손실 수용)
2 기능 차이 한눈표
| 구분 | TCP | UDP |
|---|---|---|
| 연결 | 연결지향(3-way handshake) | 비연결형 |
| 신뢰성 | 재전송/순서/무결성 보장 | 미보장(응용이 직접 처리) |
| 흐름/혼잡 제어 | 있음(윈도·ACK·Congestion Control) | 없음(응용·전송 레벨 설계 필요) |
| 전송 단위 | Byte stream(스트림) | Datagram(메시지 경계 유지) |
| 지연 | 재전송·혼잡제어로 늘 수 있음 | 오버헤드 적어 낮음 |
| HoL Blocking | 있음(앞 패킷 유실 시 뒤도 대기) | 없음(응용이 필요한 것만 처리) |
| 암호화(일반) | TLS(SSL) | DTLS / 애플리케이션 레벨 암호화 |
| 대표 사례 | HTTP(S), FTP/SFTP, SMTP/IMAP, DB | RTP/WebRTC, VoIP, DNS, 게임 상태, mDNS, syslog(옵션) |
3 언제 TCP가 맞나? (정확성·완전성 우선)
특징: 손실 시 재전송, 순서 보장, 흐름/혼잡 제어로 “정확한 전송”을 보장합니다.
적합한 상황
- 파일 전송: S3 업로드, 백업, 소프트웨어 배포 (바이트 하나도 틀리면 X)
- 웹/모바일 API: REST/gRPC-over-TCP(HTTP/2) — 요청/응답 일관성
- 금융/결제/로그인: 트랜잭션 무결성 필수
- DB 복제/메시지 큐 브로커 연결: 정확한 순서/전달 보장
지연보다 정확성/순서가 더 중요하면 TCP입니다.
단, 손실/혼잡이 심하면 Head-of-Line(HoL) 차단으로 지연이 급증할 수 있습니다.
4. 언제 UDP가 맞나? (지연·실시간성 우선)
특징: 연결/재전송/혼잡제어 없음 → 오버헤드 최소, 지연 낮음. 손실은 응용이 처리해야 합니다.
적합한 상황
- 실시간 미디어: RTP/RTCP 기반 화상회의·라이브 스트리밍(프레임 몇 개 유실 허용)
- 온라인 게임: 포지션/상태 동기화 — 오래된 패킷은 버리고 최신만 반영
- DNS: 단문 질의-응답(빠른 왕복)
- 브로드캐스트/멀티캐스트: 로컬 네트워크 공지, 서비스 발견(mDNS 등)
“지금 상태가 더 중요하고, 과거 데이터를 기다릴 이유가 없다”면 UDP를 고려하세요.
필요하면 앱 계층에서 FEC(전방 오류 정정), 적응형 비트레이트, 재전송 제한을 설계합니다.
5. 지연 vs 신뢰성: 설계 팁
- 패킷 손실 환경(모바일/와이파이)
- TCP: 재전송으로 지연 스파이크 가능(HoL)
- UDP: 손실 허용 + 타임스탬프/시퀀스로 최신 프레임만 재생
- 대역폭 변화
- TCP: 혼잡제어가 자동 조절(대신 일시 멈칫 가능)
- UDP: 응용이 자체 적응(예: 프레임 드랍, 해상도/비트레이트 다운)
- 보안
- TCP: TLS 표준
- UDP: DTLS 또는 애플리케이션 암호화(WebRTC SRTP 등)
6. 현대 대안: QUIC(UDP 위 전송)
- QUIC은 UDP 위에 연결/암호화(TLS1.3)/혼잡제어/스트림 다중화를 얹은 프로토콜.
- 0-RTT 재연결, 스트림 단위 HoL 차단 없음 → HTTP/3의 기반.
- “TCP의 신뢰성 + UDP의 낮은 지연”을 실무적으로 결합한 최신 선택지.
7. 시나리오별 추천
| 시나리오 | 권장 | 이유/메모 |
|---|---|---|
| 파일 업로드/다운로드, 결제 | TCP(HTTPS) | 재전송·순서 보장이 필수 |
| REST/gRPC API | TCP(HTTP/1.1/2/3) | HTTP 표준, 프록시/보안/관찰성 우수 |
| 화상회의·라이브 방송 | UDP(RTP/WebRTC) or HTTP-LL | 손실 허용 + 낮은 지연, 적응형 전송 |
| 실시간 게임(상태 전파) | UDP | 최신 상태 우선, 과거 패킷은 폐기 |
| DNS 질의 | UDP(소량), TCP(대형/DoT/DoH) | 크기/보안 요건에 따라 |
| 로컬 서비스 발견/멀티캐스트 | UDP | 브로드캐스트/멀티캐스트 용이 |
8. 개발 팁 (Kotlin/JVM 스니펫)
8.1 TCP 클라이언트(신뢰성 우선)
Socket("example.com", 443).use { sock ->
sock.getOutputStream().write("PING\n".toByteArray())
val resp = sock.getInputStream().readBytes()
println(String(resp))
}
val socket = DatagramSocket()
val data = "hello".toByteArray()
val pkt = DatagramPacket(data, data.size, InetAddress.getByName("239.0.0.1"), 5000)
socket.send(pkt)
// 수신
val buf = ByteArray(1500)
val recv = DatagramPacket(buf, buf.size)
socket.receive(recv)
println(String(buf, 0, recv.length))
// UDP는 순서/중복/손실을 직접 처리해야 합니다. 패킷에 seq/timestamp를 넣고, 오래된 건 버리는 로직을 넣으세요.
9. 운영/배포 관점 체크리스트
- NAT/방화벽: UDP 차단 환경이 여전히 존재 → TURN/ICE(WebRTC), 혹은 TCP fallback 고려
- MTU/MSS: UDP는 큰 패킷이 단편화되면 손실↑ → 작은 payload로 쪼개기
- 관찰성: TCP는 미들박스/프록시 호환성 우수, UDP는 자체 로그/메트릭 설계 필요
- 모바일 네트워크: 핸드오버·패킷 손실 고려 → 재전송 정책/버퍼 디자인 중요