速讀原著-TCP/IP(採用UDP的路徑MTU發現)
- 2020 年 3 月 9 日
- 筆記
第11章 UDP：用戶數據報協議
11.8 採用UDP的路徑MTU發現
下面對使用U D P的應用程式與路徑 M T U發現機制之間的交互作用進行研究。看一看如果應用程式寫了一個對於一些中間鏈路來說太長的數據報時會發生什麼情況。
例子 由於我們所使用的支援路徑 M T U發現機制的唯一系統就是Solaris 2.x，因此，將採用它作為源站發送一份6 5 0位元組數據報經s l i p。由於s l i p主機位於M T U為2 9 6的S L I P鏈路後，因此，任何長於2 6 8位元組（2 9 6－2 0－8）且「不分片」比特置為 1的U D P數據都會使b s d i路由器產生I C M P「不能分片」差錯報文。圖 11 – 1 3給出了拓撲結構和M T U。
可以用下面的命令行來產生 6 5 0位元組U D P數據報，每兩個U D P數據報之間的間隔是5秒：
solaris % sock -u -i -n10 -w650 -p5 slip discard
圖11 – 1 4是t c p d u m p的輸出結果。在運行這個例子時，將b s d i設置成在I C M P「不能分片」差錯中，不返回下一跳M T U資訊。
在發送的第一個數據報中將 D F比特置1（第1行），其結果是從b s d i路由器發回我們可以猜測的結果（第 2行）。令人不解的是，發送一個 D F比特置1的數據報（第 3行），其結果是同樣的I C M P差錯（第4行）。我們預計這個數據報在發送時應該將 D F比特置0。 第5行結果顯示，I P已經知道了發往該目的地址的數據報不能將 D F比特置1，因此，I P進而將數據報在源站主機上進行分片。這與前面的例子中， I P發送經過U D P的數據報，允許具有較小M T U的路由器（在本例中是 b s d i）對它進行分片的情況不一樣。由於 I C M P「不能分片」報文並沒有指出下一跳的 M T U，因此，看來I P猜測M T U為5 7 6就行了。第一次分片（第 5 行）包含5 4 4位元組的U D P數據、8位元組U D P首部以及2 0位元組I P首部，因此，總 I P數據報長度是5 7 2位元組。第2次分片（第6行）包含剩餘的1 0 6位元組U D P數據和2 0位元組I P首部。
不幸的是，第7行的下一個數據報將其 D F比特置1，因此b s d i將它丟棄並返回 I C M P差錯。這時發生了 I P定時器超時，通知 I P查看是不是因為路徑 M T U增大了而將 D F比特再一次置 1。我們可以從第1 9行和2 0行看出這個結果。將第 7行與1 9行進行比較，可以看出 I P每過3 0秒就將D F比特置1，以查看路徑M T U是否增大了。
這個3 0秒的定時器值看來太短。 R F C 11 9 1建議其值取 1 0分鐘。可以通過修改i p _ i r e _ p a t h m t u _ i n t e r v a l（E . 4節）參數來改變該值。同時，Solaris 2.2無法對單個U D P應用或所有U D P應用關閉該路徑M T U發現。只能通過修改i p _ p a t h _ m t u _ d i s c o v e r y參數，在系統一級開放或關閉它。正如在這個例子里所能看到的那樣，如果允許路徑M T U發現，那麼當U D P應用程式寫入可能被分片數據報時，該數據報將被丟棄。
s o l a r i s的I P層所假設的最大數據報長度（ 5 7 6位元組）是不正確的。在圖 11 – 1 3中，我們看到，實際的 M T U值是2 9 6位元組。這意味著經 s o l a r i s分片的數據報還將被 b s d i分片。圖11 – 1 5給出了在目的主機（ s l i p）上所收集到的 t c p d u m p對於第一個到達數據報的輸出結果（圖11 – 1 4的第5行和第6行）。
在本例中，s o l a r i s不應該對外出數據報分片，它應該將 D F比特置0，讓具有最小M T U的路由器來完成分片工作。
現在我們運行同一個例子，只是對路由器 b s d i進行修改使其在 I C M P「不能分片」差錯中返回下一跳M T U。圖11 – 1 6給出了t c p d u m p輸出結果的前6行。
與圖11 – 1 4一樣，前兩個數據報同樣是將 D F比特置1後發送出去的。但是在知道了下一跳M T U後，只產生了3個數據報片，而圖11 – 1 5中的b s d i路由器則產生了4個數據報片。
