[Daily morning study] TCP vs UDP 비교

04 Jul 2026 in Daily morning study / Network

#daily morning study

---

TCP와 UDP란

TCP(Transmission Control Protocol)와 UDP(User Datagram Protocol)는 인터넷 프로토콜 스택에서 전송 계층(Transport Layer, 4계층)에 해당하는 프로토콜이다. 두 프로토콜 모두 IP 위에서 동작하지만, 신뢰성과 속도 측면에서 명확히 다른 트레이드오프를 가진다.

---

TCP (Transmission Control Protocol)

핵심 특성

연결 지향(Connection-oriented)
데이터를 주고받기 전에 반드시 3-way handshake로 연결을 수립한다. 연결이 확립된 이후에야 데이터 전송이 시작된다.

신뢰성 보장

• 패킷이 손실되면 재전송(Retransmission)한다.
• 수신 측이 ACK(Acknowledgment)를 보내 패킷 수신을 확인한다.
• 패킷 순서가 뒤바뀌면 순서를 재조립한다.

흐름 제어(Flow Control)
수신 측 버퍼가 넘치지 않도록 송신 속도를 조절한다. 수신 윈도우(Receive Window) 크기를 기반으로 동작한다.

혼잡 제어(Congestion Control)
네트워크 혼잡 상황을 감지하면 송신 속도를 줄인다. 슬로우 스타트(Slow Start), AIMD(Additive Increase Multiplicative Decrease) 등의 알고리즘을 사용한다.

TCP 헤더 구조 (주요 필드)

Source Port (16bit) | Destination Port (16bit)
Sequence Number (32bit)
Acknowledgment Number (32bit)
Flags: SYN / ACK / FIN / RST / PSH / URG
Window Size (16bit)
Checksum (16bit)

총 헤더 크기는 최소 20바이트다.

---

UDP (User Datagram Protocol)

핵심 특성

비연결 지향(Connectionless)
연결 수립 과정 없이 바로 데이터를 전송한다. 수신 측이 준비됐는지 확인하지 않는다.

신뢰성 없음(Unreliable)

• 패킷 손실이 발생해도 재전송하지 않는다.
• 순서 보장이 없다.
• ACK를 기다리지 않는다.

낮은 오버헤드
헤더가 단순하고 제어 메커니즘이 없어 매우 빠르다.

UDP 헤더 구조

Source Port (16bit) | Destination Port (16bit)
Length (16bit)      | Checksum (16bit)

총 헤더 크기는 8바이트로 TCP보다 훨씬 작다.

---

TCP vs UDP 비교 정리

항목	TCP	UDP
연결 방식	연결 지향 (3-way handshake)	비연결 지향
신뢰성	보장 (재전송, ACK)	보장 안 함
순서 보장	보장	보장 안 함
흐름 제어	있음	없음
혼잡 제어	있음	없음
헤더 크기	최소 20바이트	8바이트
속도	상대적으로 느림	상대적으로 빠름
전송 단위	스트림(Stream)	데이터그램(Datagram)
사용 예	HTTP, FTP, SSH, SMTP	DNS, DHCP, 스트리밍, VoIP

---

각 프로토콜의 적합한 사용 사례

TCP를 써야 할 때

• 데이터 무결성이 중요한 경우: 파일 전송(FTP), 이메일(SMTP), 웹(HTTP/HTTPS)
• 순서가 중요한 경우: 원격 터미널(SSH, Telnet)
• 금융 거래, 데이터베이스 쿼리: 한 바이트라도 손실되면 안 되는 경우

UDP를 써야 할 때

• 지연 시간이 더 중요한 경우: 실시간 스트리밍, 온라인 게임, VoIP
• 짧은 요청-응답: DNS 쿼리 (패킷 하나로 완결되는 경우 TCP 연결 수립 오버헤드가 더 비쌈)
• 브로드캐스트/멀티캐스트: DHCP처럼 다수에게 동시에 보내야 하는 경우
• 약간의 손실을 허용하는 경우: 동영상 스트리밍에서 한두 프레임이 빠져도 사용자 경험에 크게 영향 없음

---

왜 DNS는 UDP를 쓰는가

DNS는 기본적으로 UDP 53번 포트를 사용한다. 쿼리 하나와 응답 하나로 완결되는 단순한 구조라서, TCP의 연결 수립(3-way handshake)과 해제(4-way handshake) 오버헤드가 낭비다.

단, 응답 데이터가 512바이트를 초과하거나(DNSSEC 등 확장 레코드), 존 전송(Zone Transfer, AXFR)처럼 대용량 데이터를 전송할 때는 TCP로 전환한다.

---

현대에서의 변화: QUIC

HTTP/3에서 사용하는 QUIC 프로토콜은 UDP 위에서 구현됐다. TCP의 신뢰성 보장(재전송, 순서 조립)을 애플리케이션 레벨에서 직접 구현하면서, TCP의 HOL(Head-of-Line) 블로킹 문제를 해결했다.

QUIC의 핵심 아이디어는 “TCP의 신뢰성을 챙기되, 커널이 아닌 애플리케이션에서 제어해 유연성을 높이자” 는 것이다. UDP를 기반으로 하기 때문에 OS 커널 업데이트 없이 프로토콜을 개선할 수 있다는 것도 장점이다.

---

소켓 프로그래밍 관점

TCP 소켓 흐름:

서버: socket() → bind() → listen() → accept() → recv/send() → close()
클라이언트: socket() → connect() → send/recv() → close()

UDP 소켓 흐름:

서버: socket() → bind() → recvfrom() → sendto()
클라이언트: socket() → sendto() → recvfrom()

UDP는 connect()가 없다. sendto()에 매번 목적지 주소를 지정해서 보낸다.

---

정리

TCP와 UDP의 선택은 결국 “신뢰성 vs 속도” 의 트레이드오프다.

• 데이터 하나라도 잃으면 안 된다 → TCP
• 조금 손실되더라도 빠른 전송이 더 중요하다 → UDP
• UDP 위에서 신뢰성이 필요하다 → 직접 구현하거나 QUIC 사용

실제로는 이 경계가 점점 흐려지고 있다. QUIC처럼 UDP 위에 신뢰성을 얹는 방식이 늘어나고 있고, HTTP/3의 표준화로 UDP 기반 통신이 더 보편화되고 있다.