最近石家莊橋西區(qū) yq 比較嚴重，上周我封在了公司三天，洗漱吃飯都成問題，好不容易從公司申請回家到現(xiàn)在又封控一周了，每天游離在各種 app 、微信群的搶菜環(huán)節(jié)，真的是搶而不是買，家樂福超市商品上線兩分鐘瞬間秒沒，我都不知道這群人是怎么搶菜的，難道都是圈里人？還有每天無窮無盡的核酸檢測，讓人無奈且頭疼，每天兩位數(shù)的陽性新增讓人麻木且看不到希望。今天剛接到通知，說是你可以出單元門活動活動筋骨了 ......
(相關資料圖)
說點好的：？
寫了很多篇關于 TCP 和 UDP 的文章，還沒有好好聊過這兩個協(xié)議的區(qū)別，這篇我們就來談一談這個問題。
關于 TCP 和 UDP ，想必大家都看過一張這樣的圖。
有一個小姑娘在對著瓶口慢慢喝水，下面寫著可靠的傳輸，少女的衣服沒有被水浸濕，這張圖被稱為 TCP 。
然后又有一個小姑娘在舉著水瓶以很快的速度向下倒水，少女的頭發(fā)凌亂，臉色泛紅，衣服也被水浸濕，這張圖被稱為 UDP 。
這兩張圖我認為是個程序員都能大致總結出來這兩個傳輸協(xié)議的不同點（畢竟圖上都寫的很清楚了）甚至不少同學對 UDP 產生了邪惡的念想，你說作者好好的畫個圖不行嗎，非要在臉上掛個紅，把衣服弄濕了才行。。。。。。。
咳，咱們言歸正傳，TCP 和 UDP 的區(qū)別一直是面試的重點，也是經常被用來拿來各種比較的兩個協(xié)議。
建立連接的差異TCP 建立連接需要經過三次握手，同時 TCP 斷開連接需要經過四次揮手，這也表示 TCP 是一種面向連接的協(xié)議，這個連接不是用一條網線或者一個管道把兩個通信雙方綁在一起，而是建立一條虛擬通信管道。
TCP 的三次握手流程（客戶端向服務器發(fā)送建立連接請求）：
服務端進程準備好接收來自外部的 TCP 連接，一般情況下是調用 bind、listen、socket 三個函數(shù)完成。這種打開方式被認為是被動打開(passive open)?。然后服務端進程處于LISTEN狀態(tài)，等待客戶端連接請求。客戶端通過connect?發(fā)起主動打開(active open)?，向服務器發(fā)出連接請求，請求中首部同步位 SYN = 1，同時選擇一個初始序號 sequence ，簡寫 seq = x。SYN 報文段不允許攜帶數(shù)據(jù)，只消耗一個序號。此時，客戶端進入SYN-SEND狀態(tài)。服務器收到客戶端連接后，需要確認客戶端的報文段。在確認報文段中，把 SYN 和 ACK 位都置為 1 。確認號是 ack = x + 1，同時也為自己選擇一個初始序號 seq = y。請注意，這個報文段也不能攜帶數(shù)據(jù)，但同樣要消耗掉一個序號。此時，TCP 服務器進入SYN-RECEIVED(同步收到)狀態(tài)。客戶端在收到服務器發(fā)出的響應后，需要給出確認連接。確認連接中的 ACK 置為 1 ，序號為 seq = x + 1，確認號為 ack = y + 1。TCP 規(guī)定，這個報文段可以攜帶數(shù)據(jù)也可以不攜帶數(shù)據(jù)，如果不攜帶數(shù)據(jù)，那么下一個數(shù)據(jù)報文段的序號仍是 seq = x + 1。這時，客戶端進入ESTABLISHED (已連接)狀態(tài)。服務器收到客戶的確認后，也進入ESTABLISHED狀態(tài)。而 UDP 是面向數(shù)據(jù)報的協(xié)議，所以 UDP 壓根不會有連接的概念，也就不會有三次握手建立連接的過程。
數(shù)據(jù)傳輸結束后，通信雙方可以釋放連接。數(shù)據(jù)傳輸結束后的客戶端主機和服務端主機都處于 ESTABLISHED 狀態(tài)，然后進入釋放連接的過程。
（客戶端主機主動關閉連接）
TCP 斷開連接需要歷經的過程如下：
客戶端應用程序發(fā)出釋放連接的報文段，并停止發(fā)送數(shù)據(jù)，主動關閉 TCP 連接?？蛻舳酥鳈C發(fā)送釋放連接的報文段，報文段中首部 FIN 位置為 1 ，不包含數(shù)據(jù)，序列號位 seq = u，此時客戶端主機進入FIN-WAIT-1(終止等待 1)階段。服務器主機接收到客戶端發(fā)出的報文段后，即發(fā)出確認應答報文，確認應答報文中 ACK = 1，生成自己的序號位 seq = v，ack = u + 1，然后服務器主機就進入CLOSE-WAIT(關閉等待)狀態(tài)，這個時候客戶端主機 -> 服務器主機這條方向的連接就釋放了，客戶端主機沒有數(shù)據(jù)需要發(fā)送，此時服務器主機是一種半連接的狀態(tài)，但是服務器主機仍然可以發(fā)送數(shù)據(jù)?？蛻舳酥鳈C收到服務端主機的確認應答后，即進入FIN-WAIT-2(終止等待2)的狀態(tài)。等待客戶端發(fā)出連接釋放的報文段。當服務器主機沒有數(shù)據(jù)發(fā)送后，應用進程就會通知 TCP 釋放連接。這時服務端主機會發(fā)出斷開連接的報文段，報文段中 ACK = 1，序列號 seq = w，因為在這之間可能已經發(fā)送了一些數(shù)據(jù)，所以 seq 不一定等于 v + 1。ack = u + 1，在發(fā)送完斷開請求的報文后，服務端主機就進入了LAST-ACK(最后確認)的階段?？蛻舳耸盏椒斩说臄嚅_連接請求后，客戶端需要作出響應，客戶端發(fā)出斷開連接的報文段，在報文段中，ACK = 1, 序列號 seq = u + 1，因為客戶端從連接開始斷開后就沒有再發(fā)送數(shù)據(jù)，ack = w + 1，然后進入到TIME-WAIT(時間等待)?狀態(tài)，請注意，這個時候 TCP 連接還沒有釋放。必須經過時間等待的設置，也就是2MSL?后，客戶端才會進入CLOSED?狀態(tài)，時間 MSL 叫做最長報文段壽命（Maximum Segment Lifetime）。服務端主要收到了客戶端的斷開連接確認后，就會進入 CLOSED 狀態(tài)。因為服務端結束 TCP 連接時間要比客戶端早，而整個連接斷開過程需要發(fā)送四個報文段，因此釋放連接的過程也被稱為四次揮手。UDP 不存在這條連接，所以它也不需要四次揮手操作。
所以總結一點：TCP 是面向連接的，它的數(shù)據(jù)傳輸前需要維護一條虛擬連接，數(shù)據(jù)傳輸需要在這條虛擬連接上進行，數(shù)據(jù)傳輸完畢后需要斷開這條連接，而 UDP 傳輸不是面向連接的，UDP 發(fā)送數(shù)據(jù)不會建立連接，也不會關心接收端的狀態(tài)。
可靠性的差異TCP 和 UDP 一個主要拿來作對比的就是可靠性，TCP 是一種可靠性的傳輸層協(xié)議，UDP 是一種不可靠的傳輸層協(xié)議。TCP 的這種可靠性主要由下面這些特征來保證：
通過序列號和應答號實現(xiàn)可靠性
計算機網絡主機之間的相互通信非常類似于我們日常生活中兩個人之間打電話，這種對話通常是一問一答形式，如果你講了一句話并沒有收到任何回應，你通常需要再說一次來確保對方是否聽到，如果對方給你回應了一句話，就說明他已經聽到你的講話了，這就是一個完整的通話流程（拋開建立連接不談，我們著重點放在建立連接之后）。
"對方給你的響應" 在計算機網絡中被稱為確認應答(ACK)?，TCP 就是通過 ACK 來實現(xiàn)可靠的數(shù)據(jù)傳輸，也就是說，發(fā)送方在發(fā)出請求之后會等待目標主機的響應，如果沒有收到響應，發(fā)送方在經過一段時間后就會重傳請求。所以，即使在發(fā)送過程中產生丟包，TCP 仍然能夠通過重傳來實現(xiàn)可靠性。
上面描述的情況屬于發(fā)送方請求丟失，還有一種情況屬于響應丟失，也就是說請求發(fā)送到目標主機后，目標主機會發(fā) ACK 給請求方，這個 ACK 也有可能丟失，如果 ACK 在鏈路中丟失，一段時間后請求方沒有收到目標主機的 ACK ，仍然會選擇重傳未收到 ACK 的這個請求。
除了消息丟失之外，還存在一種延遲到達的現(xiàn)象，延遲到達指的是發(fā)送方發(fā)送一個報文段之后，這個報文也許是由于網絡抖動或者網絡擁堵導致一個報文段遲遲沒有到達目標主機，或者目標主機的響應 ACK 遲遲沒有到達發(fā)送方的現(xiàn)象。這個一段時間判斷的標準就是重傳時間，一旦過了重傳時間發(fā)送方會重傳報文段，很可能存在重傳報文段到達之后，第一次發(fā)送的報文段才剛到的情況，這就存在一個問題：目標主機收到了兩個相同的報文段。必須選擇一個報文段進行丟棄，但是應該選擇哪個報文段呢？
可以通過序列號（seq）來實現(xiàn)，序列號是按照順序給發(fā)送數(shù)據(jù)的每一個字節(jié)都標上號碼的編號。接收端通過查詢 TCP 首部中的序列號和數(shù)據(jù)的長度，將自己下一步應該接收的序列號作為確認應答返送回去。通過序列號和確認應答號，TCP 能夠識別是否已經接收數(shù)據(jù)，又能夠判斷是否需要接收，從而實現(xiàn)可靠傳輸。
如上圖所示，請求按照順序發(fā)送的話是 seq = 1 ，這個請求會把第 1 字節(jié)到第 n 字節(jié)的數(shù)據(jù)一起發(fā)送過去，等待目標主機一次確認每個字節(jié)后，再發(fā)送 seq = n + 1 的請求，確認完成后再發(fā)送 seq = m + 1 的請求，這樣能夠保證序列號不會重復。
UDP 沒有所謂的序列號和確認號，所以不會對數(shù)據(jù)進行確認，數(shù)據(jù)丟失后也不會進行重傳，所以 UDP 是一種不可靠的協(xié)議。
如果使用 TCP 和 UDP 來比喻開發(fā)人員：TCP 就是那種凡事都要設計好，沒設計不會進行開發(fā)的工程師，需要把一切因素考慮在內后再開干！所以非常靠譜?；而 UDP 就是那種上來直接干干干，接到項目需求馬上就開干，也不管設計，也不管技術選型，就是干，這種開發(fā)人員非常不靠譜，但是適合快速迭代開發(fā)，因為可以馬上上手！
有序性差異我們上面說到，TCP 會對請求分開發(fā)送，每次請求所攜帶的數(shù)據(jù)都會被目標主機進行確認，目標主機依次確認每個請求后，就會對請求中的數(shù)據(jù)進行重組，由于請求是由 seq 的，所以 TCP 在重組這些數(shù)據(jù)時，也會按照順序進行重組，而 UDP 沒有有序性的這種保證。
報文段的差異
TCP 和 UDP 同屬于傳輸層協(xié)議，傳輸層協(xié)議傳輸?shù)臄?shù)據(jù)統(tǒng)稱為報文段，TCP 和 UDP 的報文段的主要差異如下。
UDP 報文段結構源端口號(Source Port):這個字段占據(jù) UDP 報文頭的前 16 位，通常包含發(fā)送數(shù)據(jù)報的應用程序所使用的 UDP 端口。接收端的應用程序利用這個字段的值作為發(fā)送響應的目的地址。這個字段是可選項，有時不會設置源端口號。沒有源端口號就默認為 0 ，通常用于不需要返回消息的通信中。目標端口號(Destination Port): 表示接收端端口，字段長為 16 位。長度(Length): 該字段占據(jù) 16 位，表示 UDP 數(shù)據(jù)報長度，包含 UDP 報文頭和 UDP 數(shù)據(jù)長度。因為 UDP 報文頭長度是 8 個字節(jié)，所以這個值最小為 8，最大長度為 2 ^ 16 = 65535 字節(jié)。校驗和(Checksum)：UDP 使用校驗和來保證數(shù)據(jù)安全性，UDP 的校驗和也提供了差錯檢測功能，差錯檢測用于校驗報文段從源到目標主機的過程中，數(shù)據(jù)的完整性是否發(fā)生了改變。TCP 報文段結構
TCP 報文段結構相比 UDP 報文結構多了很多內容。但是前兩個 32 比特的字段是一樣的。它們是源端口號?和目標端口號?。另外，和 UDP 一樣，TCP 也包含校驗和(checksum field)，除此之外，TCP 報文段首部還有下面這些
32 比特的序號字段(sequence number field)?和 32 比特的確認號字段(acknowledgment number field)。這些字段被 TCP 發(fā)送方和接收方用來實現(xiàn)可靠的數(shù)據(jù)傳輸。4 比特的首部字段長度字段(header length field)，這個字段指示了以 32 比特的字為單位的 TCP 首部長度。TCP 首部的長度是可變的，但是通常情況下，選項字段為空，所以 TCP 首部字段的長度是 20 字節(jié)。16 比特的接受窗口字段(receive window field)，這個字段用于流量控制。它用于指示接收方能夠/愿意接受的字節(jié)數(shù)量可變的選項字段(options field)，這個字段用于發(fā)送方和接收方協(xié)商最大報文長度，也就是 MSS 時使用6 比特的標志字段(flag field)?，ACK?標志用于指示確認字段中的值是有效的，這個報文段包括一個對已被成功接收報文段的確認；RST、SYN、FIN?標志用于連接的建立和關閉；CWR?和ECE?用于擁塞控制；PSH?標志用于表示立刻將數(shù)據(jù)交給上層處理；URG?標志用來表示數(shù)據(jù)中存在需要被上層處理的緊急數(shù)據(jù)。緊急數(shù)據(jù)最后一個字節(jié)由 16 比特的緊急數(shù)據(jù)指針字段(urgeent data pointer field)指出。一般情況下，PSH 和 URG 并沒有使用。所以從報文段結構的對比可以看出，TCP 相比 UDP 多了許多 Flags、序號和確認號，這些都屬于 TCP 的連接控制。除此之外還有接收窗口，這些屬于擁塞控制和流量控制的內容。TCP 的首部開銷要比 UDP 大，因為 TCP 首部固定有 20 字節(jié)，UDP 首部固定才 8 字節(jié)。TCP 和 UDP 都提供了數(shù)據(jù)校驗功能。
效率的差異TCP 報文段的發(fā)送采用的是"一問一答"形式的，每個請求都會被目標主機確認后再發(fā)送下一條報文，效率很慢，后來為了解決這個問題，TCP 引入了窗口這個概念，即使在往返時間較長、頻次很多的情況下，它也能控制網絡性能的下降。
我們之前每次請求發(fā)送都是以報文段的形式進行的，引入窗口后，每次請求都可以發(fā)送多個報文段，也就是說一個窗口可以發(fā)送多個報文段。窗口大小就是指無需等待確認應答就可以繼續(xù)發(fā)送報文段的最大值。
在這個窗口機制中，大量使用了緩沖區(qū)，通過對多個段同時進行確認應答的功能。
如下圖所示，發(fā)送報文段中高亮部分即是我們提到的窗口，在窗口內，即使沒有收到確認應答也可以把請求發(fā)送出去。不過，在整個窗口的確認應答沒有到達之前，如果部分報文段丟失，那么發(fā)送方將仍會重傳。為此，發(fā)送方需要設置緩存來保留這些需要重傳的報文段，直到收到他們的確認應答。
在滑動窗口以外的部分是尚未發(fā)送的報文段和已經接收到的報文段，如果報文段已經收到確認則不可進行重發(fā)，此時報文段就可以從緩沖區(qū)中清除。
在收到確認的情況下，會將窗口滑動到確認應答中確認號的位置，如上圖所示，這樣可以順序將多個段同時發(fā)送，用以提高通信性能，這種窗口也叫做滑動窗口(Sliding window)。
UDP 發(fā)送的報文段不需要確認，也就沒有窗口的概念，所以 UDP 傳輸效率比較高。
使用場景的差異TCP 和 UDP 在效率、報文段、流量控制、連接管理上均存在差異，由于這些差異導致了應用場景要有不同的選擇，由于 TCP 每個包都需要進行確認，因此 TCP 不適合告訴傳輸數(shù)據(jù)的場景，像是這種場景使用 UDP 就好了；像是 Ping 和 DNS Lookup，這類型的操作只需要一次簡單的請求/返回，不需要建立連接，用 UDP 就足夠了。比如 HTTP 協(xié)議需要考慮請求響應的可靠性，這種場景應該使用 TCP 協(xié)議，但是像 HTTP 3.0 這類應用層協(xié)議，從功能性上思考，暫時沒有找到太多的優(yōu)化點，但是想要把網絡優(yōu)化到極致，就會用 UDP 作為底層技術，然后在 UDP 基礎上解決可靠性。
標簽：
