tcp連線狀態詳解
說明： 通常情況下:一個正常的TCP連線，都會有三個階段:1、TCP三次握手;2、資料傳送;3、TCP四次揮手
裡面的幾個概念：
·SYN: (同步序列編號,Synchronize Sequence Numbers)
·ACK: (確認編號,Acknowledgement Number)
·FIN: (結束標誌,FINish)
TCP三次握手(建立 OPEN)
1.客戶端發起一個和服務建立TCP連結的請求，這裡是SYN(J)
2.服務端接受到客戶端的建立請求後，返回兩個資訊： SYN(K) + ACK(J+1)
3.客戶端在接受到服務端的ACK資訊校驗成功後(J與J+1)
4.服務端這時接受到客戶端的ACK資訊校驗成功後(K與K+1)，不再返回資訊，後面進入資料通訊階段
資料通訊
1.客戶端/服務端 read/write資料包
TCP四次握手(關閉 finish)
1.客戶端發起關閉請求，傳送一個資訊：FIN(M)
2.服務端接受到資訊後，首先返回ACK(M+1),表明自己已經收到訊息。
3.服務端在準備好關閉之前，最後傳送給客戶端一個 FIN(N)訊息，詢問客戶端是否準備好關閉了
4.客戶端接受到服務端傳送的訊息後，返回一個確認資訊: ACK(N+1)
5.最後，服務端和客戶端在雙方都得到確認時，各自關閉或者回收對應的TCP連結。
詳細的狀態說明(以及linux相關引數調整)
1.SYN_SEND
o客戶端嘗試連結服務端，通過open方法。也就是TCP三次握手中的第1步之後,注意是客戶端狀態
osysctl -w net.ipv4.tcp_syn_retries = 2 ,做為客戶端可以設定SYN包的重試次數，預設5次(大約180s)引用校長的話：僅僅重試2次，現代網路夠了
2.SYN_RECEIVED
o服務接受建立請求的SYN後，也就是TCP三次握手中的第2步，傳送ACK資料包之前
o注意是服務端狀態,一般15個左右正常，如果很大，懷疑遭受SYN_FLOOD***
osysctl -w net.ipv4.tcp_max_syn_backlog=4096 , 設定該狀態的等待佇列數，預設
osysctl -w net.ipv4.tcp_syncookies=1 , 開啟syncookie，在syn backlog佇列不足的時候，提供一種機制臨時將syn連結換出
osysctl -w net.ipv4.tcp_synack_retries = 2 ,做為服務端返回ACK包的重試次數，預設5次(大約180s)引用校長的話：僅僅重試2次，現代網路夠了
3.ESTABLISHED
o客戶端接受到服務端的ACK包後的狀態，服務端在發出ACK在一定時間後即為ESTABLISHED
osysctl -w net.ipv4.tcp_keepalive_time = 1200 ，預設為7200秒(2小時)，系統針對空閒連結會進行心跳檢查，如果超過net.ipv4.tcp_keepalive_probes* net.ipv4.tcp_keepalive_intvl = 預設11分，終止對應的tcp連結，可適當調整心跳檢查頻率
o目前線上的監控 waring:600 , critial : 800
4.FIN_WAIT1
o主動關閉的一方，在發出FIN請求之後，也就是在TCP四次握手的第1步
5.CLOSE_WAIT
o被動關閉的一方，在接受到客戶端的FIN後，也就是在TCP四次握手的第2步
6.FIN_WAIT2
o主動關閉的一方，在接受到被動關閉一方的ACK後，也就是TCP四次握手的第2步
osysctl -w net.ipv4.tcp_fin_timeout=30, 可以設定被動關閉方返回FIN後的超時時間，有效回收連結，避免syn-flood.
7.LASK_ACK
o被動關閉的一方，在傳送ACK後一段時間後(確保客戶端已收到)，再發起一個FIN請求。也就是TCP四次握手的第3步
8.TIME_WAIT
o主動關閉的一方，在收到被動關閉的FIN包後，傳送ACK。也就是TCP四次握手的第4步
osysctl -w net.ipv4.tcp_tw_recycle = 1 , 開啟快速回收TIME_WAIT，Enabling this option is not recommended since thiscauses problems when working with NAT (Network Address Translation)
osysctl -w net.ipv4.tcp_tw_reuse =1, 快速回收並重用TIME_WAIT的連結,貌似和tw_recycle有衝突，不能重用就回收?
onet.ipv4.tcp_max_tw_buckets: 處於time_wait狀態的最多連結數，預設為180000.
轉載於:https://blog.51cto.com/zhangshaoxiong/1271822