1、UDP協(xié)議第二組張顯帥需要解決的問題：1.掌握UDP首部字段、及IP分片過程2.掌握用Traceroute來確定路徑MTU及采用UDP進(jìn)行路徑MTU發(fā)現(xiàn)3.掌握UDP協(xié)議的特性用戶數(shù)據(jù)報協(xié)議： 用戶數(shù)據(jù)報協(xié)議 (User Datagram Protocol, UDP)是一個簡單的面向無連接的，不可靠的數(shù)據(jù)報的傳輸層協(xié)議。 在TCP/IP模型中，UDP為網(wǎng)絡(luò)層以上和應(yīng)用層以下提供了一個簡單的接口。UDP只提供數(shù)據(jù)的不可靠交付，它一旦把應(yīng)用程序發(fā)給網(wǎng)絡(luò)層的數(shù)據(jù)發(fā)送出去，就不保留數(shù)據(jù)備份（所以UDP有時候也被認(rèn)為是不可靠的數(shù)據(jù)報協(xié)議）。UDP在IP數(shù)據(jù)報的頭部僅僅加入了復(fù)用和數(shù)據(jù)校驗(yàn)（字段）。由于缺

2、乏可靠性，UDP應(yīng)用一般必須允許一定量的丟包、出錯和復(fù)制UDP封裝：源端口（源端口（Source Port）目的端口（目的端口（Destination Port）長度（Length）校驗(yàn)和（Checksum）數(shù)據(jù)（Data）IP頭頭UDP頭頭載荷數(shù)據(jù)載荷數(shù)據(jù)UDP數(shù)據(jù)報IP包UDP頭格式（1）源端口：用于標(biāo)識數(shù)據(jù)報的源端進(jìn)程，字段長度為16比特，最大支持64 k個端口號。源端進(jìn)程不需要目的端返回數(shù)據(jù)報，源端口字段可設(shè)為0（2）目的端口：目的端進(jìn)程所使用的端口，字段長度為16比特，最大支持64 k個端口號。（3）長度：16位的長度字段，表明包括UDP頭和數(shù)據(jù)在內(nèi)的整個UDP數(shù)據(jù)報的長度。（4）校

3、驗(yàn)和：16位的錯誤檢查字段，基于部分IP頭信息，UDP頭和載荷數(shù)據(jù)的內(nèi)容計算得到，用于檢測傳輸過程中出現(xiàn)的錯誤。UDP協(xié)議的特性：特點(diǎn)：1、UDP是無連接的。UDP在傳輸數(shù)據(jù)前不與對方建立連接，在傳輸數(shù)據(jù)前發(fā)送方和接收方程序需自行相互交換信息使雙方同步。2、UDP不對收到的數(shù)據(jù)進(jìn)行排序。在UDP報文的首部中并沒有關(guān)于數(shù)據(jù)順序的信息，由于IP報文并不一定按照順序到達(dá)，接收端也無從排序。3、UDP對接收到的數(shù)據(jù)報不發(fā)送確認(rèn)，發(fā)送端不知道數(shù)據(jù)是否被正確接收，也不會重發(fā)數(shù)據(jù)。4、UDP傳輸數(shù)據(jù)較快，系統(tǒng)開銷少5、UDP沒有擁塞控制機(jī)制。UDP與TCP對比：功能項TCPUDP連接服務(wù)類型面向連接面向無連

4、接維護(hù)連接狀態(tài)維持端到端的連接狀態(tài)不維持連接狀態(tài)對應(yīng)用層數(shù)據(jù)的封裝對應(yīng)用層數(shù)據(jù)進(jìn)行分段和封裝，用端口號標(biāo)識應(yīng)用程序?qū)碜詰?yīng)用層數(shù)據(jù)直接封裝為數(shù)據(jù)報，用端口表示應(yīng)用程序數(shù)據(jù)傳輸通過序列號和應(yīng)答機(jī)制保證可靠傳輸不確?？煽總鬏斄髁靠刂剖褂没瑒哟翱跈C(jī)制控制流量無流量控制機(jī)制UDP分片：總長8192的UDP數(shù)據(jù)報IP首部 Data（8176）20IP首部 Data（1472）1500有一個以太網(wǎng)和一份8192字節(jié)的UDP數(shù)據(jù)報，那么需要分成多少個數(shù)據(jù)報片？UDP首部（8）UDP首部820IP首部 Data（1480）150020IP首部 Data（784）804205個注：以太網(wǎng)MTU=1500第一片偏

