通过浏览器获取并发请求数 [英] Get number of concurrent requests by browser
问题描述
我想弄清楚将图像请求分散到多个子域是否值得.[这篇文章](链接已损坏)例如说:
<块引用>大多数浏览器一次只能发出两个请求，因此浏览器会请求两个文件，下载它们，然后转到下两个文件.页面需要正确显示的 HTTP 请求或单独组件越多，用户等待的时间就越长.
当他们说大多数时，特别是哪些浏览器?根据 这个问题?
这里有很多事情需要考虑.在大多数情况下，我只会选择一个无 cookie 域/子域来托管您的图像，例如 static.mywebsite.com.理想情况下，静态文件应该由 CDN 托管，但那是另一回事.
首先，IE7 只允许每个主机有两个并发连接.但是今天的大多数浏览器允许的不止这些.IE8 允许 6 个并发连接，Chrome 允许 6 个，Firefox 允许 8 个.
例如，如果您的网页只有 6 张图片，那么将您的图片分散到多个子域中真的毫无意义.
假设您在一个页面上有 24 张图片.好吧，生活中很少有事情是免费的，并且存在通过并行化而死亡这样的事情.如果您在 4 个不同的子域中托管您的图像，那么这意味着理论上每个图像都可以并行下载.但是，这也意味着涉及 3 个额外的 DNS 查找.DNS 查找可能需要 100 毫秒、150 毫秒，有时甚至更长.这种增加的延迟很容易抵消并行下载的任何好处.您可以通过使用 http://www.webpagetest.org/<测试站点来查看实际示例/p>
当然最好的解决方案是在可能的情况下使用 CSS sprites 来减少请求的数量.我在 这篇文章和这篇.
更新
Steve Souders 发表了一篇关于域分片主题的有趣文章...
<块引用>大多数美国排名前十的网站都进行域分片.YouTube 使用i1.ytimg.com、i2.ytimg.com、i3.ytimg.com 和 i4.ytimg.com.居住搜索使用 ts1.images.live.com、ts2.images.live.com、ts3.images.live.com 和 ts4.images.live.com.这两个网站都是跨四个域进行分片.最佳数量是多少?雅虎！发布了一项研究，建议至少跨两个分片，但没有四个以上，域名.超过四个，性能实际上会下降.
http://www.stevesouders.com/blog/2009/05/12/sharding-dominant-domains/
但是请注意，这是在 2009 年写的.2011 年他发表了评论......
<块引用>由于较新的浏览器为每个域打开了更多连接，因此可能是最好向下修改数字.我认为 2 是一个很好的妥协，但这只是一种预感.如果某些生产属性运行，那就太好了确定最佳数量的测试.
您还应该记住，雅虎和亚马逊等大型网站甚至需要进行域分片的重要原因是它们的网站是如此动态.图像附加到动态显示的产品或故事.因此，他们不可能像最佳状态那样积极地使用 CSS 精灵.
然而，像 StackOverflow 这样的网站对这些类型的图像很不友好，而且他们已经减少了请求的数量，以至于不需要进行分片.实现这一目标的一大步是他们使用了这个 sprites.png 图像...
http://cdn.sstatic.net/Sites/stackoverflow/img/sprites.png?v=5
更新 #2
Steve Souders 发布了关于域分片的另一项更新.他重复了我已经提到的大部分内容.但突出的是 SPDY 以及它会如何影响您的决定.
<块引用>也许反对域分片最有力的论据是在 SPDY(以及 HTTP 2.0)的世界中是不必要的.实际上，域分片可能会损害 SPDY 下的性能.SPDY 支持并发请求(提前发送所有请求头)以及请求优先级.跨多个域的分片减少这些好处.Chrome、Firefox、Opera 和 IE 支持 SPDY11. 如果您的流量由这些浏览器主导，您可能希望跳过域分片.
更新 #3(2018 年 2 月)
正如 Dean 在下面的评论中提到的那样，随着现代浏览器支持 HTTP/2，CSS 精灵现在并没有真正为您买单.但是您必须获得 SSL 证书，设置您的站点以使用 HTTPS，并确保您的 Web 服务器配置为 HTTP/2.要么，要么使用已经为您设置了所有这些的 CDN.完成所有这些后，您可能可以跳过 CSS 精灵和域分片.
I'm trying to figure out whether it would be worthwhile to spread image requests across multiple sub-domains. [This article](link broken) for example says:
Most browsers can only make two requests at a time, so the browser will request two files, download them and then move on to the next two. The more HTTP requests, or separate components a page requires to display properly, the longer the user will have to wait.
When they say most, which browsers in particular? Is that number related to the number of concurrent XMLHttpRequests, per this question?
There are a lot of things to consider here. In most situations, I would only choose one cookieless domain/subdomain to host your images such as static.mywebsite.com. And ideally static files should be hosted by a CDN, but that's another story.
First of all, IE7 allowed only two concurrent connections per host. But most browsers today allow more than that. IE8 allows 6 concurrent connections, Chrome allows 6, and Firefox allows 8.
So if your web page only has 6 images, for example, then it'd really be pointless to spread your images across multiple subdomains.
So let's say you have 24 images on a page. Well, few things in life are free and there's such a thing as death by parallelization. If you host your images in 4 different subdomains, then that means that every single image could theoretically be downloaded in parallel. However, it also means that there are 3 additional DNS lookups involved. And a DNS lookup could be 100 ms, 150 ms, or sometimes longer. This added delay could easily offset any benefit of parallel downloads. You can see real-world examples of this by testing sites with http://www.webpagetest.org/
Of course the best solution is to use CSS sprites when possible to cut down on the number of requests. I talk about that and the inherent overhead of every request in this article and this one.
UPDATE
There's an interesting article from Steve Souders on the subject of sharding domains...
Most of the U.S. top ten web sites do domain sharding. YouTube uses i1.ytimg.com, i2.ytimg.com, i3.ytimg.com, and i4.ytimg.com. Live Search uses ts1.images.live.com, ts2.images.live.com, ts3.images.live.com, and ts4.images.live.com. Both of these sites are sharding across four domains. What’s the optimal number? Yahoo! released a study that recommends sharding across at least two, but no more than four, domains. Above four, performance actually degrades.
http://www.stevesouders.com/blog/2009/05/12/sharding-dominant-domains/
Note however that this was written in 2009. And in 2011 he posted a comment...
Since newer browsers open more connections per domain, it’s probably better to revise the number downwards. I think 2 is a good compromize, but that’s just a hunch. It’d be great if some production property ran a test to determine the optimal number.
You should also keep in mind that the big reason it's even necessary for the big sites like Yahoo and Amazon to do domain sharding is that their sites are so dynamic. The images are attached to products or stories which are displayed dynamically. So it's not feasible for them to use CSS sprites as aggressively as would be optimal.
A site like StackOverflow, however, is light on these sorts of images and they have cut down on the number of requests so much that they don't need to do sharding. A big step towards making that happen is their usage of this sprites.png image...
http://cdn.sstatic.net/Sites/stackoverflow/img/sprites.png?v=5
UPDATE #2
Steve Souders posted another update on domain sharding. He repeats much of what I've already mentioned. But the thing that stood out was SPDY and how that should affect your decision.
Perhaps the strongest argument against domain sharding is that it’s unnecessary in the world of SPDY (as well as HTTP 2.0). In fact, domain sharding probably hurts performance under SPDY. SPDY supports concurrent requests (send all the request headers early) as well as request prioritization. Sharding across multiple domains diminishes these benefits. SPDY is supported by Chrome, Firefox, Opera, and IE 11. If your traffic is dominated by those browsers, you might want to skip domain sharding.
UPDATE #3 (February 2018)
As Dean mentioned in the comments below, CSS sprites aren't really buying you very much now with HTTP/2 being supported in modern browsers. But you do have to get an SSL certificate, set up your site to work with HTTPS, and ensure your web server is configured for HTTP/2. Either that, or use a CDN that already has all of that set up for you. Once you've done all of that then you can probably skip both CSS sprites and domain sharding.
这篇关于通过浏览器获取并发请求数的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
