Skip to content

MS_WebSocket

Jump to bottom
nishi_74322014 edited this page Aug 3, 2026 · 1 revision

WebSocket

概要

HTTPを用いて、双方向通信を実現するための技術規格。

  • APIはHTML仕様の中に含まれている（HTML Standard 9.3 Web sockets）
  • 通信プロトコル標準仕様
    • RFC 6455
    • Fetch Standard 6. WebSocket protocol alterations

仕様

ざっくり、HTTP的に接続して（Upgrade ハンドシェイク）、以降TCP/IP的に振舞う。

問題点

  • あまり流行っていない体感もあるので調査をしてみた。

  • 例えば、大規模なインターネットサイトの多くがWebSocketを採用していない。

  • 調査結果をサマリすると、

    と言う事で、WebSocketが新規採用される可能性は低いということらしい。

補足（最新化）: この見立ては 2020 年頃の記述。 その後の状況を補足すると、

  • RFC 8441 により HTTP/2 上の WebSocket（Extended CONNECT）が標準化され、 RFC 9220 で HTTP/3 にも拡張された。「統合されていない」問題は解消方向にある。
  • 一方で、サーバ→クライアントの一方向配信は Server-Sent Events、 双方向の低遅延用途は WebTransport（HTTP/3 ベース）という選択肢も増えた。
  • 実際には Slack / Discord / 取引所の板情報など、 双方向・低遅延が要る領域では WebSocket は現役で広く使われている。

したがって「新規採用される可能性は低い」は、 用途を限定しない一般論としては現在は当たらない。原文の主張は当時の観測として残す。

現行の問題

  • とびきり不安定なスペックでの波乱の経緯（RFC 6455でようやく安定した）
  • 多くのライブラリ（欠陥があるにも関わらず、複数の実装が付随するモノもある）
  • 古いブラウザではサポートされない。

技術的な問題

信頼性が高くない

  • WebSocketは、信頼性（TCP/IP）という錯覚を与えた。
  • しかし、欠損やサーバで処理される順序の入れ替わりなどが
    起こり得る単なるHTTP呼び出しであるかのように扱う必要がある。

ブラウザでTCP/IPコネクションが制限されない

ブラウザのWebSocket（TCP/IPコネクション）が、HTTP/HTTPSコネクションのように制限されない。

プロキシや負荷分散の問題

  • HTTPプロキシサーバ経由の問題
    HTTPSでないHTTPプロキシサーバ経由でWebSocketを実行すると、
    WebSocketが閉じてしまったにも関わらず、オープンであるように見える問題に対処できない。
  • TCPプロキシの問題
    • TCPプロキシを起動することが余儀なくされるが、問題もある。
    • HTTPプロキシによって緩和されるDoS攻撃は、TCPプロキシでは対処できない。
    • TCPプロキシはヘッダを入れたり、URLを書き直したりできない。
      また、従来、HTTPプロキシが処理する様々な役割も実行できない。
  • 負荷分散（NLB: MS_NLB.md）の問題
    • 既存のトラフィックを再度バランシングする方法が無い。
    • オーバーロードしたサーバを終了する以外に無い。

サーバーに、I/O完了ポートなどが必要

多数の常時接続を保持するため、スレッド当たり1接続のモデルでは破綻する。

HTTP/2と統合されていない

  • HTTP/2のサーバプッシュで、
    ポーリングまたはロングポーリングのコストを削減することができる。
  • WebSocketの実装を洗練していくと、結局HTTPの再発明になる。
  • 両プロトコルを統一するための（有効期限切れの）ドラフトを後押しする活動はない。
  • HTTP/3が統合するかもしれない。

移行メモ（最新化）: 上記のうち「統一するためのドラフトを後押しする活動はない」は 既に古い。RFC 8441（2018年）/ RFC 9220（2022年） として標準化済み。 なお HTTP/2 のサーバプッシュ自体は主要ブラウザが無効化・削除しており、 現在の代替は 103 Early Hints。

エンドユーザの視点

必要な状況が殆ど無い

  • ミリ秒未満のHTTPヘッダのパースの最適化が必要な状況が殆ど無い。
  • 例えば、ポーリングを使って、30秒の遅れにも問題を感じずに満足する。

メッセージングの信頼性の方が重要

  • （上限はあるものの）古いメッセージを"取り戻す"ことが必要。
  • 信頼性のあるメッセージングが実装できれば、複数のトランスポート機構を簡単に実装できる。

代替

各種の双方向通信がある。

ポーリング

  • 通常のポーリング — ポーリングによる疑似プッシュ方式
  • Ajax polling
    • ボディがJSON化されたもの。
    • ポーリングと同じ疑似プッシュ方式

Comet

  • 複数の手法をまとめた概念
  • Ajax と Long-polling を使用
    • Ajax — JSON化されたボディ。
    • Long-polling — プッシュ時まで、レスポンスを返さない。

Server Sent Events

  • Chunked Transfer Codingを使用して、分割（chunked）データ扱いで、継続的にレスポンス可能。
  • Chunked Transfer Codingとは、
    • 大容量のファイルなど、Content-Length を明示しないでレスポンスする方法。
    • データを細かく分けて、分割された個々のデータをサイズとセットで送信する。

※ SSE はブラウザ側に EventSource API があり、切断時の自動再接続と
Last-Event-ID による再開が仕様に含まれている点が、素のロングポーリングとの違い。

Frame

  • HTML の frameset や iframe タグを使って常時接続を実現する方法
  • Forever Frame

HTTP/2

HTTP/2 をポーリングのトランスポートとして使用すると性能が上がる（Twitter）。

参考

参考

Tags: 通信技術, IIS, .NET開発, .NET Core, ASP.NET, ASP.NET SignalR

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally