一、進程到進程的通信 在學習UDP協議之前，首先應該了解主機到主機的通信和進程到進程的通信，以及這兩種通信之間的區别。

IP協議負責主機到主機的通信。作為一個網絡層協議，IP協議隻能把報文交付給目的主機。這是一種不完整的交付，因為這個報文還沒有送交到正确的進程。像UDP這樣的傳輸層協議負責進程到進程的通信。UDP協議負責把報文交付到正确的進程。下圖描繪了IP協議和UDP協議的作用範圍。

圖6-1 UDP與IP的區别

1.端口号

在網絡中，主機是用IP地址來标識的。而要标識主機中的進程，就需要第二個标識符，這就是端口号。在TCP/IP協議族中，端口号是在0～65535之間的整數。

在客戶/服務器模型中，客戶程序使用端口号标識自己，這種端口号叫做短暫端口号，短暫的意思是生存時間比較短。一般把短暫端口取為大于1023的數，這樣可以保證客戶程序工作得比較正常。 服務器進程也必須用一個端口号标識自己。但是這個端口号不能随機選取。如果服務器随機選取端口号，那麼客戶端在想連接到這個服務器并使用其服務的時候就會因為不知道這個端口号而無法連接。TCP/IP協議族采用熟知端口号的辦法解決這個問題。每一個客戶進程都必須知道相應的服務器進程熟知端口号。 UDP的熟知端口号如下表所示：

表6-1 UDP的熟知端口号

在一個IP數據包中，目的IP地址和端口号起着不同的尋址作用。目的IP地址定義了在世界範圍内惟一的一台主機。當主機被選定後，端口号定義了在這台主機上運行的多個進程中的一個。

2.套接字地址

一個IP地址與一個端口号結合起來就叫做一個套接字地址。客戶套接字地址惟一地定義了客戶進程，而服務器套接字地址惟一地定義了服務器進程。 要使用UDP的服務，就需要一對套接字地址：客戶套接字地址和服務器套接字地址。客戶套接字地址指定了客戶端的IP地址和客戶進程，服務器套接字地址指定了服務器的IP地址和服務器進程。二、面向連接的服務與面向無連接的服務

從通信的角度來看，在OSI參考模型中，下層能向上層提供兩種不同形式的服務：面向連接的服務和面向無連接的服務。1.面向連接的服務

所謂連接，就是兩個對等實體為進行數據通信而進行的一種結合。面向連接服務在進行數據交換前，先建立連接。當數據傳輸結束後，應釋放這個連接。因此，采用面向連接的服務進行數據傳送要經曆三個階段： （1）建立連接階段：在有關的服務原語以及協議數據單元中，必須給出源用戶和目的用戶的完整地址。同時可以協商服務質量和其它一些選項。 （2）數據交換階段：在這個階段，每個報文中不必包含完整的源用戶和目的用戶的完整地址，而是使用一個連接标識符來代替。由于連接标識符相對于地址信息要短得多，因此使控制信息在報文中所占的比重相對減小，從而可減小系統的額外開銷，提高信道的有效利用率。另外，報文的發送和接收都是按固定順序的，即發送方先發送的報文，在接受方先收到。 （3）釋放連接階段：通過相應的服務原語完成釋放操作。 從面向連接服務的三個階段來看，連接就像一個管道，發送端在其一端依次發送報文，接收者依次在其另一端按同樣的順序接收報文。這種連接又稱虛拟電路。它可以避免報文的丢失、重複和亂序。 若兩個用戶經常需要通信，則可以建立永久虛電路。這樣可以免除每次通信時建立連接和釋放連接這兩個階段。這點與電話網中的專線很相似。2.面向無連接的服務

在面向無連接服務的情況下，兩個實體之間的通信不必事先建立一個連接。相對于面向連接的服務，面向無連接服務靈活方便且快速。但它不能防止報文的丢失、重複和亂序。由于它的每個報文必須包括完整的源地址的目的地址，因此開銷較大。 面向無連接服務主要有三種類型： （1）數據報：它的特點是發完報文就結束，而對方不做任何響應。數據報的服務簡單，額外開銷少，但可靠性差，它比較适合于數據具有很大的冗餘度以及要求有較高的實時性的通信場合。 （2）證實交付：又稱可靠的數據報。這種服務對每一個報文産生一個證實給發送方，不過這種證實不是來自對應方用戶，而是來自提供服務的層。這種證實隻能保證報文已經發給目的站了，而不能保證對應方用戶正确地接收到報文。 （3）請求回答：這種類型服務是接收端用戶每收到一個報文，即向發送端用戶發送一個應答報文。但是雙方發送的報文都有可能丢失。如果接收端發現報文有錯誤，則回送一個表示有錯誤的報文。

