Engine（engine.io）v1.7の目指すところの和訳

Socket.ioの通信部分（WebSocket,HTTP）を担うEngineというライブラリのv1.7のdocsを読んでいたのですが、メモしていたらなんとなくまるっと和訳っぽくなったので公開します。

ちなみに何を改良してるのかはまだ読み途中なので、なんかいい感じに書けたら追って公開します。

socketio/engine.io at 1.7.0

以下は Goals のみの和訳です。
結構適当なので面白いと思った方は本文を読んでみてはいかがでしょうか。

ゴール

以前のバージョンのsocket.io coreとは異なり、Engineはlong-polling connectionを最初に確立し、その後でよりよいtransports（WebSocketなど）にupgradeしようと試行する。

socket.io projectのlifetimeのなかで、開発チームは数え切れない欠点をHTML5 WebSocketとFlash Socketをfirst-connection-mechanismとして使うことに見出してきた。

これらは両方とも双方向通信を確立するのに正しい方法であり、HTML5 WebSocketは未来の手法である。
しかしながら、ほとんどのビジネスの要望に答えるには、別のtraditionalなHTTP1.1のmechanismsが最良の解答でもある。

WebSocketベースの通信には以下の2つの基本的な利点がある。

1. Better server performance

   • A: Load balancers ロードバランサー
   • long-polling接続のload-balancingは重大なアーキテクチャの悪夢をもたらす。なぜなら、リクエストはuser agentにより開かれたいくつものソケットにより送信されるからだ。 しかしこれらはすべてプロセスにまわされる必要があり、コンピュータはEngineのための接続を持つ。これはRAMとCPU利用率に悪い影響をもたらす。
   • B: Network traffic ネットワーク通信
   • WebSocketは各message frameが少なくとも一定量のdataにより構成されていることを前提に設計されている。HTTP1.1 tranportsでは、各message frameはHTTP headerとchunked encoding frameにより構成されている。もしあなたが"Hello World"というmessageをxhr-pollingで送信しようとしたら、そのmessageは絶対的にWebSocketで送信しようとするデータより大きいサイズになる。
   • C: Lightweight parser 軽量なパーサ
   • Bの影響により、サーバはネットワークのdataをパースするためにたくさんの仕事をしなければならないし、いつ昔ながらのHTTPリクエスト（logn-polling）が使われるのかをわかっていなければならない。これはWebSocketは少ないサーバのCPU利用率ですむという別の利点をあらわしている。

2. Better user experience

   • 1で言及した理由により、WebSocketによる接続確立の重要な影響は、raw dataの転送速度であり、これはいくつかの場合においてより良いUXであるととらえられる。
   • 重いリアルタイムのインタラクションがあるアプリケーション（ゲームなど）は大変に恩恵を受けられる。その一方でリアルタイムチャット（Gmail/Facebook）、ニュースフィード（Facebook）やタイムライン（Twitter）には些細な改善にしかならない。

このように言えるが、WebSocket接続を直接確立するには、これまでのところ以下のような問題になり得る点が証明されている:

1. Proxies
   • 多くの会社のproxyはWebSocket通信を遮断する
2. Personal firewall and antivirus software
   • 調査の結果、少なくとも3点の個人向けセキュリティアプリケーションがWebSocket通信を遮断することがわかっている
3. Cloud application platforms
   • HerokuのようなplatformやNo.deはWebSocketプロトコルの早いペースでの進化についていくことに問題を抱えている。結局のところアプリケーションはlong-pollingを使うことを避けられない。しかしsocket.io開発チームはssocket.ioのインストールがシームレスに行えるようにして、こういったことががなくなるように努力している。

これらのいくつかの問題には解決法がある。しかしながら、proxyと個人のプログラムに関しては、解決には何回ものソフトウェアのアップグレードが含まれてしまう。
経験から言ってクライアントソフトウェアのアップグレードをビジネスの解決法として提供するのは無益である: このプロジェクトの存在そのものはuser agent distributionのばらばらになった全景（panorama）に対処することである。そしてそれは最新のモダンなuser agent(Chrome, FireFox, and Safari)で行うクライアントの接続による。けれども、IE5.5よりも古い他のバージョンもあるのだ。

ユーザ視点からは、成功しなかったWebSocketの接続は、リアルタイムアプリケーションがデータを通信し始めるまでに少なくとも最高10秒間の待ち時間をかけて通信の変換を行う。これはUXを知覚的に感じ取れるほど損なっている。

まとめると、Engineは信頼性とUXを第1に集中する。また、軽微で潜在的なUXの改善とサーバの性能改善を第2とおく。Engineは結果として荒野のWebSocketから学んだ教訓となっている。