TCP/IP詳解讀書筆記（第11章 UDP：用戶數據報協議）

UDP是一個簡單的面向數據報的運輸層協議：進程的每個輸出操作都正好產生一個UDP數據報，并組裝成一份待發送的IP數據報。UDP不提供可靠性：它把應用程序傳給IP層的數據發送出去，但是并不保證它們能到達目的地。UDP數據報封裝格式如圖1所示。

圖1：UDP數據報封裝格式

UDP首部

UDP首部的各字段如圖2所示。

圖2：UDP首部格式

端口號表示發送進程和接收進程。UDP長度字段指的是UDP首部和UDP數據的字節長度。該字段的最小值為8字節（發送一份0字節的UDP數據報是OK）。這個UDP長度是有冗余的。IP數據報長度指的是數據報全長，因此UDP數據報長度是全長減去IP首部的長度。

UDP檢驗和

UDP檢驗和覆蓋UDP首部和UDP數據。回想IP首部的檢驗和，它只覆蓋IP的首部，并不覆蓋IP數據報中的任何數據。UDP的檢驗和是可選的，它是一個端到端的檢驗和。它由發送端計算，然后由接收端驗證。其目的是為了發現UDP首部和數據在發送端到接收端之間發生的任何改動。

IP分片

物理網絡層一般要限制每次發送數據幀的最大長度。任何時候IP層接收到一份要發送的IP數據報時，它要判斷向本地哪個接口發送數據（選路），并查詢該接口獲得其MTU。IP把MTU與數據報長度進行比較，如果需要則進行分片。分片可以發生在原始發送端主機上，也可以發生在中間路由器上。

把一份IP數據報分片以后，只有到達目的地才進行重新組裝（這里的重新組裝與其他網絡協議不同，它們要求在下一站就進行進行重新組裝，而不是在最終的目的地）。重新組裝由目的端的IP層來完成，其目的是使分片和重新組裝過程對運輸層（ TCP和UDP）是透明的，除了某些可能的越級操作外。已經分片過的數據報有可能會再次進行分片（可能不止一次）。IP首部中包含的數據為分片和重新組裝提供了足夠的信息。

使用UDP很容易導致IP分片，圖3為使用UDP時的IP分片示意圖。

圖3：UDP分片示意圖

最大UDP數據報長度

理論上，IP數據報的最大長度是65535字節，這是由IP首部16比特總長度字段所限制的。去除20字節的IP首部和8個字節的UDP首部，UDP數據報中用戶數據的最長長度為65507字節。但是，大多數實現所提供的長度比這個最大值小。

第一，應用程序可能會受到其程序接口的限制。socket API提供了一個可供應用程序調用的函數，以設置接收和發送緩存的長度。對于UDP socket，這個長度與應用程序可以讀寫的最大UDP數據報的長度直接相關。現在的大部分系統都默認提供了可讀寫大于8192字節的UDP數據報（使用這個默認值是因為8192是NFS讀寫用戶數據數的默認值）。

第二個限制來自于TCP/IP的內核實現。可能存在一些實現特性（或差錯），使IP數據報長度小于65535字節。

UDP服務器的設計

典型的服務器與操作系統進行交互作用，而且大多數需要同時處理多個客戶，通常一個客戶啟動后直接與單個服務器通信，然后就結束了。而對于服務器來說，它啟動后處于休眠狀態，等待客戶請求的到來。對于UDP來說，當客戶數據報到達時，服務器蘇醒過來，數據報中可能包含來自客戶的某種形式的請求消息。

1. 客戶IP地址及端口號

來自客戶的是UDP數據報。IP首部包含源端和目的端IP地址，UDP首部包含了源端和目的端的UDP端口號。當一個應用程序接收到UDP數據報時，操作系統必須告訴它是誰發送了這份消息，即源IP地址和端口號。這個特性允許一個交互UDP服務器對多個客戶進行處理。給每個發送請求的客戶發回應答。

2. 目的IP地址

一些應用程序需要知道數據報是發送給誰的，即目的IP地址。

3. UDP輸入隊列

通常程序所使用的每個UDP端口都與一個有限大小的輸入隊列相聯系。這意味著，來自不同客戶的差不多同時到達的請求將由UDP自動排隊。接收到的UDP數據報以其接收順序交給應用程序（在應用程序要求交送下一個數據報時）。

然而，排隊溢出造成內核中的U D P模塊丟棄數據報的可能性是存在的。

4. 端口復用

       每個服務器具有不同的本地I P地址，有可能在相同的端口上啟動不同的服務器，使用sockets API時，必須指定SO_REUSEADDR socket選項。