HTTP / 2仕様を読み終えた後、HTTP / 2はほとんどのユースケースで廃止されたWebソケットを実行すると思いますが、すべてではないかもしれません。
PUSH_PROMISE（通称サーバープッシュ）はここでは問題になりません。これは単なるパフォーマンスの最適化です。
ブラウザでのWebSocketの主な使用例は、データの双方向ストリーミングを有効にすることです。したがって、OPの問題は、HTTP / 2がブラウザーで双方向ストリーミングを有効にするより良い仕事をするかどうかになると思います。そうだと思います。
まず第一に、それはある双方向ジ。ストリームセクションの紹介を読んでください：
「ストリーム」は、HTTP / 2接続内でクライアントとサーバー間で交換される独立した双方向のフレームシーケンスです。ストリームにはいくつかの重要な特性があります。
単一のHTTP / 2接続には、複数のストリームからのいずれかのエンドポイントインターリーブフレームを使用して、同時に開いている複数のストリームを含めることができます。
ストリームは、一方的に確立して使用するか、クライアントまたはサーバーで共有できます。
ストリームはどちらのエンドポイントでも閉じることができます。
このような記事（別の回答でリンクされています）は、HTTP / 2のこの側面について間違っています。彼らはそれが双方向ではないと言います。HTTP / 2では起こりえないことが1つあります。接続が開かれた後、サーバーは通常のストリームを開始できず、プッシュストリームのみを開始できます。しかし、クライアントがリクエストを送信してストリームを開くと、両側がいつでも永続的なソケットを介してDATAフレームを送信できます-完全な双方向。
これはWebSocketと大差ありません。サーバーもデータを送信する前に、クライアントはWebSocketアップグレードリクエストを開始する必要があります。
最大の違いは、WebSocketとは異なり、HTTP / 2は独自の多重化セマンティクスを定義することです。つまり、ストリームが識別子を取得する方法と、フレームがストリームのIDを伝達する方法です。HTTP / 2は、ストリームに優先順位を付けるためのフロー制御セマンティクスも定義します。これは、bidiのほとんどの実際のアプリケーションで重要です。
（この間違った記事には、Websocket標準に多重化があるとあります。いいえ、ありません。それを見つけるのはそれほど難しくありません。WebsocketRFC 6455を開き、open -Fを押して、「multiplex」と入力してください。
プロトコルは拡張可能であることを目的としています。将来のバージョンでは、多重化などの追加の概念が導入される可能性があります。
Websocketの多重化のための2013年のドラフト拡張があることがわかります。しかし、どのブラウザがそれをサポートしているかはわかりません。私はその拡張機能の裏側でSPA Webアプリケーションを構築しようとはしません。特にHTTP / 2が来ると、サポートが届かない可能性があります）。
多重化とは、たとえば、反応的に更新する単一ページのアプリを強化するために、bidiのWebSocketを開くたびに通常は自分で行う必要があることです。それがHTTP / 2仕様にあることをうれしく思います。
HTTP / 2でできることを知りたい場合は、gRPCをご覧ください。gRPCはHTTP / 2全体に実装されています。特に、gRPCが提供する半二重および全二重ストリーミングオプションに注目してください。（gRPCは現在ブラウザーでは機能しませんが、実際にはブラウザーが（1）HTTP / 2フレームをクライアントのJavaScriptに公開しておらず、（2）で使用されるTrailersを一般的にサポートしていないためですgRPC仕様。）
WebSocketにはまだ場所があるのでしょうか？大きなものは、サーバーからブラウザにプッシュされたバイナリデータです。HTTP / 2では、サーバーからブラウザーにプッシュされたバイナリデータは許可されますが、ブラウザーのJSでは公開されません。オーディオフレームやビデオフレームのプッシュなどのアプリケーションでは、これがWebSocketを使用する理由です。
編集：2020年1月17日
時間の経過とともに、この回答は徐々に上位に上がっています（この回答は多かれ少なかれ正しいため、これは良いことです）。ただし、通常はPUSH_PROMISEメッセージ指向のサーバー->クライアントプッシュをシングルページアプリで実際に使用する方法についての混乱や方法に関連するさまざまな理由で正しくないというコメントが時折あります。また、サーバープッシュバイナリデータであるブラウザーのWebSocketのユースケースがあります。JSONを含むテキストデータの場合は、WebSocketを使用せず、SSEを使用してください。
要約すると、HTTP / 2プロトコルは完全な双方向です。ただし、最新のウェブブラウザはフレーム指向のHTTP / 2プロトコルをJavaScriptに公開していません。とはいえ、HTTP / 2接続を介して同じオリジンに複数のリクエストを行うと、内部ではすべてのトラフィックが1つの接続で多重化されます（これが重要です！）。
したがって、リアルタイムチャットアプリを構築する必要がある場合、たとえば、オープンコネクションを持つチャットルーム内のすべてのクライアントに新しいチャットメッセージをブロードキャストする必要がある場合、Webソケットなしでこれを行うことができます（おそらくそうする必要があります）。
サーバー送信イベントを使用してメッセージをプッシュダウンし、フェッチ APIを使用してリクエストを送信します。サーバー送信イベント（SSE）はあまり知られていないがよくサポートされている APIであり、メッセージ指向のサーバーからクライアントへのストリームを公開します。クライアントのJavaScriptのようには見えませんが、内部的には、ブラウザー（HTTP / 2をサポートしている場合）は単一のTCP接続を再利用して、これらのメッセージをすべて多重化します。効率の低下はなく、実際にはWebSocketよりも優れています。複数のストリームが必要ですか？複数のイベントソースを開きます！これらは自動的に多重化されます。
サーバーソケットイベントは、Webソケットハンドシェイクよりもリソース効率が高く、初期遅延が少ないだけでなく、自動的にフォールバックしてHTTP / 1.1で動作するという優れた特性を備えています。しかし、HTTP / 2接続がある場合、それらは信じられないほどうまく機能します。
これは、反応的に更新するSPAを実現する実際の例を含む良い記事です。