我们有两台服务器，它们位于不同的数据中心，地理位置相隔数百英里。通过我们的 VPN，它们之间的 ping 往返时间 (RTT) 为 61 毫秒。两台服务器均位于千兆 WAN 链路上。
任何类型的文件复制，无论是 SMB（拖放）、FTP（尝试过 FileZilla、TFTP 等）都非常慢，大约 1 Mbps。我尝试启用和禁用接收窗口自动调整级别、多线程复制等。我们的防火墙有大量 CPU 余量，因此 VPN 加密不起作用。
我考虑过手动设置 TCP 窗口大小，因为它在这里似乎是一个明显的候选者，但我的理解是 Windows Server 2008 R2 会忽略注册表中的任何自定义 TcpWindowSize 设置。
更新：TCP 窗口大小似乎没问题。Wireshark 显示窗口大小为 513，窗口大小缩放因子为 256，计算窗口大小为 131328。这听起来对吗？在正在进行的 FTP 传输期间，传输中的字节数保持在 9000 字节左右。
答案1
用简单的运行来打击他们
netcat——在另一端丢弃的随机数据流。我知道某个地方有一个 Windows 版本。用它作为基准。如果不能全速运行，请嗅探您的连接并重试。查找数据包丢失、无序接收、错误校验和等。
隔离问题。
netcat在两个网络内部运行。从边界运行，替换路由器。继续，直到您知道问题出在哪里，或者您可以告诉您的 ISP 问题出在站点之间的链接中，并详细说明问题如何出现。
答案2
需要考虑的一件事是，许多此类传输都非常繁琐。这意味着文件传输需要大量的来回沟通。我们也遇到了同样的问题，发现更大的管道并没有帮助，因为开销太大了。
没有办法让所有这些通信都比光速更快，而且由于往返次数太多，更大的管道通常没有帮助。您可能需要查看 WAN 加速器。对于我们在多个城市的站点上使用 SharePoint 和 CRM 的问题，差异是惊人的。
我并不是在推荐某个特定的产品，而只是推荐一个可以查找技术信息的地方。我们查看了许多不同的产品，最终选择了 Riverbed Steelhead 设备。我们在三个站点安装了试用设备，帮助台电话几乎立即停止了。使用基于 Web 的 GUI 可以轻松看到差异，并且对于 SharePoint 的 Web 流量，我们将流量减少了高达 90%，因此我们提高了速度并减少了流量，从而降低了成本。由于我们甚至无法在多个站点获得更快的连接，因此这是一个很好的解决方案。
Riverbed 建议加速 5-50 倍，我们在某些情况下超过了这个数字。他们有大量关于您遇到的问题的技术信息，我认为这些信息比我在这里提供的帮助更大 河床虹鳟
答案3
这是日志记录。关闭服务器上的所有日志记录。每个数据包都会写入驱动器，这会降低传输速度。