HTTP/2中的复用是什么意思 [英] What does multiplexing mean in HTTP/2

问题描述

有人可以解释与HTTP/2相关的复用及其工作原理吗?

Could someone please explain multiplexing in relation to HTTP/2 and how it works?

推荐答案

简单地说，多路复用允许您的浏览器一次触发同一连接上的多个请求，并以任意顺序接收请求.

Put simply, multiplexing allows your Browser to fire off multiple requests at once on the same connection and receive the requests back in any order.

现在，对于更复杂的答案...

And now for the much more complicated answer...

当您加载网页时，它会下载HTML页面，并发现它需要一些CSS，一些JavaScript，一些图像...等.

When you load a web page, it downloads the HTML page, it sees it needs some CSS, some JavaScript, a load of images... etc.

在HTTP/1.1下，您一次只能在HTTP/1.1连接上下载其中之一.因此，您的浏览器会下载HTML，然后要求提供CSS文件.返回时，它会要求提供JavaScript文件.当返回时，它会请求第一个图像文件...等等.HTTP/1.1基本上是同步的-发送请求后，您就被卡住了，直到获得响应为止.这意味着浏览器大多数时候并没有做太多事情，因为它已经触发了一个请求，正在等待响应，然后触发另一个请求，然后正在等待响应……等等.当然，复杂的站点具有许多JavaScript确实需要浏览器进行大量处理，但这取决于所下载的JavaScript，因此至少在开始时，继承到HTTP/1.1的延迟确实会引起问题.通常，服务器也没有做太多事情(至少每个请求都做不到-当然，它们会为繁忙的站点加起来)，因为它几乎可以立即响应静态资源(如CSS，JavaScript，图像，字体等).甚至对于动态请求(需要数据库调用等)也希望不会太长.

Under HTTP/1.1 you can only download one of those at a time on your HTTP/1.1 connection. So your browser downloads the HTML, then it asks for the CSS file. When that's returned it asks for the JavaScript file. When that's returned it asks for the first image file... etc. HTTP/1.1 is basically synchronous - once you send a request you're stuck until you get a response. This means most of the time the browser is not doing very much, as it has fired off a request, is waiting for a response, then fires off another request, then is waiting for a response... etc. Of course complex sites with lots of JavaScript do require the Browser to do lots of processing, but that depends on the JavaScript being downloaded so, at least for the beginning, the delays inherit to HTTP/1.1 do cause problems. Typically the server isn't doing very much either (at least per request - of course they add up for busy sites), because it should respond almost instantly for static resources (like CSS, JavaScript, images, fonts... etc.) and hopefully not too much longer even for dynamic requests (that require a database call or the like).

因此，当今网络上的主要问题之一是在浏览器和服务器之间发送请求的网络延迟.可能只有几十毫秒或几百毫秒，这似乎并不多，但是它们加起来通常是Web浏览中最慢的部分-尤其是当网站变得越来越复杂并且需要额外的资源(随着访问)和Internet访问时越来越多地通过移动设备(延迟比宽带慢).

So one of the main issues on the web today is the network latency in sending the requests between browser and server. It may only be tens or perhaps hundreds of millisecond, which might not seem much, but they add up and are often the slowest part of web browsing - especially as websites get more complex and require extra resources (as they are getting) and Internet access is increasingly via mobile (with slower latency than broadband).

作为示例，假设在HTML自身加载后，您的网页需要加载10种资源(按当今的标准，这是一个很小的网站，因为100多种资源是通用的，但是我们将使其保持简单和举这个例子).假设每个请求花费100毫秒的时间才能通过Internet到达Web服务器并往返，并且两端的处理时间都可以忽略不计(为简单起见，本例中为0).由于您必须发送每种资源并一次等待一个响应，因此下载整个站点将需要10 * 100ms = 1,000ms或1秒.

As an example let's say there are 10 resources that your web page needs to load after the HTML is loaded itself (which is a very small site by today's standards as 100+ resources is common, but we'll keep it simple and go with this example). And let's say each request takes 100ms to travel across the Internet to web server and back and the processing time at either end is negligible (let's say 0 for this example for simplicity sake). As you have to send each resource and wait for a response one at a time, this will take 10 * 100ms = 1,000ms or 1 second to download the whole site.

要解决此问题，浏览器通常会打开与Web服务器的多个连接(通常为6个).这意味着浏览器可以同时触发多个请求，这要好得多，但是以必须设置和管理多个连接的复杂性为代价(这会影响浏览器和服务器).让我们继续前面的示例，并说有4个连接，为简单起见，假设所有请求都相等.在这种情况下，您可以将请求拆分为所有四个连接，因此两个将拥有3个资源，而两个将拥有2个资源以总共获得十个资源(3 + 3 + 2 + 2 = 10).在那种情况下，最坏的情况是3个舍入时间或300ms = 0.3秒-很好的改进，但是这个简单的示例不包括建立多个连接的成本，也不包括管理它们的资源(我还没有做过)进入这里，因为这个答案已经足够长了，但是建立单独的TCP连接确实需要时间和其他资源-完成TCP连接，HTTPS握手，然后由于TCP启动缓慢而达到全速).

