当前位置：文江博客话题详情

AJAX 与 Web Sockets 的往返时间

发布于 2024-12-18 22:09:15 字数 166 浏览 2 评论 0原文

我想问一下，与标准 HTTP GET 相比，使用 Web 套接字（消息）实现时是否应该期望一些不同的往返时间（向服务器发送一些信息并接收响应）。我假设 Web 套接字已连接并且 DNS 已解析。

据我了解，如果 GET 由底层协议中的多个往返组成，情况会有所不同，对此我不确定。否则我会期待同样的结果。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

尾戒 2024-12-25 22:09:15

WebSocket 的往返时间似乎较短。我在本地和远程服务器上运行了一些测试，平均每次 100 个请求的行程时间：

Local:
WebSocket:   2.46ms
Ajax:        9.97ms

Remote:
WebSocket:  93.41ms
Ajax:      183.49ms

测试是在服务器上使用 Node.js 和 express 和 socket.io 完成的，在客户端上使用 Chrome 和 socket.io 的库完成的。远程测试通过 3G 连接进行。

更新：在家里，在延迟低得多的连接上，数字有点不同：

Websocket:  63.02ms
Ajax:       72.11ms

这表明延迟对 HTTP 请求的影响比对 WebSocket 连接的影响更大，这可能是因为 HTTP 必须使正如您提到的，需要进行更多往返才能为每个请求重新建立连接。

WebSockets seem to have a lower round trip time. I ran some tests locally and on a remote server, averaging the trip times for 100 requests at a time:

Local:
WebSocket:   2.46ms
Ajax:        9.97ms

Remote:
WebSocket:  93.41ms
Ajax:      183.49ms

The tests were done with Node.js with express and socket.io on the server, and Chrome with socket.io's library on the client. The remote tests were run over a 3G connection.

Update: At home on a much lower-latency connection, the numbers are a bit different:

Websocket:  63.02ms
Ajax:       72.11ms

This suggests that latency has a larger effect on HTTP requests than on WebSocket connections, which is likely because HTTP has to make a couple more round trips to reestablish a connection for each request, as you mentioned.

回复收藏 0 原文

萝莉病 2024-12-25 22:09:15

这取决于您考虑的初始场景。

示例1：
在一种情况下您已经建立了 HTTP 1.1 连接，在另一种情况下您已经建立了 WebSocket。在这种情况下，这两种情况的往返行程将完全相同，因为在这两种情况下，您都已经建立了 TCP 连接，并且不需要进一步的应用程序握手。（注意：两种情况发送的数据量会有所不同，但这会影响带宽，而不是延迟，即往返时间）。

示例2：
在一种情况下，您已经建立了 HTTP 1.1 连接（因为也许您刚刚下载了页面中的最后一张图像），而在另一种情况下，没有打开 WebSocket。那么，在这种情况下，通过 HTTP 的往返时间将低于通过 WebSocket 的往返时间。原因是，使用 HTTP，您只需要发送一个 TCP 段并接收一个 TCP 段（单次往返）。使用 WebSockets，您需要设置 TCP 连接并执行 WS 握手，这涉及几次往返。

回复收藏 0 原文

~没有更多了~