TCP vs UDP 판단 기준

TCP는 빠진 데이터를 다시 보내고 순서를 맞춰 주지만 UDP는 그러지 않습니다. 그렇다면 언제나 TCP를 쓰는 편이 나을까요? 그렇지 않습니다. TCP의 보장에는 연결을 맺는 왕복, 재전송을 기다리는 지연, 한 바이트가 빠지면 뒤의 데이터까지 멈추는 성질 같은 대가가 따릅니다. 이 글에서는 두 프로토콜이 무엇을 주고 무엇을 받아 가는지 비교하고, 서비스의 요구에 맞춰 고르는 기준과 UDP 위에 필요한 기능만 더하는 방법을 살펴봅니다.

무엇을 보장받고 무엇을 지불하나

마지막 행은 실무에서 자주 잊습니다. 회사나 공공 와이파이의 방화벽 가운데는 DNS 말고는 UDP를 막는 곳이 있고, NAT 장비는 조용한 UDP 흐름의 정보를 TCP보다 훨씬 빨리 지웁니다. 그래서 UDP를 쓰는 서비스는 UDP가 막혔을 때 TCP나 HTTPS로 넘어가는 길을 함께 마련해 두는 경우가 많습니다.

사용 사례별 선택

DNS는 "조회는 UDP, 영역 전송은 TCP"로 외우기 쉽지만, 조회도 TCP를 지원해야 합니다. 응답이 UDP로 보내기에 너무 크면 서버는 잘렸다는 표시를 붙여 보내고, 클라이언트는 같은 질문을 TCP로 다시 합니다. DNSSEC 서명처럼 응답이 커지는 기능이 늘면서 이 경우가 많아졌습니다.

지연과 신뢰성의 저울

TCP의 재전송은 빠진 데이터를 메워 주지만 그만큼 기다리게 합니다. 더 큰 문제는 HOL 블로킹(head-of-line blocking)입니다. TCP는 바이트 스트림 하나를 순서대로 넘기므로, 중간의 세그먼트 하나가 빠지면 그 뒤에 이미 도착한 데이터도 빈 곳이 채워질 때까지 애플리케이션에 넘기지 못합니다. 영상 통화라면 프레임 하나가 빠졌다고 뒤의 프레임까지 모두 멈추는 셈이어서, 빠진 프레임은 건너뛰고 다음 프레임을 보여 주는 편이 사용자에게 훨씬 낫습니다.

판단의 핵심은 데이터마다 쓸모 있는 기한(deadline)이 있느냐입니다. 음성 통화는 한쪽 방향의 지연이 150ms를 넘지 않는 것이 좋다고 알려져 있는데, RTT가 120ms인 경로에서 빠진 패킷을 다시 받으려면 받는 쪽이 손실을 알아채고, 다시 보내 달라고 알리고, 재전송이 도착하기까지 적어도 한 번의 왕복이 더 듭니다. 이미 기한을 넘긴 데이터를 다시 받아 봐야 재생할 수 없으므로, 이런 서비스에는 재전송이 없는 UDP가 맞습니다. 반대로 파일은 아무리 늦어도 빠진 바이트가 있으면 안 되므로 기다려서라도 메워야 합니다.

• 데이터가 하나도 빠지면 안 되고 기다릴 수 있다면 TCP를 고릅니다.
• 늦게 온 데이터가 쓸모없다면 UDP를 고르고, 손실은 다음 데이터로 덮거나 건너뜁니다.
• 작은 질문과 답이고 다시 묻기가 쉽다면 UDP로 연결의 왕복을 아낄 수 있습니다.
• 순서와 완전성은 필요하지만 여러 흐름이 서로를 막지 않아야 한다면 QUIC을 검토합니다.
• UDP를 골랐다면 UDP가 막힌 망에서 TCP로 넘어가는 길을 함께 설계합니다.

UDP 위에 필요한 만큼 더하기

UDP를 고른 서비스도 일부 메시지는 반드시 전달되어야 하는 경우가 많습니다. 게임이라면 위치 정보는 곧 새 값이 오므로 잃어도 되지만, 아이템을 얻었다는 사건은 잃으면 안 됩니다. 이럴 때는 메시지마다 순번을 붙이고, 중요한 메시지에만 ACK를 받아 일정 시간 안에 ACK가 없으면 다시 보내는 기능을 애플리케이션이 직접 더합니다.

다음 코드는 그 구조를 보여 줍니다. 실제 소켓 대신 패킷을 상대에게 넘기는 함수를 바깥에서 받고, 시각도 인자로 넘겨서 손실 상황을 정해진 대로 재현합니다. check_retransmits()는 마지막 전송 뒤 0.5초가 지난 메시지를 다시 보내고, 세 번 다시 보내도 ACK가 없으면 포기합니다. 받는 쪽은 데이터를 받으면 ACK부터 보내고, dedupe가 켜져 있으면 이미 넘긴 순번을 다시 넘기지 않습니다.

