UDP: User Datagram Protocol

11. UDP: User Datagram Protocol

 

11.1 개요

UDP는 datagram-oriented의 간단한 transport layer protocol이다. 하나의 process는 단 하나의 UDP datagram을 만들어 내고 단 하나의 IP datagram이 다음 layer로 보내지게 된다. 반면에 TCP는 stream-oriented protocol로서 하나의 application에 의해 만들어진 data의 양은 IP datagram의 개수와는 상관이 없다.

다음 Figure 11.1에 UDP encapsulation을 나타내었다.

UDP는 datagram이 목적지에 도달하리라는 보장이 없어 신뢰성이 부족하다. 그래서 TCP를 더 선호하게 될 때가 많다. 그리고 IP datagram의 크기에 대해 고려할 필요가 있다. 만약 그 크기가 MTU를 초과한다면 IP datagram 이 조각내어질 것이다.

 

11.2 UDP Header

다음의 Figure 11.3는 UDP header의 간단한 구조이다.

port number field는 sending process와 receiving process를 감지한다. IP에서 먼저 TCP로 갈 data인지 UDP로 갈 data인지 demultiplex하기 때문에 TCP의 port number와 UDP의 port number는 별개의 것이다. 하지만 well-known service에 대해서는 TCP, UDP의 port number가 같은 경우가 많다. 하지만 이것은 단지 편리함 때문이지 protocol에 의해 요구되는 것은 아니다.

UDP length field는 UDP header와 UDP data의 길이를 byte단위로 나타낸 것이다. 이 field의 최소값은 8byte다. 즉, UDP datagram이 0byte여도 패킷은 보낼 수 있다. 사실 IP datagram은 total length를 포함하므로 length field는 불필요하다. (UDP datagram의 길이는 total length - IP header length )

 

11.3 UDP Checksum

UDP checksum은 UDP header와 UDP data만 체크하고 IP header의 checksum은 IP header에서 이루어진다. 그리고 TCP의 checksum은 강제적인데 비해 UDP의 checksum은 선택적이다.

