網(wǎng)絡(luò)編程懶人入門(十三)：一泡尿的時間，快速搞懂TCP和UDP的區(qū)別

Posted on 2021-12-29 15:01 Jack Jiang 閱讀(158) 評論(0) 編輯收藏

本文引用了作者Fundebug的“一文搞懂TCP與UDP的區(qū)別”一文的內(nèi)容，感謝無私分享。

1、引言

網(wǎng)絡(luò)協(xié)議是每個搞網(wǎng)絡(luò)通信應(yīng)用開發(fā)（比如IM、推送、網(wǎng)關(guān)等等）的程序員都必須要掌握的基礎(chǔ)知識，TCP/IP協(xié)議簇中有兩個最具有代表性的傳輸層協(xié)議——分別是 TCP 和 UDP。

有過網(wǎng)絡(luò)通信開發(fā)經(jīng)驗的同學(xué)們都知道，TCP和UDP協(xié)議是平時用的最多的兩種協(xié)議，而對于很多人來說，什么時候以及什么場景下該用TCP還是UDP？這是個經(jīng)久不息的討論話題。

不同于其它長篇大論，本文盡量以簡潔精煉的文字，幫你總結(jié)歸納TCP和UDP協(xié)議的主要區(qū)別，方便那些想掌握這方面知識又不愿意耗費太多時間去系統(tǒng)地學(xué)習(xí)網(wǎng)絡(luò)理論基礎(chǔ)的同學(xué)快速理解！

推薦閱讀：為了加深理解，本系列的另一篇《網(wǎng)絡(luò)編程懶人入門(四)：快速理解TCP和UDP的差異》也可以一并閱讀。

學(xué)習(xí)交流：

- 移動端IM開發(fā)入門文章：《新手入門一篇就夠：從零開發(fā)移動端IM》
- 開源IM框架源碼：https://github.com/JackJiang2011/MobileIMSDK

（本文已同步發(fā)布于：http://www.52im.net/thread-3793-1-1.html ）

2、快速理解TCP/IP協(xié)議簇

計算機與網(wǎng)絡(luò)設(shè)備要相互通信，雙方就必須基于相同的方法。比如：如何探測到通信目標(biāo)、由哪一邊先發(fā)起通信、使用哪種語言進行通信、怎樣結(jié)束通信等規(guī)則都需要事先確定。不同的硬件、操作系統(tǒng)之間的通信，所有的這一切都需要一種規(guī)則。而我們就把這種規(guī)則稱為協(xié)議（protocol）。

TCP/IP 是互聯(lián)網(wǎng)相關(guān)的各類協(xié)議族的總稱，比如：TCP，UDP，IP，F(xiàn)TP，HTTP，ICMP，SMTP 等都屬于 TCP/IP 族內(nèi)的協(xié)議。

TCP/IP模型是互聯(lián)網(wǎng)的基礎(chǔ)，它是一系列網(wǎng)絡(luò)協(xié)議的總稱。這些協(xié)議可以劃分為四層，分別為鏈路層、網(wǎng)絡(luò)層、傳輸層和應(yīng)用層。

具體是：

1）鏈路層：負責(zé)封裝和解封裝IP報文，發(fā)送和接受ARP/RARP報文等；
2）網(wǎng)絡(luò)層：負責(zé)路由以及把分組報文發(fā)送給目標(biāo)網(wǎng)絡(luò)或主機；
3）傳輸層：負責(zé)對報文進行分組和重組，并以TCP或UDP協(xié)議格式封裝報文；
4）應(yīng)用層：負責(zé)向用戶提供應(yīng)用程序，比如HTTP、FTP、Telnet、DNS、SMTP等。

下面這張表格進行了了歸納：

下面這張圖，更生動的反映了TCP/IP協(xié)議族的關(guān)系情況（高清圖從這里下載）：

在網(wǎng)絡(luò)體系結(jié)構(gòu)中，網(wǎng)絡(luò)通信的建立必須是在通信雙方的對等層進行，不能交錯。

