什么是三次握手與四次揮手一篇文章講清楚TCP協(xié)議與UDP協(xié)議

關(guān)于TCP協(xié)議和UDP協(xié)議大家應(yīng)該都有所耳聞，我們常用的網(wǎng)絡(luò)通訊。比如瀏覽網(wǎng)頁、軟件聊天、以及你看到的這篇文章，都是通過這兩種協(xié)議來進(jìn)行數(shù)據(jù)傳輸?shù)摹?/span>到底他們是如何工作的？這兩種協(xié)議的區(qū)別又是什么呢？請(qǐng)隨小編一起耐心看完這篇文章，你一定會(huì)有所收獲。

TCP和UCP協(xié)議都工作在傳輸層，他們的目標(biāo)都是在程序之間傳輸數(shù)據(jù)。數(shù)據(jù)可以是文本文件、視頻、圖片。對(duì)于TCP和UCP協(xié)議來說，都是一堆二進(jìn)制數(shù)，并沒有多大的區(qū)別。那TCP與UCP之間的區(qū)別是什么？很多伙伴會(huì)說，最大的區(qū)別就是一個(gè)基于連接，一個(gè)基于非連接。具體又是什么意思呢？我們來舉一個(gè)簡(jiǎn)單的例子。

如果把人與人的通信比喻為進(jìn)程與進(jìn)程的通信，我們基本有兩個(gè)方式，第一種方式是寫信，第二種方式是打電話，如果不考慮速度因素，這兩種方式最大的區(qū)別是什么？

就是信寄出去之后對(duì)方是否能收到，以及收到信的內(nèi)容是否完整。先后寄兩封信過去是否按照順序接收，都變成了未知數(shù)。甚至你填寫的收信地址和收件人是否存在，你都無法確認(rèn)。

而打電話則不同，從撥打電話到對(duì)方接通互相通話，再到結(jié)束通話后掛斷，能得到及時(shí)的反饋，并且能確認(rèn)對(duì)方準(zhǔn)確的接收到。打電話是基于連接的也就是TCP，而寫信就是基于非連接的就是UDP。（如下圖）

TCP是如何保證以上過程的，有三個(gè)關(guān)鍵的步驟。分別為三次握手、傳輸確認(rèn)、四次揮手。

三次握手是建立連接的過程，當(dāng)客戶端向服務(wù)端發(fā)起連接時(shí)，會(huì)無發(fā)一包連接請(qǐng)求數(shù)據(jù)，過去詢問一下，能否與你建立連接。這包數(shù)據(jù)我們稱為SYN。如果對(duì)端同意連接，則回復(fù)一包SYN+ACK包。客戶端收到之后回復(fù)一包ACK包，連接建立。因?yàn)檫@個(gè)過程中互相發(fā)送了三包數(shù)據(jù)，所以稱之為三次握手。

為什么要三次握手而不是兩次握手呢？

服務(wù)端回復(fù)完SYN+ACK之后就建立連接，這是為了防止因?yàn)橐咽У恼?qǐng)求報(bào)文，突然又傳到服務(wù)器引起錯(cuò)誤。這是什么意思呢？假設(shè)采用兩次握手建立連接，客戶端向服務(wù)端發(fā)送了一個(gè)SYN包來請(qǐng)求建立連接，因?yàn)槟承┪粗脑虿]有到達(dá)服務(wù)器，在中間某些網(wǎng)絡(luò)節(jié)點(diǎn)產(chǎn)生了滯留。為了建立連接客戶端會(huì)重發(fā)SYN包，這次的數(shù)據(jù)包正常送達(dá)。服務(wù)端回復(fù)SYN+ACK之后建立起了連接，但是第一包數(shù)據(jù)阻塞的網(wǎng)絡(luò)節(jié)點(diǎn)突然恢復(fù)，第一包SNY包又送達(dá)到服務(wù)端。這時(shí)服務(wù)端會(huì)誤認(rèn)為是客戶端又發(fā)起了新的連接。從而在兩次握手之后，進(jìn)入等待數(shù)據(jù)狀態(tài)。服務(wù)端認(rèn)為是兩個(gè)連接，而客戶端認(rèn)為是一個(gè)連接，造成了狀態(tài)不一致。如果是三次握手的情況下，服務(wù)端收不到最后的ACK自然不會(huì)認(rèn)為連接建立成功，所以三次握手本質(zhì)上來說就是為了解決網(wǎng)絡(luò)信道不可靠的問題。

為了能夠在不可靠的信道上建立起可靠的連接，經(jīng)過三次握手后，客戶端和服務(wù)端都進(jìn)入了數(shù)據(jù)傳輸狀態(tài)。上面講到TCP協(xié)議需要在不可靠的信道上，保證可靠的連接。

現(xiàn)在就有幾個(gè)問題需要面對(duì)，一包數(shù)據(jù)有可能會(huì)被拆成多包發(fā)送，如何處理丟包問題？這些數(shù)據(jù)包到達(dá)的先后順序不同，如何處理亂序問題？

