前回記事に対して、「ICMP(ping)のパケットの優先度を落としているだけでは」という意見も幾つかあったようだ。
本文でも書いているとおり、僕自身はパケットロス率に注目したのではなく、それに伴うラウンドトリップタイム(RTT)の時間帯での差異から(ICMP/TCPあるいはUDP関わらず)バックボーンを守るための何らかのパケット制限がかけられているのではないか、という見解だ。
ただ70-90%という値があまりにセンセーショナルだったため数字が一人歩きしたか、エントリー全文が読まれていないということかと思うのだが、せっかくなので、ではTCPではどうなのか確かめてみた。以下、その結果。
追記書いてます。
—
#softbank 携帯によるデータ通信でのパケロスは本当に酷いのか?
という話があって、聞こえてくる話では75%のパケットロスもあるのだという。
一般的にネットワークに関わる層には一概に信じられないロス率だが、Twitterなどで流れてくる数値ではよく信用できないのと、ある程度偏ったテスト環境になってしまっている気もしたので、ドコモ回線含め時間帯も変えて比較してみることにした。
テスト環境は以下の通り。
テスト概要
JailBreakしSIMフリー化したiPhone3GS(iOS4.2.1)にてソフトバンク iPhone通常回線(smile.world)とドコモ データ定額(mopera.flat.foma.ne.jp)で複数のサーバーに対してping(ICMP echo)テストを実施し、パケットロス率およびラウンドトリップを計測する。
テスト方法
SSHでiPhoneへログインし、Cydiaのinetutilsに付属するpingコマンドを計30回試行し平均値を得る。
テストサーバー
テストは都内から行っている。また時間帯も変えることとし、とある日曜日のPM9時台と翌日AM2時台の二度行った。
結果は以下の通りである。
テストケース1: PM9時台に実施
| フレッツ光(Wi-Fi) | |||||
| packet loss | min | avg | max | stddev | |
| www.yahoo.co.jp | 0% | 11.704 | 16.691 | 23.845 | 3.0003ms |
| www.google.co.jp | 0% | 43.708 | 46.835 | 54.807 | 2.081ms |
| テストサーバー1 | 0% | 139.024 | 187.894 | 239.065 | 30.026ms |
| テストサーバー2 | 0% | 18.814 | 22.512 | 25.306 | 1.460ms |
| docomo(データ定額) | |||||
| packet loss | min | avg | max | stddev | |
| www.yahoo.co.jp | 0% | 108.174 | 118.389 | 154.171 | 8.798ms |
| www.google.co.jp | 0% | 128.898 | 141.954 | 155.505 | 6.944ms |
| テストサーバー1 | 0% | 206.165 | 217.398 | 361.339 | 26.932ms |
| テストサーバー2 | 0% | 106.566 | 132.891 | 613.313 | 89.298ms |
| Softbank(iPhone) | |||||
| packet loss | min | avg | max | stddev | |
| www.yahoo.co.jp | 73% | 88.733 | 179.106 | 370.456 | 92.697ms |
| www.google.co.jp | 86% | 116.306 | 120.867 | 126.555 | 4.248ms |
| テストサーバー1 | 76% | 240.308 | 259.038 | 318.825 | 24.805ms |
| テストサーバー2 | 90% | 121.751 | 131.433 | 146.446 | 10.763ms |
テストケース2: AM2時台に実施
| Softbank(iPhone) | |||||
| packet loss | min | avg | max | stddev | |
| www.yahoo.co.jp | 3% | 114.327 | 245.465 | 2133.128 | 403.058ms |
| www.google.co.jp | 23% | 107.446 | 178.063 | 896.914 | 161.420ms |
| テストサーバー1 | 0% | 533.464 | 1064.434 | 1991.588 | 373.095ms |
| テストサーバー2 | 3% | 401.674 | 967.69 | 1886.757 | 345.000ms |
比較のためWi-Fi(回線はフレッツ光)も付記している。
まず第一に流れている話通り、PM9時台では確かにロス率は70%から最大90%にも達している。まさしく通常はあり得ないレベルだと言ってもいいだろう。
しかしもう一点注目すべきなのは、ラウンドトリップに関しては、実はドコモのそれと遜色ない、若しくは場合により上回っている場合もあるということだ。
次にAM2時台となるとロス率は格段に改善されている。ほぼ問題無いレベルと言ってもいいだろう。しかしその反面ラウンドトリップは極端に落ち込み、特にmax値は10倍以上遅延しているケースもあった。また平均偏差も非常に大きくなっている点にも注目したい。これはネットワーク状態が安定していないことを示している。
果たしてこれらは何を意味しているのか。
ここから憶測にすぎないが、テストケース1において、恐らくソフトバンクのバックボーンネットワークの性能自体はドコモと比較してもそれほどの遜色は元々無さそうだと言うことだ。しかしそれはパケットロス率を上げることでバックボーンへの負荷を低減しているからではないか。
これはテストケース2においてロス率が下がったと同時にラウンドトリップが極端に下がった(つまりネットワークが飽和しつつある)ことからも想像できる。
すなわち、パケットロス率はバックボーンへの負荷を減らすべく元から意図されたもので、時間帯により例えばスイッチングルーターのバッファ量を調整するなどして日夜調整されているのではないかという推測が成り立つ。
僕自身はネットワークの実務経験も乏しく専門性は持ち合わせていないのでこれ以上の論評は差し控えるが、これはこれで1つの「見切り」かも知れないという気はする。
ユーザーとしての感想を述べるなら、僕自身はパフォーマンスも少なくとも最近は1Mbpsを下回ることもなく安定して使えていると思っており、これまでもソフトバンク回線に(電波の入り以外に)大きな不満を感じたことはない。
スマートフォンに絞ればほとんどの通信はTCPベースであることは確かであり(UDPで困るのはDNSぐらいか)非常に多くのリトライパケットが発生するとしても全体としてはそれなりの「実測値」が得られると言うことなのかも知れない。
ネットワーク屋にとってはとても考えられない対応かも知れないし(僕自身もそうしたチューニングを決意する度胸はないが)、単にパケットロス率のみ取り上げて非難するのは簡単だ。しかし1つの方法論として今後「冷静に」大いに議論されても良い点ではないだろうかとも思う。
何故なら、これはもしかすると今後いずれのキャリアも通る道かも知れないからだ。
検索する限りは同じ現象に遭っている人はいなさそうに見えたんですが、もしかしたら遭遇する人がいるかも知れないので、記録のために残しておきますね。
先日ふと今やテスト用と化したかれこれ2年半ほど使っているiPhone 3Gを掴んだ時に違和感を感じてケース裏を確認したら、ケースの真正面に縦向きに大きなヒビが入っているのに気付きました。

