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

最新特集【一覧】

EPUB生成ツール「ReVIEW」について達人出版会の高橋氏に聞いてみた

1つのソースでEPUBとPDFを生成できる「ReVIEW」を試す

Snow Leopard探索記 最終回：線路は続くよどこまでも

　次世代の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と決定的に異なる通信