1. UDP介紹
UDP是一個簡單的面向數(shù)據(jù)報的運輸層協(xié)議：進程的每個輸出操作都正好產(chǎn)生一個 UDP數(shù)據(jù)報，并組裝成一份待發(fā)送的IP數(shù)據(jù)報。這與面向流字符的協(xié)議不同，如TCP，應用程序產(chǎn)生的全體數(shù)據(jù)與真正發(fā)送的單個IP數(shù)據(jù)報可能沒有什么聯(lián)系。
UDP數(shù)據(jù)報封裝成一份 IP數(shù)據(jù)報的格式如圖11 - 1所示。

RFC 768 [Postel 1980] 是UDP的正式規(guī)范。
UDP不提供可靠性：它把應用程序傳給IP層的數(shù)據(jù)發(fā)送出去，但是并不保證它們能到達目的地。由于缺乏可靠性，我們似乎覺得要避免使用UDP而使用一種可靠協(xié)議如TCP。在討論完TCP后將再回到這個話題，看看什么樣的應用程序可以使用UDP。

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

端口號表示發(fā)送進程和接收進程。在圖 1 - 8中，我們畫出了TCP和UDP用目的端口號來分用來自IP層的數(shù)據(jù)的過程。

由于IP層已經(jīng)把IP數(shù)據(jù)報分配給TCP或UDP（根據(jù)I P首部中協(xié)議字段值） ，因此TCP端口號由TCP來查看，而UDP端口號由UDP來查看。TCP端口號與UDP端口號是相互獨立的。
盡管相互獨立，如果TCP和UDP同時提供某種知名服務，兩個協(xié)議通常選擇相同的端口號。這純粹是為了使用方便，而不是協(xié)議本身的要求。
UDP長度字段指的是UDP首部和UDP數(shù)據(jù)的字節(jié)長度。該字段的最小值為 8字節(jié)（發(fā)送一份0字節(jié)的UDP數(shù)據(jù)報是OK） 。這個UDP長度是有冗余的。 IP數(shù)據(jù)報長度指的是數(shù)據(jù)報全長（圖3 - 1） ，因此UDP數(shù)據(jù)報長度是全長減去IP首部的長度（該值在首部長度字段中指定，如圖3 - 1所示）

UDP檢驗和覆蓋UDP首部和UDP數(shù)據(jù)?；叵隝P首部的檢驗和，它只覆蓋IP的首部—并不覆蓋IP數(shù)據(jù)報中的任何數(shù)據(jù)。
UDP和TCP在首部中都有覆蓋它們首部和數(shù)據(jù)的檢驗和。UDP的檢驗和是可選的，而TCP的檢驗和是必需的。
盡管UDP檢驗和的基本計算方法與我們在描述的IP首部檢驗和計算方法相類似（16 bit字的二進制反碼和，但是稍微有所不同，在根據(jù)字段類型判定為UDP或者TCP時加入了一些處理，看代碼就曉得了） ，但是它們之間存在不同的地方。首先， UDP數(shù)據(jù)報的長度可以為奇數(shù)字節(jié)，但是檢驗和算法是把若干個 16 bit字相加。解決方法是必要時在最后增加填充字節(jié)0，這只是為了檢驗和的計算（也就是說，可能增加的填充字節(jié)不被傳送） 。
其次，UDP數(shù)據(jù)報和TCP段都包含一個1 2字節(jié)長的偽首部（本TCP/IP協(xié)議棧有所不同，只加入了4字節(jié)源IP地址和4字節(jié)目的IP地址，即利用IP首部的尾巴，實現(xiàn)了空間上的復用，看代碼就曉得了），它是為了計算檢驗和而設置的。偽首部包含IP首部一些字段。其目的是讓 UDP兩次檢查數(shù)據(jù)是否已經(jīng)正確到達目的地（例如，IP沒有接受地址不是本主機的數(shù)據(jù)報，以及IP沒有把應傳給另一高層的數(shù)據(jù)報傳給UDP） 。UDP數(shù)據(jù)報中的偽首部格式如圖11 - 3所示。

在該圖中，我們特地舉了一個奇數(shù)長度的數(shù)據(jù)報例子，因而在計算檢驗和時需要加上填充字節(jié)(0)。注意，UDP數(shù)據(jù)報的長度在檢驗和計算過程中出現(xiàn)兩次。
如果檢驗和的計算結果為 0，則存入的值為全1（65535） ，這在二進制反碼計算中是等效的。如果傳送的檢驗和為0，說明發(fā)送端沒有計算檢驗和。(因為協(xié)議要求如此，故代碼需要實現(xiàn)之。)如果發(fā)送端沒有計算檢驗和而接收端檢測到檢驗和有差錯，那么 UDP數(shù)據(jù)報就要被悄悄地丟棄。不產(chǎn)生任何差錯報文（當IP層檢測到IP首部檢驗和有差錯時也這樣做）。
UDP檢驗和是一個端到端的檢驗和。它由發(fā)送端計算，然后由接收端驗證。其目的是為了發(fā)現(xiàn)UDP首部和數(shù)據(jù)在發(fā)送端到接收端之間發(fā)生的任何改動。

/*下面闡述UDP校驗和的一些歷史和必要性*/
盡管UDP檢驗和是可選的，但是它們應該總是在用。在 80年代，一些計算機產(chǎn)商在默認條件下關閉UDP檢驗和的功能，以提高使用UDP協(xié)議的NFS（Network File System）的速度。
在單個局域網(wǎng)中這可能是可以接受的，但是在數(shù)據(jù)報通過路由器時，通過對鏈路層數(shù)據(jù)幀進行循環(huán)冗余檢驗（如以太網(wǎng)或令牌環(huán)數(shù)據(jù)幀）可以檢測到大多數(shù)的差錯，導致傳輸失敗。不管相信與否，路由器中也存在軟件和硬件差錯，以致于修改數(shù)據(jù)報中的數(shù)據(jù)。如果關閉端到端的UDP檢驗和功能，那么這些差錯在UDP數(shù)據(jù)報中就不能被檢測出來。另外，一些數(shù)據(jù)鏈路層協(xié)議（如SLIP）沒有任何形式的數(shù)據(jù)鏈路檢驗和。
Host Requirements RFC聲明，UDP檢驗和選項在默認條件下是打開的。它還聲明，如果發(fā)送端已經(jīng)計算了檢驗和，那么接收端必須檢驗接收到的檢驗和（如接收到檢驗和不為0） 。但是，許多系統(tǒng)沒有遵守這一點，只是在出口檢驗和選項被打開時才驗證接收到的檢驗和。