林檎マークからiPhoneロゴのところまで約10cmぐらいの比較的大きなヒビでした。
ケースの裏側も普通は真っ平らだと思うんですが 、こころなし林檎マークを中心に少し盛り上がって平らではない感触。
瞬間的に「電池膨張してケースが内側から割れた?」と感じました。
普段常用しているのは3GSなのですが、3Gは開発テスト用に使っていたのでこれはこれで無くなると困ります。かと言って使い続けたら、ニュースで時々聞くようにいつか爆発なんてことになったら大変です。
ということでサポートに連絡を取ってみることにしました。
まずは近くにソフトバンクショップがある(3Gは発売月にそこで買った)のでそこへ持ち込み。
んでお兄さんが言うには、
との返答。Apple Careにも入っていないので当然保証期間は切れています。
ただ、ソフトバンクショップが頼りにならないのは最初から想定内。
とりあえずソフトバンクのサポートポリシーを聞き出してから(要するにアップルとの契約上、サポートについては何も出来ないとのこと)、直接アップル・サポートへその場で電話してもらって担当へつないでもらうように頼みました。
日曜だったので少し時間はかかりましたが、 アップル・サポートへ事情を伝えてもらい、どうも電池の不具合らしいということは理解してもらえたようです。
但しこうした製品瑕疵(多分事故に関わる問題という意味かな?)については上位部署につながないといけないのだが、当日は日曜だったため混んでいて電話が繋がらず、後日あらためて連絡して欲しいとのこと。
受付番号をもらってその日はソフトバンクショップを後にしました。
翌日連絡すると、その上位部署というのはAppleCareサービスだったようです。通常のサポート部署とは違うんですね。
昨日対応できなかったことをお詫びされながら、まず「怪我や被害はでていないか」「ケースやPCなどが破損したりしなかったか」などこちらの被害がなかったかきめ細かく聞かれました。
その後再度裏面の様子や利用環境、PCとの接続形態なども細かく聞かれ、結論として
とのことでした。
実は開発・テスト用に3GはiOS3.1.3に止めており、仮に交換となった際にiOS4.xに上げられていると困るためどうなるかも質問したのですが、折り返しで「3GならiOS2.xで交換される」との回答をすぐもらえたので手続きをお願いしました。
3Gは復元でデータ初期化してから、木曜日に配送業者が引き取りに来ました。
その後連絡はなかったのですが、翌週火曜日に突然宅配便が来て、中には交換された新品(なのかな?)の3Gとやはり新しく交換されたUSBケーブルが入っていました。つまり「無償で交換」という判断をしてもらったということなのでしょう。
但し詳細について連絡も詳しい説明書なども入っていなかったので、後日こちらから連絡して(何かあったら連絡下さい、とのことで内線番号まで聞いていた)、折り返しでどういう判断をしてもらったかを聞きました。
実のところ(少なくとも日本では?)AppleCareサービスでは故障品の中身を空けて原因を調べると言うことはしないそうで、ただ外見上や利用状況から判断して「自然発生であったこと」「ユーザー瑕疵は無さそうなこと」「このまま使えば事故に繋がりかねないと判断したこと」などから部署内に在庫もあったため無償交換をしてくれた、ということのようです(ただしあまりはっきりとした判断を示されず、上記は少し曖昧な話からの僕の想像で補っています)。
また「常に出来る対応とは限らない」点は念押しされました。
ということで一件落着。3Gは新しくなったし(と言っても常用じゃないしそれ自体にはあまり意味は無いんですが)、テスト用の環境も簡単に戻せたので満足です。
アップルのサポートの評判は僕はよく知らないのですが、全般的に非常に親身で丁寧、かつ迅速な対応と判断でしたので少なくとも今回に限っては大満足でした。素晴らしいサポートが体験できました。
もちろん常にということではないかも知れませんし、特に今回は事故に繋がりかねないという点が大きかったのだろうとも思います。
めったにあることでは無いと思うのですが、もし電池が膨張などした場合には大変危険ですので、すぐにアップルのサポートへ連絡されることをお薦めします。上記と同じ対応が取られるとは限りませんが、爆発事故など起きてからでは遅いですからね。気を付けましょう。
本当は使わない時はケーブルから外して時々は放電もしておくのがいいんですよね。開発に使っているとなかなか難しいんですけどね。
前々回、前回の続きをご報告したいと思う。
かなりあれから時間がかかったが、結論としてはシンプルで楽天銀行および楽天CERT・楽天グループとしてはUDIDの送信は停止しないし、また何故送信しているか、どのように利用・管理しているか は「当行不正取引防止システム運営の機密事項」のため一切開示しないとの結論であった。
以下、その詳細。
前回記事のはてブコメントで教えてもらったんですが、Burp Proxyというプロキシー型キャプチャソフトがあるそうです。
で実際使ってみると、これいい!お手軽ですね。Fiddler2と違ってiPhoneアプリでも利用可能です。
ということで改訂版をまとめてみますよ。 一応再度のまとめにしますので前回と被る部分もありますがご了承下さい。
なおやはり再度の補足になりますが、セキュリティの向上や社会的に正当な目的の下で正しく使用されることを期待してこのエントリーを記載しています。筆者は利用の結果に対して全くの無責任・無保証ですので、あくまで自己責任でご利用下さい。
ブラウザでアクセスするWEBサービスだと、たとえSSL/TLSでセッションが暗号化されていても所詮ピア・ツー・ピア通信なので例えばFirefoxだとFirebugなどでブラウザ側でパケットをキャプチャできます。
でもiPhone(iOS)アプリだとiPhoneにそんなツールが入れられないしキャプチャできない、と思い込んでいませんか?
実は僕もそうだったのですが、この件に関連して可能なキャプチャ方法を見つけたので覚え書きで残しておきます。
但し素人の方法なのでもっと洗練された方法もあるはず。セキュリティクラスタの皆さんにおかれてはよりよい方法をご存じであればぜひTBやコメントなど頂きたく。
なおセキュリティの向上や社会的に正当な目的の下で正しく使用されることを期待してこのエントリーを記載しています。筆者は利用の結果に対して全くの無責任・無保証ですので、あくまで自己責任でご利用下さい。
結論から書き出すと、結局のところ楽天銀行アプリはUDIDを通常(初期)ログインとクイックログインそれぞれのタイミングでサーバー送出をしていた。この事実からは楽天CERTの説明には不信がある。
さてどうしてくれようというのが現時点な訳だが、まずはどういう仕様で楽天銀行アプリが動作しているのか明らかにしてみよう。楽天CERT担当者からは「即座に悪用できるものではない」との見解ももらっているしまたそもそもリバースエンジニアリングしている訳でもなく公共のインターネットを飛び交っているデータプロトコルについての解説なのだから誰に謀るものでもないだろう。ということで、安心して内容について考察してみる。
まだ曖昧な部分もあるので書くかどうか迷いはしたのだが、一定の結果には至ったので僕自身が持っている疑問の提示と皆さんへの問いかけという意味を込めて書き連ねてみる。
iPhoneアプリに「楽天銀行アプリ」というものがある。名前通り楽天銀行へログインし自身の取引結果や振り込みなどを行えるアプリだ。
僕自身も楽天銀行には口座を持っているので試してみたのだけど、「あれ?」と思わざるを得ない仕様があった。
簡単に説明すると次のような手順でこのアプリは使用する。
事実を正しく指摘してはいるけど、「本当の理由」ではないと思う。
「事実は正しく指摘」しようよ。
結論は、元の中島氏の結論も含めて携帯関係クラスタやらそうした関連記事ではさんざん出ている指摘なので特に異議もないのだけど、その「前振り部分」の事実誤認なのか無知なのか分からないが、事実無根の記述がこんなに短いエントリーなのに三つ(数え方により四つ)もあるよ。
はてブとか読む限り、勘のいい人たちは「何かおかしくね?」とちゃんと気付いてるみたいだけど、言葉のまま信じ切っている人も多いみたいなので、きちんと添削しておく。
WAP1.0の前世紀ならいざ知らず、少なくともiモードはその登場時からTCP/IPベースの携帯端末だった。 小飼氏が言っているのはその10年も昔のWAP1.0と取り違えたような話だ。
というよりWAP1.0のプロトコル・ゲートウェイ的なダサイ実装が嫌だったのでそもそも独自にiモードをTCP/IPベースにして開発した、というのは有名な話だ。
この端末からゲートウェイからもちろん外部のインターネットまで通信層をTCP/IPでデザインするというというアーキテクトはその後のWAP2.0へそのまま踏襲された(つまり現在世界的に見ても『IPアドレスが割り振られない』携帯端末はまず存在しない)。
そもそもガラケーでも問題なくSSLが出来ている(完全なピア・ツー・ピアという意味)時点でTCP/IPをサポートできていないはずが 無いのだが。
なおこれはEZWebやYahoo!ケータイでも(初期にはWAP1.0な時代があったかも知れないが、そこの歴史は僕には分からない。識者の教示を求む)同じことだ。
参考: WAP2.0で何が変わったのか
あいまいな論の文章なので判断しにくいのだけど、小飼氏の論やツイートを見ると「iPhoneにはグローバルIPが振られ、外部からも自由にアクセスされ得る」から「終端として主導権を握れる」のが他の端末との大きな違いとなった、とも読める。つまりグローバルIPを自由に使える点が重要だったという意味だろうか(正直こうしてまとめていても僕にはよく分からない)。
仮にそうだとして、日本ではソフトバンクのいわゆる「panda-world.ne.jp」と呼ばれる「iPhone専用網」でサービスされておりここではグローバルIPが割り振られる。IPがグローバルかプライベートかは通常は分からないが、JailBreakしていれば自機のIPが把握できるアプリもある。
しかし世界的にはそんなキャリアだけではない。
例えばこちらの資料をみれば一目瞭然だ。世界的にはグローバルIPを使用するキャリア、 プライベートIPを使用するキャリア(つまりキャリアグレードNATを導入しているキャリア)が混在している。
APN Settings for iPhone 3G | The iPhone User Guide
これらの国ではiPhoneの他の機種に対する魅力は無いのだろうか。ノキアは悠々自適なビジネス環境を生きているか。そんなことは無い。
更に言えば、そもそもスマートフォン網だのガラケー網などと分かれている(アクセスポイントが分けられている)国の方が珍しいので、従来の携帯端末でもグローバルIPが割り振られる場合も同様にある。
「日本のガラパゴス現象」を主題にしているのは理解しているが、しかしその論では「海外においてもiPhoneがスマート」になっている理由付けにはならないだろう。
論理的帰結として、iPhoneはまたはスマートフォンとはそうした「外的要因」からは分離されたところにその存在意義や魅力があると考えるべきだろう。
なお僕には詳細は分からないのだが、「そもそもiモードにも外部接続を受け付ける仕組みはあるよ?」という指摘もある。
これまたあいまいな文章なので判断しにくいが、「iPhoneは定額データ(=常時接続)が無ければこれほど浸透しなかった」は自明としても「定額データを導入したからiPhoneが浸透した」なら成り立たない。既に多くの人が理解するようにiPhone以前の何年も前からガラケーで定額データは一般的だったからだ。
今に始まった経緯では無いのだから「iPhone『だけ』を特別なものにした」論の論拠としては甚だ疑問だし、では何故ガラケー(やその他従来端末)がiPhoneになれなかったかの論としては成り立っていない。
このブログでは、あるいはTwitterでも散々ツイートしているし長くなる話なのでかなり簡単にまとめるが、僕自身は「肝」はいわゆる固有端末ID(uid, X-UP-SUBNO、X-JPHONE-UIDなど)をベースにしたモバイルECが想像以上に成功しそれ以外の方向性に舵を切る必然性がキャリア・メーカーともに無くなったからだと思っている。つまり「イノベーションのジレンマ」かも知れないし、中島・小飼両氏の「結論」も別に異議はない。それ故にキャリアはメーカーを飼い慣らす(実は飼い慣らしたかったのはユーザーだろうが)必要があったしメイドにもならざるを得なかった(つまり両氏の「結論」は「結果論」)、というのが本質論だと思っている。
もし興味があるのなら以下の以前のエントリーも参照して欲しい。
日本のケータイWEBはどうしてこんな仕様になったのか
結局SIMロック論議もオープンプラットフォーム構想も端末IDの話に尽きるのかも知れないなぁ
Appleは本当に垂直統合なのか – 日本の携帯キャリアとの違い
ガラケー機能は須くクラウドを目指せ
ともあれ。エンジニアたる者、事実に立脚せず思い込みだけで論陣を張るなど以ての外だし、知らないことは知らないでよいのではないか。その上で知りたいのなら(議論したいのなら)きちんと新たに学べばいいだけだ。これはネットだけでなくリアルにおいても「技術屋」としては最低限の矜持である。
ROCA, the mere engineer.
よく「日本の携帯キャリア構造を垂直統合と言われるがAppleこそ垂直統合ではないか」「Appleは日本のケータイ業界を参考に垂直統合戦略を組み立てた」などという人がいる。
しかし個人的には果たして日本のキャリア構造とAppleの戦略を同一視し、更にはそれを理由に日本のキャリア構造について肯定的に捉える(または言い訳に使う)論法には反対だ。
また更にはそれをして「勝てば官軍、負ければガラパゴス」とまで拡大解釈する向きもあるようだ。
ここではその「Appleこそ垂直統合・ガラパゴス」主張について反論をしてみようと思う。
Recent Comments