javascript - 理论 : Is It Possible/Feasible To Serve Static Content Via Websockets?

Question

在网络世界中，网络浏览器对它必须检索的每个静态文件发出新请求，因此；样式表、javascript 文件、内联图像——所有这些都会发起新的服务器请求。虽然我对 Web 的了解相当丰富，但像 websockets 这样的底层技术在工作方式和功能方面对我来说还是有些陌生。

我的问题是相当理论化的，但我想知道现在是否可能或将来是否可能通过 websocket 提供静态文件？考虑到 websockets 是从客户端(web 浏览器)到服务器的持久连接，websockets 可以用于提供一些(如果不是全部)静态内容是有道理的，因为它只是一个连接而不是许多。

澄清一点。

我意识到我关于连接的措辞不正确，如下面的 Greg 所指出的。但据我所知，创建 CDN 并在今天仍在使用的原因是为了解决浏览器和/或服务器对并发下载数量有硬性限制的问题，一旦您达到该限制，您的请求就会排队，从而增加页面加载时间。我知道它们也是为了提供无 cookie 请求而创建的。所以我的问题真的应该是:“可以使用 websockets 代替 CDN 吗？”

BrowserScope有一些有用的指标，对于大多数现代浏览器甚至 IE8 来说，请求限制似乎是每个主机名大约 6 个。但正如我所说，有时人们拥有超过 6 个资源，这是否意味着他们正在排队并减慢页面加载时间，而 websockets 可能会将其减少到一个？

Answer 1

这绝对是可能的，但是您可能不想将其用于静态资源有几个原因:

• 您至少需要一个通过标准 HTTP 机制静态交付的资源，这意味着无论如何您都需要能够提供静态资源的资源。通常，您希望将 Javascript 与 HTML 分开，这意味着另一个静态负载。或者你可以把 WebSocket 代码嵌入到主页上，但你仍然可以做得更好。
• 在页面上的脚本开始运行之前，您无法打开 WebSocket 连接。建立 WebSocket 连接会增加一些初始延迟。
• 大多数浏览器会并行加载不冲突的静态资源(一些较旧的浏览器对并行连接数有严格限制，但它们仍然具有一定的并行性)。您可以为不同的静态资源打开多个 WebSocket 连接，但可靠且高效地做到这一点需要付出很多努力。浏览器已经为静态资源解决了其中的大部分问题。
• 每个 WebSocket 连接都是有保证的基于消息顺序的传输。结合 Javascript 执行的序列化特性，这实际上意味着您可以一次处理一个 WebSocket 消息。您可以使用 Web Workers 来并行处理多个 WebSocket 连接，但主渲染脚本仍将跨这些连接序列化。您当然可以提高效率，但再次强调，这不是一个小问题，浏览器已经解决了很多此类静态资源加载问题。
• 许多网络服务器支持在交付资源之前对资源进行 gzip 压缩。 WebSocket 还没有压缩支持(它正在作为工作组的扩展进行讨论)。这意味着如果您想通过 WebSocket 压缩资源，则必须在 Javascript 中执行此操作，这会增加延迟。

如果您的页面有部分使用静态资源动态更新(例如，将新图像加载到 HTML5 canvas 游戏中)，那么 WebSockets 可能是您的最佳选择，因为已经建立的 WebSocket 连接具有低延迟和开销从服务器获取推送更新，然后通过 HTTP 传递这些更新。但我不建议在页面首次加载时将 WebSockets 用于初始静态资源。