原文地址：https://blog.csdn.net/libaineu2004/article/details/79020403

TCP(Transmission Control Protocol)　傳輸控制協議

三次握手

TCP是主機對主機層的傳輸控制協議，提供可靠的連線服務，採用三次握手確認建立一個連線:

位碼即tcp標誌位,有6種標示:SYN(synchronous建立聯機) ACK(acknowledgement 確認) PSH(push傳送) FIN(finish結束) RST(reset重置) URG(urgent緊急)

Sequence number(順序號碼) Acknowledge number(確認號碼)

第一次握手：主機A傳送位碼為syn＝1,隨機產生seq number=1234567的資料包到伺服器，主機B由SYN=1知道，A要求建立聯機；

第二次握手：主機B收到請求後要確認聯機資訊，向A傳送ack number=(主機A的seq+1),syn=1,ack=1,隨機產生seq=7654321的包

第三次握手：主機A收到後檢查ack number是否正確，即第一次傳送的seq number+1,以及位碼ack是否為1，若正確，主機A會再發送ack number=(主機B的seq+1),ack=1，主機B收到後確認seq值與ack=1則連線建立成功。

完成三次握手，主機A與主機B開始傳送資料。

在TCP/IP協議中，TCP協議提供可靠的連線服務，採用三次握手建立一個連線。 
第一次握手：建立連線時，客戶端傳送syn包(syn=j)到伺服器，並進入SYN_SEND狀態，等待伺服器確認； 
第二次握手：伺服器收到syn包，必須確認客戶的SYN（ack=j+1），同時自己也傳送一個SYN包（syn=k），即SYN+ACK包，此時伺服器進入SYN_RECV狀態； 第三次握手：客戶端收到伺服器的SYN＋ACK包，向伺服器傳送確認包ACK(ack=k+1)，此包傳送完畢，客戶端和伺服器進入ESTABLISHED狀態，完成三次握手。 完成三次握手，客戶端與伺服器開始傳送資料.

例項:

IP 192.168.1.116.3337 > 192.168.1.123.7788: S 3626544836:3626544836
IP 192.168.1.123.7788 > 192.168.1.116.3337: S 1739326486:1739326486 ack 3626544837
IP 192.168.1.116.3337 > 192.168.1.123.7788: ack 1739326487,ack 1

第一次握手：192.168.1.116傳送位碼syn＝1,隨機產生seq number=3626544836的資料包到192.168.1.123,192.168.1.123由SYN=1知道192.168.1.116要求建立聯機;

第二次握手：192.168.1.123收到請求後要確認聯機資訊，向192.168.1.116傳送ack number=3626544837,syn=1,ack=1,隨機產生seq=1739326486的包;

第三次握手：192.168.1.116收到後檢查ack number是否正確，即第一次傳送的seq number+1,以及位碼ack是否為1，若正確，192.168.1.116會再發送ack number=1739326487,ack=1，192.168.1.123收到後確認seq=seq+1,ack=1則連線建立成功。

 

圖解：
一個三次握手的過程（圖1，圖2）

 

（圖1）

（圖2）
 

 

第一次握手的標誌位（圖3）
我們可以看到標誌位裡面只有個同步位，也就是在做請求(SYN)
 
 （圖3）

第二次握手的標誌位（圖4）
我們可以看到標誌位裡面有個確認位和同步位，也就是在做應答(SYN + ACK)
 
（圖4）

第三次握手的標誌位（圖5）
我們可以看到標誌位裡面只有個確認位，也就是再做再次確認(ACK)
 
 
（圖5）

一個完整的三次握手也就是 請求---應答---再次確認

四次分手：

 

由於TCP連線是全雙工的，因此每個方向都必須單獨進行關閉。這個原則是當一方完成它的資料傳送任務後就能傳送一個FIN來終止這個方向的連線。收到一個 FIN只意味著這一方向上沒有資料流動，一個TCP連線在收到一個FIN後仍能傳送資料。首先進行關閉的一方將執行主動關閉，而另一方執行被動關閉。

 

（1）客戶端A傳送一個FIN，用來關閉客戶A到伺服器B的資料傳送（報文段4）。

（2）伺服器B收到這個FIN，它發回一個ACK，確認序號為收到的序號加1（報文段5）。和SYN一樣，一個FIN將佔用一個序號。

