【図解】NW遅延とゆらぎ(ジッタ)の違いと発生原因と調査~realtime(音声/動画)とbulkでの考え方~ | SEの道標
ネットワーク通信の流れを把握する

【図解】NW遅延とゆらぎ(ジッタ)の違いと発生原因と調査~realtime(音声/動画)とbulkでの考え方~

ネットワークにおける遅延とは

ネットワークの高速化は今も顕著であり、10Gbps も当たり前のように普及してきました。バックボーン NW で使われている 40Gbps, 100Gbps のネットワークもそのうち一般家庭にも来るかもしれません。

ところで、高速であることと遅延が小さいか大きいか、というのは別の話です。例えば 1 Gbps のネットワークよりも遅延の大きい 10 Gbps のネットワークもありえます。

ネットワーク速度というのは『一度に送信できる量の多さ』であり、トラックに例えると荷物の容量です。

一方、ネットワーク遅延というのは『送信パケットが相手に届くまでの時間』であり、トラックに例えると、トラックが荷物を目的地まで送る時間です。

例えば先程の図の通り、CL1 と CL2 が同時にファイル転送を開始したときに、SV1 では先にファイルが到達しますが、すぐに SV2 に追い抜かれます。

『ファイル転送』という通信では (数 msec の) 遅延はあまり関係ありませんが、これが音声データだったらどうでしょう

一般に音声や TV 会議等の通信については、高速である必要性は薄く、低遅延によりリアルタイムな会話が可能となります。

ネットワーク遅延の種類

ネットワークの端末間の遅延「エンド to エンド遅延」は以下の 4 種類に分割できます。

  1. 処理遅延 (Processing Delay)
  2. キューイング遅延 (Queuing Delay)
  3. シリアル化遅延 (Serialization Delay)
  4. 伝搬遅延 (Propagation Delay)

処理遅延 (Processing Delay)

処理遅延とは、NW 機器の NIC に入ってきたパケットのヘッダを書き換え、出力 NIC 用の Output Queue (ルータのメモリに存在するソフトウェアキュー) に格納するまでに掛かる時間を示します。

NW 機器では処理のほとんどがハードウェア処理ですが、一部の処理で CPU によるソフトウェア処理を行いますので NW 機器の CPU 負荷が高い状況では処理遅延が増大する可能性があります。

キューイング遅延

キューイング遅延とは、Output Queue (ソフトウェアキュー) に格納されたパケットが tx-ring (ハードウェアキュー) に到達するまで待つ時間を示します。

このキューイング遅延は、輻輳したときや、シェーピングの設定値を超えた通信量を出力するときに発生します。なのでそのときの状況に依って大きく変化します。

シリアル化遅延

シリアル化遅延とは、出力用 NIC がパケットを出力し始めてから出力し終わるまでに掛かる時間を示します。

このシリアル化遅延は、{ パケットサイズ / インタフェース速度 } で計算できます。例えば 1000Base-T のインタフェースから 1250 Bytes のパケットを出力するときは、1,250 Bytes / 1 Gbps = 10 Kbits / 1 Gbps = 10 μsec となります。

なのでシリアル化遅延はインタフェースの速度が速ければ速い程、小さくなります。

伝搬遅延

伝搬遅延とは、伝搬する電気や光が、媒体 (メタルケーブルや光ケーブル) を進むために必要な時間です。

この伝搬速度は、{ ケーブルの長さ / 伝搬速度 } で決まります。例えばガラスの中では光は一般に 190,000 km/s 前後と言われていますので、100m の光ケーブル の伝搬遅延は 100 m / 190,000,000 m/s = 0.53 μsec となります。

遅延とゆらぎ(ジッタ: jitter)の違い

先程の遅延の種類から分かる通り、③、④は遅延時間が一定となりますが、①と②については状況によって遅延時間が変化します。遅延時間の変化度合いを「ゆらぎ (ジッタ : jitter)」と呼びます。

ジッタは DNS や http 等の通信においてはあまり気にすることはありませんが、音声やリアルタイム動画通信 (LINE や Teams, Zoom 等のアプリ) については重要な指標になります。

音声やリアルタイム動画通信は、遅延が一定であれば (その一定量だけ音声や画像が遅れますが) 音質や画質には影響はありません。

なぜなら音声/動画パケットを一定時間バッファに溜め、それから出力 (再生) することにより遅延の影響を吸収するからです。

ですが、これが変化してしまう (つまりジッタが大きくなる) とバッファに溜まるパケットの間隔やバッファ時間自体が乱れ、バッファがうまく機能しません。結果、音質や画質が乱れてしまうのです。

QoS で音声や動画のパケットを優先制御させるのは、遅延を短くする効果もありますが、それよりもジッタを小さくすることによる効果が大きいです。

ただし、帯域制御には遅延を小さくする効果はありません。帯域制御は遅延があっても通信量が設定値以上になればよいのです。

優先制御と帯域制御の違い等、QoS の仕組みについては以下をご参照下さい。

【図解】初心者向けQoSとキューの仕組み〜優先制御/帯域制御やToS/CoS,shaping/policingの違い, HW/SWキュー~
QoS とは? Quality of Service の略で、サービス (本来的...

また、もう一つの注意点として、YouTube のような既に録画されている動画を再生する場合は優先制御する意味はありません。あれはリアルタイムのストリーミング再生ではなくオンデマンド再生なので、帯域が空いている時間に前もって一気にダウンロードしてしまうほうが効率的です。

リアルタイムのストリーミングや音声は、前もってダウンロードができないのに、事象発生と同時にすぐに通信されなければならないのが難しい点なのです。

Pathpingによるネットワーク遅延調査方法

『ネットワークが遅いな』と感じる場合、pathping コマンドを使って調査することができます。

例えば pathping では tracert と同様に ICMP を使って経路を調べます。

図解 tracert の見方 ~WindowsとLinuxの違い(icmp/udp),経路途中のIPが表示されない理由~
traceroute (tracert)とは tracert (Linux 系の...

そして応答のあった IP に対してそれぞれ 100 回ずつ Ping を打ち、応答時間 (RTT) やパケット損失数を表示します。以下に実行例を示します。

経路途中に RTT が大きくなるポイントがあったらそこが遅延の原因箇所候補です。ただ、注意点として、ルータ等は本来ルーティングするのが仕事であり、ルータの IP アドレス宛の ICMP (ping) に対しては優先度を下げて応答する機器もあったりします。その機器の応答 (RTT) が遅くてもその次の機器の応答が速い場合はそのケースの可能性があります。

コメント

タイトルとURLをコピーしました