三、DP協議簡介

UDP（用戶數據報協議），主要用來支持那些需要在計算機之間傳輸數據的網絡應用。包括網絡視頻會議系統在内的衆多的客戶/服務器模式的網絡應用都需要使用UDP協議。UDP協議從問世至今已經被使用了很多年，雖然其最初的光彩已經被一些類似的協議所掩蓋，但是即使是在今天，UDP仍然不失為一項非常實用和可行的網絡傳輸層協議。 UDP協議直接位于IP協議的上層。根據OSI參考模型，UDP和TCP都屬于傳輸層協議。UDP協議不提供端到端的确認和重傳功能，它不保證數據包一定能到達目的地，因此是不可靠協議。 UDP協議有以下特點：

● UDP是面向事務的協議，它用最少的傳輸量為應用程序向其它程序發送報文提供了一個途徑。

● UDP是無連接的、不可靠的傳輸機制。在發送數據報前，UDP在發送和接收兩者之間不建立連接。

● UDP讓應用程序能直接訪問網絡層的數據報服務，例如分段和重組等網絡層所提供的數據報服務。

● UDP使用IP協議作為數據傳輸機制的底層協議。

● UDP報頭和數據都以與最初傳輸時相同的形式被傳送到最終目的地。

● UDP不提供确認，也不對數據的到達順序加以控制。因此UDP報文可能會丢失。

● 不實現數據包的傳送和重複檢測。 ● 當數據包在傳送過程中發生錯誤時，UDP不能報告錯誤。

● 吞吐量不受擁塞控制算法的調節，隻受應用程序生成數據的速率、傳輸帶寬、發送端和接收端主機性能的限制。

四、UDP報文格式 下圖顯示了UDP報文格式。每個UDP報文稱為一個用戶數據報（User Datagram），用戶數據報分為兩個部分：UDP首部和UDP數據。首部被分為四個16位的字段，分别代表源端口号﹑目的端口号﹑報文的長度以及UDP校驗和。

圖6-2 UDP報文格式

● 源端口：該字段表示發送端的端口号。如果源端口沒有使用，那麼此字段的值就被指定為0。這是一個可選的字段。不同的應用程序使用不同的端口号，UDP協議使用端口号為不同的應用程序保留其各自的數據傳輸通道，從而實現了同一時間段内多個應用程序可以一起使用網絡進行數據的發送和接收。 ● 目的端口：該字段表示數據包被發往的目的端的端口号。 ● 有效負載長度：該字段表示包括UDP首部和UDP數據在内的整個用戶數據報的長度。該字段的最小值是8。數據報的最大尺寸随操作系統的不同而不同。在兩字節字段中，理論上數據報最多可達65535字節。然而，一些UDP實現将數據報的大小限制到了8192字節。 ● 校驗和：UDP的校驗的校驗範圍包括僞首部（IP首部一部分字段）、UDP首部和UDP數據，該字段是可選的。如果該字段值為零就說明不進行校驗。五、UDP封裝 當進程有報文要通過UDP發送時，它就把這個報文連同一對套接字地址以及數據的長度傳遞給UDP。UDP收到數據後就加上UDP首部。然後UDP就把這用戶數據報連同套接字地址一起傳遞給IP。IP加上自己的首部，在高層協議類型字段使用值17，指出該數據是從UDP協議來的。這個IP數據報再傳遞給數據鍊路層。數據鍊路層接收到IP數據報後，加上自己的首部（可能還有尾部），再傳給物理層。物理層把這些位編碼為電信号或光信号，把它發送到遠程的主機。如下圖所示：

圖6-3 UDP封裝

六、UDP校驗和

UDP校驗和的計算與IP和ICMP校驗和的計算不同。UDP校驗和校驗的範圍包括三部分：僞首部、UDP首部以及從應用層來的數據。 僞首部是IP首部的一部分，其中有些字段要填入0。用戶數據報封裝在IP數據包中。如下圖所示：