（3）伺服器B關閉與客戶端A的連線，傳送一個FIN給客戶端A（報文段6）。

（4）客戶端A發回ACK報文確認，並將確認序號設定為收到序號加1（報文段7）。

 

       狀態詳解:

 

        CLOSED： 這個沒什麼好說的了，表示初始狀態。

 

　　LISTEN： 這個也是非常容易理解的一個狀態，表示伺服器端的某個SOCKET處於監聽狀態，可以接受連線了。

 

　　SYN_RCVD： 這個狀態表示接受到了SYN報文，在正常情況下，這個狀態是伺服器端的SOCKET在建立TCP連線時的三次握手會話過程中的一箇中間狀態，很短暫，基本 上用netstat你是很難看到這種狀態的，除非你特意寫了一個客戶端測試程式，故意將三次TCP握手過程中最後一個ACK報文不予傳送。因此這種狀態 時，當收到客戶端的ACK報文後，它會進入到ESTABLISHED狀態。

 

　　SYN_SENT： 這個狀態與SYN_RCVD遙想呼應，當客戶端SOCKET執行CONNECT連線時，它首先發送SYN報文，因此也隨即它會進入到了SYN_SENT狀態，並等待服務端的傳送三次握手中的第2個報文。SYN_SENT狀態表示客戶端已傳送SYN報文。

 

　　ESTABLISHED：這個容易理解了，表示連線已經建立了。

 

　　FIN_WAIT_1： 這個狀態要好好解釋一下，其實FIN_WAIT_1和FIN_WAIT_2狀態的真正含義都是表示等待對方的FIN報文。而這兩種狀態的區別 是：FIN_WAIT_1狀態實際上是當SOCKET在ESTABLISHED狀態時，它想主動關閉連線，向對方傳送了FIN報文，此時該SOCKET即 進入到FIN_WAIT_1狀態。而當對方迴應ACK報文後，則進入到FIN_WAIT_2狀態，當然在實際的正常情況下，無論對方何種情況下，都應該馬 上回應ACK報文，所以FIN_WAIT_1狀態一般是比較難見到的，而FIN_WAIT_2狀態還有時常常可以用netstat看到。

　　FIN_WAIT_2：上面已經詳細解釋了這種狀態，實際上FIN_WAIT_2狀態下的SOCKET，表示半連線，也即有一方要求close連線，但另外還告訴對方，我暫時還有點資料需要傳送給你，稍後再關閉連線。

　　TIME_WAIT： 表示收到了對方的FIN報文，併發送出了ACK報文，就等2MSL後即可回到CLOSED可用狀態了。如果FIN_WAIT_1狀態下，收到了對方同時帶FIN標誌和ACK標誌的報文時，可以直接進入到TIME_WAIT狀態，而無須經過FIN_WAIT_2狀態。

　　CLOSING： 這種狀態比較特殊，實際情況中應該是很少見，屬於一種比較罕見的例外狀態。正常情況下，當你傳送FIN報文後，按理來說是應該先收到（或同時收到）對方的 ACK報文，再收到對方的FIN報文。但是CLOSING狀態表示你傳送FIN報文後，並沒有收到對方的ACK報文，反而卻也收到了對方的FIN報文。什 麼情況下會出現此種情況呢？其實細想一下，也不難得出結論：那就是如果雙方几乎在同時close一個SOCKET的話，那麼就出現了雙方同時傳送FIN報 文的情況，也即會出現CLOSING狀態，表示雙方都正在關閉SOCKET連線。

　　CLOSE_WAIT： 這種狀態的含義其實是表示在等待關閉。怎麼理解呢？當對方close一個SOCKET後傳送FIN報文給自己，你係統毫無疑問地會迴應一個ACK報文給對 方，此時則進入到CLOSE_WAIT狀態。接下來呢，實際上你真正需要考慮的事情是察看你是否還有資料傳送給對方，如果沒有的話，那麼你也就可以 close這個SOCKET，傳送FIN報文給對方，也即關閉連線。所以你在CLOSE_WAIT狀態下，需要完成的事情是等待你去關閉連線。