import struct

RELIABLE, ACK = 1, 2

class ReliableUDP:
    def __init__(self, transport, dedupe=False, retry_interval=0.5, max_retries=3):
        self.transport = transport                       # 상대에게 패킷을 넘기는 함수
        self.dedupe = dedupe
        self.retry_interval = retry_interval
        self.max_retries = max_retries
        self.pending_acks = {}                           # seq -> (패킷, 마지막으로 보낸 시각, 재시도 횟수)
        self.seen = set()
        self.seq = 0

    def send_reliable(self, payload, now):
        self.seq += 1
        packet = struct.pack("!BI", RELIABLE, self.seq) + payload
        self.pending_acks[self.seq] = (packet, now, 0)
        self.transport(packet)

    def check_retransmits(self, now):
        for seq, (packet, sent_at, retries) in list(self.pending_acks.items()):
            if now - sent_at > self.retry_interval:
                if retries >= self.max_retries:
                    print(f"seq={seq} 포기: 재시도 {retries}번")
                    del self.pending_acks[seq]
                else:
                    self.pending_acks[seq] = (packet, now, retries + 1)
                    self.transport(packet)

    def receive(self, packet):
        kind, seq = struct.unpack("!BI", packet[:5])
        if kind == ACK:
            self.pending_acks.pop(seq, None)             # 확인된 순번은 대기 목록에서 지운다
            return None
        self.transport(struct.pack("!BI", ACK, seq))     # 데이터를 받으면 ACK부터 보낸다
        if self.dedupe:
            if seq in self.seen:
                return None                              # 이미 넘긴 순번은 다시 넘기지 않는다
            self.seen.add(seq)
        return packet[5:]

def run(dedupe, lost_acks, check_times):
    inventory, sends = [], 0

    def to_receiver(packet):                             # 보내는 쪽 → 받는 쪽
        nonlocal sends
        sends += 1
        payload = receiver.receive(packet)
        if payload is not None:
            inventory.append(payload.decode())           # 받은 사건마다 아이템을 하나 넣는다

    def to_sender(packet):                               # 받는 쪽 → 보내는 쪽(ACK)
        nonlocal lost_acks
        if lost_acks > 0:
            lost_acks -= 1                               # 이 ACK는 사라진다
        else:
            sender.receive(packet)

    sender = ReliableUDP(to_receiver)
    receiver = ReliableUDP(to_sender, dedupe=dedupe)
    sender.send_reliable(b"sword", now=0.0)
    for now in check_times:
        sender.check_retransmits(now)
    label = "중복 제거 있음" if dedupe else "중복 제거 없음"
    print(f"{label}: 전송 {sends}번, 인벤토리 {inventory}, 남은 대기 {list(sender.pending_acks)}")

run(False, lost_acks=1, check_times=[0.6])
run(True, lost_acks=1, check_times=[0.6])
run(True, lost_acks=99, check_times=[0.6, 1.2, 1.8, 2.4])

중복 제거 없음: 전송 2번, 인벤토리 ['sword', 'sword'], 남은 대기 []
중복 제거 있음: 전송 2번, 인벤토리 ['sword'], 남은 대기 []
seq=1 포기: 재시도 3번
중복 제거 있음: 전송 4번, 인벤토리 ['sword'], 남은 대기 []

첫 실행에서는 데이터는 잘 도착했는데 ACK만 사라졌습니다. 보내는 쪽은 상대가 받았는지 알 수 없으므로 0.6초에 같은 순번을 다시 보내고, 중복을 걸러 내지 않는 받는 쪽은 같은 사건을 두 번 넘겨 아이템이 두 개가 되었습니다. 두 번째 실행은 받는 쪽이 이미 본 순번을 기억해 두 번째 사건을 버렸습니다.

세 번째 실행은 ACK가 모두 사라지는 경우입니다. 처음 전송과 재시도 세 번으로 모두 네 번을 보낸 뒤, 2.4초의 검사에서 포기합니다. 그런데 인벤토리를 보면 받는 쪽은 처음부터 아이템을 받았습니다. 보내는 쪽이 포기했다는 것은 "전달되지 않았다"가 아니라 "전달되었는지 모른다"는 뜻입니다. 이런 결과를 다루려면 사건마다 고유한 요청 ID를 붙여 받는 쪽이 같은 요청을 한 번만 처리하게 하고, 결과가 불확실할 때 보내는 쪽이 처리 여부를 다시 물어볼 수 있게 해야 합니다. ACK도 받는 쪽 프로그램이 패킷을 받았다는 뜻일 뿐, 아이템 지급 같은 업무가 끝났다는 뜻은 아닙니다.