圖6-4 僞首部添加在UDP數據報上

若校驗和不包括僞首部，用戶數據報也可能是安全的和正确的。但是，若IP首部受到損傷，則它可能被交付到錯誤的主機。 僞首部中包含高層協議類型字段是為了确保這個數據包是屬于UDP而不是屬于TCP（參見實驗七）的。使用UDP的進程和使用TCP的進程可以使用同一個端口号。UDP的高層協議類型字段是17。若在傳輸過程中這個值改變了，在接收端計算校驗和時就可檢測出來，UDP就可丢棄這個數據包。這樣就不會交付給錯誤的協議。1.在發送端的校驗和計算 在發送端按以下步驟計算校驗和： （1）把僞首部填加到UDP用戶數據報上。 （2）把校驗和字段填入零。 （3）按16位長度将數據報分段。

（4）若分段總數不是偶數，則增加一個分段的填充（全0）。填充隻是為了計算校驗和，計算完畢後就把它丢棄。

（5）把所有16位的分段使用反碼算術運算相加。

（6）把得到的結果取反碼，它是一個16位的數，把這個數插入到校驗和字段。 （7）把僞首部和填充丢掉。 （8）把UDP用戶數據報交付給IP進行封裝。 在僞首部中的各行的順序對校驗和的計算沒有任何影響。此外，增加0也不影響計算的結果。 下圖給出了一個計算UDP校驗和的例子。這裡假定用戶數據報的長度是15字節，因此要添加一個全0的字節。

圖6-5 UDP校驗和的計算過程

2、在接收端的校驗和計算 接收端按以下6個步驟計算校驗和是否正确： （1）把僞首部加到UDP用戶數據報上。 （2）若需要，就增加填充。 （3）把數據報按16位長度分段。 （4）把所有16位的分段使用反碼算術運算相加。 （5）把得到的結果取反碼。

（6）若得到的結果是全零，則丢棄首部和填充，并接受這個用戶數據報。若結果是非零，就丢棄這個用戶數據報。

校驗和是可選使用的，若不計算校驗和，則校驗和字段就填入0。七、UDP應用 下面列出了UDP協議的一些用途：

● UDP适用于這樣的進程，它需要簡單的請求——響應通信，而較少考慮流量控制和差錯控制。對于需要傳送成塊數據的進程，如FTP，則通常不使用UDP；

● UDP适用于具有内部流量控制和差錯控制機制的進程； ● 對多播和廣播來說，UDP是個比較合适的傳輸層協議； ● UDP可用于管理進程，如SNMP協議； ● UDP可用于某些路由選擇更新協議，如路由信息協議（RIP協議，參考實驗17）。

八、協議棧實現代碼解析 本實驗将通過對安裝目錄ExpCNS\work\EXPcns_studentnet\netproto_udp_student\netproto_udp_student下的proto_udp_student.h、netproto_udp_shudent.c和安裝目錄ExpCNS\work\EXPcns_studentnet\netproto_udp_student\netproto_udpif_student下的netproto_udpif_student.h、netproto_udpif_student.c四個文件進行編碼，完成協議棧中UDP協議的實現。 netproto_udp_student.h和netproto_udp_shudent.c文件用于實現UDP數據包發送和接收。其中，netproto_udp_student.h文件中定義了UDP協議實現相關數值以及UDP的負載内容、負載長度，關鍵代碼如下所示：

這段代碼定義了5個宏，他們代表的含義如下表所示：

表6-2 netproto_udp_student.h中定義的宏

