リアルな遅延を測る仕様

Responsiveness under Working Conditions

Transcript

1. “リアルな”遅延を測る仕様 Responsiveness under Working Conditions CDN⾃作(Y4)ゼミ チューター ⼋⾕航太
2. より良いサービス体験を提供するために遅延は⼤事 • 近年，アクセス回線において帯域が問題になることは⼤きく減った ◦ Webページロード，動画再⽣，ビデオ会議など⼀般的なワークロードは今の帯域幅 （<1Gbps）で問題なく動く ◦ • 無線規格の帯域幅増加，リクエスト多重化 etc. QoEを上げるために，パケットの伝送遅延が⼤きな要素になっている 帯域増やせばいいじゃん こういう時代は終わった 帯域やくざ 2
3. 混雑時の遅延が重要 • あるパケットの平常時の伝送遅延は，サーバーとの距離‧経路やキャッシュの 有無が⼤きな影響を及ぼす • • 混雑時の伝送遅延にはネットワーク機器のキューイングが関わってくる ◦ Bufferbloat ◦ 帯域の太さに関わらずキューイングは発⽣する 任意のネットワーク性能検証サービス（speedtest.com, fast.com etc.）はそ のタイミングのスループット，RTTしか⽰さない ◦ fast.comでRTT20msだからこのネットワークは速い！→諸説 混雑時の伝送遅延を測るにはどうすれば？？ 3
4. Responsiveness under Working Conditions https://datatracker.ietf.org/doc/draft-ietf-ippm-responsiveness/ • 回線に⼗分な負荷をかけ、実際に通信している最中の遅延を測定する • 新規接続と既存接続の両⽅で、⼩さなHTTPリクエストの応答時間を測る • 測定結果を RPM（Round-trips Per Minute） として表現する • ◦ RTTの逆数 ◦ ⾼いほど応答性がよい HTTP1/2でテスト 4
5. Responsiveness under Working Conditions • ⼗分に⼤きい”infinitely large files”を転送するセッションを張る • goodputが増加し続けるかに関わらず上限16として徐々にセッション数を増や していく • その中で⼆つの遅延計測セッションを張る ◦ ◦ Foreign Probe ▪ TCP+TLSハンドシェイク ▪ HTTPの1バイトのGETリクエストとレスポンス Self Probe ▪ 上のInfinitely large filesのセッションで別ストリームとしてGETリクエスト/レ スポンス 5
6. まとめ • 負荷がかかっているネットワークの伝送遅延を測る共通の⽅法がなかった • pingより”リアル”な遅延を測る⽅法が確⽴されつつある 6