野次馬エンジニア道

野次馬な気持ちでプログラミングをあれこれと綴ります

パフォーマンス最適化のためのネットワーク関連の最強本

HTTP2や5Gというキーワードをちょっと前によく耳にして、ふと手にとってみた本。

ハイパフォーマンス ブラウザネットワーキング ―ネットワークアプリケーションのためのパフォーマンス最適化

ハイパフォーマンス ブラウザネットワーキング ―ネットワークアプリケーションのためのパフォーマンス最適化

5Gに関しての情報は書いていなかったが、3Gから4Gに至る経緯やレイテンシと帯域幅を中心としたパフォーマンス上の差異などか細かく書いてある。特にモバイルネットワークについて、それぞれの規格毎に電波リソースの割り当てや状態遷移を纏めてある章は圧巻。

話としては、著者のGoogleI/Oでのプレゼンテーションで


Mobile Performance from the Radio Up: Battery ...

既に紹介されている内容と被る箇所も多いが、TCP/UDP/TLSといった基礎となるプロトコルの特徴に加えて、最近のLinuxカーネルに入っている最適化まで広くカバー。HTTP2.0に関しては、低レイヤーの実装の話から既存のインフラの上にどのように構築していくかの提言も含まれていて非常に興味深い内容。著者の最適化に関するありとあらゆる知識が凝縮された一冊。

以下、印象に残ったところをメモ。

ワイヤレスネットワークのパフォーマンスの基礎

低周波の信号の方は広いエリアをカバーできる(マクロセル)。一方高周波はデータ転送量は増えるがエリアは狭くなる(マイクロセル)。

P83より

{ \displaystyle
C = BW \times  \log_{2}\left( 1+\frac{S}{N} \right)
}

  • Cはチャンネル容量(bit/秒)
  • BWは周波数帯域幅(Hz)
  • Sはシグナル、Nはノイズ

多少単純化されていますが、(中略)、最大データ転送速度に関する2つの基礎的な制約事項は、利用可能な帯域幅の大きさと、受信側と送信側の信号強度です。

ついでに、下記の信号強度の説明もわかりやすい。

P87より

近くにいる声の大きい人は、遠くから届く弱い信号を遮ってしまいます。これが遠近問題。同様に周囲に関係のない会話数が増えると干渉が大きくなり、自分に関係のある信号を識別可能な範囲が小さくなります。これがセルフブリージング。

HTTPリクエスト1回のレイテンシの予想

RRC(Radio Resource Controller)の制御プレーンのレイテンシでワーストで数千ミリのオーバーヘッドがあることに着目。

P143より

3G 4G
制御プレーン 200-2,500ms 50-100ms
DNSルックアップ 200ms 100ms
TCPハンドシェイク 200ms 100ms
TLSハンドシェイク 200-400ms 100-200ms
HTTPリクエスト 200ms 100ms
合計レイテンシ 200-3500ms 100-600s

ブラウザの内部の最適化

Webアプリケーションの、「マークアップスタイルシートスクリプト」の複雑な依存関係について ブラウザの内部の最適化を紹介。まずは、

P177より

  • CSSJavaScriptのような重要なリソースはドキュメント上で可能な限り早く発見できるべきである。
  • レンダリングJavaScriptの実行をブロックしないために、CSSは可能な限り早く配信されるべきである。
  • 重要度の低いJavaScriptは、DOMとCSSOMの構築をブロックしないように実行を後回しにすべきである。
  • HTMLドキュメントはパーサに徐々に解析されるため、ドキュメントはサーバ上で生成され次第、部分的にでも随時返信されるべきである。

のようにページの構成と配信に気を使い、さらにブラウザ側に最適化のヒントを与えることも可能(ブラウザ依存)。

P177より

<link rel="dns-prefetch" href="//hostname_to_resolve.com"

<link rel="subsresource" href="/javascript/myapp.js"

<link rel="prefetch" href="/images/big.jpeg"

<link rel="//example.org/next_page.html"

  1. DNS事前解決
  2. 重要度は高いが後ろで読み込まれるリソースの優先プリフェッチ
  3. リソースのプリフェッチ
  4. 指定ページのプリレンダリング

Gmailのパフォーマンス最適化

P196より

  • 最初のレンダリングに必要なCSSと、他のCSSを分離して配信
  • 逐次実行のためにJavaScriptをより小さくチャンク化して配信
  • 新しいJavaScriptをバックグランドでダウンロードしておき、ページ再読み込みの際にアップデートを行う、帯域外アップデートメカニズムの実装

スクリプトのダウンロードは1日1回行われることでサーバの負荷を平準化。さらにローディングバーは分割されたJavaScriptの順次読み込みを表しているらしい。

ドメインシャーディング

HTTP1.xは多重機能を持っていないため、それを補うべくブラウザは1ホストあたり6つまでのTCPストリームを開始する。 サブドメインからリソースを配信することで並列性を高めるテクニックだがモバイルでは、

P191より

DNSルックアップとTCPスロースタートによって発生するオーバヘッドは高レイテンシのクライアントに著しい不利を与えます。 つまり、過度のドメインシャーディングによって不利を受けやすいのはモバイル(3G/4G)クライアントであるということです。

のように不利。

HTTP2.0

HTTPとしてのメソッドステータスコードURI、ヘッダーフィールドといった様式は変更せずに、クライアントサーバ間の通信にバイナリフレーミングレイヤーを設けることでパフォーマンスを強化。

特徴として、複数TCP接続を設けたりするHTTP1.Xで必要だった最適化を取り消し、リクエストを並列化したり優先度付けをしたりできるような仕組みが含まれる。そのため、ベストプラクティスとしては1オリジンに1接続。また並列化が十分に行えることで、ファイル結合やスプライトのようなテクニックも不要となる。

P208より

実験での計測結果を通じて、クライアントの間でより少ない数の接続で通信することで得られる安定したレイテンシ上の利点を確認しました。HTTP2.0上で送信されるパケットの総数は、従来のHTTPよりも40%も少ない場合もあります。サーバ上で同時に多数発生する接続の処理がスケーラビティの問題を引き起こしていましたが、HTTP2.0はこの負担も軽減します。

また大きな特徴として、サーバプッシュの機能もある。クライアントからのリクエストがなくても、サーバから追加リソースをクライアントに送信可能。インライン化していたようなリソースの多くはプッシュ配信を置き換え可能。