TCP協(xié)議和UDP協(xié)議最核心的區(qū)別是什么？

對(duì)于TCP協(xié)議和UDP協(xié)議，大家應(yīng)該都有所耳聞。TCP協(xié)議和UDP協(xié)議都工作在傳輸層，他們的目標(biāo)都是在應(yīng)用之間傳輸數(shù)據(jù)。我們常用的網(wǎng)絡(luò)通信，比如瀏覽網(wǎng)頁(yè)，查看郵件，電話(huà)通信等，都是通過(guò)這兩種協(xié)議來(lái)進(jìn)行數(shù)據(jù)傳輸?shù)摹?/p>

? 01 TCP與UDP的區(qū)別

這兩種協(xié)議有什么區(qū)別呢？他們又是如何工作的？跟著文檔君往下看~

TCP協(xié)議和UDP協(xié)議最核心的區(qū)別是什么？看看下邊圖片你就知道了。

TCP（Transmission Control Protocol，傳輸控制協(xié)議）是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議?？煽啃裕荰CP的最大特點(diǎn)，主要體現(xiàn)在：數(shù)據(jù)無(wú)丟失、無(wú)錯(cuò)誤、無(wú)失序、無(wú)重復(fù)到達(dá)。就如同上圖，TCP能將“孩子”（數(shù)據(jù)包）十分安全地傳送給接收者。

UDP（User Datagram Protocol，用戶(hù)數(shù)據(jù)報(bào)協(xié)議）是一種無(wú)連接、不可靠、快速傳輸?shù)膫鬏攲油ㄐ艆f(xié)議?？焖賯鬏?，是UDP的最大特點(diǎn)，主要體現(xiàn)在：數(shù)據(jù)發(fā)送前，不需要提前建立連接，能更高效地傳輸數(shù)據(jù)，但可靠性無(wú)法保證。就如同上圖，UDP只負(fù)責(zé)把“孩子”（數(shù)據(jù)包）送出去，不管接收者有無(wú)收到。

直觀感受了TCP協(xié)議與UDP協(xié)議的區(qū)別后，咱們來(lái)看看TCP協(xié)議是如何工作的？

? 02 TCP是如何工作的？

TCP通信的連接管理機(jī)制(可靠機(jī)制)總結(jié)為：三次握手建立連接，四次揮手?jǐn)嚅_(kāi)連接。

< 三次握手建立連接 >

TCP 是面向連接的協(xié)議，所以每次發(fā)出的請(qǐng)求都需要對(duì)方進(jìn)行確認(rèn)。TCP 客戶(hù)端與 TCP 服務(wù)器在通信之前需要完成三次握手才能建立連接。

?

第一次握手

目的：這是一個(gè)請(qǐng)求建立連接的數(shù)據(jù)包，客戶(hù)端先向服務(wù)器發(fā)送一個(gè)同步數(shù)據(jù)包。

數(shù)據(jù)包的TCP首部?jī)?nèi)容：

同步SYN=1（客戶(hù)端請(qǐng)求建立連接）

序號(hào)seq=x（客戶(hù)端所傳送數(shù)據(jù)的第一個(gè)字節(jié)的序號(hào)）

第二次握手

目的：服務(wù)器收到客戶(hù)端發(fā)送的第一個(gè)數(shù)據(jù)包后，判斷出為主動(dòng)建立連接的數(shù)據(jù)包。若服務(wù)器同意連接，則服務(wù)器發(fā)送一個(gè)數(shù)據(jù)包進(jìn)行回應(yīng)。

數(shù)據(jù)包的TCP首部?jī)?nèi)容：

同步SYN=1（服務(wù)器建立連接）

確認(rèn)標(biāo)記ACK=1（服務(wù)器同意連接）

序號(hào)seq=y（服務(wù)器所傳送數(shù)據(jù)的第一個(gè)字節(jié)的序號(hào)）

確認(rèn)號(hào)ack=x+1（已經(jīng)收到客戶(hù)端發(fā)送的x個(gè)字節(jié)數(shù)據(jù)，并告訴客戶(hù)端下次應(yīng)從數(shù)據(jù)的第x+1個(gè)字節(jié)開(kāi)始發(fā)送）

第三次握手

目的：客戶(hù)端收到服務(wù)器的確認(rèn)之后，再給服務(wù)器發(fā)送一個(gè)數(shù)據(jù)包。

