現在のWebアプリはAjax(ブラウザ側(HTML)→サーバ側へのリクエストに応じて返答する仕組で、サーバ側主体での通信は不可)やComet(サーバ側から主体的にブラウザ側(HTML)に通信する仕組。チャットやWebMailのプッシュなどで使われる)によってリアルタイムで通信を行ってWEBページを非同期で更新するのが主流だが、AjaxもCometもどちらもHTTPリクエストを利用しているため、通信のたびにHTTPヘッダが付与されてコネクション数に比例してトラフィック(通信量)やサーバ側のリソース(メモリなど)が増加するデメリットがあった。
(もうこの時点でわかりづらいのだが…)
例えて簡単に言うと、通信のたびにブラウザくんが手紙（通信内容）を封書（HTTPヘッダ）に入れるので、受け取るサーバくんはいちいち封書を開ける(HTTPヘッダを解釈する)手間がかかってしまう…と言う感じだ。
さてそこでHTML5の新機能「WebSocket」なのだが、これは上記のデメリットを解決するために、新しい通信規格として策定されたものだ。ただ、W3Cの最終勧告(ラストコール)後も改訂が行われるなど、まだ機能としてFIXしていないっぽいところもあるが、まぁそこは置いておく。
で、実際の「WebSocket」の機能を先の例え話で簡単に言うと、一度目の通信の時は今まで通りサーバくんは封書を開けるが、一度封書を開けた以降はブラウザくんが明示的に交流を経たない限りずっと手紙の中身だけを双方でやり取りできるようになるのだ。この時のサーバくんの応答を「ハンドシェイク応答」と云う。また、サーバくんと通信しているブラウザAくんとブラウザBくんとブラウザCくんはそれぞれ全員が手紙の内容をシェアしあえるという特徴も持っている。
なので、リアルタイム性を求めるアプリケーション（オンラインゲームやチャット、アクセス解析など）には最適な技術である。ちなみに、従来の「HTTP://」と「HTTPS://」のプロトコルに換わる「WebSocket」プロトコルはそれぞれ「ws://」と「wss://」となる。現在のところモダンブラウザでWebSocketに対応しているのは、ChromeとSafariとFirefoxだけ。IEはIE10から実装されるようだ。
「WebSocket」でのアプリケーション開発を行う上では、サーバ側がブラウザ側のハンドシェイク要求に応答するためのAPIが必要になる。そのための技術として「WebSocket API」という技術も生まれている。これを実装しているサーバーサイドスクリプトとしては、「Node.js」(Socket.io)などが有名で、「Node.js」のSocket.ioはクライアント側がWebSocketに対応していない場合にAjaxで代用通信を行うという仕組みを持っている。
「WebSocket」を体験できるデモコンテンツとしては、Mozillaが作ったMMORPG『BrowserQuest』と言うのがあるが、なぜか今は接続してもコネクション中のまま先に進まない。どんなコンテンツだったのかは、下の動画で確認できるので参考までに。
他には、接続した人とピアノセッションやチャットができる、マルチプレイヤーピアノというコンテンツもあります。
もう少し対応ブラウザが増えてくると、ユーザー参加型のWEBアプリを作る時は必須の機能になりそうだ。
