Ajaxv。Webソケットの往復時間

Question

標準のHTTP GETと比較して、Webソケット（メッセージ）で実装された場合、異なる往復時間（サーバーに情報を送信して応答を受信する）を期待する必要があるかどうかを尋ねたいと思います。 Webソケットはすでに接続されており、DNSが解決されていると思います。

私が理解している限り、Getが基礎となるプロトコルの複数の往復で構成されていれば、それは違いますが、それはわかりません。そうでなければ、同じ結果が期待されます。

Answer 1

これは、あなたが検討している最初のシナリオに依存します。

例1：あるケースでは既にHTTP 1.1接続が整っており、他のケースですでに確立されているWebSocketが既にあります。このシナリオでは、どちらの場合も往復がまったく同じになります。どちらの場合も、TCP接続がすでに確立されており、アプリケーションハンドシェイクは必要ありません。 （注：2つのケースに送信されるデータの量は異なりますが、これは遅延ではなく帯域幅、つまり往復時間に影響します）。

例2：あるケースではhttp 1.1接続が既にあります（おそらくページの最後の画像をダウンロードしただけではありません）、他のケースではWebsocketが開かれていません。このシナリオでは、HTTP上の往復時間は、WebSocket上の往復時間よりも低くなります。その理由は、HTTPを使用すると、TCPセグメントを送信してTCPセグメント（シングルラウンドトリップ）を受信するだけであるためです。 WebSocketsを使用すると、TCP接続をセットアップし、WSハンドシェイクを実行する必要があります。これには、数回の往復が含まれます。

Answer 2

WebSocketsは、往復時間が短いようです。私はローカルでいくつかのテストを実行し、リモートサーバーでいくつかのテストを実行し、一度に100のリクエストでトリップ時間を平均しました。

Local:
WebSocket:   2.46ms
Ajax:        9.97ms

Remote:
WebSocket:  93.41ms
Ajax:      183.49ms

テストは、サーバー上のExpressおよびsocket.ioを備えたnode.js、およびクライアントにsocket.ioのライブラリを備えたChromeを使用して行われました。リモートテストは3G接続で実行されました。

アップデート: ：自宅ではるかに低い遅延接続で、数字は少し異なります。

Websocket:  63.02ms
Ajax:       72.11ms

これは、LatencyがWebSocket接続よりもHTTP要求に大きな影響を与えることを示唆しています。これは、HTTPが各リクエストの接続を再確立するためにさらに数回往復しなければならない可能性が高いためです。