Web2.0とC10Kに関する数々の誤解

Web2.0 = Ajax/Cometなの？とかプロセスIDは今でも16ビットなの？とかはサテオキ、

個々のクライアントがサーバに要求する処理量は小さなものでハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする――。これが最近Web開発者の間で話題となっている「C10K問題」（クライアント1万台問題）だ。

AjaxやCometなどのクライアント側技術に伴うサーバ側の問題に関していろいろ誤解があるようなので,書いておきたい.きっとlingrの中の人はこの記事読んでニヤニヤしてるはず.

以下、記事にないことも書いてあるのでそのつもりで.

誤解その1 AjaxによるWebアプリの台頭でサーバ側の負荷が増大する

Ajaxの典型的な使い方はサーバに問い合わせてページの一部分だけを
変化させるというモノだ.これはページ全体を書き換える従来の方法と違い,
すでにレンダリングされている画像の呼び出しなどがなくなるので,かえって
サーバへの負荷が下がるケースもある.

つまりあるWebアプリを操作するのに必要なクリック数が一定だとすると,Ajaxによってサーバ側の負荷はおおむね下がる.

もちろんマウスオーバなどでサーバに問い合わせるようなサービスに関してはこの限りではない.

誤解その2 1コネクションの維持に1スレッドもしくは1プロセス必要

サーバ側から見た場合,クライアントからopenされたソケットというのは
単なるオープンされたファイルディスクリプタになる.よってそれを
維持するのに1プロセスもしくは1スレッドが必要ということはない.

ネットワークプログラムでforkやスレッドが必要なのは,ソケットからの
要求に対して同時並行的に処理を行う必要があるからで,cometのように
クライアントからの書き込み要求は別Port,あとは大多数の
維持コネクションへの処理を行うケースに関しては当てはまらない.

またソケットからの要求のwatchに関しても
http://d.hatena.ne.jp/yamaz/20061106
で書いたようにselectのようなビジーループ方式ではなく,
kqueueやepollなどのイベントドリブン方式の処理を行うことで
十分にスケールできる.

ところでTCPのコネクションとはいったい何だろうか?
実態としてはTCB(Transmission Controll Block)と呼ばれる構造体で,
FreeBSDだとtcpcbという名前で/usr/include/netinet/tcp_var.hに
定義されており,1コネクションごとに生成されカーネルメモリ内に格納される.
これはTCPのコネクションに関するデータが保存されており,
TCBがカーネルに存在することをもって,TCPの仮想チャネルが実現されている.

誤解その3 コネクションが増えるとソケットの数が不足する

ソケットは確かに不足するが,カーネルパラメータで増やすことが可能だ.
またカーネルがソケット1個を保持するのに必要なメモリもたかが知れてる
ので問題にはならない.

誤解その4 コネクションが増えるとポートの数が不足する

これはよくわからないのだが,これも時々同僚から聞いた.曰く、

「TCPヘッダのPort用のフィールドは16ビットだから65536
コネクションまでしか扱えない」

ということらしい.たしかにPort用のフィールド長は変更できないので,
ホントだったら大変だ.しかしTCPはコネクションを

(クライアント側IP,クライアント側Port,サーバ側IP,サーバ側Port)

の組で管理しているので,同一IPから65536のコネクションが張られない限り問題は起きない.
NAT越しのアクセスで6万5000ものコネクションが張られるケースだと問題は起きるかも知れないが,
いずれにしてもクライアント側の問題でサーバ側には関係ない.

結論

というわけでOSやプロトコルの制限がC10Kのネックになることはなく,
cometのような小さな処理の1万2万程度の同時コネクションならば
正しい対処を行うことによって今のPCマシンで余裕で対処できる.
よって引き続きネックになるのはマシンパワーであるというのがyamaz的見解だ.
マウスやキーボードの挙動すべてがサーバ側に送られる未来はあまり
想像したくないが,仮にそうなったとしてもベンダーにだまされること
なく,あわてず騒がす対処していきたい.

(おしまい)