TCP和UDP建立連接的差異和可靠性的差異

寫了很多篇關(guān)于 TCP 和 UDP 的文章，還沒有好好聊過這兩個(gè)協(xié)議的區(qū)別，這篇我們就來談一談這個(gè)問題。

關(guān)于 TCP 和 UDP ，想必大家都看過一張這樣的圖。

有一個(gè)小姑娘在對(duì)著瓶口慢慢喝水，下面寫著可靠的傳輸，少女的衣服沒有被水浸濕，這張圖被稱為 TCP 。

然后又有一個(gè)小姑娘在舉著水瓶以很快的速度向下倒水，少女的頭發(fā)凌亂，臉色泛紅，衣服也被水浸濕，這張圖被稱為 UDP 。

這兩張圖我認(rèn)為是個(gè)程序員都能大致總結(jié)出來這兩個(gè)傳輸協(xié)議的不同點(diǎn)（畢竟圖上都寫的很清楚了）甚至不少同學(xué)對(duì) UDP 產(chǎn)生了邪惡的念想，你說作者好好的畫個(gè)圖不行嗎，非要在臉上掛個(gè)紅，把衣服弄濕了才行。。。。。。。

咳，咱們言歸正傳，TCP 和 UDP 的區(qū)別一直是面試的重點(diǎn)，也是經(jīng)常被用來拿來各種比較的兩個(gè)協(xié)議。

建立連接的差異

TCP 建立連接需要經(jīng)過三次握手，同時(shí) TCP 斷開連接需要經(jīng)過四次揮手，這也表示 TCP 是一種面向連接的協(xié)議，這個(gè)連接不是用一條網(wǎng)線或者一個(gè)管道把兩個(gè)通信雙方綁在一起，而是建立一條虛擬通信管道。

TCP 的三次握手流程（客戶端向服務(wù)器發(fā)送建立連接請(qǐng)求）：

服務(wù)端進(jìn)程準(zhǔn)備好接收來自外部的 TCP 連接，一般情況下是調(diào)用 bind、listen、socket 三個(gè)函數(shù)完成。這種打開方式被認(rèn)為是 被動(dòng)打開(passive open)。然后服務(wù)端進(jìn)程處于 LISTEN 狀態(tài)，等待客戶端連接請(qǐng)求。

客戶端通過 connect 發(fā)起主動(dòng)打開(active open)，向服務(wù)器發(fā)出連接請(qǐng)求，請(qǐng)求中首部同步位 SYN = 1，同時(shí)選擇一個(gè)初始序號(hào) sequence ，簡(jiǎn)寫 seq = x。SYN 報(bào)文段不允許攜帶數(shù)據(jù)，只消耗一個(gè)序號(hào)。此時(shí)，客戶端進(jìn)入 SYN-SEND 狀態(tài)。

服務(wù)器收到客戶端連接后，需要確認(rèn)客戶端的報(bào)文段。在確認(rèn)報(bào)文段中，把 SYN 和 ACK 位都置為 1 。確認(rèn)號(hào)是 ack = x + 1，同時(shí)也為自己選擇一個(gè)初始序號(hào) seq = y。請(qǐng)注意，這個(gè)報(bào)文段也不能攜帶數(shù)據(jù)，但同樣要消耗掉一個(gè)序號(hào)。此時(shí)，TCP 服務(wù)器進(jìn)入 SYN-RECEIVED(同步收到) 狀態(tài)。

客戶端在收到服務(wù)器發(fā)出的響應(yīng)后，需要給出確認(rèn)連接。確認(rèn)連接中的 ACK 置為 1 ，序號(hào)為 seq = x + 1，確認(rèn)號(hào)為 ack = y + 1。TCP 規(guī)定，這個(gè)報(bào)文段可以攜帶數(shù)據(jù)也可以不攜帶數(shù)據(jù)，如果不攜帶數(shù)據(jù)，那么下一個(gè)數(shù)據(jù)報(bào)文段的序號(hào)仍是 seq = x + 1。這時(shí)，客戶端進(jìn)入 ESTABLISHED (已連接) 狀態(tài)。

