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

UDP가 어떻게 동작하고 무엇을 하는지에 대해 살펴본다.

트랜스포트 프로토콜 설계에 관심이 있다는 가정

• 아무 일도 하지 않는 트랜스포트 프로토콜을 사용하는 것을 고려가능
• 송신 측에서 애플리케이션 프로세스로부터 메시지를 얻어서 네트워크 계층에 직접 넘겨주는 것
• 수신 측에서 네트워크 계층으로부터 도착한 메시지를 애플리케이션 프로세스로 직접 넘겨주는 것도 생각할 수 잇음.

but, 최소한의 동작은 수행해야 함 .

적어도 트랜스포트 계층은 네트워크 계층과 해당하는 애플리케이션 레벨 프로세스 간의 데이터를 넘겨주기 위해 다중화와 역다중화 서비스를 제공해야 함.

[RFC 768]에서 정의된 UDP는 트랜스포트 계층 프로토콜이 할 수 있는 최소 기능으로 동작함. UDP는 다중화/역다중화 기능과 간단한 오류 검사 기능을 제외하면 IP에 아무것도 추가하지 않음.

애플리케이션 개발자가 TCP 대신 UDP를 선택한다면 애플리케이션은 거의 IP와 직접 통신하는 셈임.

• UDP는 애플리케이션 프로세스로부터 메시지를 가져와서 다중화/역다중화 서비스에 대한 출발지 포트 번호 필드와 목적지 포트 번호 필드를 첨부하고 다른 두 필드를 추가한 후에 최종 세그먼트를 네트워크 계층으로 넘겨줌.
• 네트워크 계층은 트랜스포트 계층 세그먼트를 IP 데이터그램으로 캡슐화하고, 세그먼트를 수신 호스트에게 전달하기 위해 최선을 다함.
  • IF, 세그먼트가 수신 호스트에 도착한다면, UDP는 세그먼트의 데이터를 해당하는 애플리케이션 프로세스로 전달하기 위해 목적지 포트 번호를 사용함.
• UDP는 세그먼트를 송신하기 전에 송신 트랜스포트 계층 개체들과 수신 트랜스포트 계층 개체들 사이에 핸드셰이크를 사용하지 않는다는 점을 주의해야함. ⇒ UDP를 비연결형이라고 함

애플리케이션 개발자가 TCP보다 UDP 방식으로의 개발을 선호하는 이유(많은 애플리케이션이 UDP에 적합한 이유)

• 무슨 데이터를 언제 보낼지에 대해 애플리케이션 레벨에서 더 정교한 제어
  • UDP 하에서 애플리케이션 프로세스가 데이터를 UDP에게 전달하자마자 UDP는 데이터를 UDP 세그먼트로 만들고, 그 세그먼트를 즉시 네트워크 계층으로 전달함.
  • TCP는 혼잡 제어 메커니즘을 갖고 있는데, 이 메커니즘은 목적지 호스트들과 출발지 호스트들 사이에서 하나 이상의 링크가 과도하게 혼잡해지면, 트랜스포트 계층 TCP 송신자를 제한함.
  • TCP는 신뢰적인 전달이 얼마나 오래 걸리는지에 관계없이 목적지가 세그먼트의 수신 여부를 확인응답할 때까지 데이터의 세그먼트 재전송을 계속할 것임.
  • 실시간 애플리케이션은 최소 전송률을 요구할 때도 있고, 지나치게 지연되는 세그먼트 전송을 원하지 않으며, 조금의 데이터 손실은 허용할 수도 있으므로, TCP의 서비스 모델은 이러한 애플리케이션의 요구와는 맞지 않음.
• 연결 설정이 없음.
  • TCP는 데이터 전송을 시작하기 전 세 방향 핸드셰이크를 사용함. UDP는 공식적인 사전준비 없이 바로 전송함. ⇒ UDP는 연결을 설정하기 위한 어떠한 지연도 없음.
  • HTTP 문서로 된 웹 페이지는 신뢰성이 중요하기 때문에 UDP 보다는 TCP를 사용함.
    • HTTP에서 TCP 연결 설정 지연은 웹 문서 다운로드 지연의 심각한 원인임. 구글 크롬에서 사용되는 QUIC 프로토콜은 기본 트랜스포트 프로토콜로 UDP를 사용하고 UDP 위에 애플리케이션 계층 프로토콜의 안정성을 구현함.
• 연결 상태가 없음.
  • TCP는 종단 시스템에서 연결 상태를 유지함. 연결 상태는 수신 버퍼와 송신 버퍼, 혼잡 제어 파라미터, 순서 번호와 확인응답 번호 파라미터를 포함함.
  • 상태 정보가 TCP의 신뢰적인 데이터 전송 서비스를 구현하고 혼잡 제어를 제공하는 데 필요함.
  • UDP는 연결 상태를 유지하지 않으며 파라미터 중 어떠한 것도 기록하지 않음.
  • 일반적으로 특정 애플리케이션 전용 서버는 애플리케이션 프로그램이 TCP보다 UDP에서 동작할 때 일반적으로 좀 더 많은 액티브 클라이언트를 수용할 수 있음.