「Socket.IO は必要か?」または「WebSocket は通るのか?」問題について 2016 年版

問題の詳細

WebSocket は標準仕様であるが、ブラウザが実装しているものを指す場合、これは大きく二つの仕様からなる。

• JS の API (WebSocket オブジェクトとそのメソッド) を定義した W3C の仕様
• ネットワークプロトコルを定義した IETF の仕様

前者は、仕様としては比較的初期から固まっており、後のバイナリ対応など細かい変更はあれど、簡単なテキストチャットを作るレベルでは、早い段階から落ちついていた。

つまり、これはブラウザが実装するかしないかという、いつもの問題とほぼ等しい。

次に後者のプロトコルだが、 WebSocket という技術が注目を集め始めたのは、このプロトコル自体が RFC になるよりも前だった。

最初は Hixie というエンジニアが書いたドラフトで始まり、その後 HyBi という専門の Working Group に移され、そのしばらく後に RFC になる。

ところが、 Hixie 時代からもブラウザやサーバはこの機能を実装し始めていたため、ドラフトのバージョンが上がりプロトコルフォーマットが変更されるたびに、それに追従していた時期がある。

この時期は、例えばあるブラウザはまだ HyBi-07 だが、サーバは HyBi-14 である、といったように、同じ WebSocket を話しているつもりが動かない場合があった。

対応

Socket.IO は、ブラウザとサーバ両方のライブラリを有していたわけだが、この両方の問題に対応し以下を提供していた。

• WebSocket の実装が無いブラウザ向けの Polyfill
• WebSocket のどのバージョンのドラフトでパケットを送ってきても、対応できるサーバ

これが、 Socket.IO が行っていた「互換性担保」の部分の実態である。

2016 年現在、 IE11 以降のモダンブラウザは RFC に対応したプロトコルをしゃべる WebSocket API を実装済みであるため、この部分の心配は IE11 に依存すると言える。

WebSocket | Can I use

つまり RFC の WebSocket を実装したサーバと、モダンブラウザにある WebSocket API を直接使った実装で、十分 Interoperability が担保されているわけである。

補足

ほとんど無いと思うが、仮に「いまだに RFC 以前のプロトコルで話しかけてくるクライアントがいる」場合は、基本は落とせばいいだろう。

ただし、それらを等しくサポートする、非常に苦しい選択を迫られている場合は、 Socket.IO の中でも使われている WS というモジュールが、古いプロコトルをカバーする実装になっている。

Socket.IO もこれを中で使っているため、もちろん Socket.IO を使っても良いが、その場合は通信の内容(つまり WebSocket の上で流すペイロード)にも、特定のフォーマット(Socket.IO プロトコルと呼ばれる)をサポートする必要があるので、 WS 単位ならそれがいらなくなる。

問題の詳細

WebSocket のネゴシエーションは、 HTTP リクエスト形式のパケットで始まる。

このリクエストが Connection: Upgrade というヘッダを持っていることで、以降を WebSocket で通信する合意をとるという仕組みだ。

ただし、 Proxy や LoadBalancer や Firewall といったネットワーク経路上に挟まっている、俗にいうミドルボックス(intermediaries ともいう)の中には、こうしたヘッダの存在を許可しないものがある。

理由は様々だが、多くの場合はその後の通信をサポートしてない、未知のヘッダであるなどの理由から、ヘッダがあった時点でコネクションを切断したりする。

他にも、 Personal Firewall (要するにウィルス対策ソフト)の中に、こうしたヘッダを落とす製品があることも確認されていた。

この情報は、かつて Socket.IO の Wiki にまとめられていたが、現在は消えてしまったようだ。

消されたのは、内容が古いからだろうが、自分が昔翻訳した方が残っていたので参考までに貼っておく。

解決方法

実はこの問題の解決は意外と簡単で、暗号化してしまえばいい。

つまり ws:// ではなく wss:// にすることで、 TLS で暗号化する。 End-To-End 暗号化であれば、ミドルボックスはそもそも HTTP ヘッダが見えないため、それを元に落とすことができない。

そうでなかったとしても、 HTTPS 化が推奨されている現状、新規で作るなら wss:// にしない積極的な理由はほぼ無いだろう。サイトが http でも wss を使うことはできるため、導入の負荷はサイト全体の TLS 化と比べても低いと思われる。

補足

TLS を一旦解くようなミドルボックスの存在は否定できない。

ただし、多くのクライアントに対してこれを行う場合は、相当なリソースを必要とするため、セキュリティポリシーが非常に高い環境で実施されていると考えられる。そうした状況では、通常強固なフィルタリングなどが行われているため、そもそも WebSocket 以前にまともに見れるコンテンツは限られている場合が多い。

こうしたエッジケースにあるクライアントも、本当にサポートすべきターゲットなのかによる。

解決方法

この問題の特徴は、すぐに切れるわけでは無いというところである。

どのくらいで切れるかは、ウィルス対策ソフトが長い接続を「怪しい」と判断する閾値によるが、あまりにも短いとちょっと遅いサーバを HTTP で叩いてる間にも切れてしまう。

何十秒かに一回切れてしまうのが問題なだけなら、単純に再接続すれば解決する。

WebSocket は PING 機能を持っているため、切断したら onclose イベントで判明するはずである。

そこでもう一度コネクションを貼り直す方法が考えられる。

ws.addEventListener('close', () => {
  if (意図しない切断) {
    return reconnect();
  }
});

コネクションに状態を紐付ける場合、サーバでも再接続時に処理を継続できるように(切断中の情報を保持しておくなど)実装が必要なのは言うまでもない。

補足

切断 - 再接続のループが、なんらかの原因により非常に速いサイクルで発生していしまう可能性もある。

おそらくこちらが想定していない理由での、短時間の切断が発生しており、これはどんなにリトライしても解決しないどころか、ブラウザの負荷が上がるだけである。

理想的には、リトライの回数や、発生時間を監視するなどの実装があったほうがよくなる。

また、同等のことが onerror で必要になる場合は、両方に対応する。