一、TCP connection

客戶端與服務(wù)器之間數(shù)據(jù)的發(fā)送和返回的過程當中需要創(chuàng)建一個叫TCP connection的東西;

由于TCP不存在連接的概念，只存在請求和響應(yīng)，請求和響應(yīng)都是數(shù)據(jù)包，它們之間都是經(jīng)過由TCP創(chuàng)建的一個從客戶端發(fā)起，服務(wù)器接收的類似連接的通道，這個連接可以一直保持，http請求是在這個連接的基礎(chǔ)上發(fā)送的;

在一個TCP連接上是可以發(fā)送多個http請求的，不同的版本這個模式不一樣。

在HTTP/1.0中這個TCP連接是在http請求創(chuàng)建的時候同步創(chuàng)建的，http請求發(fā)送到服務(wù)器端，服務(wù)器端響應(yīng)了之后，這個TCP連接就關(guān)閉了;

HTTP/1.1中可以以某種方式聲明這個連接一直保持，一個請求傳輸完之后，另一個請求可以接著傳輸。這樣的好處是：在創(chuàng)建一個TCP連接的過程中需要“三次握手”的消耗，“三次握手”代表有三次網(wǎng)絡(luò)傳輸。

如果TCP連接保持，第二個請求發(fā)送就沒有這“三次握手”的消耗。HTTP/2中同一個TCP連接里還可以并發(fā)地傳輸http請求。

二、TCP報文格式簡介

其中比較重要的字段有：

(1)序號(sequence number)：Seq序號，占32位，用來標識從TCP源端向目的端發(fā)送的字節(jié)流，發(fā)起方發(fā)送數(shù)據(jù)時對此進行標記。

(2)確認號(acknowledgement number)：Ack序號，占32位，只有ACK標志位為1時，確認序號字段才有效，Ack=Seq+1。

(3)標志位(Flags)：共6個，即URG、ACK、PSH、RST、SYN、FIN等，具體含義如下：

• URG：緊急指針(urgent pointer)有效。
• ACK：確認序號有效。
• PSH：接收方應(yīng)該盡快將這個報文交給應(yīng)用層。
• RST：重置連接。
• SYN：發(fā)起一個新連接。
• FIN：釋放一個連接。

需要注意的是：

• 不要將確認序號Ack與標志位中的ACK搞混了。
• 確認方Ack=發(fā)起方Seq+1，兩端配對。

三、TCP的三次握手(Three-Way Handshake)1.”三次握手”的詳解

所謂的三次握手即TCP連接的建立。這個連接必須是一方主動打開，另一方被動打開的。

以下為客戶端主動發(fā)起連接的圖解：

握手之前主動打開連接的客戶端結(jié)束CLOSED階段，被動打開的服務(wù)器端也結(jié)束CLOSED階段，并進入LISTEN階段。隨后開始“三次握手”：

(1)首先客戶端向服務(wù)器端發(fā)送一段TCP報文，其中：

• 標記位為SYN，表示“請求建立新連接”;
• 序號為Seq=X(X一般為1);
• 隨后客戶端進入SYN-SENT階段。

(2)服務(wù)器端接收到來自客戶端的TCP報文之后，結(jié)束LISTEN階段。并返回一段TCP報文，其中：

• 標志位為SYN和ACK，表示“確認客戶端的報文Seq序號有效，服務(wù)器能正常接收客戶端發(fā)送的數(shù)據(jù)，并同意創(chuàng)建新連接”(即告訴客戶端，服務(wù)器收到了你的數(shù)據(jù));
• 序號為Seq=y;
• 確認號為Ack=x+1，表示收到客戶端的序號Seq并將其值加1作為自己確認號Ack的值;隨后服務(wù)器端進入SYN-RCVD階段。

(3)客戶端接收到來自服務(wù)器端的確認收到數(shù)據(jù)的TCP報文之后，明確了從客戶端到服務(wù)器的數(shù)據(jù)傳輸是正常的，結(jié)束SYN-SENT階段。并返回最后一段TCP報文。其中：

