1樓：攻城獅
另外，關於圖示顯示的第四個包的問題。這個包不屬於握手階段，但因為ack是對方seq+1，這一點容易被認為屬於握手階段。因為window size有改變（變大），應該是通知作用的視窗更新包。
視窗更新包可以是跟隨包含payload的TCP segment一起發（也就是在包含payload的包的window size部分設定新的視窗值），也可以是單獨發出。題主抓到的正好是單獨發出的視窗更新包。
2樓：車小胖
第四個包是伺服器端用來重新整理自己接收window size到節（Update window size from 65535 to 12759）！
仔細研究TCP報文交換的同學，一定會知道一點，TCP報文除了第乙個同步報文【SYN】沒有ACK標識位，其它所有報文都會有【ACK】標識位。
所以第四個包不是用來ACK客戶端的，因為三次同步握手已經結束，而是用來重新整理伺服器端的接收視窗，從初始的65535到目前的12759。
這個TCP連線客戶端、伺服器端都是同乙個loopback軟體介面，客戶端已經在三次握手時重新整理自己Window size 到12759，所以伺服器端也跟著重新整理了。
TCP Keeplive 訊息也是周期性地發【ACK】來重新整理定時器來保活TCP連線的。
這裡不是「TCP同時連線」，因為這裡的伺服器端只會被動連線，而沒有主動連線的能力。
3樓：賦小格
從報文上來看，有點像TCP的「同時開啟」。
比如說客戶端使用埠31501向31500傳送SYN的幾乎同一時刻，服務端也使用埠31500向客戶端的埠31501傳送SYN，然後兩端各自ACK對端傳送的SYN。在這種情況下，三次握手就變成了四次握手：
我雖然不確定你這種情況是不是同時開啟，但從行為和報文內容上看非常相似。
描述TCP建立連線的三次握手過程，如果最後一次握手失敗會怎樣處理？
參考文章 What if a TCP handshake segment is lost?In other words,if the ACK is dropped but the next packet is not dropped,then everything is fine.意思是說客戶端發出...
TCP建立連線的三次握手階段為什麼要協商乙個隨機的初始序列號（ISN），而不是預設從0開始
cccchan 通訊雙方在傳送SYN建立連線之前，必須為該TCP連線選定乙個ISN。ISN必須隨時變化，以確保每個連線的ISN都不一樣，尤其是相同連線 Socket 的不同例項，ISN絕不能一樣。RFC 793規定，應該使用乙個長度為32 bit並且每4s 1的計數器來選定ISN。然而，一旦有人掌握...
tcp中兩台裝置在同時建立連線時，為什麼需兩次傳送自己的SYN？
靈劍 這個應該不是重傳，而是一種特殊的狀態時序，一般建立連線時分主動被動兩種情況，這是第三種，即允許兩個埠同時發起連線，兩邊都是主動。從時間序列上說，兩邊發出SYN前都沒有收到對方的SYN，這種情況下兩邊都做三次握手，進入連線完成序列。實際情況下應該不太可能出現這種情況，因為一般會選擇自動分配的源埠...