「WebSocket」の版間の差分

履歴の双方向閲覧

← 古い編集新しい編集 →

削除された内容追加された内容

ビジュアルウィキテキスト

インライン

2020年6月16日 (火) 08:21時点における版

WebSocket（ウェブソケット）は、コンピュータネットワーク用の通信規格の1つである。ウェブアプリケーションにおいて、双方向通信を実現するための技術規格である。2011年にRFC 6455として最初の標準仕様が定義された。

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

APIはHTML仕様の中に含まれている: HTML Standard 9.3 Web sockets（日本語訳）。
通信プロトコル: RFC 6455 （日本語訳）に加えてFetch Standard 6. WebSocket protocol alterations（日本語訳）
- HTTP/2と組み合わせる（HTTP/2ストリーム内でWebSocket通信を行う）場合: RFC 8441

概要

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

ウェブブラウザのプラグインを利用する物

Adobe Flash - jWebsocket FlashBridge
Silverlight - Microsoft WCF WebSockets、CodeProject記事（SuperWebSocket利用）^[3]

プロトコル上の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

サーバ

C/C++
Go
- golang.org/x/net/websocket
Haskell
- websockets
Java - Java EE 7 にて Java API for WebSocket (JSR 356) が追加された
- Apache Tomcat 7
- Atmosphere
- GlassFish 3.1, Grizzly
- JBoss 7
- Jetty 7
- jWebsocket
- Netty 3.3
.NET Framework
- Fleck
- Internet Information Services (IIS) 8, ASP.NET 4.5
- SuperWebSocket
Node.js
- Socket.IO
- WebSocket-Node
Objective-C
- SocketRocket
Perl
- Mojolicious
- PocketIO
PHP
- php-websocket
Python
- WebSocket-for-Python
- txWS
Ruby
- EM-WebSocket
Scala
- play framework2
その他
- apache-websocket

歴史的経緯

プロトコルは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に移ることとなった。

参照

[脚注の使い方]

外部リンク

IETF Hypertext-Bidirectional (HyBi) working group
- RFC 6455
- The WebSocket protocol - IETF でのインターネットドラフト
- The WebSocket protocol (Network Working Group) - バージョン76にて廃止された Network Working Group の古いバージョン
The WebSocket API - API の W3C 勧告候補
www.websocket.org - WebSocket ウェブサイト
Real-Time Web Test - Does your browser supports WebSockets?

この項目は、インターネットやウェブに関連した書きかけの項目です。この項目を加筆・訂正などしてくださる協力者を求めています（PJ:コンピュータ/P:コンピュータ）。

[1] Jettyで始めるWebSocket超入門第1回　WebSocket登場までの歴史 - gihyo.jp・2010年7月16日

[2] IANA Uniform Resource Identifer (URI) Schemes

[3] WebSockets, WCF, and Silverlight 5 - CodeProject

[4] BiDirectional or Server-Initiated HTTP (hybi) - Charter

[5] ybi Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard

[6] ybi Experiment comparing Upgrade and CONNECT handshakes

[7] Bug 659324 – prefix the JS API for WebSockets

[8] Firefox 7 の主な新機能を紹介します « Mozilla Developer Street (modest)

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

@@ 1行目: / 1行目: @@
-'''WebSocket'''（ウェブソケット）は、[[コンピュータネットワーク]]用の通信規格の1つである。[[ウェブアプリケーション]]において、[[複信|双方向通信]]を実現するための技術規格である。
+'''WebSocket'''（ウェブソケット）は、[[コンピュータネットワーク]]用の通信規格の1つである。[[ウェブアプリケーション]]において、[[複信|双方向通信]]を実現するための技術規格である。[[2011年]]にRFC 6455として最初の標準仕様が定義された。
-標準仕様が以下のように規定されている。
+標準仕様は以下のように規定されている。
 * [[アプリケーションプログラミングインタフェース|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 日本語訳]）
@@ 7行目: / 7行目: @@
 == 概要 ==
-[[XMLHttpRequest]]の欠点を解決する技術として開発されており、現在の[[Comet]]等に取って代わることを目標としている。
+[[XMLHttpRequest]]の欠点を解決する技術として開発されており、既存の[[Comet]]等に取って代わることを目標としている。
 いわゆる[[Ajax]]アプリケーションでは[[サーバ]]と[[クライアント (コンピュータ)|クライアント]]間のデータのやり取りが頻繁に発生するが、従来の[[XMLHttpRequest]]はあくまで[[ウェブブラウザ|ブラウザ]]側からサーバにデータの送信要求を出す手段に過ぎず、サーバ側からクライアントにデータをプッシュ配信することが難しい。一方Cometではサーバ側からのプッシュ配信が可能なものの、多くの実装では擬似的に双方向通信を行うため通信が発生するごとに[[Transmission Control Protocol|TCP]]の[[ハンドシェイク]]手続きを再度行う必要があるほか、HTTPコネクションを長時間占有するためその間同一サーバに接続する他のアプリケーションの動作に影響を及ぼす可能性があるなど、また別の問題が生じる（[[XMLHttpRequest#ロングポーリング]]も参照）。
@@ 180行目: / 180行目: @@
 * [[Push技術]]
 * [[Comet]]
-* [[SPDY]]
+* [[gRPC]]
 == 参照 ==