[하향식 접근 8판] Chapter 3 트랜스포트 계층 (3.3 비연결형 트랜스포트: UDP)

※"컴퓨터 네트워킹 하향식 접근 8판" 책을 간단하게 정리한 내용의 글입니다.※

3.3 절에서는 UDP가 어떻게 동작하고, 무엇을 하는지 자세히 살펴본다.

3.3 비연결형 트랜스포트: UDP

RFC 768에 정의된 UDP는 트랜스포트 계층 프로토콜이 할 수 있는 최소 기능으로 동작한다. 트랜스포트 계층은 네트워크 계층과 애플리케이션 계층 사이에서 다중화/역다중화를 필수적으로 수행해야 한다.

• UDP의 기능
  1. 다중화 / 역다중화
  2. 간단한 오류 검사 기능

애플리케이션 개발자가 TCP 대신 UDP를 선택한다면, 애플리케이션은 거의 IP와 직접 통신하는 것이다. UDP는 트랜스포트 계층 사이에 핸드셰이크를 하지 않는 비연결형이다.
UDP 사용하는 DNS와 같은 경우 목적지 서버로 질의를 보내고 중간에 분실될 수 있다. 이 경우 응답을 받지 못하고 송신 측 애플리케이션 다른 호스트로 다시 요청을 보내거나 응답을 수신할 수 없다고 할 것이다. 그런데도 왜 TCP대신에 UDP를 쓸까?

• TCP대신 UDP를 쓰는 이유

  • 실시간 애플리케이션 등에서 최소 전송률
    TCP는 혼잡 제어 메커님즘이 있어서 중간 링크가 혼잡해지면 송신이 제한될 수 있고, 목적지가 세그먼트 수신 여부를 응답할 때까지 데이터를 재송신하는 등의 추가적인 작업을 한다. 반면 UDP는 애플리케이션 프로세스가 UDP로 데이터를 전달하자마자 UDP 세그먼트로 만들고 즉시 네트워크 계층으로 전달한다. 그래서 애플리케이션이 최소 전송률을 요구하고, 조금의 데이터 손실은 허용되는 경우 UDP가 적합할 수 있다.
  • 연결 설정이 없음
    TCP의 경우 데이터를 전송하기 위해서 three-way handshake 과정이 필요하다. 반면 UDP는 공식적인 사전준비 없이 전송한다. 따라서 UDP는 연결을 설정하기 위한 어떤 지연도 없다. 대표적으로 DNS는 TCP의 연결 설정 지연을 피하기 위해 UDP에서 동작한다.
    구글의 크롬 브라우저의 QUIC 프로토콜은 웹 문서 다운로드의 지연을 줄이기 위해 기본 트랜스포트 프로토콜로 UDP를 사용하고, 안정성을 애플리케이션 계층 프로토콜에서 구현한다.
  • 연결 상태이 없음
    TCP와 다르게 UDP는 모든 메시지 송수신의 상태가 존재하지 않고 모든 요청은 독립적이다. 세션을 유지하거나 관리할 필요도 없다. 그렇기 때문에 TCP보다 UDP를 쓰면 좀 더 많은 액티브 클라이언트를 수용할 수 있다.
  • 패킷 헤더 오버헤드가 작음
    TCP는 세그먼트마다 20바이트의 헤더 오버헤드를 갖지만, UDP는 단지 8바이트의 헤더 오버헤드를 갖는다.

