TCP와 UDP 차이 — CS 면접에서 이렇게 답하면 된다
TCP와 UDP 차이, 면접에서 가장 자주 나오는 질문
TCP와 UDP 차이는 CS 면접에서 거의 빠지지 않는 단골 질문입니다. 두 프로토콜은 모두 전송 계층(Transport Layer, OSI 4계층)에서 동작하지만, '연결을 맺느냐'와 '신뢰성을 보장하느냐'에서 근본적으로 갈립니다. 핵심만 먼저 말하면 TCP는 연결 지향적이고 신뢰성을 보장하는 프로토콜, UDP는 비연결형이고 신뢰성을 보장하지 않는 대신 빠른 프로토콜입니다.
TCP와 UDP의 핵심 차이
| 구분 | TCP | UDP |
|---|---|---|
| 연결 방식 | 연결 지향(3-way handshake) | 비연결형 |
| 신뢰성 | 보장(재전송, 순서 보장) | 보장 안 함 |
| 순서 보장 | O (시퀀스 번호) | X |
| 흐름/혼잡 제어 | O | X |
| 전송 단위 | 세그먼트(바이트 스트림) | 데이터그램(메시지) |
| 헤더 크기 | 20~60바이트 | 8바이트 |
| 속도 | 상대적으로 느림 | 빠름 |
| 대표 사용 | HTTP/HTTPS, 파일 전송, 이메일 | DNS, 스트리밍, 게임, VoIP |
1. 연결 방식 — TCP는 악수부터 한다
TCP는 데이터를 보내기 전에 3-way handshake로 연결을 수립합니다. 클라이언트가 SYN을 보내고, 서버가 SYN+ACK로 응답하고, 클라이언트가 다시 ACK를 보내 연결이 확립됩니다. 연결 종료는 4-way handshake(FIN, ACK, FIN, ACK)를 사용합니다. 반면 UDP는 이런 절차 없이 바로 데이터그램을 던집니다. 받는 쪽이 준비됐는지 확인하지 않습니다.
2. 신뢰성 — TCP는 빠진 데이터를 다시 보낸다
TCP는 각 세그먼트에 시퀀스 번호를 붙이고, 수신 측은 ACK로 잘 받았음을 알립니다. ACK가 일정 시간 안에 오지 않으면 재전송합니다. 또 시퀀스 번호 덕분에 패킷이 뒤섞여 도착해도 원래 순서로 재조립합니다. UDP는 이런 보장이 전혀 없어서, 패킷이 유실되거나 순서가 바뀌어도 그대로 둡니다. 신뢰성이 필요하면 애플리케이션 레벨에서 직접 구현해야 합니다.
3. 흐름 제어와 혼잡 제어
TCP는 수신 측 버퍼가 넘치지 않도록 흐름 제어(슬라이딩 윈도우)를 하고, 네트워크 혼잡을 감지해 전송 속도를 조절하는 혼잡 제어(슬로 스타트, 혼잡 회피 등)를 합니다. UDP는 이런 제어가 없어 보내는 쪽이 일방적으로 쏟아냅니다.
실제 예시로 이해하기
택배로 비유하면 TCP는 '등기우편'입니다. 받는 사람이 서명(ACK)을 하고, 분실되면 다시 보냅니다. UDP는 '전단지 살포'입니다. 일단 뿌리고, 몇 장이 바람에 날아가도 신경 쓰지 않습니다. 대신 빠르고 부담이 적습니다.
왜 영상 스트리밍이나 게임이 UDP를 쓸까요? 화상통화에서 0.5초 전의 프레임을 재전송받아 봐야 의미가 없기 때문입니다. 약간의 손실을 감수하더라도 지연(latency)이 낮은 게 더 중요합니다. 반면 파일 다운로드는 단 1바이트라도 빠지면 파일이 깨지므로 TCP가 적합합니다.
면접 답변 예시
"TCP와 UDP는 둘 다 전송 계층 프로토콜이지만 신뢰성과 연결 방식이 다릅니다. TCP는 3-way handshake로 연결을 수립하고, 시퀀스 번호와 ACK, 재전송을 통해 데이터의 신뢰성과 순서를 보장하며 흐름 제어와 혼잡 제어를 수행합니다. 그래서 HTTP, 파일 전송처럼 정확성이 중요한 곳에 씁니다. UDP는 비연결형으로 이런 제어가 없어 헤더가 8바이트로 가볍고 빠릅니다. 약간의 손실을 감수하더라도 지연이 낮아야 하는 실시간 스트리밍, 게임, DNS, VoIP 등에 적합합니다. 정리하면 TCP는 신뢰성, UDP는 속도가 핵심 트레이드오프입니다."
면접 꼬리질문 대비
Q1. DNS는 왜 UDP를 주로 쓰나요?
DNS 질의는 보통 한 번의 요청-응답으로 끝나는 작은 메시지라 연결 수립 비용(handshake)이 오히려 더 큰 오버헤드가 됩니다. 그래서 기본적으로 UDP를 사용합니다. 다만 응답이 512바이트(또는 EDNS 확장 크기)를 넘거나 영역 전송(zone transfer)처럼 큰 데이터를 주고받을 때는 TCP로 폴백합니다.
Q2. TCP의 3-way handshake는 왜 3번인가요? 2번이면 안 되나요?
양쪽 모두 자신의 송신 능력과 상대의 수신 능력을 확인해야 하기 때문입니다. 클라이언트의 SYN(나 보낼게), 서버의 SYN+ACK(나도 보낼게, 네 거 받았어), 클라이언트의 ACK(네 거 받았어)를 거쳐야 양방향 통신이 검증됩니다. 2-way로는 서버가 클라이언트의 수신 능력을 확인할 수 없고, 지연된 중복 SYN으로 인한 잘못된 연결 수립 문제도 막을 수 없습니다.
Q3. UDP인데 신뢰성이 필요하면 어떻게 하나요?
애플리케이션 계층에서 재전송, 순서 보장, 흐름 제어를 직접 구현합니다. 대표적으로 QUIC(HTTP/3의 기반)이 UDP 위에서 신뢰성과 혼잡 제어를 구현해 TCP의 handshake 지연과 HOL(Head-of-Line) 블로킹 문제를 개선한 예입니다.