在實驗的編碼過程中，應該使用這些宏對相應的變量進行賦值。 netproto_udp_shudent.c文件是協議棧中UDP數據包發送和接收的實現部分，其中定義了2個函數。下面介紹這些協議棧的實現部分。 函數netp_udp_output_student的功能是構造并發送一個UDP數據包，其高層協議為自定義協議類型，負載内容為自定義負載。這個函數的編碼工作需要由學生完成。 當有數據到達本機網絡接口時，函數netp_udp_input_student将被調用，并傳遞給這個函數原始數據。在該函數中，需要判斷一些條件值來确定接收到的數據包為自定義UDP數據，如果是自定義UDP數據包，則輸出負載内容，如果不是，則返回NETP_PUSH_TO_LWIP交給協議棧繼續處理。 netproto_udpif_student.h和netproto_udpif_shudent.c文件用于實現UDP上層投遞的功能，即為高層使用UDP協議提供了接口。其中，netproto_udpif_student.h文件中并沒有定義太多内容。netproto_udpif_shudent.c文件是協議棧中UDP上層投遞的功能的實現部分，其中定義了一個全局變量recv_port和2個函數。 全局變量recv_port的作用很簡單，它記錄了發送UDP數據報時的源端口号作為接收UDP數據報的過濾條件。 函數netp_send_udp通過IP層接口發送UDP數據報，該函數功能需要學生完成。 函數netp_udp_input_student處理輸入數據包，如果輸入的數據報滿足過濾條件，則投遞給上層協議使用。該函數功能需要學生完成。 在編碼過程中可能會設計到一些結構體、宏和函數，下表是對他們進行和介紹：

表6-3 實驗涉及的結構體、宏和函數

九、各模塊推薦流程1.UDP數據包發送流程 編碼實現UDP數據包發送推薦使用如下流程：

圖6-6 UDP數據包發送推薦流程

2.輸入UDP數據包處理流程 編碼實現處理UDP輸入數據包推薦使用如下流程：

圖6-7 處理UDP輸入數據包推薦流程

3.UDP發送接口實現流程 編碼實現UDP發送接口推薦使用如下流程：

圖6-8 UDP發送接口實現推薦流程

4.UDP接收接口實現流程 編碼實現UDP接收接口推薦使用如下流程：

圖6-9 UDP接收接口實現推薦流程

【實驗步驟】

練習1 編輯并發送UDP數據報

各主機打開工具區的"拓撲驗證工具"，選擇相應的網絡結構，配置網卡後，進行拓撲驗證，如果通過拓撲驗證，關閉工具繼續進行實驗，如果沒有通過，請檢查網絡連接。 本練習将主機A和B作為一組，主機C和D作為一組，主機E和F作為一組。現僅以主機A、B所在組為例，其它組的操作參考主機A、B所在組的操作。1.主機A打開協議編輯器，編輯發送給主機B的UDP數據報。 MAC層： 目的MAC地址：接收方MAC地址 源MAC地址：發送方MAC地址 協議類型或數據長度：0800，即IP協議 IP層： 總長度：包括IP層、UDP層和數據長度 高層協議類型：17，即UDP協議 首部校驗和：其它所有字段填充完畢後填充此字段 源IP地址：發送方IP地址

【思考問題】

1.為什麼UDP協議的"校驗和"要包含僞首部？2.比較UDP和IP的不可靠程度？

練習2 UDP單播通信

本練習将主機A、B、C、D、E、F作為一組進行實驗。1.主機B、C、D、E、F上啟動實驗平台工具欄中的"UDP工具"，作為服務器端，監聽端口設置為2483，"創建"成功。2.主機C、E上啟動協議分析器開始捕獲數據，并設置過濾條件（提取UDP協議）。3.主機A上啟動實驗平台工具欄中的"UDP工具"，作為客戶端，以主機C的IP為目的IP地址，以2483為端口，填寫數據并發送。4.察看主機B、C、D、E、F上的"UDP工具"接收的信息。 ● 哪台主機上的"UDP工具"能夠接收到主機A發送的UDP報文？5.察看主機C協議分析器上的UDP報文，并回答以下問題： ● UDP是基于連接的協議嗎？闡述此特性的優缺點。 ● UDP報文交互中含有确認報文嗎？闡述此特性的優缺點。6.主機A上使用協議編輯器向主機E發送UDP報文，其中： 目的MAC地址：E的MAC地址 目的IP地址：主機E的IP地址 目的端口：2483

【思考問題】

1. 思考UDP的差錯處理能力。

練習3 UDP廣播通信

本練習将主機A、B、C、D、E、F作為一組進行實驗。1.主機B、C、D、E、F上啟動UDP工具，作為服務器端，監聽端口設為2483。2.主機B、C、D、E、F啟動協議分析器捕獲數據，并設置過濾條件（提取UDP協議）。3.主機A上啟動UDP工具，作為客戶端，以255.255.255.255為目的地址，以2483為端口，填寫數據并發送。4.察看主機B、C、D、E、F上的"UDP工具"接收的信息。 ● 哪台主機能夠接收到主機A發送的UDP報文？5.察看協議分析器上捕獲的UDP報文，并回答以下問題： ●主機A發送的報文的目的MAC地址和目的IP地址的含義是什麼？