UDP checksum을 계산하는 방법은 IP header와 비슷하지만 약간의 다른점이 있다. (IP checksum 계산법 : 일단 checksum field를 0으로 놓은 뒤 전체 header를 16진수의 단어로 간주하고 그 합을 16 bit one's complement하여 checksum field에 저장한다.) 첫째로는 16 bit 단어의 합을 해야 하는데 UDP datagram의 길이가 byte단위로 홀수가 될 수 있으므로 그럴 경우 0byte의 pad가 끝머리에 덧붙여진다는 점이다. 둘째로는 UDP와 TCP가 12byte의 pseudo header를 포함한다는 것이다. 이 pseudo header는 IP header의 몇몇 특정한 field로 이루어져 있으며 데이터가 목적지에 정확하게 도착했는지 - 정확한 IP address인지, 그리고 다른 transport layer가 아닌 UDP에 오는 것이 맞는 것인지 - 를 다시 한번 체크한다. 다음은 pseudo header를 포함한 UDP datagram이다.

이 datagram은 길이가 8 byte단위로 홀수인 경우이며, 따라서 0 byte pad가 붙여졌다. 그리고 UDP datagram의 field가 두개이므로 그 길이가 두배가 되었다.

만약 checksum이 0이라면 그 수는 complement된 것이므로 실제로 65535(2¹⁶) bits가 저장된 것이다. 그리고 checksum이 0이라면 sender가 checksum을 계산하지 않았다고 간주한다.

Sender가 checksum을 계산하였고 receiver가 checksum error를 감지하였을 때 그 UDP datagram은 어떤 error message도 없이 완전히 무시된다.

UDP checksum은 end-to-end checksum으로서 sender가 checksum을 계산하고 receiver가 판별하는 방식으로 이루어진다.

UDP checksum은 선택적으로 이루어지지만 항상 enable상태가 될 준비가 되어있어야 한다.

< tcpdump OUT >

보통 application가 UDP header의 checksum field를 관찰하는 것은 거의 불가능한 일이므로 tcpdump program에 UDP checksum을 출력하도록 설정하여 관찰해보도록 하자. 이 옵션에서 0이 출력되면 그것은 sending host가 checksum을 계산하지 않은 것이다.

다음 Figiure 11.4는 세개의 다른 시스템으로부터의 output이다. 여기서 standard echo 서버로 9 byte의 UDP datagram을 보내기 위해 sock program을 사용하였다.

 

1	0.0	sun.1900 > Gemini.echo: udp 9 (UDP cksum=6e90)
2	0.303755 ( 0.3038)	gemini.echo > sun.1900: udp 9 (UDP chsum=0)
3	17.392480 (17.0887)	sun.1904 > aix.echo : udp 9 (UDP chsum=6e3b)
4	17.614371 ( 0.2219)	aix.echo > sun.1904: udp 9 (UDP cksum=6e3b)
5	32.092454 (14.4781)	sun.1907 > solaris.echo: udp 9 (UDP cksum=6e74)
6	32.314378 ( 0.2219)	solaris.echo > sun.1907: udp 9 (UDP cksum=6e74)

 

Figure 11.4 tcpdump output to see whether other hosts enable UDP checksum

 

위의 그림을 보면 세 시스템 중 두개의 시스템이 checksum enable 상태임을 알 수 있다. 또한 3~6줄의 보내진 datagram과 받은 datagram이 모두 같은 checksum을 가졌다. Data는 echo될 뿐이므로 port number와 address만 서로 바꿔 재전송 되었을 것이다. 따라서 16-bit sum을 반복할 뿐이므로 에러를 감지할 수 없다.

 

11.4 A Simple Example

UDP datagram을 보내기 위해 sock program을 이용하여 다음과 같이 하였다.

 

bsdi % sock –v –u –i –n4 svr4 discard

connected on 140.252.13.35.1108 to 140.252.13.34.9

bsdi % sock –v –u –i –n4 –w0 svr4 discard

connected on 140.252.13.35.1110 to 140.252.13.34.9

 

-v : 순간적인 port number를 보게 해줌

-u : UDP를 뜻함

-i : 표준 입출력을 읽거나 쓰지 않고 보내는 옵션

-n4 : 4개의 datagram만 출력하게 하는 옵션 (default : 1024)

-w0 : 0만큼의 길이를 쓰게 하는, 즉 아무것도 쓰지 않게 하는 옵션

tcpdump:

1	0.0	bsdi.1108 > svr4.discard: udp 1024
2	0.002424 ( 0.0024)	bsdi.1108 > svr4.discard: udp 1024
3	0.006210 ( 0.0038)	bsdi.1108 > svr4.discard: udp 1024
4	0.010276 ( 0.0041)	bsdi.1108 > svr4.discard: udp 1024
5	41.720114 (41.7098)	bsdi.1110 > svr4.discard: udp 0
6	41.721072 ( 0.0010)	bsdi.1110 > svr4.discard: udp 0
7	41.722094 ( 0.0010)	bsdi.1110 > svr4.discard: udp 0
8	41.723070 ( 0.0010)	bsdi.1110 > svr4.discard: udp 0

 

 

 

 

 

 

 

 

 

Figure 11.6 tcpdump output when UDP datagrams are went in one direction

 

위의 datagram을 분석해 보면 우선 1024 byte의 데이터 네 개가 몇 밀리세컨드를 차이로 나타났고 그 뒤로 0 byte의 datagram이 있다. 그리고 첫번째 datagram이 도착할때까지 sender와 receiver사이에 어떤 커뮤니케이션도 존재하지 않으며 – TCP의 경우 datagram을 보내기 전에 상대방과 먼저 연결을 시도한다 – 데이터를 보낸 후에도 상대방이 데이터를 받았는지 안받았는지에 대해 알 수가 없다. 마지막으로 UDP datagram을 보낼때마다 port number가 바뀌고 있다. (1108 -> 1110)

 

11.5 IP Fragmentation

IP가 IP datagram을 받았을 때 그 길이를 MTU와 비교하여 필요하다면 fragmentation을 수행한다. 이것은 본래의 sending host 혹은 sender와 receiver사이의 라우터에서 일어난다. IP datagram이 한번 fragmentation되었을 때 그 패킷은 목적지에 도착할 때까지 합쳐지지 않으며 목직지의 IP layer에서 합쳐진다(reassembly).

IP header에서 identification, flags, framnet offset등의 세 개의 field가 reassembly하는데 필요한 정보를 제공한다. 더 자세히 살펴보면,

o. identification – IP datagram 각각의 고유번호로 각 fragmentation에 같은 값을 복사하여 보낸다.

o. flags – 3개의 bit로 이루어져 있는데 그 각각의 bit가 하는 일이 다르다. 그중 한 개의 bit는 가장 마지막 fragment를 제외하고 모두 turn on 되어진다. 다음 한 개의 bit는 더 이상 fragment가 이루어 질 수 없음을 나타낼 때 사용한다. 만약 이 bit가 turn on 되어있는데 MTU때문에 fragmentation이 필요하게 된다면 그 datagram은 버려지고 “fragmentation needed but don’t fragment bit set”이라는 ICMP error가 sending host로 보내진다.

o. fragment offset – 각 fragment의 처음이 어디인지 알려준다. 이 field값에 의해 각각의 fragment가 차례대로 합쳐지게 된다. 그러므로 각각 쪼개진 fragment는 각각 같은 IP header를 앞에 덧붙여 각각 독립적으로 목적지에 도달한다.

만약 하나의 fragment가 손실되었을 경우엔 전체 datagram이 재전송 되어야 한다. 왜냐하면 IP 자체로는 time out, retransmission가 없고 이것은 상위의 layer의 소관이기 때문이다. (TCP의 경우에는 수행하나 역시 단 하나의 fragment만을 재전송 할 수는 없다.) 또한, 중간의 라우터에의해 fragmentation되었을 경우 sending host는 그것을 알 방법이 없기 때문이다.

TCP에 비해 UDP datagram은 fragmentation이 자주 일어난다. (TCP는 fragmentation 될 정도로 큰 조각은 거의 만들지 않는다). Sock program을 이용해 datagram의 크기를 1byte씩 증가시켜 관찰을 해보면, (Ehternet의 경우 데이터의 최대값은 1500임을 상기시키자)

bsdi % sock –u –I –n1 –w1471 svr4 discard

bsdi % sock –u –I –n1 –w1472 svr4 discard

bsdi % sock –u –I –n1 –w1473 svr4 discard

bsdi % sock –u –I –n1 –w1474 svr4 discard

-> tcpdump:

1	0.0	bsdi.1112 > svr4.discard: udp 1471
2	21.008303 (21.0083)	bsdi.1112 > svr4.discard: udp 1472
3	50.449704 (29.4414)	bsdi.1112 > svr4.discard: udp 1473 (frag 26304:1480@0+)
4	50.450040 ( 0.0003)	bsdi > svr4 : (frag 26304: 1@1480)
5	75.328650 (24.8786)	bsdi.1112 > svr4.discard: udp 1471 (frag 26313:1480@0+)
6	75.328982 ( 0.0003)	bsdi > svr4 : (frag 26313:2@1480)

 

Figure 11.7 Watching fragmentation of UDP datagrams.

 

1,2번 줄은 fragmentation이 이루어지지 않았으나 다음의 1473,1474 byte의 data는 fragmentation 되었다. IP datagram이 fragmentation되었을때 tcpdump는 부가적인 정보를 제공하는데, 첫째로 3번줄의 26304와 5번줄의 26313은 IP header의 identification field 값이다. 다음으로, 콜론 다음의 숫자, (순서대로) 1480, 1, 1480, 2는 IP header를 제외한 datagram의 크기 – 8 byte의 배수여야 함(final datagram 제외) - 이다. @(at sign) 다음의 숫자는 데이터의 offset이다. 3번 줄의 데이터는 0에서 시작하고 4번줄의 데이터는 1480에서 시작함을 뜻한다. 그리고 +(plus sign)은 아직 fragment가 남아있음을 뜻한다. 그리고 4,6번 줄을 보면 (즉, 맨 처음의 fragment를 제외한 나머지 fragment) port number가 생략되었음을 알 수 있다. Address는 IP header에 포함되어 있으므로 tcpdump에 출력된 것이지만 port number는 UDP header에 포함된 정보이므로 tcpdump에 나타나지 않은 것이다.

IP datagram과 packet을 굳이 구별하자면 IP datagram은 fragmentation전 혹은 reassembly후 IP layer에서의 것이고 packet은 쪼개진 이동단위를 뜻한다.

 

11.6 ICMP Unreachable Error (Fragmentation Required)

앞에서 말했듯이 라우터가 fragmentation이 요구되는 datagram을 받았을 때 don’t fragment (DF) flag가 커져있으면 ICMP Unreachable Error가 발생한다. 이 에러는 목적지까지의 path에서 가장 작은 MTU룰 알아낼 때 쓰일 수 있으며 path MTU discovery mechanism이라 불린다.

다음 Figure 11.9는 Unreachable Error경우의 ICMP 포맷이다. 6장의 그림에서와는 다르게 MTU of next-hop network라는 field가 있다. 라우터가 ICMP error 포맷을 지원하지 않을 경우 이 field값은 0이다.

< Example >

sun의 입장에서 netb방향의 MTU는 알지만 – SLIP인스톨 할 때 configuration에 포함됨 – netb에서 sun방향의 MTU는 알지 못하므로 그걸 알아보기 위해 solaris에서 bsdi로 packet의 크기를 증가시키면서 fragmentation될때까지 ping을 실행시켰다. Ping packet의 크기가 500 byte에서 600byte로 증가할

때까지 bsdi쪽으로 가는 packet에는 아무런 문제가 없었다. 그러나 echo reply들은 사라져버렸다. 다음은 bsdi에서의 tcpdump이다.

 

1	0.0	solaris > bsdi: icmp: echo request (DF)
2	0.000000 (0.0000)	bsdi > solaris: icmp: echo reply (DF)
3	0.000000 (0.0000)	sun > bsdi: ecmp: solaris unreachable–need to frag, mtu = 0
4	0.738400 (0.7384)	solaris > bsdi: icmp: echo request (DF)
5	0.748800 (0.0104)	bsdi > solaris: icmp: echo reply (DF)
6	0.748800 (0.0000)	sun > bsdi: ecmp: solaris unreachable–need to frag, mtu = 0

 

Figure 11.11 tcpdump output for ping of bsdi from solaris with 600-byte IP datagram

 

우선 (DF) 표시는 don’t fragment bit이 turn on 되어있음을 뜻한다. 첫번째 줄은 solaris에서 bsdi로의 echo request가 fratmentation되지 않고 통과하였음을 말한다. 여기서 netb의 SLIP MTU에 아직 도달하지 못하였음을 알 수 있다. 두번째 줄에서 DF flag가 echo reply로 복사되었음을 알 수 있다. Echo reply 의 크기는 echo request와 똑같지만 sun의 SLIP MTU는 552이므로 fragmentation되어야 한다. 하지만 DF flag가 셋트되어 있으므로 sun은 bsdi로 ICMP Unreachable Error를 보낸다. 따라서 solaris에서 echo reply를 볼 수 없다. 다음은 packet의 경로이다.

 

마지막으로, 3번째 줄의 mtu=0는 sun이 MTU of next-hop network field를 지원하지 않음을 나타낸다.

 

 

 

11.7 Determining the Path MTU Using Traceroute

Traceroute를 사용하여 Path MTU를 결정한다는 것은 “don’t fragment” bit을 turn on하여 우선 자신의 MTU와 같은 크기의 패킷을 보내고 ICMP “can’t fragment” error가 도착하면 다음의 더 작은 크기의 패킷을 보내는 것을 반복하여 Path MTU를 알아내는 방식을 뜻한다.

 

11.8 Path MTU Discovery with UDP - 생략해도 될 듯..

 

11.9 Interaction Between UDP and ARP

8192 bytes의 UDP datagram이 만들어졌다면 6개의 fragment가 생길 것이고 이 packet들을 보내기 전에 ARP request , reply가 상호 교환되어야 할 것이다.

 

bsdi % arp –a

bsdi % sock –u –I –n1 –w8192 svr4 discard

 

-> tcpdump:

1	0.0	Arp who-has svr4 tell bsdi
2	0.001234 (0.0012)	Arp who-has svr4 tell bsdi
3	0.001941 (0.0007)	Arp who-has svr4 tell bsdi
4	0.002775 (0.0008)	Arp who-has svr4 tell bsdi
5	0.003495 (0.0007)	Arp who-has svr4 tell bsdi
6	0.004319 (0.0008)	Arp who-has svr4 tell bsdi
7	0.008772 (0.0045)	Arp reply svr4 is-at 0:0:c0:c2:9b:26
8	0.009911 (0.0011)	Arp reply svr4 is-at 0:0:c0:c2:9b:26
9	0.011127 (0.0012)	bsdi > svr4: (frag 10863:800@7400)
10	0.011255 (0.0001)	Arp reply svr4 is-at 0:0:c0:c2:9b:26
11	0.012562 (0.0013)	Arp reply svr4 is-at 0:0:c0:c2:9b:26
12	0.013458 (0.0009)	Arp reply svr4 is-at 0:0:c0:c2:9b:26
13	0.014526 (0.0011)	Arp reply svr4 is-at 0:0:c0:c2:9b:26
14	0.015583 (0.0011)	Arp reply svr4 is-at 0:0:c0:c2:9b:26

 

놀라운 것은, 첫째로 첫번째 reply가 돌아오기도 전에 6개의 ARP request가 발생한다는 것이다. 이것은 IP가 얼마나 빨리 fragment를 만들어 내는지를 가늠하게 한다. 다음으로, 첫번째 ARP reply가 도착했을 때 마지막 fragment만 보내진다는 것이다. 즉 처음 다섯개의 fragment는 무시된 것이다. 대부분의 implementation은 ARP reply를 기다리는 동안 마지막 패킷만을 남겨둔다. 그리고 이번 출력에서, 예외적으로 svr4는 6개가 아닌 7개의 ARP reply를 보냈다. 끝으로, 마지막 ARP reply가 되돌아온 후 svr4가 ICMP “time exceeded during reassembly” error를 보내는지 안보내는지 보기위해 5분동안 tcpdump가 실행되도록 남겨진 사실이다. ICMP error는 도착하지 않았지만.

IP layer는 datagram의 첫번째 fragment – offset이 0인 첫번째 fragment가 아닌 처음 도착하는 fragment - 가 도착했을 때 타이머를 켜야 한다. (보통 time out 값은 30 또는 60초이다.) 만약 타이머가 끝났을 때 모든 fragment가 도착하지 않았다면 모든 fragment는 무시된다. 그렇지 않을 경우 도착하지 않는 fragment들은 결국 receiver가 버퍼를 끄게 만들 것이다.

여기서 ICMP message를 볼 수 없는 이유에는 두가지가 있다. 첫째로는, 대부분의 Berkeley-derived implementation은 error을 발생시키지 않도록 만들어졌다는 것. 타이머 작용은 하지만 error는 발생시키지 않는다. 두번째 이유는 UDP header를 포함하고 있는 offset이 0인 첫째 fragment가 도착하지 않았다는 것이다. 이 첫번째 fragment가 도착하지 않았다면 Transport layer가 유효하지 않으므로 ICMP error receiver는 어느 user process가 무시된 그 datagram을 보냈는지 구별할 수가 없기 때문에 implementation에 ICMP error의 전송이 요구되지 않는다. 따라서 상위 layer가 결국은 time out되어 재전송을 시도하리라고 간주된다.

여기서는 UDP와 ARP의 상호관계를 보기위해 IP fragmentation을 이용하였으나 이 현상은 sender가 여러 개의 UDP datagram을 빠르게 전송할 때도 관찰할 수 있다.

 

11.10 Maximum UDP Datagram Size

이론적으로는 IP datagram 크기의 최대값은 65535이지만 다음 두가지의 이유로 그 크기가 제한된다. 첫번째는, application program이 programming interface에 의해 제한되는 것이고, 둘째로는 TCP/IP의 커널 Implementation에 의한 것이다.

 

11.11 ICMP Source Quench Error

UDP를 사용하다 보면 ICMP “source quench” error가 발생할 수도 있다. 이 에러는 너무 높은 속도로 datagram을 받을 때 라우터 혹은 시스템에서 발생하는 에러로서 버퍼를 다 써버리고 datagram이 버려졌을 때 발생한다.

 

11.12 UDP Server Design

 client implementation을 design하는 것이 server의 경우보다 쉽기 때문에 여기서는 server design에 대해서만 설명하려 한다. Server는 운영체제와 특히 상호작용하는 부분이 많고 대부분의 server는 동시에 많은 client를 다룰 수 있어야 한다는 점에 유의해야 할 것이다.

 

Client IP Address and Port Number

 

Client로부터 UDP datagram이 도착하면 IP header로부터 source IP를 UDP header로부터 source port number를 얻게 되는데 이는 반드시 운영체제에 의해 듣게 된다. 이로서 UDP server는 multiple clients를 다룰 수 있게 되며 각각에게 reply를 보내게 된다.

 

Destination IP Address

 

몇몇의 application은 destination address를 필요로 하는 경우가 있다. 예를들어, TFTP server의 경우 broadcast address를 가진 datagram은 무시하도록 되어있기 때문에 운영체제가 destination address를 UDP datagram으로부터 application으로 전해줘야 한다. 하지만 모든 implementation이 이러한 기능을 가지고 있지는 않다.

 

UDP Input Queue

 

UDP server는 대화식의 server이다. 즉, 하나의 server process가 하나의 UDP port에서 모든 client request를 처리한다.

보통 하나의 application이 사용하는 각각의 UDP port에 관련한 input queue의 크기는 제한되어 있으므로, 동시에 도착한 서로 다른 서버로부터의 request는 UDP에 의해 자동적으로 줄을 서게 되고, 그 순서에 따라 application에 전달되게 된다. 하지만 이러한 input queue가 가득찼을 때에는 커널의 UDP module이 계속해서 들어오는 datagram을 무시하게 되며 어떤 error message도 보내지 않는다. 또한 UDP input queue는 FIFO(first-in, first-out)방식이다. (ARP의 경우 LIFO(last-in, first-out)).

 

Restricting Local IP Address

 

대부분의 UDP server는 UDP end point를 만들 때 그들의 local IP address를 예측할 수가 없다. 즉, 서버의 어떤 특정한 port로 들어오게 되어있는 UDP datagram은 어떤 local interface도 수용할 것이라는 거다. 예를 들어, port 7777로 UDP server를 연결해보면

 

sun % sock –u –s 7777

sun % netstat –a –n –f inet

Active Internet connections (including servers)

Proto	Recv-Q	Send-Q	Local Address	Foreign Address	(state)
udp	0	0	*.7777	*.*

 

 

 

-a : 모든 network end point를 보여준다.

-n : IP address를 DNS를 사용하지 않고 10진수로 나타낸다.

-f : TCP, UDP end point만 나타내게 한다.

 

여기서 local address가 *.7777로 나타난다. 여기서 *가 바로 local IP address가 예측될 수 없음을 나타낸다. Server가 end point를 만들 때는 하나의 broadcast address를 포함한 local IP address를 명기하고, UDP datagram은 destionation IP address가 local address와 같을 경우 이 end point를 거치게 된다. 다음과 같이 server가 SLIP interface에 도착하는 datagram으로 제한했을 때,

 

sun % sock –u –s 140.252.1.29 7777

sun % netstat –a –n –f inet

Proto	Recv-Q	Send-Q	Local Address	Foreign Address	(state)
Udp	0	0	140.252.1.29.7777	*.*

 

만약 이 서버에 Ethernet으로부터 온 datagram을 보냈다면, ICMP port unreachable 이 되돌아올 것이다.

 

1	0.0	bsdi.1723 > sun.7777: udp 13
2	0.000822 (0.0008)	sun > bsdi: icmp: sun udp port 7777 unreachable

 

다른 서버가 같은 port의 각각 다른 local IP address로 접속하는 것은 가능하다. 하지만 이 경우 시스템은 application으로부터 같은 port number를 재사용 하는 것에 대해 허락을 받아야 한다.

 

sun % sock –u –s 140.252.1.29 8888            for SLIP link

sun % sock –u –s –A 140.252.13.33 8888        for Ethernet

sun % sock –u –s –A 127.0.0.1 8888            for loopback interface

sun % sock –u –s –A 140.252.13.63 8888        for Ethernet broadcasts

sun % sock –u –s –A 8888                      everything else (wildcard IP address)

 

-A : 같은 port number를 재사용 하는 것이 허락되엇음을 나타냄.

 

sun % netstat –a –n –f inet

Proto	Recv-Q	Send-Q	Local Address	Foreign Address	(state)
Udp	0	0	*.8888	*.*
Udp	0	0	140.252.13.63.8888	*.*
Udp	0	0	127.0.0.1.8888	*.*
Udp	0	0	140.252.13.33.8888	*.*
Udp	0	0	140.252.1.29.8888	*.*

 

이 경우 wildcard local IP address를 갖는 server로 가는 것은 목적지가 140.252.1.255인 datagram뿐이다. 나머지 넷은 모든 가짓수를 커버할 수 있다.

wildcard end point address가 존재할때는 특정 IP address와 일치하는 destination address를 가진 end point가 항상 우선한다. Wildcard end point는 일치하는 특정 address가 없을 경우에만 사용된다.

Restricting Foreign IP Address

 

여태껏 앞의 모든 netstat output에서 foreign IP Address와 foreign port number는 *.*였다. 하지만 대부분의 implementation은 foreign address를 제한하는 – 특정 IP address및 port number로부터만 UDP datagram을 받는 - UDP end point를 지원한다. 다음 sock program의 –f 옵션은 foreign IP address와 port number를 명기한다.

 

sun % sock –u –s –f 140.252.13.35.4444 5555

sun % netstat –a –n –f inet

Proto	Recv-Q	Send-Q	Local Address	Foreign Address	(state)
Udp	0	0	140.252.13.33.5555	140.252.13.35.4444

 

다음은 UDP server가 스스로 설정한 세가지 타입의 요악이다.

 

Local Address	Foreign Address	설명
localIP.lport	ForeignIP.fport	하나의 client로 제한됨.
localIP.lport	*.*	하나의 local interface(localIP)로 도착하도록 제한됨.
*.lport	*.*	Local port(lport)로 보내진 모든 datagram을 받음.

 

여기서 lport는 서버의 well-known port이고 localIP는 local interface의 IP address이다. 그리고 local end point를 결정할 때는 위 표의 순서대로 시도한다.