缓慢转移距离

从我们的纽约数据中心,转移到更远的地方performance不佳。

使用速度testing来testing不同的位置,我们可以轻松地将我们的100兆上行链路饱和到波士顿和费城。 当我在美国或欧洲西海岸的位置使用速度testing时,我经常只能看到约9兆位/秒。

我的第一反应是,这是一个窗口缩放问题(带宽延迟产品)。 不过,我已经在西海岸的一台testing机器上调整了Linux内核参数,并使用iperf来调整窗口大小,足以支持每秒100兆字节,而且速度仍然很慢(Capture in)。 我也试过禁用Naglealgorithm。

我们从Linux和Windows都得到了糟糕的性能,但是使用Windows的速度却要差一倍(1/3)。

转让(没有Nagle)的形状是: 在这里输入图像描述

十几岁的浸有〜100重复的副本。

随着时间的推移,接收机的最小窗口大小的形状是:

在这里输入图像描述

任何想到下一步要把我们的瓶颈?

一些速度testing结果(使用speedtest.net上传):

  • 费城:44 mbit(使用我们网站的人正在使用其余;-))
  • 迈阿密:15 mbit
  • 达拉斯:14兆位
  • 圣何塞: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 

更新:

用高杰夫深入挖掘,我们发现了一些奇怪的东西。 根据发送端的TCPDump,它通过Internet发送65k数据包。 当我们看着接收端的转储时,他们会像预期的那样到达1448碎片。

这是数据包转储在发件人端看起来的样子: 在这里输入图像描述

然后发生的事情是发送者认为它只是发送64k包,但实际上就接收者而言,它是发送包的突发。 最终的结果是混乱的拥塞控制。 你可以看到这是一个由发送者发送的数据包的包长度图:

在这里输入图像描述

任何人都知道什么可能会导致发件人认为有一个64k MTU? 也许一些/procethtoolifconfig parameter ? ( ifconfig显示MTU是1500)。 我现在最好的猜测是某种硬件加速 – 但我不确定具体是什么。

Subedit 2-2 IV:
只是有一个想法,因为这些64k数据包设置了DF位,也许我的提供商正在分割它们,搞乱了MSS自动发现! 或者,也许我们的防火墙configuration错误…

附加编辑9.73.4 20-60:
我看到64k数据包的原因是因为分段卸载(tso和gso,请参阅ethtool -K)。 关掉这些之后,我看到转移速度没有改善。 形状变化很小,重新传输的是较小的部分: 在这里输入图像描述

我也尝试了Linux上所有不同的拥塞algorithm,没有任何改进。 我的纽约提供商试图上传文件到一个testingFTP服务器或从我们的设施,并获得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 

概观

凯尔,你应该期望看到不同往返时间的单个TCP套接字不同的TCP吞吐量。 一般的TCP吞吐量公式是1

T max = Rcv_Win / RTT

根据观测带宽估算RTT:

RTT = Rcv_Win / Tput

分析

假设所有接收窗口都是64KB(使用窗口缩放),插入吞吐量以估计RTT …

表1.基于观察到的FTP吞吐量估计的RTT与观测的RTT

 +-----------+---------------+---------------+-----------------+ | City | Observed Tput | Estimated RTT | Observed Result | +-----------+---------------+---------------+-----------------+ | Philly | 44Mbps | 11.9ms | ~9ms | +-----------+---------------+---------------+-----------------+ | Miami | 15Mbps | 34.9ms | ~33ms | +-----------+---------------+---------------+-----------------+ | Dallas | 14Mbps | 37.4ms | Unk | +-----------+---------------+---------------+-----------------+ | San Jose | 9Mbps | 58.3ms | ~70ms | +-----------+---------------+---------------+-----------------+ | Berlin | 5Mbps | 104.8ms | ~90ms | +-----------+---------------+---------------+-----------------+ | Sydney | 2.9Mbps | 180.8ms | Unk | +-----------+---------------+---------------+-----------------+ 

如果估计的RTT接近或低于测量的RTT,我们不应该反对。 我们的问题是如果TCP吞吐量较低(由于导出的RTT明显更高)。 我现在看到这个数据的唯一情况是柏林。 即使如此,鉴于你在公共交通海洋链路上看到的典型拥堵,到目前为止,我并没有感到惊慌……也许你可以重新发布剩余站点的详细RTT测量(我将用mtr测量一段时间,而不是traceroute )。

数据包大小

关于从tcpdump看到的64KB IP数据包的问题,​​让我们记住本地链路MTU和IP数据包大小之间的区别。 如果发送主机将大型IP数据包分段,则在1500字节的MTU链路上发送64KB IP数据包是完全合法的2

我会在24小时内结婚,如果我知道自己正在回答SF的问题,而不是准备参加婚礼,那么我的新娘会烤我。 本周末晚些时候我会尽力跟进,但目前我已经没时间了。 我希望这有帮助…

