這是我在書上拍的圖大家湊合看，圖雖不漂亮但是內容好啊
伺服器呼叫socket,bind,listen，後處於listen狀態（楨聽來自遠方tcp埠的連線請求）。稱之為被動開啟。
客戶端通過呼叫connect激發三路握手，呼叫connect後處於syn_sent狀態（在傳送連線請求後等待匹配的連線請求）。這將導致tcp傳送乙個syn分節，他告訴伺服器將在待建立的連線中傳送的資料的初始序列號。通常syn並不攜帶資料，其所在的ip資料報只包含乙個ip首部、乙個tcp首部、及可能有的tcp選項。在這個syn傳送到伺服器之前accept函式阻塞
伺服器必須確認客戶的syn,同時自己傳送乙個syn分節，它含有伺服器將在同一連線中傳送的資料的初始序列號，伺服器在單個分節中傳送syn和對客戶syn的ack.此時伺服器處於syn_rcvd(在接受和傳送乙個連線請求後等待對方連線請求的確認)
客戶端確認伺服器的syn。此時客戶處於estabished狀態（代表乙個開啟的連線）此時客戶的connect函式返回了。
伺服器收到來自客戶的ack處於estabished狀態，此時accept函式返回、
此時，連線已經建立，客戶構造乙個請求傳送給伺服器。伺服器對客戶請求的確認是伴隨其應答傳送的。這種做法成為捎帶，他通常在伺服器處理請求並產生應答的時間少於200ms時發生，如果伺服器耗用更長的時間比如1s，則我們將看到先是確認後是應答。
某個應用程序首先呼叫close，我們稱為主動關閉，該端的tcp於是傳送乙個fin分節，表示資料傳送完畢。呼叫後處於fin_wait1狀態（等待遠端tcp連線中斷請求或者先前的tcp連線中斷請求）
接受到這個fin的對端執行被動關閉，處於close_wait狀態（等待從本地使用者發來的連線中斷請求）並傳送乙個fin的ack。fin作為乙個檔案結束符傳遞給應用程序（放在已排隊等候該應用程序接受的任何其他資料之後），因為fin的接受意味著相應連線上再無資料可以接受。
原端接受到這個ack處於fin_wait2狀態，從遠端tcp等待連線中斷請求。
一段時間後，接收到這個檔案結束符的應用程式將呼叫close關閉他的套接字，這導致他的tcp也傳送乙個fin。
原端接受到這個fin後處於time_wait狀態（等待足夠的時間以確保遠端tcp接受到連線中斷的請求的確認）
對端接受到這個ack處於closed狀態（沒有任何連線狀態）
三次握手和四次揮手
三次握手和四次揮手如圖所示 為什麼是三次握手而不是兩次 因為當客戶端第傳送syn到服務端的時候，如果有幾次請求是因為網路等原因延時等情況的時候，如果沒有第三次握手的確定。服務端就會認為客戶端重寫傳送請求了，就會去開啟連線相應。為什麼關閉連線的時候是四次握手而不是三次？當客戶端傳送請求關閉連線的時候，...
三次握手和四次揮手
tcp三次握手和四次揮手的全過程 tcp是主機對主機層的傳輸控制協議，提供可靠的連線服務，採用三次握手確認建立乙個連線 位碼即tcp標誌位,有6種表示 syn synchronous建立連線 ack acknowledgement 表示響應 確認 psh push表示有data資料傳輸 fin fi...
三次握手和四次揮手
1.在學習tcp協議的時候，總是在強調三次握手，那麼為什麼是三次？而不是兩次或者四次？強迫症表示黑人問號？今天我們就來分析一下為什麼是三次，下圖是一次tcp通訊的時序 在這個例子中,首先客戶端主動發起連線 傳送請求,然後伺服器端響應請求,然後客戶端主動關閉連線。兩條豎線表示通訊的兩端,從上到下表 示...