TCP 狀態轉換圖
tps: 斷開連接請求不僅是客戶端主動發起，也可能是server端，因為如果建立連接后但是沒有數據傳輸的時間超過server端設置的會話保持時間，那么server就會主動發起斷開連接請求。
各種狀態的含義
CLOSED：這個是套接字的初始狀態，表示TCP連接是新建“未打開的”狀態或者已經“關閉着的”。
LISTEN ：這個是服務端僅有的狀態，表示服務器端的某個SOCKET處於監聽狀態，可以接受客戶端的連接。
SYN_RCVD ：表示服務器接收到了來自客戶端請求連接的SYN報文。在正常情況下，這個狀態我們可能觀察不到，因為這個狀態是服務器端的SOCKET在建立TCP連接時的三次握手會話過程中的一個中間狀態，很短暫。
SYN_SENT ：這個狀態與SYN_RCVD 狀態相呼應，當客戶端SOCKET執行connect()進行連接時，它首先發送SYN報文，然后隨即進入到SYN_SENT 狀態，並等待服務端的發送三次握手中的第2個報文。
SYN_SENT 狀態表示客戶端已發送SYN報文。
ESTABLISHED ：表示TCP連接已經成功建立。
FIN_WAIT_1 ：這個狀態得好好解釋一下，其實FIN_WAIT_1 和FIN_WAIT_2 兩種狀態的真正含義都是表示等待對方的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()主動要求關閉連接。注意：FIN_WAIT_2 是沒有超時的（不像TIME_WAIT 狀態），這種狀態下如果對方不關閉（不配合完成4次揮手過程），那這個 FIN_WAIT_2 狀態將一直保持到系統重啟，越來越多的FIN_WAIT_2 狀態會導致內核crash。
TIME_WAIT ：表示收到了對方的FIN報文，並發送出了ACK報文。 TIME_WAIT狀態下的TCP連接會等待2*MSL（Max Segment Lifetime，最大分段生存期，指一個TCP報文在Internet上的最長生存時間。）在Linux可以通過cat /proc/sys/net/ipv4/tcp_fin_timeout看到本機的這個值，然后即可回到CLOSED 可用狀態了。
CLOSING ：這種狀態在實際情況中應該很少見，屬於一種比較罕見的例外狀態。正常情況下，當一方發送FIN報文后，按理來說是應該先收到（或同時收到）對方的ACK報文，再收到對方的FIN報文。但是
CLOSING 狀態表示一方發送FIN報文后，並沒有收到對方的ACK報文，反而卻也收到了對方的FIN報文。什么情況下會出現此種情況呢？那就是當雙方幾乎在同時close()一個SOCKET的話，就出現了雙方同時發送FIN報文的情況，這是就會出現CLOSING 狀態，表示雙方都正在關閉SOCKET連接。
CLOSE_WAIT ：表示正在等待關閉。怎么理解呢？當對方close()一個SOCKET后發送FIN報文給自己，你的系統毫無疑問地將會回應一個ACK報文給對方，此時TCP連接則進入到CLOSE_WAIT狀態。接下來呢，你需要檢查自己是否還有數據要發送給對方，如果沒有的話，那你也就可以close()這個SOCKET並發送FIN報文給對方，即關閉自己到對方這個方向的連接。有數據的話則看程序的策略，繼續發送或丟棄。簡單地說，當你處於CLOSE_WAIT 狀態下，需要完成的事情是等待你去關閉連接。
LAST_ACK ：當被動關閉的一方在發送FIN報文后，等待對方的ACK報文的時候，就處於LAST_ACK 狀態。當收到對方的ACK報文后，也就可以進入到CLOSED 可用狀態了。
實際生產環境的意義
我們知道Linux操作系統對文件句柄的總量是有限制的，套接字也屬於文件句柄，因此也是有限制的。了解套接字的狀態有助於我們了解服務器是否有隱患或者性能瓶頸。
舉個例子,假設一台服務器最多有6萬個句柄，如果由於某種業務場景，在服務器端出現大量的TIME_WAIT，此時這些套接字是無法馬上釋放，也就是無法馬上被重復使用，但仍然占用6萬句柄的名額。這塊，隨着時間的推移，可能會耗盡所有句柄，從而導致有新的連接請求是服務器端無法響應的問題。
實際生產中遇到問題及解決方案
1 服務器端大量TIME_WAIT
現象描述
某對象存儲服務，在監控系統發現有大量的TIME_WAIT。經確認該服務器是一台新上架接入的服務器。經反復確認，具備相同功能的同集群的其它服務器工作都正常，並不存在大量TIME_WAIT的情況
問題分析
結合協議我們知道主動關閉方會處於該狀態，而且TIME_WAIT狀態下的TCP連接會等待2*MSL。因此我們查看系統配置cat /proc/sys/net/ipv4/tcp_fin_timeout，發現是默認值。因此，確定是等待時間太長，導致套接字無法被利用所致。
問題解決
通過調整內核參數解決，打開文件/etc/sysctl.conf，編輯文件，加入以下內容： net.ipv4.tcp_syncookies = 1 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_tw_recycle = 1 net.ipv4.tcp_fin_timeout = 30 然后執行/sbin/sysctl -p讓參數生效。 上述內容的含義具體如下： net.ipv4.tcp_syncookies = 1 表示開啟SYN Cookies。當出現SYN等待隊列溢出時，啟用 cookies來處理，可防范少量SYN攻擊，默認為0，表示關閉； net.ipv4.tcp_tw_reuse = 1 表示開啟重用。允許將TIME-WAIT sockets重新用於新的TCP連接，默認為0，表示關閉； net.ipv4.tcp_tw_recycle = 1 表示開啟TCP連接中TIME-WAIT sockets的快速回收，默認為0，表示關閉。 net.ipv4.tcp_fin_timeout 修改系統默認的TIMEOUT時間
2 服務器端大量ESTABLISHED
問題描述
某Tomcat服務器出現大量ESTABLISHED連接。
問題分析
根據協議狀態轉換情況，初步推斷是tomcat服務器回收session時出了問題，這個一般都跟服務器的Timeout設置有聯系。查看tomcat的配置文件 server.xml
<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" URIEncoding="UTF-8" />*****
我們重點關注一下connectionTimeout，這個配置導致建立一個socket連接后，如果一直沒有收到客戶端的FIN，也沒有數據過來，那么此連接也必須等到10s后，才能被超時釋放。由於服務器並發量大，而該超時時間有長，導致連接釋放嚴重滯后，因此出現大量的ESTABLISHED連接。
問題解決
connectionTimeout="20000" 改為 connectionTimeout="100" acceptCount="100" 改為 acceptCount="5000"
轉載自：https://baijiahao.baidu.com/s?id=1626222867928553865&wfr=spider&for=pc