tcp鏈接的幾種狀態及鏈接狀態詳解

一般狀況下，一個正常的TCP鏈接，都會有三個階段:

    TCP三次握手;
    數據傳送;
    TCP四次揮手

裏面的幾個概念：

    SYN: (同步序列編號,Synchronize Sequence Numbers)
    ACK: (確認編號,Acknowledgement Number)
    FIN: (結束標誌,FINish)

I. TCP三次握手

客戶端發起一個和服務建立TCP連接的請求，這裏是SYN(J)
服務端接受到客戶端的建立請求後，返回兩個信息： SYN(K) + ACK(J+1)
客戶端在接受到服務端的ACK信息校驗成功後(J與J+1)，返回一個信息：ACK(K+1)
服務端這時接受到客戶端的ACK信息校驗成功後(K與K+1)，再也不返回信息，後面進入數據通信階段

II. 數據通信

客戶端/服務端 read/write數據包

III. TCP四次握手

    客戶端發起關閉請求，發送一個信息：FIN(M)
    服務端接受到信息後，首先返回ACK(M+1),代表本身已經收到消息。
    服務端在準備好關閉以前，最後發送給客戶端一個 FIN(N)消息，詢問客戶端是否準備好關閉了
    客戶端接受到服務端發送的消息後，返回一個確認信息: ACK(N+1)
    最後，服務端和客戶端在雙方都獲得確認時，各自關閉或者回收對應的TCP連接。

IV. 詳細的狀態說明

SYN_SEND

客戶端嘗試連接服務端，經過open方法。也就是TCP三次握手中的第1步以後,注意是客戶端狀態
sysctl -w net.ipv4.tcp_syn_retries = 2 ,作爲客戶端能夠設置SYN包的重試次數，默認5次(大約180s)引用校長的話：僅僅重試2次，現代網絡夠了

SYN_RECEIVED

服務接受建立請求的SYN後，也就是TCP三次握手中的第2步，發送ACK數據包以前
注意是服務端狀態,通常15個左右正常，若是很大，懷疑遭受SYN_FLOOD攻擊
sysctl -w net.ipv4.tcp_max_syn_backlog=4096 , 設置該狀態的等待隊列數，默認1024，調大後可適當防止syn-flood，可參見man 7 tcp

sysctl -w net.ipv4.tcp_syncookies=1 ,　打開syncookie，在syn backlog隊列不足的時候，提供一種機制臨時將syn連接換出
sysctl -w net.ipv4.tcp_synack_retries = 2 ,作爲服務端返回ACK包的重試次數，默認5次(大約180s)引用校長的話：僅僅重試2次，現代網絡夠了

ESTABLISHED

客戶端接受到服務端的ACK包後的狀態，服務端在發出ACK在必定時間後即爲ESTABLISHED
sysctl -w net.ipv4.tcp_keepalive_time = 1200 ，默認爲7200秒(2小時)，系統針對空閒連接會進行心跳檢查，若是超過net.ipv4.tcp_keepalive_probes * net.ipv4.tcp_keepalive_intvl = 默認11分，終止對應的tcp連接，可適當調整心跳檢查頻率
目前線上的監控 waring:600 , critial : 800

FIN_WAIT1

主動關閉的一方，在發出FIN請求以後，也就是在TCP四次握手的第1步

CLOSE_WAIT

被動關閉的一方，在接受到客戶端的FIN後，也就是在TCP四次握手的第2步

FIN_WAIT2

主動關閉的一方，在接受到被動關閉一方的ACK後，也就是TCP四次握手的第2步
sysctl -w net.ipv4.tcp_fin_timeout=30, 能夠設定被動關閉方返回FIN後的超時時間，有效回收連接，避免syn-flood.

LASK_ACK

被動關閉的一方，在發送ACK後一段時間後(確保客戶端已收到)，再發起一個FIN請求。也就是TCP四次握手的第3步

TIME_WAIT

主動關閉的一方，在收到被動關閉的FIN包後，發送ACK。也就是TCP四次握手的第4步
sysctl -w net.ipv4.tcp_tw_recycle = 1 , 打開快速回收TIME_WAIT，Enabling this option is not recommended since this causes problems when working with NAT (Network Address Translation)
sysctl -w net.ipv4.tcp_tw_reuse =1, 快速回收並重用TIME_WAIT的連接, 貌似和tw_recycle有衝突，不能重用就回收?
net.ipv4.tcp_max_tw_buckets: 處於time_wait狀態的最多連接數，默認爲180000.

