___
tcp斷開連線的過程
客戶端傳送fin報文，表明客戶端將不在傳送資料。
具體過程：把fin標誌位改為1，序號seq=u，之前傳送的資料加1，這裡規定即使不攜帶資料序號也要+1。
該過程中客戶端通過close系統呼叫從established狀態進入fin_wait_1狀態。
第二次揮手
服務端收到客戶端發來的連線釋放報文(fin)，傳送確認報文。
具體過程：ack 標誌位置為1，確認序號=u+1，自己的序號v。該過程中服務端進入close_wait狀態，tcp伺服器通知高層應用程序客戶端已經沒有資料要傳送了，但是服務端可能還有資料要傳送，所以這段時間服務端仍然可以正常向客戶端傳送資料。
客戶端收到服務端的確認報文後進入fin_wait_2狀態，等待服務端傳送連線釋放報文(fin)，在收到fin之前仍需要接受服務端傳送的資料。
第三次揮手
服務端傳送完最後的資料之後，就向客戶端傳送連線釋放報文(fin)。
具體過程：fin標誌位置為1，確認序號= u+1，序號為w(可能之前的半關閉狀態又傳送了資料)。
服務端此時進入last_ack狀態，等待著客戶端最後的確認。
第四次揮手
客戶端收到服務端傳送的fin，傳送最後的確認並且等待2msl。
具體過程：ack標誌位置為1，確認序號=w+1，自己序號=u+1。
服務端收到客戶端的ack之後立即進入closed狀態，但是客戶端傳送完ack之後進入time_wait狀態，等待2msl之後進入closed狀態，所以服務端總是先於客戶端關閉。
__注意事項
__ _
客戶端最後傳送ack之後要等待2msl?
_____
①保證客戶端最後傳送的ack可以到達服務端。
思考這樣乙個場景，如果不等待2msl客戶端傳送最後乙個ack之後立即進入closed狀態，導致最後ack丟失，服務端就永遠不會收到客戶端傳送的ack就一直處於last_ack狀態。等待2msl就可以解決這個問題，如果最後的ack丟失，但客戶端不關閉而是處於time_wait狀態。假設最壞的情況下最後的ack在網路中存活了msl狀態恰好到達服務端「門口」的時候丟失，服務端沒有收到ack重發fin，歷時msl到達客戶端「門口」，客戶端收到fin知道ack丟失重發ack後重置時間再次等待2msl，所以通過設定time_wait狀態總能保證服務端收到最後的ack。
②防止已經失效的報文影響下次連線。
再來思考這樣乙個場景，服務端傳送fin後由於網路原因(路由迴圈等)客戶端暫時沒有收到，服務端等待一段時間後認為丟失，重新傳送fin，客戶端收到第二次的fin回執ack後，二者斷開連線(沒有等待2msl)。然後二者再次在相同的ip、埠上再次正常建立連線，此時網路中的fin報文到達客戶端，客戶端認為服務端傳送了主動關閉請求，從而影響了本次連線。但是等待2msl就不一樣了，在這2msl內客戶端處於time_wait狀態，網路中的fin最多存活msl，所以time_wait狀態內fin必定會丟棄，從而保證在建立新連線的時候，上次連線所有的報文都丟棄。
___ _
客戶端建立連線後突然故障怎麼辦?
_____
tcp有乙個保活計時器，顧名思義就是保證對端活著的計時器，每次收到對端報文後都會重置該計時器，計時器時間是兩小時，如果兩小時內沒有收到對端的訊息就會向對端傳送探測報文段，以後每隔75分鐘傳送乙個探測報文段，連續10次沒有收到應答就認為對端故障，然後斷開連線。
TCP四次揮手
純給自己看的 發起關閉的一方是客戶端，被動關閉的一方是伺服器。1 客戶端a傳送乙個fin 1，用來關閉客戶a到伺服器b的資料傳送。圖上畫的對，還有乙個seq n 2 伺服器b收到這個fin，它發回乙個ack 1，確認序號ack為收到的序號加1。3 伺服器b關閉與客戶端a的連線，傳送乙個fin 1給客...
TCP四次揮手
四次揮手 1.客戶端程序發出連線釋放報文，並且停止傳送資料。釋放資料報文首部，fin 1，其序列號為seq u 等於前面已經傳送過來的資料的最後乙個位元組的序號加1 此時，客戶端進入fin wait 1 終止等待1 狀態。tcp規定，fin報文段即使不攜帶資料，也要消耗乙個序號。2.伺服器收到連線釋...
TCP四次揮手
之前分析了tcp的在客戶端和服務端建立連線時的三次握手，那麼順便也學習下tcp的四次揮手吧！我們就直接開始分析通訊過程吧！第一次揮手 當客戶端已經不需要向服務端傳送資料時 即請求斷開連線 客戶端先傳送乙個fin fin 1,seq u 給服務端,來告訴服務端它已經完成了想要的通訊，並請求斷開連線，此...