理论：通过 Websocket 提供静态内容是否可能/可行？

Question

在网络世界中，网络浏览器对它必须检索的每个静态文件都发出新请求，因此；样式表、javascript 文件、内联图像 - 都启动新的服务器请求。虽然我对 Web 的了解相当不错，但像 websockets 这样的底层技术在它们的工作方式和能力方面对我来说有些新意。

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

澄清一点。

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

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

Answer 1

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

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

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

Answer 2

这个答案并没有真正解决您的网络套接字问题，但它可能会使其过时：

应该解决通过单个连接传输多个资产的问题的下一代技术是SPDY，是 是 HTTP 2.0 的候选者。 它已经在 Chrome 和 Firefox 中运行，并且已经得到 Google 和 Twitter 等公司的一些实验性服务器端支持。

编辑：SPDY 协议现已弃用。不过，您可以出于研究目的对其进行研究。