现象:
尝试打开网页
http://sage.mc.yu.edu/kbeen/teaching/algorithms/resources/red-black-tree.html时出现超时错误(The connection has timed out)
firefox, chrome, ie8均出现了这个错误.
(注意:我打开别的网页没有问题,eg:google, gmail....)
用ping, tracert均能连上. 具体地:
然后我ping 了下
sage.mc.yu.edu也成功了了. ( 注:我也打不开网页
sage.mc.yu.edu).如下：
C:\Documents and Settings\xxxx>ping sage.mc.yu.edu
Pinging sage.mc.yu.edu [129.98.215.77] with 32 bytes of data:
Reply from 129.98.215.77: bytes=32 time=290ms TTL=104
Reply from 129.98.215.77: bytes=32 time=279ms TTL=104
....然后又用tracert看了一下. 信息如下:
C:\Documents and Settings\simon>tracert sage.mc.yu.edu
Tracing route to sage.mc.yu.edu [129.98.215.77]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms localhost [192.168.0.1]
2 6 ms 2 ms 1 ms 10.25.0.1 [10.25.0.1]
3 5 ms 1 ms 1 ms localhost [172.17.0.69]
4 6 ms 1 ms 4 ms localhost [172.17.2.7]
5 * 4 ms 1 ms 27.189.198.1
6 * * * Request timed out.
7 * * * Request timed out.
8 40 ms 43 ms 21 ms 27.189.251.13
.........
22 415 ms 371 ms 374 ms 216.55.2.10
23 255 ms 315 ms 255 ms rtr3-tg10-1.wan.hcvlny.cv.net [64.15.0.2]
24 348 ms * 341 ms 64.15.2.6
25 371 ms 387 ms 434 ms rtr1-gec-1.cst.bthpny.cv.net [64.15.4.122]
26 254 ms 268 ms 315 ms 4133c346.cst.lightpath.net [65.51.195.70]
27 621 ms 618 ms 623 ms aecom-inet-core2-gw.net.yu.edu [129.98.18.254]
28 371 ms 357 ms 349 ms wilf-core2-ios-gw.net.yu.edu [129.98.15.254]
29 257 ms 257 ms 262 ms sage.mc.yu.edu [129.98.215.77]从上面的信息看到, 它需要经过很多hop才能到达目标.
然后google, baidu了. 发现均不能解决. 最后只能放弃了.
但是其中说了 可以尝试修改MTU看看, 能不能解决 (这是这个文章要说的).
另外, 我还尝试了 延长firefox超时的时间, 但是没有找到确切的选项(about:config中没有找到, 也许我该的不对).
不过倒是发现有不少人 发帖询问如何修改 firefox打开网页是的 超时时间.
修改MTU
我的网络环境:
本机 通过 家用路由器 上网.
家用路由器的MTU设置为1500.
我尝试修改本机的MTU.
下面的文章摘自别人的博客或者说由别人的博客编译而成.
MTU是Maximum Transmission Unit的缩写。
意思是网络上传送的最大数据包。MTU的单位是字节。 下面列出了一些上网方式的MTU值：
EtherNet(一般上网方式，默认值):1500
PPPoE/ADSL:1492
Dial Up/Modem:576
大部分网络设备的MTU都是1500。如果本机的MTU比网关的MTU大，大的数据包就会被拆开来传送，这样会产生很多数据包碎片，增加丢包率，降低网络 速度。把本机的MTU设成比网关的MTU小或相同，就可以减少丢包。
注意:
通常本机的MTU的值最好是能用被分包就能到达目标主机. 但是通常本机到目标主机的链路不清楚(即中间经过的路由器未知),有些链路的MTU可能很小.
此外, 一般安装机器时是没有附带按照 检测 整条链路上的MTU的, 所以通常 本机的MTU不好设置啊.
就xp而言, 你能为某一个本地连接(可以认为是网卡) 设置一个MTU,并且重启后才有效, 并且每一个利用该本地连接的包都使用该MTU.此外, 本机到不同的目标主机 使用的链路 极有可能不一样(几乎不会一样), 所以 你 设置的本机MTU不可能适应所有情况..只能是 对于大部分情况这这个MTU最好....
如何检测网关的MTU？
(这里假设我不知道我的家用路由器的MTU, 我想探测出它的值, 然后依次来设置本机的MTU)
在本机打开dos窗口，执行：
ping -f -l 1452 192.168.1.1
其中192.168.1.1是网关IP地址，1452是数据包的长度。请注意，上面的参数是“-l”（小写的L），而不是“-1”。 如果能ping通，表示数据包不需要拆包，可以通过网关发送出去。 如果出现：
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
.....
表示数据包需要拆开来发送。此时，减少数据包长度，再执行上面的ping命令。从1400到1472之间多试几次，就能找到合适的数据包长度了。把数据包长度加上数据包头28字节，就得到MTU的值。 如果检测到网关的MTU值是1500，不需要修改。 如果网关有防火墙ping不通，可以试试直接把MTU设为1400。
C:\Documents and Settings\xxxxx>ping -f -l 1452 192.168.1.1
Pinging 192.168.1.1 with 1452 bytes of data:
Reply from 192.168.1.1: bytes=1452 time=5ms TTL=64
Reply from 192.168.1.1: bytes=1452 time=5ms TTL=64
Reply from 192.168.1.1: bytes=1452 time=5ms TTL=64
Reply from 192.168.1.1: bytes=1452 time=1ms TTL=64
结果出现了回应了！这表示这一个 MTU 值是可行的！不过，强烈建议找出可行的最大 MTU 值！这样一来，在设定的时候，才可以达到最佳的网速！
找出 MTU 值：利用上面这个方法找到的数值还不是 MTU 喔！由于一些封包上面的问题，上面这个值再加上 28 才是我们所需要的 MTU 值！所以，在上面的例子中，我们所需要的 MTU 值是 1464+28=1492！
附注：我设置为1452+28=1480后，还是会出现有些网站打不开、远程桌面无法通过域名登陆的问题（通过ip可以正常远程桌面登陆），而把MTU设置为1452后，反而这些问题都迎刃而解了, ....。
一般来讲，设计好本机的MTU值，可以解决部分网站打不开的情况，但是如果你的共享主机或路由器的MTU设置有问题，有时问题仍然存或，或者出现网速过慢的情况。合理的设置路由器与本机的MTU值，就可以完全解决上述问题，使上网速度达到最大化。
如何修改本机的MTU？修改方法如下：
（1）、运行regedit
（2）、浏览到： HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces
（3）、Interfaces下有多个子项，每个子项对应一个网卡。请按如下方法选择网卡：
（a）确定本机用来连接Internet的网卡或拨号连接的IP，如192.168.0.19；
（b）用鼠标点击Interfaces上的子项，查看键值列表中的IPAddress项；
（c）如果IPAddress的键值与（a）中的IP相同，即192.168.0.19，则该子项就是要找的网卡。
（4）、进入该子项，在右边的窗口里按鼠标右键，选择“新建”->“双字节值”，输入名称“MTU”，按回车。再用鼠标双击“MTU”，弹出修改窗口, 填入MTU的值。填写前请先把基数设为十进制。 设置好后，需要重启机器才能生效。
实践、重启、测试，最后得出最佳的网络状态，探索无极限，努力，终会有好结果。
如何利用tracert确定一个链路上的路由设备的MTU
(请参考别的资料已获得更多信息, 这里的东西 只是介绍性的)
tracert本身是无法检测一个链路上的路由设备的MTU. 但可以很容易地修改traceroute程序，用它来确定路径MTU。(需要有tracert的源代码)。要做的是发送分组，并设置“不分片”标志比特。发送的第一个分组的长度正好与出口MTU相等，每次收到ICMP“不能分片”差错时就减小分组的长度。如果路由器发送的ICMP差错报文是新格式，包含出口的 MTU，那么就用该MTU值来发送，否则就用下一个最小的MTU值来发送。正如RFC 1191 [Mogul and Deering 1990]声明的那样， MTU值的个数是有限的，因此在我们的程序中有一些由近似值构成的表，取下一个最小MTU值来发送。
有人做了、一个实验，多次运行修改以后的traceroute程序，目的端为世界各地的主机。可以到达1 5个国家（包括南极洲），使用了多个跨大西洋和跨太平洋的链路。但是，在这样做之前，其所在子网与路由器n e t b之间的拨号SLIP链路MTU增加到1500，与以太网相同。
在1 8次运行当中，只有其中2次发现的路径MTU小于1500。其中一个跨大西洋的链路MTU值为5 7 2（其近似值甚至在RFC 11 9 1中也没有被列出），而路由器返回的是新格式的ICMP差错报文。另外一条链路，在日本的两个路由器之间，不能处理1500字节的数据帧，并且路由器没有 返回新格式的ICMP差错报文。把MTU值设成1 0 0 6则可以正常工作。
从这个实验可以得出结论，现在许多但不是所有的广域网都可以处理大于5 1 2字节的分组。利用路径MTU发现机制，应用程序就可以充分利用更大的MTU来发送报文。
