遅延（レイテンシ）とはなにか？

インターネットでデータを送るときには、あたりまえだが、必ずいくらかの時間がかかる。これを遅延(latency)という。

よくインターネットのサービスで独自の技術により低い遅延（low latency）を実現したとかいう記事がでる。これがなにを意味するか、ネットワーク技術が専門のはずのIT企業の社員でも、全然わかってないひとが多い。

というわけで今回はインターネットでの遅延についてよくある誤解を紹介して、本当はいったいなんなのかということを説明しようと思う。

まず、よくサイトが重いとか、インターネットがめちゃくちゃ遅いというのと遅延が高いというのとは本質的には別の現象なんだが、よく混同されている。もちろんインターネットが遅くなっている場合には結果的に遅延も大きくなっていたりする。しかし、サイトが重くなったり、インターネットが遅くなっている本当の理由は、だいたいサーバの処理が追いついていないか、インターネットの帯域(bandwidth)が不足してパケットロスが発生している場合だ。遅延とはサーバが軽くてインターネットも空いている良好なネットワーク環境でも発生する時間の遅れのことだ。

再送処理などやウェイトなどのプログラム的な理由で発生する遅延を除くと、ネット上で遅延が発生する理由は次の４つしかないと考えて良い。

（１）光の速度での移動時間
（２）データの転送時間
（３）バッファリングされている時間
（４）インターネットの経路による遅延

（１） インターネットによるデータ転送は光ファイバーだろうが、銅製の電話線だろうが、結局のところ電磁波を利用しておこなわれているので光速で実行されていると考えて良い。実際は真空中じゃないのでもっと遅いはずだが、とりあえずは光速を秒速３０万キロメートルと考えると、１ミリ秒でも３００キロメートルは移動可能だ。東京−大阪間でも２ミリ秒はかからない計算だ。日本国内であればだいたい１０ミリ秒以下と考えてもいいだろう。国内だったら、どんなに遠くても1フレームもかからないぐらいだ。

（２）ほとんどのひとは自分が使用しているインターネット回線の帯域(bandwidth)の広さで、ネットの速さが決まると思っている。自宅のインターネット回線だったら12MbpsのADSLよりも100Mbpsの光回線のほうが速いと思っているし、PDC携帯のiモードよりも3G(FOMA)携帯のiモードのほうが速いと思っている。本当は回線の帯域が広いことと遅延が低いことはイコールではないのだが、まあ半分以上は正しいと考えていいだろう。なぜなら、帯域が広いと同じ大きさのデータの転送時間は短くなるからだ。１００キロバイトのデータを転送する場合には実行転送速度が1Mbpsしかでていない場合は０．８秒（８００ミリ秒）かかるが、10Mbpsでていると、０．０８秒（８０ミリ秒）で済む。したがってデータ量が大きい場合は（１）の遅延は無視できて、大部分はデータの転送時間による遅延のほうが全然大きくなる。

（３）次に重要な遅延の原因はバッファリングだ。これは意外と重要だが、（２）ばっかりに気を取られて混同されたり見落とされがちな要素だ。特にデータストリーミングなどのリアルタイム系のサービスの場合はここの遅延が全てだといっていい。実はストリーミングの場合は（２）による遅延はサービスにはまったく影響しない。なんとなく回線の帯域が広くなったり、CPUが速くなると、遅延も減るようなイメージをもっているひとが多いが、まったく関係ない。証明は簡単で例えばバッファリング時間を1秒とろうが１００ミリ秒とろうが、その1秒だか１００ミリ秒のバッファに相当するデータを転送したり処理したりする時間はそれぞれ1秒ないし100ミリ秒以内でおこなわないとそもそもリアルタイム処理できない。リアルタイムに処理できている以上、バッファしている時間以内でデータは処理しているということだ。その限りにおいては実際には何ミリ秒かかろうが、ユーザからみた場合にはバッファされている時間はまったく変化しないのだ。

（４）ネット上で通信する場合に間にルータがあった場合にも遅延は増える。これはどう考えればいいかというと、まあ、対応策としては諦めるというのが正しいわけだが、まあ、発生理由については説明しよう。これはIP層で前述の（２）と（３）による遅延が発生していると考えればよい。プログラマがネットワークプログラムを書く場合はアプリケーション層で（３）のバッファリングをおこなっているわけだが、その場合はエンドツーエンドのPC間で（２）と（３）の遅延を考えればいい。しかし、実際にはIP層においては複数のルータを通じて通信しているわけで、PC−ルータ間、ルータ−ルータ間、ルータPC間のそれぞれにおいて（２）と（３）の遅延を考えて、それの総和がエンドツーエンドの通信の遅延にプラスされることになる。ただ、その場合の（２）でのデータ長だが、パケット単位で分割されて送られているので、最大のパケットサイズのときデータを送るのに必要なデータ転送時間で考えればいい。（３）のバッファリングについてはそのときにキューが貯まっていればそのぶんだけプラスされるが、なければゼロだ。

以上が遅延が発生する基本的な原理だ。上記の考え方の応用でほとんどの遅延は説明可能だ。結局のところ、遅延をどうやって減らすかを考えるとき（１）の光速どうこういうのはほぼどうしようもなく（４）のルーターによる遅延も回避不可能だ。となると（２）と（３）をどう減らすかがポイントになる。（２）については要するに通信するデータの長さを減らすというすごく地味な話になる。（３）については、バッファリングするデータをどうやって減らすのかというのがポイントだ。

これらって実は高度なアルゴリズムを駆使して実現するとかいうような類の話ではない。むしろ、音声データを送信する場合の遅延を減らす方法というのは、なにか特別なプロトコルを開発するというよりは、たんに圧縮をやめるということだったりする。前述したように圧縮をやめると遅延が低くなる理由は、圧縮解凍のアルゴリズムの処理に時間がかかるからではない。残念ながらまったく関係ない。圧縮する場合には一定程度以上の時間長のデータをバッファリングする必要があるからだ。VPNやリモートデスクトップで発生する遅延もなんかのCPUパワーの消費で遅延が追加されるわけではなく、VPNやリモートデスクトップのためのバッファリング処理が遅延の増加の主因なのだ。

このあたりの遅延の仕組みについては、意外とちゃんとした技術者でも正確には理解していない場合が多い。遅延とかも測定するものだと思っているひとが多いが、（２）と（３）の遅延については、実は設計レベルで理論的な計算が可能だ。

まあ、こんなところか。以上でおしまい。ねむい。