今天詳細學習下TCP鏈接的三次握手四次揮手，因為開發web服務還是會經常遇到一些網絡問題的。其實這方面的資料很多，可能我們看過很多次但也忘了無數次[捂臉]，這次我主要通過抓包例子來展示這個過程。

• TCP傳輸控制協議(TransmissionControlProtocol)

他的特點是基于流、提供可靠數據傳輸，先建立連接再傳輸數據。提供如超時重傳、流控等各種機制，這樣的特點同時也導致了tcp會使用更多的連接，占用更多的資源。UDP則是直接發送數據，不保證數據的到達與接收。我們再把這個流程圖拿過來瞅瞅。

TCP建立與斷開

• 三次握手

三次握手

這里我用本機50319端口請求遠端80服務, 能清楚的看到三次TCP的連接，你是否有疑問為什么是三次，不是兩次，不是四次，其實這里是兼容安全與效率。

我們說TCP數據保證基于SYN與ACK的存在，其實這里明顯看到請求號72(也就是80->50319的回復)是將SYN+ACK合為了一條數據返回，這里我想應該可以拆開吧，但是拆開浪費一次鏈接。所以這里建立連接需要三次。

再來說下三次握手：

小明：你好麗麗，在嗎？我是小明 請求號65 50319---->SYN(Seq=0)------>80

小麗：你好小明，我在呀~~ 80->SYN+ACK(Seq=0,Ack=1)-->50319

小明：好的，那我們開始談談心吧！！ 50319->ACK(Seq=1, Ack=1)---->80

小麗：[愛慕] Established

小明：[送心] Established

• 四次揮手

四次揮手

這里先說明一點，HTTP1.1之后能自帶keep-alive屬性，也就是說同一個客戶端的http請求可以共用一個tcp連接，這樣能防止tcp連接的浪費，截圖說明

HTTP keep-alive

我們在測試的時候可以關閉這個keep-alive, 在請求的時候設置connetion:close就可以了，這樣可以方便我們抓包驗證。如果開著的話，當前的tcp連接就不會立刻斷開的截圖說明

postman 關閉keep-alive

再說回四次揮手，我們看到請求號(212)80->56427發送FIN標識的消息，這代表80端要結束連接了，56427->80回復了ACK,請求號(214), 隨后呢56247->80發送FIN標識請求號(215)，代表自己也沒有消息發送可以結束了，隨后請求號(216)80->56247發送ACK確認，至此連接關閉。

.......

小明：好吧，我說完了！ 80-----FIN----->56427

小麗：嗯嗯！ 56427------ACK--->80

小麗：我也沒話說了! 56427-----FIN----->80

小明：再見！！！ 80-----ACK----->56427

小明：[流淚]closed!!

小麗：[吐]closed!!

那為啥是四次揮手呢，如果是三次就像連接建立一樣將最后56427->80的ACK+FIN合并為一條可以嗎，當然不可以，這是因為TCP的連接雙方能發消息也能接受消息，FIN的發出代表本方將關閉消息發送，而無法確認對方是否還有消息發送過來，估需要雙方分別確定已關閉消息發送。

• 關于狀態的說明

這里我們在服務端加入sleep操作限制連接的立刻斷開如代碼

<?phpsleep (60);echo "hello World ";

我們觀察下鏈接狀態的變化

服務端狀態流轉：

LISTEN->SYN-RECEIVED->ESTABLISHED->CLOSE-WAIT->LAST-ACK->CLOSED

客戶端狀態流轉：

SYN-SENT->ESTABLISHED->FIN-WAIT1->FIN-WAIT2->TIME-WAIT->CLOSED

這里可能跟上面說的有差別，是因為我們這里是80主動關閉的連接。另外有些狀態流轉太快，我根本看不到啊[吐血]

狀態我還需要再學習學習，里面的玩意太多了，下個分享，我們找一些例子來學習下，重點是TIME_WAIT、2SML啥的。

總結：

• TCP的消息可靠性通過SYN+ACK實現
• TCP三次握手+四次揮手是有原因的
• TCP的連接雙方都有各自的狀態流轉
• 要通過一些工具如netstat、tcpdump去實際查看網絡連接狀況

總結

以上是生活随笔為你收集整理的tcp抓包返回fin_TCP/IP学习二TCP链接建立与断开的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。