Programming
What does multiplexing mean in HTTP2
In the realm of web performance, efficient data transfer is paramount. HTTP/2, the successor to HTTP/1.1, introduces significant improvements, one of the most impactful being multiplexing. But what does multiplexing mean in HTTP/2, and how does it revolutionize web communication? Essentially, it allows multiple requests and responses to be transmitted simultaneously over a single TCP connection. This overcomes the limitations of HTTP/1.1, where multiple connections were often needed to load a single webpage, leading to increased overhead and latency. This breakthrough drastically improves website loading times and enhances the overall user experience. Understanding this concept is crucial for anyone involved in web development or performance optimization.
Understanding the Limitations of HTTP/1.1
Before diving into the benefits of HTTP/2 multiplexing, it’s crucial to understand the problems it solves in HTTP/1.1. HTTP/1.1, while a significant improvement over its predecessor, still suffered from performance bottlenecks related to connection management. The most notable of these was “head-of-line blocking,” where a single stalled request could block all subsequent requests on the same connection. Web browsers often worked around this by opening multiple TCP connections to a single server, a technique known as domain sharding. However, establishing and maintaining multiple connections incurs significant overhead, including increased resource consumption on both the client and server, and slower initial connection times.
Furthermore, HTTP/1.1 required that requests and responses be processed sequentially on a single connection. This meant that even if the server had multiple resources ready to send, it had to wait for the previous request to be fully processed before sending the next one. This created unnecessary delays, especially when dealing with numerous small resources like images, stylesheets, and JavaScript files. The cumulative effect of these limitations was slower page load times and a less responsive user experience. The need for a more efficient protocol became increasingly apparent as web pages grew more complex and resource-intensive. Legacy systems also lacked efficient header compression. The performance overhead associated with verbose headers added to the latency issues.
These inefficiencies prompted the development of HTTP/2, which aimed to address the shortcomings of HTTP/1.1 by introducing features like multiplexing, header compression (HPACK), and server push. By eliminating head-of-line blocking and reducing connection overhead, HTTP/2 significantly improved web performance, particularly for websites with numerous resources.
How HTTP/2 Multiplexing Works
HTTP/2 multiplexing tackles the limitations of HTTP/1.1 by enabling multiple requests and responses to be interleaved on a single TCP connection. This is achieved through a binary protocol that divides messages into smaller units called frames. Each frame contains a stream identifier, which allows the client and server to associate the frame with a particular request or response. These streams are then multiplexed over a single connection, meaning that frames from different streams can be sent and received in any order. The receiving end then reassembles the frames into complete messages based on their stream identifiers.
This approach eliminates head-of-line blocking because a delay in one stream does not affect the progress of other streams. The server can send responses for multiple requests concurrently, and the client can receive them in parallel. This dramatically reduces latency and improves the overall responsiveness of web applications. Furthermore, HTTP/2 uses header compression (HPACK) to reduce the size of HTTP headers, which further minimizes overhead and improves performance. According to Google, “HTTP/2 enables more efficient use of network resources and reduces perceived latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection.” Google Developers: HTTP/2
Consider a scenario where a webpage needs to load ten images. In HTTP/1.1, this would typically require multiple TCP connections, each handling one or two images at a time. With HTTP/2 multiplexing, all ten images can be requested and received simultaneously over a single connection, significantly reducing the time it takes to load the page. This results in a faster and more seamless user experience. The ability to prioritize streams is another crucial aspect of HTTP/2, allowing the server to send the most important resources first, further optimizing the user experience.
Benefits of Multiplexing
The benefits of HTTP/2 multiplexing are numerous and significant, leading to improved web performance and a better user experience. Here are some key advantages:
- Reduced Latency: By eliminating head-of-line blocking and enabling concurrent requests and responses, multiplexing dramatically reduces latency, resulting in faster page load times.
- Improved Resource Utilization: Using a single TCP connection for multiple requests reduces connection overhead, leading to more efficient use of network resources.
- Simplified Development: Developers no longer need to implement workarounds like domain sharding to improve performance, simplifying the development process.
Multiplexing allows for more efficient use of TCP connections, leading to reduced server load and improved scalability. Websites can handle more concurrent users without experiencing performance degradation. This is particularly important for websites with high traffic volumes or complex applications. Furthermore, multiplexing enables better prioritization of resources, allowing the server to send the most important resources first, ensuring that the user sees the most critical content as quickly as possible. This is a key factor in improving perceived performance and user satisfaction.
The adoption of HTTP/2 and its multiplexing capabilities has been shown to significantly improve website performance. Studies have demonstrated that websites using HTTP/2 load faster and consume fewer resources than those using HTTP/1.1. This translates to a better user experience, increased engagement, and improved business outcomes. One study by Akamai found that “HTTP/2 resulted in a 14% reduction in page load time over HTTP/1.1 on desktop and a 26% reduction on mobile.” Akamai: HTTP/2 Adoption and Performance
Implementing and Testing Multiplexing
Implementing HTTP/2 multiplexing typically involves configuring your web server and ensuring that your clients (browsers) support the protocol. Most modern web servers, such as Apache and Nginx, support HTTP/2 and can be configured to use it. It’s also essential to ensure that your SSL/TLS certificates are properly configured, as most browsers require HTTPS to use HTTP/2.
To verify that your website is using HTTP/2 multiplexing, you can use browser developer tools or online testing tools. These tools can show you the protocol being used for each request and response. You can also use command-line tools like curl with the –http2 option to test HTTP/2 connectivity. Furthermore, you should monitor your website’s performance using tools like Google PageSpeed Insights to identify any potential bottlenecks and ensure that you are realizing the full benefits of HTTP/2. Remember to use Lighthouse for performance testing to ensure correct implementation. You can find more information on testing with Lighthouse on this page.
Here are the steps to configure Nginx for HTTP/2:
- Ensure your server is running Nginx version 1.9.5 or later.
- Obtain an SSL/TLS certificate for your domain.
- Configure your Nginx server block to listen on port 443 with the ssl and http2 directives.
- Enable SSL/TLS by specifying the paths to your certificate and private key.
- Restart Nginx to apply the changes.
After implementing HTTP/2, it’s crucial to continuously monitor your website’s performance and make adjustments as needed. This includes optimizing your resources, ensuring that your CDN supports HTTP/2, and staying up-to-date with the latest HTTP/2 best practices. Regularly testing your implementation will ensure you continue to get the best performance.
- What is the main advantage of HTTP/2 multiplexing?
- The main advantage is reduced latency due to the elimination of head-of-line blocking and the ability to send multiple requests and responses simultaneously over a single connection.
- Does HTTP/2 require HTTPS?
- While the HTTP/2 specification does not mandate HTTPS, most modern browsers only support HTTP/2 over HTTPS for security reasons.
- How does HTTP/2 multiplexing improve website performance?
- It improves performance by reducing connection overhead, enabling concurrent requests and responses, and allowing for better resource prioritization.
- Is HTTP/2 multiplexing enabled by default in modern browsers?
- Yes, most modern browsers support and enable HTTP/2 multiplexing by default when communicating with servers that also support it.
Ultimately, embracing HTTP/2 and its features like multiplexing is no longer optional; it’s a necessity for delivering modern, high-performance web experiences. Take the time to evaluate your current infrastructure, implement the necessary changes, and monitor your website’s performance to reap the rewards of this powerful protocol. Consider exploring topics like server push and header compression to further optimize your web applications and improve user satisfaction. You can also consult resources like the IETF’s HTTP/2 specification RFC 7540 for a deeper understanding.
Question & Answer :
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…
When you load a web page, it downloads the HTML page, it sees it needs some CSS, some JavaScript, a load of images… etc.
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).
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).
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.
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 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.
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.
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).
To put it as a real world example: assume you have to order 10 items from a shop for home delivery:
- 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 with multiple connections means you can have a (limited) number of independent orders on the go at the same time.
- 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 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”).
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.
