先假設是兩次握手，當client發出同步syn請求，server收到請求之後，傳送ack確認給client，（假設）此時server認為鏈結建立完畢，開始收發資料，如果一些原因導致client端關閉或者沒有收到server的回應，而server一直在等待client的資料，client又在等server（是否會超時重傳），造成死鎖；
另外一種情況是，因為一些網路原因，存在已經失效的鏈結請求（即上一次的鏈結請求），而client端此時沒有向server傳送請求，而server收到了這個失效的或者說是超時的鏈結請求，以為要建立鏈結，傳送乙個ack之後就進入資料收發狀態（是在兩次握手的假設下），浪費了資源（一系列的資料結構，比如等待確認的已經確認的佇列）；
① . 第一次揮手：
四次揮手時可以是客戶端發起的請求，也可以是伺服器端發起的請求。以客戶端請求斷開為例。client要求取消鏈結，最後乙個報文段置fin為1，並狀態轉換為fin_wait_1；當 server（伺服器） 收到client端的fin報文段後，會切換狀態為close_wait，告訴上層應用。
② . 第二次揮手：
lient關閉了鏈結，並且向client傳送ack確認，如果此時server的資料還沒有傳送完畢，依然會繼續向client傳送資料，client 收到server傳送的ack之後，也就是不再傳送資料，狀態切換為fin_wait_2。
③ . 第三次揮手：
當 server 資料傳送完畢，傳送乙個fin=1的報文段給client，告訴client資料傳送完畢，可以關閉鏈結，等待client的確認，並且狀態由close_wait轉為last_ack。
④ . 第四次揮手：
client 接收到server的fin之後，會對這個fin做出ack回應，狀態轉換為time_wait，這裡有個終止等待計時器，等待2msl的時間（msl報文最大生存時間），然後close，如果在這個期間收到重複的fin，則會觸發ack重傳，並將終止等待計時器重置；server 收到最後乙個ack之後，close。
四次揮手完成。
鏈結是client發起的，server端是被動接受的，而揮手就不是乙個主動，乙個被動的問題了，揮手即斷開鏈結的問題，是建立鏈結雙方的問題，client資料傳送完了，想要斷開了，它就得小心翼翼的問問server的意見，server覺得可以就給client說，我同意你斷開我，但是我斷開你必須由我發起，所以，client和server都有發起斷開鏈結fin和收到回答的權利，即四次揮手；
tcp建立的可靠地資料傳輸鏈結，那麼可靠體現在哪些地方呢？資料的完整性，有序性，可靠地重傳機制，活動視窗，擁塞視窗，擁塞避免機制等，那麼這和time_wait有什麼關係？既然tcp這麼可靠，那麼鏈結的建立和關閉必然也是很可靠的，哪怕是最後一次client發出了last_ack之後，也需要確認這個ack是否被server端收到，但是這個確認不是通過繼續讓server傳送ack（如果這樣，就無窮盡了），而是通過乙個計時器，就是前面說的終止等待計時器，當最後乙個ack被傳送之後，終止等待計時器被置為2msl，msl即報文段在傳輸過程中的最大生存時間，一般為30s到2分鐘不等，2msl即可以保證一段報文從client傳送到server再從server到client的最長時間，為什麼是這段時間，因為在這個時間內，我們的last_ack就算丟失，client仍然能夠收到server重傳的fin，那麼此時time_wait恢復初值，知道計時器結束都沒有收到server的重傳，client才會close。
TCP三次握手 四次揮手
tcp 三次握手 tcp 連線是通過三次握手進行初始化的。三次握手的目的是同步連線雙方的序列號和確認號並交換 tcp 視窗大小資訊。以下步驟概述了通常情況下客戶端計算機聯絡伺服器計算機的過程 1.客戶端向伺服器傳送乙個syn置位的tcp報文，其中包含連線的初始序列號x和乙個視窗大小 表示客戶端上用來...
TCP三次握手 四次揮手
服務端的tcp程序先建立傳輸控制塊tcb，準備接受客戶端程序的連線請求，然後服務端程序處於listen狀態，等待客戶端的連線請求，如有，則作出響應。1 客戶端的tcp程序也首先建立傳輸控制模組tcb，然後向服務端發出連線請求報文段，該報文段首部中的syn 1，ack 0，同時選擇乙個初始序號seq ...
TCP三次握手四次揮手
tcp transmission control protocol 傳輸控制協議 tcp是主機對主機層的傳輸控制協議，提供可靠的連線服務，採用三次握手確認建立乙個連線。位碼即tcp標誌位,有6種標誌 urg urgent緊急 ack acknowledgement 確認 psh push傳送 rst...