Hatena::ブログ(Diary)

はてなポイント3万を使い切るまで死なない日記

2011-01-07 遅延(レイテンシ)とはなにか? このエントリーを含むブックマーク

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


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


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


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


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


(1)光の速度での移動時間

(2)データの転送時間

(3)バッファリングされている時間

(4)インターネットの経路による遅延


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


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


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


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


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


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


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


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

blastydotblastydot 2011/01/08 13:48 (2)? うーん、転送速度のことをレイテンシと呼ぶ人は珍しいなあ。
その割りに「よくサイトが重いとか、インターネットがめちゃくちゃ遅いというのと遅延が高いというのとは本質的には別の現象なんだが、よく混同されている」ですかw

「光ファイバーだろうが、銅製の電話線だろうが、結局のところ電磁波を利用しておこなわれているので」って電磁波というものを理解していますか? 
「とりあえずは光速を秒速30万キロメートルと考えると」 光ファイバを前提とするなら最初から20万キロにしときましょうよ。
「実はストリーミングの場合は(2)による遅延はサービスにはまったく影響しない」 ここは笑うところですか? レイテンシとスループットを理解してないだけ? っても、細い回線でストリーミング使ったことないの? 「リアルタイムに処理できている以上」という前提がおかしい。リアルタイムに処理できないからバッファリングするのであって、バッファリングするまでの時間を無視していいのなら、そもそも(2)の問題なんか存在しなくなりますわな。
(4)は、「独自の技術により低い遅延」を謳うとこなら、独自のルーティング最適化とかP2P併用とか、パケット再送なしで処理できる技術の開発とかをやってるんだろうけど、まあここは突っ込んでもしょうがないか。
「(2)と(3)の遅延については、実は設計レベルで理論的な計算が可能だ」 (2)は無理だろw ネットワーク帯域を保証できるすごい技術でもできたのかね? ファイバー2ファイバーしか考えてないとしても、経路によってはポートごとに帯域絞ってたりするわけだが?
それと音声圧縮のバッファなんてそんなに必要はない。つーか、標準的なADPCMだと遅延なんて0.1ms程度だ。無圧縮音声流すとか迷惑すぎるだろ。というか、やっぱりバッファリングするまでの時間はあ無視してねーんじゃねーかよ。サービスにはまったく影響しないんじゃなかったのかよ。
レイテンシといっても、どんな用途でのどの遅延のことなのか曖昧すぎる。データ転送速度まで含んでるしなあ。

xxkickerxxxxkickerxx 2011/01/09 11:58 そのような技術者は大変レベルの低い人達だと思います。
残念ですね。

isogakiisogaki 2011/01/10 03:00 遅延って、べつに専門用語でもないわけですし、いわゆる動画の再生が遅れたりするような事象を指すこともありますよね。純粋にIPトラフィックだけの話に限定した場合、kawangoさんの認識は正しいですが、一般消費者から見た場合、遅延とはIPトラフィックだけの(1-4までの)問題だけでは済まないのであり、「遅延=インターネットがめちゃくちゃ遅い」の認識は的を外してはいないように思う。

現在の一般消費者のネットワークはほとんどがルータを介しNATで返還されて接続されており、TCPにより通信が確立されています。

TCPで接続した場合、横軸に時間をとって通信帯域幅の上下をグラフにすると、輻輳制御によりこぎりの歯のような波形が見える。つまり、時間あたりの到着するパケットの数は常々変化している。このように時間毎に到着するパケット量が変化するシステムの場合には、のこぎりの谷間でいざ再生しようとして再生すべきデータが無い状態にならないよう明示的に(時間をシフトして)一定量のデータをためこんで(バッファリング)再生しなくてはならない。

高速リカバリ・アルゴリズム(2)
http://www.soi.wide.ad.jp/class/20010012/slides/09/29.html

