この記事では、どちらも信頼できるデータ配信方法であるサーバー送信イベント (SSE) と WebSocket を比較します。通信方向、基盤となるプロトコル、セキュリティ、使いやすさ、パフォーマンス、メッセージ構造、使いやすさ、テストツールを含む 8 つの側面で分析します。これらの側面の比較は次のように要約されます。 カテゴリ サーバー送信イベント (SSE) WebSocket の通信方向 単方向 双方向 基礎となるプロトコル HTTP WebSocket プロトコルのセキュリティ HTTP と同じ 既存のセキュリティの脆弱性 使いやすさ セットアップが簡単 セットアップが複雑 パフォーマンスが速い メッセージ送信速度が高い メッセージ処理の影響を受けるおよび接続管理 メッセージ構造 プレーン テキスト テキストまたはバイナリ 使いやすさ 広く利用できる需要のある WebSocket 統合 Postman を使用したテスト ツールと、JMeter、Gadling、sse-perf、Testable または k6
を使用したコレクション
##今日の記事では、Server Sent Events (略して SSE) と WebSocket について詳しく見ていきたいと思います。どちらも実績のある優れたデータ交換方法です。
SSE と WebSockets のイメージ
まず、これら 2 つのツールの概要、つまりそれらが何を提供するのかについて簡単に説明します。次に、これらを 8 つのカテゴリーに基づいて比較します。これらが現代のシステムにとって最も重要であると私は考えています。
#カテゴリは次のとおりです:
- 通信方向
- #基礎となるプロトコル
#セキュリティ -
#シンプル
-
パフォーマンス
##メッセージ構造
- #導入が簡単
- ツール
- REST と gRPC を比較した以前の比較とは異なり、ポイントが何であるとも宣言しません。勝者に授与されます。代わりに、概要の段落に TL;DR テーブルのようなものがあります。この表には、上記の領域における 2 つのテクノロジーの主な違いが含まれています。
理由
REST とは異なり、SSE と WebSocket はどちらもユースケースに重点を置いています。この特定のケースでは、両方の概念の主な焦点は、「リアルタイム」通信メディアを提供することです。特定の焦点に焦点を当てているため、より汎用的で万能のツールである REST ほど人気はありません。
それにもかかわらず、SSE と WebSocket は両方ともさまざまな興味深い可能性を提供しており、問題を解決するための古典的な REST アプローチよりもわずかに新しいものです。
私の意見では、それらについて知り、ツールボックスにそれらのためのスペースを見つけることは良いことです。いつか、特に必要なときに、非常に複雑な質問に対するより簡単な解決策を提供するためにそれらが役立つかもしれないからです。 「リアルタイム」更新、またはアプリケーションがよりプッシュ指向のアプローチを必要とする場合。
ここで比較して説明するだけでなく、さらに普及させたいですか? WebSocket とは何ですか?
つまり、WebSocket は単一の永続的な TCP 接続を使用する通信プロトコルであり、この機能により、サーバーとクライアントの間で双方向通信が行われます。サーバーから常に新しいデータを取得する必要があるため、各メッセージは関係者間で「リアルタイム」に交換されます。
このプロトコルは、2011 年に IETF によって RFC 6455 として標準化されました。プロトコルは HTTP とは異なりますが、どちらも OSI モデルの第 7 層にあり、第 4 層に依存します。TCP。
プロトコルには、HTTP プレフィックス「http」と同様に機能する独自のプレフィックス セットがあります。 "https":
ws - 接続が使用されていないことを示します。保護された TLS
wss - 接続が TLS によって保護されていることを示します。 TLS
SSE は、WebSocket と同様に、単一の長期有効期間を利用して、Web サーバーが Web ページに更新を送信できるようにするテクノロジーです。 「リアルタイム」でデータを送信するための HTTP 接続
概念的なレベルでは、これは非常に古いテクノロジーであり、その理論的背景は 2004 年に遡ります。SSE の最初の実装は 2006 年に実装されました
最新のブラウザーのほとんどは SSE をサポートしています - Microsoft Edge は 2020 年 1 月に SSE サポートを追加しました。また、HTTP/2 を最大限に活用し、HTTP/1.1 によって事実上解消された SSE の最大の問題の 1 つを解消します。
定義上、サーバー送信イベントには 2 つの基本的な構成要素があります。
EventSource - WHATWG 仕様に基づいており、ブラウザーによって実装され、クライアントに許可するインターフェースです。この場合はブラウザ) がイベントをサブスクライブします。
イベント ストリーミング - サーバーから送信されたイベントの標準のプレーン テキスト形式を記述するプロトコル。EventSource クライアントがイベントを理解して伝播するために従う必要があります。
仕様によれば、イベントは任意のテキスト データ、オプションの ID を運ぶことができ、改行で区切られます。 text/event-stream という独自の MIME タイプもあります。
残念ながら、サーバー送信イベントはテクノロジーとしてテキストベースのメッセージのみをサポートするように設計されていますが、カスタム形式のイベントを使用して送信することはできます。ただし、最終メッセージは UTF-8 でエンコードされた文字列である必要があります。
さらに重要なのは、SSE が 2 つの非常に興味深い機能を提供していることです。
比較
コミュニケーションの方向性
両者の最大の違いはコミュニケーションスタイルかもしれません。
どちらのアプローチにも長所と短所があり、それぞれに専用の使用例があると思います。
一方で、継続的に更新されるストリームをクライアントにプッシュするだけであれば、SSE がより適切な選択肢になります。一方、これらのイベントのいずれかに何らかの方法で反応する必要がある場合は、WebSocket の方が有利である可能性があります。
理論上 (および実際上)、SSE で実行できることはすべて WebSocket でも実行できますが、サポート、ソリューションの簡素化、セキュリティなどの領域に入りつつあります。
これらすべての領域とその他の領域については、以下の段落で説明します。さらに、WebSocket を使用することは、どのような場合でも大幅な過剰行為になる可能性がありますが、SSE ベースのソリューションは実装が簡単である可能性があります。
基礎となるプロトコル
これは、2 つのテクノロジ間のもう 1 つの大きな違いです。
SSE に関する限り、HTTP/2 を利用することで、SSE の主な問題の 1 つである並列接続の最大制限が解決されます。 HTTP/1.1 では、仕様に従って並列接続の数が制限されています。
この動作により、行頭ブロックと呼ばれる問題が発生する可能性があります。 HTTP/2 は多重化を導入することでこの問題を解決し、アプリケーション層での HOL ブロッキングを解決します。ただし、行頭ブロッキングは TCP レベルで発生する可能性があります。
WebSocket プロトコルについては、上記の行で詳しく説明しました。ここでは最も重要な点だけを繰り返します。このプロトコルは従来の HTTP とは若干異なりますが、HTTP Upgrade ヘッダーは WebSocket 接続を初期化し、通信プロトコルを効果的に変更するために使用されます。
それにもかかわらず、ベースとして TCP プロトコルも使用しており、HTTP と完全な互換性があります。 WebSocket プロトコルの最大の欠点は、そのセキュリティです。
簡単
一般に、SSE ベースの統合のセットアップは、WebSocket 統合よりも簡単です。この背後にある最も重要な理由は、特定のテクノロジーで利用される通信の性質です。
SSE とそのプッシュ モデルの一方向アプローチにより、概念的なレベルで簡単になります。これを自動再接続およびすぐに使用できるストリーム継続性サポートと組み合わせると、対処する必要が大幅に減ります。
これらすべての機能を備えた SSE は、クライアントとサーバー間の結合を軽減する方法としても考えられます。クライアントは、イベントを生成したエンドポイントのみを知る必要があります。
ただし、この場合、クライアントはメッセージを受信することしかできないため、何らかの情報をサーバーに送り返したい場合は、別の通信媒体が必要となり、事態が非常に複雑になる可能性があります。
WebSocket に関する限り、状況は少し複雑です。まず、HTTP プロトコルから WebSockets プロトコルへの接続のアップグレードを処理する必要があります。これは最も簡単なことですが、覚えておく必要があるもう 1 つのことです。
2 番目の問題は、WebSocket の双方向の性質に起因します。特定の接続の状態を管理し、メッセージの処理中に発生する可能性のあるすべての例外を処理する必要があります。たとえば、メッセージの 1 つを処理するときにサーバー側で例外がスローされた場合はどうなるでしょうか。
次のステップは、WebSocket の再接続を自分で処理する必要があります。
両方のテクノロジーに影響するもう 1 つの問題、それは長時間実行される接続です。
どちらのテクノロジーでも、イベントの連続ストリームを送信するには、長期間オープンな接続を維持する必要があります。
このような接続の管理は、特に大規模な場合、リソースがすぐに不足してしまうため、困難になる可能性があります。さらに、タイムアウトの延長などの特別な構成が必要な場合があり、ネットワーク接続の問題の影響を受けやすくなります。 ＃＃＃＃＃＃＃＃＃安全性＃＃＃＃＃＃
SSE に関する限り、セキュリティに関して特別なことは何もありません。これは、SSE がトランスポート メディアとして単純な古い HTTP プロトコルを使用するためです。標準 HTTP の長所と短所はすべて SSE に当てはまり、非常にシンプルです。
一方、セキュリティは、WebSocket プロトコル全体の最大の欠点の 1 つです。まず、「同一生成元ポリシー」などというものは存在しないため、WebSocket 経由で接続する場所に制限はありません。
この脆弱性を悪用するように設計された特定の種類の攻撃、つまりクロスオリジン WebSocket ハイジャックさえ存在します。同一生成元ポリシーと WebSocket のトピックをさらに詳しく知りたい場合は、こちらの記事が興味深いかもしれません。それ以外には、WebSocket にはプロトコル固有のセキュリティ ホールはありません。
どちらの場合も、すべての標準とセキュリティのベストプラクティスが適用されるため、ソリューションを実装するときは注意してください。
パフォーマンス
パフォーマンスの点では、どちらのテクノロジーも同等であると言えます。どちらのテクノロジーにも本質的に理論上のパフォーマンス限界はありません。
ただし、1 秒あたりに送信されるメッセージの数という点では、ファイア アンド フォーゲット原則に従っているため、SSE の方が高速であると言えます。 WebSocket はクライアントからの応答を処理する必要もあります。
両方のパフォーマンスに影響を与える可能性があるのは、アプリケーションとその実装で使用する基盤となるクライアントだけです。それをチェックし、ドキュメントを読み、カスタム ストレス テストを実行すると、使用しているツールやシステム全体について非常に興味深いことが分かるかもしれません。
メッセージ構造
メッセージ構造は、おそらくプロトコル間の最も重要な違いの 1 つです。
上で述べたように、SSE はプレーン テキスト プロトコルです。さまざまな形式やコンテンツのメッセージを送信できますが、最終的にはすべて UTF-8 でエンコードされたテキストになります。複雑なフォーマットやバイナリデータの可能性はありません。
一方、WebSocket はテキスト メッセージとバイナリ メッセージの両方を処理できます。画像、音声、または通常のファイルを送信できるようにします。ファイルの処理には重大なオーバーヘッドが発生する可能性があることに注意してください。
導入の容易さ
ここで、2 つのテクノロジーは非常に似た段階にあります。 SSE の観点から見ると、WebSocket とサーバー送信イベントのサポート (クライアントとサーバー) を追加するツールが多数あります。
最も確立されたプログラミング言語には、そのようなライブラリが複数あります。あまり詳しく説明する必要はありません。表を用意し、基本ライブラリをまとめ、WebSocket と SSE のサポートを追加しました。
Java:
Spring SSE/WebSockets
Quarkus SSE/WebSockets
Scala:
Like SSE/WebSockets
Play/WebSockets
JavaScript
イベント ソース
Total.js SSE/WebSockts
Socket.io
Python
Little Star
Fast API
ご覧のとおり、SSE または WebSocket の統合をアプリケーションに追加したい場合、多くの成熟したオプションがあります。もちろん、これはすべてのライブラリのごく一部にすぎません。他にも多数のライブラリがあります。本当の問題は、特定の使用例に最適なものを見つけることかもしれません。
ツール
自動テスト
私の知る限り、SSE または WebSocket 用の自動テスト ツールはありません。ただし、Postman とコレクションを使用すると、同様の機能を比較的簡単に実現できます。
Postman は、サーバー送信イベントと WebSocket をサポートします。 Postman コレクションから派生したマジックを使用すると、エンドポイントの正確性を検証するための一連のテストを準備できます。
パフォーマンス テスト
パフォーマンス テストには、JMeter または Gadling を使用できます。私の知る限り、これら 2 つは最も成熟した全体的なパフォーマンス テスト ツールです。もちろん、これらはすべて SSE (JMeter、Gadling) と WebSocket (JMeter、Gadling) もサポートしています。
sse-perf (SSE のみ)、Testable、k6 (WebSocket のみ) などの他のツールもあります。
これらのツールの中で、個人的には Gattle または k6 をお勧めします。どちらも最高のユーザー エクスペリエンスを備えており、運用環境に最適であると思われます。
ドキュメント
SSE または WebSocket をドキュメント化するための専用ツールはありません。一方、このように両方の概念に使用できる AsyncAPI と呼ばれるツールがあります。
残念ながら、OpenAPI は SSE または WebSocket をサポートしていないようです。
要約
約束どおり、要約は手早く簡単にできます。以下を参照してください。
WebSocket と SSE の比較表
上記の表は、このトピックと記事全体をうまく簡潔にまとめたものだと思います。
最も重要な違いは通信方向であり、これによって特定のテクノロジの考えられる使用例が決まります。おそらく、そのうちの1つを選択することが最も大きな影響を与えるでしょう。
メッセージ構造も、特定の通信方法を選択する際に非常に重要なカテゴリとなる可能性があります。プレーン テキスト メッセージのみを許可することは、サーバー送信イベントの非常に重要な欠点です。
以上がSSE と WebSocketの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
