解决FIN-WAIT-1过多和time_wait过多的问题

1、解决FIN-TAIT-1过多问题：（四次握手的原理不想多说，自己去找资料吧）
net.ipv4.tcp_keepalive_probes = 5
net.ipv4.tcp_keepalive_intvl = 15
net.ipv4.tcp_retries2 = 5
net.ipv4.tcp_orphan_retries = 3

tcp_retries1 :默认值是3
它表示的是最大的重试次数，当超过了这个值，我们就需要检测路由表了。

tcp_retries2 :默认值为15
也是最大重试次数，只不过这个值一般要比上面的值大。和上面那个不同的是，当重试次数超过这个值，我们就必须放弃重试了。

tcp_orphan_retries 主要是针对孤立的socket(也就是已经从进程上下文中删除了，可是还有一些清理工作没有完成).对于这种socket，我们重试的最大的次数就是它。

2、解决time_wait过多的问题
具体问题具体分析吧，很多人会把recyle和reuse作为标准解决方案，其实这里面涉及的知识面相当广，很多时候光靠这个根本解决不了问题
例如并发量过大，前端转发端口不足，导致的time_wait问题
我们这里讨论的是另一个，即timestamp和tcp_tw_recycle导致的一些问题：
tcp_tw_recycle：大概意思是说TCP有一种行为，可以缓存每个连接最新的时间戳，后续请求中如果时间戳小于缓存的时间戳，即视为无效，相应的数据包会被丢弃。
Linux是否启用这种行为取决于tcp_timestamps和tcp_tw_recycle，因为tcp_timestamps缺省就是开启的，所以当tcp_tw_recycle被开启后，实际上这种行为就被激活了。
现在很多公司都用LVS做负载均衡，通常是前面一台LVS，后面多台后端服务器，这其实就是NAT，当请求到达LVS后，它修改地址数据后便转发给后端服务器，但不会修改时间戳数据，对于后端服务器来说，请求的源地址就是LVS的地址，加上端口会复用，所以从后端服务器的角度看，原本不同客户端的请求经过LVS的转发，就可能会被认为是同一个连接，加之不同客户端的时间可能不一致，所以就会出现时间戳错乱的现象，于是后面的数据包就被丢弃了，具体的表现通常是是客户端明明发送的SYN，但服务端就是不响应ACK，还可以通过下面命令来确认数据包不断被丢弃的现象：

[root@down nginx]# netstat -s |grep  rejects
    541157958 packets rejects in established connections because of timestamp

既然是需要同时开启tcp_timestamps和tcp_tw_recycle才会启动这种行为，那我们就应该把默认开启的tcp_timestamps关闭掉，就能解决这个问题了
net.ipv4.tcp_timestamps = 0

sysctp -p生效