有限狀態機&Time_wait的解讀

一、TCP有限狀態機

其中各狀態的含義：

    

狀態	含義
closed	初始狀態
listen	被動打開一方——監聽狀態
syn_sent	主動打開一方——鏈接創建已發送
syn_rcvd	被動打開一方——鏈接創建已接收
established	雙方——鏈接已經創建
fin_wait1	主動關閉一方——FIN已發送，等待確認
fin_wait2	主動關閉一方——確認已收到，等待對方關閉請求
time_wait	主動關閉一方——最後的確認已經發送，須要等待2MSL
close_wait	被動關閉一方——詢問我方進程是否還有數據要發送，沒有也要發送FIN進行關閉
last_ack	被動關閉一方——我方的fin已經發送，想要收到你的最後的確認
closing	主動關閉一方——在發送完FIN以後沒有收到確認可是收到了對端的FIN                             （場景：同時發送的FIN）

二、爲何須要三次握手

1）合併了鏈接確認和鏈接請求，如圖上的2

2）最後一次的ACK，防止了已失效的鏈接請求報文

   （client向server發送了SYN鏈接請求報文，可是因爲鏈路問題，滯留好久，client認爲這個報文丟失因而又重傳了一次；而在新鏈接過 

      程中，server收到了這個消失好久的報文，若是沒有三次握手，server就認爲這是一個新鏈接，因而鏈接創建，server會向這個新鏈接

      發送的數據都不會被client處理，server這樣就浪費了不少資源）

三、爲何須要四次揮手

1）FIN報文和ACK報文是成對的，而且能夠容許有半關閉的狀況；一方關閉了本身的發送方向，不在發送數據；可是另一方還有數據想要發送，這個時候是能夠不發送FIN報文，繼續發送數據到對端，對端只不過是關閉了發送方向，接收方向依然能夠接收數據

四、time_wait必須等待2MSL時間的理由

1）爲了保證主動關閉一方發送的最後一個ACK報文能過到達被動關閉的一方

    （由於這個報文有可能丟失，因此被動關閉的一方有可能重傳FIN報文，而後主動一方在2MSL中能收到這個重傳的報文，A在確認一次

       並重啓2MSL）

2）防止「已失效的鏈接請求報文」，和上面的三次握手中最後一個ACK必須有的那種狀況同樣，若是在2MSL中那個鏈接請求報文到了，咱們不對這個遲到的報文作處理，讓其消失；不會讓此次釋放鏈接完成後，還有舊的鏈接請求存在。