服務(wù)器收到客戶的確認(rèn)后，也進(jìn)入 ESTABLISHED 狀態(tài)。

而 UDP 是面向數(shù)據(jù)報(bào)的協(xié)議，所以 UDP 壓根不會(huì)有連接的概念，也就不會(huì)有三次握手建立連接的過程。

數(shù)據(jù)傳輸結(jié)束后，通信雙方可以釋放連接。數(shù)據(jù)傳輸結(jié)束后的客戶端主機(jī)和服務(wù)端主機(jī)都處于 ESTABLISHED 狀態(tài)，然后進(jìn)入釋放連接的過程。

（客戶端主機(jī)主動(dòng)關(guān)閉連接）

TCP 斷開連接需要?dú)v經(jīng)的過程如下

客戶端應(yīng)用程序發(fā)出釋放連接的報(bào)文段，并停止發(fā)送數(shù)據(jù)，主動(dòng)關(guān)閉 TCP 連接?？蛻舳酥鳈C(jī)發(fā)送釋放連接的報(bào)文段，報(bào)文段中首部 FIN 位置為 1 ，不包含數(shù)據(jù)，序列號(hào)位 seq = u，此時(shí)客戶端主機(jī)進(jìn)入 FIN-WAIT-1(終止等待 1) 階段。

服務(wù)器主機(jī)接收到客戶端發(fā)出的報(bào)文段后，即發(fā)出確認(rèn)應(yīng)答報(bào)文，確認(rèn)應(yīng)答報(bào)文中 ACK = 1，生成自己的序號(hào)位 seq = v，ack = u + 1，然后服務(wù)器主機(jī)就進(jìn)入 CLOSE-WAIT(關(guān)閉等待) 狀態(tài)，這個(gè)時(shí)候客戶端主機(jī) -> 服務(wù)器主機(jī)這條方向的連接就釋放了，客戶端主機(jī)沒有數(shù)據(jù)需要發(fā)送，此時(shí)服務(wù)器主機(jī)是一種半連接的狀態(tài)，但是服務(wù)器主機(jī)仍然可以發(fā)送數(shù)據(jù)。

客戶端主機(jī)收到服務(wù)端主機(jī)的確認(rèn)應(yīng)答后，即進(jìn)入 FIN-WAIT-2(終止等待2) 的狀態(tài)。等待客戶端發(fā)出連接釋放的報(bào)文段。

當(dāng)服務(wù)器主機(jī)沒有數(shù)據(jù)發(fā)送后，應(yīng)用進(jìn)程就會(huì)通知 TCP 釋放連接。這時(shí)服務(wù)端主機(jī)會(huì)發(fā)出斷開連接的報(bào)文段，報(bào)文段中 ACK = 1，序列號(hào) seq = w，因?yàn)樵谶@之間可能已經(jīng)發(fā)送了一些數(shù)據(jù)，所以 seq 不一定等于 v + 1。ack = u + 1，在發(fā)送完斷開請(qǐng)求的報(bào)文后，服務(wù)端主機(jī)就進(jìn)入了 LAST-ACK(最后確認(rèn))的階段。

客戶端收到服務(wù)端的斷開連接請(qǐng)求后，客戶端需要作出響應(yīng)，客戶端發(fā)出斷開連接的報(bào)文段，在報(bào)文段中，ACK = 1, 序列號(hào) seq = u + 1，因?yàn)榭蛻舳藦倪B接開始斷開后就沒有再發(fā)送數(shù)據(jù)，ack = w + 1，然后進(jìn)入到 TIME-WAIT(時(shí)間等待) 狀態(tài)，請(qǐng)注意，這個(gè)時(shí)候 TCP 連接還沒有釋放。必須經(jīng)過時(shí)間等待的設(shè)置，也就是 2MSL 后，客戶端才會(huì)進(jìn)入 CLOSED 狀態(tài)，時(shí)間 MSL 叫做最長(zhǎng)報(bào)文段壽命（Maximum Segment Lifetime）。

