![[ C H A N G E L O G ]](/images/changelog.s.s.gif){kind=small}
![[Tux]](/images/tux.s.gif)
|
aka LWN JAPAN
|
|
|
ChangeLog |
Web100
|
ChangeLog メール版 登録 |
Web100：100％のパフォーマンスを求めて
NSF (（米）国立科学財団：U.S. National Science Foundation) が
資金援助を検討中の新たなイニシアティブは、
ユーザがインターネットに出て行く際の実行的な帯域幅を
素晴らしく向上させる潜在能力を持っています...
そしてこの研究は Linux を用いて行われる予定です。
このメリットは多いでしょう：
ネットワークの利用向上、
Linux がインターネット研究の最前線に立つ、
そしておそらく、
Linux カーネルハッカーが、このシステムの改良のために
合州国政府から報酬を得られることさえ考えられます。
NSF は、 米国中の科学者がその研究にギガビットネットワークを活用できるようにするために、 ネットワークのインフラに 5 千万ドル（50億円）以上を費しています。 ところで残念ながら、多くの方がすでにお気づきのように、 高速で大容量のネットワーク接続があることと、 いずれかの通信が実際にその帯域幅の 100 ％を使用できることとは別のことです。 実際、本当に広帯域なネットワークで、帯域がほとんど使われていない場合でも、 転送レートは一般にその 10％かそれ以下です。 どこに問題があるのでしょう？ 主な問題は TCP がどのように設計されるか、 また、どのように実装されるのかに非常に大きく関わっています。 確認応答を受信する前に転送してもよい (又はこれを超えると転送を中断しなければならない) データの量を設定するためには、「最大ウィンドウサイズ」が使用されます。
※ 最大ウィンドウサイズ - 大量のデータを送信する際に、いちいち相手側が受け取ったことを確認してから次のデータを送っていたのではネットワークの性能を生かすことはできません。そのため、TCP プロトコルには「ウィンドウ」と呼ばれる機構が用いられています。 これはある時点で一度に受信可能なデータ量を互いに教え合うことで、まとめてデータを送れるようにします。広帯域の接続 (例えばギガビットネットワーク) が利用できる場合、 この最大ウィンドウサイズは、 ネットワークの帯域幅と遅延の両方を考慮して設定されなければなりません。 この設定値が小さすぎると、ソフトウェアは転送を中断させられてしまい、 利用可能な通信能力をうまく利用することができません。 現在、 ほとんどのアプリケーションは、 最適な最大ウィンドウサイズを探して設定してみようともしません。
※ 原理的には、Linux を含むほとんどの UNIX 系 OS では、ソケットオプション SO_RCVBUF と SO_SNDBUF を指定することで、アプリケーションがウィンドウサイズを設定することができますが、最適な最大ウィンドウサイズを探し出し、これを利用しようとするアプリケーションはほとんどありません。その代わりに、カーネルがセットしたデフォルト値を受け入れます。 当然それは、もっとも普通のネットワーク状況に最適化されていなければなりません。
※ Linux ではデフォルトの最大ウィンドウサイズは 65535 バイト（ /proc/sys/net/core/rmem_default で設定できます。）ですが、この 65535 バイトという値はイーサネット等の LAN (遅延が短い) や現状のインターネット (帯域幅が狭い) では十分な値ですが、転送遅延が 30 ミリ秒程度のネットワークにおいて非常に大雑把な計算でも約 1 Mバイト/秒のスピードが限界です。明らかにギガビットネットワークでは不十分な値です。実際、アプリケーションがエンドユーザにこのデフォルト値を 変更させてくれない可能性もあります。 時として、ある種の ftp や他のアプリケーションは、 この最大ウィンドウサイズを設定させてくれるように作られています。 けれども最適な値を見つけ出すのは簡単な課題ではなく、 今のところ特定のネットワークトポロジについての深い知識を 備えたネットワーク技術者に積極的に協力してもらう必要があります。 NSF は、この問題に対するオープンソースな解決策の開発への さらなる研究に資金援助することに合意しました。 Linux と Apache が、 計画の基盤となる OS とウェブサーバの主要な候補パッケージとなっています。 Web-100 プロジェクトの暫定的な白書 (英語) が公開されており、今も更新中です。 また、 Web-100 のワークショップ (英語) が NCAR（米大気圏研究センター）の科学計算部門によって計画されており、 このプロジェクトへの NFS の支援を検討するために 10月 27〜28日にコロラド州ボールダーで開催されます。 参加に興味がある方は、このワークショップを率いている Basil Irwin 氏 (英語) までご連絡下さい。 ギガビットネットワークを持っていない方にとってはどうなのでしょう？ 興味を持つべきでしょうか？ そうですね、最初のインターネットもまた、 NSF から資金援助され、サポートされていたことを思い出してみて下さい。 その時は、質の高い研究をサポートすることが目的とされていました。 でも、その成果、私達みんなが頼りにしている低コストのネットワークも 手にすることができました。 現在のネットワーク技術の使いやすさが 100倍向上すれば、 その恩恵を利用しようと思うアプリケーションの数も同様に何倍にもなるでしょう。 どうして、NSF がこの段階で参加するかどうかを気にしなければならないのでしょうか？ この分野の開発者に、かなりの資金と確かな仕事をもたらすからです。 それに、これは将来より大きな帯域幅のネットワークにアクセスするようになった時に、 私達みんなに影響を与えるであろう問題を解決することになるからです。 これはビジネス上の利害関係によって複雑化されない、 オープンソースをベースにした投資なのです。 もし私達のためにこの問題が今解決されれば、 みんなの家にギガビットネットワークのパフォーマンスがやってくるような 未来へとスムーズに飛び込んでいくのに役に立つことでしょう。 NSF の支援が、今日のインターネットの誕生にいかに有益であったかに注目して下さい。 NSF に資金支援され製作された NSFnet はインターネットの前身ですし、 また、Mosaic プロジェクトは今日のウェブブラウザの母となりました。 それに、今日の性能が 100倍向上するという、 NSF の支援により可能となる効果についてもまた考えてみるのも良いでしょう。 --Liz Coolbaugh |