全NAT环境下的TCP参数优化

2020年4月10日 发表评论 阅读评论

问题现象

我边遇到的一个情况,一台主机访问另一台主机时,会发现有的时候时长特别长(注意是特别长),有的时间非常快,出现有问题的概率挺大的。通过抓包比对,发现TCP/IP包在花费时间特别长的时候有包重传的情况。而多花费的这3秒就耗费在了重传上:

full-nat-syn-ack

问题解决

其实这个问题呢,是个老生常谈的问题,这里涉及到两个TCP/IP参数net.ipv4.tcp_timestamps=1 和 net.ipv4.tcp_tw_recycle=1(默认该值为0),当两个参数同时设置为1时,就会导致上面提到的问题。解决方法也很简单,设置其中一个参数为0即可。

tcp_timestamps的本质是记录数据包的发送时间。基本的步骤如下:

  • 发送方在发送数据时,将一个timestamp(表示发送时间)放在包里面
  • 接收方在收到数据包后,在对应的ACK包中将收到的timestamp返回给发送方(echo back)
  • 发送发收到ACK包后,用当前时刻now - ACK包中的timestamp就能得到准确的RTT。当然实际运用中要考虑到RTT的波动,因此有了后续的(Round-Trip Time Measurement)RTTM机制。

但是需要注意的是,timestamps是一个双向的选项,当一方不开启时,两方都将停用timestamps。比如client端发送的SYN包中带有timestamp选项,但server端并没有开启该选项。则回复的SYN-ACK将不带timestamp选项,同时client后续回复的ACK也不会带有timestamp选项。当然,如果client发送的SYN包中就不带timestamp,双向都将停用timestamp。

tcp_tw_recycle 从字面上也可以看出,就是timewait的快速回收,对客户端和服务器同时起作用,开启后在 3.5*RTO 内回收,RTO 200ms~ 120s 具体时间视网络状况。注意还有一个tcp_tw_reuse参数,该参数只对客户端起作用,开启后客户端在1s内回收。reuse就是重用time_wait的socket连接。 服务端同一个端口被连接理论上是没限制的。

tcp_tw_reuse,tcp_tw_recycle 必须在客户端和服务端timestamps 开启时才管用(默认打开),其实意思就是假如服务端和客户端两边有一边timestamps没开启。tcp_tw_reuse和tcp_tw_recycle都没啥作用。tcp_tw_recycle 内网状况比tcp_tw_reuse 稍快,公网尤其移动网络大多要比tcp_tw_reuse 慢,优点就是能够回收服务端的TIME_WAIT数量。

分析总结

本文提到的这个同时开启这两个参数在全NAT环境下出问题的机率较高,除了上面所说的请求时间长,还有可能会出现ping和telnet都是正常的,但是就是访问异常,无响应。

理解了这两个参数,问题原因就比较简单了:问题出在了tcp三次握手,因为net.ipv4.tcp_timestamps=1 标记了时间戳,如果有一个用户的时间戳大于这个链接发出的syn中的时间戳,服务器上就会忽略掉这个syn,不返会syn-ack消息,表现为用户无法正常完成tcp3次握手,从而不能打开web页面。在业务闲时,如果用户nat的端口没有被使用过时,就可以正常打开;业务忙时,nat端口重复使用的频率高,很难分到没有被使用的端口,从而产生这种问题。

具体应该关闭和开启那个参数呢?建议权限linux的默认设置,关闭tcp_tw_recycle,因为Linux已经优化很好了 。而当一台主机即冲当服务端,同时又是客户端时(比如web,对于用户来说是服务端,但对于后端的数据库或第三方应用来说就是客户端),想要解决timewait过多的问题,可以开启tcp_tw_reuse和调整ip_local_port_range可用范围。

另外tcp_timestamp还被用于PAWS机制,先解释下PAWS(Protect Against Wrapped Sequence numbers):在高带宽下,TCP序列号可能在较短的时间内就被重复使用(recycle/wrapped)就可能导致同一条TCP流在短时间内出现序号一样的两个合法的数据包及其确认包!而开启了tcp_timestamp后,就会:

1. 发送方在发送数据时,将一个timestamp(表示发送时间)放在包里面
2. 接收方在收到数据包后,在对应的ACK包中将收到的timestamp返回给发送方(echo back)
3. 发送发收到ACK包后,用当前时刻now - ACK包中的timestamp就能得到准确的RTT

当然,开启timestamp也不是说没有一点坏处,其会增加10字节的TCP header开销。

参考页面:http://perthcharles.github.io/2015/08/27/timestamp-intro/




本站的发展离不开您的资助,金额随意,欢迎来赏!

You can donate through PayPal.
My paypal id: itybku@139.com
Paypal page: https://www.paypal.me/361way

分类: Linux/unix/mac 标签:
  1. 本文目前尚无任何评论.
  1. 本文目前尚无任何 trackbacks 和 pingbacks.