5、移值是 0第一片偏移值是 1500路徑MTU：如果兩臺主要之間的通信要通過不同的多個網(wǎng)絡(luò)，那么每個網(wǎng)絡(luò)的鏈路層就可能有不同的MTU。這里不同的網(wǎng)絡(luò)指的是，例如：以太網(wǎng)，令牌環(huán)網(wǎng)，F(xiàn)DDI（光纖分布式數(shù)據(jù)接口）這類的網(wǎng)絡(luò) 。而這個時候進(jìn)行數(shù)據(jù)的通信時，重要的不是兩臺主機(jī)的所在網(wǎng)絡(luò)的MTU的值，重要的是兩臺通信主機(jī)路徑中的最小MTU，被稱作路徑MTU，也被寫作PMTU。它等于路徑上每一跳的MTU之中的最小值。兩臺主機(jī)之間的路徑MTU不一定是個常數(shù)，它取決于當(dāng)時所選擇的路由。而選路不一定是對稱的，也就是從A到B的路徑路由和從B到A的路徑路由不一定相同，因此路徑MTU在兩個方向上不一定是一致的。Tra

6、ceroute來確定路徑MTU：大多數(shù)的系統(tǒng)不支持路徑MTU發(fā)現(xiàn)功能，但可以很容易地修改traceroute程序，用它來確定路徑MTU。要做的是發(fā)送分組，并設(shè)置“不分片”標(biāo)志比特。發(fā)送的第一個分組的長度正好與出口MTU相等，每次收到ICMP“不能分片”差錯時就減小分組的長度。 如果路由器發(fā)送的ICMP差錯報文是新格式，包含出口的MTU，那么就用該MTU值來發(fā)送，否則就用下一個最小的MTU值來發(fā)送。 MTU值的個數(shù)是有限的，因此在我們的程序中有一些由近似值構(gòu)成的表，取下一個最小MTU值來發(fā)送。UDP進(jìn)行路徑MTU發(fā)現(xiàn)：在此例中solaris向slip發(fā)送650字節(jié)的udp包由于slip主機(jī)位于M

7、TU為296的SLIP鏈路后，因此，任何長于268字節(jié)（296208）且“不分片”比特置為1的UDP數(shù)據(jù)都會使bsdi路由器產(chǎn)生ICMP“不能分片”差錯報文。UDP進(jìn)行路徑MTU發(fā)現(xiàn)：運(yùn)行這個例子時，將bsdi設(shè)置成在ICMP“不能分片”差錯中，不返回下一跳MTU信息。就是說bsdi產(chǎn)生一份老格式的icmp報文。 在發(fā)送的第一個數(shù)據(jù)報中將DF比特置1（第1行） 第二行bsdi路由器向源端返回一個icmp包，注意這里的mtu是0。 源端solaris現(xiàn)在已經(jīng)知道了發(fā)往該目的地址的數(shù)據(jù)報不能將DF比特置1，因此，IP進(jìn)而將數(shù)據(jù)報在源站主機(jī)上進(jìn)行分片，由于ICMP“不能分片”報文并沒有指出下一跳的M

8、TU，因此，看來IP猜測MTU為576就行了。第一次分片（第5行）包含544字節(jié)的UDP數(shù)據(jù)、8字節(jié)UDP首部以及20字節(jié)IP首部，因此，總IP數(shù)據(jù)報長度是 572字節(jié)。第2次分片（第6行）包含剩余的106字節(jié)UDP數(shù)據(jù)和20字節(jié)IP首部。 不幸的是，第7行的下一個數(shù)據(jù)報將其DF比特置1，因此bsdi將它丟棄并返回ICMP差錯。 UDP進(jìn)行路徑MTU發(fā)現(xiàn)：這是因?yàn)榘l(fā)生了IP定時器超時，通知IP查看是不是因?yàn)槁窂組TU增大了而將DF比特再一次置1。 我們可以從第19行和20行看出這個結(jié)果。將第7行與19行進(jìn)行比較，可以看出IP每過30秒就將DF比特置1，以查看路徑MTU是否增大了。 這個30秒的

