アップロード中にVPNが遅く感じる理由：待ち行列遅延

バックアップのアップロードが始まり、転送カウンターは健全に見えるのに、ビデオ通話はぐちゃぐちゃになる。その数字が示す意味で回線の帯域が足りないわけではなく、パケットはどこかの待ち行列で待っており、対話型のパケットは大容量データの後ろに並んでいる。これが待ち行列遅延で、一般にバッファブロートと呼ばれる。VPNが独自の待ち行列を加えることはあるが、問題を単独で生み出すことはまれだ。

帯域と遅延は別の測定値

スループットは毎秒どれだけデータが動くかに答え、遅延はひとつのパケットが経路を横切るのにどれだけかかるかに答える。飽和した回線は、バーストが終われば待ち行列が回線速度で排出されるため、大きな滞留を抱えても良好なスループットを報告できる。対話型トラフィックが最初に苦しむのは、通話が数ミリ秒ごとにパケットを必要とし、最後に大きなファイルが届けばよいわけではないからだ。したがって速度テストの結果だけを測ると、あなたを調べに向かわせた症状が隠れてしまう。

負荷時の方向にも注目してほしい。アップロードのバッファが満杯だと、ダウンロード容量が遊んでいる間も他のすべてが遅れる。

負荷をかけて往復時間を測る

静かな回線で基準値を取り、その後、制御した転送をひとつ走らせながら同じ測定を繰り返す。絶対値ではなく二回の実行を比べる。

ping -c 20 -i 0.2 203.0.113.5
dd if=/dev/zero bs=1M count=50 | ssh [email protected] "cat > /dev/null"

最初のコマンドは往復時間を標本化し、二番目は速度テストサービスを使わずに持続的なアップロードを作る。平らなままの基準値のあと、数百ミリ秒上がる負荷時の実行、それが探すべき兆候だ。ネットワークによってはICMPの優先度を下げるので、pingは手がかりとして扱い、アプリ自身の遅延表示で確かめる。従量制の回線では、再現できる対比が長い飽和より大切なので、テストを短く保つ。

待ち行列をボトルネックの場所へ移す

待ち行列管理は、滞留を実際に抱える機器でしか役に立たない。ルールを追加する前に、インターフェースが何をしているかを調べる。

tc -s qdisc show dev eth0
tc qdisc replace dev eth0 root fq_codel

showコマンドは現在の規律と滞留・破棄のカウンターを報告し、このインターフェースがボトルネックなのか、単にトラフィックを通しているだけなのかを教えてくれる。根の規律を公平な待ち行列アルゴリズムに置き換えると、短いフローは大容量データと共有するひとつのFIFOではなく、自分たちの順番を得る。ルーターがボトルネックなら、習慣でトンネル機器ではなくルーターのWANインターフェースに適用する。以前の設定を残し、バルクのレートが少し下がっても使える通話との交換としては悪くないので、負荷時の応答性と転送レートの両方を再試験する。

トンネルが変えるもの、隠すもの

VPNは暗号化とホップをひとつ加え、トンネルの外の機器から個々のフローも隠す。上流の機器がアプリごとの優先制御を提供する場合、元の会話ではなく暗号化されたパケットが見えるその機器にとって、これは重要だ。トンネル自体を終端するルーターは見え方も作業負荷も違い、その内側で分類できる。どちらの構成でもアクセス回線の待ち行列はなくならず、遅延がたまるのは通常そこだ。

遅延が負荷に追随しないなら、待ち行列の調整をやめて、Wi-Fiの状況、パケットサイズの問題、あるいは一本の不良な出口経路といった別の場所を見る。測定なしで適用した待ち行列設定は、謎を移動させるだけだ。