我的问题是理论上的,但我想知道现在是否可能通过websocket提供静态文件？考虑到websockets是从客户端(Web浏览器)到服务器的持久连接,因此可以使用websockets来提供一些(如果不是全部)静态内容,因为它只是一个连接而不是许多连接.
澄清一点点.
我意识到我的关于连接的措辞不正确,正如Greg在下面指出的那样.但据我所知,CDN创建并且至今仍在使用的原因是解决浏览器和/或服务器对并发下载数量有严格限制的问题,一旦达到该限制,您的请求就会排队,从而增加了页面加载时间.我知道它们也是为了提供无cookie请求而创建的.所以我的问题应该是：“可以使用websockets代替CDN吗？”
BrowserScope有一些有用的指标,对于大多数现代浏览器甚至IE8而言,似乎请求限制大约为每个主机名6个.但正如我所说,有时人们有超过6个资源,这是否意味着他们正在排队并减慢页面加载时间,其中websockets可能会将此减少到一个？
解决方法
>您需要至少一个通过标准HTTP机制静态传递的资源,这意味着您无论如何都需要能够提供静态资源的东西.通常,您希望将Javascript与HTML分开,这意味着另一个静态负载.或者你可能很乱,并将WebSocket代码嵌入主页,但你还是真的还好.
>在页面上的脚本开始运行之前,您无法打开WebSocket连接.建立WebSocket连接会增加一些初始延迟.
>大多数浏览器将并行加载非冲突的静态资源(一些旧的浏览器对并行连接的数量有严格的限制,但它们仍然有一些并行化).您可以为不同的静态资源打开多个WebSocket连接,但是可靠而有效地执行此操作将需要花费很多精力.浏览器已经解决了静态资源的大部分问题.
>每个WebSocket连接都是基于保证订单消息的传输.结合Javascript执行的序列化特性,这实际上意味着您可以一次处理一个WebSocket消息.您可以使用Web Workers能够并行处理多个WebSocket连接,但主渲染脚本仍将通过这些连接进行序列化.你当然可以提高效率,但再一次,这不是一个小问题,浏览器已经解决了很多这些静态资源加载问题.
>许多Web服务器在交付之前都支持gziping资源. WebSocket还没有压缩支持(它被作为工作组中的扩展进行讨论).这意味着如果您想通过WebSocket压缩资源,则必须在Javascript中执行此操作,这将增加更多延迟.
如果您的页面部分使用静态资源动态更新(例如,将新图像加载到HTML5画布游戏中),那么WebSockets可能是您的最佳选择,因为已建立的WebSocket连接将具有低延迟和开销以获得推送更新从服务器然后通过HTTP传递这些.但是,当您首次加载页面时,我不建议使用WebSockets作为初始静态资源.
