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

Book

www.oreilly.co.jp

TCP, TLS, HTTPといったアプリケーションよりも低いレイヤーについて基本的な構造を説明し、パフォーマンスの観点からエンジニアはどう関わるべきかが書かれている。文章は読みやすかった。読み飛ばした部分もあるが10日間ほどで読み終わった。380ページ。

以下、自分用メモ。

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

  • ネットワークのパフォーマンスを決める２つの要素がある
  • レイテンシは要するにパケットを送信してから受信するまでの時間。光ファイバーを通る時間やルータの処理時間などの計。
  • 帯域幅は要するに速度(bps)。
  • 光ファイバーを通る時間(propagation delay)は光の速さが29km/sであり、限界が決まっている。
  • 感覚的に数百ミリ秒遅れると人間は遅れを認識する。
  • ラストワンマイルのレイテンシ。要するにパケットが太平洋を渡っても、最後に複数のプロバイダを経由することでレイテンシが発生してしまうこと。
  • ほとんどの場合、帯域幅ではなくレイテンシがパフォーマンスのボトルネック。

2章 TCPの構成要素

  • TCP接続で3ウェイハンドシェイクから始まる。ここでもクライアントがデータを送信し始めるまでに1往復分のレイテンシが発生している。
  • フロー制御。データの送信サイズがウィンドウ値で制限されてしまう。データ受信側が処理しきれないデータ量を送信側が送信してしまうのを防ぐための仕組み。
  • スロースタート。データの送信サイズは小さい値から始まって、１往復ごとに送信サイズが大きくなっていく。ネットワーク自体の許容量を超えないようにするための仕組み。
  • 上記のようにデータサイズが制限されることにより発生するレイテンシ(データを余計に送信するためデータの往復が発生するなど)がボトルネックであり、帯域幅はそんなに関係ない。
  • ウィンドウ値を大きくしたり、スロースタートリスタートを無効にしたりするとパフォーマンスにはいいらしい。
  • そもそもとして、CDNを利用してデータを近くでやり取りするようにするといい

3章 UDPの構成要素

  • 受信側に確実に届けるための仕組みがない。このため信頼性は低い。
  • その分、余計なデータの往復などが発生しないため、レイテンシの発生が少ない。
  • NATの話が出てきた。ここでも処理時間(レイテンシ)が発生する
  • 疲れてたので読み飛ばしながら進んだ。

4章 TLS

  • HTTPSのSのやつ。暗号化、認証、データ整合性を提供する。要するに、認証局を利用して、クライアントから送信されたデータが本当にクライアントから送られてきたものかどうかを保証する。逆も同じ。
  • TLSハンドシェイクから通信を始める。最大２往復。
  • １往復目で使用するTLSのバージョンや多分だけど利用できる認証局をクライアントが送信して、サーバがバージョンや認証局はこれを使います、っていうレスポンスを返す。
  • ２往復目で暗号化のために共通鍵のやり取りを行う。
  • TCPハンドシェイクと合わせると、最大で３往復分のレイテンシが発生する。暗号化の計算によるレイテンシは大したことないらしいので、ここがボトルネックとなる。
  • パケットはすでに光速で近い速度なためここは大きなレイテンシ改善は見込めないが、CDNを利用することで距離を近くすることができる。つまり、CDNにTCP・TLSハンドシェイクを行わせることでレイテンシ改善が見込める。
  • これが動的コンテンツのやり取りにおいて、キャッシュ機構は使用しないのにCDNを利用する理由。

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

  • パフォーマンスは周波数帯域幅とシグナル強度に依存する

6章 WiFi

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

  • 3G,4G,LTEの規格について
  • RRCは物理層での接続を管理する。TCPハンドシェイクが行われる前段階。ここでもレイテンシが発生する。
  • 読み飛ばした

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

  • 読み飛ばした

9章 HTTPの歴史

  • 0.9 => 1.0 => 1.1 => 2.0
  • 0.9のリクエストはGETメソッドとパスの１行で構成される。めちゃシンプル
  • 1.0でキャッシュ(Expires)がレスポンスで返るようになった
  • 1.1でKeep-Alive接続が可能になった
  • 2.0はパフォーマンス向上が主なテーマ

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

  • JavaScriptの実行はCSSにブロックされる可能性がある。
  • パフォーマンスを計測できるツールを使う、そして計測する。
  • ウォーターフォールチャートがパフォーマンスを計測する上で見やすい
  • ブラウザがやっているパフォーマンス最適化

11章 HTTP 1.x

  • キープアライブ接続がとにかく重要！
    • TCP・TLSハンドシェイクを省略できるのでレイテンシ削減に繋がる
  • クライアントは一度に一つのリクエストしか送れない、サーバは一度に一つのリクエストしか処理できない、といったように並列処理ができないという課題がある。HTTPのHoLブロッキング(TCPのHoLブロッキングとは別)。
  • ここを解決できればパフォーマンス改善に繋がる。これをやりたいのがHTTP2.0。

12章 HTTP 2.0

  • パフォーマンス向上に主眼が置かれている
  • バイナリフレーミングレイヤー(？)。これでクライアントから複数のリクエストを一度に送信できるようになるらしい
  • サーバからプッシュで画像などを配信できるようになるらしい

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

  • 定番のパフォーマンスベストプラクティス
    • DNSルックアップを減らす(キープアライブ接続)
    • TCP接続の再利用(キープアライブ接続)
    • HTTPリダイレクトを減らす(新たにDNSルックアップやTCP接続が必要になるため)
    • 不要なリソースはそもそも配信しない
    • リソースのキャッシュ

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

  • 印象に残っていない

15章 XMLHttpRequest

  • ajaxで使うやつ
  • CORSを気にしている

16章 Sever-Sent Events

  • 読み飛ばした
  • サーバ => ブラウザ

17章 WebSocket

  • 読み飛ばした
  • サーバ <=> ブラウザ

18章 WebRTC

  • 読み飛ばした
  • リアルタイム通信で使用する(Web会議など)