在整個數(shù)據(jù)傳輸過程中，數(shù)據(jù)在發(fā)送端時經(jīng)過各層時都要附加上相應(yīng)層的協(xié)議頭和協(xié)議尾（僅數(shù)據(jù)鏈路層需要封裝協(xié)議尾）部分，也就是要對數(shù)據(jù)進行協(xié)議封裝，以標(biāo)識對應(yīng)層所用的通信協(xié)議。

有關(guān)TCP/IP協(xié)議簇的知識，幾本書都寫不完，這里我就不再贅述了，有興趣可以讀一讀《TCP/IP詳解卷1：協(xié)議（在線閱讀）》。

另外，學(xué)習(xí)知識，我特別喜歡了解技術(shù)之外的一些知識，比如下面兩篇：

《技術(shù)往事：改變世界的TCP/IP協(xié)議（珍貴多圖、手機慎點）》
《5G時代已經(jīng)到來，TCP/IP老矣，尚能飯否？》

接下來，我們將回到正題，學(xué)習(xí)TCP/IP 中有兩個具有代表性的傳輸層協(xié)議——TCP 和 UDP。

3、快速理解UDP協(xié)議

3.1 基本介紹

UDP協(xié)議：全稱是用戶數(shù)據(jù)報協(xié)議，在網(wǎng)絡(luò)中它與TCP協(xié)議一樣用于處理數(shù)據(jù)包，是一種無連接的協(xié)議。

在OSI模型中，處在第四層——傳輸層，處于IP協(xié)議的上一層（見下圖）。

▲ 上圖引用自《計算機網(wǎng)絡(luò)通訊協(xié)議關(guān)系圖》

UDP有不提供數(shù)據(jù)包分組、組裝和不能對數(shù)據(jù)包進行排序的缺點，也就是說，當(dāng)報文發(fā)送之后，是無法得知其是否安全完整到達的。

UDP協(xié)議的幾個主要特別，我進行歸納，下面的下節(jié)將逐一說明。

3.2 面向無連接

首先 UDP 是不需要和 TCP一樣在發(fā)送數(shù)據(jù)前進行三次握手建立連接的，想發(fā)數(shù)據(jù)就可以開始發(fā)送了。并且也只是數(shù)據(jù)報文的搬運工，不會對數(shù)據(jù)報文進行任何拆分和拼接操作。

具體來說就是：

1）在發(fā)送端：應(yīng)用層將數(shù)據(jù)傳遞給傳輸層的 UDP 協(xié)議，UDP 只會給數(shù)據(jù)增加一個 UDP 頭標(biāo)識下是 UDP 協(xié)議，然后就傳遞給網(wǎng)絡(luò)層了；
2）在接收端：網(wǎng)絡(luò)層將數(shù)據(jù)傳遞給傳輸層，UDP 只去除 IP 報文頭就傳遞給應(yīng)用層，不會任何拼接操作。

3.3 支持單播、多播、廣播

UDP 不止支持一對一的傳輸方式，同樣支持一對多，多對多，多對一的方式，也就是說 UDP 提供了單播、多播、廣播的功能。

3.4 面向報文

UDP協(xié)議是面向報文的。

發(fā)送方的UDP對應(yīng)用程序交下來的報文，在添加首部后就向下交付IP層。UDP對應(yīng)用層交下來的報文，既不合并，也不拆分，而是保留這些報文的邊界。

因此，應(yīng)用程序必須選擇合適大小的報文（見《UDP中一個包的大小最大能多大？》）。

3.5 不可靠性

UDP的不可靠性首先體現(xiàn)在無連接上，通信的雙方不需要建立連接，想發(fā)就發(fā)，這樣的情況肯定不可靠。

并且收到什么數(shù)據(jù)就傳遞什么數(shù)據(jù)，并且也不會備份數(shù)據(jù)，發(fā)送數(shù)據(jù)也不會關(guān)心對方是否已經(jīng)正確接收到數(shù)據(jù)了。

