从我们的纽约数据中心到较远地点的传输性能不佳。
使用速度测试测试各个位置，我们可以轻松地使到波士顿和费城的 100 mbit 上行链路饱和。当我使用速度测试测试美国西海岸或欧洲的位置时，我经常只看到大约 9 mbit/s。
我的第一反应是这是一个窗口缩放问题（带宽延迟积）。但是，我已经在西海岸的一台测试机上调整了 Linux 内核参数，并使用 iperf 直到窗口大小足以支持每秒 100 兆字节，但速度仍然很慢（已在 Capture 中验证）。我还尝试禁用 Nagle 算法。
Linux 和 Windows 的性能都较差，但使用 Windows 的速度明显更差（只有 1/3）。
转移的形状（没有 Nagle）是：
10 秒左右的 Dip 有大约 100 个重复确认。
接收器的最小窗口大小随时间的变化形状为：
关于下一步该怎么做才能解决瓶颈，您有什么想法吗？
一些速度测试结果（使用speedtest.net上传）：
- 费城：44 mbit（使用我们网站的人们正在使用其余部分 ;-) ）
- 迈阿密：15 mbit
- 达拉斯：14 mbit
- 圣何塞：9 mbit
- 柏林：5 mbit
- 悉尼：2.9 mbit
更多数据：
迈阿密：69.241.6.18
2 stackoverflow-nyc-gw.peer1.net (64.34.41.57) 0.579 ms 0.588 ms 0.594 ms
3 gig4-0.nyc-gsr-d.peer1.net (216.187.123.6) 0.562 ms 0.569 ms 0.565 ms
4 xe-7-2-0.edge1.newyork1.level3.net (4.78.132.65) 0.634 ms 0.640 ms 0.637 ms
5 vlan79.csw2.newyork1.level3.net (4.68.16.126) 4.120 ms 4.126 ms vlan89.csw3.newyork1.level3.net (4.68.16.190) 0.673 ms
6 ae-81-81.ebr1.newyork1.level3.net (4.69.134.73) 1.236 ms ae-91-91.ebr1.newyork1.level3.net (4.69.134.77) 0.956 ms ae-81-81.ebr1.newyork1.level3.net (4.69.134.73) 0.600 ms
7 ae-10-10.ebr2.washington12.level3.net (4.69.148.50) 6.059 ms 6.029 ms 6.661 ms
8 ae-1-100.ebr1.washington12.level3.net (4.69.143.213) 6.084 ms 6.056 ms 6.065 ms
9 ae-6-6.ebr1.atlanta2.level3.net (4.69.148.105) 17.810 ms 17.818 ms 17.972 ms
10 ae-1-100.ebr2.atlanta2.level3.net (4.69.132.34) 18.014 ms 18.022 ms 18.661 ms
11 ae-2-2.ebr2.miami1.level3.net (4.69.140.141) 40.351 ms 40.346 ms 40.321 ms
12 ae-2-52.edge2.miami1.level3.net (4.69.138.102) 31.922 ms 31.632 ms 31.628 ms
13 comcast-ip.edge2.miami1.level3.net (63.209.150.98) 32.305 ms 32.293 ms comcast-ip.edge2.miami1.level3.net (64.156.8.10) 32.580 ms
14 pos-0-13-0-0-ar03.northdade.fl.pompano.comcast.net (68.86.90.230) 32.172 ms 32.279 ms 32.276 ms
15 te-8-4-ur01.northdade.fl.pompano.comcast.net (68.85.127.130) 32.244 ms 32.539 ms 32.148 ms
16 te-8-1-ur02.northdade.fl.pompano.comcast.net (68.86.165.42) 32.478 ms 32.456 ms 32.459 ms
17 te-9-3-ur05.northdade.fl.pompano.comcast.net (68.86.165.46) 32.409 ms 32.390 ms 32.544 ms
18 te-5-3-ur01.pompanobeach.fl.pompano.comcast.net (68.86.165.198) 33.938 ms 33.775 ms 34.430 ms
19 te-5-3-ur01.pompanobeach.fl.pompano.comcast.net (68.86.165.198) 32.896 ms !X * *
69.241.6.0/23 *[BGP/170] 1d 00:55:07, MED 3241, localpref 61, from 216.187.115.12
AS path: 3356 7922 7922 7922 20214 I
> to 216.187.115.166 via xe-0/0/0.0
圣何塞：208.79.45.81
2 stackoverflow-nyc-gw.peer1.net (64.34.41.57) 0.477 ms 0.549 ms 0.547 ms
3 gig4-0.nyc-gsr-d.peer1.net (216.187.123.6) 0.543 ms 0.586 ms 0.636 ms
4 xe-7-2-0.edge1.newyork1.level3.net (4.78.132.65) 0.518 ms 0.569 ms 0.566 ms
5 vlan89.csw3.newyork1.level3.net (4.68.16.190) 0.620 ms vlan99.csw4.newyork1.level3.net (4.68.16.254) 9.275 ms vlan89.csw3.newyork1.level3.net (4.68.16.190) 0.759 ms
6 ae-62-62.ebr2.newyork1.level3.net (4.69.148.33) 1.848 ms 1.189 ms ae-82-82.ebr2.newyork1.level3.net (4.69.148.41) 1.011 ms
7 ae-2-2.ebr4.sanjose1.level3.net (4.69.135.185) 69.942 ms 68.918 ms 69.451 ms
8 ae-81-81.csw3.sanjose1.level3.net (4.69.153.10) 69.281 ms ae-91-91.csw4.sanjose1.level3.net (4.69.153.14) 69.147 ms ae-81-81.csw3.sanjose1.level3.net (4.69.153.10) 69.495 ms
9 ae-23-70.car3.sanjose1.level3.net (4.69.152.69) 69.863 ms ae-13-60.car3.sanjose1.level3.net (4.69.152.5) 69.860 ms ae-43-90.car3.sanjose1.level3.net (4.69.152.197) 69.661 ms
10 smugmug-inc.car3.sanjose1.level3.net (4.71.112.10) 73.298 ms 73.290 ms 73.274 ms
11 speedtest.smugmug.net (208.79.45.81) 70.055 ms 70.038 ms 70.205 ms
208.79.44.0/22 *[BGP/170] 4w0d 08:03:46, MED 0, localpref 59, from 216.187.115.12
AS path: 3356 11266 I
> to 216.187.115.166 via xe-0/0/0.0
费城：68.87.64.49
2 stackoverflow-nyc-gw.peer1.net (64.34.41.57) 0.578 ms 0.576 ms 0.570 ms
3 gig4-0.nyc-gsr-d.peer1.net (216.187.123.6) 0.615 ms 0.613 ms 0.602 ms
4 xe-7-2-0.edge1.newyork1.level3.net (4.78.132.65) 0.584 ms 0.580 ms 0.574 ms
5 vlan79.csw2.newyork1.level3.net (4.68.16.126) 0.817 ms vlan69.csw1.newyork1.level3.net (4.68.16.62) 9.518 ms vlan89.csw3.newyork1.level3.net (4.68.16.190) 9.712 ms
6 ae-91-91.ebr1.newyork1.level3.net (4.69.134.77) 0.939 ms ae-61-61.ebr1.newyork1.level3.net (4.69.134.65) 1.064 ms ae-81-81.ebr1.newyork1.level3.net (4.69.134.73) 1.075 ms
7 ae-6-6.ebr2.newyork2.level3.net (4.69.141.22) 0.941 ms 1.298 ms 0.907 ms
8 * * *
9 comcast-ip.edge1.newyork2.level3.net (4.71.186.14) 3.187 ms comcast-ip.edge1.newyork2.level3.net (4.71.186.34) 2.036 ms comcast-ip.edge1.newyork2.level3.net (4.71.186.2) 2.682 ms
10 te-4-3-ar01.philadelphia.pa.bo.comcast.net (68.86.91.162) 3.507 ms 3.716 ms 3.716 ms
11 te-9-4-ar01.ndceast.pa.bo.comcast.net (68.86.228.2) 7.700 ms 7.884 ms 7.727 ms
12 te-4-1-ur03.ndceast.pa.bo.comcast.net (68.86.134.29) 8.378 ms 8.185 ms 9.040 ms
68.80.0.0/13 *[BGP/170] 4w0d 08:48:29, MED 200, localpref 61, from 216.187.115.12
AS path: 3356 7922 7922 7922 I
> to 216.187.115.166 via xe-0/0/0.0
柏林：194.29.226.25
2 stackoverflow-nyc-gw.peer1.net (64.34.41.57) 0.483 ms 0.480 ms 0.537 ms
3 oc48-po2-0.nyc-telx-dis-2.peer1.net (216.187.115.133) 0.532 ms 0.535 ms 0.530 ms
4 oc48-so2-0-0.ldn-teleh-dis-1.peer1.net (216.187.115.226) 68.550 ms 68.614 ms 68.610 ms
5 linx1.lon-2.uk.lambdanet.net (195.66.224.99) 81.481 ms 81.463 ms 81.737 ms
6 dus-1-pos700.de.lambdanet.net (82.197.136.17) 80.767 ms 81.179 ms 80.671 ms
7 han-1-eth020.de.lambdanet.net (217.71.96.77) 97.164 ms 97.288 ms 97.270 ms
8 ber-1-eth020.de.lambdanet.net (217.71.96.153) 89.488 ms 89.462 ms 89.477 ms
9 ipb-ber.de.lambdanet.net (217.71.97.82) 104.328 ms 104.178 ms 104.176 ms
10 vl506.cs22.b1.ipberlin.com (91.102.8.4) 90.556 ms 90.564 ms 90.553 ms
11 cic.ipb.de (194.29.226.25) 90.098 ms 90.233 ms 90.106 ms
194.29.224.0/19 *[BGP/170] 3d 23:14:47, MED 0, localpref 69, from 216.187.115.15
AS path: 13237 20647 I
> to 216.187.115.182 via xe-0/1/0.999
更新：
与 Tall Jeff 一起深入研究这个问题后，我们发现了一些奇怪的事情。根据发件人的它将数据包作为 65k 数据包发送通过互联网。当我们查看接收方的转储时，它们到达的碎片为 1448，正如您所期望的那样。
发送方转储的数据包如下：
然后发生的事情是，发送方认为它只是发送了 64k 个数据包，但实际上就接收方而言，它正在发送大量数据包。最终结果是拥塞控制混乱。您可以看到这是发送方发送的数据包的数据包长度图：
有人知道什么可能导致发送方认为 MTU 为 64k 吗？可能是某些/proc，ethtool或者ifconfig parameter？（ifconfig显示 MTU 为 1500）。我现在最好的猜测是某种硬件加速——但我不确定具体是什么。
子编辑 2-2 IV：
我刚刚想到，既然这些 64k 数据包设置了 DF 位，也许我的提供商正在对它们进行分段，并扰乱 MSS 自动发现！或者我们的防火墙配置错误……
附加编辑 9.73.4 20-60：
我之所以看到 64k 数据包，是因为段卸载（tso 和 gso，参见 ethtool -K）已打开。关闭这些后，我看不到传输速度有任何改善。形状略有变化，重新传输的段更小：
我也尝试了 Linux 上的所有不同拥塞算法，但没有任何改善。我的纽约提供商尝试从我们所在的设施将文件上传到 OR 中的测试 FTP 服务器，速度提高了 3 倍。
请求的从 NY 到 OR 的 MTR 报告：
root@ny-rt01:~# mtr haproxy2.stackoverflow.com -i.05 -s 1400 -c 500 -r
HOST: ny-rt01.ny.stackoverflow.co Loss% Snt Last Avg Best Wrst StDev
1. stackoverflow-nyc-gw.peer1.n 0.0% 500 0.6 0.6 0.5 18.1 0.9
2. gig4-0.nyc-gsr-d.peer1.net 0.0% 500 0.6 0.6 0.5 14.8 0.8
3. 10ge.xe-0-0-0.nyc-telx-dis-1 0.0% 500 0.7 3.5 0.5 99.7 11.3
4. nyiix.he.net 0.0% 500 8.5 3.5 0.7 20.8 3.9
5. 10gigabitethernet1-1.core1.n 0.0% 500 2.3 3.5 0.8 23.5 3.8
6. 10gigabitethernet8-3.core1.c 0.0% 500 20.1 22.4 20.1 37.5 3.6
7. 10gigabitethernet3-2.core1.d 0.2% 500 72.2 72.5 72.1 84.4 1.5
8. 10gigabitethernet3-4.core1.s 0.2% 500 72.2 72.6 72.1 92.3 1.9
9. 10gigabitethernet1-2.core1.p 0.4% 500 76.2 78.5 76.0 100.2 3.6
10. peak-internet-llc.gigabiteth 0.4% 500 76.3 77.1 76.1 118.0 3.6
11. ge-0-0-2-cvo-br1.peak.org 0.4% 500 79.5 80.4 79.0 122.9 3.6
12. ge-1-0-0-cvo-core2.peak.org 0.4% 500 83.2 82.7 79.8 104.1 3.2
13. vlan5-cvo-colo2.peak.org 0.4% 500 82.3 81.7 79.8 106.2 2.9
14. peak-colo-196-222.peak.org 0.4% 499 80.1 81.0 79.7 117.6 3.3
答案1
确保 TCP 窗口打开得足够宽以覆盖带宽延迟积也是我的第一猜测。假设配置正确（并且两端都支持），我接下来将检查数据包跟踪以确保窗口确实打开，并且路径中的某个跳跃没有剥离窗口缩放。如果一切正常，并且您确定没有遇到路径中带宽受限的跳跃，则导致问题的可能原因是随机数据包丢失。您提到的重复 ACK 指示支持此假设。（重复 ACK 通常是数据丢失的直接结果）。另请注意，由于带宽延迟积较大，因此打开的滑动窗口较大，即使是低水平的随机数据包丢失也会严重影响连接的总吞吐量。
附注：对于通过 TCP 和多跳 WAN 连接进行的批量数据传输，应该没有必要或理由禁用 Nagle。事实上，正是这种情况导致了 Nagle 的存在。通常，只有在需要强制输出子 MTU 大小的数据报且不产生任何延迟的交互式连接中才需要禁用 Nagle。即：对于批量传输，您希望每个数据包中包含尽可能多的数据。
答案2
您是否调整了数据包重新排序阈值？在 Linux 上的 /proc 上检查 tcp_reordering。在长管道上，多路径效应通常会导致错误的数据包丢失检测、重新传输以及您在图表中发送的速度下降。它还会导致大量重复的 Ack，因此值得检查。不要忘记您必须调整管道的两侧才能获得良好的结果，并且至少使用立方。交互式协议（如 ftp）可能会损害您可以执行的任何 tcp 长管道优化。除非您只传输大文件。
答案3
根据您向各个站点报告的延迟情况，您看到的情况在我看来很正常。延迟会很快毁掉几乎任何单个连接的吞吐量，无论可用带宽是多少。
Silver Peak 提供了一个快速而粗略的估算器，用于估算在给定带宽和给定延迟水平下您可以看到的吞吐量：http://www.silver-peak.com/calculator/
插入具有适当延迟的 100mbit 连接，您会发现您的速度实际上与您期望的速度（大约）相匹配。
至于 Windows 的性能是否比 Linux 差，很遗憾，我无法提供任何好的建议。我猜你是在对相同硬件（特别是 NIC）进行同类比较吧？