缓慢转移距离
从我们的纽约数据中心，转移到更远的地方performance不佳。
使用速度testing来testing不同的位置，我们可以轻松地将我们的100兆上行链路饱和到波士顿和费城。 当我在美国或欧洲西海岸的位置使用速度testing时，我经常只能看到约9兆位/秒。
我的第一反应是，这是一个窗口缩放问题（带宽延迟产品）。 不过，我已经在西海岸的一台testing机器上调整了Linux内核参数，并使用iperf来调整窗口大小，足以支持每秒100兆字节，而且速度仍然很慢（Capture in）。 我也试过禁用Naglealgorithm。
我们从Linux和Windows都得到了糟糕的性能，但是使用Windows的速度却要差一倍（1/3）。
- 从Ubuntu恢复启动networking连接？
- 使用Nmap查找打印机
- 是否有可能判断两个IP地址是否属于同一台服务器？
- 为什么ICMPredirect主机发生？
- 升级到千兆networking – 启用巨帧
转让（没有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？ 也许一些/proc ， ethtool或ifconfig 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：
- 参考： TCP吞吐量testing框架 ，第3.3.1节
- 有关更多详细信息，请参阅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）的苹果对苹果比较？