標準の HTTP GET と比較して、Web ソケット (メッセージ) を使用して実装した場合、ラウンドトリップ時間 (サーバーに情報を送信して応答を受信する時間) が異なると予想されるかどうかを尋ねたいと思います。Web ソケットが既に接続されており、DNS が解決されていると仮定します。
私が理解している限り、基になるプロトコルで GET が複数のラウンドトリップで構成されている場合は異なりますが、これはよくわかりません。そうでなければ、同じ結果が期待できます。
標準の HTTP GET と比較して、Web ソケット (メッセージ) を使用して実装した場合、ラウンドトリップ時間 (サーバーに情報を送信して応答を受信する時間) が異なると予想されるかどうかを尋ねたいと思います。Web ソケットが既に接続されており、DNS が解決されていると仮定します。
私が理解している限り、基になるプロトコルで GET が複数のラウンドトリップで構成されている場合は異なりますが、これはよくわかりません。そうでなければ、同じ結果が期待できます。
WebSocket のラウンドトリップ時間が短いようです。ローカルとリモート サーバーでいくつかのテストを実行し、一度に 100 リクエストのトリップ時間を平均しました。
ローカル: ウェブソケット: 2.46ms アヤックス:9.97ms リモート: ウェブソケット: 93.41ms アヤックス: 183.49ms
テストは、サーバーで Express と socket.io を使用する Node.js と、クライアントで socket.io のライブラリを使用する Chrome で行われました。リモート テストは 3G 接続で実行されました。
更新: 遅延の少ない接続を使用している自宅では、数値が少し異なります。
ウェブソケット: 63.02ms アヤックス:72.11ms
これは、レイテンシーが WebSocket 接続よりも HTTP リクエストに大きな影響を与えることを示唆しています。
検討している最初のシナリオによって異なります。
例1:1つのケースではすでにHTTP 1.1接続が確立されており、もう1つのケースではWebSocketがすでに確立されています。このシナリオでは、両方の場合のラウンドトリップはまったく同じになります。どちらの場合も、TCP接続がすでに確立されており、それ以上のアプリケーションハンドシェイクは必要ないためです。(注:2つのケースで送信されるデータの量は異なりますが、これは遅延ではなく帯域幅、つまりラウンドトリップ時間に影響します)。
例2:あるケースではすでにHTTP 1.1接続が確立されており(おそらくページの最後の画像をダウンロードしたため)、他のケースではWebSocketが開かれていません。このシナリオでは、HTTPを介したラウンドトリップ時間は、WebSocketを介したラウンドトリップ時間よりも短くなります。その理由は、HTTPでは、TCPセグメントを送信してTCPセグメントを受信するだけでよいためです(単一のラウンドトリップ)。WebSocketを使用する場合は、TCP接続をセットアップし、WSハンドシェイクを実行する必要があります。これには数回のラウンドトリップが含まれます。