服務(wù)端主要收到了客戶端的斷開連接確認(rèn)后，就會(huì)進(jìn)入 CLOSED 狀態(tài)。因?yàn)榉?wù)端結(jié)束 TCP 連接時(shí)間要比客戶端早，而整個(gè)連接斷開過程需要發(fā)送四個(gè)報(bào)文段，因此釋放連接的過程也被稱為四次揮手。

UDP 不存在這條連接，所以它也不需要四次揮手操作。

所以總結(jié)一點(diǎn)：TCP 是面向連接的，它的數(shù)據(jù)傳輸前需要維護(hù)一條虛擬連接，數(shù)據(jù)傳輸需要在這條虛擬連接上進(jìn)行，數(shù)據(jù)傳輸完畢后需要斷開這條連接，而 UDP 傳輸不是面向連接的，UDP 發(fā)送數(shù)據(jù)不會(huì)建立連接，也不會(huì)關(guān)心接收端的狀態(tài)。

可靠性的差異

TCP 和 UDP 一個(gè)主要拿來作對(duì)比的就是可靠性，TCP 是一種可靠性的傳輸層協(xié)議，UDP 是一種不可靠的傳輸層協(xié)議。TCP 的這種可靠性主要由下面這些特征來保證：

通過序列號(hào)和應(yīng)答號(hào)實(shí)現(xiàn)可靠性

計(jì)算機(jī)網(wǎng)絡(luò)主機(jī)之間的相互通信非常類似于我們?nèi)粘Ｉ钪袃蓚€(gè)人之間打電話，這種對(duì)話通常是一問一答形式，如果你講了一句話并沒有收到任何回應(yīng)，你通常需要再說一次來確保對(duì)方是否聽到，如果對(duì)方給你回應(yīng)了一句話，就說明他已經(jīng)聽到你的講話了，這就是一個(gè)完整的通話流程（拋開建立連接不談，我們著重點(diǎn)放在建立連接之后）。

"對(duì)方給你的響應(yīng)" 在計(jì)算機(jī)網(wǎng)絡(luò)中被稱為確認(rèn)應(yīng)答(ACK)，TCP 就是通過 ACK 來實(shí)現(xiàn)可靠的數(shù)據(jù)傳輸，也就是說，發(fā)送方在發(fā)出請(qǐng)求之后會(huì)等待目標(biāo)主機(jī)的響應(yīng)，如果沒有收到響應(yīng)，發(fā)送方在經(jīng)過一段時(shí)間后就會(huì)重傳請(qǐng)求。所以，即使在發(fā)送過程中產(chǎn)生丟包，TCP 仍然能夠通過重傳來實(shí)現(xiàn)可靠性。

上面描述的情況屬于發(fā)送方請(qǐng)求丟失，還有一種情況屬于響應(yīng)丟失，也就是說請(qǐng)求發(fā)送到目標(biāo)主機(jī)后，目標(biāo)主機(jī)會(huì)發(fā) ACK 給請(qǐng)求方，這個(gè) ACK 也有可能丟失，如果 ACK 在鏈路中丟失，一段時(shí)間后請(qǐng)求方?jīng)]有收到目標(biāo)主機(jī)的 ACK ，仍然會(huì)選擇重傳未收到 ACK 的這個(gè)請(qǐng)求。

除了消息丟失之外，還存在一種延遲到達(dá)的現(xiàn)象，延遲到達(dá)指的是發(fā)送方發(fā)送一個(gè)報(bào)文段之后，這個(gè)報(bào)文也許是由于網(wǎng)絡(luò)抖動(dòng)或者網(wǎng)絡(luò)擁堵導(dǎo)致一個(gè)報(bào)文段遲遲沒有到達(dá)目標(biāo)主機(jī)，或者目標(biāo)主機(jī)的響應(yīng) ACK 遲遲沒有到達(dá)發(fā)送方的現(xiàn)象。這個(gè)一段時(shí)間判斷的標(biāo)準(zhǔn)就是重傳時(shí)間，一旦過了重傳時(shí)間發(fā)送方會(huì)重傳報(bào)文段，很可能存在重傳報(bào)文段到達(dá)之后，第一次發(fā)送的報(bào)文段才剛到的情況，這就存在一個(gè)問題：目標(biāo)主機(jī)收到了兩個(gè)相同的報(bào)文段。必須選擇一個(gè)報(bào)文段進(jìn)行丟棄，但是應(yīng)該選擇哪個(gè)報(bào)文段呢？

