我想问一下,与标准 HTTP GET 相比,当使用 Web 套接字(消息)实现时,我是否应该期望一些不同的往返时间(向服务器发送一些信息并接收响应)。我假设 Web 套接字已经连接并且 DNS 已解析。
据我了解,如果 GET 包含底层协议中的多个往返,那将是不同的,我不确定。否则我会期待同样的结果。
我想问一下,与标准 HTTP GET 相比,当使用 Web 套接字(消息)实现时,我是否应该期望一些不同的往返时间(向服务器发送一些信息并接收响应)。我假设 Web 套接字已经连接并且 DNS 已解析。
据我了解,如果 GET 包含底层协议中的多个往返,那将是不同的,我不确定。否则我会期待同样的结果。
WebSocket 的往返时间似乎较短。我在本地和远程服务器上运行了一些测试,一次平均 100 个请求的行程时间:
当地的: 网络套接字:2.46 毫秒 阿贾克斯:9.97 毫秒 偏僻的: 网络套接字:93.41 毫秒 阿贾克斯:183.49 毫秒
测试是在服务器上使用带有 express 和 socket.io 的 Node.js 以及在客户端使用带有 socket.io 库的 Chrome 完成的。远程测试通过 3G 连接运行。
更新:在家中使用低得多的延迟连接,数字有点不同:
网络套接字:63.02ms 阿贾克斯:72.11 毫秒
这表明延迟对 HTTP 请求的影响比对 WebSocket 连接的影响更大,这可能是因为 HTTP 必须进行多次往返才能为每个请求重新建立连接,正如您所提到的。
这取决于您正在考虑的初始场景。
示例 1:在一种情况下,您已经有一个 HTTP 1.1 连接,在另一种情况下已经建立了一个 WebSocket。在这种情况下,两种情况的往返行程将完全相同,因为在这两种情况下,您已经建立了 TCP 连接,并且不需要进一步的应用程序握手。(注意:两种情况发送的数据量会有所不同,但这会影响带宽,而不是延迟,即往返时间)。
示例 2:在一种情况下,您已经有一个 HTTP 1.1 连接(因为也许您刚刚下载了页面中的最后一张图像),而在另一种情况下没有打开 WebSocket。那么,在这种情况下,HTTP 的往返时间将低于 WebSocket 的往返时间。原因是使用 HTTP 您只需要发送一个 TCP 段并接收一个 TCP 段(单次往返)。使用 WebSockets,您需要建立 TCP 连接并执行 WS 握手,这涉及到几次往返。