TCP/UDP 차이와 신뢰성

TCP와 UDP는 전송 계층 프로토콜이다. IP가 데이터를 어디로 보낼지 결정한다면, TCP와 UDP는 어떻게 보낼지를 결정한다. 둘의 가장 큰 차이는 신뢰성(Reliability)이다. TCP는 연결을 보장하고, 실패하면 알려주며, 패킷의 순서와 재전송을 보장한다.

계층 안에서의 위치

두 프로토콜이 어느 계층에 있는지부터 확인한다.

상위 계층은 바로 아래 계층이 제공하는 서비스를 이용한다. ‘HTTP가 TCP 위에서 동작한다’는 말이 바로 이 의미다.

[ HTTP ]     ← 무엇을 주고받을지 (내용과 형식)
    ↓
[ TCP ]      ← 손실 없이 순서대로 운반
    ↓
[ IP ]       ← 길 찾기
    ↓
[ Ethernet ] ← 실제 신호 전송

HTTP는 무엇을 주고받을지를 정의하고, TCP는 그 데이터를 신뢰성 있게 전달하는 방법을 담당한다.

참고: 소켓은 어디에 있을까?

소켓은 TCP/IP 계층의 일부가 아니다. 애플리케이션이 TCP나 UDP를 사용할 수 있도록 운영체제가 제공하는 API다. HTTP는 소켓 위에서 동작한다. 반대로 소켓 통신은 HTTP 같은 응용 계층 프로토콜 없이 TCP나 UDP를 직접 사용하는 방식을 말한다.

TCP가 신뢰성을 보장하는 방식

연결 보장

데이터를 보내기 전에 3-way handshake로 논리적 연결을 먼저 수립한다.

SYN     →   연결 요청
        ←   SYN/ACK  연결 수락 + 확인
ACK     →   확인 응답

연결에 실패하면 애플리케이션은 연결 실패를 알 수 있다. 연결 종료는 4-way handshake(FIN → ACK → FIN → ACK)로 처리한다.

패킷 순서 보장과 재전송

송신한 데이터를 세그먼트 단위로 나누고 각각에 일련번호를 부여한다. 수신 측은 이 번호로 순서를 정렬하고 누락을 감지한다.

99번 다음에 101번이 도착했다면 그 구간을 다시 요청해 채운다. 순서 보장과 재전송이 함께 동작하는 지점이다.

UDP가 신뢰성을 보장하지 못하는 이유

UDP도 패킷에 출발지와 목적지의 IP, 포트를 명시한다. 어디로 보낼지는 명확하다. 하지만 중간에서 패킷이 손실되었을 때 상대방이 받았는지 확인할 방법이 없다. ACK 같은 확인 응답 메커니즘이 프로토콜에 없기 때문이다.

헤더 구조를 보면 차이가 드러난다

신뢰성의 차이는 헤더에 그대로 나타난다.

TCP 헤더 (20바이트 이상)

UDP 헤더 (8바이트 고정)

UDP 헤더에는 순번도, 확인 응답도, 제어 플래그도 없다. 신뢰성을 보장할 수단 자체가 존재하지 않는다. 대신 헤더가 가볍다.

흐름 제어와 혼잡 제어

TCP는 두 가지 기준으로 전송 속도를 조절한다. 둘은 제어 대상이 다르다.

• 흐름 제어(Flow Control): 송신자가 수신자의 수용 능력을 넘어서지 않도록 속도를 조절한다. 수신자가 자신의 버퍼 크기를 알려주는 Sliding Window 방식이 대표적이다.

• 혼잡 제어(Congestion Control): 네트워크 자체의 혼잡 상황에 따라 속도를 조절한다. Slow Start, Congestion Avoidance, Fast Retransmit, Fast Recovery 같은 알고리즘이 쓰인다.

지수 백오프

TCP의 재전송에는 지수 백오프(Exponential Backoff)가 적용된다. 재시도 간격을 2배씩 늘려가는 방식이다.

1초 → 실패 → 2초 → 실패 → 4초 → 8초 → 16초 → 32초 ...

실패가 반복될수록 간격을 벌려 네트워크에 추가 부하를 주지 않는다. 이 패턴은 TCP 밖에서도 널리 쓰인다. Kafka, RabbitMQ 같은 메시징 시스템, 클라이언트와 서버 사이의 재시도 로직이 대부분 이 구조를 따른다. 재시도 로직을 설계할 때 TCP의 처리 방식을 참고할 수 있다.

언제 무엇을 쓰는가

• TCP: 데이터 손실이나 순서가 중요한 경우. 웹 통신(HTTP), 파일 전송, 이메일, DB 프로토콜

• UDP: 속도가 우선이고 일부 손실을 감당할 수 있는 경우. 실시간 스트리밍, 게임, DNS, VoIP

HTTP/3와 QUIC

지금까지 설명만 보면 UDP는 스트리밍과 게임, TCP는 일반 웹에서 사용하는 것처럼 보인다. 그런데 HTTP/3는 UDP 위에서 동작한다.

HTTP/3는 2022년 6월 RFC 9114로 표준에 등재되었다. 그 기반 프로토콜이 QUIC(Quick UDP Internet Connections)이다. Google이 2012년경 개발을 시작해 IETF 표준화를 거쳐 RFC 9000(2021년 5월)이 되었다. 표준 등재 이전부터 Instagram, Facebook, Akamai 같은 플랫폼과 CDN에서 이미 사용하고 있었다.

QUIC이 UDP 위에서 신뢰성을 구현하는 방식

UDP는 연결성, 순서, 재전송을 보장하지 않는다. QUIC은 그 기능들을 자신의 프로토콜 레벨에서 직접 구현한다. 순서번호, ACK, 재전송, 흐름 제어, 혼잡 제어를 모두 갖췄다. TCP가 커널에서 하던 일을 QUIC이 유저 공간에서 수행한다.

QUIC의 장점

• 빠른 연결 설정: TCP + TLS 조합은 연결 수립에 여러 번의 왕복(RTT)이 필요하다. QUIC은 연결 수립과 암호화를 함께 처리해 1-RTT 또는 0-RTT로 끝낸다.

• Head-of-Line Blocking 완화: TCP는 하나의 연결에서 앞 패킷이 손실되면 뒤 패킷들도 대기해야 한다. QUIC은 스트림 단위로 독립 전송하므로 한 스트림의 손실이 다른 스트림을 막지 않는다. 여러 리소스를 동시에 내려받는 웹 환경에서 효과가 크다.

• 연결 마이그레이션: Connection ID로 연결을 식별한다. IP가 바뀌어도 연결이 유지되므로 Wi-Fi에서 LTE로 전환해도 통신이 끊기지 않는다.

• 기본 암호화: TLS 1.3이 프로토콜에 내장되어 있다. 선택이 아니라 의무다.

• 빠른 진화: 운영체제 커널이 아닌 유저 공간에서 동작하므로 업데이트가 빠르다. TCP는 커널 수준이라 변경이 느리다.

정리

QUIC은 UDP의 한계를 애플리케이션 계층에서 보완한다. 즉, UDP의 낮은 신뢰성은 프로토콜 자체의 한계라기보다 프로토콜 설계상의 선택이었다는 점을 보여준다.