主题：【求助】不灵了，请弟兄们帮忙 -- 萨苏

记得TCP的拥塞控制机制里当拥塞发生（包被丢弃）的时候，传输窗口减半，拥塞停止就一点点增加到最大窗口限制。不过如果来回路由的TCP连接数，路由长短等条件一样的话流量应该不会相差这么大吧。会不会是Office1向Office2的路由上有拥塞？

office2的host弱了一点,win的网络性能不算很好.对大容量传输请求,是不是有些请求 来不及回应? 发送端为了同步,也只好等.

office2可能换一个系统接收么?

Windows size不断变化就是终端在响应中间路由器或者对方要求降低传输速度的要求阿.

在TCP协议中, 中间路由器或者对方在发现流量过大, 需要降低的时候, 往往就会采取一些方法, 比如将某些packet drop 掉, 这样发送方没有收到ACK 就会减小窗口大小, 当窗口变小, 发送方发现传送的东西又都得到顺利的 Ack的时候, 就又会增加窗口大小, 这就是TCP基本的动态流量控制手段.

你用的不是专线, 中间的路由器就把你的Package 当作和其他人的数据一个级别的东西, 当某个方向上流量大的时候, 自然就可能会drop掉你的一些数据宝, 这样就启动发送方的流量控制机制, 所以你看到的流量也是锯齿形.

TCP本身是为Best effort Traffic 设计的, 因为这个原因, TCP是不适合用来进行图像, 话音等需 Constant Bit Rate 的实时通信的.

恐怕问题的根本原因还是中间路由器过于拥赛.

业务部门因为安全要求也拒绝离线传送数据

暂时恐怕换还不太容易，不过如果真是它的表现问题，我就不用操心了。

手头倒是有懂Sky-X的，一直觉得挺有前途的产品，卖了给Packeteer可惜，我们这个懂行的现在还在和Sky-X的供货商联系，如果有个小鱼（和鱼玄机无关），大体就是他了。

如此说来是接收数据的Server发出ACK后，得不到所等待的数据，因此再次发出Window Size减半的ACK？周一上班后会和负责的工程师谈一下这个思路。

也就是说office1发送请求后，发现拥塞因此重新发window size减半的请求，而office2的Server的ACK便也相应出现Window Size的变化，被我们的Sniffer观察到，这样判断是否正确呢？

应该是发送数据的office1发出数据包之后，在TIMEOUT期间内没有接到由office2返回的ACK包（可能是由于中间某路由器由于拥塞－buffer满－将数据包丢弃了），于是发送端将自己的传输窗口减半以进行流量控制。虽然说数据包丢失或者ACK包丢失都可能造成这种情况，一般由于ACK包占用流量很小，应该是由于数据包被丢弃造成了。

以前溜过一眼TCP记得好像是这样的，具体描述可见http://www.faqs.org/rfcs/rfc2581.html(主要是3.1部分）。Good luck!!

我是做防火墙的，东西大概和你“挨踢”里的东西原理上差不多。类似的情况可能的原因太多，一般会按实现的难易程度用排除法确定故障点再进行下一步（对于我们来讲防火墙是单点出口，忒容易背雷）。

我感觉上排除的顺序如下：

1.在office1上开一个server（比如ftp），从office2的PC上upload文件，看传输速度，如果速度一样慢就没host和应用系统什么事儿了。剩下就是线路和线路上设备的事儿了。

2.分别关上3个firewall的filter，试试对upload文件速度的影响，如果网管不好说话，也可以把server和PC放在防火墙前面，这样IP地址改来改去比较麻烦。firewall的filter有时会惹麻烦。

3.分别把server和PC放在SPY/X前面，看SPY/X对速度的影响。不知道SPY/X是不是透明传输，如果是就连根线短过SPY/X就行了。

4.如果上面的都对速度没影响，问题就在CISCO3845和中间的线路上了，可以试试CISCO3845上的VPN设置成只传输不加密upload文件等等，IPsec出问题也是常事儿。最直接的方法就是关掉CISCO3845上的VPN，server和PC都直接设置成公用IP，upload文件，如果还是有问题，那铁定是ISP的问题；如果没问题，就找CISCO工程师吧。

以上步骤的顺序可以任意组合，看哪个好实现了。office2有个愿意合作的IT是关键

我那朋友说他主要做软件方面，不是很懂网络，估计跟您用的SERVER有关，如果是单向传输缓慢，可能是FRAME SIZE不稳定，看能否将它设置为比如说20K。。卖糕的，我根本不懂他说些什么。。对不起啦

买暗光纤吧！ 如果钱够多。 不然就只有自己重写TCP了， 就这样都不一定管用。

不知道明年， 新技术出来，还来得急吗 。

这是正常的。 PACKET 会SYNCHRONIZE。 估计ISP有自己的密秘调度算法。

TCP ACK里的窗口大小描述的是接受端缓存还剩多少空间。有几个原因可以造成这个尺寸变小。

一是丢包，也就是说如果一个包丢了，后续收到的包要存在缓存里面，直到收到丢的包（重发）后才一起传给应用程序。这样的ACK包里，一般序列数字不变，只是窗口变小。不过这样的窗口尺寸变化应该很快，一两个回程时间之后就会恢复。如果又有丢包，也可以从窗口尺寸变化的大小和快慢分析出来。仔细分析一个波峰周期内的ACK内容就可以看出来丢包情况。

还有一个可能就是接受端（ｗｉｎ２０００ｓｅｒｖｅｒ）应用程序从网络内核取数据太慢，跟不上网卡接收速度。有的机器上网络接收扫描之类的保护也可能造成类似问题。换台机器，关掉网络保护试试。

另外有的ｖｐｎ路由可能会篡改客户ｔｃｐ窗口尺寸，不过这种可能性不太大。

我想这类问题我有一点类似的经历，不过我们的规模小的多。这种问题一般还是出在应用上，估计something is wrong with windows application server. What application are you running on Windows? FTP server or something else (sshd?)? What client are you running on office1 (rcp,scp or rsync?). These issues may be critical.