前言

面試中我們經(jīng)常會被問到TCP協(xié)議的三次握手和四次揮手的過程，為什么總喜歡問這個問題呢？

其實我們平時使用的很多協(xié)議都是應用層協(xié)議，比如HTTP協(xié)議，https協(xié)議，DNS協(xié)議，F(xiàn)TP協(xié)議等；而應用層協(xié)議都是要基于傳輸層的兩個協(xié)議之上的，也就是TCP協(xié)議和UDP協(xié)議。我們在使用應用層協(xié)議遇到一些問題需要去分析定位的時候，會需要涉及到底層協(xié)議的連接問題上。所以，作為測試掌握這兩個底層協(xié)議的工作原理是非常有必要的！

UDP協(xié)議作為一個不可靠的傳輸層協(xié)議，工作過程相對比較簡單！所以我們就重點來大家講一下TCP協(xié)議。

Wireshark抓包分析TCP協(xié)議 為了更好的學習和理解TCP協(xié)議的連接和斷開連接的過程，我們來引入一個非常適合用來學習網(wǎng)絡協(xié)議的抓包工具Wireshark。這個抓包工具可以詳細看到每一層網(wǎng)絡報文的詳細信息。

TCP協(xié)議的三次握手過程 TCP建立連接需要經(jīng)歷三次握手，具體過程如下：

那么，這個過程我們配合抓包工具來看看具體的案例；如下圖是訪問某個HTTP請求用wireshark抓到的報文，前面的三個報文就是TCP的三次握手過程：SYN包，SYN ACK包，ACK報文。

展開看詳情：

第一次握手的報文如下：這是客戶端發(fā)起給服務器的報文，用于請求建立連接。

可以看到TCP報文里有一個Flags位：

當Syn位標記為1的時候，表示這個報文是一個請求鏈接的報文；

自己的序號（sequence number）：0

第二次握手的報文如下：這是服務器回復給客戶端的報文，用于確認并同意連接請求。

可以看到TCP報文里的Flags位：

Syn位也標記為1，表示這個報文是一個同意建立鏈接的報文；

ACK位也標記為1，表示是一個對上一個報文的確認報文；

Sequence number：自己的序號；

acknowledgment number：表示對上一個請求報文的確認號，所以是在上一個報文的序號+1

第三次握手：是客戶端發(fā)給服務器的，是對上一個同意連接請求的確認。

Flags里的ACK位標記為1，表示是一個對上一個報文的確認報文；

Sequence number：自己的序號，在上一個報文的基礎上+1；

acknowledgment number：表示對上一個請求報文的確認號，在上一個報文序號的基礎上+1.

至此，三次握手完成！接下來就開始發(fā)送HTTP的請求了。

TCP協(xié)議的四次揮手過程

當數(shù)據(jù)傳輸結束了，客戶端和服務器之間就開始斷開連接了。斷開連接需要經(jīng)歷四次揮手，具體過程如下：

同樣，我們用wireshark工具來進行詳細過程的報文的分析：

我們同樣展開看下詳細的報文內(nèi)容：

第一次揮手：當數(shù)據(jù)傳輸首先結束的端（比如客戶端），會率先發(fā)起結束斷開連接的請求：

Flags位的 Fin位標記為1，說明這是個一個斷開連接的請求的報文。

這時候我們發(fā)送這個請求的端已經(jīng)停止發(fā)送數(shù)據(jù)了！但是還可以接受數(shù)據(jù)。

第二次揮手：對上一個斷開連接請求的報文進行確認。并同時，停止接受數(shù)據(jù)。

所以，我們能看到這個報文的ACK位標記為1，并且acknowledgment number是對上一個報文的序號+1，表示對上一個報文的確認。

第三次揮手：服務器端也結束數(shù)據(jù)發(fā)送了，所以也會發(fā)起一個斷開連接的請求。

這是個服務器發(fā)起FIN報文，請求斷開連接，同時，服務器也會停止發(fā)送數(shù)據(jù)。

第四次揮手：是客戶端對服務器斷開連接請求的進行確認。

所以這個flags位是ACK位標記為1。此時，客戶端也停止接受數(shù)據(jù)了。

至此，服務器和客戶端都停止發(fā)送和接受數(shù)據(jù)了！四次揮手就完成了。