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生效
阅读(3819) | 评论(0) | 转发(0) |