계층 안에서의 위치TCP가 신뢰성을 보장하는 방식연결 보장패킷 순서 보장과 재전송UDP가 신뢰성을 보장하지 못하는 이유헤더 구조를 보면 차이가 드러난다흐름 제어와 혼잡 제어지수 백오프언제 무엇을 쓰는가HTTP/3와 QUIC - UDP의 한계를 다시 보기QUIC이 UDP 위에서 신뢰성을 구현하는 방식QUIC의 장점정리
TCP와 UDP는 전송 계층 프로토콜이다. IP가 데이터를 "어디로 보낼지" 결정한다면, 전송 프로토콜은 "어떻게 보낼지"를 결정한다.
두 프로토콜의 차이를 "TCP는 정확하고 UDP는 빠르다"로 정리하지만, TCP를 설명하는 키워드로는 정확성보다 신뢰성(Reliability)이 정확하다. 연결을 보장하고, 실패하면 알려주고, 패킷의 순서와 재전송을 보장한다는 의미가 모두 담기기 때문이다.
계층 안에서의 위치
두 프로토콜이 어느 계층에 있는지부터 확인한다.
계층 | 역할 | 대표 프로토콜 |
응용 계층 (Application) | 데이터의 형식과 규칙 | HTTP, HTTPS, WebSocket, gRPC, DNS |
전송 계층 (Transport) | 데이터를 어떻게 운반할지 | TCP, UDP |
인터넷 계층 (Internet) | 어디로 보낼지 (주소와 경로) | IP |
네트워크 접근 계층 | 실제 물리적 전송 | Ethernet, Wi-Fi |
위 계층이 아래 계층을 도구처럼 사용한다. "HTTP는 TCP 위에서 동작한다"는 말이 의미하는 바다.
[ HTTP ] ← 무엇을 주고받을지 (내용과 형식) ↓ [ TCP ] ← 손실 없이 순서대로 운반 ↓ [ IP ] ← 길 찾기 ↓ [ Ethernet ] ← 실제 신호 전송
HTTP는 "무엇을" 주고받을지만 정하고, 안전하게 운반하는 일은 아래의 TCP에 맡긴다.
소켓은 이 계층 어디에도 속하지 않는다. 프로그램이 TCP나 UDP를 사용하도록 운영체제가 열어주는 창구(API)다. 소켓 통신은 HTTP 같은 고수준 프로토콜 없이 소켓 API로 TCP·UDP를 직접 다루는 방식을 가리킨다.
TCP가 신뢰성을 보장하는 방식
연결 보장
데이터를 보내기 전에 3-way handshake로 논리적 연결을 먼저 수립한다.
SYN → 연결 요청 ← SYN/ACK 연결 수락 + 확인 ACK → 확인 응답
연결이 성립되지 않으면 에러를 돌려받는다. 연결 종료는 4-way handshake(FIN → ACK → FIN → ACK)로 처리한다.
패킷 순서 보장과 재전송
애플리케이션이 보내는 데이터를 세그먼트 단위로 나누고 각각에 일련번호를 부여한다. 수신 측은 이 번호로 순서를 정렬하고 누락을 감지한다.
108번까지 도착했는데 100번이 비어 있다면 그 구간을 다시 요청해 채운다. 순서 보장과 재전송이 함께 동작하는 지점이다.
UDP가 신뢰성을 보장하지 못하는 이유
UDP도 패킷에 출발지와 목적지의 IP, 포트를 명시한다. 어디로 보낼지는 명확하다. 하지만 중간에서 패킷이 손실되었을 때 상대방이 받았는지 확인할 방법이 없다. 확인 응답 자체가 프로토콜에 없기 때문이다.
헤더 구조를 보면 차이가 드러난다
신뢰성의 차이는 헤더에 그대로 나타난다.
TCP 헤더 (20바이트 이상)
필드 | 역할 |
Source / Destination Port | 출발지 포트, 목적지 포트 |
Sequence Number | 패킷 순서 보장을 위한 순번 |
Acknowledgment Number | 다음에 받기를 기대하는 순번 (수신 확인) |
Flags | SYN, ACK, FIN, RST 등 제어 플래그 |
Window Size | 흐름 제어용 수신 가능 크기 |
Checksum | 데이터 무결성 검증 |
UDP 헤더 (8바이트 고정)
필드 | 역할 |
Source / Destination Port | 출발지 포트, 목적지 포트 |
Length | 길이 |
Checksum | 데이터 무결성 검증 |
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 밖에서도 널리 쓰인다. 메시징 플랫폼의 재전송 로직, 클라이언트와 서버 사이의 재시도 로직이 대부분 이 구조를 따른다. 재시도 로직을 설계할 때 TCP의 처리 방식을 참고할 수 있다.
언제 무엇을 쓰는가
- TCP: 데이터 손실이나 순서가 중요한 경우. 웹 통신(HTTP), 파일 전송, 이메일, DB 프로토콜.
- UDP: 속도가 우선이고 일부 손실을 감당할 수 있는 경우. 실시간 스트리밍, 게임, DNS, VoIP.
HTTP/3와 QUIC - UDP의 한계를 다시 보기
위 기준대로면 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의 낮은 신뢰성이 극복 불가능한 한계가 아니라 프로토콜 설계의 선택이었음을 보여준다.
"UDP는 스트리밍과 게임용, TCP는 일반 웹"이라는 구분은 경계가 흐려지고 있다.