[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了！这点很不靠谱，很不和谐，很不大众化！