TCP四次揮手不同情況的研究

建議有些網路基礎的人查看此檔案，當然了新手仔細看也能看懂，大佬直接跳過新手加油站

1.新手加油站

1.1 TCP四次握手流程圖

首先我們知道傳輸層TCP協議為了確保可靠連接，會有連接時的三次握手和斷開連接時的四次揮手的機制

我們這里不討論掉三次握手，來看一下正常四次揮手的流程（如下圖所示）

注意：實際上client和server端都可以先發出斷開連接請求，只不過下圖演示的是客戶端先發起關閉請求

1.2 TCP頭部

新手可能看到上面那個圖一臉蒙圈，那么我來說明一下，看完說明再理解能更加明了一些（大佬直接跳過），

首先圖的左右兩次代表了客戶端和服務端，兩方都可以先發起請求，不過演示的圖片是客戶端先發起的，
左邊和右邊表示各種狀態（像終止等待，關閉等待），下邊會列舉，
中間的FIN，ACK，和seq和ack需要了解TCP的頭部和資料部分（詳解如下）

首先我們發送TCP請求的時候，不光有資料，還有一些TCP協議每次發送都固定必須有的資料，這些資料存在TCP首部中，我們這里不用全知道，只做簡單了解，
seq就是頭部中的序號------可以簡單理解成，假設有1萬個資料，太大我們不能一次發送，所以seq可以理解成我這次發送是從這1w個里面的第幾個開始的
ack就是對方想要的資料--------假設我們這次發送的是從500開始的，那么seq也就是500，并且假設發送了10個資料，那么對方接收到第509個資料（從500開始，發10個，500也算這次發的，所以最后是509），那么對方現在會告訴你我接到你剛才的資料了，我希望你下次發從第510個資料開始，這時ack為510
大寫的FIN和ACK是上圖頭部中的6個標志位（上圖的那六個字母）中的兩個，它們只能為0,1，當FIN為1的時候代表這個包對方是想要跟你斷開連接的包，通知你一聲，而ACK代表抓個包是對方對你剛才發個它的包的回復，

1.3 四次握手流程詳解

好了，簡單知道了上述內容就可以看我們四次握手的流程了，分為以下四步

雙方都是建立連接狀態，客戶端想要跟服務器斷開連接，于是發了個包，這個包的兩個標志為FIN和ACK為1，FIN為1表示想要關閉連接，而ACK為1代表是回復它上個包（因為之前他們肯定進行過資料互動，所以服務器肯定有包發送給客戶端，就算沒資料包發送，三次握手的時候也是有包的），同樣的因為之前有過互動所以這里seq和ack的值不確定，所以用u和v來表示
服務器告訴對方接收到了，但是此時還沒斷開連接，雙方仍然可以傳遞資料，
等到服務器這時候該傳的資料傳完了，同樣的告訴客戶端我也可以跟你關閉連接了，
客戶端回復收到了

狀態：

? 上方是流程的一個詳解，我們這里主要討論狀態，因為這跟后邊四次握手的不同情況有關系，

FIN-WAIT-1：表示想主動關閉連接，向對方發送FIN報文后會進入到FIN-WAIT-1狀態，
CLOSE-WAIT：表示在等待關閉，當對方發送FIN給自己，自己會回應一個ACK報文，此時進入CLOSE——WAIT狀態，在此狀態下，是需要考慮自己還有沒有資料要發給對方，如果沒有就發送FIN報文給對方，
**FIN-WAIT-2：**接收到了對方的ACK確認后就會進入該狀態，并等待對方發送FIN報文，

? 如果接收到了對方同時帶FIN，和ACK的報文，就可以直接進入到了TIME-WAIT狀態，而無需經過FIN-WAIT-2狀態
**LAST-ACK：**被動關閉方發送FIN報文后，等待對方的ACK報文，當收到對方的ack報文后進入到close狀態，
TIME-WAIT：表示主動方收到了對方的FIN報文，并發送了ACK報文，在等待2MSL后即可進入到CLOSED狀態了，

? MSL：（Maximum Segment Lifetime，最大分段生存期），是TCP報文在internet上的最長存活時間，每個TCP實作都需要一個具體的MSL，RFC 1122建議是2分鐘，所以2MSL就是4分鐘，
**CLOSED：**關閉狀態

注意：

? 這里解釋的狀態只是正常的揮手中出現的，還有別的狀態下方會討論到，

2.針對揮手不同情況的實驗和研究

? 以上只是通常情況，四次握手會根據實際的不同，發生不同的變化，下面用Wireshark抓包分析一下，

2.1 正常情況

? 框起來的是四次揮手，至于上邊那三個，有基礎的應該知道那是三次握手，可以看到步驟和我們的之前描述的四次揮手的流程一模一樣，

客戶端想要和服務器斷開連接，標志位：FIN，ACK置為1，這里seq是1，ack是1.
服務器回復客戶端接收到了你的請求所以標志位ACK為1，因為上個請求對方ack為1，證明想要我從第一個資料開始發，所以這次我的seq必為1，而對方上次seq是1所以這次我希望它從第2個資料開始發了，所以這次的ack為2.
服務器感覺事情都忙完了，發給客戶端可以斷開連接，FIN，ACK置為1，seq和ack都和第二步一樣，因為這次他們的值還是根據第一步來的，所以值和第二步是一樣一樣的，
客戶端回復服務器接收到了，因為上個服務器發來的包ack為2，所以這次我的seq為2，因為上次服務器的seq為1，所以這次我希望它從第2個資料開始發，所以ack為2，

