先ずサーバプッシュとは何か。

よくある「5秒後にジャンプします」とかの事をクライアントプルと言う。
この場合のクライアントとはブラウザの事。
ブラウザの方から引っ張る＝クライアントプル。

その反対がサーバプッシュ。
サーバの方から押す＝サーバプッシュ。
つまり、サーバからブラウザに対して「今すぐジャンプしなさい」と
伝えるための技術。
よくある用例は？と聞かれても、実はまだ目立った用例は無い。
技術自体は昔からあって、対応サーバとネスケで可能だった。
しかし時代はダイアルアップ。常時接続なんてまだまだ夢の時代。
現実的じゃなかった。結局流行らずに廃れてしまった。



さて、Webのチャットなんかは大抵30秒ごとに更新とかの
クライアントプルになってる。
これは新たな書き込みが無くても常に30秒ごとに更新する。
最近のCGIならAjaxで最新の書き込みだけを取ってくるとか
やってるのもあるのかもしれないけど。
Javaアプレットのやつはとりあえず今は考えない。
どちらにせよ間隔をあけて定期的に読み込みに行くので、
メッセンジャーのようなリアルタイムなチャットは出来ない。

でもここでサーバプッシュが使えれば状況は変わってくる。
新しい書き込みがあった時点で、チャットを開いてる全てのブラウザを
更新することができる。
新しい書き込みが無ければ更新される事も無い。
メッセンジャーのようなリアルタイムなチャットが可能になるわけだ。



そんな話をするからにはサーバプッシュが出来るようになったんでしょ？
と思うかもしれないけど、この辺はまだまだこれからといった感じ。
対応サーバがいくつか出てきて、サービスも増えはじめてる。
しかしサーバプッシュはクライアントとサーバの接続を
常に保持する必要があるため、データのやり取りが無くても負荷がすごい。
このあたりはShoutCastとかicecastなんかの
ストリーミングサーバと同じかもしれない。
こっちの場合は更に転送量の問題もあるけど。

しかし、問題は使用個所にある。
ストリーミングサーバはWebページからユーザが視聴を開始するまでは
特に仕事は無い。
でもサーバプッシュ技術を使うべき場所は通常のWebページなわけだから、
ユーザが普通にページを閲覧してるだけでサーバに負荷がかかる。
これが大規模なポータルサイトなんかになってくると事は重大だ。
サーバダウンに直結するから。
C10K問題（1万クライアント問題）は通常のWebページより明らかに厳しい。
場合によっては負荷は軽くてもプロセス番号が不足するという事態もありえる。



問題点についてはさておき、実際の仕組みはどうなっているのか。
実は意外と簡単で、リクエストに対してCGI側ですぐにレスポンスを返さず
何も無ければタイムアウトにならない程度の時間でレスポンスを返して
またすぐにブラウザから接続させる。
何かイベントが起こった時（チャットなら書き込みがあった時）は
すぐにレスポンスで情報を送ってまたすぐにブラウザから接続させる。
これだけ。わたしでも思いついた。
「あれ？これAjaxで出来るんじゃね？おれ天才じゃね？」と思ってたら、
既にCometって名前まで付いてた。

現在ノウハウの蓄積が進んでいて、ライブラリの整備が行われてるところ。
この技術でこれからのWebアプリケーションは更に高度化していく事になる。
多分。

---

＜映画 Galaxy Quest ほか | 2月の記事一覧 | mixi専ブラ＞
＜＜前の5件 | ぜろろん雑記（開発中）TOP | 次の5件＞＞

---

コメントはまだありません。

このブログシステムはまだ開発中です。
コメントフォームが表示されていても書き込むことはできません。