Tcp
如何調試為什麼 WAN TCP/IP 吞吐量低於預期？
我試圖弄清楚為什麼我控制的兩台主機之間的 tcp/ip 吞吐量遠低於預期。
主持人 A：Comcast（住宅）在波士頓地鐵提供的網際網路連接——可以從各種知名網站（例如下載 Google Chrome）持續實現 100Mbps 下載
主機 B：由 Cogent 提供的網際網路連接；可以始終達到接近 100Mbps 往返各個站點。
測試連接：主機 A 從 B 下載一個大文件，通過非標準埠 (22442) 上的 rsync/ssh (即
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 Host Loss% Snt Last Avg Best 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鑑於我的第一次實驗的結果，以及康卡斯特在第三層設施（350 Cermak）中控制的兩個路由器之間發生如此多的封包遺失的事實——我開始更傾向於“康卡斯特 Boogeyman”的解釋。
我建議幾件事：
- 使用 ping 檢查封包遺失。嘗試至少 100 次不同數據包大小的 ping，包括大約 1400 字節的較大數據包。
- 大約 70 毫秒的往返時間 (RTT) 可能會非常高，具體取決於距離。也許一定要看看每條路的跟踪路由。在您粘貼的輸出中，來自 a -> b 的流量似乎受到延遲的影響，但反之則不然，這可能表明來自 a -> b 的路徑存在問題，但來自b -> a 很好。
- 查看這篇舊論文中用於分析 TCP 吞吐量的技術。
這篇論文有點過時了（Ethereal 現在是 Wireshark），但技術仍然不錯。
5 秒的空閒時間與 18 秒的掛鐘時間相比可能表明當 TCP 視窗緩衝區（發送或接收）已滿時連接處於空閒狀態，這將導致吞吐量下降。然而，非常不對稱的延遲是最突出的，所以我會首先關注這一點。祝您好運，感謝您向我介紹 tcptrace；我以前沒見過。