[TCP/IP Networks] 6. UDP: User Datagram Protocol

1. 개요

User Datagram Protocol(UDP) (RFC768 [Postel 1980])

Simple, datagram-oriented, transprot layer protocol

신뢰성(reliability)을 전혀 지원X

: 응용이 쓴 데이터그램은 IP 계층에 전달 but, 목적지까지 도착한다는 보장X

=> UDP 응용은 최종 IP 데이터그램의 크기 고려 필요

네트워크의 MTU 초과하는 UDP/IP 데이터그램이 분할(fragmented)

2. UDP Header

Port number 필드

sending process와 receving process 구별에 사용

보통 TCP 포트 번호와 UDP 포트 번호를 나누어 관리

TCP 포트 번호는 UDP 포트 번호에 독립적

= 전송 계층 프로토콜이 다름 -> 포트 번호 중복 허용

UDP length 필드: UDP header + data 길이

최소 크기는 8바이트(data 길이 0): data 비어도 무방

IP 길이 필드에 IP 데이터그램의 총 길이 명시, UDP 옵션 X 고정 헤더 길이 사용 => 사실 필요 X 필드

3. UDP Checksum

IP 헤더의 체크섬 필드: IP 헤더만 체크

UDP 체크섬: 헤더와 데이터 전체 체크한 결과

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

IP 헤더; 바이트 단위 -> 4의 배수 => 언제나 16비트 워드 단위로 표현해도 정수 표현 but, UDP 데이터그램은 X

ㄴUDP 데이터그램 크기 = 홀수 바이트 -> 0으로 채운 1바이트 패딩 추가

(패딩: 체크섬 시에만 사용, 실제 전송 X)

IP의 일부 필드로 12바이트의 가상 헤더를 만들어 체크섬 시 사용

ㄴUDP 데이터그램 길이는 두 번 반복

전송된 체크섬 필드값 = 0 => 체크섬이 사용되지 X

 

UDP checksum 계산 시 활용되는 필드_의도적으로 데이터가 홀수 바이트로 가정(PAD 필요)

종단간(end-to-end) 체크섬

송수신 주체 외의 누군가가 헤더나 데이터를 수정했을까 확인

체크섬 에러가 발생한 UDP 데이터그램은 조용히 폐기

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

but, Host Requirements RFC에서 디폴트로 UDP체크섬의 사용 요구

(TCP: 체크섬의 사용 = TCP 표준 문서 상의 의무)

Host Requirements RFC 등장 전인 1980년대, 속도를 빠르게 하려고 몇몇 회사들 UDP 체크섬 끔

-> LAN: 보통 체크섬이 있는 경우 ↑ -> 문제 X but, 인터넷: 라우터의 버그 -> 비트 변경 -> 문제 O

*Advanced Q: NAT가 동작하는 경우 문제 X?

tepdump 활용 -> 각 호스트 별 Checksum 사용 여부 확인

응용에서 UDP 체크섬에 대한 정보 확인 불가능

링크 계층에서 패킷 캡쳐 하는 tepdump 소스 수정 -> 각 UDP 체크섬 출력

(UDP cksum = 0: 송신 호스트가 UDP 체크섬 지원하지 X)

3/4 = 5/6 체크섬 값, 각 페어가 16비트 크기의 필드 값 위치 변경되었기 때문

 

4. IP Fragmentation

상위 계층에서 보내온 데이터 단위는 원칙적으로 한 IP 데이터그램에 담기는데,

최초 송신 호스트에서 OR 중간 라우터에서 IP 데이터그램을 여러개로 분할

필요한 상황

IP 데이터그램의 크기 > 보내는데 쓰려는 링크 계층이 전송할 수 있는 MTU

Fragmentation 여러 홉에서 일어날 수 O

링크 계층의 MTU 크기는 인터페이스에 쿼리를 보내 확인

IP Reassembly (IP 데이터그램 재조합)

: 분할된 IP 데이터그램들을 한 IP 데이터그램으로 재조합하는 것

