[The following posting is by Kazuo Yokosuka of Rikei Corp., a reseller of Apposite’s products in Japan.]
こんにちは。株式会社 理経の横須賀です。Apposite Technologies社WANエミュレータの販売担当をしております。今回は、前回の記事でも予告した通り、ネットワークの世界における遅延について記事を書きたいと思います。長い文章になりますが、どうぞお付き合い下さい。
お客様からApposite社WANエミュレータのお問い合わせを頂くときに、まず、ほとんどのお客様が「パケットに遅延をかけてみたいのですが…」というご要望をお持ちです。なぜか「パケットロスを再現したいです」「パケットの順序を入れ替えたいです」というお声は余り聞きません。日本のお客様にとって遅延はもっとも重要性のある検証項目のようです。
そもそも遅延とは何でしょうか？ネットワークの世界では、遅延とは、「あるデータのパケットが、クライントとサーバー間のネットワークを、『往復』するのにかかった時間」のことを言います。「往復」というところがポイントです。行きと帰りにかかった時間の合計時間なのです。エンジニアの方なら、しばしば端末への疎通をPingコマンドで確認すると思いますが、その時もRTT(round trip time)として、パケットの往復時間が、ミリ秒単位で表示されます。その時間は上りと下りの回線で発生した遅延の合計時間なので、上りと下りでそれぞれ何ミリ秒かかったかは、Pingではわかりません。（ちなみに、Apposite社のLinktropyとNetropyでは、この上りと下りの遅延をそれぞれ設定できます。）
この遅延は、ネットワーク上にあるルータやスイッチが、パケットを処理し次のホップに転送するための時間の累積によって引き起こされている、と思われがちなのですが、WAN回線上では、遅延は主に端末間の物理的な距離が原因になります(ただし、端末間の物理的な距離が短い、LAN内なら、機器の処理による遅延はある程度影響が大きくなります。)。
よく知られているように、電磁波の速度は、「真空中では」光速と同じです。光の速度は非常に高速なので、惑星間の移動でも無い限り、私たちは通常生活において、光の速度を無視して生活しています。（隣町に光が届くのは、0.00…秒後だ、などとは考えませんよね。光の速度については後述します。）しかし、コンピュータプロセッシングの世界においては、その0.00…秒の遅延が重要になってきます。光がほぼ無限大に高速でも、大陸間の通信だけでなく、都市間、町と町の通信にも、その到達にかかる時間は影響を与えるのです。それでは、遅延について、改めて考えてみましょう。
図：Linktropyの操作画面。「Delay」が遅延を設定する項目です。「LAN A→LAN B」「LAN B→LAN A」で、それぞれ上りと下りの遅延を設定できます。Constant:常に一定の遅延を掛ける。Uniform:一様分布。最小値と最大値を設定し、その間の数値の遅延をランダムに発生させ、ジッターを発生させる。 Normal：正規分布。平均値や標準偏差の大小を設定。
遅延を構成する幾つかの要素
あるアプリケーションがデータを送受信する際、遅延の原因となる要素は複数あります。OSI参照モデルの一番上の層から考えてみましょう。
1.アプリケーションまたはホストによる遅延
送信側のアプリケーションが、パケットをTCP/IP層に手渡す時に発生する遅延、また、反対側にある受信側のアプリケーションがパケットを受信・処理し、応答を返す時に発生する遅延、これらをまとめて「アプリケーション遅延」と呼びます。比較的単純なPing/ICMPエコーリクエストなどのアプリケーションでは、このアプリケーションによる遅延は、マイクロ秒単位になります。一秒間で数万件の株式の取引が行われる、コンピュータによる「高頻度取引(HFT)」の世界でも無い限り（ナノ秒単位の遅延が問題になるそうです）、アプリケーション遅延は無視されることが多いようです。もちろん、アプリケーションが複雑になってくると、アプリケーション遅延もより大きくなっていきます。
2.伝送遅延
私達がデータのパケットについて考える時、つい、ケーブル上を伝わっていく一つの箱のようなものをイメージしがちですが、実際には「1」と「0」の数字の長い羅列で、それは1つずつ転送される必要があります。その羅列の一番初めのビットが、ポートから送出され、最後のビットが転送されるまでの時間を「伝送遅延」または「シリアライゼーション遅延」といいます。この遅延は、パケットのサイズが大きい時、さらにネットワークの帯域幅が狭いときに大きくなります。例えば、64バイトのパケットを1Gbpsのネットワーク上で送信するときは、0.5マイクロ秒ほどの時間しかかからず、ほぼ無視できます。1500バイトのパケットでも0.12ミリ秒しかかかりません。ところが、1500バイトのパケットを712kbpsのDSL回線で送ろうとすると、なんと伝送遅延だけで16ミリ秒かかります。伝送遅延に関して言えば、私たちはブロードバンドの恩恵を十分に受けていると言えますね。
3.伝搬遅延
この「伝搬遅延」は、WAN回線上の遅延の主な原因です。ケーブルで結ばれたある地点から、ある地点にパケットを送った時にかかる、物理的な時間のことを指しています。一般的に光の速さは真空中で約30万キロメートル/秒となりますが、光ファイバーを通ると、その速度は約20万キロメートル/秒まで落ちます。例えば、アメリカだと、ロサンゼルスとニューヨークは約5000キロメートル離れています。結果、光ファイバーを通るパケットは、伝搬遅延だけで往復約50ミリ秒かかります（5000km÷20万km毎秒×2）。日本で考えてみると、東京－大阪間が約500キロメートルなので、伝搬遅延は往復約5ミリ秒となります。（こう考えると、日本国内の通信では、アメリカほど遅延が問題にならないのかもしれませんね。）もちろん、これは理論上の話です。ロサンゼルス－ニューヨーク間、東京－大阪間で敷設されているケーブルの長さは、施設内の引き回しなどを考慮すると、もっと長いはずです。
この伝搬遅延が大きいと、いくら100Mbpsや1Gbps等の広帯域の回線を家庭や企業で契約しても、TCP/IP通信では、データ転送速度がそれほど出なくなります(UDP通信はこの影響を受けません。なので、このUDP通信をベースにした、WAN高速化装置も市場にいくつかあります)。TCP/IP通信は、原則的に、データが一つ一つ宛先に届いたかどうか確認してから次のデータを送るからです。衛星を利用したIP通信などでは、特にこれは顕著です(地球局A→衛星→地球局B→衛星→地球局Aで、約500msecかかります。)。こればっかりは、いくらブロードバンド化を進めても、どうしようもない問題です。
4.キューイングまたは輻輳遅延
ある回線上に、その回線の帯域幅以上のパケットが到達してしまった場合、ネットワーク上のルータ(またはスイッチ)は、超過したパケットをバッファに溜め込みます。（そのバッファを更に超過した場合は、パケットは破棄されます。）その、ルータがデータを転送するために、パケットをバッファに保持している時間を「キューイング遅延」または「輻輳遅延」と呼びます。これらの遅延は、どれくらいの量のトラフィックがキューの中で詰まっているのか、回線がどれくらい混雑しているのかによって決まってきます。
まとめると
送信側と受信側の「アプリケーション遅延」、バックボーンネットワークにあるルータやスイッチそれぞれで発生する「伝送遅延」、物理的な距離を往復する時発生する「伝搬遅延」、そして「キューイング遅延」を全て合計した時間が、私達が普段目にしているRTTの遅延なのです。
RTT ＝ アプリケーション遅延 + 伝送遅延 + 伝搬遅延 + キューイング遅延
下の画像は、米ベライゾン社が提供する光ファイバーインターネットサービス“Fios”上で、ロサンゼルスからニューヨークのコロンビア大学のwebサーバーに向けて、tracerouteコマンドを実行したときのものです。
パケットは一旦ロサンゼルスにあるベライゾンの複数のルータまで行き、戻ってきています。（1~7）そこまでは大体10ミリ秒の遅延がかかっています。そのあと、パケットはヒューストン、アトランタ、ワシントンを経由し、アメリカを横断するのに約80ミリ秒かかっています。最終的には、コロンビア大学のサーバーに辿り着く前に、ニューヨークも通っているようです。
下の画像は、Netropyレコーダー(Pingを利用して、実際のネットワークの遅延とパケットロス率を長時間記録し、Netropy上で再現できるソフトウェアです。本体をご購入頂いた方には無料でご利用頂けます。)を使用して、ロサンゼルスからコロンビア大学間の遅延を記録したものです。これによると、これらの拠点間のRTTは、105から129ミリ秒の間を推移していることがわかります。このグラフから、105ミリ秒が、2拠点間の伝搬遅延で、残りの0～24ミリ秒が回線上の輻輳遅延と考えてよさそうです。
このように、一口に「遅延」と言っても、色々な要素から、その遅延は構成されているのです。皆様の参考になりましたでしょうか？「そこは意味が間違っているよ！」「その用語は変だ」等のご指摘があれば、下記メールアドレスまでご一報下さい。以上、「ネットワークにおける遅延とは」でした！次回の記事の内容は未定です。
Posted by 横須賀一雄(kazuo Yokosuka)
お問い合わせ先
株式会社理経
伝送・配信システム営業部
プロダクト営業グループ
〒163-0535
東京都新宿区西新宿1-26-2 新宿野村ビル35F
URL: http://www.rikei.co.jp/
Tel:03-3345-2141 Mail:sales-ipg@rikei.co.jp
http://www.rikei.co.jp/product/maker_ja_214.html
