主题：【求助】不灵了，请弟兄们帮忙 -- 萨苏
见鹿顶记注解
主要是俺的帖子下见的不多啊。。。
本帖一共被 1 帖 引用 (帖内工具实现)
送朵花试一下
这些天从Interface的duplex设定到Sky-X的Linktest进行的测试已经不下一百个了，问题依然如雾中看花。不过基本可以限定在网络的速度不平衡上，子矜等几位朋友的看法颇有道理。这个我最初是不大以为然的，因为网络方面双方的协议里有SLA,不应该有不平衡的问题，测试的时候带宽也的确达到要求，所以发现不平衡后一直在设备上找原因，现在看来。。。还难说，Vendor在作测试。问题很可能是Packet Loss导致的，确认中。
这场恶战的经验，可否成为萨老添IT那坑的材料呢？
“
...
我盼那盼那
盼东方出红日
...
”
------现代舞剧《白毛女》
老萨好可怜，俺实在是爱莫能助啊
如果PACKET SIZE没问题， 就是PACKET之间的时间差大了， 没有形成TRAIN。
问题可能出在那个加密设备上。 我建议你OFFLINE加密之后，再传送。
老萨的问题如果出在网络上的话，是一个标准的mpls vpn(level2 or level 3)的应用的问题，在用户端是难以解决的，只能碰运气了。这里个关键是用户对中间的TRAFFIC无法施加policy.这几年downturn,估计这种vpn的价格还没下来或根本就没有。。。。。。
有一个ROUTER在一个INTERFACE上overload,老萨一个星期不回家都没用！
从这个“症状”链接出处来看，问题很可能是在Office2(Server）端，而与网络无关。
“（Office2的）ACK MSG，里面的Window Size却在不断变化，从16K到0.3K”就会造成“从Office1向Office2传递的时候，（Throughput）为间断的波峰”。这里需要解释一下TCP Packet里的Window Size代表的是“receive window”，其目的是用于flow control。TCP协议中还有一种window是congestion window，用于congestion control。TCP sender在传送数据时，取两个window的最小值。receive window波动的原因一般和网络（congestion，packet loss）无关，而是由于receiver端的application process consume receive buffer的速度不够快。Packet loss或timeout会造成congestion window的波动，但当receive window只有0.3K的时候，throughput太低的原因基本上可以肯定是receiver端的问题。
我的建议是按以下顺序调查Office2上的：
1、application：这个可能性最大。application如果写的不好的话，无法处理大流量的数据，就会造成这种问题。可以试试在office2上用ftp从office1下载一个大文件，看看是不是还有throughput波动的情况。
2、operating system：这个可能性很小。win2000的tcp/ip协议栈的performance还是不错的，处理20M的流量应该没问题。可以试一试重装一个干净的系统，关掉其他所有不必要的service和application。
3、网卡：实在没办法了就换个网卡试试。
自己机器的网卡的link speed /duplex mode 设为100M Full，人家的设为auto,从人家那里拉东西，就老是纳闷：怎么大家都是用100M端口，局域网传输还这么慢吞吞的。后来把auto那台机改为100M Full就正常了。
老萨已经测试过无数次物理链路了。
1.假设如果物理线路没有问题，问题就在两台服务器上了。
建议：
两个办公室用两台普通工作站替代主机传送数据
前提是：两台工作站性能良好，经过了简单的网络传输测试
1.1如果测试结果表明传输速率正常，那么用替换的方式检测两台主机，找出哪一台主机有问题？
1.2传输速率还不正常
可能ISP的线路有问题,请设法检测路由器端口到ISP之间的线路啦,这个好像有点悬。