靈魂拷問:TCP&UDP徹底搞懂了嗎?
01 TCP與UDP的區(qū)別
TCP(Transmission Control Protocol,傳輸控制協(xié)議)是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議??煽啃?,是TCP的最大特點,主要體現(xiàn)在:數(shù)據(jù)無丟失、無錯誤、無失序、無重復(fù)到達(dá)。就如同上圖,TCP能將“孩子”(數(shù)據(jù)包)十分安全地傳送給接收者。
UDP(User Datagram Protocol,用戶數(shù)據(jù)報協(xié)議)是一種無連接、不可靠、快速傳輸?shù)膫鬏攲油ㄐ艆f(xié)議??焖賯鬏?,是UDP的最大特點,主要體現(xiàn)在:數(shù)據(jù)發(fā)送前,不需要提前建立連接,能更高效地傳輸數(shù)據(jù),但可靠性無法保證。就如同上圖,UDP只負(fù)責(zé)把“孩子”(數(shù)據(jù)包)送出去,不管接收者有無收到。
直觀感受了TCP協(xié)議與UDP協(xié)議的區(qū)別后,咱們再來看看TCP協(xié)議是如何工作的~
02 TCP是如何工作的?
< 三次握手建立連接 >
第一次握手
目的:這是一個請求建立連接的數(shù)據(jù)包,客戶端先向服務(wù)器發(fā)送一個同步數(shù)據(jù)包。
數(shù)據(jù)包的TCP首部內(nèi)容:
同步SYN=1(客戶端請求建立連接)
序號seq=x(客戶端所傳送數(shù)據(jù)的第一個字節(jié)的序號)
第二次握手
目的:服務(wù)器收到客戶端發(fā)送的第一個數(shù)據(jù)包后,判斷出為主動建立連接的數(shù)據(jù)包。若服務(wù)器同意連接,則服務(wù)器發(fā)送一個數(shù)據(jù)包進(jìn)行回應(yīng)。
數(shù)據(jù)包的TCP首部內(nèi)容:
同步SYN=1(服務(wù)器建立連接)
確認(rèn)標(biāo)記ACK=1(服務(wù)器同意連接)
序號seq=y(服務(wù)器所傳送數(shù)據(jù)的第一個字節(jié)的序號)
確認(rèn)號ack=x+1(已經(jīng)收到客戶端發(fā)送的x個字節(jié)數(shù)據(jù),并告訴客戶端下次應(yīng)從數(shù)據(jù)的第x+1個字節(jié)開始發(fā)送)
第三次握手
目的:客戶端收到服務(wù)器的確認(rèn)之后,再給服務(wù)器發(fā)送一個數(shù)據(jù)包。
數(shù)據(jù)包的TCP首部內(nèi)容:
同步SYN=1(雙方已同意建立連接)
確認(rèn)標(biāo)記ACK=1(收到服務(wù)器的確認(rèn)數(shù)據(jù)包)
序號seq=x+1(發(fā)出的數(shù)據(jù)包就是數(shù)據(jù)的第x+1個字節(jié))
確認(rèn)號ack=y+1(收到服務(wù)器發(fā)送y字節(jié)數(shù)據(jù),并告訴服務(wù)器下次應(yīng)從數(shù)據(jù)的第y+1個字節(jié)開始發(fā)送)
Tips
在客戶端與服務(wù)器端傳輸?shù)腡CP數(shù)據(jù)中,雙方的序號seq和確認(rèn)號ack的值,都是在彼此seq和ack值的基礎(chǔ)上進(jìn)行計算的,這樣做保證了TCP數(shù)據(jù)傳輸?shù)倪B貫性。一旦出現(xiàn)某一方發(fā)出的TCP數(shù)據(jù)丟失,便無法繼續(xù)"握手",以此確保了"三次握手"的順利完成。
< 四次揮手?jǐn)嚅_連接 >
第一次揮手
目的:客戶端向服務(wù)器發(fā)送連接釋放的請求數(shù)據(jù)包,并停止發(fā)送數(shù)據(jù)。
在連接釋放數(shù)據(jù)包的TCP首部中:
終止FIN=1(客戶端要主動釋放客戶端和服務(wù)器的TCP連接)
序號seq=x(x由客戶端指定。隨后等待服務(wù)器的確認(rèn))
第二次揮手
目的:服務(wù)器在收到連接釋放的報文之后,給客戶端發(fā)送確認(rèn)報文。因此,客戶端到服務(wù)器方向上的連接釋放,TCP連接此時處于半關(guān)閉狀態(tài)。半閉因為客戶端已無法發(fā)送數(shù)據(jù)給服務(wù)器,半開因為服務(wù)器仍可以發(fā)送數(shù)據(jù)給客戶端并被其接收。
在服務(wù)器發(fā)送給客戶端確認(rèn)報文的TCP首部中:
確認(rèn)標(biāo)記ACK=1(收到了客戶端發(fā)送的數(shù)據(jù)包,同意客戶端釋放連接)
確認(rèn)號ack=x+1(在收到客戶端報文的基礎(chǔ)上,將其序號seq值加1作為本段報文確認(rèn)號ack的值)
序號seq=y(y由服務(wù)器指定。隨后等待客戶端的確認(rèn))
第三次揮手
目的:若服務(wù)器已停止向客戶端發(fā)送的數(shù)據(jù),則釋放連接,并向客戶端發(fā)送確認(rèn)報文。
在確認(rèn)報文的TCP首部中:
終止FIN=1(服務(wù)器釋放服務(wù)器到客戶端的TCP連接,不再向客戶端發(fā)送數(shù)據(jù))
確認(rèn)標(biāo)記ACK=1(服務(wù)器對客戶端的數(shù)據(jù)傳送完畢)
確認(rèn)號ack=x+1(在收到客戶端報文的基礎(chǔ)上,將其序號seq值加1作為本段報文確認(rèn)號ack的值)
序號seq=z(z由服務(wù)器指定。隨后等待客戶端的確認(rèn))
第四次揮手
目的:客戶端收到服務(wù)器的連接釋放報文段后,向服務(wù)器發(fā)出確認(rèn)報文。
在確認(rèn)報文的TCP首部中:
終止FIN = 1(客戶端和服務(wù)器斷開連接)
確認(rèn)標(biāo)記ACK=1(收到服務(wù)器的確認(rèn)報文,并同意服務(wù)器釋放連接)
確認(rèn)號ack=z+1(在收到服務(wù)端報文的基礎(chǔ)上,將其序號seq值加1作為本段報文確認(rèn)號ack的值)
序列號seq=x+1(在收到服務(wù)端報文的基礎(chǔ)上,將其確認(rèn)號作為本段報文序列號的值)
了解完TCP后,我們再來了解一下UDP是如何工作的~
03 UDP是如何工作的?
舉個例子,當(dāng)傳輸層從IP層收到UDP數(shù)據(jù)報文時,根據(jù)UDP數(shù)據(jù)報文首部中的目的端口,把UDP數(shù)據(jù)報文通過相應(yīng)的端口傳遞給應(yīng)用進(jìn)程,如下圖所示。
如上圖中應(yīng)用進(jìn)程4與端口2,如果接收方UDP發(fā)現(xiàn)收到的報文中的目的端口號不正確(即不存在對應(yīng)于端口號的應(yīng)用進(jìn)程),則丟棄該報文,并由ICMP發(fā)送“端口不可達(dá)”差錯報文給發(fā)送方。
Tips
ICMP(Internet Control Message Protocol,Internet控制報文協(xié)議)是TCP/IP協(xié)議簇的一個子協(xié)議,用于在IP主機、路由器之間傳遞控制消息??刂葡⑹侵妇W(wǎng)絡(luò)通不通、主機是否可達(dá)、路由是否可用等網(wǎng)絡(luò)本身的消息。
04 總結(jié)一下
TCP和UDP服務(wù)的是程序,但程序和人是一樣的,可以你來我往進(jìn)行交流,也可以一股腦的傾訴。TCP就是彼此之間坦誠交流,消息有沒有收到,收到的信息是否一致,都可以有及時的反饋。
優(yōu)點:可靠。
缺點:傳輸速率慢。
適用場景:通信軟件的賬戶登錄、支付等相關(guān)功能,采用可靠的TCP。
UDP就是傾訴,我不管你有沒有聽進(jìn)去,不管你有無反饋,我就要不停地說。
優(yōu)點:傳輸速率快。
缺點:不可靠。
適用場景:QQ、微信等即時通信軟件進(jìn)行點對點通信,或者音視頻通話時,通常采用傳輸快速的UDP。
- 上一篇:警惕!別讓這些小細(xì)節(jié)毀了整個PCB 2023/8/10
- 下一篇:2023.7.25 經(jīng)驗分享會 2023/7/25