• 標志位為ACK，表示“確認收到服務(wù)器端同意連接的信號”(即告訴服務(wù)器，我知道你收到我發(fā)的數(shù)據(jù)了);
• 序號為Seq=x+1，表示收到服務(wù)器端的確認號Ack，并將其值作為自己的序號值;
• 確認號為Ack=y+1，表示收到服務(wù)器端序號Seq，并將其值加1作為自己的確認號Ack的值;
• 隨后客戶端進入ESTABLISHED階段。
• 服務(wù)器收到來自客戶端的“確認收到服務(wù)器數(shù)據(jù)”的TCP報文之后，明確了從服務(wù)器到客戶端的數(shù)據(jù)傳輸是正常的。結(jié)束SYN-SENT階段，進入ESTABLISHED階段。
• 在客戶端與服務(wù)器端傳輸?shù)腡CP報文中，雙方的確認號Ack和序號Seq的值，都是在彼此Ack和Seq值的基礎(chǔ)上進行計算的，這樣做保證了TCP報文傳輸?shù)倪B貫性。一旦出現(xiàn)某一方發(fā)出的TCP報文丟失，便無法繼續(xù)"握手"，以此確保了"三次握手"的順利完成。
• 此后客戶端和服務(wù)器端進行正常的數(shù)據(jù)傳輸。

這就是“三次握手”的過程。

2. “三次握手”的動態(tài)過程

3. “三次握手”的通俗理解

舉個栗子：把客戶端比作男孩，服務(wù)器比作女孩。用他們的交往來說明“三次握手”過程：

(1)男孩喜歡女孩，于是寫了一封信告訴女孩：我愛你，請和我交往吧!;寫完信之后，男孩焦急地等待，因為不知道信能否順利傳達給女孩。

(2)女孩收到男孩的情書后，心花怒放，原來我們是兩情相悅呀!于是給男孩寫了一封回信：我收到你的情書了，也明白了你的心意，其實，我也喜歡你!我愿意和你交往!;

寫完信之后，女孩也焦急地等待，因為不知道回信能否能順利傳達給男孩。

(3)男孩收到回信之后很開心，因為發(fā)出的情書女孩收到了，并且從回信中知道了女孩喜歡自己，并且愿意和自己交往。然后男孩又寫了一封信告訴女孩：你的心意和信我都收到了，謝謝你，還有我愛你!

女孩收到男孩的回信之后，也很開心，因為發(fā)出的情書男孩收到了。由此男孩女孩雙方都知道了彼此的心意，之后就快樂地交流起來了~~

這就是通俗版的“三次握手”，期間一共往來了三封信也就是“三次握手”，以此確認兩個方向上的數(shù)據(jù)傳輸通道是否正常。

4. 為什么要進行第三次握手?

為了防止服務(wù)器端開啟一些無用的連接增加服務(wù)器開銷以及防止已失效的連接請求報文段突然又傳送到了服務(wù)端，因而產(chǎn)生錯誤。

由于網(wǎng)絡(luò)傳輸是有延時的(要通過網(wǎng)絡(luò)光纖和各種中間代理服務(wù)器)，在傳輸?shù)倪^程中，比如客戶端發(fā)起了SYN=1創(chuàng)建連接的請求(第一次握手)。

如果服務(wù)器端就直接創(chuàng)建了這個連接并返回包含SYN、ACK和Seq等內(nèi)容的數(shù)據(jù)包給客戶端，這個數(shù)據(jù)包因為網(wǎng)絡(luò)傳輸?shù)脑騺G失了，丟失之后客戶端就一直沒有接收到服務(wù)器返回的數(shù)據(jù)包。

客戶端可能設(shè)置了一個超時時間，時間到了就關(guān)閉了連接創(chuàng)建的請求。再重新發(fā)出創(chuàng)建連接的請求，而服務(wù)器端是不知道的，如果沒有第三次握手告訴服務(wù)器端客戶端收的到服務(wù)器端傳輸?shù)臄?shù)據(jù)的話，

服務(wù)器端是不知道客戶端有沒有接收到服務(wù)器端返回的信息的。

這個過程可理解為：

這樣沒有給服務(wù)器端一個創(chuàng)建還是關(guān)閉連接端口的請求，服務(wù)器端的端口就一直開著，等到客戶端因超時重新發(fā)出請求時，服務(wù)器就會重新開啟一個端口連接。那么服務(wù)器端上沒有接收到請求數(shù)據(jù)的上一個端口就一直開著，長此以往，這樣的端口多了，就會造成服務(wù)器端開銷的嚴重浪費。

還有一種情況是已經(jīng)失效的客戶端發(fā)出的請求信息，由于某種原因傳輸?shù)搅朔?wù)器端，服務(wù)器端以為是客戶端發(fā)出的有效請求，接收后產(chǎn)生錯誤。

