Loading article…
 WebSocketを使用した接続を説明する図 | |
| 国際標準 | RFC 6455 |
|---|---|
| 開発者 | 国際電気通信連合 |
| 業界 | コンピュータサイエンス |
| コネクタタイプ | TCP |
| Webサイト | https://websockets.spec.whatwg.org/ |
WebSocket はコンピュータ通信プロトコルであり、単一の伝送制御プロトコル(TCP) 接続を介して同時双方向通信チャネルを提供します。WebSocket プロトコルは、 2011 年にIETFによってRFC 6455として標準化されました 。Web アプリケーションがこのプロトコルを使用できるようにする現在の仕様は、WebSocketとして知られています。[1]これは、 WHATWGによって維持されているライブ スタンダードであり、 W3CのWebSocket APIの後継です。[2]
WebSocket は、ほとんどの Web ページを提供するために使用されるHTTPとは異なります。両者は異なりますが、RFC 6455 では、WebSocket は「HTTP ポート 443 および 80 で動作し、HTTP プロキシおよび仲介者をサポートするように設計されている」と述べられており、HTTP と互換性があります。互換性を実現するために、WebSocketハンドシェイクでは、 HTTP アップグレード ヘッダー[3]を使用して、HTTP プロトコルから WebSocket プロトコルに変更します。
WebSocket プロトコルは、Web ブラウザ(または他のクライアントアプリケーション) とWeb サーバー間の全二重通信を、 HTTPポーリングなどの半二重通信よりも低いオーバーヘッドで実現し、サーバーとの間でのリアルタイムのデータ転送を容易にします。これは、サーバーがクライアントから最初に要求されることなくクライアントにコンテンツを送信するための標準化された方法を提供し、接続を開いたままメッセージをやり取りできるようにすることで可能になります。このようにして、クライアントとサーバーの間で双方向の継続的な会話を行うことができます。通信は通常、TCPポート番号 443 (または、セキュリティで保護されていない接続の場合は 80) を介して行われます。これは、ファイアウォールを使用して Web 以外のインターネット接続をブロックする環境で役立ちます。さらに、WebSocket は TCP 上でメッセージのストリームを可能にします。TCP だけでは、メッセージの概念が存在しないバイト ストリームを扱います。同様の双方向のブラウザ サーバー通信は、 CometやAdobe Flash Playerなどの一時的なテクノロジを使用して、標準化されていない方法で実現されています。[4]
Google Chrome、Firefox、Microsoft Edge、Internet Explorer、Safari、Operaなどほとんどのブラウザがこのプロトコルをサポートしています。[5]
WebSocketプロトコル仕様では、 ws(WebSocket)とwss(WebSocket Secure)を、それぞれ暗号化されていない接続と暗号化された接続に使用される2つの新しいURI( Uniform Resource Identifier )スキーム[6]として定義しています。スキーム名とフラグメント(つまり、は#サポートされていません)を除いて、残りのURIコンポーネントはURI汎用構文を使用するように定義されています。[7]
歴史
WebSocket は、TCP ベースのソケット API のプレースホルダーとして、HTML5仕様で最初に TCPConnection として参照されました。 [8] 2008 年 6 月、 Michael Carterが主導する一連の議論の結果、WebSocket として知られるプロトコルの最初のバージョンが生まれました。[9] WebSocket 以前は、ポート 80 の全二重通信はCometチャネルを 使用して実現できましたが、Comet の実装は簡単ではなく、TCP ハンドシェイクと HTTP ヘッダーのオーバーヘッドのため、小さなメッセージには非効率的です。WebSocket プロトコルは、Web のセキュリティの前提を損なうことなくこれらの問題を解決することを目的としています。「WebSocket」という名前は、その後すぐにIan Hicksonと Michael Carter によって #whatwg IRC チャット ルームでのコラボレーションを通じて作られ、[10]その後、Ian Hickson によって HTML5 仕様に組み込むために作成されました。2009 年 12 月、Google Chrome 4 は、WebSocket がデフォルトで有効になっている標準を完全にサポートした最初のブラウザーになりました。[11] WebSocketプロトコルの開発はその後、2010年2月にW3CおよびWHATWGグループからIETFに移され、イアン・ヒクソンの下で2回の改訂が行われました。[12]
プロトコルが出荷され、複数のブラウザでデフォルトで有効化された後、 2011 年 12 月に Ian Fette の下で RFC 6455 が完成しました。
RFC 7692 では、メッセージごとに DEFLATEアルゴリズム を使用して WebSocket に圧縮拡張機能が導入されました。
クライアントの例
<!DOCTYPE html>
< script >
// サーバーに接続
ws = new WebSocket ( "ws://127.0.0.1/scoreboard" ) // ローカル サーバー// ws = new WebSocket("wss://game.example.com/scoreboard") // リモート サーバー
ws . onopen = () => { console . log ( "接続が開かれました" ) ws . send ( "こんにちは、サーバーさん。昨日のゲームのスコアを送ってください" ) }
ws . onmessage = ( event ) => { console . log ( "データを受信しました" , event . data ) ws . close () // スコアを取得したので、接続はもう必要ありません}
ws.onclose = ( event ) = > { console.log ( "接続が閉じられました" 、event.code 、event.reason 、event.wasClean ) }
ws . onerror = () => { console . log ( "エラーのため接続が閉じられました" ) } </ script >
サーバーの例
socket からsocketをインポートし、 base64からb64encodeをインポートし、 hashlibからsha1をインポートします。
マジック = b "258EAFA5-E914-47DA-95CA-C5AB0DC85B11"
# ソケットを作成し、ポート 80 で listen します
ws = socket ( )
ws .bind (( "" , 80 )) ws .listen ( ) conn , addr = ws .accept ( )
#
connの行のリクエストを解析します 。recv ( 4096 ) .split ( b " \r\n " ) : if line .startswith ( b " Sec-WebSocket-Key" ): nonce = line .split ( b " : " ) [ 1 ] .strip ()
# 応答のフォーマット
response = f """ \
HTTP/1.1 101 スイッチング プロトコル
アップグレード: websocket
接続: Upgrade
Sec-WebSocket-Accept: { b64encode ( sha1 ( nonce + MAGIC ) . digest ()) . decode () }
「」
conn.send ( response.replace ( " \n " 、" \ r\ n " ) . encode ( ) )
while True : # クライアントからのメッセージをデコードします
header = conn . recv ( 2 )
FIN = bool ( header [ 0 ] & 0x80 ) # ビット 0
assert FIN == 1 , "断片化されていないメッセージのみサポートしています"
opcode = header [ 0 ] & 0xf # ビット 4-7
assert opcode == 1 または opcode == 2 , "データ メッセージのみサポートしています"
masked = bool ( header [ 1 ] & 0x80 ) # ビット 8
assert masked , "クライアントはすべてのフレームをマスクする必要があります"
payload_size = header [ 1 ] & 0x7f # ビット 9-15
assert payload_size <= 125 , "小さいメッセージのみサポートしています"
masking_key = conn . recv ( 4 )
payload = bytearray ( conn . recv ( payload_size ))
iがrange ( payload_size )の場合 : payload [ i ] = payload [ i ] ^ masking_key [ i % 4 ] print ( payload )
ウェブAPI
Web アプリケーション (Web ブラウザなど) は、WebSocketインターフェイスを使用して WebSocket サーバーに接続できます。
プロトコル
手順:
- 接続を確立するためにハンドシェイク（HTTP リクエスト+ HTTP レスポンス）を開きます。
- アプリケーション データを転送するためのデータ メッセージ。
- 接続を閉じるためのハンドシェイクの終了(2 つの Close フレーム)。
オープニングの握手
クライアントはHTTPリクエスト（メソッド GET、バージョン1.1以上）を送信し、サーバーは成功した場合はステータスコード101（プロトコル切り替え）のHTTPレスポンスを返します。これは、ハンドシェイクがHTTPと互換性があるため、WebSocketサーバーがHTTP（80）およびHTTPS（443）と同じポートを使用できることを意味します。[28]
リクエスト例: [38]
GET /chat HTTP / 1.1
ホスト: server.example.com
アップグレード: websocket
接続: アップグレード
Sec-WebSocket キー: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket プロトコル: chat、superchat
Sec-WebSocket バージョン: 13
オリジン: http://example.com
応答例:
HTTP / 1.1 101 スイッチング プロトコル
アップグレード: websocket
接続: アップグレード
Sec-WebSocket-Accept : HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Sec-WebSocket-Protocol : chat
HTTP では各行は で終わり\r\n、最後の行は空になります。
# Sec-WebSocket-Key を使用して Sec-WebSocket-Accept を計算します
from base64 import b64encode
from hashlib import sha1
from os import urandom
# key = b64encode(urandom(16)) # クライアントはこれを実行する必要があります
key = b "x3JJHMbDL1EzLkh9GBhXDw==" # 上記のサンプル リクエストの値
magic = b "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" # プロトコル定数
print ( b64encode ( sha1 ( key + magic ) . digest ()))
# 出力: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
接続が確立されると、通信は HTTP プロトコルに準拠しないバイナリ フレーム ベースのプロトコルに切り替わります。
Sec-WebSocket-Keyキャッシュプロキシが以前のWebSocket会話を再送信するのをSec-WebSocket-Accept防ぐことを目的としており、[39]認証、プライバシー、整合性は提供されません。
一部のサーバーでは短い を受け入れますがSec-WebSocket-Key、最近の多くのサーバーでは「Sec-WebSocket-Key ヘッダーが無効です」というエラーでリクエストを拒否します。
フレームベースのメッセージ
開始ハンドシェイクの後、クライアントとサーバーは、データ メッセージ(テキストまたはバイナリ) や制御メッセージ(close、ping、pong)などのメッセージをいつでも相互に送信できます。メッセージは 1 つ以上のフレームで構成されます。
フラグメンテーションにより、メッセージを2つ以上のフレームに分割できます。これにより、初期データは利用可能だが全長が不明なメッセージを送信できます。フラグメンテーションがない場合、メッセージ全体を1つのフレームで送信する必要があるため、最初のバイトを送信する前に完全な長さが必要になり、バッファが必要になります。[40]また、複数のストリームを同時に多重化することもできます（たとえば、単一の大きなペイロードでソケットを独占することを回避するため）。[41]
- 断片化されていないメッセージは、および
FIN = 1を含む単一のフレームで構成されますopcode ≠ 0。 - 断片化されたメッセージは、および
FIN = 0を含む単一のフレームと、それに続くおよび をopcode ≠ 0含む 0 個以上のフレーム、そしておよびを含む単一のフレームで終了するフレームで構成されます。FIN = 0opcode = 0FIN = 1opcode = 0
フレーム構造
オペコード
ステータスコード
ブラウザのサポート
WebSocketプロトコルの安全なバージョンは、Firefox 6、[54] Safari 6、Google Chrome 14、[55] Opera 12.10、Internet Explorer 10 [56]に実装されています。 詳細なプロトコルテストスイートレポート[57]には、これらのブラウザの特定のプロトコル側面への準拠がリストされています。
このプロトコルの古い、安全性の低いバージョンは、Opera 11とSafari 5、およびiOS 4.2のSafariのモバイルバージョンに実装されていました。[58] OS7のBlackBerryブラウザはWebSocketを実装しています。[59]脆弱性のため、Firefox 4と5、 [60]およびOpera 11では無効になっています。[61] ブラウザ開発者ツールを使用して、開発者はWebSocketハンドシェイクとWebSocketフレームを検査できます。[62]
サーバーの実装
- Nginxは2013年からWebSocketをサポートしており、バージョン1.3.13 [71]で実装され、 WebSocketアプリケーションのリバースプロキシやロードバランサとして機能するようになりました。 [72]
- Apache HTTP Serverは2013年7月からWebSocketをサポートしており、バージョン2.4.5で実装されている[73] [74]
- インターネットインフォメーションサービスは、Windows Server 2012でリリースされたバージョン8でWebSocketのサポートを追加しました。[75]
- lighttpdは2017年からWebSocketをサポートしており、lighttpd 1.4.46で実装されています。[76] lighttpd mod_proxyは、WebSocketアプリケーションのリバースプロキシおよびロードバランサーとして機能します。lighttpd mod_wstunnelは、WebSocketエンドポイントとして機能し、 JSON形式 を含む任意のデータをバックエンドアプリケーションに送信します。lighttpdは2022年からHTTP/2経由のWebSocketをサポートしており、lighttpd 1.4.65で実装されています。[77]
セキュリティに関する考慮事項
通常のクロスドメインHTTPリクエストとは異なり、WebSocketリクエストは同一生成元ポリシーによって制限されません。したがって、WebSocketサーバーは、接続がCookieまたはHTTP認証で認証されている場合に発生する可能性があるクロスサイトWebSocketハイジャック攻撃（クロスサイトリクエストフォージェリに類似）を回避するために、接続確立中に「Origin」ヘッダーを予想される生成元と照合する必要があります。機密（プライベート）データがWebSocket経由で転送されている場合は、トークンまたは同様の保護メカニズムを使用してWebSocket接続を認証することをお勧めします。[78]脆弱性の実際の例は、2020年にCable Hauntの形で確認されました。
プロキシトラバーサル
WebSocket プロトコル クライアント実装は、ユーザー エージェントが宛先ホストおよびポートに接続するときにプロキシを使用するように構成されているかどうかを検出し、構成されている場合はHTTP CONNECTメソッドを使用して永続的なトンネルを設定します。
WebSocket プロトコル自体はプロキシ サーバーやファイアウォールを認識しませんが、HTTP 互換のハンドシェイクを備えているため、HTTP サーバーはデフォルトの HTTP ポートと HTTPS ポート (それぞれ 80 と 443) を WebSocket ゲートウェイまたはサーバーと共有できます。WebSocket プロトコルは、それぞれ WebSocket と WebSocket Secure 接続を示す ws:// と wss:// プレフィックスを定義します。どちらのスキームも、HTTP アップグレード メカニズムを使用してWebSocket プロトコルにアップグレードします。一部のプロキシ サーバーは透過的で、WebSocket で正常に動作しますが、その他のプロキシ サーバーは WebSocket が正しく動作しないようにし、接続に失敗します。場合によっては、追加のプロキシ サーバー構成が必要になることがあり、特定のプロキシ サーバーをアップグレードして WebSocket をサポートする必要があることがあります。
暗号化されていないWebSocketトラフィックがWebSocketをサポートしていない明示的または透過的なプロキシサーバーを通過すると、接続が失敗する可能性があります。[79]
暗号化された WebSocket 接続を使用する場合、WebSocket Secure 接続でトランスポート層セキュリティHTTP CONNECT(TLS) を使用すると、ブラウザーが明示的なプロキシ サーバーを使用するように構成されているときにコマンドが発行されるようになります。これにより、WebSocket Secure クライアントと WebSocket サーバーの間で、HTTP プロキシを介した低レベルのエンドツーエンド TCP 通信を提供するトンネルが設定されます。透過プロキシ サーバーの場合、ブラウザーはプロキシ サーバーを認識しないため、何もHTTP CONNECT送信されません。ただし、ワイヤ トラフィックは暗号化されているため、中間の透過プロキシ サーバーは暗号化されたトラフィックをそのまま通過させる可能性があり、WebSocket Secure を使用すると WebSocket 接続が成功する可能性が高くなります。暗号化を使用するとリソース コストがかからないわけではありませんが、安全なトンネルを通過するため、成功率が最も高くなることがよくあります。
2010年半ばのドラフト（バージョンhixie-76）では、ヘッダーの後に8バイトのキーデータを含めたが、そのデータをヘッダーで宣伝しなかったため、リバースプロキシやゲートウェイとの互換性が損なわれました。 [80]このデータはすべての中間層で転送されなかったため、プロトコルの障害につながる可能性があります。最近のドラフト（例：hybi-09 [81]）では、キーデータをヘッダーに配置することでこの問題を解決しました。
Content-Length: 8Sec-WebSocket-Key
参照
注記
- ^ ab Geckoベースのブラウザバージョン6～10はWebSocketオブジェクトを「MozWebSocket」として実装しており、[65]既存のWebSocket対応コードと統合するために追加のコードが必要である。
参考文献
- ^ 「WebSockets 標準」。websockets.spec.whatwg.org。2023 年 3 月 12 日時点のオリジナルよりアーカイブ。2022 年 5 月 16 日閲覧。
- ^ 「WebSocket API」。www.w3.org。2022年6月8日時点のオリジナルよりアーカイブ。2022年5月16日閲覧。
- ^ Ian Fette、Alexey Melnikov (2011 年 12 月)。「TCP および HTTP との関係」。RFC 6455 WebSocket プロトコル。IETF。sec . 1.7。doi : 10.17487/ RFC6455。RFC 6455 。
- ^ 「Adobe Flash Platform – ソケット」。help.adobe.com。2021年4月18日時点のオリジナルよりアーカイブ。2021年7月28日閲覧。TCP
接続には「クライアント」と「サーバー」が必要です。Flash Playerはクライアントソケットを作成できます。
- ^ 「WebSocket API (WebSockets)」。MDN Web Docs。Mozilla Developer Network。2023-04-06。2021-07-28時点のオリジナルよりアーカイブ。2021-07-26取得。
- ^ Graham Klyne 編 (2011-11-14)。「IANA Uniform Resource Identifier (URI) Schemes」。Internet Assigned Numbers Authority。2013-04-25時点のオリジナルよりアーカイブ。2011-12-10取得。
- ^ Ian Fette、Alexey Melnikov (2011 年 12 月)。「WebSocket URI」。RFC 6455 WebSocket プロトコル。IETF。sec . 3。doi : 10.17487 / RFC6455。RFC 6455 。
- ^ “HTML 5”. www.w3.org . 2016年9月16日時点のオリジナルよりアーカイブ。2016年4月17日閲覧。
- ^ 「[whatwg] TCPConnection feedback from Michael Carter on 2008-06-18 (whatwg.org from June 2008)」。lists.w3.org。2016年4月27日時点のオリジナルよりアーカイブ。2016年4月17日閲覧。
- ^ 「IRC ログ: freenode / #whatwg / 20080618」krijnhoetmer.nl。2016年 8 月 21 日時点のオリジナルよりアーカイブ。2016年 4 月 18 日閲覧。
- ^ 「Web Sockets Now Available In Google Chrome」。Chromiumブログ。2021 年 12 月 9 日時点のオリジナルよりアーカイブ。2016 年 4 月 17 日閲覧。
- ^ <ian@hixie.ch>、Ian Hickson (2010 年 5 月 6 日)。「WebSocket プロトコル」。Ietf Datatracker。2017年 3 月 17 日時点のオリジナルよりアーカイブ。2016年 4 月 17 日閲覧。
- ^ 「インターフェース定義」。WHATWG。2023年3月12日時点のオリジナルよりアーカイブ。2024年4月10日閲覧。
- ^ "new WebSocket(url, protocols)". WHATWG . 2023年3月12日時点のオリジナルよりアーカイブ。2024年4月30日閲覧。
- ^ "close(code, reason)". WHATWG . 2023年3月12日時点のオリジナルよりアーカイブ。2024年4月10日閲覧。
- ^ 「WebSocket メッセージが受信されたとき」。WHATWG。2023年 3 月 12 日時点のオリジナルよりアーカイブ。2024年 4 月 13 日閲覧。
- ^ ab 「WebSocket接続が閉じられたとき; サブステップ3」。WHATWG。2023年3月12日時点のオリジナルよりアーカイブ。2024年4月13日閲覧。
- ^ ab WebSocket接続が閉じられました。 sec. 7.1.4. doi : 10.17487/RFC6455 . RFC 6455.
- ^ WebSocket 接続クローズコード。7.1.5 節。doi : 10.17487 / RFC6455。RFC 6455 。
- ^ WebSocket 接続終了理由。7.1.6 節。doi : 10.17487 / RFC6455。RFC 6455 。
- ^ “CONNECTING”. WHATWG . 2023年3月12日時点のオリジナルよりアーカイブ。2024年4月13日閲覧。
- ^ クライアント要件。p. 14. sec. 4.1. doi : 10.17487/RFC6455 . RFC 6455。
- ^ "OPEN". WHATWG . 2023年3月12日時点のオリジナルよりアーカイブ。2024年4月10日閲覧。
- ^ _WebSocket 接続が確立されました_。p. 20。doi : 10.17487 / RFC6455。RFC 6455 。
- ^ “CLOSING”. WHATWG . 2023年3月12日時点のオリジナルよりアーカイブ。2024年4月10日閲覧。
- ^ WebSocket の終了ハンドシェイクが開始されました。7.1.3 節。doi : 10.17487/ RFC6455。RFC 6455 。
- ^ 「CLOSED」。WHATWG。2023年3月12日時点のオリジナルよりアーカイブ。2024年4月10日閲覧。
- ^ オープニングハンドシェイク。1.3節。doi : 10.17487 / RFC6455。RFC 6455 。
- ^ クライアント要件 8. p. 18. doi : 10.17487/RFC6455 . RFC 6455.
- ^ クライアント要件 9. p. 18. doi : 10.17487/RFC6455 . RFC 6455.
- ^ クライアント要件 7. p. 18. doi : 10.17487/RFC6455 . RFC 6455.
- ^ サーバーステップ 5.4. p. 24. doi : 10.17487/RFC6455 . RFC 6455.
- ^ クライアント要件 6. p. 18. doi : 10.17487/RFC6455 . RFC 6455.
- ^ サーバーステップ 5.3. p. 24. doi : 10.17487/RFC6455 . RFC 6455.
- ^ クライアント要件 5. p. 17. doi : 10.17487/RFC6455 . RFC 6455.
- ^ サーバーステップ 5.2. p. 24. doi : 10.17487/RFC6455 . RFC 6455.
- ^ クライアント要件 10. p. 18. doi : 10.17487/RFC6455 . RFC 6455.
- ^ プロトコルの概要。1.2節。doi : 10.17487 / RFC6455。RFC 6455 。
- ^ 「WebSocket プロトコルの主な目標」。IETF。2016 年 4 月 22 日時点のオリジナルからアーカイブ。2015 年7 月 25 日閲覧。
計算 [...] は、キャッシュ仲介者が WS サーバーと実際にやり取りすることなく、WS クライアントにキャッシュされた WS サーバーの応答を提供することを防ぐことを目的としています。
- ^ フラグメンテーション。5.4節。doi : 10.17487/ RFC6455。RFC 6455 。
- ^ John A. Tamplin、Takeshi Yoshino (2013)。WebSocket の多重化拡張。IETF。ID draft-ietf-hybi-websocket-multiplexing。
- ^ FIN. p. 28. doi : 10.17487/RFC6455 . RFC 6455.
- ^ RSV1、RSV2、RSV3。p. 28。doi ：10.17487 / RFC6455。RFC 6455 。
- ^ マスク。p. 29. doi : 10.17487/RFC6455 . RFC 6455。
- ^ ペイロード長。p. 29. doi : 10.17487/RFC6455 . RFC 6455.
- ^ 概要。5.1節。doi : 10.17487/ RFC6455。RFC 6455 。
- ^ クライアントからサーバーへのマスキング。5.3 節。doi : 10.17487/ RFC6455。RFC 6455 。
- ^ ハンドシェイクの終了。1.4 節。doi : 10.17487/ RFC6455。RFC 6455 。
- ^ 閉じる。 sec. 5.5.1. doi : 10.17487/RFC6455 . RFC 6455。
- ^ Ping. sec. 5.5.2. doi : 10.17487/RFC6455 . RFC 6455.
- ^ Pong. sec. 5.5.3. doi : 10.17487/RFC6455 . RFC 6455.
- ^ 予約済みのステータスコードの範囲。7.4.2 項。doi : 10.17487/ RFC6455。RFC 6455。
- ^ 定義されたステータスコード。7.4.1節。doi : 10.17487 / RFC6455。RFC 6455 。
- ^ Dirkjan Ochtman (2011 年 5 月 27 日). 「Firefox 6 で WebSocket が有効になりました」. Mozilla.org . 2012 年 5 月 26 日時点のオリジナルよりアーカイブ。2011年 6 月 30 日閲覧。
- ^ 「Chromium Web Platform Status」。2017年3月4日時点のオリジナルよりアーカイブ。2011年8月3日閲覧。
- ^ 「WebSockets (Windows)」。Microsoft。2012 年 9 月 28 日。2015 年 3 月 25 日時点のオリジナルよりアーカイブ。2012年 11 月 7 日閲覧。
- ^ 「WebSockets プロトコル テスト レポート」。Tavendo.de。2011 年 10 月 27 日。2016 年 9 月 22 日時点のオリジナルよりアーカイブ。2011年 12 月 10 日閲覧。
- ^ Katie Marsal (2010 年 11 月 23 日). 「Apple が iOS 4.2 で Safari に加速度計と WebSocket のサポートを追加」AppleInsider.com。2011年 3 月 1 日時点のオリジナルよりアーカイブ。2011年 5 月 9 日閲覧。
- ^ 「Web Sockets API」。BlackBerry 。 2011年6月10日時点のオリジナルよりアーカイブ。2011年7月8日閲覧。
- ^ Chris Heilmann (2010 年 12 月 8 日). 「WebSocket は Firefox 4 で無効になっています」. Hacks.Mozilla.org . 2017 年 3 月 6 日時点のオリジナルよりアーカイブ。2011年 5 月 9 日閲覧。
- ^ Aleksander Aas (2010 年 12 月 10 日). 「WebSocket について」. My Opera Blog . 2010 年 12 月 15 日時点のオリジナルよりアーカイブ。2011年 5 月 9 日閲覧。
- ^ Wang, Vanessa; Salim, Frank; Moskovits, Peter (2013 年 2 月)。「付録 A: Google Chrome 開発者ツールによる WebSocket フレーム検査」。HTML5 WebSocketの決定版ガイド。Apress。ISBN 978-1-4302-4740-1. 2015年12月31日時点のオリジナルよりアーカイブ。2013年4月7日閲覧。
- ^ 「WebSockets (Firefox でのサポート)」。developer.mozilla.org。Mozilla Foundation。2011 年 9 月 30 日。2012 年 5 月 26 日時点のオリジナルよりアーカイブ。2011年 12 月 10 日閲覧。
- ^ “Bug 640003 - WebSockets - ietf-06 へのアップグレード”. Mozilla Foundation. 2011-03-08. 2021-04-01 時点のオリジナルよりアーカイブ。 2011-12-10取得。
- ^ 「WebSockets - MDN」。developer.mozilla.org。Mozilla Foundation。2011-09-30。2012-05-26 時点のオリジナルよりアーカイブ。2011-12-10取得。
- ^ 「バグ 640003 - WebSocket - ietf-07 へのアップグレード (コメント 91)」。Mozilla Foundation。2011 年 7 月 22 日。2021 年 4 月 1 日時点のオリジナルよりアーカイブ。2011年 7 月 28 日閲覧。
- ^ 「Chromium バグ 64470」。code.google.com。2010年 11 月 25 日。2015 年 12 月 31 日時点のオリジナルよりアーカイブ。2011年 12 月 10 日閲覧。
- ^ 「Windows Consumer Preview の WebSocket」。IE エンジニアリング チーム。Microsoft。2012 年 3 月 19 日。2015 年 9 月 6 日時点のオリジナルよりアーカイブ。2012年 7 月 23 日閲覧。
- ^ 「WebKit Changeset 97247: WebSocket: WebSocket プロトコルを hybi-17 に更新」。trac.webkit.org。2012年1 月 5 日時点のオリジナルよりアーカイブ。2011年 12 月 10 日閲覧。
- ^ 「Opera 12.50 夏のホットなスナップショット」。Opera Developer News。2012 年 8 月 3 日。2012 年 8 月 5 日時点のオリジナルよりアーカイブ。2012年 8 月 3 日閲覧。
- ^ “Welcome to nginx!”. nginx.org . 2012年7月17日時点のオリジナルよりアーカイブ。2022年2月3日閲覧。
- ^ 「NGINX を WebSocket プロキシとして使用する」。NGINX。2014年 5 月 17 日。2019 年 10 月 6 日時点のオリジナルよりアーカイブ。2019 年11 月 3 日閲覧。
- ^ 「Apache HTTP Server 2.4 の新機能の概要」。Apache。2020年 11 月 11 日時点のオリジナルよりアーカイブ。2021 年 1 月 26日閲覧。
- ^ “Changelog Apache 2.4”. Apache Lounge . 2021年1月22日時点のオリジナルよりアーカイブ。 2021年1月26日閲覧。
- ^ 「IIS 8.0 WebSocket プロトコル サポート」。Microsoft Docs。2012年 11 月 28 日。2020 年 2 月 18 日時点のオリジナルよりアーカイブ。2020 年2 月 18日に取得。
- ^ “Release-1 4 46 - Lighttpd - lighty labs”. 2021年1月16日時点のオリジナルよりアーカイブ。2020年12月29日閲覧。
- ^ “Release-1 4 65 - Lighttpd - lighty labs”. 2024年5月3日時点のオリジナルよりアーカイブ。2024年5月3日閲覧。
- ^ Christian Schneider (2013 年 8 月 31 日)。「クロスサイト WebSocket ハイジャック (CSWSH)」。Web アプリケーション セキュリティ ブログ。2016 年 12 月 31 日時点のオリジナルよりアーカイブ。2015 年12 月 30 日閲覧。
- ^ Peter Lubbers (2010 年 3 月 16 日)。「HTML5 Web ソケットがプロキシ サーバーとやり取りする方法」。Infoq.com。C4Media Inc. 2016 年 5 月 8 日時点のオリジナルよりアーカイブ。2011年 12 月 10 日閲覧。
- ^ Willy Tarreau (2010-07-06). 「WebSocket -76 は HTTP リバース プロキシと互換性がありません」。ietf.org (メール). Internet Engineering Task Force。2016-09-17 にオリジナルからアーカイブ。2011-12-10に取得。
- ^ Ian Fette (2011 年 6 月 13 日)。「Sec-WebSocket-Key」。WebSocket プロトコル、ドラフト hybi-09、sec. 11.4。2011年6 月 15 日閲覧。2016年2月1日、Wayback Machineにアーカイブされました
外部リンク
- IETF ハイパーテキスト双方向 (HyBi) ワーキング グループ
- RFC 6455 WebSocket プロトコル – IETF HyBi ワーキング グループによって公開された提案標準
- WebSocket プロトコル – IETF HyBi ワーキング グループによって公開されたインターネット ドラフト
- WebSocket プロトコル – Ian Hickson によるオリジナルのプロトコル提案
- WebSocket API は 2015-06-07 にWayback Machineでアーカイブされています– W3Cの API のワーキング ドラフト仕様
- WebSocket API – W3Cの API の候補勧告仕様
- WebSocket.org 2018-09-16にWayback MachineでアーカイブされたWebSocketのデモ、ループバックテスト、一般情報、コミュニティ