可以通過序列號(hào)（seq）來實(shí)現(xiàn)，序列號(hào)是按照順序給發(fā)送數(shù)據(jù)的每一個(gè)字節(jié)都標(biāo)上號(hào)碼的編號(hào)。接收端通過查詢 TCP 首部中的序列號(hào)和數(shù)據(jù)的長(zhǎng)度，將自己下一步應(yīng)該接收的序列號(hào)作為確認(rèn)應(yīng)答返送回去。通過序列號(hào)和確認(rèn)應(yīng)答號(hào)，TCP 能夠識(shí)別是否已經(jīng)接收數(shù)據(jù)，又能夠判斷是否需要接收，從而實(shí)現(xiàn)可靠傳輸。

如上圖所示，請(qǐng)求按照順序發(fā)送的話是 seq = 1 ，這個(gè)請(qǐng)求會(huì)把第 1 字節(jié)到第 n 字節(jié)的數(shù)據(jù)一起發(fā)送過去，等待目標(biāo)主機(jī)一次確認(rèn)每個(gè)字節(jié)后，再發(fā)送 seq = n + 1 的請(qǐng)求，確認(rèn)完成后再發(fā)送 seq = m + 1 的請(qǐng)求，這樣能夠保證序列號(hào)不會(huì)重復(fù)。

UDP 沒有所謂的序列號(hào)和確認(rèn)號(hào)，所以不會(huì)對(duì)數(shù)據(jù)進(jìn)行確認(rèn)，數(shù)據(jù)丟失后也不會(huì)進(jìn)行重傳，所以 UDP 是一種不可靠的協(xié)議。

如果使用 TCP 和 UDP 來比喻開發(fā)人員：TCP 就是那種凡事都要設(shè)計(jì)好，沒設(shè)計(jì)不會(huì)進(jìn)行開發(fā)的工程師，需要把一切因素考慮在內(nèi)后再開干！所以非常靠譜；而 UDP 就是那種上來直接干干干，接到項(xiàng)目需求馬上就開干，也不管設(shè)計(jì)，也不管技術(shù)選型，就是干，這種開發(fā)人員非常不靠譜，但是適合快速迭代開發(fā)，因?yàn)榭梢择R上上手！

有序性差異

我們上面說到，TCP 會(huì)對(duì)請(qǐng)求分開發(fā)送，每次請(qǐng)求所攜帶的數(shù)據(jù)都會(huì)被目標(biāo)主機(jī)進(jìn)行確認(rèn)，目標(biāo)主機(jī)依次確認(rèn)每個(gè)請(qǐng)求后，就會(huì)對(duì)請(qǐng)求中的數(shù)據(jù)進(jìn)行重組，由于請(qǐng)求是由 seq 的，所以 TCP 在重組這些數(shù)據(jù)時(shí)，也會(huì)按照順序進(jìn)行重組，而 UDP 沒有有序性的這種保證。

報(bào)文段的差異

TCP 和 UDP 同屬于傳輸層協(xié)議，傳輸層協(xié)議傳輸?shù)臄?shù)據(jù)統(tǒng)稱為報(bào)文段，TCP 和 UDP 的報(bào)文段的主要差異如下。

UDP 報(bào)文段結(jié)構(gòu)

