UDP是怎么工作的

這篇文章將為大家詳細講解有關UDP是怎么工作的，小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

IETF（互聯網工程任務組）是一個由工程師和計算機科學家組成的社區，他們致力于帶來新的互聯網技術、標準和規范。RFC文檔就是由IETF發布的。

RFC通常是為了進行同行評審而編寫的正式文檔。RFC主要討論了不同協議的方法及其完整的細節和特性。它主要是作為標準文件，以便工程師實現、提供反饋、提交與新協議相關的信息及其概念（RFC類似提案，因此以“Request for Comments（征求意見）”命名）。為什么要此處要討論IETF和RFC呢？

那是因為一個編號為768的RFC文檔。這可能是最短的RFC文檔（只有幾段文字和協議的少量細節）。RFC通常非常詳細，有數百頁。但是這個RFC非常短小緊湊。

這份RFC所描述的協議稱為UDP（用戶數據報協議）。UDP協議的復雜性較低，并且非常直觀（和相對的TCP協議不同。TCP協議稍微復雜一些，因為一些可靠性方面的機制）。

TCP/IP參考模型包含5層。每層執行不同的工作來實現網絡通信。最頂端的是應用層。這一層為軟件和應用程序在網絡中使用協議（如HTTP、FTP、SMTP）通訊提供方法。下一層是傳輸層，TCP和UDP（我們討論的主題）在這里進入視野。TCP提供可靠的通信，而UDP不提供任何可靠傳輸機制。UDP也不提供任何順序傳輸機制。再下一層是IP層，它提供了將消息傳送到目標IP的方法。接下來是數據鏈路層，在這里物理地址（MAC）被添加到數據包頭部，以便通過物理層將消息傳遞到網關。

不管你使用的是TCP還是UDP，IP協議是讓上層協議可以在網絡中工作（這是因為TCP和UDP位于傳輸層，而IP位于網絡層）。看看上面的表格。通信從應用層開始，然后向下通過不同的層。每個層將在其上一層數據上添加自己的字段和頭部。在源頭，消息每進入下一層，都被添加相關的字節和信息。在目的地，消息每進入上一層，下層的無用信息都被剝離。

因此無論你根據需求選擇了TCP還是UDP，都會使用IP協議，讓網絡通信變成可能。

相關閱讀：理解TCP三次握手

在本文中我們不會討論TCP。這是因為它有點復雜，需要單獨的文章來闡述。UDP是傳輸層協議中使用最少的。這是因為我們日常使用的大多數應用程序都需要可靠性。UDP基本上是一種面向消息的不可靠協議。

在某種程度上UDP和IP非常相似。IP也不提供任何形式的傳輸或可靠性保證機制。

讓我們使用tcpdump看看當建立UDP連接時會發生什么。tcpdump是可以捕獲網絡數據包的工具。幾乎所有的Linux發行版都支持tcpdump。

相關閱讀：使用tcpdump分析網絡包

tcpdump可以幫助我們查看網絡流量的詳細信息。為了理解這一點，我們需要首先發送一個UDP請求，同時捕獲網絡數據包。

讓我們向遠程服務器發送一個DNS請求。然后在另一個終端上捕獲數據包并查看。

相關閱讀：DNS服務器是如何工作的

在第一個終端上執行以下命令：

ubuntu@testing:~$ sudo tcpdump -n -vvv host 8.8.8.8 and port 53

在第二個終端上執行以下命令：

ubuntu@testing:~$ dig @8.8.8.8 www.google.com

在第二個終端上執行命令時，你會在第一個終端中看到一系列消息，看起來類似：

18:40:39.758842 IP (tos 0x0, ttl 64, id 4636, offset 0, flags [none], proto UDP (17), length 56)
    192.168.40.27.55625 > 8.8.8.8.53: [udp sum ok] 63851+ A? google.com. (28)
18:40:39.812844 IP (tos 0x0, ttl 59, id 53901, offset 0, flags [none], proto UDP (17), length 104)
    8.8.8.8.53 > 192.168.40.27.55625: [udp sum ok] 63851 q: A? google.com. 3/0/0 google.com. [32s] A 172.217.26.174, google.com. [32s] A 172.217.26.174, google.com. [32s] A 172.217.26.174 (76)

第一行表示IP包的內容。它和UDP協議沒有關系。字符串“proto UDP (17)”表示用于標識上一層協議的一個8位字段。不同的協議用不同的數字表示。如果是TCP協議，那么你在輸出中看到的數字將是6，而非17。

如果IP報頭中沒有protocol字段，接收方將無法知道IP分組所傳遞的數據屬于哪種協議，是ICMP還是GRE等等。我們例子中的協議是UDP，因此顯示數字17。第一行輸出不包含任何與UDP相關的內容，它只是告訴IP包傳遞的是UDP數據。

請記住，UDP包的信息，以及程序數據都封裝在IP包中（正如我們前面討論的，接收方將剝離包中與每層協議相關聯的特定數據，然后提交到上一層協議，向上傳遞直到應用層）。

“id 4636” 是IP標識字段的一部分，在處理分片時很有用。

如果IP包過大，中間網絡設備無法直接發送，這是需要對IP包進行分片。再將各個分片發送到目標地址。接收方需要使用某種標識來重新組裝收到的分片。所有分片擁有相同的標識數字。接收方據此把分片視為同一個包的一部分。如果沒有發生分片（比如我們的例子），大多數IP頭將具有唯一的標識。