再者網(wǎng)絡(luò)環(huán)境時好時壞，但是 UDP 因為沒有擁塞控制，一直會以恒定的速度發(fā)送數(shù)據(jù)（即使網(wǎng)絡(luò)條件不好，也不會對發(fā)送速率進行調(diào)整）。

這樣實現(xiàn)的弊端就是在網(wǎng)絡(luò)條件不好的情況下可能會導(dǎo)致丟包，但是優(yōu)點也很明顯，在某些實時性要求高的場景（比如電話會議）就需要使用 UDP 而不是 TCP（見《網(wǎng)絡(luò)編程懶人入門(五)：快速理解為什么說UDP有時比TCP更有優(yōu)勢》）。

下面這個動圖可以很好的說明UDP的不可靠性：

從上面的動圖可以得知，UDP只會把想發(fā)的數(shù)據(jù)報文一股腦的丟給對方，并不在意數(shù)據(jù)有無安全完整到達。

3.6 頭部開銷小

UDP協(xié)議頭部開銷小（如下圖所示），傳輸數(shù)據(jù)報文時是很高效的。

▲ 上圖引用自《TCP/IP詳解 - 第11章·UDP協(xié)議》

UDP 頭部包含了以下幾個數(shù)據(jù)：

1）兩個十六位的端口號，分別為源端口（可選字段）和目標(biāo)端口；
2）整個數(shù)據(jù)報文的長度；
3）整個數(shù)據(jù)報文的檢驗和（IPv4 可選字段），該字段用于發(fā)現(xiàn)頭部信息和數(shù)據(jù)中的錯誤。

因此 UDP 的頭部開銷小，只有8字節(jié)，相比 TCP 的至少20字節(jié)要少得多，在傳輸數(shù)據(jù)報文時是很高效的。

作為對比，下圖是TCP協(xié)議的頭部開銷：

▲ 上圖引用自《TCP/IP詳解 - 第17章·TCP協(xié)議》

3.7 更全面地學(xué)習(xí)UDP協(xié)議

UDP協(xié)議相對來說比較簡單易學(xué)，如果覺得理論上有所欠缺，可以通過網(wǎng)絡(luò)經(jīng)典書籍《TCP/IP詳解 - 第11章·UDP：用戶數(shù)據(jù)報協(xié)議》中的章節(jié)來補充。

其實生產(chǎn)應(yīng)用時，UDP協(xié)議也有它復(fù)雜的一面，下面這幾篇值得學(xué)習(xí)一下：

《不為人知的網(wǎng)絡(luò)編程(五)：UDP的連接性和負載均衡》
《不為人知的網(wǎng)絡(luò)編程(六)：深入地理解UDP協(xié)議并用好它》
《不為人知的網(wǎng)絡(luò)編程(七)：如何讓不可靠的UDP變的可靠？》

另外，隨著近年來Google等互聯(lián)網(wǎng)大廠大力推廣Quic協(xié)議，UDP協(xié)議在新時代移動互聯(lián)網(wǎng)環(huán)境下或許能找到更多的應(yīng)用場景，有興趣的讀者可以學(xué)習(xí)一下QUIC協(xié)議：《網(wǎng)絡(luò)編程懶人入門(十)：一泡尿的時間，快速讀懂QUIC協(xié)議》、《技術(shù)掃盲：新一代基于UDP的低延時網(wǎng)絡(luò)傳輸層協(xié)議——QUIC詳解》、《讓互聯(lián)網(wǎng)更快：新一代QUIC協(xié)議在騰訊的技術(shù)實踐分享》。

4、快速理解TCP協(xié)議

4.1 基本介紹

當(dāng)一臺計算機想要與另一臺計算機通訊時，兩臺計算機之間的通信需要暢通且可靠，這樣才能保證正確收發(fā)數(shù)據(jù)。

