ネットワークのスピードを決めるもの

昨日、回線遅延シミュレータ：Ethdelayのサポートで出張していることを書きましたが、そもそもネットワークのスピードは何によって決まるのか、ということを簡単に書いてみましょう。

イーサーネットだと、「100Mでリンクしている」とか「ギガビットだ」とか言いますが、それは回線帯域の話しです。回線の太さと考えると良いでしょう。単位時間あたりにどれだけの量をながせるか、ということです。帯域が大きい方が当然スピードが速いと考えるかもしれませんが、実はそうとも限らないのです。

インターネットでは、主にTCPやUDPが使われます。TCPはメールやWEBなど、UDPは名前解決や動画配信などで使われます。TCPはコネクション型と言われ、送ったものは必ず相手に届く、あるいはエラーがわかる、という仕組みを実現していますが、実はTCPもIPというパケット単位のプロトコルを使って実現していますので、コネクション型と言っても、本当はバラバラのパケットのやり取りで実現しています。

どうやっているかというと、データを送る際に、シーケンス番号をつけて送り、受信側から、何番まで受け取ったという応答をもらうことで信頼性を実現しています。送ったのに受けたという応答がこなければ再送します。プログラムの作りが悪かったり、プロトコル設計がまずいとエラーの判断をしそこねたりしますが、TCP自体がある程度、そうやって勝手に信頼性のための努力をしてくれます。

とても便利なことなのですが、ここで問題になるのが回線遅延です。送った後に、受けたという応答が来るまで次のデータを遅れないのです（実際はウインドウ制御という概念があり、ある程度までは送るのですが）。回線遅延は主に距離が影響してきます。海外や衛星だと遅くなります。たとえ回線帯域が太くても、回線遅延が大きいと、TCPでは帯域を十分に使い切れないのです。

さらに、やり取りの頻度によって差は大きくなります。例えば、1400バイトのデータは一つのIPパケットで届けることができますので、

・1400バイト送信
・受信確認を返信

というやり取りだけですむのですが、プロトコルによっては、小さい単位で送ったり、あるいは事前に大量のネゴシエーションが必要だったりして、２０パケットくらいのやり取りをしてしまうと、実際の転送時間は全く違ってきてしまいます。

昨日のEthdelayの問題もこれが原因で、あまりにも大量のやり取りのため、小さな遅延でも、塵も積もれば山となるで、大きな差になってしまっていたのです。

TCPの特性をうまくごまかして、遅延の大きい回線でも高速化する製品などもありますが、そういう工夫の前に、まずは検討できるのであれば、プロトコルを再検討し、細かいやり取りをしないようなプロトコルにするだけでも効果が出ることもあります。

Ethdelayシリーズは帯域も遅延も、さらにパケットロスもシミュレーションできますので、手軽に様々な回線の事前評価ができるのが便利です。さらに安い！

なお、ある程度精度の高いシミュレーションを望む場合は、CPU性能が高いEthdelayEx、EthdelayProがおすすめです。