这是个不好定位的问题，当服务器连接数高时会出现。

问题现象：一台同事的电脑无法打开一个域名，有时偶尔能打开一次。

分析过程:

1.页面错误是网络无法连接的错误页面，分析是tcp三次握手没有完成。

2.抓包发现请求头比正常的请求多了  TSval 0, TSecr 0，

3.上网找到了timestamps参数（tcp 的时间戳），找到网友的相关问题处理http://www.mscbsc.com/bbs/archiver/index.php?tid-304644.html&

针对带有时间戳的tcp syn包不响应的问题，查阅了相关资料。在网上中查到（[url]http://www.spinics.net/lists/linux-net/msg17195.html[/url]）相关内容，和我们遇到的非常相似，后来查到rfc1323中有相关内容。测试了下，已经解决了问题。产生问题的原因是 部分win7系统中的注册表中有Tcp1323Opts这个选项，会导致其在发包时加入时间戳，经过nat之后，如果前面相同的端口被使用过，且时间戳大于这个链接发出的syn中的时间戳，服务器上就会忽略掉这个syn，不返会syn-ack消息，表现为用户无法正常完成tcp3次握手，从而不能打开portal页面。在业务闲时，如果用户nat的端口没有被使用过时，就可以正常打开；业务忙时，nat端口重复使用的频率高，很难分到没有被使用的端口，从而产生这种问题。

4.发现问题电脑的注册表Tcp1323Opts值为3，而正常电脑值为1

解决方法：

1.修改客户端的注册表Tcp1323Opts设置为0。
2. 在服务器上修改变量  Sysctl –w net.ipv4.tcp_timestamps=0

三、测试结果
1.redhat AS 5.3的timestamps=1，没有问题，不知是否是连接数低的原因，为了避免，也改为了0

2.redhat  RHEL 6.2  timestamps=1是，连接数2千多，发现的问题，改为0后正常。

这个跟系统应该有一定的关系,抓包发现AS5 发请求包时有 TSval 0, TSecr 0，但ack包却不包含这两个，tcp连接建立正常。 RHEL6.2 发请求包时有 TSval 0, TSecr 0，大部分不回ack包，无法建立连接，偶尔能建立连接ack回包也带TSval , TSecr 这个，这就是和AS5的区别！