ネットワークの遅延とは?パケットキャプチャからみる遅延

ユーザから「ネットワークの遅延をはかりたい」という要望をいただくことがあります。ネットワーク機器や計測器には、「遅延」を測定できるものが数多く存在します。そのくらいネットワークを監視する上で、遅延をはかることは重要だと考えられています。

今回は、ネットワークにおける「遅延」の一般的な解釈と計測する手法について解説します。

ネットワークの遅延とは

遅延といった場合、まずは「片側遅延」なのか「往復遅延」をはっきりさせる必要があります。
ネットワークでは特に断りがない場合、「往復遅延」を指すことのほうが多いように思いますが、この2つは2倍近く数値が違いますので注意します。

片側遅延と往復遅延

片側遅延と往復遅延

往復遅延はラウンドトリップタイム(RTT)ともいい、「パケットが往復するのにかかった時間」を指します。
エンジニアであれば、端末への疎通確認としてPingコマンドを使用したことがあるかと思いますが、応答で表示されている時間は往復遅延です。上りと下りでそれぞれ何ミリ秒かかったかは、Pingでは測定できません。

Ping応答画面1

Ping応答画面

では、このPing通信を遅延の観点からもう少し細かく見てみましょう。
PCから外部のWEBサーバに対してPing要求を行った場合のパケットをPCのWiresharkでキャプチャします。
そのときの結果は以下です。今回は、Wiresharkの時刻をわかりやすくデルタタイム(前のパケットとの差分時間)で表示しました。

Ping応答画面2

WiresharkでのPing通信の結果

このときのコマンドのRTTとWiresharkのデルタタイムの数値はほぼ同じ結果が得られます。なぜならばキャプチャポイントとPingの発信するポイントが同一だからです。
キャプチャポイントがPing発信ポイントと離れている場合は、当然、RTTとデルタタイムはかけ離れた数値となります。

この一連の流れとかかった時間を図で表した場合、以下のようになります。

ネットワーク遅延測定

ネットワーク遅延を分解した図

この中で①と③はネットワークに関わる遅延、②と④はアプリケーションに関わる遅延です。

ネットワークに関わる遅延とアプリケーションに関わる遅延

私達が実際に体感する遅延とは、上の図で示した通り、遅延とはネットワークに関わる遅延とアプリケーションに関わる遅延の合計です。
それぞれにどのような種類の遅延があるかご紹介します。細かいことをいうともっとたくさん種類があるかと思いますが、今回は、はじめに考慮しておくべき代表的なものを挙げたいと思います。

ネットワークに関わる遅延

伝搬遅延

データがある地点からある地点まで到達するのにかかる物理的な時間のことです。距離が遠ければ遠いほど伝送遅延は大きくなります。また、伝送する素材などによっても変わってきます。
たとえば、空気中の光ファイバの伝搬速度の公称値は約20万km/秒と言われています。(真空中だと光の速さは約30万km/秒と理科の時間で習ったと思いますが、空気中だと結構落ちるみたいですね。)つまり、1msで200km、1mあたり5nsの遅延が発生します。
メタルケーブル(銅線)だと構造や素材にもよりますが、光よりもさらに遅延が大きくなります。

ネットワーク機器の挿入遅延

ネットワーク機器の入力インタフェイスでパケットを受信して、ルーティングやスイッチング処理を行い、出力インタフェイスから電気信号に変換して送信を完了するまでの時間のことです。パケットは、ネットワーク上で様々な機器を経由して最終的な宛先まで届きますが、それぞれの機器で遅延は発生します。
細かい話をすると、それぞれの工程でキューイング遅延やシリアル化遅延などと名称がありますが、ここではざっくりとネットワーク機器の挿入遅延と呼ぶことにします。
この遅延は、機器の処理の処理能力、ネットワークの混雑状況、回線速度、処理をするパケット長などの環境により変化します。

アプリケーションに関わる遅延

アプリケーション遅延

ホストがパケットを受信し上位層に渡して、処理して、下位層に渡す際に発生する遅延です。要求元(クライアント)と要求先(サーバ)のそれぞれで発生します。
ホストの処理能力、アプリケーションの種類、処理の混雑状況により変化します。

ネットワークの遅延をはかる方法

上記のことから、遅延はこのように分解できます。

RTT = ネットワーク遅延 + アプリケーション遅延

パケットのやり取りを時間経過で表すと、各遅延は以下の時間の合計となります。

ネットワーク遅延チャート

クライアント-サーバ間の遅延チャート

ひとことに「遅延」といっても遅延の種類は複数あることがわかりました。したがって、遅延を解消するためには、まずはどこに原因があるかを突き止める必要があります。自力で調査することも可能ですが、原因となるネットワーク機器がたくさんある場合や複数のアプリケーションが関連しているケースでは非常に作業が煩雑になります。
このような場合は、ネットワークの可視化ツールを使えば簡単に知ることができます。

当社で開発販売しているパケットキャプチャ製品「SYNESIS」は、キャプチャしたパケットから通信ごとにサーバ時間、クライアント時間、ネットワーク時間を計算し表示する機能があります。このようなツールを使用するとどの時間がボトルネックになっているかを確認できます。

SYNESIS-APM画面

SYNESIS APM/NPM解析画面

SYNESISには、このほかにも遅延測定をする上で役に立つ機能があります。
ご興味がありましたら、以下よりお問い合わせください。

SYNESIS お問い合わせ

RAILモデルでの遅延

比較としてGoogle Chromeチームが発案したRAILモデルでの遅延についてご紹介します。
RAILにおける遅延に対するユーザの認識は、以下の記述のとおりです。

ここでの「遅延」とは、Response (応答)、Animation (アニメーション)、Idle (アイドル処理)、Load (読み込み)のそれぞれのパフォーマンスを指しています。このコンテンツは、Webアプリケーション開発者を対象とした遅延の計測方法となっています。
1秒以上の遅延は、作業に支障をきたすレベルという基準は納得です。

あとがき

「遅延」に対する認識は、ネットワークエンジニアとアプリケーションエンジニアでも異なる場合がありますので、常に定義を確認するようにしましょう。