web-dev-qa-db-ja.com

低遅延のクライアントからサーバーへのメッセージ用のHTTP / 2またはWebsocket

Webアプリケーションでクライアントからサーバーへのメッセージの待ち時間を非常に短くする必要があります。

この要件にはHTTPの代わりにWebSocketを使用する方が望ましいと言っているstackoverflowに関する投稿をいくつか見ましたが、かなり前のことです。

今日、2018年、HTTP/2の進歩に伴い、このユースケースにWebSocketを使用する価値はありますか？

websockethttp2
9
rico

HTTP/2には 多重化 があります。これは、ドメインごとに6つの接続制限があるため、HTTP/1の場合と同様に待機時間がないことを意味します。つまり、これは、あなたが言うように、低遅延接続に使用できることを意味します。

ただし、HTTPヘッダーなど、HTTPには他にもオーバーヘッドがあり、Webソケットでは発生しない小さなリクエストに不要な余分なデータを追加する可能性があります。

さらに、HTTP/2は全二重プロトコルではないため、要求にのみ応答できます（ただし、サーバープッシュのおかげで複数の応答がある可能性があります）。これはクライアントサーバーメッセージングにのみ必要であるとあなたは言っているので、これはあなたにとってそれほど心配ではないかもしれません。

HTTP/2を支えるバイナリフレーミングレイヤーは完全に二重化されたプロトコルであるため、理論的にはWebSocketに似ている可能性がありますが、HTTP/2ではこれを許可していません-リクエストとレスポンスの送信をドラッグしてこれを偽造しない限り（ 長いポーリング または サーバー送信イベント ）。実際、 Websockets over HTTP/2 が承認されており、WebSocketメッセージをHTTP/2データフレームでラップすることにより、HTTP/2バイナリ形式をWebSocketに使用できるようになります。これには、同じ接続で通常のHTTPメッセージも許可するという追加の利点があります。執筆時点では、どのブラウザでもまだ利用できません（ただし、 FireFoxのバージョン65 および Chromeは実装を開始しました ）。それまでは、WebsocketはHTTP /1.1に戻ります。

この質問と回答も参照してください： HTTP/2はWebSocketを廃止しますか？

4
Barry Pollard

それはあなたのクライアントとあなたの要件に依存します。クライアントがHTTP/2の基盤となるTLS接続を閉じないことが確実な場合（しばらく使用されていない場合でも）、メッセージ/要求を送信するための待ち時間は、永続化されたWebSocket接続と同様である可能性があります。アイドル時間の後にクライアントが接続を閉じ、新しいTLS接続を確立する必要がある場合は、さらに悪化します。

クライアントとしてのブラウザの場合、Webソケット接続が永続的になることはわかっており、HTTP接続については何も知りません。同じサーバー上のSSEエンドポイントにダミーのリクエストを送信して接続を維持することで、ブラウザーに接続を維持させることができるかもしれませんが、これは少し回避策です。

接続の確立とは別に、両方のプロトコルに異なる種類のオーバーヘッド（フロー制御とストリームヘッダーとマスキング）があり、影響は実際のアプリケーションのニーズに基づいてのみ推定できる可能性があります。

1
Matthias247

webアプリケーションのクライアントからサーバーへのメッセージの待ち時間が非常に短い。

これを「接続」して、低遅延メッセージをクライアントとサーバーの間で送信したいと読みました。

HTTP/2とWebsocketはどちらもバイナリにすることができ、メッセージが転送されるフレームには同様のオーバーヘッド（数バイト）がありますが、Websocketはメッセージ全体を繰り返し処理してmaskペイロード、次に受信者はこれを逆にする必要があります。 WebSocketフレームのマスクは何ですか？ を参照してください。

さらに、Websocketプリミティブはより低レベルです。複数のメッセージストリームを作成するには、自分でそれを行う必要がありますが、HTTP/2を使用すると簡単に実行できます。参照 HTTP/2に関するポッドキャスト 。また、同じアプリケーションでWebsocketとHTTPの両方を使用すると、サーバーコードがより複雑になります。

フロー制御はHTTP/1.1 Websocketを使用する場合に問題になる可能性がありますが、HTTP/2に組み込まれているプロトコル機能です。

サーバーからクライアントへ

これは、fetchとresponse.body.getReader();を使用して ReadableStream を取得することにより、HTTP/2で効率的に実行できます。ブラウザJavaScriptのストリームに関する良い記事： 2016-Webストリームの年 。

クライアントからサーバーへ

現在、HTTPでクライアントからサーバーにメッセージを送信する唯一の方法は、完全なリクエストを送信することです。ストリーミングリクエストの本文は計画されていますが、ブラウザではまだ実装されていません。ストリーミングされたリクエストボディについては、 リクエストボディとしてReadableStreamを使用してフェッチ を参照してください。

1
Jonas