TCP와 UDP, 언제 무엇을

TCP와 UDP의 차이를 표로 정리해봅니다. 그 다음이 더 중요합니다. 표의 숫자를 외우는 것이 아니라, 실제 서비스들이 왜 그 프로토콜을 선택했는지 설계 관점으로 이해해야 합니다.

TCP와 UDP 비교

웹과 파일 전송 — TCP

웹 페이지 하나를 받는 데 글자 몇 개가 빠지거나 순서가 뒤바뀐다면 어떻게 될까요. 이미지가 깨지거나 JavaScript가 실행되지 않아 페이지가 망가집니다. 파일 다운로드에서 데이터 일부가 사라지면 파일이 손상됩니다. 신뢰성이 절대적으로 필요한 경우입니다.

이런 서비스들은 TCP를 씁니다. 좀 느려도 됩니다. 정확하게 도착하는 것이 먼저입니다. HTTP, HTTPS, FTP, SMTP, SSH가 모두 TCP 기반입니다.

DNS — UDP

DNS는 도메인 이름을 IP 주소로 바꾸는 서비스입니다. 질문 하나에 응답 하나입니다. 패킷이 딱 두 개면 됩니다. 이런 짧은 교환에서 TCP처럼 연결을 맺고(3-way), 끊는(4-way) 오버헤드는 실제 데이터보다 훨씬 큽니다.

UDP로 질문을 던지고 응답을 기다립니다. 응답이 안 오면 애플리케이션이 타임아웃 후 다시 묻습니다. 간단합니다. DNS가 빠른 이유의 일부가 여기 있습니다. 단, 응답이 512바이트를 초과하는 경우나 영역 전송(Zone Transfer) 같은 대량 데이터 교환에는 TCP를 씁니다.

음성통화와 화상회의 — UDP

실시간 음성·영상 통화에서는 지연이 가장 치명적입니다. 패킷 하나가 사라졌다고 TCP처럼 재전송을 기다리면 이미 수백 밀리초가 흘렀습니다. 그 시간이면 통화 흐름이 끊기고 상대방 음성이 뚝뚝 끊겨 들립니다.

차라리 그 프레임을 건너뛰거나, 직전 프레임을 조금 늘려서 채우는 편이 낫습니다. 이런 판단을 애플리케이션이 직접 내릴 수 있도록 UDP 위에 구현합니다. RTP(Real-time Transport Protocol)가 대표적입니다. UDP 위에 순서 번호와 타임스탬프를 추가하되, 재전송 대신 누락 감지와 보간을 선택합니다.

실시간 게임 — UDP

온라인 게임에서 내 캐릭터 위치를 서버에 보내는 패킷이 사라지면 어떻게 할까요. 재전송을 기다리는 동안 서버는 내 캐릭터가 어디 있는지 모릅니다. 그 틈에 50ms가 지나 새 위치 패킷이 도착합니다. 오래된 재전송 패킷을 받아서 위치를 되돌리는 것은 의미 없습니다.

게임은 최신 상태가 중요합니다. 낡은 패킷은 버립니다. UDP를 써서 최대한 빨리 보내고, 누락된 것은 무시하거나 예측으로 보완합니다. FPS 게임의 부드러운 움직임이 이런 설계 덕분입니다.

영상 스트리밍 — 상황에 따라 다름

유튜브 같은 VOD 스트리밍은 실시간이 아닙니다. 미리 버퍼에 담아두므로 약간의 재전송 지연이 허용됩니다. 이런 경우 HTTP(TCP) 위의 DASH나 HLS를 씁니다. 반면 실시간 방송이나 WebRTC 기반 통화는 UDP를 씁니다. 같은 영상이라도 목적에 따라 프로토콜 선택이 달라집니다.

다음 절에서는 UDP가 어울리는 환경들을 조금 더 살펴봅니다.