 |
WebSocket（ウェブソケット）は、単一のTCPコネクション上に双方向通信のチャンネルを提供する、コンピュータの通信プロトコルの1つである。WebSocketプロトコルは、2011年にRFC 6455としてIETFにより標準化された。Web IDL（英語版）中のWebSocketAPIは、当初W3Cにより標準され、後にWHATWGに引き継がれている。
WebSocketはHTTPとは異なるプロトコルである。ともにOSI参照モデルのレイヤー7に位置し、レイヤー4のTCPに依存している。両者は異なるプロトコルであるが、RFC 6455では、WebSocketは「HTTPプロキシと仲介者をサポートするために、HTTPの443番および80番ポート上で動作するように設計されている」と述べられているように、HTTPプロトコルと互換性がある。互換性を実現するために、WebSocketのハンドシェイクはHTTP/1.1 Upgradeヘッダーを使用し、HTTPプロトコルをWebSocketプロトコルに変更するように実現されている。
標準仕様は以下のように規定されている。
XMLHttpRequestの欠点を解決する技術として開発されており、既存のComet等に取って代わることを目標としている。
いわゆるAjaxアプリケーションではサーバとクライアント間のデータのやり取りが頻繁に発生するが、従来のXMLHttpRequestはあくまでブラウザ側からサーバにデータの送信要求を出す手段に過ぎず、サーバ側からクライアントにデータをプッシュ配信することが難しい。一方Cometではサーバ側からのプッシュ配信が可能なものの、多くの実装では擬似的に双方向通信を行うため通信が発生するごとにTCPのハンドシェイク手続きを再度行う必要があるほか、HTTPコネクションを長時間占有するためその間同一サーバに接続する他のアプリケーションの動作に影響を及ぼす可能性があるなど、また別の問題が生じる（XMLHttpRequest#ロングポーリングも参照）。
これに対しWebSocketでは、サーバとクライアントが一度コネクションを行った後は、必要な通信を全てそのコネクション上で専用のプロトコルを用いて行う。従来の手法に比べると、新たなコネクションを張ることがなくなる・HTTPコネクションとは異なる軽量プロトコルを使うなどの理由により通信ロスが減る、一つのコネクションで全てのデータ送受信が行えるため同一サーバに接続する他のアプリケーションへの影響が少ないなどのメリットがある[1]。
WebSocketの接続を確立するために、クライアント側はまずハンドシェイク要求を送る。そして、サーバ側はハンドシェイク応答を返す。以下はHTTP/1.1の場合の例である。
ウェブブラウザが以下の要求をサーバ側に送る：
GET /chat HTTP/1.1Host: server.example.comUpgrade: websocketConnection: UpgradeSec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==Origin: http://example.comSec-WebSocket-Protocol: chat, superchatSec-WebSocket-Version: 13
サーバ側は以下の応答を返す。
HTTP/1.1 101 Switching ProtocolsUpgrade: websocketConnection: UpgradeSec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=Sec-WebSocket-Protocol: chat
ハンドシェイクはHTTPの様であるが、厳密には異なる。サーバ側は最初HTTPの要求として解釈し、そして、WebSocketへと切り替える。
WebSocketプロトコルの仕様書はws: とwss:という2つの新しいURIスキームを定義している[2]。
クライアント側は、Internet Explorer 10（含むモバイル）、Mozilla Firefox 6 (Firefox for Mobile 7)、Google Chrome 4 (含むモバイル)、Safari 5（含むiOS 4.2以降）、Opera 12.10（含むモバイル）、Android 4.4、BlackBerry 7（要設定）で実装されている。
| プロトコル | Internet Explorer | Mozilla Firefox | Google Chrome | Safari | Opera | Android |
|---|---|---|---|---|---|---|
| draft-hixie-thewebsocketprotocol-75 | 4 | 5.0.0 | ||||
| draft-hixie-thewebsocketprotocol-76 draft-ietf-hybi-thewebsocketprotocol-00 | 4（無効化） | 6 | 5.0.1 | 11.00（要設定） Opera Mobileも要設定 | ||
| draft-ietf-hybi-thewebsocketprotocol-07 | 6 | |||||
| draft-ietf-hybi-thewebsocketprotocol-10 | 7 | 14 | ||||
| RFC 6455 | 10 | 11 | 16 | 6 | 12.10 | 4.4 |
ウェブブラウザのプラグインを利用する物
プロトコル上のSec-WebSocket-Version:とドラフト番号の対応関係は以下の通り。hybi-04からプロトコル上に対応するドラフト番号が現れるようになった。
| Sec-WebSocket-Version: | ドラフト番号 |
|---|---|
| 4 | hybi-04 |
| 5 | hybi-05 |
| 6 | hybi-06 |
| 7 | hybi-07 |
| 8 | hybi-08〜12 |
| 13 | hybi-13〜17 RFC 6455 |
プロトコルは2011年5月の完成を目標に進められていたが[5]、その期日を過ぎても仕様の改訂は続けられ、2011年7月11日に最終草案のdraft-ietf-hybi-thewebsocketprotocol-10が勧告[6]されたが、さらにその後も改訂は続き、2011年9月30日に draft-ietf-hybi-thewebsocketprotocol-17がリリースされ、それが2011年12月11日にRFC 6455のproposed standard（標準化への提唱）となった。
2010年11月26日にdraft-ietf-hybi-thewebsocketprotocol-03やそれ以前のWebSocketのプロトコルにセキュリティホールが発見され[7]、2010年12月に、一時的に、Firefox 4とOpera 11のWebSocketが無効になり、Chromeはプロトコル改訂よりも先に攻撃コードが出た場合は無効にするとしていた。Opera 11はopera:config#Enable%20WebSocketsを開き、設定を有効にすると利用可能。その後、2011年1月11日にdraft-ietf-hybi-thewebsocketprotocol-04が発表され、サーバにアップロード通信する際はプロキシを混乱させないために、通信内容をXORでマスキングさせる方法となった。2011年8月16日に再度WebSocketに対応させた、Firefox 6 がリリースされたが、まだ、仕様の改訂が続くという理由から、Firefox 10までは、MozWebSocketと頭にMozがつく形となった[8]。Firefox for Mobileは7から対応[9]。
ウェブブラウザで動作するJavaScript用のAPIの策定は、当初W3Cで行われていた。その後、HTML5とともにWHATWGに移ることとなった。
WHATWGでは、当初主にHTML Standard内でWebSocketのAPIが規定していた。その後、2021年に別個の仕様に分離することが提起され[10]、WebSockets Standardが創設されることとなった。
典拠管理データベース: 国立図書館 |
|---|
 | この項目は、インターネットやウェブに関連した書きかけの項目です。この項目を加筆・訂正などしてくださる協力者を求めています（PJ:コンピュータ/P:コンピュータ）。 |
