1 / 52

제 11 장

제 11 장. 사용자 데이터그램 프로토콜. Content. Introduction UDP Header UDP Checksum IP Fragmentation ICMP 도달불가 에러[단편화 요구] Traceroute 를 이용한 Path MTU 결정 UDP 를 이용한 Path MTU 발견 UDP 와 ARP 간의 상호 작용 UDP 데이터그램 크기의 최대값 ICMP 발신지 억제 에러 UDP 서버 설계 Summary. Introduction.

tommy
Download Presentation

제 11 장

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 제 11 장 사용자 데이터그램 프로토콜

  2. Content • Introduction • UDP Header • UDP Checksum • IP Fragmentation • ICMP 도달불가 에러[단편화 요구] • Traceroute를 이용한 Path MTU결정 • UDP를 이용한 Path MTU발견 • UDP와 ARP간의 상호 작용 • UDP 데이터그램 크기의 최대값 • ICMP 발신지 억제 에러 • UDP 서버 설계 • Summary

  3. Introduction • Simple, datagram-oriented, transport layer protocol • 프로세스에 의한 output으로 하나의 UDP datagram을 생성 • stream-oriented protocol인 TCP와 다름 • No reliability • 목적지에 도착을 보장하지 못함

  4. UDP Header • Port number • sending process와 receiving process 구별 • UDP와 TCP port는 IP로부터 구별 됨 (figure 1.8) • UDP length: UDP header+data의 길이 • 최소 크기 8 바이트(data가 0일 경우) • IP datagram total length - IP header length

  5. 16-bit source port number 16-bit destination port number 16-bit UDP length 16-bit UDP checksum Data(if any) UDP Header Figure 11.2 UDP header

  6. UDP Checksum • UDP header와 UDP data를 체크 • IP checksum은 IP header만 체크 • IP header checksum과 유사하지만 차이점이 있음 • UDP datagram의 길이는 홀수일 수 있지만, checksum algorithm은 16-bit word • 0값의 pad byte를 붙임으로서 해결 • 12-byte pseudo-header 포함 • 데이터가 보내질 올바른 목적지를 2번 체크

  7. UDP Checksum • UDP checksum 계산 필드 32-bit source IP address 32-bit source IP address zero 8-bit protocol 16-bit UDP length 16-bit source port number 16-bit dest port number 16-bit UDP length 16-bit UDP checksum data Pad byte(0)

  8. UDP Checksum • TCP와 UDP는 헤더에 checksum을 가짐 • UDP는 optional, TCP는 mandatory • UDP는 optional이지만, 항상 checksum을 사용해야 함 • tcpdump Output 1 0.0 sun.1900 > gemini.echo: udp 9 (UDP cksum=6e90) 2 0.303755(0.3038)gemini.echo > sun.1900: udp 9 (UDP cksum =0) 3 17.392480(17.0887) sun.1904 > aix.echo: udp 9 (UDP cksum=6e3b) 4 17.614371(0.2219) axi.echo > sun.1904:udp 9 (UDP cksum=6e3b)

  9. IP Fragmentation • IP fragmentation을 하는 이유 • 데이터 그램의 크기가 물리적인 네트워크 계층이 전송할 수 있는 frame의 최대 크기보다 클때 • Fragmentation 과정 • IP는 상위계층에서 전달받은 IP datagram을 어느 local interface를 통해 전달할 것인지를 결정(MTU를 질의) • MTU와 IP datagram을 비교 • if ( IP datagram > MTU ) then Fragmentation • Fragmentation 발생 위치 • 송신 host 또는 중간 router

  10. IP Fragmentation • Reassemble • 최종 목적지에 도달 후, reassemble됨 • 몇몇 다른 네트워크 프로토콜은 최종 목적지가 아닌 다음 hop에서 reassemble하기도 함 • 목적지의 IP Layer가 수행 • Fragmentation & Reassemble 목적 • 처리 속도를 저하시키지 않는 범위에서 transport layer에서 transparency을 제공하기 위함 • Fragmentation의 재 fragmentation이 가능 • IP header에 reassemble을 위한 정보를 유지

  11. IP Fragmentation • IP header field • Identification field : 송신자가 전송하는 각 IP 데이터그램에 대하여 유일한 값을 포함, 번호는 해당 데이터그램의 각 단편에 복사 • Flags field • more fragment bit : fragment가 더 있다는 것을 의미하기 위함, 마지막 fragment를 제외하고 각 fragment는 이 비트를 set • don’t fragment bit : IP는 datagram을 단편화하지 못함, 그러나 ICMP error를 본래 전송자에게 보냄 (ICMP error : fragmentation이 필요한데 don’t fragment bit가 set되어 있음을 의미) • Fragment offset field : 해당 fragment의 offset을 나타냄

  12. IP Fragmentation • Routing of Fragments • 각각의 fragment는 자신의 IP header를 갖는 독립된 패킷 • 다른 패킷과 독립적으로 전송, 최종 목적지에 다른 순서로 도착할 수 있지만 IP header정보로 재조립 • Fragmentation의 단점 • fragment를 하나라도 분실하면 datagram의 모든 fragment를 재전송 • fragmentation이 중간 router에서 이루어진 경우 발신지는 datagram의 fragmentation정보를 알 수 없음

  13. IP Fragmentation • Example • sock 프로그램을 이용해서 fragmentation이 일어날 때까지 datagram의 크기를 증가시킨다. • Ethernet 의 MTU = 1500 bytes • user data = 1500 - 20(IP header) - 8(UDP header) = 1472 bytes 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

  14. IP Fragmentation • tcpdump output 1 0.0 bsdi.1112 >svr4.discard: udp 1471 2 21.008303 (21.0083) bsdi.1114 >svr4.discard: udp 1472 3 50.449704 (29.4414) bsdi.1116 >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.1118>svr4.discard: udp 1474 (frag 26313:1480@0+) 6. 75.328982 ( 0.0003) bsdi>svr4: (frag 26313:2@1480) • line 1, 2 : not fragmented • line 3, 4, 5, 6 : fragmented • identification number : 26304, 26313 • 1480= 1472(user data)+8(UDP header) - excluding IP header • ‘@’ 다음의 number : offset • + : more fragment , if (not +) then last fragment

  15. IP Fragmentation • 생성된 fragment의 크기는 마지막 fragment를 제외하고 8의 배수가 되어야 함 • 첫번째 fragment를 제외한 나머지는 프로토콜과 source, destination의 port number를 생략함 • terminology • IP datagram : IP Layer에서 종단간 전송의 단위 • packet : IP Layer와 Link layer간에 전달되는 데이터의 단위 packet은 하나의 IP datagram이 되거나 fragment가 될 수 있음

  16. UDP datagram IP header UDP header UDP data (1473 bytes) 20 byte 8 byte IP header UDP header IP header 20 byte 8 byte 20 byte 1 byte 1472 bytes packet packet Figure 11.8 Example of UDP Fragmentation

  17. ICMP Unreachable Error(Fragmentation Required) • router가 fragmentation이 필요한 datagram을 받은 경우, DF flag가 set되어 있을 때 발생 • 목적지까지의 경로에서 가장 작은 MTU를 결정할 필요가 있는 프로그램은 이러한 error를 이용 • (path MTU discovery Mechanism)

  18. Newer Format of ICMP Unreachble Error 0 7 8 15 16 31 type(3) code(4) checksum 8 bytes Unused (must be 0) MTU of next-hop network IP header(including options) + first 8bytes of original IP datagram data Figure 11.9 ICMP unreachable error options)+first 8bytes of original IP datagram data

  19. MTU=1500 MTU=1500 MTU=1500 MTU=1500 SLIP bsdi sun netb solaris MTU=552 MTU=? ICMP echo ping fragment request fragment watch with tcpdump fragmentation Figure 11.10 Systems being used to determine MTU of SLIP link from netb to sun

  20. ICMP Unreachable Error(Fragmentation Required) • tcpdump output on bsdi 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 icmp : solaris unreachable - need to frag, mtu = 0 (DF) 4 0.738400 (0.7384) solaris > bsdi : icmp : echo request (DF) 5. 0.748800 (0.0104) bsdi>solaris : icmp : echo reply (DF) 5. 0.748800 (0.0000) sun>bsdi icmp : solaris unreachable - need to frag, mtu = 0 (DF) • Solaris 2.2 는 대개 DF를 set 한다. 이는 path MTU discovery mechanism의 한 부분이다.

  21. MTU=1500 MTU=1500 MTU=1500 MTU=1500 SLIP bsdi sun netb solaris MTU=552 MTU=? ICMP echo ICMP echo request ICMP echo request request ICMP echo reply ICMP unreachable fragmentation required and DF set Figure 11.12 Packets exchanged in example

  22. Determining the path MTU using Traceroute • path MTU discovery 성질이 없다고 해도, path MTU를 결정하기 위해 traceroute version을 수정할 수 있다. • example scenario • DF set packet을 보냄 • 1번 packet의 크기 = sending interface의 MTU • ICMP “can’t fragment” error를 받을 때 마다 packet의 크기를 줄임 • 만약 ICMP error를 보내는 router가 sending interface의 MTU를 포함하는 새로운 version을 보내면, 이 값을 사용할 것이다. 그렇지 않으면, 다음 작은 MTU를 시도 • RFC 1191에서는 MTU의 수를 제한 -> 본 프로그램은 유사한 테이블을 갖고 있어서 다음 작은 값으로 시도 • sun -> slip (SLIP link MTU = 295)

  23. Determining the path MTU using Traceroute • traceroute output (sun -> slip) sun % traceroute.pmtu slip traceroute to slip (140.252.13.65), 30 hop max outgoing MTU =1500 1 bsdi (140.252.13.35) 15 ms 6ms 6ms 2 bsdi (140.252.13.35) 6 ms fragmentation required and DF set, trying new MTU = 1492 fragmentation required and DF set, trying new MTU = 1006 fragmentation required and DF set, trying new MTU = 576 fragmentation required and DF set, trying new MTU = 552 fragmentation required and DF set, trying new MTU = 544 fragmentation required and DF set, trying new MTU = 512 fragmentation required and DF set, trying new MTU = 508 fragmentation required and DF set, trying new MTU = 296 2 slip (140.252.13.65) 377 ms 377 ms 377ms

  24. Determining the path MTU using Traceroute • Modify ICMP code on bsdi • sun % traceroute.pmtu slip traceroute to slip (140.252.13.65), 30 hop max outgoing MTU = 1500 1 bsdi (140.252.13.35) 53ms 6ms 6ms 2 bsdi (140.252.13.35) 6ms fragmentation required and DF set, Next hop MTU = 296 2 slip (140.252.13.65) 377ms 378MS 377 MS • 올바른 MTU를 찾기 전에 8개의 다른 값으로 시도할 필요없다. • router는 제대로 된 값을 전달한다.

  25. Path MTU Discovery with UDP • UDP를 이용하는 application과 path MTU discovery mechanism 간의 상호작용을 알아본다. • Example • application이 중간의 link에 대해서 상당히 큰 datagram을 write 한다 • solaris : source host, slip : destination host • sending data : solaris -> slip • size of data : 650 bytes • SLIP link MTU behind slip : 296 • 268 byte (296-20-8) 이상되는 UDP datagram( DF set)은 router bsdi 가 ICMP error를 생성하게 한다. • solaris % sock -u -i -n10 -w650 slip discard

  26. run tcpdump here MTU=1500 MTU=1500 MTU=1500 MTU=1500 SLIP SLIP slip bsdi sun netb solaris MTU=296 MTU=296 MTU=552 MTU=1500 650-byte UDP datagram with DF bit set ICMP can’t fragment error Figure 11.13 Systems used for path MTU discovery using UDP

  27. tcpdump output on sun 1 0.0 solaris.36196>slip.discard:udp 650 (DF) 2 0.004218 (0.0042) bsdi>solaris: icmp: slip unreachable - need to frag, mtu=0 (DF) 3 4.980528 (4.9763) solaris.36196>slip.discard:udp 650 (DF) 4 4.984503 (0.0040) bsdi>solaris: icmp: slip unreachable - need to frag, mtu=0 (DF) 5 9.870407 (4.9763) solaris.36196>slip.discard:udp 650 (frag 47942:552@0+) 6 9.960056 (0.0896) solaris>slip: (frag 47942:106@552) 7 14.940338 (4.9763) solaris.36196>slip.discard:udp 650 (DF) 8 14.944466 (0.0040) bsdi>solaris: icmp: slip unreachable - need to frag, mtu=0 (DF) 9 19.890015 (4.9763) solaris.38196>slip.discard:udp 650 (frag 47944:552@0+) 10 19.950463 (0.0604) solaris>slip: (frag 47944:106@552) 19 44.940485 (5.0100) solaris.36196>slip.discard:udp 650 (DF) 20 44.944432 (0.0040) bsdi>solaris: icmp: slip unreachable - need to frag, mtu=0 (DF)

  28. Path MTU Discovery with UDP • tcpdump output on slip 1 0.0 solaris.38196>slip.discard: udp 650 (frag 47942:272@0+) 2 0.304513 (0.3045) solaris>slip: (frag 47942:272@272+) 3 0.334651 (0.0301) solaris>slip: (frag 47942:8@544+) 4 0.0.1320 (0.1320) solaris>slip: (frag 47942:106@552) • solaris는 fragmetation(x), but DF bit를 off

  29. Path MTU Discovery with UDP • Modify router bsdi • return next-hop MTU(ICMP error) 1 0.0 solaris.37974>slip.discard: udp 650 (DF) 2 0.004199 (0.0042) bsdi>solaris: icmp : slip unreachable - need to frag, mtu = 296 (DF) 3 4.950193 (4.9460) solaris. 37974>slip.discard: udp 650 (DF) 4 4.954325 (0.0041) bsdi>solaris: icmp : slip unreachable - need to frag, mtu = 296 (DF) 5 9.779855 (4.8255) solaris.37974>slip.discard:udp 650 (frag 35278:272@0+) 6 9.930018 (0.1502) solaris>slip: (frag 35278:272 @272+) 7 9.990170 (0.0602) solaris>slip: (frag 35278:114 @544) source host가 fragmentation 실행

  30. Interaction Between UDP and ARP • UDP와 ARP의 상호작용을 알아본다. • Example • sock 프로그램을 사용해서 8192 byte를 생성 • Ethernet 상에서 6개의 fragment로 나뉘어 질것이다. • 프로그램 실행 전에 ARP cache가 비어있는지 확인 • 첫 번째 fragment가 전송되기 전에 ARP request와 reply가 교환되어야 한다 • bsdi % arp -a • bsdi % sock -u -iI -w8192 svr4 discard • 첫 번째 fragment는 ARP request를 전송하도록 유도 • 나머지 fragment들은 reply가 오기전에 전송준비

  31. Interaction Between UDP and ARP • tcpdump output 1 0.0 arp who-has svr4 tell bsdi 2 0.001234 (0.0012) 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.0041) arp reply svr4 is-at 0:0:c0:c2:9b:26 • reply가 돌아오기 전에 6개의 ARP request가 생성되었다. 이는 6개의 fragment는 빠르게 생성이 되었고 각각의 fragment에 의해서 ARP request가 생성되었다. • last packet 만이 전송되었다.

  32. Interaction Between UDP and ARP • ICMP error는 전송되지 않았다. • IP layer는 반드시 첫번째 fragment가 도착할 때 timer를 start시켜야 한다. • “first” : first arrival fragment, not first fragment • timer가 종료될 때 까지 해당 datagram의 모든 fragment가 도착하지 않았다면, 모든 fragment들은 discard될 것이다. • 그렇지 않으면 수신자의 buffer가 넘치게 되는 결과를 초래할 것이다. • ICMP error가 전송되지 않은 이유 • Berkely : timer가 종료되어, 모든 fragment를 거부 • other : first fragment가 도착되지 않았기 때문

  33. Maximum UDP Datagram Size • 이론상, IP datagram의 최대 크기는 65535 bytes • lenth field : 16 bit -> 216 - 1 • UDP datagram에서 User data의 최대 크기는 65507 bytes • 65507 = 65535 - IP header(20) - UDP header(8)

  34. ICMP source Quench Error • 처리할 수 없을 정도로 빠르게 datagram을 받을 때, system(host or router)에 의해서 생성되기도 한다. • 시스템의 buffer가 넘쳐서 datagram을 버릴지라도 “source quench”의 전송은 반드시 이루어져야 하는 아니다. • Example • bsdi -> sun : Ethernet, sun -> : SLIP • SLIP link = 100 * Ethernet link 이기 때문에 sun의 버퍼가 쉽게 넘칠 것이다. • 100개의 1024-byte datagram을 전송 : bsdi -> sun -> solaris • bsdi % sock -u -i -w1024 -n 100 solaris discard

  35. ICMP source Quench Error 0 7 8 15 16 31 type(4) code(0) checksum 8 bytes Unused (must be 0) IP header(including options) + first 8bytes of original IP dagagram data Figure 11.18 ICMP source quench error

  36. ICMP source Quench Error • tcpdump output 1 0.0 bsdi.1403 > solaris.discard:udp 1024 26 lines thar we don’t show 27 0.10 (0.00) bsdi.1403>solaris.dicard: udp 1024 28 0.11 (0.01) sun>bsdi: icmp: source quench 29 0.11 (0.00) bsdi.1403>solaris.discard:udp 1024 30 0.11 (0.00) sun>bsdi: icmp: source quench 142 lines thar we don’t show 173 0.71 (0.06) bsdi.1403>solaris.discard:udp 1024 174 0.71 (0.00) sun>bsdi: icmp: source quench

  37. ICMP source Quench Error • 26개의 datagram은 에러없이 전송, but 27번째 datagram부터는 전송할 때마다 error 에러를 받는다. • original tcpdump ouptut • 26+(74(버려진 datagram)*2(line))=174 • 전송 시간 • sun -> solaris(SLIP) : 9600 bits/sec 로 1024byte 전송하는데 걸리는 시간은 1초 조금 넘게 걸린다. • bsdi->sun(Ethernet) : 100개의 datagram이1초 이내에 sun에 도착한다.(첫번째 datagram이 SLIP Link를 통과하기 전에)

  38. UDP Server Design • UDP를 이용하는 서버의 설계 및 구현시 고려사항 • Client IP Address and Port Number • Destination IP Address • UDP Input Queue • Restricting Local IP Address • Restricting Foreign IP Address • Multiple Recipients per Port • 서버의 설계 및 구현은 대개 클라이언트 보다 어렵다. • O/S와의 interaction, 동시에 여러 클라이언트들을 처리 • Protocol 특성이라는 측면에서 다룬다.

  39. UDP Server Design • Client IP Address and Port Number • 서버에 클라이언트의 UDP datagram이 도착 • IP header = Source IP Addr. + Destination IP Addr. • UDP header = Source Port Num. + Destication Port Num • 서버의 O/S는 Source IP Addr.와 Port Num.을 통해서, 도착한 메시지의 발신지를 알 수 있다. • 동시에 여러 클라이언트를 처리가능하게 한다. • Source Addr.과 Port Num.을 통해서 각각의 request에 대한 반복을 가능하게 한다.

  40. UDP Server Design • Destination IP Address • 몇몇 application들은 datagram이 어디로 전송되는지를 알고자 한다. • Host Requirement RFC • TFTP server는 반드시 Destination 주소가broadcast 주소로 된 datagram은 무시한다. • 이는 O/S가 수신된 UDP datagram의 destination IP 주소를 Application에 넘기도록 요구한다. • 모든 application이 이 기능을 제공하는 것은 아니다.

  41. UDP Server Design • UDP Input Queue • 필요성 • UDP 서버는 단일 port를 통해서 모든 클라이언트의 요청을 처리한다. • 각 UDP port와 관계된 제한된 크기의 Input queue가 존재 • 여러 클라이언트로부터 동시에 도착한 요청들이 자동적으로 UDP에 의해서 Queue에 저장된다. • Application에 Datagram 전달 순서 • 도착한 순서대로 전달.(FIFO) • Queue Overfolw가 발생하면, 커널의 UDP module이 incoming datagram을 무시한다.

  42. UDP Server Design • example of Input Queue overflow 서버 bsdi bsdi % sock -s -u -v -E -R256 -r256 -P30 6666 from 140.252.13.33, to 140.252.13.63 : 11111111111 from sun, to broadcast address from 140.252.13.34, to 140.252.13.35 : 444444444444 from sun, to broadcast address 클라이언트 sun sun % sock -u -v 140.252.13.63 6666 to Ethernet broadcat address connected on 140.252.13.33.1258 to 140.252.13.63.6666 1111111111 11 bytes of data (with newline) 222222222 10 bytes of data (with newline) 33333333333 12 bytes of data (with newline)

  43. UDP Server Design 클라이어트 svr4 svr4 % sock -u -v bsdi 6666 connected on 0.0.0.0.1042 to 140.252.13.35.6666 4444444444444 14 bytes of data (with newline) 555555555555555 16 bytes of data (with newline) 66666666 9 bytes of data (with newline) • tcpdump output 1 0.0 sun.1252 > 140.252.13.63.6666: UDP 11 2 2.499484 (2.4992) svr4.1042 > bsdi.6666: UDP 14 3 4.959166 (2.4600) sun.1252 > 140.252.13.63.6666: UDP 10 4 7.607149 (2.4992) svr4.1042 > bsdi.6666: UDP 16 5 10.079059 (2.4719) sun.1252 > 140.252.13.63.6666: UDP 12 6 12.415943 (2.3369) svr4.1042 > bsdi.6666: UDP 9

  44. UDP Server Design • Input Queue Overflow 발생시, UDP는 application에 알리지 않는다. • 초과된 datagram들은 UDP에 의해서 거절된다. • datagram이 거절되었다는 것을 클라이언트에게 알리지 않는다. • UDP Input Queue는 FIFO(first-in, first-out)

  45. UDP Server Design • Restricting Local IP Address • 대부분의 UDP 서버들은 UDP end point를 생성할때, 자신들의 local IP 주소를 wildcard로 한다. • 서버의 port로 들어오는 UDP datagram은 어떤 local interface에서 든지 받아들여 진다. • Example sun % sock -u -s 7777 sun % netstat -a -n -f inet Active Internet Connections (including sercers) proto Recv-Q Send-Q Local Address Foreign Address (state) udp 0 0 *.7777 *.* flag -a : reports on all network end points, -n : print IP addr. as decimal number -f net : report only TCP and UDP end point

  46. UDP Server Design • 서버가 자신의 end point를 생성시, end point에 대한 local IP addr.로 호스트의 local IP address 중 하나를 명시하는 것이 가능. • if (destination addr. = specified local addr.), incomming datagram이 end point에 pass 됨. • Example sun % sock -u -s 140.252.1.29 7777 proto Recv-Q Send-Q Local Address Foreign Address (state) udp 0 0 *.7777 *.* tcpdump output 1 0.0 bsdi.1723 > sun.7777: UDP 13 2 0.000822 (0.0008) sun > bsdi: icmp: sun udp port 7777 unreachable

  47. UDP Server Design • 동일한 port에 다른 local IP addr.를 갖는 Server • 대개, 동일한 port를 재사용한다 라는 것을 Application에 알려야 한다. • Example 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) 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 *.*

  48. UDP Server Design • Priority • wildcard address를 갖는 end point가 있다면, 묵시적인 우선순위가 존재. • “destination IP addr. = specific IP addr” 인 종단점은 wildcard보다 먼저 선택된다. • match되는 것이 없을 경우에만 wildcard end point가 이용된다.

  49. UDP Server Design • Restricting Foreign IP Address • 대부분의 implementations 경우, UDP end point로 하여금 foreign addr.를 제한. • end point는 명시한 IP addr.과 port로 부터만 datagram을 수신. • Example sun % sock -u -s -f 140.252.13.35.4444 5555 proto Recv-Q Send-Q Local Address Foreign Address (state) udp 0 0 140.252.13.33.5555 140.252.13.35.4444

  50. UDP Server Design • Multiple Recipients Per Port • 대부분의 implementation • An application end point - An local Addr.& port number • Example sun % sock -u -s 9999 sun % sock -u -s 9999 we expect this to fail can’t bind local address: Address Already in use sun % sock -u -s -A 9999 so we try -A flag this time can’t bind local address: Address Already in use

More Related