哈喽哈喽大家好
上次聊了下关于TIME_WAIT的误区问题，总结优化的方法就是
- 设置链接复用
- 增加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配置时，需要注意它所带来的副作用
预告
Nginx一些简单又实用的安全配置整理