例如：當(dāng)你想查看網(wǎng)頁或查看電子郵件時，希望完整且按順序查看網(wǎng)頁，而不丟失任何內(nèi)容。當(dāng)你下載文件時，希望獲得的是完整的文件，而不僅僅是文件的一部分，因為如果數(shù)據(jù)丟失或亂序，都不是你希望得到的結(jié)果，于是就用到了TCP。

TCP協(xié)議：全稱是傳輸控制協(xié)議是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議，由 IETF 的RFC 793定義。

TCP 是面向連接的、可靠的流協(xié)議。流就是指不間斷的數(shù)據(jù)結(jié)構(gòu)，你可以把它想象成排水管中的水流。

有關(guān)TCP協(xié)議的理論可以繼續(xù)閱讀《TCP/IP詳解 - 第17章·TCP：傳輸控制協(xié)議》，限于篇幅這里就展開了。

接下來我們逐個介紹TCP最主要的幾個特點。

4.2 TCP連接過程（3次握手）

如下圖所示，這是建立一個TCP連接的過程（俗稱“3次握手”）:

1）第一次握手：客戶端向服務(wù)端發(fā)送連接請求報文段。該報文段中包含自身的數(shù)據(jù)通訊初始序號。請求發(fā)送后，客戶端便進入 SYN-SENT 狀態(tài)。

2）第二次握手：服務(wù)端收到連接請求報文段后，如果同意連接，則會發(fā)送一個應(yīng)答，該應(yīng)答中也會包含自身的數(shù)據(jù)通訊初始序號，發(fā)送完成后便進入 SYN-RECEIVED 狀態(tài)。

3）第三次握手：當(dāng)客戶端收到連接同意的應(yīng)答后，還要向服務(wù)端發(fā)送一個確認報文。客戶端發(fā)完這個報文段后便進入 ESTABLISHED 狀態(tài)，服務(wù)端收到這個應(yīng)答后也進入 ESTABLISHED 狀態(tài)，此時連接建立成功。

這里可能大家會有個疑惑：為什么 TCP 建立連接需要三次握手，而不是兩次？這是因為這是為了防止出現(xiàn)失效的連接請求報文段被服務(wù)端接收的情況，從而產(chǎn)生錯誤。

下面的動畫演示了3次握手過程，可能更好懂一些：

▲ 動圖引用自《跟著動畫來學(xué)TCP三次握手和四次揮手》

4.3 TCP斷開鏈接（4次揮手）

TCP 是全雙工的，如上圖所示，在斷開連接時兩端都需要發(fā)送 FIN 和 ACK。

1）第一次揮手：若客戶端 A 認為數(shù)據(jù)發(fā)送完成，則它需要向服務(wù)端 B 發(fā)送連接釋放請求。

2）第二次揮手：B 收到連接釋放請求后，會告訴應(yīng)用層要釋放 TCP 鏈接。然后會發(fā)送 ACK 包，并進入 CLOSE_WAIT 狀態(tài)，此時表明 A 到 B 的連接已經(jīng)釋放，不再接收 A 發(fā)的數(shù)據(jù)了。但是因為 TCP 連接是雙向的，所以 B 仍舊可以發(fā)送數(shù)據(jù)給 A。

3）第三次揮手：B 如果此時還有沒發(fā)完的數(shù)據(jù)會繼續(xù)發(fā)送，完畢后會向 A 發(fā)送連接釋放請求，然后 B 便進入 LAST-ACK 狀態(tài)。

4）第四次揮手：A 收到釋放請求后，向 B 發(fā)送確認應(yīng)答，此時 A 進入 TIME-WAIT 狀態(tài)。該狀態(tài)會持續(xù) 2MSL（最大段生存期，指報文段在網(wǎng)絡(luò)中生存的時間，超時會被拋棄）時間，若該時間段內(nèi)沒有 B 的重發(fā)請求的話，就進入 CLOSED 狀態(tài)。當(dāng) B 收到確認應(yīng)答后，也便進入 CLOSED 狀態(tài)。

關(guān)于TCP的4次揮手，下面的動畫或許更生動一些：