【思考問題】

1.如果将目的MAC地址換成某一個主機的MAC地址，是否所有主機還會收到這種報文？

2.如果将目的MAC地址設成廣播地址，目的IP設成某一主機的IP地址，結果怎樣？

3.在可靠性不是最重要的情況下，UDP可能是一個好的傳輸協議。試給出這種特定情況的一些示例。

4.UDP協議本身是否能确保數據報的發送和接收順序？

練習4 UDP數據報發送與接收

本練習将主機A和B作為一組，主機C和D作為一組，主機E和F作為一組。現僅以主機A、B所在組為例，其它組的操作參考主機A、B所在組的操作。實驗開始前，先單擊"初始環境"。 在實驗中，主機A将新接口的IP地址設置為172.16.1.11、主機B使用處于連接狀态的物理接口，将新接口的IP設置為172.16.1.12、主機C将新接口的IP地址設置為172.16.1.13、主機D使用處于連接狀态的物理接口，将新接口的IP地址設置為172.16.1.14、主機E使用處于連接狀态的物理接口，将新接口的IP地址設置為172.16.1.15、主機F将新接口的IP地址設置為172.16.1.16。所有主機使用子網掩碼255.255.255.0，默認網關設置為0.0.0.0。1.設置目的IP地址 各主機打開安裝目錄ExpCNS\work\EXPcns_student\netproto_udp_student\netproto_udp_student下的netproto_udp_student.h文件，将IP_DEST_ADDR宏所定義的IP地址修改為同組同學的新接口IP地址。2.編碼實現發送UDP數據包 （1）各主機打開安裝目錄ExpCNS\work\EXPcns_student\netproto_udp_student\netproto_udp_student下的netproto_udp_student.c文件，在函數netp_udp_output_student内編寫實現代碼。 （2）參考實驗原理UDP數據包發送推薦流程圖給出的流程，分析已經存在的代碼。 已經存在的代碼創建了UDP頭結構、UDP僞首部結構、源IP地址、目的IP地址、發送緩沖區和校驗和緩沖區等變量，UDP校驗和的計算過程，将UDP頭和負載拷貝到發送緩沖區中以及将緩沖區數據發送到網絡中的實現。 （3）構造UDP頭，校驗和字段為0 構造并填充一個UDP數據包頭。可以使用netproto_udp_student.h文件中所定義的端口值。總長度為UDP_HEADER_LEN PAYLOAD_LEN。 （4）構造UDP僞首部 各主機構造并填充UDP僞首部。其中，源IP地址為本接口IP地址，目的IP地址為IP_DEST_ADDR所指定的IP地址，長度與UDP頭中的總長度數值相同。3.所有主機編碼實現UDP數據包輸入處理功能 （1）各主機打開安裝目錄ExpCNS\work\EXPcns_student\netproto_udp_student\netproto_udp_student下的netproto_udp_student.c文件，在函數netp_udp_input_student内編寫實現代碼。 （2）參考實驗原理處理UDP輸入數據包推薦流程圖給出的流程，分析已經存在的代碼。 已經存在的代碼定義了以太網幀頭、IP包頭、UDP報頭、UDP僞報頭、校驗和、負載緩沖區指針和校驗和緩沖區指針，以太網高層協議的校驗，目的IP地址的校驗，申請負載緩沖區，打印負載内容等實現。 （3）提取UDP數據包 各主機通過以IP頭結構ip_header中的protocol即"高層協議類型"字段值判斷該數據幀的高層協議是否為UDP協議，可以使用宏IP_PROTO_UDP。如果不是UDP數據包則返回NETP_PUSH_TO_LWIP交給協議棧繼續執行。 （4）提取UDP目的端口号為UDP_SOUR_PORT的數據報 各主機通過UDP頭結構udp_header中的dest_port即"目的端口号"字段值判斷該UDP數據報是否是我們感興趣的UDP數據報。如果不是則返回NETP_PUSH_TO_LWIP交給協議棧繼續執行。 （5）判斷UDP校驗和是否正确 如果UDP頭的校驗和字段值不為0，則需要驗證校驗和是否正确。各主機通過IP包頭和UDP報頭中的數值驗證UDP校驗和是否正确，如果不正确則丢棄該數據報。4.所有主機打開協議分析器，開始捕獲數據5.所有主機調試并運行程序6.各主機停止數據捕獲，觀察實驗現象 ● 你收到的負載内容是什麼？7.參考代碼如下：

