前言

網際網路江湖中，UDP如莽夫仗劍疾行，以無連線之刃斬開資料洪流，寧丟包亦不折速度鋒芒；TCP似儒雅紳士，借三次握手執禮相待，攜重傳機制與流量控制，在可靠傳輸中織就秩序經緯。二者剛柔相濟：即時影片裡UDP的快意恩仇，網頁載入時TCP的君子之約，恰似武林中並存的狂放劍意與綿密掌法，共築數字世界的通訊哲學。

莽夫：UDP協議

想必大家肯定都看過《狂飆》這部電視劇吧，裡面一些角色想必大家都印象深刻就比如莽村的李宏偉，而我們現在所要講述的 UDP協議它就出自莽村。

image.png

面向無連線

現在大家可以先想象一個場景，當我們要發快遞給某個人的時候，即使我們知道了收件人的地址，我們還需要先向收件人確認一下基礎資訊。而 UDP協議 就不一樣了它發快遞的時候，只要知道了對面的地址就直接傳送快遞，並不會管別的東西，這就是他身為莽夫的第一層境界。

面向無連線（知道了對面的 ip 後就直接傳輸資料）

只做資料報文的搬運工

相信大家都聽過農夫山泉的一個廣告詞：我們不生產水，我們只是大自然的搬運工。而 UDP協議除了莽之外還有點懶，他並不參與資料報文的生成，而是直接拿到本來要傳送的資料經過一系列處理之後得到的資料報文進行傳送，並且不會增加額外的報文頭部。

image.png

只做資料報文（有頭和體）的搬運工（不增加額外的報文頭部，頭部開銷比較小隻有8個位元組）

不保證資料的有序性和可靠性

關於他的這一點我覺得大家應該能理解，上面兩點我們可以看出來這個莽夫並不是一個可靠的人，接下來我們還是以發快遞的情景來模仿。

如果我們在網上買一些需要按照順序組裝的東西的話，那麼在發快遞的時候就會幫你提前按照順序來編號之類的方便你組裝，並且一般會全部都打包給你。但是 UDP 它就是個急性子，它一拿到廠家給你的零件就直接傳送了，也不會管你排序什麼的，這就不能保證傳輸過來資料的有序性了。除此之外，由於它比較急急忙忙的多少都會有點丟三落四，這就引出了它的另一個缺點，它在傳輸的過程中不保證資料的可靠性，可能會丟包，也就是把你所需要的零件可能路上丟失了。

1742109718971.png

不保證資料包的有序性

不保證資料的可靠性（丟包）

沒有擁塞控制

說起這個擁塞控制呢，大家在生活中肯定遇到過，當我們在刷影片或者看電視劇的時候，如果網路環境不好的話它就會一卡一卡的，而這個擁塞控制呢就是根據網路環境來控制這個網路傳輸速度的。

由於 UDP協議沒有擁塞控制，所以它在進行傳輸的時候，速率是恆定的，並不會因為網路環境的變化而降低速率，這就會導致上面的丟包的出現。幹就完了！！！

1742110023624.png

高效

我們知道它沒有擁塞控制之後，那麼在我們看電視或者刷影片的時候並不會因為網路環境而影響我們的傳輸速率，這一點就成就了它高效的一個特點。

UDP 小結

面向無連線（知道了對面的 ip 後就直接傳輸資料）

只做資料報文（有頭和體）的搬運工（不增加額外的報文頭部，頭部開銷比較小隻有8個位元組）

不保證資料包的有序性

不保證資料的可靠性（丟包）

沒有擁塞控制

高效（前五點都是高效）

應用場景：直播，影片，遊戲，即時性要求高的應用

紳士：TCP協議

現在都是文明社會了，咱就不搞UDP的莽村那一套了，咱們來聊一聊更適合我們社會的 TCP協議，他在進行資訊傳輸的時候並不會像 UDP 一樣知道你ip地址直接塞給你就是了，而是會先詢問一下你的意見，這就是我們常說的TCP三次握手，並且在傳輸完了資訊之後還會非常友好的跟你說：say goodbye，也就是我們常說的TCP四次揮手，接下來我們來學習一下它的紳士禮儀。

image.png

頭部資訊多

在上文中我們聊到 UDP 是資料報文的搬運工，但是 TCP 就比較勤快了，它會往報文的頭部新增一些資訊用來告訴服務端它想要服務端做的事情，它一般會往頭部新增下面的資訊。