“tos 0x0”表示服務類型。

TOS（Type Of Service，服務類型）表明應該如何處理數據包。有些數據包可能需要特殊處理（例如語音電話）。

“ttl 64”表示生存時間。

生存時間是在到達最終目的地之前，一個IP數據包可能經過的最大網絡設備數。如果在源和目標之間有68個設備，例子中的IP包將在第64個設備上被丟棄（因為ttl是64），并不會到達目的地。不同系統默認的生存周期是不同的。

推薦閱讀：ttl在traceroute中扮演什么角色

“offset 0”也和IP分片有關。默認情況下，它始終設置為0。如果IP分片，各分片將具有相同的標識字段（如前所述），同時還有一個偏移量字段，表明重組時分片數據的位置。

讓我們考慮分片的例子。假設第1個分片的標識是100，偏移量是0。第2個分片的標識是100，偏移量是170。這表示在重組時，第2個分片的數據位于原始IP包的第1360（170*8=1360）字節處。

現在我們回到主題：UDP。下面是tcpdump輸出中的第二行：

192.168.40.27.55625 > 8.8.8.8.53: [udp sum ok] 63851+ A? google.com. (28)

這一行有5個主要部分。這些是UDP的全部內容。這里看到的IP地址實際上是IP包的一部分，IP地址屬于UDP。IP地址存在于IP層。源IP地址是192.168.40.27，這是我電腦的IP地址。8.8.8.8是google的公共DNS地址，我們正式向這個地址發送的DNS請求。

下面是UDP的頭字段。 

• 源端口。這是發送UDP請求時隨機選擇的端口號（在例子中是55625，從第二行可以看出）。

• 目標端口：接收我們請求的應用程序的目標端口。DNS默認使用端口號53，和例子中的相同。

• 長度：請求發送的實際用戶數據大小。在例子中（通過dig發送的DNS請求），請求長度是UDP請求數據長度加上UDP頭長度。第二行的最后一個字段是數字28，表示用戶數據占28字節。UDP包有8字節的頭部數據。即UDP包的長度是28+8=36字節。

• 校驗和：UDP校驗和的計算有點復雜。我將寫一篇文章介紹UDP和TCP校驗和的計算（對于TCP和UDP，校驗和計算方式是相同的）。雖然tcpdump輸出中沒有顯示校驗和值，但它看起來像0xaab或0x8921之類的值。

相關閱讀：UDP和TCP校驗和是如何計算的？

• 有效載荷：這是客戶端實際發送的數據。在例子中是由dig生成的DNS請求 63851+ A? google.com 。A代表請求google.com的A記錄，63851+是DNS事務標識，它幫助DNS客戶端識別應答。

關于UDP校驗和需要記住的一點是，它是可選的。UDP協議沒有強制要求計算校驗和。校驗和用于判斷數據在傳輸過程中是否遭到篡改。它提供了一種“錯誤檢測”機制。

為什么UDP使用校驗和進行錯誤檢測？

這是個好問題，是個實際的問題。因為UDP要求輕量級，并未提供任何可靠性或糾錯機制。既然UDP是無連接的、不可靠的，為什么還要校驗和呢？

UDP不關心被丟棄的數據包，也不關心亂序傳遞。但是UDP希望收到的數據包是完整的（盡管是可選的，有完整性驗證的規定）。但是，如果不能糾錯，用校驗和檢查完整性又有什么用呢？。

它的確不能糾正完整性錯誤。但是可以丟棄校驗和錯誤的數據包。接收方不會收取校驗和錯誤的數據包。沒有什么機制可以反饋給發送方，錯誤的數據包會被默默地丟棄。

如果UDP是無連接的，它如何識別應答？

8.8.8.8.53 > 192.168.40.27.55625: [udp sum ok] 63851 q: A? google.com. 3/0/0 google.com. [32s] A 172.217.26.174, google.com. [32s] A 172.217.26.174, google.com. [32s] A 172.217.26.174 (76)

上面顯示的是對DNS請求應答（tcpdump輸出中的最后一行）。這里的源IP和源端口是8.8.8.8和53。目標IP和目標端口為192.168.40.27和55625。

應答中的目標端口與原始請求中的源端口相同（tcpdump輸出中的第二行）。

也就是說，應答直接發送給發出原始請求的端口。這是客戶端程序識別正確應答的方法。

在理想情況下，客戶端程序打開端口等待響應。只有在收到應答時，源端口（套接字）才會關閉。

將UDP與TCP進行比較的最佳用例

想象一下，你希望將一個視頻直播給數百萬用戶（可能是一場板球比賽）。TCP需要大量的開銷來處理這類請求。就直播流而言，如果TCP收到太多請求，操作系統必須等待所有未確認的數據。這意味著，如果有數百萬個請求，操作系統將把所有未確認數據保存在緩沖區中。在這種情況下，TCP不是個好主意。

如果你需要快速且簡單的響應，那么UDP是最好的選擇。比如DNS、NTP等。

想想游戲之類的場景。游戲中新的狀態正在不斷地替換舊狀態。這意味著舊狀態對于客戶端來說是沒有用的（忘了重發缺失包的面向連接的TCP吧）。在這里UDP是一個不錯的選擇。

關于“UDP是怎么工作的”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，使各位可以學到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。