iBetter Books
수정

UDP — 신뢰성을 버린 대가

TCP가 그렇게 훌륭하다면 UDP는 왜 존재할까요. 이 의문에서 UDP 이해가 시작됩니다. UDP를 "덜 만들어진 프로토콜"로 보는 시각은 완전히 잘못됐습니다. UDP는 일부러 신뢰성을 뺐습니다. 그것이 무엇을 얻기 위한 선택이었는지 이해하면 UDP가 어디에 어울리는지 자연스럽게 보입니다.

UDP 헤더의 단순함

TCP 헤더는 최소 20바이트이고, 옵션까지 합치면 60바이트까지 늘어납니다. 안에는 순서 번호, 확인 번호, 윈도우 크기, 체크섬, 플래그 비트들이 빼곡히 들어갑니다.

UDP 헤더는 딱 8바이트입니다. 출발지 포트, 목적지 포트, 길이, 체크섬. 이게 전부입니다. 연결 상태를 관리하지 않고, 순서를 보장하지 않고, 재전송도 하지 않습니다. 그냥 던집니다.

버린 것과 얻은 것

TCP가 신뢰성을 보장하려면 운영체제가 상당한 일을 합니다. 연결 상태를 메모리에 유지하고, ACK를 기다리고, 타임아웃을 관리하고, 재전송을 처리하고, 순서를 재조립합니다. 이 모든 작업이 지연(latency)과 오버헤드를 만듭니다.

UDP는 이 모든 것을 생략합니다. 애플리케이션이 "보내라"고 하면 즉시 보냅니다. ACK도 기다리지 않습니다. 결과적으로 TCP보다 훨씬 빠르고 오버헤드가 작습니다. 한 가지를 버림으로써 속도와 단순함을 얻은 것입니다.

신뢰성은 필요한 곳에서 직접 구현

중요한 점은 UDP 위에서도 신뢰성이 필요하다면 애플리케이션이 직접 구현할 수 있다는 것입니다. TCP가 해주는 재전송과 순서 보장을, 자신의 요구사항에 딱 맞게 만들 수 있습니다. 덜 엄격하게, 또는 다른 방식으로.

예를 들어 화상통화에서 패킷 하나가 유실되면 어떻게 할까요. 재전송을 기다리면 이미 늦습니다. 그냥 그 프레임을 건너뛰거나, 앞뒤 프레임으로 보간하는 편이 낫습니다. 이런 판단은 애플리케이션이 직접 내려야 합니다. TCP는 무조건 재전송을 기다리므로 이런 선택이 불가능합니다.

UDP도 체크섬은 있다

"신뢰성이 없다"는 말이 오염된 데이터를 그대로 전달한다는 뜻은 아닙니다. UDP도 헤더에 체크섬이 있습니다. 수신 측에서 체크섬이 맞지 않으면 해당 패킷을 버립니다. 다만 버린 사실을 송신 측에 알리거나 재전송을 요청하지 않는다는 것입니다.

단순한 UDP가 어떤 상황에서 TCP보다 더 나은 선택인지는 다음 절에서 구체적으로 비교합니다.