Sequence Number （序列號）
Acknowledgment Number （確認號）
Window Size （視窗大小，當前網路環境支援傳輸多少位元組的資料）
識別符號

識別符號	識別符號含義
URG	緊急報文
ACK	確認報文表示當前報文有效
PSH	接收端應該立即將資料傳給應用層
SYN	建立連線
RST	需要重連
FIN	關閉連線

TCP 三次握手

在我們簡單瞭解完了 TCP 會往頭部新增什麼之後，接下來我們就來學習一下紳士是如何與人溝通的。當我們客戶端向服務端使用 TCP 協議傳送資訊的時候，通常會透過識別符號來判斷你是想要跟我溝通還是不想跟我溝通而這個過程就是我們所說的 TCP三次握手。

首先我們先來了解一下 TCP 三次握手的大致流程，這個場景呢就好比我們去大街上看到心儀的小姐姐，當我們加上小姐姐的vx之後，我們肯定要跟小姐姐進行交流，而交流的經典三部曲就是：

image.png

而我們將聊天記錄翻譯成我們程式設計師的過程就是：

image.png

TCP三次握手過程：

客戶端傳送 SYN 報文，請求建立連線（客戶端進入 SYN-SEND 狀態）

服務端收到 SYN 報文，回覆 SYN + ACK 報文，表示同意建立連線（服務端進入 SYN-RECEIVED 狀態，如果服務端停留在這個狀態一段時間會自動關閉）

客戶端接收到 SYN + ACK 報文，回覆 ACK 報文，表示連線建立成功（客戶端和服務端同時進入 ESTABLISHED 狀態）

面試官：為什麼需要三次握手？兩次握手行不行？

當我們瞭解了什麼是TCP三次握手之後，可能就會有同學感到疑惑了，為什麼後面還要回復服務端一個好的？如果我只進行兩次握手，知道了服務端在的話不就好了。我們都知道東西能簡單肯定不復雜，面試官能問出來的問題肯定有坑，接下來我們用一個場景來模擬一下為什麼需要三次握手。

首先我們有兩個端客戶端 A 和服務端 B ，當 A 向 B 第一次傳送 SYN 報文請求建立連線時，此時由於網路環境不好導致了 SYN 報文的丟失，這個時候由於客戶端的一個機制：當一段時間沒有收到回覆之後會重新發送 SYN 報文。A 就又向 B 傳送了一個 SYN 報文，接下來的過程就完整的走完了 TCP三次握手的流程，客戶端 A 關閉。

這時，可能網路環境突然又好起來了，第一次傳送的 SYN 報文有可能再次出現再次出現在網路環境中被服務端 B 接收到，當 B 接收到第一次傳送的 SYN 報文之後，此時 B 向 A返回 SYN + ACK 報文，並且 B 進入ESTABLISHED狀態，此時由於 A 已經關閉，所以 B 會一直處於這個狀態從而進入死鎖狀態造成資源的浪費。

TCP 四次揮手

跟小姐姐聊天的美好時光總是短暫的，在我們跟小姐姐交流完了之後到點了該打瓦了，這時候就得對小姐姐說再見了，咱們跟小姐姐告別的時候得說一些適當的話，在這裡呢我們來學習一下 TCP四次揮手。

同樣的我們先來了解一下 TCP四次揮手的大致流程，同樣的我們模擬一個跟小姐姐聊天的場景，當我們跟小姐姐聊天的時候突然想打瓦了，這時候我們就得對小姐姐說再見，小姐姐收到後給你發了個好的，可能之前還在打字給你發訊息，接著她將剛剛沒發完的訊息發給你之後，就發了句晚安，這時候你就可以告訴她你收到了並且回了個晚安。

接下來我們用一張過程圖給大家展示：

image.png

TCP 四次揮手過程：

客戶端向服務端傳送 FIN 報文，請求斷開連線（客戶端進入FIN-WAIT-1 狀態）

服務端收到 FIN 報文，回覆 ACK 報文（服務端進入 CLOSE-WAIT 狀態）

服務端將未傳輸完的資料傳輸完後，向客戶端傳送 FIN 報文，請求斷開連線（服務端進入 LAST-ACK 狀態）

客戶端收到 FIN 報文，回覆 ACK 報文（客戶端進入 TIME-WAIT 狀態，一段時間後 CLOSEED）此時服務端進入 CLOSEED 狀態