이 코드는 구조를 보여 주는 모형이어서 실제로 쓰려면 더 필요한 것이 많습니다. 보낸 쪽 주소를 확인하지 않으면 누구나 가짜 ACK를 보낼 수 있고, seen은 영원히 커지므로 최근 순번의 범위만 기억하는 방식으로 바꿔야 합니다. check_retransmits()를 주기적으로 부르는 타이머, 경로에 맞춘 재전송 간격, 많이 보낼 때의 혼잡 제어도 필요합니다. 게임 업계에서는 이런 기능을 갖춘 ENet 같은 라이브러리를 쓰거나, 입력을 보낼 때 최근 몇 개의 입력을 함께 실어 하나쯤 사라져도 다음 패킷으로 메우는 방식을 쓰기도 합니다. 범용으로 이 모든 것을 갖춘 것이 다음 글의 QUIC입니다.

더 깊이: UDP로 얼마나 자주 보내도 되나

UDP에는 혼잡 제어가 없으므로, 보내는 속도의 한도는 애플리케이션이 스스로 지켜야 합니다. RFC 8085(BCP 145)는 이 한도를 데이터의 양에 따라 나누어 권합니다. 많은 데이터를 보내는 애플리케이션은 TCP와 비슷한 윈도우 기반 혼잡 제어나 TFRC 같은 방식을 갖추어야 하고, 혼잡 제어가 없다면 경로가 심하게 막혔을 때 전송을 멈추는 회로 차단기(circuit breaker)라도 두어야 합니다.

본문의 게임 메시지처럼 데이터가 적은 애플리케이션에도 규칙이 있습니다. 한 목적지에 평균적으로 RTT마다 데이터그램 하나보다 많이 보내지 않아야 하고, RTT를 모르지만 손실은 알 수 있다면 처음 1초로 정한 간격을 손실이 날 때마다 지수적으로 늘려 가며 보낼 수 있습니다. 돌아오는 트래픽이 아예 없어 RTT를 잴 수 없다면 3초에 데이터그램 하나를 넘지 않게 합니다. 본문 코드가 0.5초라는 고정 간격으로 다시 보내는 것은 구조를 보여 주기 위한 단순화이며, 실제로 쓸 때는 잰 RTT에 맞춘 간격과 재시도마다 늘어나는 대기를 넣어야 합니다.

정리

• TCP는 손실 복구와 순서, 혼잡 제어를 주는 대신 연결의 왕복과 재전송의 대기, HOL 블로킹이라는 대가를 받습니다.
• UDP는 기다림 없이 보내고 메시지 경계를 지키지만, 손실과 순서, 혼잡 제어는 애플리케이션의 몫이고 UDP를 막는 망에 대비해야 합니다.
• 데이터에 쓸모 있는 기한이 있어 재전송이 그 기한 안에 올 수 없다면 UDP가, 늦더라도 빠짐없이 받아야 한다면 TCP가 맞습니다.
• UDP 위에 순번과 ACK, 재전송을 더하면 ACK가 사라졌을 때 중복이 생기므로 받는 쪽의 중복 제거가 필요하고, 재전송을 포기한 결과는 "모른다"로 다루어야 합니다.
• 주소 확인, 순번 범위 관리, 타이머, 혼잡 제어까지 직접 만들기보다 검증된 라이브러리나 QUIC을 먼저 검토합니다.

연습 문제

1. 서비스별 선택

다음 기능에 TCP와 UDP 가운데 무엇이 맞는지, 이유와 함께 고르세요. (가) 메신저의 대화 기록 동기화, (나) 화상 회의의 음성, (다) 초당 30번 보내는 게임 캐릭터의 위치, (라) 기기의 펌웨어 업데이트 내려받기.

2. 중복 제거 없이 ACK가 모두 사라지면

본문 코드에서 run(False, lost_acks=99, check_times=[0.6, 1.2, 1.8, 2.4])를 실행하면 몇 번 전송되고, 인벤토리에는 아이템이 몇 개 들어가나요? 마지막에 보내는 쪽은 이 메시지에 대해 무엇을 알고 있나요?

3. 재전송이 기한 안에 올 수 있을까

20ms마다 음성 패킷을 보내는 통화에서 한쪽 방향의 지연이 60ms이고, 패킷은 보낸 뒤 150ms 안에 도착해야 재생에 쓸 수 있다고 합시다. 받는 쪽은 다음 패킷이 도착했을 때 앞의 패킷이 빠졌다는 것을 알아채고 곧바로 재전송을 요청하며, 보내는 쪽도 요청을 받자마자 다시 보낸다면, 재전송된 패킷은 원래 보낸 시각으로부터 몇 ms 뒤에 도착하나요?

다음 글 QUIC과 전송 계층의 진화에서는 UDP 위에서 여러 스트림과 암호화, 손실 복구, 연결 이동을 함께 제공하는 QUIC이 TCP 기반 웹의 지연을 어떻게 줄이는지 살펴봅니다.