핵심 요약
TCP는 연결을 맺고 순서·재전송·흐름제어를 보장하는 대신 오버헤드가 있다. UDP는 그냥 보내고 잊는(fire-and-forget) 방식이라 빠르지만 손실·순서 뒤바뀜을 앱이 감수해야 한다. "정확성이 중요하면 TCP, 실시간성이 중요하면 UDP"가 기본 기준이다.
1. 핵심 차이 한눈에
| 항목 | TCP | UDP |
|---|---|---|
| 연결 | 3-way 핸드셰이크 | 없음 |
| 신뢰성 | 재전송·순서 보장 | 보장 안 함 |
| 속도 | 상대적으로 느림 | 빠름 |
| 흐름/혼잡 제어 | 있음 | 없음 |
| 헤더 크기 | 20바이트~ | 8바이트 |
2. 언제 TCP인가
- 웹(HTTP/HTTPS), 파일 전송, 이메일 — 한 바이트라도 틀리면 안 되는 것
- 순서와 완전성이 속도보다 중요한 모든 경우
3. 언제 UDP인가
- 실시간 영상·음성통화, 온라인 게임 — 조금 손실돼도 "지금" 도착이 더 중요
- DNS 조회 — 짧은 요청/응답 하나라 연결 맺는 비용이 아까움
- 브로드캐스트·멀티캐스트 — TCP는 1:1만 가능
4. 흔한 오해
- "UDP는 불안정해서 나쁘다" — 아니다. QUIC(HTTP/3)은 UDP 위에 신뢰성을 앱 레벨로 다시 구현해 TCP의 단점(HOL 블로킹)을 피한다
- "TCP는 데이터 경계를 지켜준다" — 아니다. TCP는 바이트 스트림이라
send두 번이 한 번에 읽힐 수 있다(그래서 길이 프레이밍 필요)
5. 면접 답변 틀
"TCP는 신뢰성, UDP는 저지연입니다. 데이터가 하나도 틀리면 안 되는 웹·파일 전송은 TCP, 조금 손실돼도 실시간성이 중요한 통화·게임·DNS는 UDP를 씁니다. 요즘은 HTTP/3처럼 UDP 위에서 신뢰성을 직접 구현하는 방향도 있습니다."
자주 묻는 질문
HTTP/3가 UDP를 쓴다는데, 그럼 느리지 않나요?
QUIC은 UDP 위에서 재전송·순서·암호화를 직접 구현합니다. TCP의 head-of-line 블로킹(한 패킷 손실이 뒤 스트림 전체를 막는 문제)을 피할 수 있어 오히려 손실이 있는 네트워크에서 더 빠릅니다.
UDP는 순서가 뒤바뀔 수 있는데 게임은 어떻게 처리하나요?
게임은 보통 최신 상태만 중요하므로 오래된 패킷은 그냥 버립니다. 순서 번호를 붙여 늦게 온 패킷을 무시하거나, 중요한 이벤트만 별도로 신뢰성 있게 재전송하는 식으로 앱에서 제어합니다.
TCP는 데이터 경계를 지켜주나요?
아니요. TCP는 바이트 스트림이라 보낸 메시지 단위가 그대로 읽힌다는 보장이 없습니다. 메시지 앞에 길이를 붙이거나 구분자를 두는 프레이밍을 직접 해야 합니다.
댓글 0