TCP 的11种连接状态及相应优化策略

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的情况

View Code

问题分析

结合协议我们知道主动关闭方会处于该状态，而且TIME_WAIT状态下的TCP连接会等待2*MSL。因此我们查看系统配置cat /proc/sys/net/ipv4/tcp_fin_timeout，发现是默认值。因此，确定是等待时间太长，导致套接字无法被利用所致。

View Code

问题解决

通过调整内核参数解决，打开文件/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时间

View Code

2 服务器端大量ESTABLISHED

问题描述

某Tomcat服务器出现大量ESTABLISHED连接。

问题分析

根据协议状态转换情况，初步推断是tomcat服务器回收session时出了问题，这个一般都跟服务器的Timeout设置有联系。查看tomcat的配置文件 server.xml

<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" URIEncoding="UTF-8" />*****

View Code

我们重点关注一下connectionTimeout，这个配置导致建立一个socket连接后，如果一直没有收到客户端的FIN，也没有数据过来，那么此连接也必须等到10s后，才能被超时释放。由于服务器并发量大，而该超时时间有长，导致连接释放严重滞后，因此出现大量的ESTABLISHED连接。

问题解决

connectionTimeout="20000"  改为 connectionTimeout="100"
acceptCount="100"  改为 acceptCount="5000"

View Code

转载自：https://baijiahao.baidu.com/s?id=1626222867928553865&wfr=spider&for=pc