「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
HTTPを用いて、双方向通信を実現するための技術規格。
- APIはHTML仕様の中に含まれている
HTML Standard 9.3 Web sockets
- 通信プロトコル標準仕様
- RFC 6455
- Fetch Standard 6. WebSocket protocol alterations
仕様 †
あまり詳しく読んでいないが、ざっくり、HTTP的に接続して、以降TCP/IP的に振舞う。
問題点 †
- あまり流行っていない体感もあるので調査をしてみた。
と言う事で、WebSocketが新規採用される可能性は低いということらしい。
現行の問題 †
- とびきり不安定なスペックでの波乱の経緯（RFC6455でようやく安定した）
- 多くのライブラリ（欠陥があるにも関わらず、複数の実装が付随するモノもある）
- 古いブラウザではサポートされない。
技術的な問題 †
信頼性が高くない。 †
- しかし、欠損やサーバで処理される順序の入れ替わりなどが
起こり得る単なるHTTP呼び出しであるかのように扱う必要がある。
ブラウザでTCP/IPコネクションが制限されない。 †
ブラウザのWebSocket（TCP/IPコネクション）が、
HTTP/HTTPSコネクションのように制限されない。
- HTTPプロキシサーバ経由の問題
HTTPSでないHTTPプロキシサーバ経由でWebSocketを実行すると、
WebSocketが閉じてしまったにも関わらず、オープンであるように見える問題に対処できない。
- TCPプロキシの問題
- TCPプロキシを起動することが余儀なくされるが、問題もある。
- HTTPプロキシによって緩和されるDoS攻撃は、TCPプロキシでは対処できない。
- TCPプロキシはヘッダを入れたり、URLを書き直したりできない。
また、従来、HTTPプロキシが処理する様々な役割も実行できない。
- 負荷分散の問題
- 既存のトラフィックを再度バランシングする方法が無い。
- オーバーロードしたサーバを終了する以外に無い。
サーバーに、I/O完了ポートなどが必要 †
- 両プロトコルを統一するための（有効期限切れの）ドラフトを後押しする活動はない。
エンドユーザの視点 †
必要な状況が殆ど無い。 †
- ミリ秒未満の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 を明示しないでレスポンスする方法。
- データを細かく分けて、分割された個々のデータをサイズとセットで送信する。
Frame †
- HTML の framesetやiframeタグを使って常時接続を実現する方法
- Forever Frame
ポーリングのトランスポートとして使用すると性能が上がる（Twitter）。
参考 †
参考 †
問題点 †
Wikipedia †
Tags: :通信技術, :IIS, :.NET開発, :.NET Core, :ASP.NET, :ASP.NET SignalR
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