所以我們需要“第三次握手”來確認這個過程，讓客戶端和服務(wù)器端能夠及時地察覺到因為網(wǎng)絡(luò)等一些問題導(dǎo)致的連接創(chuàng)建失敗，這樣服務(wù)器端的端口就可以關(guān)閉了不用一直等待。

也可以這樣理解：“第三次握手”是客戶端向服務(wù)器端發(fā)送數(shù)據(jù)，這個數(shù)據(jù)就是要告訴服務(wù)器，客戶端有沒有收到服務(wù)器“第二次握手”時傳過去的數(shù)據(jù)。若發(fā)送的這個數(shù)據(jù)是“收到了”的信息，接收后服務(wù)器就正常建立TCP連接，否則建立TCP連接失敗，服務(wù)器關(guān)閉連接端口。由此減少服務(wù)器開銷和接收到失效請求發(fā)生的錯誤。

5. 抓包驗證

下面是用抓包工具抓到的一些數(shù)據(jù)包，可用來分析TCP的三次握手：

圖中顯示的就是完整的TCP連接的”三次握手”過程。在52528 -> 80中，52528是本地(客戶端)端口，80是服務(wù)器的端口。80端口和52528端口之間的三次來回就是"三次握手"過程。

• 注意到”第一次握手”客戶端發(fā)送的TCP報文中以[SYN]作為標志位，并且客戶端序號Seq=0;
• 接下來”第二次握手”服務(wù)器返回的TCP報文中以[SYN，ACK]作為標志位;并且服務(wù)器端序號Seq=0;確認號Ack=1(“第一次握手”中客戶端序號Seq的值+1);
• 最后”第三次握手”客戶端再向服務(wù)器端發(fā)送的TCP報文中以[ACK]作為標志位;其中客戶端序號Seq=1(“第二次握手”中服務(wù)器端確認號Ack的值);確認號Ack=1(“第二次握手”中服務(wù)器端序號Seq的值+1)。

這就完成了”三次握手”的過程，符合前面分析的結(jié)果。

四、TCP的四次揮手(Four-Way Wavehand)

1. 前言

對于"三次握手"我們耳熟能詳，因為其相對的簡單。但是，我們卻不常聽見“四次揮手”，就算聽過也未必能詳細地說明白它的具體過程。

下面就為大家詳盡，直觀，完整地介紹“四次揮手”的過程。

2. “四次揮手”的詳解

所謂的四次揮手即TCP連接的釋放(解除)。連接的釋放必須是一方主動釋放，另一方被動釋放。以下為客戶端主動發(fā)起釋放連接的圖解：

揮手之前主動釋放連接的客戶端結(jié)束ESTABLISHED階段。隨后開始“四次揮手”：

(1)首先客戶端想要釋放連接，向服務(wù)器端發(fā)送一段TCP報文，其中：

• 標記位為FIN，表示“請求釋放連接“;
• 序號為Seq=U;
• 隨后客戶端進入FIN-WAIT-1階段，即半關(guān)閉階段。并且停止在客戶端到服務(wù)器端方向上發(fā)送數(shù)據(jù)，但是客戶端仍然能接收從服務(wù)器端傳輸過來的數(shù)據(jù)。

注意：這里不發(fā)送的是正常連接時傳輸?shù)臄?shù)據(jù)(非確認報文)，而不是一切數(shù)據(jù)，所以客戶端仍然能發(fā)送ACK確認報文。

(2)服務(wù)器端接收到從客戶端發(fā)出的TCP報文之后，確認了客戶端想要釋放連接，隨后服務(wù)器端結(jié)束ESTABLISHED階段，進入CLOSE-WAIT階段(半關(guān)閉狀態(tài))并返回一段TCP報文，其中：

• 標記位為ACK，表示“接收到客戶端發(fā)送的釋放連接的請求”;
• 序號為Seq=V;
• 確認號為Ack=U+1，表示是在收到客戶端報文的基礎(chǔ)上，將其序號Seq值加1作為本段報文確認號Ack的值;
• 隨后服務(wù)器端開始準備釋放服務(wù)器端到客戶端方向上的連接。

客戶端收到從服務(wù)器端發(fā)出的TCP報文之后，確認了服務(wù)器收到了客戶端發(fā)出的釋放連接請求，隨后客戶端結(jié)束FIN-WAIT-1階段，進入FIN-WAIT-2階段

