ついにRFCに登場!Webサーバとの双方向通信を実現する「WebSocket」

杉山貴章(オングス)
2012-01-06 09:00:00
  • このエントリーをはてなブックマークに追加

 次世代のWebアプリケーションの中核を担う技術として「HTML5」に注目が集まっているが、それと並んで期待されている技術に「WebSocket」がある。

 IETFとW3Cによって仕様の策定が進められており、最初の提案以来幾度もの改訂を経て、2011年12月11日にそのプロトコル仕様がRFCのProposed Standard(RFC 6455)となった。

AjaxからComet、そしてWebSocketへ

 WebSocketはウェブサーバとブラウザが直接コネクションを張って双方向通信するための技術規格である。HTTPとは異なる独自の軽量プロトコルによって通信を行うため、オーバーヘッドが小さく、長時間に渡って通信する場合でもHTTPコネクションを占有する必要がないというメリットがある。

 WebSocketが生まれた背景には、サーバとブラウザがもっとリアルタイムに通信して情報の配信や更新を行えるようにしたいというニーズがある。その元を辿ると、今では多くのウェブサイトで当たり前のように使われるようになった「Ajax」に行き当たる。

 Ajaxは、JavaScriptのXmlHttpRequestを利用することでサーバとの非同期通信を実現している。それまでのウェブサイトでは、エンドユーザーが何らかの操作をすることでサーバにリクエストを行い、ページの遷移によって表示内容の更新を行っていた。それがAjaxが登場したことで、エンドユーザーの操作を妨げることなく、サーバからの情報の取得や、表示内容の更新を行えるようになった。

 しかし、Ajaxでもブラウザからのリクエストによってサーバが応答するという仕組みは従来と変わっていないため、サーバ側から自動でデータを配信することはできない。チャットや株式情報のような常に情報の更新を必要とするサービスでは、ブラウザからの要求の有無に関わらず、サーバから自動でデータを送る「プッシュ配信」の仕組みが求められていた。

 そこで登場したのが「Comet」である。Cometは、サーバ側でリクエストに対する保留状態を作っておき、任意のタイミングでレスポンスを返すという方法によってプッシュ配信を実現する(この方式を「ロングポーリング」と呼ぶ)。

 ただし、CometはあくまでもHTTPの枠組みの中で無理矢理プッシュ配信を実現する技術であり、HTTPコネクションを長時間占有してしまうというデメリットがある。またタイムアウト発生時などでは、その都度再接続が行われるのでオーバーヘッドが大きいという問題もある。

 リアルタイム性が重視されるウェブアプリケーションでは、これらのデメリットが大きなネックになってくる。そこで、HTML5の策定に合わせた新しい通信規格として「WebSocket」が提案された。もともとはHTML5仕様の一部として策定が進められていたが、その後独立した仕様に切り離された。現在はプロトコル仕様が「RFC 6455」として、API仕様が「The WebSocket API」として提唱されている。

AjaxやCometと決定的に異なる通信

  • コメント(2件)
#1 m11m   2012-01-06 20:23:50
>>(これをポーリングと呼ぶ)
呼びません。
#2 builder編集部   2012-01-06 21:50:42
m11m 様

builder編集部です。ご指摘、ありがとうございました。

「ポーリング」についてですが、ご指摘の通り誤りでしたので、下記の通り修正いたしました。

修正前:
Cometは、サーバ側でリクエストに対する保留状態を作っておき(これをポーリングと呼ぶ)、任意のタイミングでレスポンスを返すという方法によってプッシュ配信を実現する。

修正後:
サーバ側でリクエストに対する保留状態を作っておき、任意のタイミングでレスポンスを返すという方法によってプッシュ配信を実現する(この方式を「ロングポーリング」と呼ぶ)。

この度はご迷惑をおかけしまして、誠に申し訳ございませんでした。
今後もご愛読頂ければ幸いです。よろしくお願いいたします。
  • 新着記事
  • 特集
  • ブログ
このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]