源端口號(hào)(Source Port) :這個(gè)字段占據(jù) UDP 報(bào)文頭的前 16 位，通常包含發(fā)送數(shù)據(jù)報(bào)的應(yīng)用程序所使用的 UDP 端口。接收端的應(yīng)用程序利用這個(gè)字段的值作為發(fā)送響應(yīng)的目的地址。這個(gè)字段是可選項(xiàng)，有時(shí)不會(huì)設(shè)置源端口號(hào)。沒有源端口號(hào)就默認(rèn)為 0 ，通常用于不需要返回消息的通信中。

目標(biāo)端口號(hào)(Destination Port): 表示接收端端口，字段長(zhǎng)為 16 位。

長(zhǎng)度(Length): 該字段占據(jù) 16 位，表示 UDP 數(shù)據(jù)報(bào)長(zhǎng)度，包含 UDP 報(bào)文頭和 UDP 數(shù)據(jù)長(zhǎng)度。因?yàn)?UDP 報(bào)文頭長(zhǎng)度是 8 個(gè)字節(jié)，所以這個(gè)值最小為 8，最大長(zhǎng)度為 2 ^ 16 = 65535 字節(jié)。

校驗(yàn)和(Checksum)：UDP 使用校驗(yàn)和來保證數(shù)據(jù)安全性，UDP 的校驗(yàn)和也提供了差錯(cuò)檢測(cè)功能，差錯(cuò)檢測(cè)用于校驗(yàn)報(bào)文段從源到目標(biāo)主機(jī)的過程中，數(shù)據(jù)的完整性是否發(fā)生了改變。

TCP 報(bào)文段結(jié)構(gòu)

TCP 報(bào)文段結(jié)構(gòu)相比 UDP 報(bào)文結(jié)構(gòu)多了很多內(nèi)容。但是前兩個(gè) 32 比特的字段是一樣的。它們是 源端口號(hào) 和 目標(biāo)端口號(hào)。另外，和 UDP 一樣，TCP 也包含校驗(yàn)和(checksum field) ，除此之外，TCP 報(bào)文段首部還有下面這些

32 比特的序號(hào)字段(sequence number field) 和 32 比特的確認(rèn)號(hào)字段(acknowledgment number field) 。這些字段被 TCP 發(fā)送方和接收方用來實(shí)現(xiàn)可靠的數(shù)據(jù)傳輸。

4 比特的首部字段長(zhǎng)度字段(header length field)，這個(gè)字段指示了以 32 比特的字為單位的 TCP 首部長(zhǎng)度。TCP 首部的長(zhǎng)度是可變的，但是通常情況下，選項(xiàng)字段為空，所以 TCP 首部字段的長(zhǎng)度是 20 字節(jié)。

16 比特的 接受窗口字段(receive window field) ，這個(gè)字段用于流量控制。它用于指示接收方能夠/愿意接受的字節(jié)數(shù)量

可變的選項(xiàng)字段(options field)，這個(gè)字段用于發(fā)送方和接收方協(xié)商最大報(bào)文長(zhǎng)度，也就是 MSS 時(shí)使用

6 比特的 標(biāo)志字段(flag field)， ACK 標(biāo)志用于指示確認(rèn)字段中的值是有效的，這個(gè)報(bào)文段包括一個(gè)對(duì)已被成功接收?qǐng)?bào)文段的確認(rèn)；RST、SYN、FIN 標(biāo)志用于連接的建立和關(guān)閉；CWR 和 ECE 用于擁塞控制；PSH 標(biāo)志用于表示立刻將數(shù)據(jù)交給上層處理；URG 標(biāo)志用來表示數(shù)據(jù)中存在需要被上層處理的 緊急 數(shù)據(jù)。緊急數(shù)據(jù)最后一個(gè)字節(jié)由 16 比特的緊急數(shù)據(jù)指針字段(urgeent data pointer field) 指出。一般情況下，PSH 和 URG 并沒有使用。

所以從報(bào)文段結(jié)構(gòu)的對(duì)比可以看出，TCP 相比 UDP 多了許多 Flags、序號(hào)和確認(rèn)號(hào)，這些都屬于 TCP 的連接控制。除此之外還有接收窗口，這些屬于擁塞控制和流量控制的內(nèi)容。TCP 的首部開銷要比 UDP 大，因?yàn)?TCP 首部固定有 20 字節(jié)，UDP 首部固定才 8 字節(jié)。TCP 和 UDP 都提供了數(shù)據(jù)校驗(yàn)功能。

