UDP

UDP: User Datagram Protocol (RFC768)

- Simple, datagram-oriented, transport layer protocol

- 신뢰성을 지원하지 않음 ( 목적지 도착한다는 보장 없음 ) 

- UDP 응용은 최종 IP 데이터그램의 크기를 고려 해야한다 

 

UDP Header 

◎ port number field

   - sending process와 receiving process 구별에 사용

   - 보통 TCP 포트 번호와 UDP 포트 번호를 나눠 관리하지만, TCP 포트 번호는 UDP 포트 번호에 "독립적" (전송 계층 프로토콜이 다르면 포트 번호는 중복이 허용됨) 

◎ UDP length Field : UDP header + data의 길이 

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

   - IP 길이 필드에 IP 데이터그램의 총 길이가 명시되고, UDP는 옵션 없이 고정 헤더 길이를 쓰므로, 필요 없는 필드임

 

UDP Checksum

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

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

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

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

   - 전송된 체크섬 필드값이 0이면, 체크섬이 사용되지 않았음을 나타냄

 

◎ UDP 체크섬은 종단 간 체크섬임

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

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

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

체크섬이 동일한 이유

>> checksum 연산할 때 교환법칙이 성립한다. 그래서 순서가 바뀌는것이지, 값이 바뀌는게 아니므로 동일한 값이다. 

 

체크섬이 과연 필요한가?

-TCP로 보냈을 때 에러가 훨씬 많았다... 왜? TCP를 쓸 땐 장거리 네트워크 일 때만 사용. UDP는 단거리에서만 사용 

 

IP Fragmentation

MTU maximum transport unit 보다 크게 되면 Fragmentation 수행 함. 

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

IP Fragmentation 이 필요한 상황 : IP 데이터그램의 크기가 링크 계층이 전송할 수 있는 MTU 보다 클 때

IP Reassembly 

- 최종 목적지에서만 수행

 

Fragmentation 관련 IP 헤더 필드

◎ Identification 필드 ID Field : Unique 한 식별자이다. 패킷, 데이터그램을 나눠서 설명을 하는 이유는 Datagram이 쪼개지면 패킷이고, 재조립이 되면 Datagram인 것이다. 

분할될 경우, 각 단편의 Identification 필드에 복사됨 

◎ Flags 필드 - 3개의 flag

 - MF (more fragment) 비트 : 송신된 단편 뒤에 더 있음을 알림

- DF ( don't fragment) 비트 : IP는 datagram을 단편화하지못하고 폐기함. ICMP error 메세지를 송신자에게 보낸다. 

 - 마지막 플래그는 안쓴다

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

◎ Total length 필드 : 데이터그램의 총 길이가 아닌 , 각 단편의 전체 길이를 기재함

 

Routing of Fragments

 - 각각의 단편은 자신의 IP 헤더를 갖는 독립된 패킷이기 때문에  

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

 

각각의 단편은 자신의 IP헤더를 갖는 독립된 패킷이기 때문에 다른 패킷과 독립적으로 전송, 다른 순서로 도착할 수 있음을 주의하시길 바랍니다. 

 

◎ Fragmentation의 단점

 - 단편 하나라도 분실하면 데이터그램 전체의 재전송이 요구된다

 - 하지만 IP는 자체 재전송을 할 수 없다 -> 상위계층(TCP)의 문제

 - 중간 라우터에서 Fragmentation이 일어나나면 송신자는 데이터그램의 분할 여부 알 수 없음

 - Kent and Mogul 1987은 Fragmentation을 피해야한다고 주장 

 

Fragmentation 예제를 살펴보면

 - sock 프로그램으로 UDP 패킷을 1471 바이트부터 1474 바이트까지 전송을 합니다. 

 이 호스트들이 1500byte를 갖는 MTU를 갖고 있는데 , 최대 크기는 1500 에서 IP 헤더와 UDP 헤더의 크기를 뺀 1472byte만큼 전송이 가능합니다.

만약 1471바이트를 전송하면 아무 문제가 없지만 1473바이트 만큼 전송을 한다면 자동적으로 fragmentation이 수행됩니다. 아이덴티피케이션 값은 26304, + 사인은 More fragmentation 을 의미합니다. 

주의할 점은 생성된 fragment의 크기는 마지막 fragment를 제외하고는 8의 배수가 되어야한다는 것입니다. UDP 헤더는 첫 번째 헤더에만 등장합니다. 그 뒤에 있는 fragment의 경우에는 IP헤더, UDP data등이 존재합니다.

앞과 동일한 실험을 Linux에서 했을떄의 차이점은 

- 마지막 fragment가 제일 첫번째로 나왔다는 것입니다.  어느 정도의 데이터그램의 길이인지 예측할 수 있으므로 버퍼 공간을 할당하기 좋습니다. 

 

Dont fragmentation을 설정한 경우, ICMP Unreachable error가 발생할 수 있습니다. 

보통 DF는 Path MTU를 알아보기 위해 사용됩니다. 하지만 못 쓰는 상황도 있을 수 있음을 주의해야합니다. 

Solaris라는 운영체제는 DF를 디폴트로 설정하여 패킷을 전송합니다. 

Solaris 2.2의 IP는 Path MTU Discovery를 지원합니다. SUN이라는 컴퓨터에서