1. UDP介紹
UDP是一個簡單的面向數據報的運輸層協(xié)議:進程的每個輸出操作都正好產生一個 UDP數據報,并組裝成一份待發(fā)送的IP數據報。這與面向流字符的協(xié)議不同,如TCP,應用程序產生的全體數據與真正發(fā)送的單個IP數據報可能沒有什么聯系。
UDP數據報封裝成一份 IP數據報的格式如圖11 - 1所示。
RFC 768 [Postel 1980] 是UDP的正式規(guī)范。
UDP不提供可靠性:它把應用程序傳給IP層的數據發(fā)送出去,但是并不保證它們能到達目的地。由于缺乏可靠性,我們似乎覺得要避免使用UDP而使用一種可靠協(xié)議如TCP。在討論完TCP后將再回到這個話題,看看什么樣的應用程序可以使用UDP。
2. UDP首部
UDP首部的各字段如圖11 - 2所示。
端口號表示發(fā)送進程和接收進程。在圖 1 - 8中,我們畫出了TCP和UDP用目的端口號來分用來自IP層的數據的過程。
由于IP層已經把IP數據報分配給TCP或UDP(根據I P首部中協(xié)議字段值) ,因此TCP端口號由TCP來查看,而UDP端口號由UDP來查看。TCP端口號與UDP端口號是相互獨立的。
盡管相互獨立,如果TCP和UDP同時提供某種知名服務,兩個協(xié)議通常選擇相同的端口號。這純粹是為了使用方便,而不是協(xié)議本身的要求。
UDP長度字段指的是UDP首部和UDP數據的字節(jié)長度。該字段的最小值為 8字節(jié)(發(fā)送一份0字節(jié)的UDP數據報是OK) 。這個UDP長度是有冗余的。 IP數據報長度指的是數據報全長(圖3 - 1) ,因此UDP數據報長度是全長減去IP首部的長度(該值在首部長度字段中指定,如圖3 - 1所示)
UDP檢驗和覆蓋UDP首部和UDP數據?;叵隝P首部的檢驗和,它只覆蓋IP的首部—并不覆蓋IP數據報中的任何數據。
UDP和TCP在首部中都有覆蓋它們首部和數據的檢驗和。UDP的檢驗和是可選的,而TCP的檢驗和是必需的。
盡管UDP檢驗和的基本計算方法與我們在描述的IP首部檢驗和計算方法相類似(16 bit字的二進制反碼和,但是稍微有所不同,在根據字段類型判定為UDP或者TCP時加入了一些處理,看代碼就曉得了) ,但是它們之間存在不同的地方。首先, UDP數據報的長度可以為奇數字節(jié),但是檢驗和算法是把若干個 16 bit字相加。解決方法是必要時在最后增加填充字節(jié)0,這只是為了檢驗和的計算(也就是說,可能增加的填充字節(jié)不被傳送) 。
其次,UDP數據報和TCP段都包含一個1 2字節(jié)長的偽首部(本TCP/IP協(xié)議棧有所不同,只加入了4字節(jié)源IP地址和4字節(jié)目的IP地址,即利用IP首部的尾巴,實現了空間上的復用,看代碼就曉得了),它是為了計算檢驗和而設置的。偽首部包含IP首部一些字段。其目的是讓 UDP兩次檢查數據是否已經正確到達目的地(例如,IP沒有接受地址不是本主機的數據報,以及IP沒有把應傳給另一高層的數據報傳給UDP) 。UDP數據報中的偽首部格式如圖11 - 3所示。
在該圖中,我們特地舉了一個奇數長度的數據報例子,因而在計算檢驗和時需要加上填充字節(jié)(0)。注意,UDP數據報的長度在檢驗和計算過程中出現兩次。
如果檢驗和的計算結果為 0,則存入的值為全1(65535) ,這在二進制反碼計算中是等效的。如果傳送的檢驗和為0,說明發(fā)送端沒有計算檢驗和。(因為協(xié)議要求如此,故代碼需要實現之。)如果發(fā)送端沒有計算檢驗和而接收端檢測到檢驗和有差錯,那么 UDP數據報就要被悄悄地丟棄。不產生任何差錯報文(當IP層檢測到IP首部檢驗和有差錯時也這樣做) 。
UDP檢驗和是一個端到端的檢驗和。它由發(fā)送端計算,然后由接收端驗證。其目的是為了發(fā)現UDP首部和數據在發(fā)送端到接收端之間發(fā)生的任何改動。
/*下面闡述UDP校驗和的一些歷史和必要性*/
盡管UDP檢驗和是可選的,但是它們應該總是在用。在 80年代,一些計算機產商在默認條件下關閉UDP檢驗和的功能,以提高使用UDP協(xié)議的NFS(Network File System)的速度。
在單個局域網中這可能是可以接受的,但是在數據報通過路由器時,通過對鏈路層數據幀進行循環(huán)冗余檢驗(如以太網或令牌環(huán)數據幀)可以檢測到大多數的差錯,導致傳輸失敗。不管相信與否,路由器中也存在軟件和硬件差錯,以致于修改數據報中的數據。如果關閉端到端的UDP檢驗和功能,那么這些差錯在UDP數據報中就不能被檢測出來。另外,一些數據鏈路層協(xié)議(如SLIP)沒有任何形式的數據鏈路檢驗和。
Host Requirements RFC聲明,UDP檢驗和選項在默認條件下是打開的。它還聲明,如果發(fā)送端已經計算了檢驗和,那么接收端必須檢驗接收到的檢驗和(如接收到檢驗和不為0) 。但是,許多系統(tǒng)沒有遵守這一點,只是在出口檢驗和選項被打開時才驗證接收到的檢驗和。
另外需要解釋幾個術語:IP數據報是指IP層端到端的傳輸單元(在分片之前和重新組裝之后) ,分組是指在IP層和鏈路層之間傳送的數據單元。一個分組可以是一個完整的 IP數據報,也可以是IP數據報的一個分片。(這里有如何分片的說明,書里介紹的詳細,簡而言之,超過MTU就需要分,但是第一片和接下來的片是有區(qū)別的:第一個有UDP首部,其他沒有,但是可以通過IP的flags來組合起來。下面的圖很形象的說明了。)
------------------------------------------以上內容整理于《TCP/IP協(xié)議詳解:卷1》--------------------------------------
------------------------------------------以下內容產生于代碼及分析--------------------------------------
3. UDP宏定義實現
C++ Code
4. UDP函數實現
本TCP/IP協(xié)議棧中的UDP實現只一個make_udp_reply_from_request函數——udp服務器,可以響應其他udp的請求。在連接的順序看來,在stm32板子上面的為服務器,等待pc機客戶端的請求,當請求到來的時候,返回由程序員自行設定的響應,如本文中將做出3個響應的例子(當然udp一旦建立之后,就部分客戶端和服務器端,地位是對等的,但是認為發(fā)起者為clien比較符合認知而已)。
這里說以下輸入吧:buf為緩沖區(qū),data為要傳輸的數據,datalen即為sizeof(data),port即為pc端的udp端口號
5. UDP實驗
在有了以上的UDP實現之后,你還需要有UDP的請求進來,如下代碼所示:
下面的代碼放在一個while(1)或者RTOS進程里面,作為服務器來等待客戶端的響應
ps:本實驗中板子udp的port為1200,pc機的port為4001
實驗部分實現了三個簡單的實驗:
通過串口輸出UDP客戶端的IP地址及端口號
通過串口和UDP輸出UDP的輸入數據,即USART ECHO和UDP ECHO
實現UDP命令控制STM32板子上面的LED
C++ Code