根据TCP/IP介绍，socket大概包含10个连接状态。我们平常工作中遇到的，除了针对SYN的拒绝服务攻击，如果有异常，大概率是TIME_WAIT和CLOSE_WAIT的问题。TIME_WAIT一般通过优化内核参数能够解决；CLOSE_WAIT一般是由于程序编写不合理造成的，更应该引起开发者注意。

TIME_WAIT

TIME_WAIT是主动关闭连接的一方保持的状态，像nginx、爬虫服务器，经常发生大量处于time_wait状态的连接。TCP一般在主动关闭连接后，会等待2MS，然后彻底关闭连接。由于HTTP使用了TCP协议，所以在这些频繁开关连接的服务器上，就积压了非常多的TIME_WAIT状态连接。

某些系统通过dmesg可以看到以下信息。

__ratelimit: 2170 callbacks suppressedTCP: time wait bucket table overflowTCP: time wait bucket table overflowTCP: time wait bucket table overflowTCP: time wait bucket table overflow

通过ss -s命令查看，可以看到timewait已经有2w个了。

ss -sTotal: 174 (kernel 199)TCP:   20047 (estab 32, closed 20000, orphaned 4, synrecv 0, timewait 20000/0), ports 10785

sysctl命令可以设置这些参数，如果想要重启生效的话，加入/etc/sysctl.conf文件中。

# 修改阈值net.ipv4.tcp_max_tw_buckets = 50000 # 表示开启TCP连接中TIME-WAIT sockets的快速回收net.ipv4.tcp_tw_reuse = 1#启用timewait 快速回收。这个一定要开启，默认是关闭的。net.ipv4.tcp_tw_recycle= 1   # 修改系统默认的TIMEOUT时间,默认是60snet.ipv4.tcp_fin_timeout = 10

测试参数的话，可以使用 sysctl -w net.ipv4.tcp_tw_reuse = 1 这样的命令。如果是写入进文件的，则使用sysctl -p生效。

CLOSE_WAIT

CLOSE_WAIT一般是由于对端主动关闭，而我方没有正确处理的原因引起的。说白了，就是程序写的有问题，属于危害比较大的一种。

Socket中的11种状态

1、客户端独有的：(1)SYN_SENT (2)FIN_WAIT1 (3)FIN_WAIT2 (4)CLOSING (5)TIME_WAIT 。2、服务器独有的：(1)LISTEN (2)SYN_RCVD (3)CLOSE_WAIT (4)LAST_ACK 。3、共有的：(1)CLOSED (2)ESTABLISHED 。各个状态的意义如下： LISTEN - 侦听来自远方TCP端口的连接请求； SYN-SENT -在发送连接请求后等待匹配的连接请求； SYN-RECEIVED- 在收到和发送一个连接请求后等待对连接请求的确认； ESTABLISHED- 代表一个打开的连接，数据可以传送给用户； FIN-WAIT-1 - 等待远程TCP的连接中断请求，或先前的连接中断请求的确认；FIN-WAIT-2 - 从远程TCP等待连接中断请求； CLOSE-WAIT - 等待从本地用户发来的连接中断请求； CLOSING -等待远程TCP对连接中断的确认； LAST-ACK - 等待原来发向远程TCP的连接中断请求的确认； TIME-WAIT -等待足够的时间以确保远程TCP接收到连接中断请求的确认； CLOSED - 没有任何连接状态；

我们平常工作中遇到的，除了针对SYN的拒绝服务攻击，大概率是TIME_WAIT和CLOSE_WAIT的问题。

TIME_WAIT一般通过优化内核参数能够解决。

CLOSE_WAIT一般是由于程序编写不合理造成的，更应该引起开发者注意。

1. time_wait状态如何产生？ 调用close()发起主动关闭的一方，在发送最后一个ACK之后会进入time_wait的状态，也就说该发送方会保持2MSL时间之后才会回到初始状态。MSL值得是数据包在网络中的最大生存时间。产生这种结果使得这个TCP连接在2MSL连接等待期间，定义这个连接的四元组(客户端IP地址和端口，服务端IP地址和端口号)不能被使用。

2.time_wait状态产生的原因

1)为实现TCP全双工连接的可靠释放

假设发起主动关闭的一方(client)最后发送的ACK在网络中丢失，由于TCP协议的重传机制，执行被动关闭的一方(server)将会重发其FIN，在该FIN到达client之前，client必须维护这条连接状态，也就说这条TCP连接所对应的资源(client方的local_ip,local_port)不能被立即释放或重新分配，直到另一方重发的FIN达到之后，client重发ACK后，经过2MSL时间周期没有再收到另一方的FIN之后，该TCP连接才能恢复初始的CLOSED状态。如果主动关闭一方不维护这样一个TIME_WAIT状态，那么当被动关闭一方重发的FIN到达时，主动关闭一方的TCP传输层会用RST包响应对方，这会被对方认为是有错误发生，然而这事实上只是正常的关闭连接过程，并非异常。