この、のこぎりの歯が何なのかというと、TCPでは、転送量を少しづつ増やしてパケットがロストしたら転送量減らすという処理を行なって最大の速度で通信できるように工夫しており、のこぎりの谷間は、ちょうど、パケットがロストしたタイミングである。ここで、データ転送中、パケットがロストが発生したどうなるかというと、UDPの場合には単にロストし、TCPの場合には再送の制御が行なわれ、再送が完了するまで、末端のアプリケーションにデータが届かなくなる。この際、ロストしたデータが届くまでには、(最低でも)1RTT分の時間がかかる。

だから、上述の通り、ルータの内側のTCPで通信する動画や音声再生システムでは、最低でも、パケットロストが発生しても、ロストした分のデータの到着は待てる程度(最低でも1RTT)にはデータをためこむ必要があるし、パケットロストがひどい環境ではもっと多くの時間分のデータをためこむ必要がある。

というわけで、TCPを使って音声・動画を配信する場合、末端のアプリケーションがどの程度データをためこんで再生するのか、そのためこみ量が鍵となる。ニコニコ動画にも使われているAdobe Flash Media Server+Adobe Flashでは、このあたりの制御を自動で行なう。どうするのかというと、(たぶん)パケットのロス率が高くて、突然データの到着が遅れたりするのが頻発する環境の場合には、なるべく長い時間データをためこむ(バッファリング)ようになる。

TCPの特性として、海外からのパケット転送や衛星経由でのパケット転送のようなRTTの大きい環境では、のこぎりの歯の角度がゆるやかになる傾向があり、通信速度が戻るまでに長い時間がかかるという特性があり、RTTがおおきい場合、ロストしたパケットが届くのにも長い時間がかかるようになる。さらに海外ではインフラが不十分な国も多くパケットロス率も高くなる。携帯や無線LANのようなインフラもパケットロス率が高いので、こうした環境では、10秒や20秒といった単位で動画の再生の遅延が発生することがある。

そして、ある程度ビットレートが低ければ、のこぎりの歯の角度がゆるやかだろうが、すぐに回復しますが、ビットレートが高い場合には、回復がおいつかず、結局データの到着が送れ待たされることで「動画がとぎれる」という現象が発生することになります。

> これらって実は高度なアルゴリズムを駆使して実現するとかいうような類の話ではない。

といっても、以上のように、(IPだけではなくTCPの)実利用を考えると、Adobe Flashの中でどの程度のバッファ容量を取るのかという点が結構なキモだったりして、このバッファ容量を算出するアルゴリズムというのはそれなりに高度だったりするのです。

TCPを経由して動画を中継・再生すると、以上のような罠にはまりますから、海外からの中継の場合、TCPじゃなくて、UDPで(落ちたパケットをあきらめて)再生するほうが、遅れがなく許容できるだけの放送品質を保てたりしますね。


> パケット再送なしで処理できる技術の開発とかをやってるんだろうけど、

をやるためには、結局TCPの上でがんばっているのではだめで、UDP上でForwarded Error Correctionを使う必要があったり。でも日本の一般的な環境でUDPなんて使えないわけで、今の日本のインターネットではTCPの呪縛から逃れることができない。

>「(2)と(3)の遅延については、実は設計レベルで理論的な計算が可能だ」
> (2)は無理だろw ネットワーク帯域を保証できるすごい技術でもできたのかね?

実は、パケット到着の分布関数や各種パラメータを駆使すれば、数式を使って算出することができるのです。このへんは、以下の本が詳しい。

岩波講座 インターネット〈5〉ネットワーク設計理論 [単行本]
# ISBN-13: 978-4000110556

> それと音声圧縮のバッファなんてそんなに必要はない。つーか、標準的なADPCMだと
> 遅延なんて0.1ms程度だ。無圧縮音声流すとか迷惑すぎるだろ。

指摘されているように、現実的に無圧縮というのはありえない。だからこそ、学者の人はどれだけ低遅延の圧縮アルゴリズムを開発できるかに注力していたりする。