UDP用戶數據報協議

1、引言

UDP是一個簡單的面向數據報的運輸層協議:進程的每個輸出操作都正好產生一個UDP數據報,並組裝成一份待發送的IP數據報。UDP數據報封裝成一份IP數據報的格式如圖11-1所示。

說明:

(1)UDP不提供可靠性:它把應用程序傳給IP層的數據發送出去,但是並不保證它們能到達目的地。

(2)應用程序必須關心IP數據報的長度。如果它超過網絡的MTU,就要對IP數據報進行分片。如果需要,源端到目的端之間的每個網絡都要進行分片,並不只是發送端主機連接第一個網絡才這樣做(路徑MTU與網絡MTU的概念可以參考:《TCP/IP詳解卷1:協議》第2章 鏈路層-讀書筆記)。

 

2、UDP首部

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

說明:

(1)端口號表示發送進程和接收進程。TCP端口號與UDP端口號是相互獨立的。如果TCP和UDP同時提供某種知名服務,兩個協議通常選擇相同的端口號,只是爲了方便,而不是協議本身的要求。

(2)UDP長度字段指的是UDP首部和UDP數據的字節長度。該字段的最小值爲8字節(發送一份0字節的UDP數據報是可以的)。這個UDP長度是有冗餘的。

(3)UDP數據報長度是全長減去IP首部的長度。

 

3、UDP檢驗和

UDP檢驗和覆蓋UDP首部和UDP數據。而IP首部的檢驗和,只覆蓋IP的首部,並不覆蓋IP數據報中的任何數據。UDP和TCP在首部中都有覆蓋它們首部和數據的檢驗和。UDP的檢驗和是可選的,而TCP的檢驗和是必需的。UDP檢驗和的基本計算方法IP首部檢驗和計算方法相似(16 bit字的二進制反碼和),但它們之間存在不同的地方:

(1)UDP數據報的長度可以爲奇數字節,但檢驗和算法是把若干個16 bit字相加。解決方法是必要時在最後增加填充字節0,這只是爲了檢驗和的計算,可能增加的填充字節不被傳送。

(2)UDP數據報和TCP段都包含一個12字節長的僞首部,它是爲了計算檢驗和而設置的。僞首部包含IP首部一些字段,目的是讓UDP兩次檢查數據是否已經正確到達目的地。UDP數據報中的僞首部格式如圖11-3所示。

說明:

(1)UDP數據報的長度在檢驗和計算過程中出現兩次。

(2)如果檢驗和的計算結果爲0,則存入的值爲全1(65535),這在二進制反碼計算中是等效的。如果傳送的檢驗和爲0,說明發送端沒有計算檢驗和。

(3)如果發送端沒有計算檢驗和而接收端檢測到檢驗和有差錯,UDP數據報就要被丟棄。不產生任何差錯報文(當IP層檢測到IP首部檢驗和有差錯時也這樣做)。

(4)UDP檢驗和是一個端到端的檢驗和。它由發送端計算,然後由接收端驗證。其目的是爲了發現UDP首部和數據在發送端到接收端之間發生的任何改動。

(5)儘管UDP檢驗和是可選的,但是它們應該總是在用。

(6)UDP檢驗和(事實上,TCP/IP協議簇中所有的檢驗和)是簡單的16 bit和。它們檢測不出交換兩個16 bit的差錯。

 

4、IP分片

物理、網絡層一般要限制每次發送數據幀的最大長度。任何時候IP層接收到一份要發送的IP數據報時,它要判斷向本地哪個接口發送數據(選路),並查詢該接口獲得其MTU。IP把MTU與數據報長度進行比較,如果需要則進行分片。

說明:

(1)分片可以發生在原始發送端主機上,也可以發生在中間路由器上。

(2)把一份IP數據報分片以後,只有到達目的地才進行重新組裝。重新組裝由目的端的IP層來完成,目的是使分片和重新組裝過程對運輸層(TCP和UDP)是透明的。

注意:其他網絡協議可能要求在下一站就進行進行重新組裝,而不是在最終的目的地。

(3)已經分片過的數據報有可能會再次進行分片(可能不止一次)。

IP首部中包含的數據爲分片和重新組裝提供了足夠的信息。

IP分片過程:

(1)對於發送端發送的每份IP數據報,標識字段都包含一個唯一值,該值在數據報分片時被複制到每個片中。

(2)標誌字段用其中一個比特來表示“更多的片”。除了最後一片外,其他每個組成數據報的片都要把該比特置1。

(3)片偏移字段指的是該片偏移原始數據報開始處的位置。

說明:

(1)當數據報被分片後,每個片的總長度值要改爲該片的長度值。

(2)標誌字段中有一個比特稱作“不分片”位。如果將這一比特置1,IP將不對數據報進行分片。相反把數據報丟棄併發送一個ICMP差錯報文給起始端。

