RSS
iPhone (Softbank) の回線がひどいと評判になっていたので、実験をしてみました。
遅延があるのは置いておくとして、ロスはあまり目立たず、モバイル回線としてはまずまずという感じではないでしょうか。
赤い線が地を這っています。81% packet loss でした。
余談ですが、ICMP パケットもパケット課金の対象になるので、あんまりジャンジャカ転送されるよりは多少フィルタが掛かってた方がパケ放題じゃない人にとっては嬉しいはず。ping flood でパケ死とか、笑えない。
# あと、TCP の RTT のいい感じな可視化方法があれば、知りたいです。
そうか、こういうときのための Jailbreak だったのか。
実験内容
- 日時: 2011/6/20 22:34-22:39 JST (5 分間)
- 都内某所にて iPhone 4 を静止状態、Wi-Fi を無効に設定して実施。アンテナは常時安定して 5 本立った状態
- iPhone 4 (iOS 4.3.3) から 3G 経由で、自宅の au ひかり (1 Gbps) 回線に接続された SSH サーバ (Linux) にアクセスし、yes コマンドを実施 (iPhone アプリの iSSH を使用)
- サーバ側にて、tcpdump コマンドでパケットを採取。同時に ping を実施
# tcpdump -i br0 -n host (iPhone の IP アドレス) -w iphone.pcap & ping (iPhone の IP アドレス)
結果
Wireshark による集計結果は次の通り。縦軸はパケット、横軸は時間。画像はクリックで拡大します。TCP
黒い線がサーバの送出したパケット (tcp) 、赤い線が再送したパケット (tcp.analysis.retransmission) ≒ packet lossです。遅延があるのは置いておくとして、ロスはあまり目立たず、モバイル回線としてはまずまずという感じではないでしょうか。
ICMP Echo (ping)
黒い線がサーバの送出したエコー要求パケット (icmp.type == 8) 、赤い線が iPhone からのエコー応答パケット (icmp.type == 0) です。(packet loss が無い場合、赤い線が黒い線に重なります)赤い線が地を這っています。81% packet loss でした。
まとめ
- Softbank 回線の ICMP パケット転送には、何らかのフィルタが掛かっている、ようだ。
- 回線の品質は、言われているほど悪くはないのではないか。
- ネットワークの専門家ではないので、これ以上のことは聞かれても困ります :-)
余談ですが、ICMP パケットもパケット課金の対象になるので、あんまりジャンジャカ転送されるよりは多少フィルタが掛かってた方がパケ放題じゃない人にとっては嬉しいはず。ping flood でパケ死とか、笑えない。
# あと、TCP の RTT のいい感じな可視化方法があれば、知りたいです。
追記 (2011/06/21)
TCP RTT の可視化について、コメントをいただいています。本 blog 史上最大のコアっぷりに焦りと勉強不足を感じつつ(笑)そうか、こういうときのための Jailbreak だったのか。
追記 (2011/06/24)
はてブコメントを頂いたので。id:totttte 反証記事だからきっちり対等に比較しなきゃ意味ないのに、 どうして、TCP側は網内→インターネット方向で張ったパケットなのに、pingはインターネット→網内のネットワークになっているのか？往路 (インターネット → SB 網) と復路 (SB 網 → インターネット) のどちらで packet loss が生じたのかは、確かにこの検証からは不明ですね。ただ、「TCP 接続をどちらが開始したのか」というのは意味のない議論だと考えます。往路で loss しても、復路 (ACK) で loss しても、サーバ側では再送を行うはずです。ping に関しても、いずれかで loss が起きれば request timeout になります。
Comments
TCPに関するkernel設定を変更してしまうという手はありますが。。。
簡単な方法としては、正確ではありませんが、たとえば、libpcapでTCPパケット風のパケットを自作してやり取りを行うプログラムを書いてみたり、TCPセッションが開始される3 way hand shakeだけの部分を切り出してRTTとしてみるとかはどうでしょう？
コメントありがとうございます。（いつも blog 拝見しています!）
kernel の設定について、TCP セグメントの数が常に 1 になるようにすれば、RTT になるのかなと思っています。
ハンドシェイク自作については、iPhone 側で何かしらのポートを空ける or iPhone アプリを作らないといけないのでちょっとハードル高いですが、時間があったら挑戦してみます。
# そもそも libpcap を使ったプログラムを書いたことが無いという話もあります :-)
情報ありがとうございます。そのままズバリな機能があったのですね。
グラフの読み方と調節の仕方がまだ分かっていないので、使いこなせるように勉強します... (汗)
kernel設定が出来るのであれば、それでやれば何となくのデータが取れそうですね。
3 way hand shakeの部分は、いくつかのTCPセッションを普通に張ってみて、その部分のwireshark結果を見てみるという意味です。
わかりにくくてすみません。。。
libpcapその他のプログラミングに関しては、そこまでやるのもやり過ぎな気がするので、忘れて下さい。。。
といいつつ、もし興味があるのであればlinux用のサンプルコードをいくつか公開しているのでどうぞ。
http://www.geekpage.jp/programming/linux-network/book/
サンプルコード、ぜひ参考にさせていただきます。ありがとうございます。
複数回セッションを張って測定し、
tcpdump -rとフィルターで、SYN/SYN+ACKだけを取り出し、
テキスト処理で統計をとってみてもいいかもしれませんね。
勉強中とのことですので、
その方がWiresharkで可視化するより、
個々のパケットについての理解が深まるかもしれません。
> あんまりジャンジャカ転送されるよりは多少フィルタが掛かってた方が
> パケ放題じゃない人にとっては嬉しいはず。
> ping flood でパケ死とか、笑えない。
そもそも、iPhone 側がPing に応答する意味はないと思う。
それこそ、書かれているように「Ping flood」の餌食になりますから・・・
訂正前
「そもそも、iPhone 側がPing に応答する意味はないと思う。」
訂正後
「そもそも、iPhone 側がPing に応答するべきではないと思う。」
アドバイスありがとうございます。
ついツールに頼ってしまいがちですが、そういった地道な努力も必要ですね。。
Hide さん
ユーザが設定変更できれば、なお良いですね。