理解浏览器的并发请求

最近看了月光的《为什么要少用 iframe ?》,很受启发,上面不但说了 iframe 的创建比其它包括 scripts 和 css 的 DOM 元素的创建慢了 1-2 个数量级,还说到了 iframe 阻塞页面加载,占用浏览器并发连接数的问题,因为 window 的 onload 事件需要在所有 iframe 加载完毕后(包含里面的元素)才会触发。当 onload 事件加载延迟后,它给用户的感觉就是这个网页非常慢。WebKit 内核浏览器通过 JavaScript 动态设置 iframe 的 src 可以避免这种阻塞情况。

虽说 iframe 用的越来越少了,但这个浏览器链接数的确是个值得注意的地方,随即在网上找了很多资料看,顺便整理出来,和大家共享。首先先来扫个盲,怎么理解浏览器并发链接数呢?

  1. 浏览器发出请求。
  2. DNS进行解析。
  3. 服务器返回请求内容。
  4. 浏览器按顺序分析获取的内容,并且依次获取页面的外链css、外链js、img等,一个下载完再下载下一个。

假设下载一个非常大的图片,那一个链接数肯定会让网页加载的非常慢,因为加载是队列式的,后面的内容被图片给“堵”住了。为此,现代浏览器都支持并发请求,比较老的浏览器,包含 IE6 & 7 和 Firefox 2,只能对一个域名同时打开两个连接。而最新的浏览器,对一个域名同时并发请求数达到了4到8个,这样浏览器就可以同时下载js,css,img了,一般情况下,堵塞的现象就很少了。

浏览器 HTTP 1.1 HTTP 1.0
IE 6,7 2 4
IE 8,9 6 6
Firefox 13 6 6
Chrome 20 6
Safari 5.1.7 6
Opera 11.64 8

上表数据来自SteveSouders.com

W3C 的HTTP/1.1协议中提到,如果是相同域名下的请求,就会有限制,只能保持一定数量。现在就能很好的解释网站图片服务器的域名为什么有这么多了。但多域名指向一个图片服务器速度是快了,但一定就是最好的吗?《Yahoo!关于网站优化的经典建议》中提到“要减少请求数”和“减少 DNS 解析次数”,而这就和我们网站的做法相违背了。所以,这就需要我们开发人员在提高并发连接数和减少 DNS 解析之间找到个完美的平衡点了:)

最后附上两个测试并发请求的工具:
http://developer.oncecode.com/comet/测试你的浏览器并发数
http://site-perf.com/模拟一个浏览器测试并发数

在 “理解浏览器的并发请求” 上有 4 条评论

  1. 撸主,这篇文章总结写的不好,误人子弟。
    应该这么写,这些并发都是双数,意味着我们合并图片的时候也要是双数

发表评论