練習5 UDP報文的上層投遞的設計與實現

本練習将主機A和B作為一組，主機C和D作為一組，主機E和F作為一組。現僅以主機A、B所在組為例，其它組的操作參考主機A、B所在組的操作。實驗開始前，先單擊"初始環境"。 在實驗中，主機A将新接口的IP地址設置為172.16.1.11、主機B使用處于連接狀态的物理接口，将新接口的IP設置為172.16.1.12、主機C将新接口的IP地址設置為172.16.1.13、主機D使用處于連接狀态的物理接口，将新接口的IP地址設置為172.16.1.14、主機E使用處于連接狀态的物理接口，将新接口的IP地址設置為172.16.1.15、主機F将新接口的IP地址設置為172.16.1.16。所有主機使用子網掩碼255.255.255.0，默認網關設置為0.0.0.0。1.編碼實現發送UDP數據報接口 （1）各主機打開安裝目錄ExpCNS\work\EXPcns_student\netproto_udp_student\netproto_udpif_student下的netproto_udpif_student.c文件，在函數netp_send_udp内編寫實現代碼。 （2）參考實驗原理UDP發送接口實現推薦流程圖給出的流程，分析已經存在的代碼。 已經存在的代碼創建了UDP頭結構、UDP僞首部結構、源IP地址、負載緩沖區指針和校驗和緩沖區指針等變量，申請負載緩沖區、校驗和緩沖區，UDP校驗和的計算過程，将UDP頭和負載拷貝到發送緩沖區中以及利用IP接口将緩沖區數據發送到網絡中的實現。 （3）構造UDP頭，校驗和字段為0 構造并填充一個UDP數據包頭。可以使用安裝目錄ExpCNS\work\EXPcns_student\netproto_udp_student\netproto_udp_student下的netproto_udp_student.h文件中所定義的端口值。總長度為UDP_HEADER_LEN buff_len。 （4）構造UDP僞首部 各主機構造并填充UDP僞首部。其中，源IP地址為本接口IP地址，目的IP地址為用戶所指定的目的IP地址，長度與UDP頭中的總長度數值相同。2.編碼實現接收UDP數據報接口 （1）各主機打開netproto_ udpif _student.c文件，在函數netp_udp_input_student内編寫實現代碼。 （2）參考實驗原理UDP接收接口實現推薦流程圖給出的流程，分析已經存在的代碼。 已經存在的代碼定義了以太網幀頭、IP包頭、UDP報頭、UDP僞報頭、校驗和、負載緩沖區指針和校驗和緩沖區指針，以太網高層協議的校驗，目的IP地址的校驗，申請負載緩沖區，将負載内容投遞到上層協議、釋放負載緩沖區等實現。 （3）提取UDP數據包 各主機通過以IP頭結構ip_header中的protocol即"高層協議類型"字段值判斷該數據幀的高層協議是否為UDP協議，可以使用宏IP_PROTO_UDP。如果不是UDP數據包則返回NETP_PUSH_TO_LWIP交給協議棧繼續執行。 （4）提取UDP目的端口号為recv_port的數據報 各主機通過UDP頭結構udp_header中的dest_port即"目的端口号"字段值判斷該UDP數據報是否是我們感興趣的UDP數據報。如果不是則返回NETP_PUSH_TO_LWIP交給協議棧繼續執行。 （5）判斷UDP校驗和是否正确 如果UDP頭的校驗和字段值不為0，則需要驗證校驗和是否正确。各主機通過IP包頭和UDP報頭中的數值驗證UDP校驗和是否正确，如果不正确則丢棄該數據報。3.所有主機打開協議分析器，開始捕獲數據4.所有主機調試并運行程序5.各主機停止數據捕獲，觀察實驗現象 ● 你收到的負載内容是什麼？6.參考代碼如下：

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!