コンテンツにスキップ

「WebSocket」の版間の差分

出典: フリー百科事典『ウィキペディア(Wikipedia)』
削除された内容 追加された内容
現在の標準仕様のありかの記載をとりあえず追加
m編集の要約なし
1行目: 1行目:
'''WebSocket'''(ウェブソケット)は、[[コンピュータネットワーク|コンピュータ・ネットワーク]]用の通信規格の1つである。[[ウェブアプリケーション]]において、[[複信|双方向通信]]を実現するための技術規格である。
'''WebSocket'''(ウェブソケット)は、[[コンピュータネットワーク]]用の通信規格の1つである。[[ウェブアプリケーション]]において、[[複信|双方向通信]]を実現するための技術規格である。


標準仕様が以下のように規定されている。
標準仕様が以下のように規定されている。
* [[アプリケーションプログラミングインタフェース|API]]はHTML仕様の中に含まれている: [https://html.spec.whatwg.org/multipage/comms.html#network HTML Standard 9.3 Web sockets]([https://triple-underscore.github.io/WebSocket-ja.html 日本語訳])。
* [[アプリケーションプログラミングインタフェース|API]]は[[HyperText Markup Language|HTML]]仕様の中に含まれている: [https://html.spec.whatwg.org/multipage/comms.html#network HTML Standard 9.3 Web sockets]([https://triple-underscore.github.io/WebSocket-ja.html 日本語訳])。
* [[通信プロトコル]]: RFC 6455 ([https://triple-underscore.github.io/RFC6455-ja.html 日本語訳])に加えて[https://fetch.spec.whatwg.org/#websocket-protocol Fetch Standard 6. WebSocket protocol alterations]([https://triple-underscore.github.io/Fetch-ja.html#websocket-protocol 日本語訳])
* [[通信プロトコル]]: RFC 6455 ([https://triple-underscore.github.io/RFC6455-ja.html 日本語訳])に加えて[https://fetch.spec.whatwg.org/#websocket-protocol Fetch Standard 6. WebSocket protocol alterations]([https://triple-underscore.github.io/Fetch-ja.html#websocket-protocol 日本語訳])


8行目: 8行目:
[[XMLHttpRequest]]の欠点を解決する技術として開発されており、現在の[[Comet]]等に取って代わることを目標としている。
[[XMLHttpRequest]]の欠点を解決する技術として開発されており、現在の[[Comet]]等に取って代わることを目標としている。


いわゆる[[Ajax]]アプリケーションではサーバとクライアント間のデータのやり取りが頻繁に発生するが、従来のXMLHttpRequestはあくまでブラウザ側からサーバにデータの送信要求を出す手段に過ぎず、サーバ側からクライアントにデータをプッシュ配信することが難しい。一方Cometではサーバ側からのプッシュ配信が可能なものの、多くの実装では擬似的に双方向通信を行うため通信が発生するごとにTCPの[[ハンドシェイク]]手続きを再度行う必要があるほか、HTTPコネクションを長時間占有するためその間同一サーバに接続する他のアプリケーションの動作に影響を及ぼす可能性があるなど、また別の問題が生じる([[XMLHttpRequest#ロングポーリング]]も参照)。
いわゆる[[Ajax]]アプリケーションでは[[サーバ]][[クライアント (コンピュータ)|クライアント]]間のデータのやり取りが頻繁に発生するが、従来の[[XMLHttpRequest]]はあくまで[[ウェブブラウザ|ブラウザ]]側からサーバにデータの送信要求を出す手段に過ぎず、サーバ側からクライアントにデータをプッシュ配信することが難しい。一方Cometではサーバ側からのプッシュ配信が可能なものの、多くの実装では擬似的に双方向通信を行うため通信が発生するごとに[[Transmission Control Protocol|TCP]]の[[ハンドシェイク]]手続きを再度行う必要があるほか、HTTPコネクションを長時間占有するためその間同一サーバに接続する他のアプリケーションの動作に影響を及ぼす可能性があるなど、また別の問題が生じる([[XMLHttpRequest#ロングポーリング]]も参照)。


これに対しWebSocketでは、サーバとクライアントが一度コネクションを行った後は、必要な通信を全てそのコネクション上で専用のプロトコルを用いて行う。従来の手法に比べると、新たなコネクションを張ることがなくなる・HTTPコネクションとは異なる軽量プロトコルを使うなどの理由により通信ロスが減る、一つのコネクションで全てのデータ送受信が行えるため同一サーバに接続する他のアプリケーションへの影響が少ないなどのメリットがある。<ref>[http://gihyo.jp/dev/feature/01/websocket/0001 Jettyで始めるWebSocket超入門 第1回 WebSocket登場までの歴史] - gihyo.jp・2010年7月16日</ref>。
これに対しWebSocketでは、サーバとクライアントが一度コネクションを行った後は、必要な通信を全てそのコネクション上で専用のプロトコルを用いて行う。従来の手法に比べると、新たなコネクションを張ることがなくなる・HTTPコネクションとは異なる軽量[[通信プロトコル|プロトコル]]を使うなどの理由により通信ロスが減る、一つのコネクションで全てのデータ送受信が行えるため同一サーバに接続する他のアプリケーションへの影響が少ないなどのメリットがある。<ref>[http://gihyo.jp/dev/feature/01/websocket/0001 Jettyで始めるWebSocket超入門 第1回 WebSocket登場までの歴史] - gihyo.jp・2010年7月16日</ref>。


== プロトコル ==
== プロトコル ==
WebSocketの接続を確立するために、クライアント側はまずハンドシェイク要求を送る。そして、サーバ側はハンドシェイク応答を返す。以下がその例である。
WebSocketの接続を確立するために、クライアント側はまず[[ハンドシェイク]]要求を送る。そして、サーバ側はハンドシェイク応答を返す。以下がその例である。


ウェブブラウザが以下の要求をサーバ側に送る:
[[ウェブブラウザ]]が以下の要求をサーバ側に送る:


<pre>
<pre>
28行目: 28行目:
</pre>
</pre>


サーバ側は以下の応答を返す。
サーバ側は以下の応答を返す。


<pre>
<pre>
38行目: 38行目:
</pre>
</pre>


ハンドシェイクは[[HTTP]]の様であるが、厳密には異なる。サーバ側は最初HTTPの要求として解釈し、そして、WebSocketへと切り替える。
ハンドシェイクは[[Hypertext Transfer Protocol|HTTP]]の様であるが、厳密には異なる。サーバ側は最初HTTPの要求として解釈し、そして、WebSocketへと切り替える。


== URIスキーム ==
== URIスキーム ==
WebSocket プロトコルの仕様書は '''ws:''' と '''wss:''' という2つの新しい URI スキームを定義している<ref>[http://www.iana.org/assignments/uri-schemes.html IANA Uniform Resource Identifer (URI) Schemes]</ref>。
WebSocketプロトコルの仕様書は'''ws:''' と '''wss:'''という2つの新しい[[Uniform Resource Identifier|URI]][[スキーム]]を定義している<ref>[http://www.iana.org/assignments/uri-schemes.html IANA Uniform Resource Identifer (URI) Schemes]</ref>。


==実装状況==
==実装状況==
===クライアント===
===クライアント===
クライアント側は、[[Internet Explorer 10]](含むモバイル)、[[Mozilla Firefox]] 6 ([[Firefox for Mobile]] 7)、[[Google Chrome]] 4 (含むモバイル)、[[Safari]] 5 (含む[[iOS (アップル)|iOS]] 4.2以降)、[[Opera]] 12.10(含むモバイル)、[[Android]] 4.4、[[BlackBerry]] 7 (要設定)で実装されている。
クライアント側は、[[Internet Explorer 10]](含むモバイル)、[[Mozilla Firefox]] 6 ([[Firefox for Mobile]] 7)、[[Google Chrome]] 4 (含むモバイル)、[[Safari]] 5(含む[[iOS (アップル)|iOS]] 4.2以降、[[Opera]] 12.10(含むモバイル)、[[Android]] 4.4、[[BlackBerry]] 7(要設定で実装されている。


{| class="wikitable"
{| class="wikitable"
67行目: 67行目:
! draft-hixie-thewebsocketprotocol-76<br/>draft-ietf-hybi-thewebsocketprotocol-00
! draft-hixie-thewebsocketprotocol-76<br/>draft-ietf-hybi-thewebsocketprotocol-00
|
|
|4 (無効化)
|4(無効化
|6
|6
|5.0.1
|5.0.1
|11.00 (要設定)<br>Opera Mobileも要設定
|11.00(要設定<br>Opera Mobileも要設定
|
|
|-
|-
98行目: 98行目:
|}
|}


ウェブブラウザのプラグインを利用する物
ウェブブラウザの[[プラグイン]]を利用する物
* [[Adobe Flash]] - jWebsocket FlashBridge
* [[Adobe Flash]] - jWebsocket FlashBridge
* [[Silverlight]] - Microsoft WCF WebSockets, CodeProject記事 (SuperWebSocket 利用)<ref>[http://www.codeproject.com/KB/silverlight/WebSocketsSilverlight.aspx WebSockets, WCF, and Silverlight 5 - CodeProject]</ref>
* [[Silverlight]] - Microsoft WCF WebSocketsCodeProject記事(SuperWebSocket利用<ref>[http://www.codeproject.com/KB/silverlight/WebSocketsSilverlight.aspx WebSockets, WCF, and Silverlight 5 - CodeProject]</ref>


プロトコル上の <code>Sec-WebSocket-Version:</code> とドラフト番号の対応関係は以下の通り。hybi-04からプロトコル上に対応するドラフト番号が現れるようになった。
プロトコル上の<code>Sec-WebSocket-Version:</code>とドラフト番号の対応関係は以下の通り。hybi-04からプロトコル上に対応するドラフト番号が現れるようになった。
{| class="wikitable"
{| class="wikitable"
|+
|+
127行目: 127行目:
|}
|}


===サーバ===
===サーバ===
* C/C++
* C/C++
** [http://git.warmcat.com/cgi-bin/cgit/libwebsockets/ libwebsockets]
** [http://git.warmcat.com/cgi-bin/cgit/libwebsockets/ libwebsockets]
170行目: 170行目:


===歴史的経緯===
===歴史的経緯===
プロトコルは2011年5月の完成を目標に進められていたが<ref>[https://datatracker.ietf.org/wg/hybi/charter/ BiDirectional or Server-Initiated HTTP (hybi) - Charter]</ref>、その期日を過ぎても仕様の改訂は続けられ、2011年7月11日に最終草案のdraft-ietf-hybi-thewebsocketprotocol-10が勧告<ref>[http://www.ietf.org/mail-archive/web/hybi/current/msg07725.html hybi Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard]</ref>されたが、さらにその後も改訂は続き、2011年9月30日に draft-ietf-hybi-thewebsocketprotocol-17 がリリースされ、それが2011年12月11日に RFC 6455 proposed standard (標準化への提唱)となった。
プロトコルは2011年5月の完成を目標に進められていたが<ref>[https://datatracker.ietf.org/wg/hybi/charter/ BiDirectional or Server-Initiated HTTP (hybi) - Charter]</ref>、その期日を過ぎても仕様の改訂は続けられ、2011年7月11日に最終草案のdraft-ietf-hybi-thewebsocketprotocol-10が勧告<ref>[http://www.ietf.org/mail-archive/web/hybi/current/msg07725.html hybi Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard]</ref>されたが、さらにその後も改訂は続き、2011年9月30日に draft-ietf-hybi-thewebsocketprotocol-17がリリースされ、それが2011年12月11日にRFC 6455のproposed standard(標準化への提唱)となった。


2010年11月26日にdraft-ietf-hybi-thewebsocketprotocol-03やそれ以前のWebSocketのプロトコルにセキュリティホールが発見され<ref>[http://www.ietf.org/mail-archive/web/hybi/current/msg04744.html hybi Experiment comparing Upgrade and CONNECT handshakes]</ref>、2010年12月に、一時的に、Firefox 4とOpera 11のWebSocketが無効になり、Chromeはプロトコル改訂よりも先に攻撃コードが出た場合は無効にするとしていた。Opera 11 <code>opera:config#Enable%20WebSockets</code> を開き、設定を有効にすると利用可能。その後、2011年1月11日にdraft-ietf-hybi-thewebsocketprotocol-04が発表され、サーバにアップロード通信する際はプロキシを混乱させないために、通信内容を XOR でマスキングさせる方法となった。2011年8月16日に再度WebSocketに対応させた、Firefox 6 がリリースされたが、まだ、仕様の改訂が続くという理由から、Firefox 10 までは、MozWebSocket と頭に Moz がつく形となった<ref>[https://bugzilla.mozilla.org/show_bug.cgi?id=659324 Bug 659324 &ndash; prefix the JS API for WebSockets]</ref>。[[Firefox for Mobile]] 7 から対応<ref>[https://dev.mozilla.jp/2011/08/firefox7/ Firefox 7 の主な新機能を紹介します « Mozilla Developer Street (modest)]</ref>。
2010年11月26日にdraft-ietf-hybi-thewebsocketprotocol-03やそれ以前のWebSocketのプロトコルにセキュリティホールが発見され<ref>[http://www.ietf.org/mail-archive/web/hybi/current/msg04744.html hybi Experiment comparing Upgrade and CONNECT handshakes]</ref>、2010年12月に、一時的に、Firefox 4とOpera 11のWebSocketが無効になり、Chromeはプロトコル改訂よりも先に攻撃コードが出た場合は無効にするとしていた。Opera 11は<code>opera:config#Enable%20WebSockets</code>を開き、設定を有効にすると利用可能。その後、2011年1月11日にdraft-ietf-hybi-thewebsocketprotocol-04が発表され、サーバにアップロード通信する際は[[プロキシ]]を混乱させないために、通信内容を[[排他的論理和|XOR]]でマスキングさせる方法となった。2011年8月16日に再度WebSocketに対応させた、Firefox 6 がリリースされたが、まだ、仕様の改訂が続くという理由から、Firefox 10までは、MozWebSocketと頭にMozがつく形となった<ref>[https://bugzilla.mozilla.org/show_bug.cgi?id=659324 Bug 659324 &ndash; prefix the JS API for WebSockets]</ref>。[[Firefox for Mobile]]は7から対応<ref>[https://dev.mozilla.jp/2011/08/firefox7/ Firefox 7 の主な新機能を紹介します « Mozilla Developer Street (modest)]</ref>。


[[ウェブブラウザ]]で動作する[[JavaScript]]用のAPIの策定は、当初[[World Wide Web Consortium|W3C]]で行われていた。その後、[[HTML5]]とともに[[WHATWG]]に移ることとなった。
ウェブブラウザで動作する[[JavaScript]]用の[[アプリケーションプログラミングインタフェース|API]]の策定は、当初[[World Wide Web Consortium|W3C]]で行われていた。その後、[[HTML5]]とともに[[Web Hypertext Application Technology Working Group|WHATWG]]に移ることとなった。


== 関連項目 ==
== 関連項目 ==

2017年10月11日 (水) 15:01時点における版

WebSocket(ウェブソケット)は、コンピュータネットワーク用の通信規格の1つである。ウェブアプリケーションにおいて、双方向通信を実現するための技術規格である。

標準仕様が以下のように規定されている。

概要

XMLHttpRequestの欠点を解決する技術として開発されており、現在のComet等に取って代わることを目標としている。

いわゆるAjaxアプリケーションではサーバクライアント間のデータのやり取りが頻繁に発生するが、従来のXMLHttpRequestはあくまでブラウザ側からサーバにデータの送信要求を出す手段に過ぎず、サーバ側からクライアントにデータをプッシュ配信することが難しい。一方Cometではサーバ側からのプッシュ配信が可能なものの、多くの実装では擬似的に双方向通信を行うため通信が発生するごとにTCPハンドシェイク手続きを再度行う必要があるほか、HTTPコネクションを長時間占有するためその間同一サーバに接続する他のアプリケーションの動作に影響を及ぼす可能性があるなど、また別の問題が生じる(XMLHttpRequest#ロングポーリングも参照)。

これに対しWebSocketでは、サーバとクライアントが一度コネクションを行った後は、必要な通信を全てそのコネクション上で専用のプロトコルを用いて行う。従来の手法に比べると、新たなコネクションを張ることがなくなる・HTTPコネクションとは異なる軽量プロトコルを使うなどの理由により通信ロスが減る、一つのコネクションで全てのデータ送受信が行えるため同一サーバに接続する他のアプリケーションへの影響が少ないなどのメリットがある。[1]

プロトコル

WebSocketの接続を確立するために、クライアント側はまずハンドシェイク要求を送る。そして、サーバ側はハンドシェイク応答を返す。以下がその例である。

ウェブブラウザが以下の要求をサーバ側に送る:

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13

サーバ側は以下の応答を返す。

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chat

ハンドシェイクはHTTPの様であるが、厳密には異なる。サーバ側は最初HTTPの要求として解釈し、そして、WebSocketへと切り替える。

URIスキーム

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月の完成を目標に進められていたが[4]、その期日を過ぎても仕様の改訂は続けられ、2011年7月11日に最終草案のdraft-ietf-hybi-thewebsocketprotocol-10が勧告[5]されたが、さらにその後も改訂は続き、2011年9月30日に draft-ietf-hybi-thewebsocketprotocol-17がリリースされ、それが2011年12月11日にRFC 6455のproposed standard(標準化への提唱)となった。

2010年11月26日にdraft-ietf-hybi-thewebsocketprotocol-03やそれ以前のWebSocketのプロトコルにセキュリティホールが発見され[6]、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がつく形となった[7]Firefox for Mobileは7から対応[8]

ウェブブラウザで動作するJavaScript用のAPIの策定は、当初W3Cで行われていた。その後、HTML5とともにWHATWGに移ることとなった。

関連項目

参照

外部リンク