get技能 TCP（ip socket 关系）通信的三次握手和四次撒手的详细流程（顿悟）
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報文。
【問題3】為什么不能用兩次握手進行連接？
答：3次握手完成兩個重要的功能，既要雙方做好發送數據的準備工作(雙方都知道彼此已準備好)，也要允許雙方就初始序列號進行協商，這個序列號在握手過程中被發送和確認。
???????現在把三次握手改成僅需要兩次握手，死鎖是可能發生的。作為例子，考慮計算機S和C之間的通信，假定C給S發送一個連接請求分組，S收到了這個分組，并發 送了確認應答分組。按照兩次握手的協定，S認為連接已經成功地建立了，可以開始發送數據分組。可是，C在S的應答分組在傳輸中被丟失的情況下，將不知道S 是否已準備好，不知道S建立什么樣的序列號，C甚至懷疑S是否收到自己的連接請求分組。在這種情況下，C認為連接還未建立成功，將忽略S發來的任何數據分 組，只等待連接確認應答分組。而S在發出的分組超時后，重復發送同樣的分組。這樣就形成了死鎖。
【問題4】如果已經建立了連接，但是客戶端突然出現故障了怎么辦？
TCP還設有一個保活計時器，顯然，客戶端如果出現故障，服務器不能一直等下去，白白浪費資源。服務器每收到一次客戶端的請求后都會重新復位這個計時器，時間通常是設置為2小時，若兩小時還沒有收到客戶端的任何數據，服務器就會發送一個探測報文段，以后每隔75分鐘發送一次。若一連發送10個探測報文仍然沒反應，服務器就認為客戶端出了故障，接著就關閉連接。
---------------------?
?
------------------
?
說到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
第3種情況：client調用connect + send，server調用了socket + bind + listen + accept + recv + send
?
tcpdump抓包如下：
抓包結果顯示：三次握手完成，并且雙方都可以發送和接受數據了
使用ss工具去查看，client和server都顯示ESTAB
?
[html]?view plain?copy
【連接過程總結】
?
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
server顯示CLOSE-WAIT狀態
?
?
[html]?view plain?copy
而且有一個值得注意的現象是：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
?
?
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
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關閉流程操作
參考博文：
https://blog.csdn.net/qq_38950316/article/details/81087809?
https://blog.csdn.net/libaineu2004/article/details/79020403
總結
以上是生活随笔為你收集整理的get技能 TCP（ip socket 关系）通信的三次握手和四次撒手的详细流程（顿悟）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 锁屏密码锁、图案锁忘记怎么办？简单利用a
- 下一篇： 【Excel VBA】Len的有趣之处—