Network Quality Estimation in Chrome

docs.google.com

Twitterで見かけたChromeにあるNetwork Quality Estimator サービス(NQE)の紹介のスライドです。

ページのロードの最適化のために、ネットワークの状態を計測するサービスが含まれているそうです。

developerも、RTT estaimate, Download bandwidth estimate, EffectiveConnectionType の3つを使うことが可能らしいです。

以下はスライドを読んでいるときに書いた自分用のメモです

  • 課題
    • 既製品で使えるようにするために、電波状況やTCPの状態へのアクセスはしない
    • 受動的に計測する必要がある
  • RTTは、HTTPレイヤー、トランスポートレイヤー、SPDY(H2)/QUIC (H3) のレイヤーの3つで計測している
  • HTTPレイヤーのRTT
    • レスポンス受信時刻 - リクエスト送信時刻
    • cons: サーバーの処理時間が入ってしまう。H2/H3だとリクエストがほかのリクエストに対してstuckした状態になる。
    • RTTの上限が求められる
  • TransportレイヤーのRTT
    • 定期的に、TCPソケットのRTTの見積もり値を取得し中央値を取得する。
    • ノイズは少ない
    • cons: パケットロスは考慮されない。
    • RTTの下限が求められる
    • UDPソケットでは信頼ができない。
    • POSIXプラットフォームでだけ利用できる
  • QUIC/H2 PING
    • サーバーは優先して処理することが予期される。
    • より現実的な上限が求められる
    • cons: すべてのサーバーがQUIC/H2をサポートしているわけではない
  • 3つの情報を組み合わせて一つのRTTを計算する
  • RTTだけでは十分ではないので帯域を計測する
  • ↓ state of the art
    • Packet pair
    • Packet train
    • Physical layer characteristics
    • Middleware (Network carrier estimates bandwidth)
    • Download large file, Measure TCP stats
  • passiveであることが求められる。計測のために新しいトラフィックを生成しないことが大事
  • ゴールは、利用可能な帯域を計測すること
  • アルゴリズムは、time-windowで計算する。 (詳細はよくわからなかった。
  • 応答性
    • どのくらい速く、ネットワークの状態の変化に追従できるか
    • RTTと帯域は自然のトラフィックをベースに計算する
    • 自然のトラフィックベースではないと不正確になる
  • 応答性の改善
    • ネットワークの情報をID(type, SSID, MCC/MNC, 電波の強さ)と合わせて保存しておく
    • アンドロイドでは、電波の強さを使っている