(3)當IP數據報被分片後,每一片都成爲一個分組,具有自己的IP首部,並在選擇路由時與其他分組獨立。當數據報的這些片到達目的端時有可能會失序,但在IP首部中有足夠的信息讓接收端能正確組裝這些數據報片。

(4)在分片時,除最後一片外,其他每一片中的數據部分(除IP首部外的其餘部分)必須是8字節的整數倍。

(5)任何運輸層首部只出現在第1片數據中。

 

5、ICMP不可達差錯(需要分片)

發生ICMP不可達差錯的另一種情況是(前面講過端口不一致也會導致ICMP不可達差錯),當路由器收到一份需要分片的數據報,而在IP首部又設置了不分片(DF)的標誌比特。

如果某個程序需要判斷到達目的端的路途中最小MTU是多少(路徑MTU發現機制),那麼這個差錯就可以被該程序使用。報文格式如圖11-9所示:

 

6、最大UDP數據報長度

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

(1)應用程序可能會受到其程序接口的限制

socket API提供了一個可供應用程序調用的函數,以設置接收和發送緩存的長度。這個長度與應用程序可以讀寫的最大UDP數據報的長度直接相關,現在的大部分系統都默認提供可讀寫大於8192字節的UDP數據報。

(2)限制來自於TCP/IP的內核實現。

可能存在一些實現特性(或差錯),使IP數據報長度小於65535字節。

數據報截斷:

IP能夠發送或接收特定長度的數據報並不意味着接收應用程序可以讀取該長度的數據。UDP編程接口允許應用程序指定每次返回的最大字節數。如果接收到的數據報長度大於應用程序所能處理的長度,發生的情況取決於編程接口和實現。例如:Berkeley版socket API對數據報進行截斷,並丟棄任何多餘的數據。

 

7、ICMP源站抑制差錯

當一個系統(路由器或主機)接收數據報的速度比其處理速度快時,可能產生這個差錯。

注意:“可能”產生這個差錯。即使一個系統已經沒有緩存並丟棄數據報,也不要求它一定要發送源站抑制報文。

 

8、UDP服務器的設計

對於服務器來說,它啓動後處於休眠狀態,等待客戶請求的到來。對於UDP來說,當客戶數據報到達時,服務器甦醒過來,數據報中可能包含來自客戶的某種形式的請求消息。

(1)客戶IP地址及端口號

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

(2)目的IP地址

一些應用程序需要知道數據報是發送給誰的,即目的IP地址。這要求操作系統從接收到的UDP數據報中將目的IP地址交給應用程序。

(3)UDP輸入隊列

大多數UDP服務器是交互服務器。這意味着,單個服務器進程對單個UDP端口上(服務器上的名知端口)的所有客戶請求進行處理。

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

排隊溢出造成內核中的UDP模塊丟棄數據報的可能性是存在的。

1)應用程序並不知道其輸入隊列何時溢出。只是由UDP對超出數據報進行丟棄處理。

2)沒有發回任何信息告訴客戶其數據報被丟棄。

 

(4)限制本地IP地址

大多數UDP服務器在創建UDP端點時都使其本地IP地址具有通配符(wildcard)的特點。表明進入的UDP數據報如果其目的地爲服務器端口,那麼在任何本地接口均可接收到它。

另一方面當服務器創建端點時,它可以把其中一個主機本地IP地址包括廣播地址指定爲端點的本地IP地址。只有當目的IP地址與指定的地址相匹配時,進入的UDP數據報才能被送到這個端點。

(5)限制遠端IP地址

大多數系統都允許UDP端點對遠端地址進行限制,即端點將只能接收特定IP地址和端口號的UDP數據報。

(6)每個端口有多個接收者

大多數系統在某一時刻只允許一個程序端點與某個本地IP地址及UDP端口號相關聯。當目的地爲該IP地址及端口號的UDP數據報到達主機時,就複製一份傳給該端點。

然而,在一個支持多播的系統上,多個端點可以使用同一個IP地址和UDP端口號。

當UDP數據報到達的目的IP地址爲廣播地址或多播地址,而且在目的IP地址和端口號處有多個端點時,就向每個端點傳送一份數據報的複製。如果UDP數據報到達的是一個單播地址,那麼只向其中一個端點傳送一份數據報的複製。選擇哪個端點傳送數據取決於各個不同的系統實現

 

小結:

(1)UDP是一個簡單協議,它向用戶進程提供的服務位於IP層之上,包括端口號和可選的檢驗和。ICMP不可達差錯,是新的路徑MTU發現功能中的一部分。

(2)對於UDP和ARP之間的接口,大多數的ARP實現在等待ARP應答時只保留最近傳送給目的端的數據報。

(3)當系統接收IP數據報的速率超過這些數據報被處理的速率時,系統可能發送ICMP源站抑制差錯報文。使用UDP時很容易產生這樣的ICMP差錯。

發佈了10 篇原創文章 · 獲贊 12 · 訪問量 6萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章