服务器tcp连接timewait过多优化及详细分析

服务器tcp连接timewait过多优化及详细分析,第1张

服务器tcp连接timewait过多优化及详细分析

[情况说明]

7层负载均衡上,查网络状态发现timewait太多,刚开始提前准备推广。

整体网络拓扑,前端是dr模式下四层负载均衡的lvs,后端是七层负载均衡的开发应用(nginx,或haproxy)。

[提高实际效果]

在更改之前,创建了29个连接,timewait创建了900个连接,如下图所示。

更改后,创建了32个连接,timewait的数量从900减少到49,如下图所示。


[实际改进计划]

注意:nat的前端开发和应用不适合此对策。一份详细的“计划的详细说明”将表明

更改第7层负载的设备,/etc/sysctl.conf。

net.ipv4.tcp_tw_reuse=1

net.ipv4.tcp_tw_recycle=1

net.IPv4.TCP_timestamps=1

net.ipv4.tcp_fin_timeout=20

Sysctl-p在存储后生效


[计划的详细说明]

net.ipv4.tcp_tw_reuse = 1

#表示重量已打开。允许等待时间套接字再次用于新的TCP连接,默认设置为0,表示关闭;该文档指示是否允许在等待时间的情况下再次使用套接字进行新的TCP连接(这对快速重启某些服务非常有帮助,并且在启动后提醒端口号已经被申请)。


net.ipv4.tcp_tw_recycle = 1


#表示TCP连接中时间等待套接字的快速获取打开,默认设置为0,表示关闭。


net.ipv4.tcp_timestamps打开时,net.ipv4.tcp_tw_recycle只有打开时才能生效。为此,可以参考以下代码。

if (tcp_death_row.sysctl_tw_recycle && tp->rx_opt.ts_recent_stamp)             recycle_ok = icsk->icsk_af_ops->remember_stamp(sk); if (recycle_ok) {                              tw->tw_timeout = rto;                          } else {          tw->tw_timeout = TCP_TIMEWAIT_LEN;                              if (state == TCP_TIME_WAIT)                                      timeo = TCP_TIMEWAIT_LEN;               }


如果网络服务器在nat的自然环境下,出于安全考虑,一般禁止使用tcp_tw_recycle。如果在nat下开启tcp_tw_recycle,很可能部分客户无法连接到网络服务器:在nat模式下(网络服务器一般使用dnat,客户一般使用snat),nat机器(或网络服务器)会改变目的ip和源ip来屏蔽内部信息。想象一下,许多客户根据dnat退出并浏览网站。在dnat级别,时间格式会紊乱一段时间,所以按照tcp的时间格式tcp_TW_recycle会失效。实际参考

fc1323的扩展表明

 RFC 1323          TCP Extensions for High Performance           May 1992            discarded when a connection is closed.            An additional mechanism could be added to the TCP, a per-host            cache of the last timestamp received from any connection.            This value could then be used in the PAWS mechanism to reject            old duplicate segments from earlier incarnations of the            connection, if the timestamp clock can be guaranteed to have            ticked at least once since the old connection was open.  This            would require that the TIME-WAIT delay plus the RTT together            must be at least one tick of the sender's timestamp clock.            Such an extension is not part of the proposal of this RFC.            Note that this is a variant on the mechanism proposed by            Garlick, Rom, and Postel [Garlick77], which required each            host to maintain connection records containing the highest            sequence numbers on every connection.  Using timestamps            instead, it is only necessary to keep one quantity per remote            host, regardless of the number of simultaneous connections to            that host.

Tcp会记录每个连接的时间格式。如果事后的时间格式小于之前记录的时间格式,会觉得是不正确的连接,拒绝连接。如果开启了tcp_tw_recycle,那么这种标准就会被激发出来(这样可以快速获取连接)。因此,在lvs应用nat的情况下,当有客户向lvs请求时,LVS会修改地址数据信息,并将请求发送到后端开发网络服务器,但不容易改变时间格式(因为nat系统只改变源地址和目的详细地址)。就后端开发网络服务器而言,需要的源地址始终是LVS的详细地址,端口号是复用的。不同手机客户端的需求,与LVS共享后大概会被视为同一个连接。另外,不同手机客户端的时间很可能不一致,这样就会出现时间格式混乱的情况,这样后面的数据文件就会被扔掉。实际主要表现一般是手机客户端原本推送的SYN,但是服务器不响应ACK。会出现有的客户可以连接到网络服务器,有的客户不能的情况。


但是在lvs应用使用dr模式的情况下,LVS总是修改mac和ip详细地址的映射关系,后端开发网络服务器仍然看到被屏蔽的客户端ip,所以调用这个标准不会有问题。这里大家都可以应用这个对策,很大的原因就在这里

net.ipv4.tcp_timestamps = 1

#表示TCP连接中时间等待套接字的快速获取打开,默认设置为0,表示关闭。


net.IPv4.TCP_fin_timeout=15;该主要参数用于设置保持FIN_WAIT_2状态的时间。4TCP招手,所有正常的解决方案都是在FIN_WAIT_2的条件下接受FIN进入TIME_WAIT状态。TCP_FIN_TIMOUT的主要参数在TIME_WAIT条件下对时间没有伤害。但如果将这个主参数设置的更小,会使FIN_WAIT_2到TIME_WAIT的时间减少,进而使连接进入TIME_WAIT状态的时间更长。情况开始的早,等的时间一样,结束的也早。客观上也加快了TIME_WAIT套接字清除速率。

对于tcp的断开,请参考以下有限状态机:


[补充说明]

如果在更改后运行命令netstat-s|greptimestamp

在已建立的连接中发现由于时间戳而被拒绝的数据包。

随着bid值的快速增加,你可能要回滚这个变化:说明有很多人在用snat浏览你的网站。


因为:虽然服务器不应用nat,但是手机客户端应用snat的情况很多。如果后来发现在已建立的连接中由于时间戳而导致的数据包拒绝正在迅速改善,则建议取消该计划。到时候net.IPv4.TCP_max_tw_buckets(CentOS默认设置好像是262144)可以调整到100000。其实也说明了在超时总数不大的情况下,tcp_tw_recycle的主要参数其实是可以调整的(风险很大)。



[摘要]

一个小小的变化,背后涉及的知识却异常多,所以必须如此

1.你不能只是找到一个计划并应用它。你一定深有体会。都说这种药A能治好病B,但本质是药A能治好病c的病因,吃药前要搞清楚病因。就算运气治好了,也不能总报这样的运气。

2.对于核心主参数的调整,你必须掌握好每一个主参数后再行动,否则可能会有不幸发生。

3.如有变化,必然有一个灰度的全过程,必须观察一段时间,才会有大规模的变化。


欢迎分享,转载请注明来源:内存溢出

原文地址: https://outofmemory.cn/zz/783660.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-05-04
下一篇 2022-05-04

发表评论

登录后才能评论

评论列表(0条)

保存