这是一个历史遗留问题,早在去年就有员工反映说自己的机器在公司的网络上无法顺利访问51cto网站,网页有时候打开很慢,有时候根本打不开,但是在家里或者使用公司ADSL线路就没有问题,在公司访问其他网站却丝毫不受影响。针对这个事情我进行了长时间的摸索排查,发现,这种情况只出现在win7系统中,确实是有这种情况出现,XP系统丝毫没有问题,不管访问什么网站都没有出现访问困难的情况,于是我在自己的win7笔记本上开始了实验:
1.      检查ping
        一开始我就测试一下网络的通畅性,所以就ping一下51cto网站的地址,发现返回的时间都很短,基本上就是3ms或者4ms,所以断定网络没有问题。不光有问题的员工,其实我的win7访问也是不顺畅的。
 

 
2.      Tracert路由跟踪
       在我测试的时候依旧有员工反映说访问不顺畅,所以我就在他们访问不顺畅的时候进行路由跟踪,以便寻找故障位置,结果发现tracert路由跟踪也没问题。键入:“tracert –d www.51cto.com”,此时我的机器访问依然不顺畅。
 

3.      修改DNS
         此时我怀疑是不是DNS解析有问题,所以就修改了我机器上配置的DNS服务器地址,问题依旧,还是不顺畅。使用nslookup www.51cto.com也不行,看来不是DNS解析的问题。
 

 
4.      直接输入IP地址
        此时我又想起来了,如果直接敲IP地址行不行呢,所以就在我的浏览器上直接敲上了网站服务器的IP,结果依旧如故。
5.      查看防火墙跟组策略的配置
        此时判断应该与域名解析没有关系,如果域名解析有问题的话XP系统应该也会有问题的,所以否定了这个猜测,因为win7跟XP的防火墙和组策略有不同,所以我就查看防火墙的入站跟出站策略有没有限制什么,查了很多遍,没有什么好的结果,再查看组策略,似乎也没有太大关系,但是问题依旧存在啊,所以就索性把防火墙关闭,连自己安装的三方防火墙软件一起关闭,再打开浏览器查看,问题还是没有丝毫解决。
6.      求助别人
        此时的我可是束手无策了,只好求助于我之前加过的QQ群,看他们有没有好的方法,等了N天,不见有人回答;发到百度知道跟QQ问问,给出的答案要么不是我想要的,要么就是直接让我换系统!怎么可能嘛,因为这个问题换系统?!再说在别的网络上访问没有问题,根本不是系统有问题啊,win7各个版本都会出现这个情况。此时我想起了IE的网络诊断,所以就试了一下当访问不顺利时候诊断结果是什么,结果是“远程计算机80端口不接受连接”,既然是远程计算机不接受连接,那会不会是服务器那边的问题,所以求助机房的运维人员,让他们检查一下,回答我问题的人远程在我的计算机上看了看情况,然后查了一下服务器的状态,结果是“服务器那边没有问题”,难道是服务器系统跟win7有不兼容的情况吗?我问了一下我的领导,得到的结果是:服务器是centOS系统,不会存在排除某些客户端系统的情况,这种情况应该就不是系统的问题了,我又把注意力转到网络上,既然win7系统在别的网络状态下不会出现这种情况,会不会是公司主干网络的问题呢,而源头又在核心路由器上,所以我就求助了一下路由器生产厂家的客服人员,客服的工程师依然是远程在我的机器上看了看路由器的配置,并调出了debug的隐藏界面,改了一下参数,让我观察一下,可是根据我的观察问题还是没解决。于是对方让我装一个wireshark流量分析工具,远程抓取了公司内网中的数据包,并且告诉我,通过查看,发现公司的路由器可以升级一下固件,让我升级一下固件,然后他分析一下抓过的数据包,两边一起行动。为了保险起见,我也询问了光纤网络提供商,看一下他那边的线路有没有什么问题。
7.      升级核心路由器固件
        我于是等到下班之后升级了一下路由器固件,第二天上班时候客服工程师给我回馈:win7的数据包好像跟xp的有所不同,然后询问我升级之后怎么样,我说问题依旧,那位客服还真是很有责任心,(敬佩一个),让我把笔记本直接接到路由器的LAN口上再进行抓包分析。
8.      关闭RFC 1323 时间戳
        客服工程师远程把公司路由器的WAN口镜像到我的笔记本所接的LAN口,进行抓包操作,经过一段时间的分析,他发现路由器的WAN口在网页无法打开的时候接收不到来自服务器的回应,于是也帮我查了下有关的问题解决办法,说网上有类似的情况得到解决的,让我装一个QQ管家,装完之后他设置了一下,然后又通过抓包分析了一下流量,并查了查文档,然后在我的命令行上键入了这样一条命令:“netsh int tcp show global”,查看了一下,发现这样一条:“RFC 1323 时间戳”的状态是“enable”,于是键入:“netsh int tcp set global timestamps=disable”,我问其原因,客服工程师的回答是:“RFC 1323时间戳应该就是与服务器协商每个报文发送的间隔或者延时什么的,这个好像与linux的服务器配合,可能存在一些问题,如果同类报文从同一地址发过去多的话,会出现服务器无法响应请求的情况”,将时间戳关闭,然后让我重启了一下机器,重启之后我再次远程让那位工程师帮我检查一下,结果访问公司网站出奇的顺利,所以他让我观察一下,如果可以了就可以在别的有问题的机器上试一下那条命令,如果不行再想别的办法,所以我就开始等,并跟以前有问题的同事说,什么时候访问不了了,就告诉我,果然,等他们访问不了的时候,我打开我这边的浏览器访问公司网站,还是很顺利,所以我就用同样的办法查看并关闭了他们机器上的那个时间戳,故障立刻就消失了,我还不放心,让他们下班之前反馈一下使用情况,下班之前我问了一下,结果是一切正常。
 

        后记:这是我目前碰见过的最棘手的问题,解决时间最长,不过解决了是很有成就感的,同时也增长了处理问题的经验跟方法。(这条关闭时间戳的命令只适合于win7、vista和2008,XP用户是没有作用的)

本文出自 “樱花残月” 博客,请务必保留此出处http://mike3470.blog.51cto.com/1412804/497986