TCP와 UDP의 개념 및 특징, 차이점, 활용사례, 분석방법

1. 전송계층에서 TCP와 UDP가 맡는 역할

TCP와 UDP는 모두 TCP/IP 스택의 전송계층에서 동작하며, 애플리케이션이 생성한 데이터를 IP 계층으로 넘기기 전에 프로세스 간 통신 단위로 정리하고 포트 기반 다중화를 제공하는 역할을 수행합니다. 전송계층의 핵심은 단순 전송이 아니라, 어떤 애플리케이션 요구사항을 어떤 통신 방식으로 만족시킬지 결정하는 데 있으며, TCP는 연결지향적 채널을, UDP는 데이터그램 기반 전달을 제공합니다.

즉, 두 프로토콜의 차이는 “데이터를 보내는가”의 차이가 아니라 “데이터를 어떤 제약과 보장 조건으로 보낼 것인가”의 차이로 이해하는 것이 정확합니다. 신뢰성, 순서 보장, 재전송, 흐름제어가 필요하면 TCP가 유리하고, 연결 수립 지연과 상태 관리 오버헤드를 줄이며 즉시 전송하는 특성이 중요하면 UDP가 유리합니다.

2. TCP의 구조적 원리

2-1. 연결지향성의 의미

TCP는 연결지향형 프로토콜로서 통신 전에 세션 상태를 만들고, 그 상태를 유지한 채 바이트 스트림을 연속적으로 전달합니다. 이 구조 때문에 송신자와 수신자는 시퀀스 번호, ACK, 윈도우 크기, 재전송 타이머 같은 상태 정보를 공유하며, 패킷 하나하나보다 “연결 전체의 일관성”을 관리합니다.

2-2. 3-way Handshake

TCP는 일반적으로 SYN, SYN-ACK, ACK의 3단계 절차를 통해 양측이 통신 가능 상태인지와 초기 시퀀스 동기화를 확인한 후 실제 데이터 전송을 시작합니다. 이 절차는 초기 지연을 유발하지만, 반대로 말하면 세션 성립 전부터 상대 상태를 검증하고 이후의 신뢰성 메커니즘을 작동시킬 토대를 만드는 과정입니다.

2-3. 신뢰성 보장의 실제 메커니즘

TCP의 신뢰성은 막연한 개념이 아니라 ACK, 재전송, 순서 제어, 체크섬 검증의 결합으로 구현됩니다. 송신 측은 보낸 세그먼트에 대해 ACK를 기다리고, 손실이나 타임아웃이 의심되면 재전송하며, 수신 측은 시퀀스 번호를 기준으로 원래 순서대로 데이터를 재조립합니다.

RFC 9293 기준으로 TCP 체크섬은 선택사항이 아니며, 송신자는 생성해야 하고 수신자는 반드시 검증해야 합니다. 즉, TCP의 신뢰성은 단순히 재전송만을 의미하는 것이 아니라, 손상 검출, 순서 복원, 중복 처리, 상태기반 복구가 결합된 종합 메커니즘입니다.

2-4. 흐름제어와 혼잡제어

TCP는 수신 측 처리 능력을 초과하지 않도록 흐름제어를 수행하고, 네트워크 전체 혼잡을 완화하기 위해 혼잡제어도 수행합니다. 이것이 중요한 이유는 빠른 송신이 항상 좋은 것이 아니라, 수신 버퍼 고갈이나 중간 네트워크 혼잡을 유발하면 전체 서비스 품질이 더 나빠질 수 있기 때문입니다.

예를 들어 Zero Window는 수신 측이 더 이상 받을 공간이 없음을 의미하며, Retransmission이나 DupACK 증가는 손실 또는 재정렬, 혼잡, 방화벽 간섭 같은 문제를 시사할 수 있습니다. 따라서 TCP는 단순히 “느리지만 안전한 프로토콜”이 아니라, 네트워크 상태에 반응하며 전송률을 조정하는 적응형 전송 제어 체계로 이해해야 합니다.

3. UDP의 구조적 원리

3-1. 비연결형 데이터그램 모델

UDP는 연결 설정 없이 메시지를 데이터그램 단위로 전달하는 프로토콜이며, 최소한의 메커니즘만 제공하도록 설계되었습니다. RFC 768은 UDP가 메시지를 최소한의 프로토콜 처리로 보내기 위한 절차를 제공하며, 전달 보장과 중복 보호를 제공하지 않는다고 명시합니다.

이 말은 UDP가 품질이 낮다는 뜻이 아니라, 전송 신뢰성의 상당 부분을 애플리케이션 또는 상위 프로토콜이 직접 책임지는 구조라는 뜻입니다. 따라서 UDP는 커널 전송계층의 개입이 적은 대신, 애플리케이션 설계가 더 정교해야 하는 프로토콜입니다.