前"兩次揮手"既讓服務(wù)器端知道了客戶端想要釋放連接，也讓客戶端知道了服務(wù)器端了解了自己想要釋放連接的請求。于是，可以確認關(guān)閉客戶端到服務(wù)器端方向上的連接了

(3)服務(wù)器端自從發(fā)出ACK確認報文之后，經(jīng)過CLOSED-WAIT階段，做好了釋放服務(wù)器端到客戶端方向上的連接準備，再次向客戶端發(fā)出一段TCP報文，其中：

• 標記位為FIN，ACK，表示“已經(jīng)準備好釋放連接了”。注意：這里的ACK并不是確認收到服務(wù)器端報文的確認報文。
• 序號為Seq=W;
• 確認號為Ack=U+1;表示是在收到客戶端報文的基礎(chǔ)上，將其序號Seq值加1作為本段報文確認號Ack的值。

隨后服務(wù)器端結(jié)束CLOSE-WAIT階段，進入LAST-ACK階段。并且停止在服務(wù)器端到客戶端的方向上發(fā)送數(shù)據(jù)，但是服務(wù)器端仍然能夠接收從客戶端傳輸過來的數(shù)據(jù)。

(4)客戶端收到從服務(wù)器端發(fā)出的TCP報文，確認了服務(wù)器端已做好釋放連接的準備，結(jié)束FIN-WAIT-2階段，進入TIME-WAIT階段，并向服務(wù)器端發(fā)送一段報文，其中：

• 標記位為ACK，表示“接收到服務(wù)器準備好釋放連接的信號”。
• 序號為Seq=U+1;表示是在收到了服務(wù)器端報文的基礎(chǔ)上，將其確認號Ack值作為本段報文序號的值。
• 確認號為Ack=W+1;表示是在收到了服務(wù)器端報文的基礎(chǔ)上，將其序號Seq值作為本段報文確認號的值。
• 隨后客戶端開始在TIME-WAIT階段等待2MSL

為什么要客戶端要等待2MSL呢?見后文。

服務(wù)器端收到從客戶端發(fā)出的TCP報文之后結(jié)束LAST-ACK階段，進入CLOSED階段。由此正式確認關(guān)閉服務(wù)器端到客戶端方向上的連接。

客戶端等待完2MSL之后，結(jié)束TIME-WAIT階段，進入CLOSED階段，由此完成“四次揮手”。

后“兩次揮手”既讓客戶端知道了服務(wù)器端準備好釋放連接了，也讓服務(wù)器端知道了客戶端了解了自己準備好釋放連接了。于是，可以確認關(guān)閉服務(wù)器端到客戶端方向上的連接了，由此完成“四次揮手”。

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

3. “四次揮手”的通俗理解

舉個栗子：把客戶端比作男孩，服務(wù)器比作女孩。通過他們的分手來說明“四次揮手”過程。

• "第一次揮手"：日久見人心，男孩發(fā)現(xiàn)女孩變成了自己討厭的樣子，忍無可忍，于是決定分手，隨即寫了一封信告訴女孩。
• “第二次揮手”：女孩收到信之后，知道了男孩要和自己分手，怒火中燒，心中暗罵：你算什么東西，當初你可不是這個樣子的!于是立馬給男孩寫了一封回信：分手就分手，給我點時間，我要把你的東西整理好，全部還給你!男孩收到女孩的第一封信之后，明白了女孩知道自己要和她分手。隨后等待女孩把自己的東西收拾好。
• “第三次揮手”：過了幾天，女孩把男孩送的東西都整理好了，于是再次寫信給男孩：你的東西我整理好了，快把它們拿走，從此你我恩斷義絕!
• “第四次揮手”：男孩收到女孩第二封信之后，知道了女孩收拾好東西了，可以正式分手了，于是再次寫信告訴女孩：我知道了，這就去拿回來!

這里雙方都有各自的堅持。

• 女孩自發(fā)出第二封信開始，限定一天內(nèi)收不到男孩回信，就會再發(fā)一封信催促男孩來取東西!
• 男孩自發(fā)出第二封信開始，限定兩天內(nèi)沒有再次收到女孩的信就認為，女孩收到了自己的第二封信;若兩天內(nèi)再次收到女孩的來信，就認為自己的第二封信女孩沒收到，需要再寫一封信，再等兩天…..

倘若雙方信都能正常收到，最少只用四封信就能徹底分手!這就是“四次揮手”。

