「ハイパフォーマンス ブラウザネットワーキング」を読んだ

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

目的、モチベーション

バックエンドのパフォーマンス改善の知識を深めるため。

全体の感想

広範にかつ様々なレイヤーでトピックがあり、バックエンド側に限らずネットワーク全般をカバーしていた。
HTTPやWebSocket, WebRTCなどのプロトコルや、モバイルデバイスを含むクライアント側のネットワークの種類の説明などが紹介されていた。
所謂バックエンドのサーバ改善だけを目的に読むのは微妙だが、トータルでパフォーマンス改善して、ユーザ体験を向上するためなら、網羅的に紹介されていてよかったと思う。
ただし、初版が2014年5月で少し古いので、HTTP2の説明は他の本を参考にした方が良さそう。

目次

概要

今回はマイクロサービスにおけるバックエンドに関連の多かったI部しかまとめてないです。

I部　ネットワークの基礎

1章　レイテンシ・帯域幅入門

1.2 レイテンシを構成する多数の構成要素

種類	説明
伝播遅延	メッセージが送信元から宛先まで移動するためにかかる時間。距離を信号の伝搬速度で割ったもの。
伝送遅延	パケットの全ビットをリンクに載せるまでにかかる時間。パケット長とリンクのデータ転送速度の関数。
処理遅延	パケットヘッダの処理、ビットレベルのエラー検知、パケットの宛先決定にかかる時間。
キューイング遅延	パケットが処理できる状態になる前にキューで待機する時間。

1.3 光の速さと伝播遅延

当然だが、通信速度は光の速さが最大となる。光は地球を1秒間で約7周半できるため十分高速だと思われがちだが、実際の通信で何回か往復するため数秒になり、ユーザとしては不十分な速度となる。
そのため、CDNなどを利用してできるだけ物理的な距離を短くするか、圧縮などでデータ量を減らすことが重要。

2章　TCPの構成要素

2.1 3ウェイハンドシェイク

TCP接続を開始する際に、3ウェイハンドシェイクを行う。

1. SYN: クライアントは無作為にシーケンス番号xを選び、SYNパケットを送信。他のTCPフラグやオプションが含まれていることもある。
2. SYN ACK: サーバはxに1を加えてその値を確認応答番号とする。そして自信のシーケンス番号yを無作為に選び、自身のフラグとオプションを付加した上でレスポンスを送信する。
3. ACK: クライアントはxとyの両方に1を足し、xをシーケンス番号、yを確認応答番号としたACKパケットを送信してハンドシェイクを完了する。

これは数十msかかりコストが高いため、TCPコネクションの再利用の最適化が重要になる。

2.2 輻輳回避と輻輳制御

2.2.1 フロー制御
受信側が処理できないほどの大量のデータを送信しないように、受信ウィンドウサイズ(rwnd)でバッファサイズを指定できる。

2.2.2 スロースタート
クライアントとサーバ間のネットワークの利用状況に応じて、通信量をコントロールした方が効率的に利用できる。
しかしネットワークの状態は絶えず変化し、接続時には利用状況がわからないため、徐々にウインドウサイズを大きくしていくことで、解決する。
輻輳ウインドウサイズは、指数関数的に増加させていく。

そのため、TCP接続を再利用しない場合は、スロースタートしながら処理を開始するために、レイテンシーは大きくなる。

2.2.3 輻輳回避
パケットロスが発生したときに、セグメントを倍数的に減少させる。

2.5 TCPの最適化

サーバ設定のチューニング

• サーバのカーネルのバージョンを最新にする
• TCP 初期ウィンドウの増加
• アイドル後のスロースタートを無効化
• ウインドウスケーリングを有効にする

アプリケーションの動作のチューニング

• 不要なデータ送信を除去する
• 送信データを圧縮する
• 物理的に近い場所にサーバを設置する
• TCP接続を再利用

3章　UDPの構成要素

4章　TLS

4.2 TLSハンドシェイク

下記のような流れで、TLSによる接続を確立する。

1. TCPコネクションを確立
2. クライアントが平文で動作仕様を送信
3. サーバがTLSプロトコルのバージョンや暗号スイートを決め、証明書を返す
4. クライアントがレスポンスに同意し、RSAかDiffie-Hellman鍵交換プロセスを開始し、セッションのための共通鍵を生成する
5. サーバはクライアントから送られた鍵交換パラメータを処理し、MACを検証することでメッセージの整合性を確認
6. クライアントは、サーバからのメッセージを共通鍵で復元してメッセージのMACを検証

4.3 TLSセッション再開（TLS Session Resumption）

TLSハンドシェイクはレイテンシと計算コストが必要となる。これを緩和するための機能が用意されている。

4.3.1 セッションID
サーバがセッションIDとパラメータ情報をキャッシュし、クライアントもセッションIDをキャッシュすることで、暗号スイートと鍵の生成プロセスをスキップして、パケットの往復を一回削れる。ただし、サーバがすべてのクライアントのセッションキャッシュを維持し続ける必要があり、大規模サービスでは複数のサーバ間でセッションを利用できるような工夫が必要。

4.3.2 セッションチケット
セッションIDでのデプロイメントの問題を払拭するために、セッションチケットが公開された。
この仕組みでは、サーバではセッション情報を保存せずに、TLSハンドシェイクの最後で、クライアントにセッションデータを返してクライアントが管理する。このセッション情報はサーバの秘密鍵で暗号化されているため安全。

4.6 TLSレコードプロトコル

4.7 TLSの最適化

4.7.4 TLS False Start
TLSのハンドシェイクの途中から、アプリケーションのデータの送信を行うことで、パケットの往復を減らすことができる。
ハンドシェイクのロジック自体は変更せずに、クライアントがデータを読み取れるようになる鍵の交換をした時点から、データのやり取りを行う。

4.7.6 TLS圧縮

サーバでのTLS圧縮は無効にすべき。
トランスポートレベルのTLS圧縮はコンテンツタイプを識別しないため、画像や動画などすでに圧縮されているデータを更に圧縮しようとする。そのため、二重に圧縮することでCPUを無駄に使用してしまう。

4.7.7 証明書チェーンの長さ

証明書チェーンのサイズを小さくするために、必要のない証明書はチェーンに含めないこと。
また、ルート証明書を含める必要もない。

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

5章　ワイヤレスネットワーク入門

6章　WiFi

7章　モバイルネットワーク

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

III部　HTTP

9章　HTTPの歴史

10章　Webパフォーマンス入門

11章　HTTP 1.x

12章　HTTP 2.0

13章　アプリケーション配信最適化

IV部　ブラウザAPIとプロトコル

14章　ブラウザネットワーク入門

15章　XMLHttpRequest

16章　Server-Sent Events

17章　WebSocket

18章　WebRTC

次のアクション

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