數(shù)據(jù)包的TCP首部?jī)?nèi)容：

同步SYN=1（雙方已同意建立連接）

確認(rèn)標(biāo)記ACK=1（收到服務(wù)器的確認(rèn)數(shù)據(jù)包）

序號(hào)seq=x+1（發(fā)出的數(shù)據(jù)包就是數(shù)據(jù)的第x+1個(gè)字節(jié)）

確認(rèn)號(hào)ack=y+1（收到服務(wù)器發(fā)送y字節(jié)數(shù)據(jù)，并告訴服務(wù)器下次應(yīng)從數(shù)據(jù)的第y+1個(gè)字節(jié)開(kāi)始發(fā)送）

? Tips

在客戶(hù)端與服務(wù)器端傳輸?shù)腡CP數(shù)據(jù)中，雙方的序號(hào)seq和確認(rèn)號(hào)ack的值，都是在彼此seq和ack值的基礎(chǔ)上進(jìn)行計(jì)算的，這樣做保證了TCP數(shù)據(jù)傳輸?shù)倪B貫性。一旦出現(xiàn)某一方發(fā)出的TCP數(shù)據(jù)丟失，便無(wú)法繼續(xù)"握手"，以此確保了"三次握手"的順利完成。

< 四次揮手?jǐn)嚅_(kāi)連接 >

聚散終有時(shí)，當(dāng)數(shù)據(jù)傳輸完成后，TCP客戶(hù)端與TCP服務(wù)器需要通過(guò)四次會(huì)話(huà)斷開(kāi)連接，這個(gè)過(guò)程我們稱(chēng)之為四次揮手。

第一次揮手

目的：客戶(hù)端向服務(wù)器發(fā)送連接釋放的請(qǐng)求數(shù)據(jù)包，并停止發(fā)送數(shù)據(jù)。

在連接釋放數(shù)據(jù)包的TCP首部中：

終止FIN=1（客戶(hù)端要主動(dòng)釋放客戶(hù)端和服務(wù)器的TCP連接）

序號(hào)seq=x（x由客戶(hù)端指定。隨后等待服務(wù)器的確認(rèn)）

第二次揮手

目的：服務(wù)器在收到連接釋放的報(bào)文之后，給客戶(hù)端發(fā)送確認(rèn)報(bào)文。因此，客戶(hù)端到服務(wù)器方向上的連接釋放，TCP連接此時(shí)處于半關(guān)閉狀態(tài)。半閉因?yàn)榭蛻?hù)端已無(wú)法發(fā)送數(shù)據(jù)給服務(wù)器，半開(kāi)因?yàn)榉?wù)器仍可以發(fā)送數(shù)據(jù)給客戶(hù)端并被其接收。

在服務(wù)器發(fā)送給客戶(hù)端確認(rèn)報(bào)文的TCP首部中：

確認(rèn)標(biāo)記ACK=1（收到了客戶(hù)端發(fā)送的數(shù)據(jù)包，同意客戶(hù)端釋放連接）

確認(rèn)號(hào)ack=x+1（在收到客戶(hù)端報(bào)文的基礎(chǔ)上，將其序號(hào)seq值加1作為本段報(bào)文確認(rèn)號(hào)ack的值）

序號(hào)seq=y（y由服務(wù)器指定。隨后等待客戶(hù)端的確認(rèn)）

第三次揮手

目的：若服務(wù)器已停止向客戶(hù)端發(fā)送的數(shù)據(jù)，則釋放連接，并向客戶(hù)端發(fā)送確認(rèn)報(bào)文。

在確認(rèn)報(bào)文的TCP首部中：

終止FIN=1（服務(wù)器釋放服務(wù)器到客戶(hù)端的TCP連接，不再向客戶(hù)端發(fā)送數(shù)據(jù)）

確認(rèn)標(biāo)記ACK=1（服務(wù)器對(duì)客戶(hù)端的數(shù)據(jù)傳送完畢）

確認(rèn)號(hào)ack=x+1（在收到客戶(hù)端報(bào)文的基礎(chǔ)上，將其序號(hào)seq值加1作為本段報(bào)文確認(rèn)號(hào)ack的值）

序號(hào)seq=z（z由服務(wù)器指定。隨后等待客戶(hù)端的確認(rèn)）

第四次揮手

