HTTP나 JSON-RPC 같은 프로토콜은 “무슨 메시지를 주고받을지"를 정한다. 하지만 그 메시지를 실제로 상대에게 실어 나르는 일은 더 아래 계층이 맡는다. 이를 전송 계층(transport layer)이라 한다. 인터넷에서 이 역할을 하는 대표 주자가 TCP와 UDP이고, 그 한계를 넘으려고 등장한 것이 QUIC이다. 위에 어떤 프로토콜을 얹든 결국 이 셋 중 하나를 타고 흐른다.
TCP — 느려도 확실하게
TCP는 Transmission Control Protocol의 약자다. 데이터가 빠짐없이, 보낸 순서대로, 정확히 도착하는 것을 보장하는 연결형 프로토콜이다.
통신을 시작하기 전에 양쪽이 연결을 맺는다. 이 과정을 3-way handshake라 한다. 클라이언트가 “연결하자(SYN)“고 보내면 서버가 “좋다, 나도 준비됐다(SYN+ACK)“고 답하고, 클라이언트가 “확인했다(ACK)“고 마무리하는 세 번의 왕복이다. 연결이 맺어진 뒤에는 받은 쪽이 매번 “잘 받았다(ACK)“고 응답하고, 정해진 시간 안에 응답이 없으면 보낸 쪽이 다시 보낸다. 이 재전송이 유실을 복구한다. 또한 패킷마다 순서 번호가 붙어 있어, 도착 순서가 뒤섞여도 받는 쪽이 원래 순서로 재조립한다.
대가는 지연이다. 연결을 맺느라 왕복이 필요하고, 응답을 기다리느라 시간이 든다. 더 미묘한 약점은 머리 막힘(Head-of-Line blocking)이다. TCP는 하나의 연결로 모든 데이터를 한 줄로 흘려보내기 때문에, 앞쪽 패킷 하나가 유실되면 뒤따르는 패킷들이 멀쩡히 도착했더라도 그 하나가 재전송될 때까지 전부 대기해야 한다. 한 차선뿐인 도로에서 맨 앞 차가 멈추면 뒤차가 모두 막히는 것과 같다.
정확성이 중요한 거의 모든 곳이 TCP를 쓴다. 웹(HTTP/1.1과 HTTP/2), 메일, 파일 전송이 그렇다.
UDP — 빠르게, 일단 던진다
UDP는 User Datagram Protocol의 약자다. TCP와 정반대로, 연결을 맺지 않고 도착도 순서도 보장하지 않는다. 데이터그램(datagram)이라 부르는 작은 덩어리를 목적지로 그냥 쏘기만 한다.
연결 절차가 없으니 즉시 보낼 수 있고, 재전송이나 순서 재조립 같은 부담이 없어 가볍고 빠르다. 대신 유실되어도 알아채지 못하고, 순서가 뒤섞여도 바로잡지 않는다. 신뢰성이 필요하면 그 일을 애플리케이션이 직접 떠안아야 한다.
이 성격은 정확성보다 실시간성이 중요한 곳에 맞는다. 음성·화상 통화나 게임에서는 한두 프레임이 깨지더라도 그걸 다시 받느라 늦어지는 것보다 그냥 넘기고 다음 데이터를 받는 편이 낫다. 짧은 질의와 응답이 오가는 DNS도, 매번 연결을 맺을 이유가 없어 UDP를 쓴다.
QUIC — UDP의 속도에 TCP의 신뢰성을 다시 얹다
QUIC은 TCP의 한계를 넘으려고 만들어진 프로토콜이다. 흥미로운 점은 그것을 TCP를 고쳐서가 아니라 UDP 위에 새로 쌓아 올려 해결했다는 것이다. TCP는 운영체제 커널과 중간 장비(라우터, 방화벽)에 깊이 박혀 있어 새 기능을 넣으려면 인터넷 전체를 업데이트해야 하므로 사실상 진화가 막혀 있다. 반면 UDP는 단순하고 어디서나 통과되므로, 그 위에서 새 전송 프로토콜을 애플리케이션 레벨로 자유롭게 구현할 수 있다. QUIC은 UDP가 보장하지 않는 재전송, 순서, 혼잡 제어를 스스로 구현해 신뢰성을 되찾는다.
QUIC이 해결한 TCP의 약점은 세 가지다.
첫째, 연결 수립이 빠르다. TCP는 연결을 맺는 handshake와 암호화를 위한 TLS handshake가 따로라 왕복이 여러 번 필요하다. QUIC은 이 둘을 하나로 합쳐 한 번의 왕복(1-RTT)에 끝내고, 한 번 연결했던 상대라면 왕복 없이(0-RTT) 바로 데이터를 보낼 수도 있다.
둘째, 머리 막힘이 없다. QUIC은 하나의 연결 안에 서로 독립적인 여러 스트림(stream)을 둔다. 한 스트림에서 패킷이 유실되어도 다른 스트림은 영향받지 않고 계속 흐른다. 한 차선 도로를 여러 차선으로 나눈 셈이다.
셋째, 연결이 잘 끊기지 않는다. TCP 연결은 IP 주소로 식별되므로 Wi-Fi에서 LTE로 네트워크가 바뀌면 끊긴다. QUIC은 연결을 Connection ID라는 별도 식별자로 추적해, 네트워크가 바뀌어도 연결을 유지한다.
또한 QUIC은 TLS 1.3 암호화를 내장한다. TCP에서는 암호화가 선택이지만 QUIC에서는 통신 자체에 포함된다. 이 QUIC을 전송 계층으로 삼는 것이 HTTP/3다.
셋을 어떻게 고르나
| TCP | UDP | QUIC | |
|---|---|---|---|
| 연결 | handshake 필요 | 없음 | 빠른 handshake (0–1 RTT) |
| 신뢰성·순서 | 보장 | 보장 안 함 | 보장 (스트림 단위) |
| 머리 막힘 | 있음 | 해당 없음 | 없음 |
| 기반 | IP 위 | IP 위 | UDP 위 |
| 암호화 | 별도(TLS) | 별도 | 내장(TLS 1.3) |
| 대표 용도 | 웹, 메일, 파일전송 | 스트리밍, DNS, 게임 | HTTP/3 |
계층으로 그리면 위에 무엇을 얹느냐에 따라 스택이 달라진다. HTTP/1.1과 HTTP/2는 TCP 위에, HTTP/3는 QUIC 위에, 그 QUIC은 다시 UDP 위에 얹힌다. DNS나 게임은 UDP를 직접 쓴다.
선택의 기준은 단순하다. 데이터가 정확해야 하면 TCP, 약간의 유실을 감수하더라도 빨라야 하면 UDP다. QUIC은 둘의 장점을 모으려는 시도이고, 그 대가로 UDP 위에 신뢰성 계층을 직접 구현하는 복잡성을 떠안았다. 새 웹 트래픽은 점점 QUIC으로 옮겨가고 있지만, 보편성과 성숙도에서는 여전히 TCP와 UDP가 기본값이다.