我们专注服务于当下互联网基础设施建设与云计算、大数据时代的各种需求!

TCP RFC 1323网络优化的问题

[rfc1323]window7的Tcp1323Opts与linux的net.ipv4.tcp_timestamps和NAT

最近遇到一个内网win7用户无法上部分网站的问题,同网段的其他机器都是正常,出问题的机器访问其他网站也是正常。
网络结构简单,client<->源地址转换NAT<->网站
经过在server上抓包发现,server上有时会对client的syn包无响应。

依次排查了服务器的iptables\backlog\syncookies依然没有效果,通过google查到了这样一个链接

http://www.spinics.net/lists/linux-net/msg17195.html

这个上面出的问题和我们遇到的非常相似,测试了下,完全解决问题。
通过我们测试,部分win7系统中的注册表中有Tcp1323Opts这个选项,会导致其在发包时加入时间戳,经过nat之后,如果前面相同的端口被使用 过,且时间戳大于这个链接发出的syn中的时间戳,就会导致在服务器上忽略掉这个syn。表现为用户无法正常完成tcp3次握手。方法是在服务器上禁止

1
sysctl -w net.ipv4.tcp_timestamps=0

或者修改客户端的注册表Tcp1323Opts设置为0。

rfc1323
http://www.faqs.org/rfcs/rfc1323.html
Tcp1323Opts
http://technet.microsoft.com/en-us/library/cc938205.aspx

 

这个问题最好是更改客户端的这个值,因为所有服务器上timestamps都是1.

 

Windows XP包含几个可以动态地影响性能的注册表参数——其中有一个设置是用于处理RFC 1323的,即高性能的TCP扩展。

RFC 1323中所引用的TCP窗口是接收窗口——存储到达TCP片的缓存空间,除非(a)到达的数据包设置了Push标记然后它们被立即下发到应用程序中,或者(b)接收它的应用程序到缓存中取它的数据。

在TCP握手过程中,基于TCP连接的双方都会告诉对方它们的接收缓存大小。这是包含在TCP包头的Window Size字段里的。这个字段的典型值是65,535(它是一个2字节长度的字段,65,535是它能表示的最大值)。这表明如果需要的话,发送握手数据包 的设备有65,535个字节空间可用于存储到达的数据。注意如果从一个TCP节点发来的初始通信在TCP握手数据包中使用了TCP Window Scale选项,那么XP系统默认会使用Window Scaling。这意味着如果你的XP设备是作为服务器(响应初始的TCP握手数据包)使用,你将会使用Window Scaling。如果你的XP设备是一个客户端(比如,你用来连接一个HTTP服务器或邮件服务器),你就不会使用Window Scaling。

Tcp1323Opts
Key: TcpipParameters
Value Type: REG_DWORD — number (flags)
Valid Range: 0, 1, 2, 3
0 (disable RFC 1323 options) (禁用RFC 1323选项)
1 (window scaling enabled only) (仅启用窗口缩放)
2 (timestamps enabled only) (仅启用时间戳)
3 (both options enabled) (启用窗口缩放和时间戳)

  默认:没有值。默认的行为是这样的:当初始化TCP连接时不使用时间戳(Timestamp)和窗口尺寸(Window Scale)选项,但如果TCP节点在初始化通信时在SYN片中包含了它们,就使用时间戳和窗口尺寸(Window Scale)选项。实际上windows xp sp3默认设置成3了!这点很不靠谱,很不和谐,很不大众化!