我试图弄清楚为什么我控制的两个主机之间的 tcp/ip 吞吐量比预期的低得多。
主机 A：由波士顿地铁康卡斯特（住宅）提供的互联网连接 - 可以从各个知名网站持续实现 100Mbps 下载（例如下载 Google Chrome）
主机 B：由 Cogent 提供的互联网连接；可以持续实现与各个站点之间接近 100Mbps 的速度。
测试连接：主机 A 通过非标准端口 (22442) 上的 rsync/ssh 从 B 下载一个大文件（即rsync --progress -e 'ssh -p 22442' ...吞吐量仅为 2.5Mbps（292564 Bps）左右）
其他客户端（例如临时 EC2 实例）尝试从 B 下载相同内容时，吞吐量可达到近 30 倍
我已经设法使用 tcptrace 捕获 A 和 B 之间的连接的统计信息（附在下面），但我不确定是否有任何问题。
我想我的这边有些地方需要调整，但我也对康卡斯特调整流量有些怀疑——所以在我开始胡乱操作之前，我想先寻求建议。接下来我可以尝试哪些好方法？提前谢谢。
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 倍左右，与原始流量大致匹配。
其次，我使用大小为 1400b 的数据包从 B->A 运行 mtr，看到以下情况：
XXX（0.0.0.0）2013 年 5 月 27 日星期一 19:20:37
按键： 帮助 显示模式 重新启动统计 字段顺序 退出
数据包 Ping
主机损失率 Snt 最后平均值 最佳 Wrst 标准差
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
他-3-1-0-0-cr01.350ecermak.il.ibone.comcast.net
他-3-0-0-0-cr01.350ecermak.il.ibone.comcast.net
他-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
鉴于我的第一次实验的结果，以及康卡斯特在 Tier III 设施（350 Cermak）中控制的两个路由器之间发生如此多的数据包丢失的事实 —— 我开始更倾向于“康卡斯特恶魔”的解释。
答案1
我建议以下几点：
使用 ping 检查数据包丢失。尝试至少 100 次不同大小的数据包的 ping，包括一个大约 1400 字节的较大数据包。
往返时间 (RTT) 约为 70 毫秒，根据距离的不同，这个数字可能相当高。也许一定要查看每个方向的跟踪路由。在您粘贴的输出中，似乎从 a -> b 的流量存在延迟，但相反的情况没有，这可能表明从 a -> b 的路径存在问题，但从 b -> a 的返回路径没有问题。
看看这张旧纸用于分析 TCP 吞吐量。
该论文有点过时（Ethereal 现在是 Wireshark），但是技术仍然有效。
5 秒的空闲时间与 18 秒的挂钟时间相比可能表明当 TCP 窗口缓冲区（发送或接收）已满时，连接处于空闲状态，这会导致吞吐量下降。但是，非常不对称的延迟是最突出的问题，所以我首先会关注这一点。祝你好运，感谢你向我介绍 tcptrace；我以前从未见过这种情况。