Nginx通过这个配置减少TIME-WAIT（nginx调优）

总结优化的方法就是

• 设置链接复用
• 增加tw_bucket队列大小
• 增加可用端口数量

快速回收，由于引发的一些问题，不建议配置

这些都是系统层面处理TIME_WAIT的方法，在Nginx中，有这么一条配置

reset_timedout_connection

官方文档这么描述

说人话就是，在连接超时后，向客户端发送RST包来直接重置连接，而不是走正常的四次握手断开连接，向客户端发送RST后，不再等待客户端的应答，直接释放这个链接使用的套接字中的所有资源。这样的好处就是服务器端不会产生太多处于FIN_WAIT_1、FIN_WAIT_2、TIME_WAIT状态的TCP连接

需要解释下这里说的连接超时，这个连接超时是指相对的和nginx是直连的客户端的连接，也就是一条连接四元组中的src，不是nginx后端超时，也不是客户端请求超时，这个情况存在于网络状况很差的情况，服务端发送请求后客户端不确认的情况

这里又引申到另外一个配置，即send_timeout，发送响应的超时时间，因为time_wait只存在主动断开的一方，send_timeout默认时间60s，当nginx向客户端发送了响应，但是一直等不到客户端的确认，超过send_timeout的时间后，nginx将关闭这个连接，这个时候就是nginx主动断开的连接

此时，如果nginx开启reset_timedout_connection，就会直接reset这个连接，而不会走正常的四次挥手去断开连接

因为这个环境不太好模拟，所以我们通过另一种方式，即return 444状态码去测试，按照上面官方文档中的解释，444状态码就是用来直接reset连接的

抓包对比下正常403断开和444断开的情况：

上图是正常的四次握手断开连接

接着在nginx中配置return 444，之后再抓包对比

可以看到，服务端直接发送了reset，此时查看服务器连接状态，没有产生time-wait

从上面的分析可以看到，如果使用此配置，可以有效减少客户端网络差的情况，引起的time-wait，但是考虑下面这种场景

服务端由于并发量大，网络拥塞，客户端的确认包迟迟到不了服务端，而服务端接收不到确认包，reset了客户端，客户端会一直无法访问，而客户端访问其他网络是正常的

总结：

在Nginx中，配置一些禁止访问的资源的时候，可以用444，代替403、404等状态码，从而可以减少恶意请求或访问带来的资源消耗，当使用reset_timedout_connection配置时，需要注意它所带来的副作用