javascript - 用于数据传输的 WebSockets 与 XHR

Question

我正在使用 Node.js 为 Web 应用程序设计架构，我们需要能够将中等大小的文件从图库发送到客户端。当用户浏览图库时，他们将尽快(针对每个图库项目)发送这些二进制文件。这些文件可能高达 6Mb，但可能平均约为 2Mb。

我的客户坚持认为我们应该使用 websockets 而不是 XHR 进行数据传输。需要明确的是，我们不需要双向通信。

我缺乏这方面的经验，需要推理方面的帮助。到目前为止，我的观点如下:

• 使用 WebSockets 会破坏 HTTP 提供的任何客户端缓存。如果用户两次访问图库中的同一项目，他们将被迫重新下载内容。
• WebSocket 消息不能由代理缓存处理/路由到代理缓存。它们必须始终由显式服务器处理。
• CDN 旨在提供广泛的网络缓存，拦截 HTTP 请求。 WebSockets 会限制我们利用 CDN。
• 我猜 Nodejs 能够比并发 websocket 连接更快地响应成百上千的 XHR。

是否有任何支持/反对使用 websockets 通过标准 HTTPRequests 进行纯数据传输的技术论据。任何人都可以否定/澄清我的观点并提供链接来帮助我的研究吗？

我发现此链接非常有用:https://www.mnot.net/cache_docs/#PROXY

Answer 1

除了 XHR 使用 HTTP 并因此在缓存方面更好(这对速度至关重要)之外，我还可以看到 XHR 的以下技术参数:

• HTTP 是文件下载的专用协议(protocol)。它原生内置于浏览器中(使用 XHR 接口(interface))，因此对开发人员而言优化得更好且更易于使用
• HTTP 已经具有许多您需要使用 websockets 手工制作的东西，例如文件路径请求、身份验证、 session 、缓存……所有这些都在客户端和服务器端。
• XHR 即使在旧版浏览器中也有更好的支持
• 一些防火墙只允许 HTTP(S) 连接

似乎没有任何技术原因更喜欢网络套接字 - 唯一可能影响您选择的是“客户端为王”。不过，您可以通过告诉他他必须支付多少钱才能在 websocket 连接上重新实现 HTTP 功能来说服他。它并不便宜，尤其是当您的应用程序变得更加复杂时。

顺便说一句，我不支持你的最后一点。 Node 应该能够处理与 HTTP 连接一样多的 websocket 连接；如果适当优化所有事情都是均匀的。但是，如果您的服务器架构不仅仅基于 Node ，则有大量纯文件服务应用程序可能比 Node 更快(甚至不包括 HTTP 缓存层)。