　　LAST_ACK： 這個狀態還是比較容易好理解的，它是被動關閉一方在傳送FIN報文後，最後等待對方的ACK報文。當收到ACK報文後，也即可以進入到CLOSED可用狀態了。

 

 

總結：

 

1．為什麼建立連線協議是三次握手，而關閉連線卻是四次握手呢？

 

這是因為服務端的LISTEN狀態下的SOCKET當收到SYN報文的建連請求後，它可以把ACK和SYN（ACK起應答作用，而SYN起同步作用）放在一個報文裡來發送。但關閉連線時，當收到對方的FIN報文通知時，它僅僅表示對方沒有資料傳送給你了；但未必你所有的資料都全部發送給對方了，所以你可以未必會馬上會關閉SOCKET,也即你可能還需要傳送一些資料給對方之後，再發送FIN報文給對方來表示你同意現在可以關閉連線了，所以它這裡的ACK報文和FIN報文多數情況下都是分開發送的.

 

2．為什麼TIME_WAIT狀態還需要等2MSL後才能返回到CLOSED狀態？

 

這是因為雖然雙方都同意關閉連線了，而且握手的4個報文也都協調和傳送完畢，按理可以直接回到CLOSED狀態（就好比從SYN_SEND狀態到ESTABLISH狀態那樣）；但是因為我們必須要假想網路是不可靠的，你無法保證你最後傳送的ACK報文會一定被對方收到，因此對方處於LAST_ACK狀態下的SOCKET可能會因為超時未收到ACK報文，而重發FIN報文，所以這個TIME_WAIT狀態的作用就是用來重發可能丟失的ACK報文。

 

-------------------

 

說到tcp協議，凡是稍微看過的人都能順口說出三次握手和四次斷連，再牛逼的一點的就能夠把每個狀態（SYNC_SENT、CLOSE_WAIT。。。。。。等）都能背出來，

而說道socket程式設計，基本上寫過網路程式設計的人都會熟悉那幾個標準的API：socket、connect、listen、accept。。。。。。等

 

但是，我敢打賭很少有人明白tcp狀態和socket程式設計API之間的關係。不信？ 看看如下幾個問題你是否知道吧：

1）什麼時候客戶端才能夠連線上server端， 是server端呼叫bind後還是listen後還是accept後 ？

2）什麼情況下會出現FIN_WAIT_2狀態

。。。。。。。。。。。。。。。。。。。。。

 

本週打破砂鍋問到底的精神以及實事求是的精神，我用python指令碼寫了一些指令碼測試這些情況，看完後你一定會大呼過癮，對tcp的協議和socket程式設計的理解又更上層樓。

 

注：以下測試是在Linux（2.6.18）平臺上用python（2.7）指令碼測試，其它平臺沒有測試，有興趣可以自己測試一下。

 

【連線過程測試和驗證】

第1種情況：client呼叫connect，server只是呼叫了socket + bind，沒有呼叫listen

tcpdump抓包如下：

抓包結果顯示：server端直接回復了RST包

此時使用netstat或者ss命令去檢視，無論是client還是server，都查不到連線

 

第2種情況：client呼叫connect，server呼叫了socket + bind + listen

tcpdump抓包如下：

抓包結果顯示：三次握手完成

使用ss工具去檢視，client和server都顯示ESTAB

 

[html] view plain copy

1. [[email protected] ~]$ ss  -t -n | grep 50000  
2. ESTAB      0      0                10.1.73.45:55354           10.1.73.76:50000   

第3種情況：client呼叫connect + send，server呼叫了socket + bind + listen + accept + recv + send

 

tcpdump抓包如下：

抓包結果顯示：三次握手完成，並且雙方都可以傳送和接受資料了

使用ss工具去檢視，client和server都顯示ESTAB

 

[html] view plain copy

1. [[email protected] ~]$ ss  -t -n | grep 50000  
2. ESTAB      0      0                10.1.73.45:41363           10.1.73.76:50000   

【連線過程總結】

 

1）可以看到，只有當server端listen之後，client端呼叫connect才能成功，否則就會返回RST響應拒絕連線

2）只有當accept後，client和server才能呼叫recv和send等io操作

3）socket API呼叫錯誤不會導致client出現SYN_SENT狀態，那麼只能是網路裝置丟包（路由器、防火牆）才會導致SYNC_SENT狀態

 

