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

Question

在Web世界中,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作为初始静态资源.