ハイパフォーマンスブラウザネットワーキングを読んでモバイルアプリ開発(クライアント/サーバ含め)に関わる人が知っているべきだと思ったこと

モバイルアプリやWebアプリをテストする上で、それらの構成要素を知ることは非常に大事です。また、モバイル通信環境ではネットワークを考慮した環境への配慮の必要性がさらに大事です。そこで、ハイパフォーマンスブラウザネットワーキングを読みました。その中で、重要と感じたところをメモがてら残しておきます。

始めに

大学や職場では、電波や光の変調技術や伝搬遅延などの基礎、TCPのセッション確立、その上側のHTTP通信の話しまでは知っていたのですが、物理層の端末側状態遷移までは知らなかったです。また、モバイルネットワークでも、基地局や3G/LTE/WiFiなどの切り替えや特性が存在することは知っていましたが、それらが物理層でどういう状態で待機状態になっているか?など知らなかったです。この本では、そこらへんを含めたネットワーキングを全体的に知ることできたことが一番の収穫です。

というのも、モバイルアプリのテストって、PCよりも通信状態によるパケットの損失など、環境に依存する箇所が大きいとつくづく感じているのですよね。そこら辺をある程度ざっくりとテストしはするのですが、不具合解析やよりユーザの利用状況を考えたテストまで踏み込むと、厳密に通信がどのような状態か、まで考慮できた方が良いです。なので、個人的にここはすごく良かったです。

以下、いくつかモバイル通信環境に焦点を当てた上で、個人的に重要だと感じたところをピックアップ。

RRCレイテンシの存在

RRC(Radio Resource Controller)は、モバイル端末が基地局との通信を物理層で制御する機能です。モバイル通信(3G/4Gなど)では、モバイル端末が基地局との通信を物理層で確立した後、TCPの確立などに進みます。それらすべてには遅延が生じるのですが、その一番始めに存在し、モバイル通信固有の機能になります。

このRRCレイテンシは、LTE/3Gでは以下のようなレイテンシが発生するようです。

  • LTE: 10~100ms
  • 3G: 最大で2秒

なので、モバイルネットワークの場合、HTTPリクエストの到達までにかかる遅延要素は以下になるのですね。

RRCネゴシエーション=>DNSルックアップ=>TCPハンドシェイク=>TLSハンドシェイク=>HTTPリクエスト

この遅延を考慮した上で、端末上で動作するネイティブ/ブラウザアプリを設計・実装していく必要が現実世界ではあるのですね。モバイルアプリにおけるテストでは、OS側の責務だからと3G/LTE/WiFiと通信方式が異なる環境下でテスト(というか、動作確認)されることが少なくない気がします。一方で、こういう所はユーザビリティという視点でもアプリの快適さに大きな影響を与えるので、気に留めた方が良いです。

ハンドオーバー

LTEでは、基地局から基地局のハンドオーバーに100ms以内の時間かかるそうです。一方、3Gなどでは、数秒かかることも多いそうです。日常的にこういう遅延が発生しているのですね。

ジッタ

モバイルアプリケーションの通信では、ジッタと呼ばれる変動的なパケットの遅延が発生するらしいです。ここは知らなかったです。

AT&Tの各種ネットワークにおける、モバイル端末がRRCを行いDNSルックアップに到達するまでの、平均的なレイテンシは以下のようです。

  • LTE: 40~50ms
  • HSPA+: 100~200ms
  • HSPA: 150~400ms

モバイル通信における、実世界で考慮されるトレードオフ

  • バッテリー消費とネットワークパフォーマンス
  • スループットをユーザ個別に最適化するか、ネットワーク全体に最適化するか
  • レイテンシとジッタの考慮
  • コストとフィージビリティ
  • 国や地域
  • 他の基準

モバイルネットワークへの最適化

  • バッテリー消費を抑える
    • 無線通信は、ディスプレイに次いで2番目に電力を消費するそうです。また、無線のエネルギー消費量とデータ転送量は比例する訳ではないそうです。
    • AT&TのApplication Resource Optimizerを使うことで、AndroidやiOSにおけるバッテリー消費量の概算を出せるそうです。やってみよう。
  • 非効率な定期データの送受信を排除する
    • プッシュ通信の活用、データをなるべくまとめる、重要度の低い通信は端末がアクティブになったときにのみ通信する、などを実施する。
  • ネットワークコミュニケーションとユーザインタラクションを切り離す
  • 変化するネットワークインタフェース状態に対応するデザイン
    • 無線の回線品質は、基地局との距離、混雑度、干渉などにより刻々と変化する
      • 到達不能なホスト
      • 突然のスループット低下やレイテンシの上昇
      • 突然の圏外
    • エンドツーエンドの通信に置ける帯域幅などの予測は、モバイルネットワークの話しになると有線状態の倍以上の難しさになる
  • バースト的に送受信し、アイドル状態に戻る
    • モバイル端末のインタフェースはバースト的な送受信に最適化されている
      • 多くのリクエストを集約し、できるだけ多くのデータをできるだけ早くダウンロードした上で、通信をアイドル状態にすることが望ましい
        • バッチ処理や、プリフェッチで多くの情報を取得しておくことが大事
    • プログレッシブダウンロードは害の方が大きい
      • 動画や音楽のストリーミングよりはファイル全体のダウンロードのほうが良い
      • コンテンツのプリフェッチ
      • 広告などのサードパーティーコンテンツはプリフェッチしておき、アプリ内のロジックで出し分けすべき

DASHやHLSのようなHTTPストリーミング技術などは最近いろいろ研究されていますので、一概には言えないかもしれません。一方、3G世代のような通信環境では少なくとも一括ダウンロードのほうが良さそうな印象を受けました。

締め

基礎的な技術の話しでは知っていることも多かったですが、それらがまとまって、どういう形で関連しているかを知るのに非常にためになりました。アプリケーションの実装方法も、テストにおける評価環境も、どのような設計・実施すべきかを考えるにあたって良い知見を与えてくれました。個人的に作成しているテストのマインドマップに加えていこう。

※9章以降はHTTPのWebアプリの話しだったり、WebSocketなどの個別要素に特化した話しになってくるよう。なので、その領域にガッツリ関わっていないなら、9章以降は必要に応じて読めば良いかも。

Advertisements