9、定時器值看來太短。RFC1191建議其值取10分鐘。 solaris的IP層所假設(shè)的最大數(shù)據(jù)報長度（576字節(jié)）是不正確的。在圖中，我們看到，實(shí)際的MTU值是296字節(jié)。這意味著經(jīng)solaris分片的數(shù)據(jù)報還將被bsdi分片。UDP進(jìn)行路徑MTU發(fā)現(xiàn)：本圖給出了在目的主機(jī)（slip）上所收集到的tcpdump對于第一個到達(dá)數(shù)據(jù)報的輸出結(jié)果?？梢钥闯鲈趕lip主機(jī)上的收到的包是被bsdi又重新分了片的 第1行是272 第2行是272 第3行是8 第4行是106 滑動窗口協(xié)議： 滑動窗口是一種流量控制技術(shù)。早期的網(wǎng)絡(luò)通信中,通信雙方不會考慮網(wǎng)絡(luò)的擁擠情況直接發(fā)送數(shù)據(jù)。由于大家不知道網(wǎng)絡(luò)擁塞狀況，一

10、起發(fā)送數(shù)據(jù),導(dǎo)致中間結(jié)點(diǎn)阻塞掉包,誰也發(fā)不了數(shù)據(jù)。所以就有了滑動窗口機(jī)制來解決此問題。Host AHost BDATA（seq=1，len=1024）DATA（seq=1025，len=1024）DATA（seq=2049，len=1024）DATA（seq=3073，len=1024）ACK（ack=4079，win=2048）Host AHost BDATA（seq=4097，len=1024）DATA（seq=5121，len=1024）DATA（seq=7169，len=1024）DATA（seq=6145，len=1024）ACK（ack=6145，win=2048）要求減小窗口滑動

11、窗口協(xié)議：1、假定初始發(fā)送窗口大小為4096，每個段的數(shù)據(jù)為1024B，則主機(jī)A每次發(fā)送4個段給主機(jī)B；2、主機(jī)B正確接收到這些數(shù)據(jù)后，以確認(rèn)號4097進(jìn)行確認(rèn)；3、主機(jī)B由于緩存不足或處理能力有限，認(rèn)為發(fā)送速度過快期望窗口降低一半；4、主機(jī)B在回送的確認(rèn)中將窗口尺寸降低到2048，要求主機(jī)A每次只發(fā)送2048B；5、主機(jī)A收到確認(rèn)后，按照要求降低發(fā)送窗口尺寸，一次只發(fā)兩段，降低發(fā)送速度。滑動窗口協(xié)議是用來改善吞吐量的一種技術(shù)，即容許發(fā)送方在接收任何應(yīng)答之前傳送附加的包。接收方告訴發(fā)送方在某一時刻能送多少包（稱窗口尺寸），若接收方要求窗口大小為0，則代表接收方已接收全部數(shù)據(jù)，或接收方應(yīng)用程序沒有時間讀取數(shù)據(jù)，要求暫停發(fā)送，可滑動窗口協(xié)議解決了端到端流量控制的問題，但無法干預(yù)網(wǎng)絡(luò)。UDP需要滑動窗口協(xié)議嗎？UDP是不可靠的，本身缺乏擁塞控制機(jī)制，如果想實(shí)現(xiàn)可靠文件傳輸，需要加入額外的機(jī)制來確?？煽俊?yōu)點(diǎn)：1、實(shí)現(xiàn)擁塞控制，避免丟包2、實(shí)現(xiàn)可靠文件傳輸缺點(diǎn)：1、加大系統(tǒng)開銷，提高CPU占用率2、延遲大，由于需要等待確認(rèn)和超時面向連接和無連接協(xié)議：面向連接的服務(wù)：就是通信雙方在通信時，要事先建立一條通信線路，其過程有建立連接、使用連接和釋放連接三個過程。TCP協(xié)議就是一種面向連接