在web世界中，web浏览器对它必须检索的每个静态文件都会发出新的请求，因此；样式表、javascript文件、内联图像-所有这些都会启动一个新的服务器请求。虽然我对网络的了解很好，但像websocket这样的底层技术对我来说是新的，它们的工作方式和功能都是新的。
我的问题相当理论化，但我想知道现在是否有可能或将来是否有可能通过websocket提供静态文件？考虑到websocket是从客户端（web浏览器）到服务器的持久连接，因此websocket可以用于服务一些（如果不是全部的话）静态内容是有道理的，因为它只是一个连接，而不是多个连接。
稍微澄清一下
我意识到我关于关系的措辞是不正确的，正如Greg在下面指出的那样。但据我所知，创建CDN并至今仍在使用的原因是为了解决浏览器和/或服务器对并发下载次数有严格限制的问题，一旦达到该限制，您的请求就会排队，从而增加页面加载时间。我知道它们也是为了提供无cookie请求而创建的。所以我的问题应该是："websocket可以代替CDN吗？"
BrowserScope有一些有用的指标，对于大多数现代浏览器甚至IE8来说，请求限制似乎是每个主机名6个。但正如我所说，有时人们有超过6个资源，这是否意味着他们正在排队，并减缓页面加载时间，而websocket可能会将其减少到一个？
这肯定是可能的，但有几个原因可能不想将其用于静态资源：
- 您至少需要一个通过标准HTTP机制静态传递的资源，这意味着您需要能够以任何方式为静态资源提供服务的资源。通常，您希望将Javascript与HTML分离，这意味着另一个静态加载。或者，你可以把WebSocket代码嵌入到主页上，但你仍然过得更好
- 在页面上的脚本开始运行之前，您无法打开WebSocket连接。建立WebSocket连接会增加一些初始延迟
- 大多数浏览器都会并行加载不冲突的静态资源（一些较旧的浏览器对并行连接的数量有严格的限制，但它们仍然有一些并行性）。您可以为不同的静态资源打开多个WebSocket连接，但要可靠高效地做到这一点需要付出大量的努力。浏览器已经解决了静态资源的大部分问题
- 每个WebSocket连接都是一个有保证的基于订单消息的传输。结合Javascript执行的序列化特性，这有效地意味着您可以一次处理一条WebSocket消息。您可以使用Web Worker来并行处理多个WebSocket连接，但主呈现脚本仍将在这些连接之间序列化。你当然可以让它变得高效，但这不是一个微不足道的问题，浏览器已经解决了很多静态资源加载问题
- 许多web服务器支持在交付资源之前对资源进行gzip封装。WebSocket还没有压缩支持（工作组正在将其作为扩展进行讨论）。这意味着，如果你想通过WebSocket压缩资源，你必须在Javascript中这样做，这会增加更多的延迟
如果您的页面中有使用静态资源动态更新的部分（例如，将新图像加载到HTML5画布游戏中），那么WebSocket可能是您的最佳选择，因为已经建立的WebSocket连接将具有较低的延迟和开销，用于从服务器获取推送更新，然后通过HTTP传递这些更新。但我不建议在首次加载页面时使用WebSockets作为初始静态资源。
这个答案并不能真正解决您的网络套接字问题，但它可能会使其过时：
本应解决在单个连接上传输多个资产问题的下一代技术是SPDY，是是HTTP2.0的候选技术它在Chrome和Firefox中有可用的实现，并且已经得到了谷歌和推特等公司的一些实验性服务器端支持
编辑：SPDY协议现已弃用 但是，您可以出于研究目的查看它。