【斷連過程測試和總結】

第1種情況：client呼叫close，但server沒有呼叫close

tcpdump抓包如下：

抓包結果顯示：client傳送了fin包，server端應答了ack包

 

使用ss工具去檢視，client顯示FIN_WAIT_2狀態：

 

[html] view plain copy

1. [[email protected] ~]$ ss  -t -n | grep "10.1.73.76:50000"  
2. FIN-WAIT-2 0      0                10.1.73.45:47630           10.1.73.76:50000  

server顯示CLOSE-WAIT狀態

 

 

[html] view plain copy

1. [[email protected]_test ~]$ ss  -t -n | grep 50000  
2. CLOSE-WAIT 1      0                10.1.73.76:50000           10.1.73.45:47630   

而且有一個值得注意的現象是：client的連線過一段時間就沒有了，而server的連線一直處於CLOSE_WAIT狀態

 

原因在於Linux系統核心中有一個引數可以控制FIN_WAIT_2的時間：tcp_fin_timeout
 

第2種情況：client呼叫close，server呼叫close

tcpdump抓包如下：

抓包結果顯示：熟悉的四次斷連來啦

使用ss工具去檢視，client顯示TIME-WAIT狀態

 

[html] view plain copy

1. [[email protected] ipv4]$ ss -a -n | grep 50000  
2. TIME-WAIT  0      0                10.1.73.45:39751           10.1.73.76:50000   

 

 

server端使用ss工具去看已經看不到連線了
 

第3種情況：server端被kill了

tcpdump抓包如下：

抓包結果顯示：熟悉的四次斷連來啦

咦，怎麼會和正常的server close一樣呢？答案就在於作業系統的實現：

close函式其實本身不會導致tcp協議棧立刻傳送fin包，而只是將socket檔案的引用計數減1，當socket檔案的引用計數變為0的時候，作業系統會自動關閉tcp連線，此時才會傳送fin包。

這也是多程序程式設計需要特別注意的一點，父程序中一定要將socket檔案描述符close，否則執行一段時間後就可能會出現作業系統提示too many open files

 

第4種情況：client端呼叫shutdown操作

shutdown操作有三種關閉方式：SHUT_RD、SHUT_WR、SHUT_RDWR，分別測試後發現有趣的現象。

1）如果是SHUT_RD，則tcpdump抓包發現沒有傳送任何包；

2）如果是SHUT_WR或者SHUT_RDWR，則client會發送FIN包給server，

    若server收到後執行close操作，則server傳送FIN給client，最終連線被關閉。

SHUT_WR或者SHUT_RDWR抓包顯示如下：

 

使用ss命令檢視，client顯示如下：

 

[html] view plain copy

1. [[email protected] ~]$ ss -a | grep 50000  
2. TIME-WAIT  0      0              10.1.73.45:45641           10.1.73.76:50000   

server顯示連線已經被關閉了。

 

 

關於shutdown的詳細解釋可以參考：http://www.gnu.org/software/libc/manual/html_node/Closing-a-Socket.html

歸納一下SHUT_RD的處理：

1）client端不再接收資料，如果有新的資料到來，直接丟棄(reject)

2）沒有傳送任何tcp包，所以server端並不知道這個狀態，server端可以繼續傳送資料，但由於1）的原因，發了也白髮

 

歸納一下SHUT_WR或者SHUT_RDWR的處理：

1）停止傳送資料（不能再呼叫write操作），丟棄緩衝區中未傳送的資料（已呼叫write但底層tcp協議棧還沒傳送的）

2）停止等待已傳送資料的確認訊息，已傳送未確認的資料不再重發

 

【斷連過程總結】

1）close只是減少socket檔案的引用計數，當計數減為0後，作業系統執行tcp的斷連操作

2）client端close後server端不close，會導致client端連線狀態為FIN_WAIT_2，server端連線狀態為CLOSE_WAIT

     正常程式設計肯定不會這樣處理，一般都是在異常處理跳轉（C++/JAVA等）導致沒有close，或者整個系統異常導致沒有close（例      如JVM記憶體出現out of memory錯誤）

3）shutdown的處理邏輯比較複雜，非特殊情況不要亂用，很容易出問題

4）程序退出後作業系統會自動回收socket，發起tcp關閉流程操作