调谐窗口进行高延迟/高带宽TCP传输

如何通过芝加哥和伦敦之间的100 mbps链路加速我的Windows 7 tcp文件传输？

现在，我在两个sftp会话中传输两个4GB文件。 每个文件传输以500 KB / s（4 Mbits / sec）的速度运行。 （B ==字节，b ==位，自然）。 这很慢，因为iperftesting显示单个TCPstream的速率为16.8 Mbits / sec。 这是2 MB /秒。

开始第二个sftp会话不会影响第一个iota的速度。 这对我来说是有意义的，因为我注意到我的iperftesting在TCP下是有限的，每个连接都是16 Mbps，为了更多的连接而留下空间。 我能够通过运行许多并行连接来使iperf饱和我的线路，并且这是带宽的线性增长。 也就是说，通过5个并行连接，我实现了大约5×16 == 80 Mbps的带宽。

我注意到使用sftp的本地文件传输大约是30 MB / s …相当好。 所以我不认为SSH通道encryption是瓶颈。

• 什么是用于塑造办公室带宽使用的最好的开源工具？
• 远程屏幕Windows Server 2003的多个实例之间共享。可能吗？
• 带宽*延迟产品
• 测量40Gbe的性能
• 应用程序监视每个程序的带宽使用量

我已经回顾了通过高速，高延迟的广域网链路传输单个大文件的最佳方式是什么？ 以及其他服务器故障的问题，还有很多有趣的工具，但我正在寻找的是一种方式来调整Windows的TCP堆栈，以确保我至less得到我的全部2 MB …也许更多，因为iPerftesting是跨越未经调整的机器。

我也注意到，当我从芝加哥的文件服务器上把一个文件拖放到伦敦机器上时，它似乎在一个相当好的剪辑中传输（如在传输期间查看细节所示），但几分钟后它从悬崖下降到Kbps的10。 这很奇怪。

我的延迟时间稳定在88毫秒左右，所以我认为networking基础设施是好的。 我们有专线; 这不是互联网上的VPN或类似的东西。

========

我有一个Linux虚拟机，“靠近”我的Windows桌面，networking方面。 也就是说，他们在不同的子网上，但是两台机器都进入了交换机，这两台交换机都进入了另一台到伦敦的交换机。 现在我运行一个从Linux到伦敦的sftp，运行速度为8 MB / s，而我的桌面以500 KB / s的速度运行。

========好吧，我将我的Linux笔记本电脑放在与我的桌面完全相同的交换机上。 在这个时候桌面正以500KB / s的速度执行sftp的时候，Linux笔记本正在以7.6MB / s的速度发送4Gig文件。 当然，在伦敦的同一台服务器上。

========另一个testing：我使用的是VanDyke公司的SecureFX。我的PC上也有Cygwin，我只是去了那里使用了CLI sftp命令。 我只是增加了我的吞吐量的五倍…我现在得到2.5 MB / s而不是500k！ ： – \这与我的iPerf 16 Mbps的结果相同。 我会满意的…虽然现在我注意到，我的笔记本电脑是三倍的速度。

========另一个testing：在我的伦敦机器上，我从芝加哥的文件服务器启动了Windows资源pipe理器文件复制到本地安装的Downloads文件夹（即在内部硬盘上）。 吞吐量在12分钟左右稳定在5.49 MB / s。 这足够接近我的罚款！ 而且，通过SecureCRT进行复制的速度非常慢，稳定在500 KB / s。

我唯一可以得出结论的是，虽然可能会有TCP调整，将有所帮助，你使用的应用程序可以有很大的不同！ 此外，我不知道为什么我的文件拷贝前一天performance得如此奇怪。 如果再次发生，我会尝试debugging。

感谢您的build议和答复。

======================

好的，我遵循了托德·威尔科克斯（Todd Wilcox）的链接，想到了一些事情：

• 首先，根据微软的说法，从https://technet.microsoft.com/en-us/library/cc957546.aspx?f=255&MSPPError=-2147217396，“TCP使用接收窗口…对于以太网，默认值这个条目是0x4470（17,520，或每个1460字节12段）“我有一个广域网80毫秒的延迟，所以这是太小了。
• 我已经在registry（后者在我的适配器）中将GlobalMaxTcpWindowSize和TcpWindowSize设置为1 MiB，然后到命令行并使用netsh将接收窗口自动调节级别从正常更改为禁用。 我的networking传输速度没有改变，所以我重新启动了我的机器，并再次执行从我的桌面到伦敦服务器的SFTP。
• 吞吐量骤降至700 KB / s。 不用说，我把所有东西都放回去，重新启动。 现在我的吞吐量回到2.1 MB /秒。
• 在sftp期间，Wireshark显示了一个奇怪的锯齿图案到TCP窗口缩放，从大约64000到62000字节，然后再次备份。 该周期大约需要35秒。
• 假设我的平均窗口大小为63000字节。 因此，我的Bps吞吐量应该是（从http://bradhedlund.com/2008/12/19/how-to-calculate-tcp-throughput-for-long-distance-links/ ），窗口大小（字节）/延迟（秒）== 700 KB /秒。 奇怪，我得到2.1 MB /秒…这比理论更高！ 我确定没有Wan加速器，或者比Cisco 4948更复杂。或许Wireshark的窗口缩放图与窗口大小不一样，我不知道，但是Google使用Google Chrome来告诉我， dfindTCP窗口大小。
• 事情并没有加起来。 虽然我确实发现我的玩笑确实搞砸了，但我不知道如何明确地告诉我的TCP窗口大小是多less。 此外，经常布拉德·赫德伦（Brad Hedlund）的页面给出了一些计算结果，这些并没有反映在我的经验中。
• 最后，这是我所学到的最伟大的教训：我想我会一个人离开。 如果我们发现需要更好的吞吐量，也许我会推荐一个WAN加速器。 但是由于我们正在走向世界的一半，我们不应该期望来自单个TCP连接的惊人的带宽。