速讀原著-TCP/IP(最大UDP數據報長度)
- 2020 年 3 月 9 日
- 筆記
第11章 UDP：用戶數據報協議
11.10 最大UDP數據報長度
理論上，I P數據報的最大長度是6 5 5 3 5位元組，這是由I P首部（圖3 – 1）1 6比特總長度欄位所限制的。去除 2 0位元組的I P首部和8個位元組的U D P首部，U D P數據報中用戶數據的最長長度為6 5 5 0 7位元組。但是，大多數實現所提供的長度比這個最大值小。
我們將遇到兩個限制因素。第一，應用程式可能會受到其程式介面的限制。 socket API提供了一個可供應用程式調用的函數，以設置接收和發送快取的長度。對於 UDP socket，這個長度與應用程式可以讀寫的最大 U D P數據報的長度直接相關。現在的大部分系統都默認提供了可讀寫大於 8 1 9 2位元組的U D P數據報（使用這個默認值是因為 8 1 9 2是N F S讀寫用戶數據數的默認值）。
第二個限制來自於T C P / I P的內核實現。可能存在一些實現特性（或差錯），使I P數據報長度小於6 5 5 3 5位元組。
作者使用s o c k程式對不同U D P數據報長度進行了試驗。在SunOS 4.1.3下使用環回介面的最大I P數據報長度是3 2 7 6 7位元組。比它大的值都會發生差錯。但是從B S D / 3 8 6到SunOS 4.1.3的情況下，S u n所能接收到最大I P數據報長度為3 2 7 8 6位元組（即3 2 7 5 8位元組用戶數據）。在Solaris 2.2下使用環回介面，最大可收發 I P數據報長度為6 5 5 3 5位元組。從Solaris 2.2到AIX 3.2.2，發送的最大IP數據報長度可以是65535位元組。很顯然，這個限制與源端和目的端的實現有關。
我們在3 . 2節中提過，要求主機必須能夠接收最短為 5 7 6位元組的I P數據報。在許多U D P應用程式的設計中，其應用程式數據被限制成 5 1 2位元組或更小，因此比這個限制值小。例如，我們在1 0 . 4節中看到，路徑資訊協議總是發送每份數據報小於 5 1 2位元組的數據。我們還會在其他U D P應用程式如D N S（第1 4章）、T F T P（第1 5章）、B O O T P（第1 6章）以及S N M P（第2 5章）中遇到這個限制。
數據報截斷 由於I P能夠發送或接收特定長度的數據報並不意味著接收應用程式可以讀取該長度的數據。因此，U D P編程介面允許應用程式指定每次返回的最大位元組數。如果接收到的數據報長度大於應用程式所能處理的長度，那麼會發生什麼情況呢？不幸的是，該問題的答案取決於編程介面和實現。
典型的B e r k e l e y版socket API對數據報進行截斷，並丟棄任何多餘的數據。應用程式何時能夠知道，則與版本有關（4.3BSD Reno及其後的版本可以通知應用程式數據報被截斷）。
S V R 4下的socket API(包括Solaris 2.x) 並不截斷數據報。超出部分數據在後面的讀取中返回。它也不通知應用程式從單個UDP數據報中多次進行讀取操作。TLI API不丟棄數據。相反，它返回一個標誌表明可以獲得更多的數據，而應用程式後面的讀操作將返回數據報的其餘部分。
在討論T C P時，我們發現它為應用程式提供連續的位元組流，而沒有任何資訊邊界。 T C P以應用程式讀操作時所要求的長度來傳送數據，因此，在這個介面下，不會發生數據丟失。
