ネットワーク遅延対策技術

第1回では、富士通が発表した次世代ものづくり環境「エンジニアリングクラウド」と、富士通研究所が開発した仮想デスクトップ高速表示技術「RVEC（レベック）」の動画圧縮技術についてお話しました。第2回では、圧縮率が高くかつ極めて高速な静止画圧縮技術についてお話しました。

最終回となる今回は、エンジニアリングクラウドで問題となるネットワーク遅延への対策についてご説明します。

スループット低下の原因はネットワーク遅延とパケットロス

RVECのような仮想デスクトップでは、データの転送にTCP（Transmission Control Protocol）というプロトコルを用いています。TCPを用いた通信では確実にデータが届くことが保証されているため、ファイル転送のFTPや、HTML文書を転送するHTTPなどに用いられています。

さて、仮想デスクトップなどを使って遠隔地からサーバーの操作をしている時に、画面の反応速度が遅いと感じたことはないでしょうか。ネットワーク通信帯域は十分なはずなのに、このようなスループットの低下がTCP通信で発生する原因の1つがネットワーク遅延です。

ネットワーク遅延とは、データがネットワークを介して送信側から受信側に届くまでの時間のことです。遠隔地にあるサーバーとデータをやりとりする時には、データが届くまでの過程で数多くの中継器を通ることになりますが、各中継器においてわずかな処理時間が発生し、それらが積み重なったものが最終的に遅延となります。ネットワーク遅延を表す指標としては、片道ではなく往復にかかる時間である、往復遅延時間（RTT: Round Trip Time）が用いられます。平均的に、日本国内では100ミリ秒以下、日米間で約100ミリ秒、日欧間では約200ミリ秒の往復遅延時間があります。

では、なぜこのネットワーク遅延によりTCP通信のスループットが低下してしまうのでしょうか。TCP通信ではデータをパケットと呼ばれる最小単位に分割して送信しますが、確実にデータが届くことを保証するために、図1のように受信したパケットごとにACKと呼ばれる応答を返します。送信側ではACKが戻ってくるまで次のパケットの送信を待つため、ここで待ち時間が発生します。往復遅延時間が大きくなるとACKが戻ってくるまでの時間も遅くなりますので、この待ち時間が大きくなり、結果的にTCP通信のスループットが低下してしまいます。

実際のTCP通信では1つずつのパケットではなく、複数個のパケットを同時に送信することができ、そのパケットの数（データサイズ）をウィンドウサイズと呼んでいます。ウィンドウサイズはOS（Operating System）によって異なりますが、一般的には64キロバイト程度です。TCP通信の最大スループットはこのウィンドウサイズと往復遅延時間から図2の式で求めることができます。

RTTが100msでウィンドウサイズが64キロバイトの場合には、この式に当てはめると、ネットワーク通信帯域がどんなにあったとしも、TCP通信では5Mbps以上のスループットは出ないことになります。

TCP通信のスループットを劣化させるもう1つの原因がパケットロスです。通信が集中してしまう輻輳が発生し中継器でパケットが溢れてしまう、通信ノイズの影響でパケット内の情報が壊れてしまう場合などにパケットロスが発生します。パケットロスが発生すると送信側にはACKが帰ってきませんので、TCP通信では一定時間後に同じパケットを再送信します。ACKが帰ってくるまで何度でも同じパケットを送らなければいけませんので、TCP通信のスループットの低下につながります。

このようなTCP通信のスループット低下への対策として、ウィンドウサイズの設定値を大きくするという手法があります。ウィンドウサイズを大きくすることで、同時に送信できるパケットの数を増やすことができ、ACKを待たずに次々とパケットを送信することが可能になります。しかし、パケットロスが発生した場合には、ロスしたパケットまでさかのぼって再送することになるため、パケットロスが増加した場合にはスループットが低下してしまうという問題があります。