リアルタイムWebを構築しやすくする「Socket.IO」とは

近未来の技術トレンドを先取り！ 「Tech-Sketch」出張所 第1回

最適なリアルタイムWeb技術が選択されることを確認

　では、動作確認をしましょう。今回は独自にサーバを立てるのではなく、PaaSを利用してみます。

　開発者が簡単に利用できるPaaSはたくさんありますが、PaaS自身のネットワークやルーティングの仕組みに違いがあるため、利用できるリアルタイムWeb技術がそれぞれ異なります。

　例えばdotCloudやNodejitsuはWebSocketに対応していますが、Herokuや当社のPaaSであるeXcaleはまだWebSocketプロトコルに対応しておらず、リアルタイム双方向通信を行うためにはComet（Ajax long polling）を用いなければなりません。

　今回はdotCloudとeXcaleに同じプログラムをデプロイし、それぞれ自動的に最適なリアルタイムWeb技術で接続されることを確認します。

　具体的なデプロイ方法や追加で必要な設定ファイルなどは、各PaaSのマニュアルを確認してください。

dotCloudでWebSocket

　dotCloudに接続した際のブラウザ側の通信状況はこうなりました。

　サーバよりStatusCode 101 "Switching Protocols" が返り、ここでHTTPからWebSocketへプロトコルがスイッチしていることが分かります。

　その際のサーバ側ログはこのようになります。

　WebSocketで送受信していることが分かります。

eXcaleでComet（HTTP Long polling）

　同じプログラムをeXcaleにデプロイし、接続した際の通信状況はこうなりました。

　xhr-polling（AjaxでHTTP Long PollingをするComet）で接続していること、タイムアウトが起きるたびに何度も接続しなおしていることが分かります。

　その際のサーバ側ログはこのようになります。

　xhr-pollingで送受信していますね。

dotCloudでComet（HTTP Long polling）

　接続するリアルタイムWeb技術をSocket.IOが自動選択するのではなく、必要であれば明示的に指定することもできます。例えばdotCloudでxhr-pollingを指定してみたら、このようになりました。

　eXcaleの場合と同様、xhr-pollingで接続していることが分かります。

最後に

　このように、Socket.IOを用いると、リアルタイムWeb技術の実装を気にすることなく、簡単にリアルタイムWebを構築することができます。皆さんもリアルタイムWebを構築する際には、Socket.IOの利用を検討すると良いでしょう。

　さて次回は、ブラウザからではなくiOSとAndroidの「ネイティブアプリ」からSocket.IOでサーバに接続し、双方向通信する方法を紹介します。