理论：通过Websockets服务静态内容是否可行/可行？

Question

在网络世界中，Web浏览器会对它必须检索的每个静态文件发出新请求，因此;样式表，javascript文件，内嵌图像 - 全部启动新的服务器请求。虽然我对网络的了解非常好，但像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连接，但主渲染脚本仍将通过这些连接进行序列化。你当然可以提高效率，但再一次，这不是一个小问题，浏览器已经解决了很多这些静态资源加载问题。
• 许多Web服务器在交付之前都支持gziping资源。 WebSocket还没有压缩支持（它被作为工作组中的扩展进行讨论）。这意味着如果您想通过WebSocket压缩资源，则必须在Javascript中执行此操作，这将增加更多延迟。

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

Answer 2

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

应该解决通过单个连接传输多个资产问题的下一代技术是SPDY，它目前是HTTP 2.0的候选者。它在Chrome和Firefox中都有工作实现，并且已经有谷歌和Twitter之类的一些实验性服务器端支持。