websocket接続を介してパケットを送信するための追加オーバーヘッドはありますか？

Question

AJAXリクエストを実行するときは、データを送信するためにhttp接続をオープンする必要があるため、各リクエストにオーバーヘッドが発生するため、できるだけ少なくしようとしました。 websocket接続は常に開いているので、要求を送信するための明白なパケット帯域幅の外のコストはありますか？

たとえば、 1分の間、クライアントは100kbのデータをサーバーに送信します。クライアントがこれらの要求のいずれかに対する応答を必要としないと仮定すると、パケットを待ち行列に入れ、それを1つの大きなバーストで送信することと準備ができている間に送信することの利点はありますか？

つまり、常時開いている接続のデータ転送を停止して開始するためのオーバーヘッドはありますか？

できるだけリアルタイムでマルチプレイヤーブラウザゲームを作りたいと思っていますが、大規模な統合要求がサーバに余分なストレスを与えているのに対して、1分あたり100個の小さなリクエストは見つけたくありません。私は、クライアントが応答を必要とする場合は、前後に多くの待ち時間があるため、応答が遅くなることを理解しています。私はこれを考慮し、適切なときにのみ統合する。 1分あたりのリクエスト数が増えるにつれて、ユーザーエクスペリエンスは向上しますが、サーバー上でどんな料金がかかるかわかりません。

Answer 1

webSocket接続がすでに確立されているため、webSocketメッセージがHTTP要求よりもオーバーヘッドが少ないため、同じメッセージをAjaxコール経由で送信するよりも、特定のメッセージ送信でオーバーヘッドが小さくなることが間違いありません。

最初に、1つの大きな送信を送信する場合には、より小さい送信をたくさん送信するよりもオーバーヘッドが少なくなります。これはTCPの性質です。すべてのTCPパケットは別々に処理され、確認されます。そのため、より多くの送信にはもう少しオーバーヘッドがかかります。その違いが重要であるかどうか、そして（バッチ処理の遅延のために）ユーザーエクスペリエンスの要素を犠牲にする価値のあるコードを書く価値があるかどうかは、特定の状況の詳細に完全に依存します。

遅延がなく、パケットの一括処理がない場合にクライアントが最良の状態になる状況を説明したので、バッチ処理を実装しておらず、サーバーの処理方法をテストしないと思われます。かなり混雑している場合は、小さなパケットをたくさんロードしてください。それがうまくいく場合は、より良いユーザーエクスペリエンスを維持してください。負荷に追いつくのに問題がある場合は、サーバーを真剣にプロファイリングし、パフォーマンスの主なボトルネックがどこにあるのかを調べます（ボトルネックが実際にどこにあるのかということに驚くでしょう。なぜスケーラビリティを向上させるためにエネルギーを集中させるべきかを知るためにプロファイルし測定する必要があります）。

FYIのほとんどの実装では、Nagel's algorithmが実装されているため、TCPスタック自体は、複数の要求を時間的にかなり密接に送信している場合や、低速リンク経由で送信している場合に少量のバッチングを行います。

サーバが追いつくことができる限り、応答の遅いパケットを保持しながらサーバをビジー状態にすると、バッチ処理を開始してサーバの負荷を軽減する動的システムを実装することもできます別々の送信の数。