4. 為什么“握手”是三次，“揮手”卻要四次?

TCP建立連接時之所以只需要"三次握手"，是因為在第二次"握手"過程中，服務(wù)器端發(fā)送給客戶端的TCP報文是以SYN與ACK作為標志位的。SYN是請求連接標志，表示服務(wù)器端同意建立連接;ACK是確認報文，表示告訴客戶端，服務(wù)器端收到了它的請求報文。

即SYN建立連接報文與ACK確認接收報文是在同一次"握手"當中傳輸?shù)?，所?quot;三次握手"不多也不少，正好讓雙方明確彼此信息互通。

TCP釋放連接時之所以需要“四次揮手”,是因為FIN釋放連接報文與ACK確認接收報文是分別由第二次和第三次"握手"傳輸?shù)摹楹谓⑦B接時一起傳輸，釋放連接時卻要分開傳輸?

• 建立連接時，被動方服務(wù)器端結(jié)束CLOSED階段進入“握手”階段并不需要任何準備，可以直接返回SYN和ACK報文，開始建立連接。
• 釋放連接時，被動方服務(wù)器，突然收到主動方客戶端釋放連接的請求時并不能立即釋放連接，因為還有必要的數(shù)據(jù)需要處理，所以服務(wù)器先返回ACK確認收到報文，經(jīng)過CLOSE-WAIT階段準備好釋放連接之后，才能返回FIN釋放連接報文。

所以是“三次握手”，“四次揮手”。

5. 為什么客戶端在TIME-WAIT階段要等2MSL?

為的是確認服務(wù)器端是否收到客戶端發(fā)出的ACK確認報文

當客戶端發(fā)出最后的ACK確認報文時，并不能確定服務(wù)器端能夠收到該段報文。所以客戶端在發(fā)送完ACK確認報文之后，會設(shè)置一個時長為2MSL的計時器。MSL指的是Maximum Segment Lifetime：一段TCP報文在傳輸過程中的最大生命周期。2MSL即是服務(wù)器端發(fā)出為FIN報文和客戶端發(fā)出的ACK確認報文所能保持有效的最大時長。

服務(wù)器端在1MSL內(nèi)沒有收到客戶端發(fā)出的ACK確認報文，就會再次向客戶端發(fā)出FIN報文;

• 如果客戶端在2MSL內(nèi)，再次收到了來自服務(wù)器端的FIN報文，說明服務(wù)器端由于各種原因沒有接收到客戶端發(fā)出的ACK確認報文?？蛻舳嗽俅蜗蚍?wù)器端發(fā)出ACK確認報文，計時器重置，重新開始2MSL的計時;
• 否則客戶端在2MSL內(nèi)沒有再次收到來自服務(wù)器端的FIN報文，說明服務(wù)器端正常接收了ACK確認報文，客戶端可以進入CLOSED階段，完成“四次揮手”。

所以，客戶端要經(jīng)歷時長為2SML的TIME-WAIT階段;這也是為什么客戶端比服務(wù)器端晚進入CLOSED階段的原因

6. 抓包驗證

圖中顯示的就是完整的TCP連接釋放的”四次揮手”過程。在 80 -> 55389 中，假設(shè)80是本地(客戶端)端口，55389是服務(wù)器端口。80端口與55389之間的四次來回就是"四次揮手"過程。

• ”第一次揮手”客戶端發(fā)送的FIN請求釋放連接報文以[FIN，ACK]作為標志位，其中報文序號Seq=2445;確認號Ack=558;

注意：這里與“第三次握手”的ACK并不是表示確認的ACK報文。

• ”第二次揮手”服務(wù)器端返回的ACK確認報文以[ACK]作為標志位;其中報文序號Seq=558;確認號Ack=2246;
• ”第三次揮手”服務(wù)器端繼續(xù)返回的FIN同意釋放連接報文以[FIN，ACK]作為標志位;其中報文序號Seq=558;確認號Ack=2246;
• ”第四次揮手”客戶端發(fā)出的ACK確認接收報文以[ACK]作為標志位;其中報文序號Seq=2446;確認號Ack=559;

后一次“揮手”傳輸報文中的序號Seq值等于前一次"握手"傳輸報文中的確認號Ack值;

后一次“揮手”傳輸報文中的確認號Ack值等于前一次"握手"傳輸報文中的序號Seq值;

故這是連續(xù)的“四次揮手”過程，與前面的分析相符。