编辑2011-06-13:

还有更多的想法…首先,我错过了你的问题窗口大小的图表,所以感谢你的耐心。 我猜这些数据的情况和条件到目前为止还不清楚。

  • 这个问题谈论iperf,speedtest.net和FTP吞吐量,但像69.241.6.18地址不响应从我的Linux服务器的FTP连接。 您尝试了各种协议和技术是有道理的,但是将细节与连接度量标准的连接技术关联起来,以及在收集更多数据时确定特定的源/目标将变得相关。
  • 在使用iperf ,请注意我在Windows XP下看到了iperf可怜的结果。 其他的ServerFault问题在Windows 7下也提到了类似的问题。我的解决scheme是在有问题的机器上用LiveCD启动到Linux上。突然iperf结果开始变得更有意义,这使我相信这可能是iperf在任何一种Windows核心下,但我不能说更多。 另外,当您testing时,您在每个端点使用哪个iperf开关?
  • 如果FTP是关心的问题,那么你究竟如何以及究竟在testing什么(详细说明使用的源,目的地和客户端/服务器版本)?
  • 每当我过去冲浪到speedtest.net时,他们都用多个并行的TCP套接字来测量, 这与在FTP传输(单个TCP套接字)期间看到的是完全不同的度量。 如果您使用多个TCP套接字进行测量,并且得到的结果远远小于端口速度,这对我来说是一个重要的数据点,因为我对并行套接字(3 – 5并行)的使用经验很容易达到连接,甚至面对path中适度的数据包丢失。
  • 你可以发布更多的细节,从一个mtr跟踪来自每个testing点的结果摘要吗? 也许一个表格显示什么协议/testing技术使用,吞吐量testing结果, mtr数据包丢失, mtr往返响应时间。 mtr测量应在转移发生之前进行。

最后,我在你的问题中看到了一些对防火墙的引用。 我做了“tcp窗口缩放防火墙”的谷歌查询,并发现通过防火墙的TCP窗口扩展吞吐量问题的几个轶事参考; 可悲的是,没有提到缺陷甚至供应商。 也许你可以尝试从防火墙内外运行knoppix或debian livecd的笔记本电脑进行一些FTP传输(所以我们在testing之间获得一致的平台参考)。


END-NOTES:

  1. 参考: TCP吞吐量testing框架 ,第3.3.1节
  2. 有关更多详细信息,请参阅Unix和Linux上的这个问题的末尾注释。

确保TCP窗口足够宽以覆盖带宽延迟产品,这也是我的第一个猜测。 假设configuration正确(并且两端都支持),接下来我将检查一个数据包跟踪,以确保窗口确实处于打开状态,并且path中的一个跃点不会剥离窗口缩放。 如果这一切都很好,而且您确信您不会在path上遇到带宽受限的跳跃,那么导致您的问题的可能原因是随机数据包丢失。 这个假设是由您提到的重复ACK的指示支持的。 (重复的ACK通常是数据丢失的直接结果)。 还要注意的是,对于大带宽延迟产品以及大的开放滑动窗口,即使低水平的随机数据包丢失也会严重影响连接的总吞吐量。

注意:对于通过TCP和多跳WAN连接的批量数据传输,应该没有必要或没有理由禁用Nagle。 事实上,这个确切的情况就是为什么Nagle存在。 一般来说,Nagle只需要在交互式连接中被禁用,在这种交互连接中,需要毫不拖延地排出sub-MTU大小的数据报。 即:对于批量传输,您希望每个数据包中的数据尽可能多。

你调整你的包重新sorting? 在Linux上的/ proc上的tcp_reordering上检查它。 在长pipe道上,通常会产生多path效应,导致错误的丢包检测,重传以及您在图表中发送的速度下降。 它也会导致很多重复的Ack,所以值得检查。 不要忘记,你必须调整pipe道的两侧,以获得良好的效果,并至less使用立方体。 像ftp这样的交互协议可以损害任何tcp,以便进行长pipe道优化。 除非你只是传输大文件。

根据您向各个网站报告的延迟情况,您看到的内容对我来说看起来相当正常。 无论可用带宽如何,延迟都会通过吞吐量几乎任何单一连接而非常迅速地被谋杀。

银峰提供了一个快速和肮脏的估计量的吞吐量,你可以期望看到一个给定的带宽量在给定的延迟水平这里: http : //www.silver-peak.com/calculator/

用适当的延迟插入一个100mbit连接,你会发现你的速度实际上与你应该看到的(大致)匹配。

至于Windows提供比Linux更差的性能,不幸的是,我不能提供任何好的build议。 我认为你正在做相同的硬件(特别是NIC)的苹果对苹果比较?