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

成都創(chuàng)新互聯(lián)公司堅信：善待客戶，將會成為終身客戶。我們能堅持多年，是因為我們一直可值得信賴。我們從不忽悠初訪客戶，我們用心做好本職工作，不忘初心，方得始終。10余年網(wǎng)站建設(shè)經(jīng)驗成都創(chuàng)新互聯(lián)公司是成都老牌網(wǎng)站營銷服務(wù)商,為您提供網(wǎng)站建設(shè)、網(wǎng)站制作、網(wǎng)站設(shè)計、H5網(wǎng)站設(shè)計、網(wǎng)站制作、高端網(wǎng)站設(shè)計、成都微信小程序服務(wù),給眾多知名企業(yè)提供過好品質(zhì)的建站服務(wù)。

IETF（互聯(lián)網(wǎng)工程任務(wù)組）是一個由工程師和計算機科學家組成的社區(qū)，他們致力于帶來新的互聯(lián)網(wǎng)技術(shù)、標準和規(guī)范。RFC文檔就是由IETF發(fā)布的。

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

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

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

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

不管你使用的是TCP還是UDP，IP協(xié)議是讓上層協(xié)議可以在網(wǎng)絡(luò)中工作（這是因為TCP和UDP位于傳輸層，而IP位于網(wǎng)絡(luò)層）?？纯瓷厦娴谋砀?。通信從應(yīng)用層開始，然后向下通過不同的層。每個層將在其上一層數(shù)據(jù)上添加自己的字段和頭部。在源頭，消息每進入下一層，都被添加相關(guān)的字節(jié)和信息。在目的地，消息每進入上一層，下層的無用信息都被剝離。

因此無論你根據(jù)需求選擇了TCP還是UDP，都會使用IP協(xié)議，讓網(wǎng)絡(luò)通信變成可能。

相關(guān)閱讀：理解TCP三次握手

在本文中我們不會討論TCP。這是因為它有點復雜，需要單獨的文章來闡述。UDP是傳輸層協(xié)議中使用最少的。這是因為我們?nèi)粘Ｊ褂玫拇蠖鄶?shù)應(yīng)用程序都需要可靠性。UDP基本上是一種面向消息的不可靠協(xié)議。

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

讓我們使用tcpdump看看當建立UDP連接時會發(fā)生什么。tcpdump是可以捕獲網(wǎng)絡(luò)數(shù)據(jù)包的工具。幾乎所有的Linux發(fā)行版都支持tcpdump。

相關(guān)閱讀：使用tcpdump分析網(wǎng)絡(luò)包

tcpdump可以幫助我們查看網(wǎng)絡(luò)流量的詳細信息。為了理解這一點，我們需要首先發(fā)送一個UDP請求，同時捕獲網(wǎng)絡(luò)數(shù)據(jù)包。

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

相關(guān)閱讀：DNS服務(wù)器是如何工作的

在第一個終端上執(zhí)行以下命令：

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

在第二個終端上執(zhí)行以下命令：

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

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

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包的內(nèi)容。它和UDP協(xié)議沒有關(guān)系。字符串“proto UDP (17)”表示用于標識上一層協(xié)議的一個8位字段。不同的協(xié)議用不同的數(shù)字表示。如果是TCP協(xié)議，那么你在輸出中看到的數(shù)字將是6，而非17。

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

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

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

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

“tos 0x0”表示服務(wù)類型。

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

“ttl 64”表示生存時間。

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

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

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

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

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

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

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

下面是UDP的頭字段。 

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

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

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

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

相關(guān)閱讀：UDP和TCP校驗和是如何計算的？

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

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

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

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

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

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

如果UDP是無連接的，它如何識別應(yīng)答？

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請求應(yīng)答（tcpdump輸出中的最后一行）。這里的源IP和源端口是8.8.8.8和53。目標IP和目標端口為192.168.40.27和55625。

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

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

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

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

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

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

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

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