針對(duì)這些要求，TCP協(xié)議為每一個(gè)連接建立了一個(gè)發(fā)送緩沖區(qū)，從建立連接后的第一個(gè)字節(jié)的序列號(hào)為0，后面每個(gè)字節(jié)的序列號(hào)就會(huì)增加1。發(fā)送數(shù)據(jù)時(shí)，從發(fā)送緩沖區(qū)取一部分?jǐn)?shù)據(jù)組成發(fā)送報(bào)文，在其TCP協(xié)議頭中會(huì)附帶序列號(hào)和長度。接受端在收到數(shù)據(jù)后，需要回復(fù)確認(rèn)報(bào)文，確認(rèn)報(bào)文中的ACK等于接收序列號(hào)加長度。也就是下一包數(shù)據(jù)需要發(fā)送的開始序列號(hào)，這樣一問一答的發(fā)送方式能夠使發(fā)送端確認(rèn)發(fā)送的數(shù)據(jù)已經(jīng)被對(duì)方收到。發(fā)送端也可以一次發(fā)送連續(xù)的多包數(shù)據(jù)，接收到只需要回復(fù)一次ACK就可以了。這樣發(fā)送端可以把待發(fā)送的數(shù)據(jù)分割成一系列的碎片發(fā)送到對(duì)端，對(duì)端根據(jù)序列號(hào)和長度在接收后得出完整的數(shù)據(jù)。假設(shè)其中丟失了某些數(shù)據(jù)包。在接收端可以要求發(fā)送端重傳。比如丟失了100-199這100個(gè)字節(jié)，接收端向發(fā)送端發(fā)送ACK=100的報(bào)文，發(fā)送端收到后重傳這一包數(shù)據(jù)。接收端進(jìn)行補(bǔ)齊。以上過程不區(qū)分客戶端和服務(wù)端。TCP連接是全雙工的。對(duì)于兩端來說均采用上述機(jī)制。

4.mp4

我們?cè)倏匆幌率裁词撬拇螕]手？

處于連接狀態(tài)的客戶端和服務(wù)端，都可以發(fā)起關(guān)閉連接請(qǐng)求。此時(shí)需要四次揮手來進(jìn)行連接關(guān)閉。

假設(shè)客戶端主動(dòng)發(fā)起連接關(guān)閉請(qǐng)求，他需要向服務(wù)端發(fā)起一個(gè)包FIN包，表示要關(guān)閉連接，自己進(jìn)入終止等待1狀態(tài)，這是第一次揮手。服務(wù)端收到FIN包，發(fā)送一包ACK包，表示自己進(jìn)入了關(guān)閉等待狀態(tài)?？蛻舳诉M(jìn)入終止等待2狀態(tài)，這是第二次揮手。服務(wù)端此時(shí)還可以發(fā)送未發(fā)送的數(shù)據(jù)，而客戶端還可以接收數(shù)據(jù)，待服務(wù)端發(fā)送完數(shù)據(jù)之后，發(fā)送一包FIN包進(jìn)入最后確認(rèn)狀態(tài)，這是第三次揮手。客戶端收到之后回復(fù)ACK包，進(jìn)入超時(shí)等待狀態(tài)，經(jīng)過超時(shí)時(shí)間后關(guān)閉連接，而服務(wù)端收到ACK包后，立即關(guān)閉連接，這是第四次揮手。為什么客戶端需要等待超時(shí)時(shí)間？這是為了保證對(duì)方已收到ACK包，因?yàn)榧僭O(shè)客戶端發(fā)送完最后一包ACK包后就釋放了連接。一旦ACK包在網(wǎng)絡(luò)中丟失，服務(wù)端將一直停留在最后確認(rèn)狀態(tài)。如果客戶端發(fā)送最后一包ACK包后，等待一段時(shí)間，這時(shí)服務(wù)端因?yàn)闆]有收到ACK包會(huì)重發(fā)FIN包，客戶端會(huì)響應(yīng)這個(gè)FIN包重發(fā)ACK包并刷新超時(shí)時(shí)間。

以上機(jī)制和三次握手一樣，也是為了保證在不可靠的網(wǎng)絡(luò)鏈路中，進(jìn)行可靠的連接斷開、確認(rèn)。

了解了TCP協(xié)議，我們?cè)倏匆幌耈DP協(xié)議。

首先UDP協(xié)議是基于非連接的，發(fā)送數(shù)據(jù)就是簡(jiǎn)單的把數(shù)據(jù)包封裝一下，然后從網(wǎng)卡發(fā)出去就可以了，數(shù)據(jù)包之間并沒有狀態(tài)上的聯(lián)系。正因?yàn)閁DP這種簡(jiǎn)單的處理方式，導(dǎo)致他的性能損耗非常少，對(duì)于CPU內(nèi)存資源的占用也過小于TCP。但是對(duì)于網(wǎng)絡(luò)傳輸過程中產(chǎn)生的丟包UDP協(xié)議并不能保證，所以UDP在傳輸穩(wěn)定性上要弱于TCP。