我想弄清楚为什么我控制的两台主机之间的TCP / IP吞吐量远低于预期。
主机A：波士顿地铁Comcast（Residential）提供的互联网连接 – 可以持续实现从各种知名网站下载100Mbps（例如下载Google Chrome）
主持人B：Cogent提供的互联网连接; 可以始终如一地在各个站点达到近100Mbps。
testing连接：主机A通过非标准端口（22442）上的rsync / ssh从B下载大文件（即rsync --progress -e 'ssh -p 22442' ... – 吞吐量仅为2.5Mbps （292564 Bps）
当尝试从B下载相同的数据时，其他客户端（例如临时EC2实例）的吞吐量可能会达到近30倍
我已经设法捕获与Tcptrace之间的连接（下面附加）的统计数据，但我不知道是否有什么似乎错了。
我想我的目的是需要调整一下，但是我也对Comcast塑造stream量有所怀疑 – 所以在我开始讨论之前，我想我会寻求build议。 我有什么好的下一步尝试？ 提前致谢。
tcptrace -r -l -o1 dump.out 1 arg remaining, starting with 'dump.out' Ostermann's tcptrace -- version 6.6.7 -- Thu Nov 4, 2004 5763 packets seen, 5763 TCP packets traced elapsed wallclock time: 0:00:00.019828, 290649 pkts/sec analyzed trace file elapsed time: 0:00:18.655110 TCP connection info: 1 TCP connection traced: TCP connection 1: host a: XXX.XXXX.XXX:41608 host b: XXX.XXXX.XXX:22442 complete conn: RESET (SYNs: 2) (FINs: 1) first packet: Sun May 26 14:48:52.923281 2013 last packet: Sun May 26 14:49:11.578391 2013 elapsed time: 0:00:18.655110 total packets: 5763 filename: dump.out a->b: b->a: total packets: 1946 total packets: 3817 resets sent: 15 resets sent: 0 ack pkts sent: 1930 ack pkts sent: 3817 pure acks sent: 1874 pure acks sent: 35 sack pkts sent: 228 sack pkts sent: 0 dsack pkts sent: 0 dsack pkts sent: 0 max sack blks/ack: 3 max sack blks/ack: 0 unique bytes sent: 4100 unique bytes sent: 5457821 actual data pkts: 55 actual data pkts: 3781 actual data bytes: 4100 actual data bytes: 5457821 rexmt data pkts: 0 rexmt data pkts: 0 rexmt data bytes: 0 rexmt data bytes: 0 zwnd probe pkts: 0 zwnd probe pkts: 0 zwnd probe bytes: 0 zwnd probe bytes: 0 outoforder pkts: 0 outoforder pkts: 23 pushed data pkts: 55 pushed data pkts: 41 SYN/FIN pkts sent: 1/1 SYN/FIN pkts sent: 1/0 req 1323 ws/ts: Y/Y req 1323 ws/ts: Y/Y adv wind scale: 7 adv wind scale: 7 req sack: Y req sack: Y sacks sent: 228 sacks sent: 0 urgent data pkts: 0 pkts urgent data pkts: 0 pkts urgent data bytes: 0 bytes urgent data bytes: 0 bytes mss requested: 1460 bytes mss requested: 1460 bytes max segm size: 712 bytes max segm size: 1448 bytes min segm size: 16 bytes min segm size: 21 bytes avg segm size: 74 bytes avg segm size: 1443 bytes max win adv: 301184 bytes max win adv: 21632 bytes min win adv: 5888 bytes min win adv: 14592 bytes zero win adv: 0 times zero win adv: 0 times avg win adv: 269168 bytes avg win adv: 21615 bytes initial window: 20 bytes initial window: 21 bytes initial window: 1 pkts initial window: 1 pkts ttl stream length: 4101 bytes ttl stream length: NA missed data: 1 bytes missed data: NA truncated data: 0 bytes truncated data: 0 bytes truncated packets: 0 pkts truncated packets: 0 pkts data xmit time: 18.128 secs data xmit time: 18.527 secs idletime max: 5206.5 ms idletime max: 5285.9 ms throughput: 220 Bps throughput: 292564 Bps RTT samples: 57 RTT samples: 1661 RTT min: 59.0 ms RTT min: 0.0 ms RTT max: 106.1 ms RTT max: 40.1 ms RTT avg: 77.2 ms RTT avg: 1.4 ms RTT stdev: 17.2 ms RTT stdev: 7.1 ms RTT from 3WHS: 60.0 ms RTT from 3WHS: 0.0 ms RTT full_sz smpls: 2 RTT full_sz smpls: 1 RTT full_sz min: 60.0 ms RTT full_sz min: 0.0 ms RTT full_sz max: 70.1 ms RTT full_sz max: 0.0 ms RTT full_sz avg: 65.1 ms RTT full_sz avg: 0.0 ms RTT full_sz stdev: 0.0 ms RTT full_sz stdev: 0.0 ms post-loss acks: 0 post-loss acks: 16 segs cum acked: 0 segs cum acked: 2090 duplicate acks: 0 duplicate acks: 201 triple dupacks: 0 triple dupacks: 8 max # retrans: 0 max # retrans: 0 min retr time: 0.0 ms min retr time: 0.0 ms max retr time: 0.0 ms max retr time: 0.0 ms avg retr time: 0.0 ms avg retr time: 0.0 ms sdv retr time: 0.0 ms sdv retr time: 0.0 ms
几个更新我尝试了一些其他的事情。
首先，我尝试通过第三台主机对转移进行“重新路由” – 我获得了非常可观的吞吐量约30分钟，然后吞吐量衰减了20倍，几乎与原始stream量匹配。
其次，我用B-> A运行了mtr，数据包大小为1400b，并看到以下内容：
XXX（0.0.0.0）2013年5月27日星期一19:20:37 2013
键：帮助显示模式重新启动统计字段退出的顺序
包Pings
主机损失％Snt最后平均最佳Wrst StDev
1. XXX.XX 0.0％173 0.1 0.1 0.1 0.2 0.0
2. XX.XX-XXatlas.cogentco.com 0.0％173 0.9 0.9 0.8 4.2 0.3
3. XX.XX-XXatlas.cogentco.com 0.0％173 0.7 12.7 0.7 211.8 38.3
4. te7-3.ccr01.ord07.atlas.cogentco.com 0.0％173 1.1 12.8 0.7 196.8 39.9
5. te0-4-0-7.mpd21.ord01.atlas.cogentco.com 0.0％173 1.0 1.0 0.9 1.5 0.1
6. be2006.ccr21.ord03.atlas.cogentco.com 0.0％173 1.3 1.3 1.2 1.9 0.1
7. be-202-pe04.350ecermak.il.ibone.comcast.net 0.0％172 39.7 41.6 36.3 156.7 15.4
8. he-3-2-0-0-cr01.350ecermak.il.ibone.comcast.net 2.3％172 46.9 45.0 36.8 51.4 3.6
he-3-1-0-0-cr01.350ecermak.il.ibone.comcast.net
he-3-0-0-0-cr01.350ecermak.il.ibone.comcast.net
he-3-12-0-0-cr01.350ecermak.il.ibone.comcast.net
9. he-3-6-0-0-ar01.woburn.ma.boston.comcast.net 1.2％172 68.7 67.9 64.8 72.4 1.6
10. XXXXboston.comcast.net 1.7％172 67.6 66.8 64.2 70.4 1.0
11. XXXXboston.comcast.net 1.2％172 67.5 66.4 64.0 69.2 1.0
12. XXXXcomcast.net 1.2％172 75.7 75.2 72.0 85.8 1.9
鉴于我的第一个实验的结果，以及Comcast在一个三级设施（350 Cermak）控制的两台路由器之间发生了很多数据包丢失这一事实，我开始更加倾向于对“Comcast Boogeyman”的解释。
我会build议几件事情：
使用ping检查数据包丢失情况。 尝试使用不同数据包大小的至less100个ping，其中包括大小约为1400字节的数据包。
往返时间（RTT）约70毫秒可能会相当高，取决于距离。 也许一定要看看每个方向的traceroute。 在你粘贴的输出中，似乎你的stream量来自一个 – > b正在遭受延迟，而不是反过来，这可能表明从a – > b的path存在问题，但是从b – > a很好。
看看这篇旧文章中分析TCP吞吐量的技术。
这篇论文有些过时（Ethereal现在是Wireshark），但是技术仍然很好。
5秒的空闲时间与18秒的挂钟时间相比，可能表明当TCP窗口缓冲区（发送或接收）变满时连接将空闲，这将导致吞吐量下降。 然而，非常不对称的延迟是首先突出的，所以我首先关注这个问题。 祝你好运，谢谢你介绍我tcptrace; 我以前没见过。