2.2 三次揮手情況

注意：

? 這里我寫的三次揮手情況，它只是在表面上看來是三次揮手，實際上的步驟沒有改變，只不過把第二次和第三次合并了，下方是我用WireShark抓包的截圖，其中中間標紅的忽略掉只看綠色部分，

我們會發現，正常的三次揮手到這里怎么變成了四次了，第二次揮手怎么沒了？

? 實際上它還是存在的，就像我上方所說，這種情況是將第二次和第三次合并了，也就是說當客戶端發送了關閉連接的請求的時候，服務器因為之前跟你建立連接并且已經把你之前想要的資料傳給你了，然后沒事了一直等你訊息，你一直沒動靜，早就等的不耐煩了，這時它收到了你的關閉連接請求，好家伙，爺早就不想干了，它快速反應過來我這邊資料已經處理完了，于是在回復你訊息收到了的同時也告訴你它也想跟你關閉連接，

2.3 CLOSING狀態

參考：

注意：

? 這里重頭戲來了，我們之前看了正常TCP斷開連接的四次揮手程序，

? 當然還有看上去是經歷三次揮手，實際上跟正常的四次揮手程序類似，不過是將第2,3次合并了，具體流程其實還是可以算是一樣的，

特殊情況：

? 那么還有一種情況，就是假如在相同的時間，比如12點整，這個時候客戶端和服務器都想和對方斷開連接，同時發給對方一個FIN包，那么兩邊會出現什么情況？

客戶端肯定是發了一個FIN包，這時沒有接到對面的ACK包，而是接到了對面的FIN包，
服務器端也是一樣的，發了一個FIN包，等對面的ACK包，不過ACK包沒等到，直接等到了個對方發過來的FIN包，

這時會出現一個新狀態→CLOSING：

? 一種罕見的狀態，雙方同時都想和對方斷開連接，也就是當你發送FIN報文后，沒有收到對方的ACK報文反而也收到了對方的FIN報文，那么雙方都會進入到CLOSING狀態，等待對方的ack報文，如果等待到了對方的ack報文，就直接關閉，

抓包分析：

? 這里因為要構造TCP連接，所以用了packetdrill，只能在Linux系統中使用，所以人生苦短我用Kali

注意：

? 腳本不難，但是注意抓包的時候抓的網卡一定要對，我這里抓的是any，我也不知道any是什么，但是看它的線路跟eth0幾乎一樣，在根據英文，盲猜就是任何網卡的包都抓的意思

腳本：

0.000 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
0.000 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
0.000 bind(3, ..., ...) = 0
0.000 listen(3, 1) = 0

0.100 < S 0:0(0) win 32792 <mss 1460,sackOK,nop,nop,nop,wscale 7>
0.100 > S. 0:0(0) ack 1<...>
0.200 < . 1:1(0) ack 1 win 257
0.200 accept(3, ..., ...) = 4

// 象征性寫入一些資料，裝的像一點一個正常的TCP連接：握手-傳輸-揮手
0.250 write(4, ..., 3000) = 3000

0.300 < . 1:1(0) ack 3001 win 257

// 主動斷開，發送FIN
0.400 close(4) = 0
// 在未對上述close的FIN進行ACK前，先FIN
0.500 < F. 1:1(0) ack 3001 win 260
// 至此，成功進入同時關閉的CLOSING狀態，


// 由于packetdrill不能用dup呼叫，也好用多執行緒，為了維持行程不退出，只能等待
10000.000 close(4) = 0

結果如圖所示：

? kali里面自帶wireshark，抓包結果如下，可以看見出現了兩個FIN，ACK

這里詳解一下下面幾個問題：

假設43515埠是客戶端，8080埠是服務器

超時重傳問題

? 正常當同時出現FIN的時候，雙方等待對方的ack并且如果接收到ACK就進入TIME-WAIT狀態，等過了時間就關閉了，如果沒接收到對方的ACK，就會重傳FIN包，圖中明顯是一方沒接收到ACK包，一直在重傳，這個不用深究，看了大佬的文章總結出來應該是作業系統內核的BUG，了解一下就好

三次揮手和CLOSING狀態的區分

? 之前我們講過三次揮手狀態是將第二次揮手，和第三次揮手合并了，那么這兩種情況好像啊，怎么區分呢？其實很簡單，三次揮手雖然簡化了但是步驟沒省略所有的seq和ack都是正常的，

? 而CLOSING狀態，看好兩個FIN包，正常第一個FIN包服務器發送seq 1001給客戶端，客戶端期望的下次資料是什么？是不是應該是1002，而我們圖中第二個FIN包是多少，是不是1001很明顯它不是接收到服務器的FIN包后才發回來的，而還停留在上個服務器發的包呢，
seq和ack對應不上問題

? 看懂了上面區分問題，這個問題就簡單了，客戶端發的FIN包，ack是1001，但是服務器給的ACK包的seq確實1002這是為什么？，因為雙方都知道，奧，我們的FIN包同時發的，那么按照正常揮手情況你的ACK應該是1002啊，不過現在咱倆沖突了，那他很聰明，就直接按照正常情況給你發了seq為1002的包