3-2. 저오버헤드의 본질

UDP 헤더는 고정 8바이트로 매우 작으며, Source Port, Destination Port, Length, Checksum만 포함합니다. 반면 TCP 헤더는 일반적으로 20바이트 이상이며 옵션에 따라 더 커질 수 있으므로, UDP는 프로토콜 오버헤드 자체가 작고 연결 상태를 유지하지 않아 즉시 전송에 유리합니다.

이 차이는 짧은 메시지를 자주 보내는 실시간 시스템에서 체감 효과가 큽니다. 특히 음성, 게임, 실시간 이벤트 전파처럼 “몇 개 손실되더라도 지금 도착하는 정보”가 더 가치 있는 경우에는 UDP 구조가 매우 합리적입니다.

3-3. UDP가 빠른 이유와 한계

UDP는 연결 수립 대기, ACK 대기, 순서 복원, 재전송 관리가 전송계층에 없기 때문에 일반적으로 더 빠르고 지연이 낮습니다. 그러나 패킷 손실, 중복, 역순 도착이 발생해도 이를 기본적으로 수정하지 않으므로, 그대로 사용하면 애플리케이션 품질이 직접 흔들릴 수 있습니다.

4. 헤더 구조와 패킷 흐름 비교

헤더 차이는 단순한 바이트 수 차이를 넘어서, 프로토콜이 어디까지 책임질 것인가의 철학 차이를 반영합니다. TCP 헤더는 상태 추적과 제어를 위한 정보가 많고, UDP 헤더는 목적지 식별과 무결성 최소 확인에 집중하므로, 결과적으로 TCP는 네트워크 친화적 제어가 강하고 UDP는 애플리케이션 자율성이 큽니다.

5. TCP와 UDP의 핵심 차이

5-1. 성능과 지연

TCP는 연결 수립과 상태 유지, 재전송, ACK 처리 때문에 오버헤드가 존재하며, UDP는 이러한 절차가 적어 더 빠르고 효율적인 경향이 있습니다. 다만 실제 체감 성능은 네트워크 손실률, RTT, 애플리케이션 복구 로직, 방화벽 정책에 따라 달라지므로, 단순히 TCP는 느리고 UDP는 빠르다고 일반화하는 것은 불완전합니다.

5-2. 운영 자원 사용량

IBM 자료는 많은 동시 클라이언트를 처리하는 환경에서 TCP가 UDP보다 더 많은 OS 자원을 사용할 수 있으며, 확장성 측면에서 UDP가 강하게 선호될 수 있다고 설명합니다. 이는 연결 단위 상태와 타임아웃 관리, 소켓 자원 점유가 TCP 쪽에서 더 크게 작동할 수 있기 때문입니다.

5-3. 장애 복구와 예측 가능성

일반적으로 TCP는 신뢰적이지만, 일부 장애 상황에서는 OS가 연결 타임아웃을 오래 끌고 갈 수 있어 복구 시간이 길어질 수 있습니다. 반대로 UDP는 연결 상태가 없어 전송 자체는 단순하지만, 애플리케이션이 재시도 정책과 타임아웃 정책을 명확히 설계해야 안정적인 장애 복구가 가능합니다.

6. 서비스별 활용사례

6-1. 웹과 파일 다운로드

전통적인 웹 브라우징, 파일 다운로드, 이메일 같은 서비스는 데이터 손실 없이 순서가 유지되어야 하므로 TCP와 잘 맞습니다. 문서, 첨부파일, 트랜잭션 데이터는 일부라도 빠지거나 순서가 어긋나면 결과 자체가 훼손되므로, TCP의 재전송과 순서 보장이 실질적 가치가 됩니다.

6-2. DNS

DNS는 대표적으로 TCP와 UDP를 모두 사용하는 서비스입니다. 일반 질의는 빠른 응답을 위해 주로 UDP를 사용하지만, 존 전송은 데이터 일관성과 완전성이 중요하므로 TCP를 사용하며, 응답이 커서 UDP에서 잘리면 클라이언트가 TCP로 재시도할 수 있습니다.

6-3. 실시간 스트리밍과 음성/영상 통화

실시간 미디어는 모든 프레임의 완전 복구보다 재생 연속성과 지연 최소화가 더 중요하므로 UDP 기반 설계가 자주 사용됩니다. 늦게 도착한 음성 패킷은 정확하더라도 이미 재생 타이밍을 놓쳤기 때문에, 이런 영역에서는 “완전한 과거 데이터”보다 “지금 도착한 최신 데이터”가 더 가치 있습니다.

6-4. HTTP/3와 QUIC