V. 相關說明

主動關閉方在接收到被動關閉方的FIN請求後，發送成功給對方一個ACK後,將本身的狀態由FIN_WAIT2修改成TIME_WAIT，而必須再等2倍的MSL(Maximum Segment Lifetime,MSL是一個數據報在internetwork中能存在的時間)時間以後雙方纔能把狀態 都改成CLOSED以關閉鏈接。目前RHEL裏保持TIME_WAIT狀態的時間爲60秒

keepAlive策略能夠有效的避免進行三次握手和四次關閉的動做


TCP鏈接狀態詳解

CLOSED: 表示初始狀態。

LISTEN: 表示服務器端的某個SOCKET處於監聽狀態，能夠接受鏈接。

SYN_SENT:在服務端監聽後，客戶端SOCKET執行CONNECT鏈接時，客戶端發送SYN報文，此時客戶端就進入
SYN_SENT狀態，等待服務端的確認

SYN_RCVD: 表示服務端接受到了SYN報文，在正常狀況下，這個狀態是服務器端的SOCKET在創建TCP鏈接時的三
次握手會話過程當中的一箇中間狀態，很短暫，基本上用netstat你是很難看到這種狀態的，除非你特地寫了一
個客戶端測試程序，故意將三次TCP握手過程當中最後一個ACK報文不予發送。所以這種狀態時，當收到客戶端的
ACK報文後，它會進入到ESTABLISHED狀態。

ESTABLISHED：表示鏈接已經創建了。

FIN_WAIT_1: 這個是已經創建鏈接以後，其中一方請求終止鏈接，等待對方的FIN報文。FIN_WAIT_1狀態是當
SOCKET在ESTABLISHED狀態時，它想主動關閉鏈接，向對方發送了FIN報文，此時該SOCKET即進入到FIN_WAIT_1
狀態。而當對方迴應ACK報文後，則進入到FIN_WAIT_2狀態，固然在實際的正常狀況下，不管對方何種狀況下
，都應該立刻迴應ACK報文，因此FIN_WAIT_1狀態通常是比較難見到的，而FIN_WAIT_2狀態還有時經常能夠用
netstat看到。

FIN_WAIT_2：實際上FIN_WAIT_2狀態下的SOCKET，表示半鏈接，也即有一方要求close鏈接，但另外還告訴對
方，我暫時還有點數據須要傳送給你，稍後再關閉鏈接。

TIME_WAIT: 表示收到了對方的FIN報文，併發送出了ACK報文，就等2MSL後便可回到CLOSED可用狀態了。若是
FIN_WAIT_1狀態下，收到了對方同時帶FIN標誌和ACK標誌的報文時，能夠直接進入到TIME_WAIT狀態，而無須
通過FIN_WAIT_2狀態。

CLOSING: 這種狀態比較特殊，實際狀況中應該是不多見，屬於一種比較罕見的例外狀態。正常狀況下，當你
發送FIN報文後，按理來講是應該先收到(或同時收到)對方的ACK報文，再收到對方的FIN報文。可是CLOSING狀
態表示你發送FIN報文後，並無收到對方的ACK報文，反而卻也收到了對方的FIN報文。什麼狀況下會出現此
種狀況呢？其實細想一下，也不可貴出結論：那就是若是雙方几乎在同時close一個SOCKET的話，那麼就出現
了雙方同時發送FIN報文的狀況，也即會出現CLOSING狀態，表示雙方都正在關閉SOCKET鏈接。

CLOSE_WAIT: 這種狀態的含義實際上是表示在等待關閉。怎麼理解呢？當對方close一個SOCKET後發送FIN報文給
本身，你係統毫無疑問地會迴應一個ACK報文給對方，此時則進入到CLOSE_WAIT狀態。接下來呢，實際上你真
正須要考慮的事情是察看你是否還有數據發送給對方，若是沒有的話，那麼你也就能夠close這個SOCKET，發
送FIN報文給對方，也即關閉鏈接。因此你在CLOSE_WAIT狀態下，須要完成的事情是等待你去關閉鏈接。

 

LAST_ACK: 這個狀態仍是比較容易好理解的，它是被動關閉一方在發送FIN報文後，最後等待對方的ACK報文。 當收到ACK報文後，也便可以進入到CLOSED可用狀態了。