websocketを使用する場合は、双方向通信専用の接続が必要です。 http/2を使用する場合は、サーバーによって維持される2番目の接続があります。HTTP/2を使用しているときにwebsocketよりもSSE + RESTを優先すべきですか？
この場合、websocketを使用すると、SSEと通常のHTTP要求で、単一のHTTP/2接続で双方向通信の利点が得られるため、不必要なオーバーヘッドが発生するようです。
あなたはどう思いますか？
2つのストリームを1つの多重化HTTP/2 TCP接続（サーバー間通信用に1つのストリーム - Server Sent Events（SSE）、クライアント - サーバー間通信と通常のHTTP通信用に1つのストリーム）接続（通常のHTTP通信用とWebSocket用）は比較が容易ではありません。
おそらく、走行距離はアプリケーションによって異なるでしょう。
オーバーヘッド？まあ、確かに接続の数が倍増します。 しかしWebSocketはメッセージを圧縮できますが、SSEではメッセージを圧縮できません。
柔軟性？接続が分離されている場合は、異なる暗号化を使用できます。 HTTP/2では、通常、非常に強力な暗号化が必要となり、パフォーマンスが制限される可能性があります。 一方、WebSocketはTLSを必要としません。
クリアテキストのWebSocketはモバイルネットワークで動作しますか？私の経験では、それは依存しています。アンチウィルス、アプリケーションファイアウォール、モバイル事業者は、操作する国によってWebSocketのトラフィックを制限したり、信頼性を低くすることがあります。
APIの可用性はありますか？ WebSocketは広く普及しており、認知されている標準です。たとえばJavaでは公式のAPI（javax.websocket）があり、別のAPIが登場しています（java.net.websocket）。
私はSSEは双方向ウェブ通信の技術的に劣った解決策であり、技術としてはそれほど普及していない（WebSocketと比較して標準的なAPIも書籍もない）と思う。 Jettyでone of the firstからimplement itにもかかわらず、HTML5から削除された場合、私は驚かないでしょう。
あなたが興味を持っていることに応じて、ベンチマークを行うか、特定のケースの技術を評価する必要があります。
Web開発者の観点からは、WebソケットとRESTインターフェイスの違いはセマンティクスです。 RESTは、サーバーからのすべてのメッセージがクライアントからのメッセージへの応答である要求/応答モデルを使用します。一方、WebSocketsは、サーバーとクライアントの両方が、以前の要求と関係なく、いつでもメッセージをプッシュできるようにします。
どのテクニックを使用するかは、アプリケーションのコンテキストでより意味があるかどうかによって異なります。確かに、ある技術の動作をもう一方の技術とシミュレートするためにいくつかのトリックを使用することができますが、通常は、本書で使用されたときに通信モデルに適したものを使用することが好ましいです。
サーバーによって送信されるイベントは、すべての主要なブラウザではまだサポートされていない、まったく新しいテクノロジなので、重大なWebアプリケーションではまだオプションではありません。
これらのトリックは、パフォーマンス目的のために作成されたすべての歴史的手法と同様にCOMETフレームワークにすることができます。私の質問は、パフォーマンスに関連していて、それらの技術についての私の理解を確実にすることでした。私は開発者がゼロから実装するのは難しいことに同意しますが、それは私の質問の目的ではありませんでした。関連する場合、この手法はフレームワークによって隠されるべきです。ありがとう。 –
実装するアプリケーションの種類によって大きく異なります。サーバーとクライアント間の双方向通信が本当に必要な場合はWebSocketが適していますが、すべての通信プロトコルを実装する必要があり、すべてのITインフラストラクチャで十分にサポートされていない可能性があります（一部のファイアウォール、プロキシまたはロードバランサはWebSocketをサポートしない場合があります） 。したがって、100％の双方向リンクが必要ない場合は、クライアントからサーバーへの追加情報のためにREST要求を持つSSEを使用することをお勧めします。 しかし、SSEには、Javascriptの実装のような特定の警告が付いています。ヘッダーを上書きすることはできません。唯一の解決策はクエリパラメータを渡すことですが、クエリ文字列サイズの制限で問題に直面する可能性があります。 SSEとWebSocketの選択は、実際に実装する必要があるアプリケーションの種類によって異なります。 数ヶ月前、私はあなたにいくつかの情報を与えるかもしれないブログ投稿を書いていた：http://streamdata.io/blog/push-sse-vs-websockets/。当時はHTTP2は考慮されていませんでしたが、これはあなたに何を質問する必要があるかを知るのに役立ちます。
SSEは、HTTP/2サーバープッシュ機能とうまく組み合わせる主要な通知メカニズムとして、HTTP/2でより一般的になると思います。重要なリソースが変更されると、サーバーは変更をプッシュしてSSEイベントを送信し、クライアントがキャッシュから変更を取得できるようにします。 通知を使用するには、ペイロードサイズが圧縮を必要とするほど大きくならないようにします。 –