表示开启TCP连接中TIME-WAIT sockets的快速回收，意思就是系统会保存最近一次该socket连接上的传输报文（包括数据或者仅仅是ACK报文）的时间戳，当相同四元组socket过来的报文的时间戳小于缓存下来的时间戳则丢弃该数据包，并回收这个socket，默认为0，表示关闭。开启这个功能风险有点大，NAT环境可能导致DROP掉SYN包（回复RST），在NAT场景下不要使用。需要注意在Linux内核4.10版本以后该参数就已经被移除了。
net.ipv4.tcp_fin_timeout = 60
这个时间不是修改2MSL的时长，主动关闭连接的一方接收到ACK之后会进入，FIN_WAIT-2状态，然后等待被动关闭一方发送FIN，这个时间是设置主动关闭的一方等待对方发送FIN的最长时长，默认是60秒。在这个状态下端口是不可能被重用的，文件描述符和内存也不会被释放，因为这个阶段被动关闭的一方有可能还有数据要发送，因为对端处于CLOSE_WAIT状态，也就是等待上层应用程序。关于这个的真实含义我希望大家清楚，而且不要调整的太小当然太大也不行，至少在3.10内核版本上这个参数不是调整的TIME_WAIT时长。我的资料查询3.10内核变量定义和RedHat官方解释。至于到底如何修改TIME_WAIT的时长，目前没找到可以通过命令或者配置的形式去修改的方式。
net.ipv4.ip_local_port_range = 32768 60999
表示用于外连使用的随机高位端口范围，也就是作为客户端连接其他服务的时候系统从这个范围随机取出一个端口来作为源端口使用来去连接对端服务器，这个范围也就决定了最多主动能同时建立多少个外连。
net.ipv4.tcp_max_tw_buckets = 6000
同时保持TIME_WAIT套接字的最大个数，超过这个数字那么该TIME_WAIT套接字将立刻被释放并在/var/log/message日志中打印警告信息（TCP: time wait bucket table overflow）。这个过多主要是消耗内存，单个TIME_WAIT占用内存非常小，但是多了就不好了，这个主要看内存以及你的服务器是否直接对外。
使用net.ipv4.tcp_tw_reuse和net.ipv4.tcp_tw_recycle 的前提是开启时间戳net.ipv4.tcp_timestamps = 1不过这一项默认是开启的。
作为7层的代理的Nginx在这种场景下首先要搞清楚哪一侧产生TIME_WAIT最多。为什么要看这个，我们知道TIME_WAIT是主动关闭一方具有的状态，但是Nginx作为7层代理对外它是服务器而对内它是客户端（例如，相对于后端的其他Web应用比如Tomcat）。
对外侧（被动连接）ss -nat | grep "TIME-WAIT" | awk '{print $4}' | egrep -w "192.168.71.101:80|192.168.71.101:443" | wc -l
作为代理服务器对外提供的端口就是80和443，所以我们针对"TIME-WAIT"状态来进行过滤本地地址和端口而且通过-w进行严格匹配2个条件就是"192.168.71.101:80|192.168.71.101:443"，这样就统计出Nginx作为服务器一方的外连TIME-WAIT的数量。
看一下抓包情况（下图是测试环境的包，上图是生产环境的统计）
由于在作为Web代理角色运行的时候为了提高HTTP性能所以Nginx通常会开启Keep-alive来让客户端对TCP连接进行复用，如果客户端在Keep-alive超时内没有进行通信那么当触发超时时服务器就会主动断开连接，也就是上图红色箭头的地方，另外一个情况就是Nginx设置对Keep-alive最大请求数量，意思是改链接在复用的时候可以发送多少次请求，如果到达这个最大请求次数也会断开连接，但无论怎么说这种情况是服务器主动断开所以TIME_WAIT则会出现在服务器上。
对于这种情况的TIME_WAIT通过修改net.ipv4.tcp_tw_reuse无法优化，因为服务器工作在80或者443端口，不存在重复使用或者快速回收的前提。开启net.ipv4.tcp_tw_recycle这个功能倒是还有点意义。
对内侧（主动连接）ss -nat | grep "TIME-WAIT" | awk '{print $4}' | egrep -w -v "192.168.71.101:80|192.168.71.101:443" | wc -l