• UDP의 단점
  UDP는 TCP와 다르게 혼잡 제어를 하지 않는다.
  혼잡 제어를 하지 않기 때문에 앞서 말했듯이 빠른 전송이 더 중요한 경우에 TCP보다 더 적합한 프로토콜이 된다.
  하지만 혼잡 제어는 네트워크가 꼭 필요한 작업을 할 수 없게 되는 폭주 상태에 빠지는 것을 막기 위해 반드시 필요하다. 만약 모두가 혼잡 제어를 사용하지 않는다면 라우터에 많은 패킷 오버플로가 발생할 것이고, 소수의 UDP 패킷만이 무사히 전달될 것이다.
  또한 UDP 패킷으로 인해 혼잡도가 높아지면 TCP 송신자들이 속도를 줄이도록 할 것이다. 이는 TCP 연결의 송신율을 감소시킨다.
  즉, UDP의 혼잡 제어 결여는 UDP 통신의 높은 손실률을 초래할 수 있고, TCP 세션의 혼잡이 발생해서 송신율을 감소시킬 수 있다.

• UDP를 사용하면서 신뢰적 데이터 전송을 하는 방법
  UDP를 사용하면서 애플리케이션 계층에서 추가적인 신뢰성을 구현하면 가능하다. 이는 TCP의 혼잡 제어 메커니즘에 전송률을 억제당하지 않으면서 신뢰적으로 통신을 할 수 있게 해준다. 앞서 언급한 QUIC 프로토콜이 예시이다.

< 3.3.1 UDP 세그먼트 구조 >

UDP 세그먼트 구조는 위 그림과 같다.
아래 애플리케이션 데이터는 애플리케이션 계층에서 받은 데이터이다.
헤더에는 네 가지 필드가 각각 2바이트 씩 들어가고, 총 8바이트의 헤더를 갖는다.

출발지 포트번호, 목적지 포트번호가 있다.
길이 필드는 헤더를 포함하는 UDP 세그먼트의 길이(바이트 단위)이다.
체크섬 필드는 세그먼트에 오류가 발생했는지 검사하기 위한 필드이고, 수신 호스트가 사용한다.

< 3.3.2 UDP 체크섬 >

UDP 체크섬은 세그먼트가 출발지로부터 목적지로 이동했을 때, UDP 세그먼트 안의 비트에 대한 변경사항이 없는지 오류를 검출하기 위한 것이다.

• 체크섬을 구하는 방법
  UDP 세그먼트 안의 모든 16비트 워드를 합산한다. 오버플로는 윤회식 자리올림(wrap aroung)한다.
  그리고 그 결과에 대해 1의 보수를 수행한다.(1은 0으로 0은 1로 바꾸는 것)
  결과가 16비트가 나오게 되고, UDP 헤더에서 체크섬 또한 16비트를 차지한다.
• 수신 호스트가 UDP 체크섬으로 오류를 검출하는 방법
  수신 측에서는 체크섬을 포함한 모든 16비트 워드를 더한다.
  이때 오류가 없었다면 체크섬을 제외한 모든 것과 그 1의 보수(체크섬 값)을 더하는 것이기 때문에 11111111 11111111의 결과가 나오게 될 것이다. 하나라도 0이 있다면 패킷에 오류가 발생한 것이다.
• 다른 많은 링크 계층 프로토콜이 오류 검사를 제공하는데 UDP에서도 오류 검사를 제공하는 이유
  그 중간의 모든 링크가 오류 검사를 제공한다는 포장이 없기 때문이다. 오류 검사를 제공하지 않는 프로토콜을 사용하는 링크가 하나라도 있으면 세그먼트가 오류 없이 전달되었는지 확신할 수 없다.
  또한 모든 링크에서 정상적으로 전달되었어도 라우터의 메모리에 저장될 때 비트오류가 발생할 수 있다.
  
  종단과 종단의 원칙(end-end principle)의 예이다. UDP는 종단 기반으로 트랜스포트 계층에서 오류 검사를 제공해야만 한다. UDP는 종단 기반으로 구현되어야 하므로, '하위 레벨에 있는 기능들은 상위 레벨에서 이들을 제공하는 비용과 비교했을 때 중복되거나 거의 가치가 없을 수 있다'는 것이다.
  
  하지만 UDP는 오류 복구를 위한 어떤 것도 하지 않는다. 이 이상은 애플리케이션의 몫이다.