ダウンロードは速いのに、なぜクリックが遅く感じるのか

大きなファイルを速くダウンロードしたのに、どのクリックも遅く感じるのは矛盾ではない。容量は一秒あたりにどれだけ動かせるかを示し、往復時間は有益なことが起きるまでにやり取りがどれだけかかるかを示す。前者を改善しても後者には何の効果もなく、後者こそ人が入力やクリックや通話で気づくものだ。測るべきは回線ではなく苦情である。

速いファイル、遅いクリック：二つの異なる数値

一括転送はデータを絶えず流し続けるため、個々のリクエストが待っていても健全な速度を報告できる。多くのベンチマークは複数の接続を同時に開くので、単一のリクエストが遅いままでも合計値は上がる。二つの結果は両立するもので、遅延を訴える利用者に高い方の数値を示すのは信頼を失うやり方だ。

ページの読み込みは、名前解決、接続の確立、リクエスト、応答、そして依存するリクエストが続く小さなやり取りの連鎖だ。各段階が往復時間を再び支払うので、遅延の大きい経路は容量が豊富でも遅く感じる。

トンネルは独自の移動と処理を加え、地図上のラベルより経路の方が重要だ。同じ国の二つの出口でも、一つの目的地までの道は大きく異なりうる。二十ミリ秒の差でもページの体感は変わるが、スループットの数値はほとんど動かない。だから出口の選択は旗のアイコンではなく遅延のサンプルに従うべきだ。

測るのは苦情であり、回線ではない

利用者が言った文に合う測定を選ぶ。遅いダウンロードには正しい方向の持続速度、途切れる通話にはそのアプリ自身の統計、起動の遅いページには名前解決と接続確立の時間が要る。

ping -c 20 10.60.0.5
curl -sS -o /dev/null -w 'ttfb=%{time_starttransfer} rate=%{speed_download}\n' https://files.plant.example/1gb.bin
iperf3 -c 10.60.0.5 -t 10 -P 4

一つ目のコマンドは予測どおりに応答するホストへの往復サンプルを与え、二つ目は最初のバイトまでの時間と一つの接続の持続速度を報告し、三つ目は四つの並列ストリームで合計スループットを測る。同じ日の同じ時刻に同じ目的地に対して実行し、朝と夜のサンプルを比べても測定ではなく物語ができるだけだと心得る。

出口を比べるときは目的地を固定する。サーバーとトンネルの両方を変えると変数が二つになり、どちらが効いたのか分からなくなる。各出口は、一度のサンプルが経路変更や雑音の多い一分間に当たりやすいので、少なくとも三回実行する。最良値より中央値の方が役に立つ。

ICMPは答えではなく手がかりとして扱う。応答するホストがエコー要求を、あなたのアプリが使う経路とは別の経路で処理することはあるし、応答が一つ落ちたからといって全アプリがパケットを失っている証拠にはならない。

負荷時の遅延は待ち行列の問題だ

人を最も混乱させるのは、暇なときは快適なのにバックアップ中は使い物にならない接続だ。それは容量ではなく待ち行列である。飽和した上り回線は他のあらゆるパケットの前にバッファを作るので、キー入力はアップロードの一部の後ろで待つ。

ping -c 20 10.60.0.5 &
iperf3 -c 10.60.0.5 -t 20 -R -b 20M

一つ目のコマンドは背後で遅延をサンプリングし、二つ目は逆方向を飽和させる。転送中に ping の時間が跳ね上がり、その後に戻れば、経路障害を発見したのではなく bufferbloat を再現したことになる。修正は通常、待ち行列管理の設定、背景速度を下げること、または一括転送を対話経路から外すことだ。

任意の背景トラフィックを減らすことは、出口の国を変えるより効くことが多い。安く、元に戻せ、一分で試せるからだ。待ち行列を管理できないなら大きなアップロードは勤務時間外に予定し、日中に走らせる必要があるなら速度を制限する。ルーターが対応しているなら待ち行列管理の設定がより良い修正だ。

一つだけ変えて、同じ条件どうしで比べる

暇なときの遅延が大きい場合は、目的地を固定して出口を比べ、次に最良の候補について経路を比べる。定常スループットが低い場合は、容量、サーバー負荷、クライアントの処理が別の限界だから、代わりにそれらを見る。

何を、どの目的地に対して、何時に、どの設定で測ったのかを書き留める。この四つの事実がなければ比較は再現できず、次の人はゼロから始めることになる。

そしてチケットの主張に道具を合わせる。「インターネットが遅い」は測定ではなく、「このホストへの最初のバイトに900 msかかったがスループットは良好だった」は測定であり、容量ではなく遅延を直接指している。