To get around this, browsers usually open multiple connections to the web server (typically 6). This means a browser can fire off multiple requests at the same time, which is much better, but at the cost of the complexity of having to set-up and manage multiple connections (which impacts both browser and server). Let's continue the previous example and also say there are 4 connections and, for simplicity, let's say all requests are equal. In this case you can split the requests across all four connections, so two will have 3 resources to get, and two will have 2 resources to get totally the ten resources (3 + 3 + 2 + 2 = 10). In that case the worst case is 3 round times or 300ms = 0.3 seconds - a good improvement, but this simple example does not include the cost of setting up those multiple connections, nor the resource implications of managing them (which I've not gone into here as this answer is long enough already but setting up separate TCP connections does take time and other resources - to do the TCP connection, HTTPS handshake and then get up to full speed due to TCP slow start).

HTTP/2允许您在相同连接上发送多个请求-因此，您无需按照上述方法打开多个连接.因此，您的浏览器可以说给该CSS文件给我".给我那个JavaScript文件. Gimme image1.jpg. Gimme image2.jpg ...等等.充分利用单个连接.这具有明显的性能优势，它不会延迟等待空闲连接的那些请求的发送.所有这些请求(几乎)并行地通过Internet到达服务器.服务器对每个响应，然后它们开始返回.实际上，它比Web服务器更强大，因为Web服务器可以按感觉中的任何顺序响应它们并以不同的顺序发送回文件，甚至可以将每个请求的文件分解成碎片并将文件混合在一起.这具有第二个好处，即一个繁重的请求不会阻止所有其他后续请求(称为行头阻塞问题).然后，Web浏览器的任务是将所有部分放回原处.在最佳情况下(假设没有带宽限制-参见下文)，如果同时并行触发所有10个请求，并立即由服务器答复，则意味着您基本上有一个往返行程或100ms或0.1秒，下载所有10个资源.这没有HTTP/1.1的多个连接所具有的缺点！随着每个网站上资源的增加，这也具有更大的可伸缩性(当前浏览器在HTTP/1.1下最多可以打开6个并行连接，但是随着网站变得越来越复杂，它应该会增加吗?).

HTTP/2 allows you to send off multiple requests on the same connection - so you don't need to open multiple connections as per above. So your browser can say "Gimme this CSS file. Gimme that JavaScript file. Gimme image1.jpg. Gimme image2.jpg... Etc." to fully utilise the one single connection. This has the obvious performance benefit of not delaying sending of those requests waiting for a free connection. All these requests make their way through the Internet to the server in (almost) parallel. The server responds to each one, and then they start to make their way back. In fact it's even more powerful than that as the web server can respond to them in any order it feels like and send back files in different order, or even break each file requested into pieces and intermingle the files together. This has the secondary benefit of one heavy request not blocking all the other subsequent requests (known as the head of line blocking issue). The web browser then is tasked with putting all the pieces back together. In best case (assuming no bandwidth limits - see below), if all 10 requests are fired off pretty much at once in parallel, and are answered by the server immediately, this means you basically have one round trip or 100ms or 0.1 seconds, to download all 10 resources. And this has none of the downsides that multiple connections had for HTTP/1.1! This is also much more scalable as resources on each website grow (currently browsers open up to 6 parallel connections under HTTP/1.1 but should that grow as sites get more complex?).

此图显示了差异，并且有一个

This diagram shows the differences, and there is an animated version too.

注意:HTTP/1.1确实具有流水线的概念，该概念也允许多个请求立刻被送走.但是，仍然必须按顺序返回它们，以完整地请求它们，因此即使在概念上相似，也远未达到HTTP/2的水平.更不用说事实上，浏览器和服务器对它的支持都非常差，因此很少使用.

Note: HTTP/1.1 does have the concept of pipelining which also allows multiple requests to be sent off at once. However they still had to be returned in order they were requested, in their entirety, so nowhere near as good as HTTP/2, even if conceptually it's similar. Not to mention the fact this is so poorly supported by both browsers and servers that it is rarely used.

在下面的评论中强调的一件事是带宽如何影响我们.当然，您的Internet连接受到可下载数量的限制，而HTTP/2不能解决该问题.因此，如果以上示例中讨论的那10个资源都是高质量的打印质量图像，则下载速度仍然很慢.但是，对于大多数Web浏览器来说，带宽要比延迟少的问题.因此，如果这十种资源是小物品(尤其是CSS和JavaScript之类的文本资源，可以压缩成很小的大小)，如网站上常见的那样，那么带宽并不是真正的问题-数量庞大的资源通常是问题，HTTP/2似乎可以解决该问题.这也是为什么在HTTP/1.1中使用串联作为另一种解决方法的原因，因此，例如，所有CSS经常被合并到一个文件中:下载的CSS数量相同，但是通过将其作为一种资源来使用，则具有巨大的性能优势(尽管对于HTTP/2则不太那么，实际上有人说串联应该是 HTTP/2下的反模式-尽管也有很多人反对完全取消它).

One thing highlighted in below comments is how bandwidth impacts us here. Of course your Internet connection is limited by how much you can download and HTTP/2 does not address that. So if those 10 resources discussed in above examples are all massive print-quality images, then they will still be slow to download. However, for most web browser, bandwidth is less of a problem than latency. So if those ten resources are small items (particularly text resources like CSS and JavaScript which can be gzipped to be tiny), as is very common on websites, then bandwidth is not really an issue - it's the sheer volume of resources that is often the problem and HTTP/2 looks to address that. This is also why concatenation is used in HTTP/1.1 as another workaround, so for example all CSS is often joined together into one file: the amount of CSS downloaded is the same but by doing it as one resource there are huge performance benefits (though less so with HTTP/2 and in fact some say concatenation should be an anti-pattern under HTTP/2 - though there are arguments against doing away with it completely too).

举一个现实的例子:假设您必须从商店订购10件商品才能送货上门:

To put it as a real world example: assume you have to order 10 items from a shop for home delivery:

带有一个连接的

• HTTP/1.1意味着您必须一次订购一个，并且直到最后一个订购时才能订购下一个.您可以理解，要完成所有步骤，将需要数周的时间.

• HTTP/1.1 with one connection means you have to order them one at a time and you cannot order the next item until the last arrives. You can understand it would take weeks to get through everything.

具有多个连接的HTTP/1.1意味着您可以同时具有(有限)数量的独立订单.

HTTP/1.1 with multiple connections means you can have a (limited) number of independent orders on the go at the same time.

HTTP/1.1意味着您可以一个接一个地要求所有10个项目，而无需等待，但是所有项目都按照您要求的特定顺序到达.而且，如果一件物品缺货，那么您就必须等待，直到获得订购的物品为止-即使这些后来的物品实际上是有库存的！这样会好一些，但仍然会延迟，可以说大多数商店都不支持这种订购方式.

HTTP/1.1 with pipelining means you can ask for all 10 items one after the other without waiting, but then they all arrive in the specific order you asked for them. And if one item is out of stock then you have to wait for that before you get the items you ordered after that - even if those later items are actually in stock! This is a bit better but is still subject to delays, and let's say most shops don't support this way of ordering anyway.

HTTP/2意味着您可以按任何特定顺序订购商品-不会有任何延迟(类似于上述内容).商店将在准备就绪时分派它们，因此它们可能以与您要求的顺序不同的顺序到达，并且它们甚至可能拆分物品，因此该顺序的某些部分首先到达(因此比上面更好).最终，这应该意味着您1)总体上更快地完成所有工作，以及2)可以在到达每个项目时就开始处理它们(哦，这不如我想的那么好，所以我可能还想订购其他东西，或者代替它") ;).

HTTP/2 means you can order your items in any particular order - without any delays (similar to above). The shop will dispatch them as they are ready, so they may arrive in a different order than you asked for them, and they may even split items so some parts of that order arrive first (so better than above). Ultimately this should mean you 1) get everything quicker overall and 2) can start working on each item as it arrives ("oh that's not as nice as I thought it would be, so I might want to order something else as well or instead").

当然，您仍然受到邮递员货车大小(带宽)的限制，因此，如果当天装满，他们可能不得不将一些包裹留在分拣办公室，直到第二天为止.与实际发送和发送订单的延迟相比，这是一个问题.大多数Web浏览都涉及来回发送小写字母，而不是笨重的包裹.

Of course you're still limited by the size of your postman's van (the bandwidth) so they might have to leave some packages back at the sorting office until the next day if they are full up for that day, but that's rarely a problem compared to the delay in actually sending the order across and back. Most of web browsing involves sending small letters back and forth, rather than bulky packages.

希望有帮助.

这篇关于HTTP/2中的复用是什么意思的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！