理論上，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以應用程式讀操作時所要求的長度來傳送資料，因此，在這個介面下，不會發生資料丟失。
速讀原著 TCP IP 用UDP還是用TCP
注意到d n s名字伺服器使用的熟知埠號無論對 u d p還是t c p都是5 3。這意味著d n s均支援u d p和t c p訪問，但我們使用 t c p d u m p觀察的所有例子都是採用 u d p。那麼這兩種協議都在什麼情況下採用以及採用的理由都是什麼呢？當名字解析器發出乙個查詢請求，並...
速讀原著 TCP IP 免費ARP
我們可以看到的另乙個 a r p特性稱作免費arp gratuitous arp 它是指主機傳送a r p查詢自己的i p位址。通常，它發生在系統引導期間進行介面配置的時候。如果傳送免費a r p的主機正好改變了硬體位址 很可能是主機關機了，並換了一塊介面卡，然後重新啟動 那麼這個分組就可以使其他主...
速讀原著 TCP IP 插口排錯選項
檢視乙個t c p連線上發生的事情的另一種方法是使能插口排錯選項，當然是在支援這一特徵的系統中。這個特徵只能工作在 t c p上 其他協議都不行 並且需要應用程式支援 當應用程式啟動時，使能乙個插口排錯選項 大多數伯克利演變的實現都支援這個特徵，包括s u nos 4.4bsd和svr4。程式使能了...