Article ID No. 13085761170 (Delete) | New Date & Time 2009 2010 2011 2012 2013 /1 2 3 4 5 6 7 8 9 10 11 12 /1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 :0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 :0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 Category Title Content iPhone (Softbank) の回線がひどいと評判になっていたので、実験をしてみました。 <h1>実験内容</h1><ul><li>日時: 2011/6/20 22:34-22:39 JST (5 分間)</li><li>都内某所にて iPhone 4 を静止状態、Wi-Fi を無効に設定して実施。アンテナは常時安定して 5 本立った状態</li><li>iPhone 4 (iOS 4.3.3) から 3G 経由で、自宅の au ひかり (1 Gbps) 回線に接続された SSH サーバ (Linux) にアクセスし、yes コマンドを実施 (iPhone アプリの iSSH を使用)</li><li>サーバ側にて、tcpdump コマンドでパケットを採取。同時に ping を実施</li></ul>コマンドは次の通り。<pre># tcpdump -i br0 -n host (iPhone の IP アドレス) -w iphone.pcap & ping (iPhone の IP アドレス)</pre> <h1>結果</h1>Wireshark による集計結果は次の通り。縦軸はパケット、横軸は時間。画像はクリックで拡大します。 <h2>TCP</h2>黒い線がサーバの送出したパケット (tcp) 、赤い線が再送したパケット (tcp.analysis.retransmission) ≒ packet lossです。 <a href="up/iphone_softbank_graph_tcp.png"><img src="up/iphone_softbank_graph_tcp.png" style="width: 80%; max-width: 600px;"></a> 遅延があるのは置いておくとして、ロスはあまり目立たず、モバイル回線としてはまずまずという感じではないでしょうか。 <h2>ICMP Echo (ping)</h2>黒い線がサーバの送出したエコー要求パケット (icmp.type == 8) 、赤い線が iPhone からのエコー応答パケット (icmp.type == 0) です。(packet loss が無い場合、赤い線が黒い線に重なります) <a href="up/iphone_softbank_graph_icmp.png"><img src="up/iphone_softbank_graph_icmp.png" style="width: 80%; max-width: 600px;"></a> 赤い線が地を這っています。81% packet loss でした。 <h1>まとめ</h1><ul><li>Softbank 回線の ICMP パケット転送には、何らかのフィルタが掛かっている、ようだ。</li><li>回線の品質は、言われているほど悪くはないのではないか。</li><li>ネットワークの専門家ではないので、これ以上のことは聞かれても困ります :-)</li></ul>ある 5 分間を切り出したものでしかないので過信はできませんが、少なくとも ICMP と TCP の packet loss 率に相関が無いことは示せたかと。 余談ですが、ICMP パケットもパケット課金の対象になるので、あんまりジャンジャカ転送されるよりは多少フィルタが掛かってた方がパケ放題じゃない人にとっては嬉しいはず。ping flood でパケ死とか、笑えない。 # あと、TCP の RTT のいい感じな可視化方法があれば、知りたいです。 <h2>追記 (2011/06/21)</h2>TCP RTT の可視化について、コメントをいただいています。本 blog 史上最大のコアっぷりに焦りと勉強不足を感じつつ(笑) そうか、こういうときのための Jailbreak だったのか。 <h2>追記 (2011/06/24)</h2>はてブコメントを頂いたので。<blockquote>id:totttte 反証記事だからきっちり対等に比較しなきゃ意味ないのに、 どうして、TCP側は網内→インターネット方向で張ったパケットなのに、pingはインターネット→網内のネットワークになっているのか?</blockquote>往路 (インターネット → SB 網) と復路 (SB 網 → インターネット) のどちらで packet loss が生じたのかは、確かにこの検証からは不明ですね。ただ、「TCP 接続をどちらが開始したのか」というのは意味のない議論だと考えます。往路で loss しても、復路 (ACK) で loss しても、サーバ側では再送を行うはずです。ping に関しても、いずれかで loss が起きれば request timeout になります。 Password