目的：客戶(hù)端收到服務(wù)器的連接釋放報(bào)文段后，向服務(wù)器發(fā)出確認(rèn)報(bào)文。

在確認(rèn)報(bào)文的TCP首部中：

終止FIN = 1（客戶(hù)端和服務(wù)器斷開(kāi)連接）

確認(rèn)標(biāo)記ACK=1（收到服務(wù)器的確認(rèn)報(bào)文，并同意服務(wù)器釋放連接）

確認(rèn)號(hào)ack=z+1（在收到服務(wù)端報(bào)文的基礎(chǔ)上，將其序號(hào)seq值加1作為本段報(bào)文確認(rèn)號(hào)ack的值）

序列號(hào)seq=x+1（在收到服務(wù)端報(bào)文的基礎(chǔ)上，將其確認(rèn)號(hào)作為本段報(bào)文序列號(hào)的值）

了解完TCP后，再來(lái)了解一下UDP是如何工作的~

? 03 UDP是如何工作的？

UDP協(xié)議是面向無(wú)連接的，即發(fā)送數(shù)據(jù)之前不需要建立連接（無(wú)TCP協(xié)議復(fù)雜的三次握手，四次揮手的過(guò)程），發(fā)送數(shù)據(jù)就是簡(jiǎn)單的把數(shù)據(jù)包封裝一下，然后從網(wǎng)卡發(fā)出去，數(shù)據(jù)包之間并沒(méi)有狀態(tài)上的聯(lián)系。UDP 協(xié)議基本上是 IP 協(xié)議與上層協(xié)議的接口，UDP協(xié)議使用IP層提供的服務(wù)將應(yīng)用層得到的數(shù)據(jù)從一臺(tái)主機(jī)的某個(gè)應(yīng)用進(jìn)程傳遞到另一臺(tái)主機(jī)的某個(gè)應(yīng)用進(jìn)程。

舉個(gè)栗子~

當(dāng)傳輸層從IP層收到UDP數(shù)據(jù)報(bào)文時(shí)，根據(jù)UDP數(shù)據(jù)報(bào)文首部中的目的端口，把UDP數(shù)據(jù)報(bào)文通過(guò)相應(yīng)的端口傳遞給應(yīng)用進(jìn)程，如下圖所示。

?

如上圖中應(yīng)用進(jìn)程4與端口2，如果接收方UDP發(fā)現(xiàn)收到的報(bào)文中的目的端口號(hào)不正確(即不存在對(duì)應(yīng)于端口號(hào)的應(yīng)用進(jìn)程)，則丟棄該報(bào)文，并由ICMP發(fā)送“端口不可達(dá)"差錯(cuò)報(bào)文給發(fā)送方。

? Tips

ICMP（Internet Control Message Protocol，Internet控制報(bào)文協(xié)議）是TCP/IP協(xié)議簇的一個(gè)子協(xié)議，用于在IP主機(jī)、路由器之間傳遞控制消息。控制消息是指網(wǎng)絡(luò)通不通、主機(jī)是否可達(dá)、路由是否可用等網(wǎng)絡(luò)本身的消息。

? 04 總結(jié)一下

數(shù)據(jù)傳輸看似簡(jiǎn)單，其實(shí)非常智慧~

TCP和UDP服務(wù)的是程序，但程序和人是一樣的，可以你來(lái)我往進(jìn)行交流，也可以一股腦的傾訴。TCP就是彼此之間坦誠(chéng)交流。消息有沒(méi)有收到，收到的信息是否一致，都可以有及時(shí)的反饋。

優(yōu)點(diǎn)：可靠。

缺點(diǎn)：傳輸速率慢。

適用場(chǎng)景：通信軟件的賬戶(hù)登錄、支付等相關(guān)功能，采用可靠的TCP。

UDP就是傾訴，我不管你有沒(méi)有聽(tīng)進(jìn)去，不管你有無(wú)反饋，我就要不停地說(shuō)。

優(yōu)點(diǎn)：傳輸速率快。

缺點(diǎn)：不可靠。

適用場(chǎng)景：QQ、微信等即時(shí)通信軟件進(jìn)行點(diǎn)對(duì)點(diǎn)通信，或者音視頻通話(huà)時(shí)，通常采用傳輸快速的UDP。

TCP和UDP各有優(yōu)缺點(diǎn)，就看你實(shí)際需求啦~

?

?

審核編輯：劉清