效率的差異

TCP 報(bào)文段的發(fā)送采用的是"一問一答"形式的，每個(gè)請(qǐng)求都會(huì)被目標(biāo)主機(jī)確認(rèn)后再發(fā)送下一條報(bào)文，效率很慢，后來為了解決這個(gè)問題，TCP 引入了 窗口 這個(gè)概念，即使在往返時(shí)間較長(zhǎng)、頻次很多的情況下，它也能控制網(wǎng)絡(luò)性能的下降。

我們之前每次請(qǐng)求發(fā)送都是以報(bào)文段的形式進(jìn)行的，引入窗口后，每次請(qǐng)求都可以發(fā)送多個(gè)報(bào)文段，也就是說一個(gè)窗口可以發(fā)送多個(gè)報(bào)文段。窗口大小就是指無需等待確認(rèn)應(yīng)答就可以繼續(xù)發(fā)送報(bào)文段的最大值。

在這個(gè)窗口機(jī)制中，大量使用了 緩沖區(qū) ，通過對(duì)多個(gè)段同時(shí)進(jìn)行確認(rèn)應(yīng)答的功能。

如下圖所示，發(fā)送報(bào)文段中高亮部分即是我們提到的窗口，在窗口內(nèi)，即使沒有收到確認(rèn)應(yīng)答也可以把請(qǐng)求發(fā)送出去。不過，在整個(gè)窗口的確認(rèn)應(yīng)答沒有到達(dá)之前，如果部分報(bào)文段丟失，那么發(fā)送方將仍會(huì)重傳。為此，發(fā)送方需要設(shè)置緩存來保留這些需要重傳的報(bào)文段，直到收到他們的確認(rèn)應(yīng)答。

在滑動(dòng)窗口以外的部分是尚未發(fā)送的報(bào)文段和已經(jīng)接收到的報(bào)文段，如果報(bào)文段已經(jīng)收到確認(rèn)則不可進(jìn)行重發(fā)，此時(shí)報(bào)文段就可以從緩沖區(qū)中清除。

在收到確認(rèn)的情況下，會(huì)將窗口滑動(dòng)到確認(rèn)應(yīng)答中確認(rèn)號(hào)的位置，如上圖所示，這樣可以順序?qū)⒍鄠€(gè)段同時(shí)發(fā)送，用以提高通信性能，這種窗口也叫做 滑動(dòng)窗口(Sliding window)。

UDP 發(fā)送的報(bào)文段不需要確認(rèn)，也就沒有窗口的概念，所以 UDP 傳輸效率比較高。

使用場(chǎng)景的差異

TCP 和 UDP 在效率、報(bào)文段、流量控制、連接管理上均存在差異，由于這些差異導(dǎo)致了應(yīng)用場(chǎng)景要有不同的選擇，由于 TCP 每個(gè)包都需要進(jìn)行確認(rèn)，因此 TCP 不適合告訴傳輸數(shù)據(jù)的場(chǎng)景，像是這種場(chǎng)景使用 UDP 就好了；像是 Ping 和 DNS Lookup，這類型的操作只需要一次簡(jiǎn)單的請(qǐng)求/返回，不需要建立連接，用 UDP 就足夠了。比如 HTTP 協(xié)議需要考慮請(qǐng)求響應(yīng)的可靠性，這種場(chǎng)景應(yīng)該使用 TCP 協(xié)議，但是像 HTTP 3.0 這類應(yīng)用層協(xié)議，從功能性上思考，暫時(shí)沒有找到太多的優(yōu)化點(diǎn)，但是想要把網(wǎng)絡(luò)優(yōu)化到極致，就會(huì)用 UDP 作為底層技術(shù)，然后在 UDP 基礎(chǔ)上解決可靠性。

編輯：黃飛

?