WebSocketのRFCを一寸だけ訳す

HTML5と共に気になる技術があります。WebSocket。TCPソケット通信をHTTPプロトコルの下で実現する技術であり、試みだと想像しています。XMLHttpRequestを利用するAjaxは、ドキュメント全体の更新で高負荷となるHTTPと異なり、初めて観た時に革新的だった。でもプログラムレベルでは、やっぱりなじまない。もう少し、他の部分とは独立的にTCP送信を実装したいもんだと、WebSocketに期待しています。
そのWebSocketですが、RFCが公開されていたので、さわりの部分だけ訳してみました。

原文は、ここです。
http://tools.ietf.org/html/rfc6455

いやあ、酷い和訳です。あくまで自分の勉強のためなので、決して訳を鵜呑みにしないように。そもそも、日本語になっていないような気もするし、概要と導入部の最初の節だけなので、具体的な内容には乏しい。

ウェブソケット プロトコル

概要
ウェブソケット・プロトコルは、管理された環境で委託されたコードが動いているクライアントと、そのコードが通信を受け取っているホストとの双方向通信を可能にします。
セキュリティモデルは、ウェブ・ブラウザに一般に使われている原初的なセキュリティモデルです。プロトコルは、T通信を開始時の通信確定手順と、それに続くTCP層の基本的なメッセージ・フレーム群で構成されています。
この技術の狙いは、サーバとの双方向通信を必要とするブラウザベースのアプリケーションに、XMLHttpRequest、iframe、ロング・ポーリングのような複合的なHTTP接続に頼らない、機構を提供することです。

1. 導入（イントロダクション）
1.1. 背景
歴史的に、クライアントとサーバ間の二方向の通信を必要とするウェブアプリ（チャット、ゲームとか）は、更新確認のため、上位への通知を送信する間、(ドキュメントの表示のためのHTTPではない）別のHTTPコール(RFC6202)を使ったサーバへのポーリングを多用してきた。

この結果は、様々な問題を生むことになる。
* サーバは、それぞれのクライアントと、クライアント数だけのTCP通信を強いられる。ある通信は、クライアントに情報を送り、またある通信は送られてくるメッセージを受け取るために。
* 通信の成立は、非常に負荷が高い。それぞれのクライアントーサーバ間メッセージは、(そのための）HTTP headerをメッセージ毎に持っている。
* クライアントサイドスクリプト(Ajaxのような)は、送信結果を結びつけるために、送信と受信の管理（マッピング）を強いられる。

より単純な解決は、双方向の流れをまとめた一つのTCP接続を使うことであるべきだ。これが、ウェブソケットプロトコルの提供するものだ。WebSocket APIを組み込むことで、ウェブプロトコルは、ウェブページから、遠隔地のサーバへの双方向通信を実現するため、HTTPポーリングに代わる別の手段を提供する。
同様の技術は、様々なウェブ・アプリケーションで使われることが可能だ。ゲーム、リアルな証券情報ニュース、複数人による同時編集アプリ、リアルタイムな情報発信機能を提供するユーザインターフェースなどなど。

ウェブソケット プロトコルは、現存する基盤（プロキシ、フィルタリング、認証）からの利便性を得るために、トランスポート層でHTTPを利用している現存の双方向通信技術を捨て去ることができるように設計されました。

== このあたり、全くお手上げ ==
そのような（現存の）技術は、効率と信頼性のトレードオフのもとで実装されている。なぜなら、HTTPは、本来、双方向通信に利用されることを意図していなかったからである。
ウェブソケットは、その目的を、既存のHTTP基盤のもとで、既存のHTTP双方向通信技術に割り当てている（？）。それは、80ポートや443ポートで動作することで、HTTPプロキシや媒体（それが、現在の環境への特殊な使用を意味することであっても）をサポートすることだ。
「 The WebSocket Protocol attempts to address the
goals of existing bidirectional HTTP technologies in the context of
the existing HTTP infrastructure; as such, it is designed to work
over HTTP ports 80 and 443 as well as to support HTTP proxies and
intermediaries, even if this implies some complexity specific to the
current environment.」
== ここまで ==

しかし、設計では、ウェブソケットをHTTPのみに制限していないし、将来の実装では、全体のプロトコルを再構成する事無く、専用のポートのもとで、より単純な通信確定を使うことが出来る。
最後の点は、重要である。なぜなら、双方向のメッセージ通信の際の交信パターンは標準的なHTTP交信にぴったりとはあっていないし、いくつかのコンポーネントの一寸変わった取込を実現できるからだ。