浏览器允许的并发请求资源数

一、    

    浏览器的并发请求数目限制是针对同一域名的。即，同一时间针对同一域名下的请求有一定数量限制。超过限制数目的请求会被阻塞。

    不同浏览器这个限制的数目不一样：

    

 

    下边技术的出现和大量使用都和并发资源数有关。

 

    1.Cookie-free domain 

    由于写在主域名下的cookie，如 xxx.com下的 cookie 比较大的情况下，若图片之类的 pic.xxx.com  图片去服务器取数据的时候，都需要发送本地的头，就会带上cookie，这样就会造成send数据过多，导致速度变慢像 js、style 等都会有这些问题。通常使用一个其他域名，这样这个域名下就没有cookie 了。

    按照普通设计，当网站cookie信息有1KB、网站首页共150个资源时，用户在请求过程中需要发送150KB的cookie信息，在512Kbps的常见带宽下，需要长达3秒左右才能全部发送完毕。 尽管这个过程可以和页面下载不同资源的时间并发，但毕竟对速度造成了影响。 而且这些信息在js/css/images/flash等静态资源上，几乎是没有任何必要的。 解决方案是启用和主站不同的域名来放置静态资源，也就是cookie free。

    将css放置在页面最上方应该是很自然的习惯，但第一个css内引入的图片下载是有可能堵塞后续的其他js的下载的。而在目前普遍过百的整页请求数的前提下，浏览器提供的仅仅数个并发，对于进行了良好优化甚至是前面有CDN的系统而言，是极大的性能瓶颈。 这也就衍生了domain hash技术来使用多个域名加大并发量（因为浏览器是基于domain的并发控制，而不是page），不过过多的散布会导致DNS解析上付出额外的代价，所以一般也是控制在2-4之间。

 

    2.css sprites

    再怎么提速，页面上过百的总资源数也仍然是很可观的，如果能将其中一些很多页面都用到的元素如常用元素如按钮、导航、Tab等的背景图，指示图标等等合并为一张大图，并利用css background的定位来使多个样式引用同一张图片，那也就可以大大的减少总请求数了，这就是css sprites的由来。

 

    3.js/css combine(合并)

    全站的js/css原本并不多，其合并技术的产生却是有着和图片不同的考虑。 由于css/js通常可能对dom布局甚至是内容造成影响，在浏览器解析上，不连贯的载入是会造成多次重新渲染的。因此，在网站需要保持模块化来提高可维护性的前提下，js/css combine也就自然衍生了，同时也是minify、compress等对内容进行多余空格、空行、注释的整理和压缩的技术出现的原因。

 

    4.Cache-Control max-age

    随着cookie free和domain hash的引入，网站整体的打开速度将会大大的上一个台阶。 这时我们通常看到的问题是大量的请求由于全站公有header/footer/nav等关系，其对应文件早已在本地缓存里存在了，但为了确保这个内容没有发生修改，浏览器还是需要请求一次服务器，拿到一个304 Not Modified(客户端有缓冲的文档并发出了一个条件性的请求,服务器告诉客户，原来缓冲的文档还可以继续使用。)才能放心。 一些比较大型的网站在建立了比较规范的发布制度后，会将大部分静态资源的有效期设置为最长，也就是Cache-Control max-age为10年。 这样设置后，浏览器就再也不会在有缓存的前提下去确认文件是否有修改了。 超长的有效期可以让用户在访问曾访问过的网站或网页时，获得最佳的体验。 带来的复杂性则体现在每次对静态资源进行更新时，必须发布为不同的URL来确保用户重新加载变动的资源。

 

    5.延迟加载

    很多页面浏览量很大，但其实用户直接很大比例直接就跳走了，第一屏以下的内容用户根本就不感兴趣。 对于超大流量的网站如淘宝、新浪等，这个问题尤其重要。 这个时候一般是通过将图片的src标签设置为一个loading或空白的样式，在用户翻页将图片放入可见区或即将放入可见区时再去载入。 不过这个优化其实和并发资源数的关系就比较小了，只是对一些散布不合理，或第一页底部的资源会有一定的帮助。 主要意图还是降低带宽费用。