u n i o n - FF CHRONO: 鯖アーカイブ

2006年12月26日

■Ajaxによるチャットについて

Ajaxとは、単純にいうと、HTTP通信における非同期処理の技術です。
で、これを利用して、リアルタイムチャットの実装が見られます。
ですが、これは非常に大きな危険性を孕む可能性があります。

通信にHTTPを用いるっていうことは、普通は接続対象はhttpdとなります。
しかし、httpdは、持続的な接続を持つように設計されてはいません。
というか、ご存知の方には常識ですが、HTTP自体が持続的な接続を持つように設計されていないんですよね。
そこで、生まれた技術がセッションなわけです。
まあ、そこは本題ではないので、この辺はスルーします。

で、Ajaxによるチャットの何が問題なのか。
まず、今までのウェブチャットと同様の方式で、リアルタイム性を追求した場合。
単純に、リクエスト間隔を短くした場合です。
これがタブーなのはすぐにおわかりになるでしょう。
ただのDoSスクリプトです。

そこの問題を解決するアイディアがあります。
通常、HTTP通信では、クライアントとサーバがコネクションを確立し、クライアントからサーバにリクエストを送信、サーバが処理してレスポンスを返し、コネクションを切断します。
なので、通常、クライアントとhttpdが接続している時間というのは、短いものです。
ですが、そうすると、チャットなんかのユーザが複数いるようなものでは、自分以外のユーザも関与するため、自分がリクエストを送出した場合、他のユーザもそのリクエストに対するレスポンスを取得する必要があります。
そのためには、httpd側からクライアントに対してコネクションの接続を要求できないので、あらかじめクライアントからhttpdに接続を要求して、コネクションを持続させている必要性があります。
そこで。
クライアントが先にリクエストを送出し、応答を別のクライアントからのメッセージが到着するまで保留状態にしておくというアイディアが出てきました。
そうすれば、その間は持続的なコネクションが発生し、クライアントはレスポンスをうけたら、またすぐさまコネクションを確立すればいいのです。

さて。
この発想には感心する人も少なくないと思います。
しかし、少なくとも、自分以外の人も利用しているhttpdを用いてこのようなことをおこなうべきではありません。
通常、httpdには最大同時接続者数制限が設けられています。
httpdに限らず、たとえばDoSに晒された時に、他に与える影響をなるべく抑えるために、このような制限を持たせることは通常のことでしょう。
そしてまた、httpdは前述の通り、持続的な通信を前提にしていません。（そのサーバがファイル置き場になっていて、HTTPでダウンロードさせる方式の場合などは別ですが、通常はそうでしょう）
そこでほぼ持続的な通信をもつ先ほどの手法を用いると、httpdに対するコネクションの枯渇の可能性が生まれます。
最大同時接続者数が100に設定されているサーバで、そのチャットを100個開くとどうなるでしょう？
これが自分以外の人も利用しているhttpdを用いてこのようなことをおこなうべきではないとする理由です。
また、悪意が無くても、通常利用するだけでもコネクションが枯渇することは十分あります。
たとえば、最大接続者数が100のサーバで、このチャット利用者が20人いたとすると、勝手に最大接続者数を80にサーバ設定を書き換えているのと同義になります。
もしこのようなことをおこなうのであれば、専用のデーモンを用意するか、専用のhttpdを用意するべきです。
そうすれば、他の利用者に対する影響は、減ります。
通常にサイト公開をおこなっているユーザと同じhttpdにおいて、このようなことをおこなうのは、他のユーザに対する嫌がらせととられてもおかしくありません。

しかし、どうにもAjaxとリアルタイムチャットは、親和性が低いように思います。
HTTPというプロトコル自体がリアルタイム通信に根本的に不向きなのが大きいです。
Ajaxによって、クライアント個人がトリガとなる非同期通信の経路は確保されました。
しかし、チャットは他のクライアントもトリガとなります。
ここにおいて、コネクションが本来的に持続しないプロトコルの特性が故に、先述のような手法を用いる必要があります。
しかし、レスポンスごとにコネクションが切断されるということは、一回発言があると、そのたびに再度コネクション確立のオーバーヘッドがのしかかります。
このあたりはどうにもやはり不向きに思えて仕方がありません。

投稿者邑波。 : 14:01 | コメント (0) | トラックバック

2006年06月14日

■mrtgを導入してみる。