UDP: User Datagram Protocol

UDP

• Simple, datagram-oriented, transport layer protocol
• best effort service model : 전송에는 최선을 다하지만 전송 완료는 보장하지 않음
• 신뢰성 (Reliability)을 전혀 지원하지 않음 : 응용이 쓴 데이터그램은 IP 계층에 전달되지만, 목적지까지 도착한다는 보장은 없음
• 이로 인해 UDP 응용은 최종 IP 데이터그램의 크기를 고려가 중요하다 => 네트워크의 MTU를 초과하는 UDP/IP 데이터그램이 분할됨 (fragment)
• IP 데이터그램 = IP 헤더 + UDP 데이터그램(UDP 헤더 + UDP 데이터)

 

 

UDP Header

Port number 필드

• sending process와 receiving process 구별에 사용
• 보통 TCP 포트 번호와 UDP 포트 번호를 나누어 관리하지만, TCP 포트 번호는 UDP 포트 번호에 독립적 => 즉, 전송 계층 프로토콜이 다르면 포트 번호는 중복이 허용

UDP length 필드 : UDP header + data의 길이

• 최소 크기는 8바이트 : data가 비어도 무방
• IP 길이 필드에 IP 데이터그램의 총 길이가 명시되고, UDP는 옵션 없이 고정 헤더 길이를 쓰므로, 사실 필요없는 필드

 

 

UDP Checksum

: IP 헤더의 checksum 필드는 IP 헤더만 체크하지만, UDP checksum은 헤더와 데이터 전체를 체크한 결과

 

종단간 (end-to-end) checksum

• 송수신 주체 외의 누군가가 헤더나 데이터를 수정했을까 확인
• 체크섬 에러가 발생한 UDP 데이터그램은 조용히 폐기

 

UDP 표준문서는 checksum의 사용을 선택사항으로 표기

• 하지만 Host Requeirements RFC에서 디폴트로 UDP checksum의 사용을 요구 (반면, TCP checksum의 사용은 TCP 표준 문서 상에서 의무)

 

IP Checksum(16비트 워드 단위로 1의 보수 합)과 다른 점

1) IP 헤더는 바이트 단위로 4의 배수라서 언제나 16비트 워드 단위로 표현해도 정수로 표현되는데, UDP 데이터그램은 아님

• UDP 데이터그램 크기가 홀수 바이트라면, 0으로 채운 1바이트 패딩 추가
• 패딩은 checksum 시에만 사용되고 실제 전송되지 않음

2) IP의 일부 필드로 12바이트의 가상 헤더를 만들어 checksum 시 사용

• 이 때 UDP 데이터그램 길이는 두 번 반복됨

3) 전송된 checksum 필드 값이 0이면, checksum이 사용되지 않았음을 나타냄

 

 

UDP checksum 계산 시 활용되는 필드들

• 의도적으로 데이터가 홀수 바이트로 가정 (PAD 필요)

* PAD : 패킷 조립 분해 장치

 

 

IP Fragmentation

 : 상위 계층에서 보내온 데이터 단위는 원칙적으로 한 IP 데이터그램에 담기는데, 최초 송신 호스트에서 또는 중간 라우터에서 IP 데이터그램을 여러 개로 분할하는 것

• 생성된 fragment의 크기는 마지막 fragment를 제외하고 8의 배수가 되어야 함 => 표준 요구사항

 

IP Fragmentation이 필요한 상황

 : 보내는데 쓰려는 링크 계층이 전송할 수 있는 MTU보다 IP 데이터그램의 크기가 클 때

• Fragmentation이 여러 홉에서 일어날 수도 있음
• 링크 계층의 MTU 크기는 인터페이스에 쿼리를 보내 확인

 

IP Reassembly

• 분할된 IP 데이터그램들을 한 IP 데이터그램으로 재조합하는 것으로, 최종 목적지에서만 수행
• 다른 프로토콜들은 다음 홉에서 재조합을 하기도 함
• 전송 계층에 투명하게 분할 및 재조합을 하는 것이 목적

 

Fragmentation 관련 IP 헤더 필드

Identification 필드	송신자에서 보낸, (아직 분할되지 않은) 각 IP 데이터그램에 대한 "유일한" 식별자 - 분할될 경우, 각 fragment(단편)의 Identification 필드에 복사됨
Flags 필드	- MF (more fragment) 비트 : 본 fragment 뒤에 송신된 fragment가 있음을 알림 (마지막 fragment에는 MF 비트를 설정하지 않음) - DF (don't fragment) 비트 : DF가 설정되면, IP는 데이터그램을 단편화하지 못하고 폐기. 대신, ICMP error를 최소 송신자에게 보냄 => "fragmentation needed but don't fragment bit set"
Fragment offset 필드	해당 fragment가 원래 데이터그램의 첫 바이트에서 몇 바이트 뒤의 데이터인지를 명시
Total Length 필드	원래 데이터그램의 총 길이가 아닌 각 fragment의 총 길이를 기재

 

Routing of Fragments

• 각각의 fragment는 자신의 IP 헤더를 갖는 독립된 패킷
• 다른 패킷과 독립적으로 전송
• 최종 목적지에 다른 순서로 도착할 수 있지만 IP 헤더로 재조립

 

Fragmentation의 단점

• fragment 하나라도 분실하면 데이터그램 전체의 재전송이 요구되나, IP는 자체 재전송을 할 수 없음 => 상위 계층의 책임이기 때문에
• 중간 라우터에서 Fragmentation이 일어났다면, 송신자는 데이터그램의 분할 여부조차 알 방법이 없음

=> [Kent and Mogul 1987]은 Fragmentation을 피해야 한다고 주장

 

 

ICMP Unreachable Error (Fragmentation Required)

: Path MTU Discovery 매커니즘 [RFC1191]에서 사용 (하지만 못 쓰는 상황도 있을 수 있음에 주의)

• Path MTU Discovery 매커니즘이 있으면 UDP에서 IP Fragmentation 문제에도 데이터 전송이 가능
• 응용에서 재전송을 반드시 처리해주어야 함
• 학습한 Path MTU는 timeout으로 사라질 수 있다는 점은 UDP를 사용하는 응용이 세심히 고려해야 함

 

 

Interaction Between UDP and TCP

• 어떤 구현(bsdi)에서는 매 fragment가 ARP 요청을 만들어냄 => Host Requirements RFC는 이런 ARP Flooding을 막고자 1초에 1개의 요청만을 보내도록 추천하기에, 이 상황은 문제가 있음
• ARP는 ARP 응답이 오기 전에 unresolved 상태의 동일 목적지로 가는 여러 패킷이 도착하면, 하나 이상의 패킷을 저장 => 대부분의 구현은 마지막 패킷만 저장

 

 

Maximum UDP Datagram Size

: 이론상, IP 데이터그램의 최대 크기는 65,535 bytes라서, UDP 데이터 그램의 최대 크니는 바이트 단위로

65,535 - 최소 IP헤더 크기(20) - UDP 헤더 크기(8) = 65,507

 

• IPv6의 경우, Total Length 필드가 없어지고 16비트의 Payload Length 필드가 사용되므로, 65,527비트 (점보그램을 사용하지 않는다는 가정 하에)
• 이론상 최대 크기로 보내는 경우는 거의 없음 => 시스템의 프로토콜 구현에 한계/ 수신 응용이 그렇게 큰 UDP 데이터그램 처리가 불가능