2)为使旧的数据包在网络因过期而消失

为说明这个问题，我们先假设TCP协议中不存在TIME_WAIT状态的限制，再假设当前有一条TCP连接：(local_ip, local_port, remote_ip,remote_port)，因某些原因，我们先关闭，接着很快以相同的四元组建立一条新连接。本文前面介绍过，TCP连接由四元组唯一标识，因此，在我们假设的情况中，TCP协议栈是无法区分前后两条TCP连接的不同的，在它看来，这根本就是同一条连接，中间先释放再建立的过程对其来说是“感知”不到的。这样就可能发生这样的情况：前一条TCP连接由local peer发送的数据到达remote peer后，会被该remot peer的TCP传输层当做当前TCP连接的正常数据接收并向上传递至应用层(而事实上，在我们假设的场景下，这些旧数据到达remote peer前，旧连接已断开且一条由相同四元组构成的新TCP连接已建立，因此，这些旧数据是不应该被向上传递至应用层的)，从而引起数据错乱进而导致各种无法预知的诡异现象。作为一种可靠的传输协议，TCP必须在协议层面考虑并避免这种情况的发生，这正是TIME_WAIT状态存在的第2个原因。

3)总结 具体而言，local peer主动调用close后，此时的TCP连接进入TIME_WAIT状态，处于该状态下的TCP连接不能立即以同样的四元组建立新连接，即发起active close的那方占用的local port在TIME_WAIT期间不能再被重新分配。由于TIME_WAIT状态持续时间为2MSL，这样保证了旧TCP连接双工链路中的旧数据包均因过期(超过MSL)而消失，此后，就可以用相同的四元组建立一条新连接而不会发生前后两次连接数据错乱的情况。

通过ss -s命令查看，可以看到timewait已经有2w个了。

如果想要重启生效的话，加入/etc/sysctl.conf文件中。

net.ipv4.tcp_syncookies = 1  #表示开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭；net.ipv4.tcp_max_tw_buckets = 50000 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 = 10  # 修改系统默认的TIMEOUT时间,默认是60s

使用sysctl -p生效

如果以上配置调优后性能还不理想，可继续修改一下配置：

vi /etc/sysctl.confnet.ipv4.tcp_keepalive_time = 1200 #表示当keepalive起用的时候，TCP发送keepalive消息的频度。缺省是2小时，改为20分钟。net.ipv4.ip_local_port_range = 1024 65000 #表示用于向外连接的端口范围。缺省情况下很小：32768到61000，改为1024到65000。net.ipv4.tcp_max_syn_backlog = 8192 #表示SYN队列的长度，默认为1024，加大队列长度为8192，可以容纳更多等待连接的网络连接数。net.ipv4.tcp_max_tw_buckets = 5000  #同时保持TIME_WAIT套接字的最大个数，超过这个数字那么该TIME_WAIT套接字将立刻被释放#并在/var/log/message日志中打印警告信息(TCP: time wait bucket table overflow)。#这个过多主要是消耗内存，单个TIME_WAIT占用内存非常小，但是多了就不好了，这个主要看内存以及你的服务器是否直接对外#默认为180000，改为5000。#对于Apache、Nginx等服务器，上几行的参数可以很好地减少TIME_WAIT套接字数量#但是对于 Squid，效果却不大。此项参数可以控制TIME_WAIT套接字的最大数量，避免Squid服务器被大量的TIME_WAIT套接字拖死。

CLOSE_WAIT

这种状态的含义其实是表示在等待关闭。怎么理解呢？当对方close一个SOCKET后发送FIN报文给自己，你系统毫无疑问地会回应一个ACK报文给对方，此时则进入到CLOSE_WAIT状态。接下来呢，实际上你真正需要考虑的事情是查看你是否还有数据发送给对方，如果没有的话，那么你也就可以close这个SOCKET，发送FIN报文给对方，也即关闭连接。所以你在CLOSE_WAIT状态下，需要完成的事情是等待你去关闭连接。CLOSE_WAIT一般是由于对端主动关闭，而我方没有正确处理的原因引起的。说白了，就是程序写的有问题，属于危害比较大的一种。代码需要判断socket，一旦读到0，断开连接，read返回负，检查一下errno，如果不AGAIN，就断开连接。