최신 웹 전송의 중요한 예외가 QUIC 기반 HTTP/3이며, 이는 UDP 위에서 다중화 전송을 구현합니다. QUIC는 UDP 위에서 동작하지만, TLS 1.3 통합과 스트림 독립 처리로 TCP 수준의 단순 UDP보다 훨씬 높은 기능을 제공하며, HTTP/2의 TCP 수준 Head-of-Line Blocking 문제를 줄이도록 설계되었습니다.

다만 HTTP/3가 항상 절대적으로 우월한 것은 아니며, UDP 차단 환경에서는 TCP 기반 HTTP/2로 자동 폴백될 수 있고, CPU 오버헤드가 더 커질 수 있다는 점도 함께 봐야 합니다.

6-5. 온라인 게임

온라인 게임은 위치, 입력, 상태 갱신처럼 아주 짧고 빈번한 메시지를 다루므로 UDP가 자주 활용됩니다. 예를 들어 플레이어 좌표가 100ms 늦게 정확하게 도착하는 것보다, 일부 누락이 있더라도 20ms 안에 최신 좌표가 도착하는 것이 플레이 감각에는 더 유리합니다.

7. 패킷 캡처와 성능 측정 방법

7-1. Wireshark로 TCP 분석하기

Wireshark에서는 TCP의 시퀀스/ACK 분석 기능과 tcp.analysis.flags 필드를 통해 재전송, Fast Retransmission, DupACK, ZeroWindow, ZeroWindowProbe 같은 이벤트를 확인할 수 있습니다. 이 정보는 단순히 패킷이 보였다는 수준을 넘어서, 손실인지 지연인지 수신 측 병목인지, 혹은 중간 보안장비 개입인지 추정하는 데 매우 유용합니다.

예를 들어 Retransmission이 반복되면 패킷 손실, RTT 급증, 방화벽 드롭, MTU 문제를 의심할 수 있고, Zero Window가 지속되면 수신 애플리케이션 또는 서버 자원 부족을 먼저 의심하는 것이 일반적입니다. 또한 체크섬 오류는 실제 오류일 수도 있지만, NIC 오프로드에 의해 캡처 시점에만 잘못 보이는 경우도 있어 해석에 주의가 필요합니다.

7-2. UDP 분석 포인트

UDP는 전송계층 자체에 ACK와 재전송이 거의 없으므로, 분석 시에는 애플리케이션 레벨 시퀀스, RTP 시퀀스, 지터, 손실률, 서버 응답 간격, 방화벽 정책을 함께 봐야 합니다. 즉, UDP 문제 분석은 “UDP 패킷이 보인다/안 보인다”에서 끝나지 않고, 상위 프로토콜이 어떤 복구 전략을 쓰는지까지 포함해야 정확합니다.

7-3. iperf3로 측정하기

iperf3는 TCP, UDP, SCTP 처리량 측정을 지원하며, UDP 테스트를 수행하더라도 제어 연결은 TCP를 사용합니다. 즉, iperf3 결과를 볼 때는 데이터 평면과 제어 평면이 다른 프로토콜일 수 있다는 점을 이해해야 합니다.

TCP 측정에서는 처리량과 재전송, 윈도우 변화가 중요하고, UDP 측정에서는 설정한 대역폭 대비 실제 수신률, 지터, 손실률이 중요합니다. 따라서 네트워크 진단 시 “속도만 빠른가”보다 “손실 없이 안정적인가, 지연 변동이 작은가”를 함께 봐야 합니다.

8. 장애 분석 시나리오와 프로토콜 선택 기준

8-1. 사례 1: 웹 서비스가 느리지만 끊기지는 않는 경우

이 경우 TCP 재전송, DupACK, Window Size 축소, RTT 증가를 먼저 살펴보는 것이 효과적입니다. 원인은 회선 손실, 중간 방화벽, MTU 불일치, 서버 수신 버퍼 압박일 수 있으며, 증상은 모두 “연결은 되지만 체감 성능이 나쁜 상태”로 나타날 수 있습니다.

8-2. 사례 2: 실시간 음성 품질이 순간적으로 깨지는 경우

UDP 기반 실시간 서비스에서는 지터 증가, 일시적 손실, 무선 구간 품질 저하, QoS 미적용이 주요 원인일 수 있습니다. 이때 단순 재전송보다 버퍼링 정책, 패킷 간격, 회선 품질, 우선순위 제어가 더 중요한 개선 포인트가 됩니다.

8-3. 사례 3: DNS는 되다가 일부 요청만 실패하는 경우

일반 질의는 UDP로 정상 처리되지만 큰 응답에서 잘림이 발생하면 TCP 재시도가 필요하므로, 방화벽이 TCP/53을 막고 있으면 일부 요청만 실패할 수 있습니다. 특히 DNSSEC, 큰 레코드셋, 존 전송 환경에서는 TCP 허용 정책을 누락하지 않는 것이 중요합니다.