远距离传输慢

19

从我们的纽约数据中心传输到较远的位置的性能很差。

使用速度测试来测试各个位置，我们可以轻松地使到波士顿和费城的100 Mbps上行链路饱和。当我使用速度测试到美国或欧洲的西海岸进行定位时，我通常只会看到大约9 Mbps。

我的第一反应是这是一个窗口缩放问题（带宽延迟乘积）。但是，我已经在西海岸的一台测试机上调整了Linux内核参数，并使用iperf，使Window的大小足以支持每秒100 MB，但速度仍然很慢（已在Capture中验证）。我也尝试过禁用Nagle算法。

Linux和Windows的性能都差，但是使用Windows的速度却差得多（1/3）。

传输的形状（没有Nagle）为：在此处输入图片说明

10秒钟左右的浸入有大约100个重复的插口。

接收器的最小窗口大小随时间变化的形状为：

在此处输入图片说明

有什么想法可以解决瓶颈吗？

一些速度测试结果（使用speedtest.net上传）：

  • 费城：44兆比特（使用我们网站的人正在使用其余的;-)）
  • 迈阿密：15兆位
  • 达拉斯：14兆位
  • 圣何塞：9兆位
  • 柏林：5兆位
  • 悉尼：2.9兆位

更多数据：
迈阿密：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一起深入研究这一点，我们发现了一些奇怪的东西。根据发送方的 TCPDump，它通过Internet将数据包作为65k数据包发送。当我们查看接收方的转储时，它们到达的碎片是1448，正如您所期望的那样。

这是数据包转储在发送方的样子：在此处输入图片说明

然后发生的事情是，发送方认为它只是在发送64k数据包，但实际上，就接收方而言，它正在发送数据包突发。最终结果是混乱的拥塞控制。您可以看到以下是发送方正在发送的数据包的数据包长度的图表：

在此处输入图片说明

有人知道导致发送方认为存在64k MTU的原因吗？也许一些/proc，ethtool或者ifconfig parameter？（ifconfig显示MTU为1500）。我目前的最佳猜测是某种形式的硬件加速-但我不确定具体是什么。

Subedit 2-2 IV：
刚想到，由于这64k数据包设置了DF位，也许我的提供者无论如何都要对其进行分段，并弄乱了MSS自动发现！也许我们的防火墙配置错误...

辅助编辑9.73.4 20-60：
之所以看到64k数据包，是因为分段卸载（tso和gso，请参见ethtool -K）处于打开状态。关闭这些功能后，我发现传输速度没有任何改善。形状略有变化，并且重新传输的片段较小：在此处输入图片说明

我也尝试了Linux上所有不同的拥塞算法，但没有任何改进。我的纽约供应商尝试将文件从我们所在的设施上载到OR中的测试ftp服务器，并且速度提高了3倍。

要求的从纽约到俄勒冈州的地铁报告：

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
networking  tcp 
— 凯尔·勃兰特（Kyle Brandt）
source
Windows 2008 r2下您的性能不佳吗？
— Jim B
Windows 2008 R2比Linux差，但是使用Linux我仍然只能拉20-30mbit。我尝试了各种Windows调整，尤其是围绕影响窗口缩放的内容进行了调整。但是我的理论是，连接很烂，而Linux可以更好地处理该糟糕的连接。
— 凯尔·布​​兰特
2
我的第一个猜测是您所在位置和西海岸/欧洲之间的ISP上的一条路由缓慢/缓慢。
— 至强
1
由于对于性能较差的区域，AS路径有所不同，因此沿途似乎并不是上游。
— 凯尔·布​​兰特
1
如果使用UDP不能获得很好的结果，那么TCP肯定无济于事（当然，请确保您可以运行以本地速度与UDP链接，否则您的iperf测试硬件可能有缺陷）。
— 杰德·丹尼尔斯

Answers:

5

确保TCP窗口打开得足够宽以覆盖带宽延迟乘积，这也是我的第一个猜测。假设配置正确（并得到两端的支持），我接下来将检查数据包跟踪，以确保窗口确实正在打开，并且路径中的跳数不会剥离窗口缩放。如果这一切都很好，并且可以确定您未在路径中陷入带宽受限的跃点，则可能是随机数据包丢失导致了问题。您提到的重复ACK的指示支持此假设。（重复的ACK通常是丢失数据的直接结果）。另请注意，由于带宽延迟乘积较大，因此滑动窗口较大，

旁注：对于通过TCP和多跳WAN连接进行的批量数据传输，应该没有必要或没有理由禁用Nagle。实际上，确切的场景就是Nagle存在的原因。通常，仅需要对交互式连接禁用Nagle，在这种情况下，必须强制释放小于MTU大小的数据报，而不会产生任何延迟。即：对于批量传输，您希望每个数据包中的数据尽可能多。

— 高杰夫
source
1

您是否调整了包裹重新排序的阈值？在Linux上的/ proc的tcp_reordering上检查它。在长管道上，常见的多路径效应会导致错误的丢包检测，重传以及您在图表中发送的速度下降。它也会导致很多重复的Acks，因此值得检查。别忘了，您必须调整管道的两侧，以获得良好的结果并至少使用立方。诸如ftp这样的交互式协议可能会损害任何tcp，以实现您可以进行的长管道优化。除非您仅传输大文件。

— ene
source
-2

根据您向各个站点报告的延迟，您看到的内容对我来说似乎很正常。延迟几乎可以通过吞吐几乎所有单个连接（无论可用带宽如何）通过吞噬能力。

Silver Peak为您提供了一个快速而又肮脏的估计器，您可以在这里看到给定带宽的给定延迟水平下的吞吐量：http : //www.silver-peak.com/calculator/

插入具有适当延迟的100mbit连接，您会发现速度实际上与预期的速度（大约）匹配。

至于Windows提供的性能不如Linux，不幸的是，我在这里无法提供任何好的建议。我假设您正在使用相同的硬件（特别是网卡）进行一次苹果对苹果的比较？

— 莱恩
source
1
我不明白，如果有足够大的窗口来容纳带宽延迟乘积，那么延迟会随时间影响吞吐量。
— 凯尔·布​​兰特
当使用单个连接进行操作时，这只是野兽的本性。如果您启动到同一目标的多个同时连接，则只要两端有足够的带宽，只要有足够的并发连接，就可以填充带宽。阅读routerjockey.com/2009/05/07/how-does-latency-effect-throughput
— Layn 2011年
2
@Layn：该链接中的公式是如何计算带宽延迟乘积。给定足够大的窗口大小就没关系了。从东到西的TCP连接没有第二个9mbit的硬限制-这太愚蠢了。
— 凯尔·布​​兰特
1
@Layn：您真的应该用一点科学（或数据...）来备份这样的语句。我向你保证你错了。我们在世界各地都设有办事处，我们可以持续做得比您举例说明的要好。我刚刚从蒙特利尔到布宜诺斯艾利斯（延迟为145毫秒）进行了28.8 mbps的scp测试。
— DictatorBob
2
@Layn：无论延迟如何，您都应该能够非常接近使用UDP饱和100Mbps的链接，因此您的论点并不会真正解决。
— Jed Daniels
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.