主题：【求助】不灵了，请弟兄们帮忙 -- 萨苏
我一直在关注这个帖子,正如几位大虾所说的，我也认为多半是TCP协议的差错控制或拥塞控制机制在跨越多传输链路路经时造成的问题。我不熟悉SKY-X加速器的工作原理，上网查了查没有详细说明，不过既然说是针对高延时卫星链路起到加速作用，想来应该是类似增加滑动窗口的大小，使用大量硬件缓冲自动控制重传。如果发生频繁的重传肯定会是这样。我个人觉得萨兄这个方案大概要推翻了。
1.图中的数据,是Sky-X到Host这一段的呢,还是到Internet这一段的? 如果是前者,只能想出一种解释,就是发送端TCP出错,否则锯齿的高度应当逐个减半.
2. 两个Host之间虽然时延大,但都是有线,随机丢包率应该不大,TCP应当能充分利用带宽,是不是可以考虑不用Sky-X? 或者去掉Sky-X再测一下现象,也能帮助分析故障原因.
英文原名是《TCP Tuning and Network Troubleshooting Speed up your file transfers by 100X》
文章主旨是说Tcp发送方和接受方的Buffer size会极大的影响文件传输效率。过大，过小都会影响传输效率。最佳优化值要fine tune。譬如说，推荐的经验公式是：
buffer size = RTT * bandwidth
文章的Link是：
希望能有一点点帮助！
先用上再慢慢调。澳洲那边还是很落后的，高手不多，一时指望不上。
俺看不懂那些专业的东东，只看懂了上行是23M，下行只有3M。
俺用ADSL上网，下载/上传比为5：1。
以前用小猫上网，下行/上行比为10：1。
Down片时，用FTP，对方经常限速。
俺要说的是，老大不妨从这里想一想法子。
压缩以后还要7.6GB每小时！
您说要命不要？
更换了新的服务器，并且纠正了网络上的Flow Control设置的一个错误，经过测试，从Sky-X到Sky-X的速度已经超过40MBps（通过在Sky-X两端加PC，用iperf测试结果）
对比一下，现在是一条比较光滑的传输曲线了，而且没有Window 0的重传信号。
但是端到端的数据传送，依然被压在4M以下，什么原因呢？在检查服务器的IO Buffer和Swapping设置，不过不太相信这是问题根源，因为曾经停掉除我们在测试的内容外所有对服务器通讯，结果依然如故。
依然在测试中，并期待大家的帮助。
没懂。你说的40兆已经是在sky-x后面端对端了吗？那应该已经很好办了啊，一个一个地上防火墙啊！
我兄弟是防火墙专家，可惜现在找不着他（刚搬到新地方上班）。平时和他闲聊，他提到过业界某些firewall有很严重的性能问题。如果是防病毒的一块在防火樯上，可能性就很大了。
谢谢您的协助，实际上我们现在也在和防火墙较劲儿，起了疑心。。。
说的出来的防火墙也就那几个啊。不过说实话但凡是防火墙开内容过滤的性能都好不到哪去。
防火墙策略，端口状态，load之类的。
另外IP有经过映射吗？
因为我们一直通过Sky-X的Monitor窗口判断使用带宽，现在我们怀疑它在发送端和接受端的表示可能是不同的！
因为在发送端，Monitor窗口的带宽使用率为12-13MBPS的时候，linkstat的结果只有3-4Mbps，同时Skyxstat的结果倒是和窗口接近。
由于我们无法接入对端的Sky-X监视窗口，这下子可让我们无法证实又满腹狐疑起来。。。
请你把最后一行删了。