/ 최종 목적지에서만 수행(다른 프로토콜들은 다음 홉에서 재조합 하기도)

전송 계층에서 투명하게 분할 및 재조합 하는 것이 목적

Fragmentation 관련 IP 헤더 필드

Identification 필드

: 송신자에서 보낸, (아직 분할되지 않은) 각 IP 데이터그램에 대한 유일한(unique) 식별자

Flags 필드

MF(more fragment) 비트: 본 단편 뒤에 송신된 단편 O (마지막 단편 MF 비트 설정 X)

DF(don't fragment) 비트: DF 설정 -> IP는 datagram을 단편화 X, 폐기

대신 ICMP error를 최소 송신자에게 보냄 (fragmentation needed but don't fragment bit set)

Fragment offset 필드: 해당 단편이 원래 데이터그램의 첫 바이트에서 몇 바이트 뒤의 데이터인지 명시

Total Length 필드: 원래 데이터그램의 총 길이가 아닌 각 단편의 총 길이 기재

Routing of Fragments

각각의 단편은 자신의 IP 헤더를 갖는 독립된 패킷

다른 패킷과 독립적으로 전송, 최종 목적지에 다른 순서로 도착할 수 O, IP 헤더로 재조립

Fragmentation 단점

단편 하나라도 분실하면 데이터그램 전체의 재전송 요구, IP 자체 재전송 불가(상위 계층의 책임)

ㄴIP: 재전송/타임아웃 X -> 보낸 데이터그램 기억 X

중간 라우터에서 Fragmentation -> 송신자: 데이터그램의 분할 여부 알 방법 X

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

예제

sock 프로그램으로 1471바이트부터 1474바이트 UDP 데이터 전송

 

5. ICMP 도달불가 에러(단편화 요구)

Path MTU Discovery 메커니즘 [RFC1191]에서 사용_but 못 쓰는 상황도 O

못 쓰는 예제 (solaris가 600바이트 데이터의 ping packet 보냄)

 

6. UDP를 이용한 Path MTU 발견

 

7. UDP와 ARP간의 상호 작용

 

8. UDP 데이터그램 크기의 최대값

이론상, IP 데이터그램의 최대 크기: 65,535 bytes <- IPv4의 Total Length 필드가 16bit

=> UDP 데이터그램의 최대크기 = 바이트 단위로 65,535

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

IPv6 경우, Total Length 필드 X, 16비트의 Payload Length 필드 사용 -> 65,527 바이트

(점보그램 사용 X 가정)

but, 이론상 최대 크기로 보내는 경우 거의 X

ㄴ시스템의 프로토콜 구현의 한계/ 수신 응용이 큰 UDP 데이터그램 처리 X

구현 측면 한계

프로토콜 구현들은 송수신용 버퍼 크기 정하는 API 제공

크기는 응용이 읽고 쓰는 UDP 데이터그램의 최대 크기 결정

(최근 8,192 바이트 OR 65,535 바이트 디폴트

but, 몇몇 구현에서 디폴트 값 < 최대 IP 데이터그램 크기/ 수십 KB 이상 보내는 것을 막는 경우)

호스트: 최소 576 바이트의 IP 데이터그램 받을 수 있어야 함

= 576 바이트가 넘는 IP 데이터그램을 받지 못하는 호스트 존재

=> 많은 UDP 응용들은 512 바이트 이하의 응용 데이터 보냄 (DNS, DHCP 등)

데이터그램 절단(Datagram Truncation)

송신자가 수신자의 버퍼 크기보다 큰 UDP 데이터그램을 보내면, 대부분의 응용이 초과 부분 절단

문제: 어떤 구현은 다음 read 함수 호출에서 나머지 주기도 하고, 다른 구현은 절단된 양을 알리기도 하고,

또 어떤 구현은 데이터가 절단되었다는 사실만 알리기도 하고,...

9. 요약

UDP is a simple protocol

: UDP가 user process에 제공하는 서비스 = port number/ optional checksum

ICMP unreachable error는 path MTU discovery에 사용됨

UDP와 ARP간의 interaction