最小化 HTTP 连接与并行下载 [英] Minimizing HTTP Connections vs. Parallel Downloads

问题描述

多年来，Web 开发人员一直遵循这样一种逻辑，即最大限度地减少 HTTP 连接可以加快应用程序的速度，因为浏览器不会因代码的下载/执行而窒息.例如，雅虎长期以来一直吹捧他们的最佳实践，并告诉我们将 CSS/JavaScript/图像资源组合成单个文件- 从而减少了 HTTP 请求的总数并压缩了总资源大小.

For years, web developers have followed the logic that minimizing HTTP connections speeds up applications because the browser isn't choking on the download/execution of code. For example Yahoo has long touted their best practices, and tell us to combine CSS/JavaScript/image resources into single files - thereby reducing the total number of HTTP requests and compressing the total resource size.

但在提高网页速度方面存在其他最佳实践" - 具体而言，最大限度地提高 并行 HTTP 下载(来自 Google).这种方法告诉我们，通过将 HTTP 连接分布在多个主机名上，浏览器可以同时执行更多操作.

But other "best practices" exist with regards to increasing webpage speed - specifically, maximizing the number of parallel HTTP downloads (from Google). This approach tells us that by spreading the HTTP connections across multiple hostnames the browser can do more simultaneously.

因此，随着现代 Web 应用程序变得非常庞大(例如，仅 JavaScript 就有 3MB 以上)，必须提出以下问题:

So as modern web applications are becoming very large (e.g. 3MB+ of JavaScript alone) the question must be asked:

在单个文件中使用 3MB 以上的 JavaScript 会使我的应用程序加载速度更快吗?或者，如果多个较小的文件分布在主机名上，加载速度会更快吗?

为了简单起见，我们还应该假设正在遵循其他最佳实践"，因此这个问题最好存在于真空中.

For the sake of simplicity we should also assume other "best practices" are being followed, so this question best exists in a vacuum.

我还没有看到有关该主题的任何经验数据，但我想这些方法的性能肯定存在差异 - 因此知道该最佳点存在于何处是理想的.

I have yet to see any empirical data on the subject, but I imagine there has to be a point where the performance of these approaches diverge - so knowing where that sweet-spot exists would be ideal.

推荐答案

我认为这取决于浏览器可用的套接字数量.假设浏览器有 4 个可用的套接字，4 个较小的请求将比 1 个较大的请求快.

I think this depends on number of sockets available for the browser. Say the browser has it's 4 sockets available, 4 smaller requests will be faster than 1 large request.

这里的技巧是在启动时知道您的应用程序将发送什么请求，并最大化浏览器可以使用的套接字数量的请求数量.我相信浏览器只有 4 个，但说实话，我从来没有看过这个数字在现代浏览器中是否发生了变化.

The trick here would be knowing at startup what requests your application will send and maximize the # of requests for # of sockets a browser can use. I believe browsers only have 4 but to be honest I haven't ever looked to see if that number has changed in modern browsers.

看起来每个浏览器都有自己的套接字数量，有些有 2 个:浏览器中的最大并行 http 连接数?

Looks like each browser can have it's own number of sockets, some having 2: Max parallel http connections in a browser?

https://stackoverflow.com/a/985704/925782 说 IE10 是 8 个套接字的赢家，哇，去浏览器:)

https://stackoverflow.com/a/985704/925782 says IE10 is winner with 8 sockets, wow, go IE :)

当然，缓存控制也会在其中发挥作用，其中首次加载将是一切，后续加载将是较少的实际请求.

Cache control would also play part in this of course where first load would be everything, subsequent loads would be less actual requests.

如果你想搞怪:http://www.stevesouders.com/blog/2008/03/20/roundup-on-parallel-connections/

我同意一些图表和真实数据会是一篇很棒的博文，我的回答纯属理论性质.

I agree that some charts and real data would be a great blog post, my response is purely theoretical in nature.

这篇关于最小化 HTTP 连接与并行下载的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！