HTTP/2: the Pros, the Cons, and What You Need to Know

HTTP/2: Revolutionary improvement in web page loading speed

HTTP/2 is a major upgrade to HTTP/1.1, designed to solve performance issues and reduce website loading time. It achieves this through features such as multiplexed streams, server push, header compression and binary format.

Multiplexing allows multiple requests and responses to be sent simultaneously over a single TCP connection, reducing congestion and increasing speed. Server push actively sends resources to the browser's cache, thereby improving performance. Header compression reduces data retrieval time and bandwidth usage. The binary format is easier to process, thus reducing server workload and page loading time.

Developers will no longer need to use solutions such as image Sprite, inline and file connection to reduce the number of requests on web pages. However, most HTTP/2-enabled browsers require HTTPS encryption, which may pose a challenge to some users considering switching.

Although HTTP/2 has many advantages, it has also been criticized for its over-focus on bandwidth and neglecting privacy issues. Some believe that HTTP/2 may not last long due to the rapid development of technology and the need for more flexible protocols to address changing technological challenges.

How HTTP/1.1 works

When you access a web page, the browser obtains the page by requesting all resources of the page from the web server. Since the birth of the Web, this has been done primarily through HTTP/1.1.

As time goes by, technology continues to evolve, websites become more and more complex and resource-intensive, the HTTP/1.1 protocol is under increasing pressure and requires many workarounds to deal with performance issues.

Today's web pages usually contain a lot of resources, such as images, text, fonts, etc., which makes them much heavier than those in the 90s and even the 2000s. As a result, they load longer, so web designers and developers come up with clever workarounds to solve this problem. However, it is obvious that the HTTP protocol itself needs to be updated.

How HTTP/2 works

Your browser will still send requests to the server and receive responses to the required resources so that the webpage can display properly, but the nuances between the two will change. HTTP/2 introduces new features such as multiplexed streams, server push, header compression and binary formats, which we will explore in turn.

• Multiplexing stream: Multiplexing passes these resources into smaller parts, passes them through a connection, and then reassembles the resources once they reach their final destination (browser) , thereby eliminating congestion problems caused by many connection delivery resources such as text, fonts, and pictures.

• Server push: Server push represents a more efficient way to deliver resources to the browser. In an HTTP/1 environment, the HTML page is sent to the browser, which must parse it and determine the resources it may need, and then request those resources from the server. HTTP/2 is more proactive in this regard, sending resources that the browser may need without requests. These resources go into the browser's cache and are immediately available when needed, which is an advantage for performance.

• Header Compression: In HTTP/1, each sent request is attached with a small portion of additional data - the HTTP header - that describes how the browser or server behaves. On average, a browser can make about 6 connections at a time, but considering that the number of connections required to load a typical web page may be as high as 100, this still requires retrieving a large amount of data, which takes time and bandwidth. When an HTTP/2 connection is established, all headers are packaged into a compressed block and sent as a whole. It transmits faster, and after the transmission is completed, the header block is decoded.

• Binary format instead of text format: Text format has some extra overhead that needs improvement, while binary format does not require any parsing. It's also more compact. The extra work of the server means extra time to wait for the webpage to load. This is why the binary format is easier to handle and is a reasonable improvement.

What different things can developers do now

Developers will no longer need to process image Sprite, inline and file connections, because there is no need to reduce the number of requests on the web page. Basically, this will be the biggest change in their daily work. However, there is more to be said about internal changes that may affect their work in some way.

Things to note

Although the HTTP/2 specification itself is not mandatory, most browsers that support HTTP/2 require HTTPS encryption. This means that if your HTTP/2 site is not provided via an encrypted connection, visitors will either have to find another client to access your site or miss it.

While there are now some trends that drive sites to deliver via HTTPS, browsers have criticized this requirement and will undoubtedly be a stumbling block for some people considering switching to HTTP/2. (For more tips on what HTTPS is and how to implement it, read SitePoint's recent introduction to HTTPS.)

For the public, the transition of the network will be seamless. Modifications and upgrades required to work in the new protocol version will be done in the server and in the browser. The server will be updated over time, ultimately supporting both protocols. Browsers that support the new protocol will automatically switch to HTTP/2. At the same time, old browsers will not be able to understand it. As a developer, you need to know if both your browser and the server you are using support for HTTP/2 to ensure that the connection will be upgraded to HTTP/2.

Some controversies

While many are excited about HTTP/2, others, like Poul-Henning Kamp, are not that impressed. Kamp thinks HTTP/2 is "really just a grand name for HTTP/1.2" and thinks that if it does take off, it will most likely not last long.

In his opinion, the new protocol does not solve the actual problem, but focuses too much on bandwidth. A better focus, he suggests, should be to cancel the concept of cookies and replace it with a session/identity tool. This will improve privacy in a world with increasing security risks to some extent. And HTTP/2, Kamp believes, does not significantly improve privacy.

View the difference

This Akamai demonstration illustrates how resources are loaded concurrently in both protocol versions. The first image is loaded via HTTP/1 and six concurrent connections (if you are using Google Chrome), while the second image is loaded via HTTP/2 as a whole, all parts are loaded at the same time.

If you want to have a deeper understanding of how data is loading differently in protocol connections, check out this golang.org example. It allows you to try different delay settings so that you can see how data is loaded concurrently on devices of different capacity. The longer the latency, the more obvious the HTTP/2 wins in terms of performance.

Bottom line

HTTP/2 will be a smooth transition for ordinary users, and for those working in the network, there are some choices to make.

Generally speaking, the website will be safer and load faster. The agreement has not brought about any fundamental change, probably because it is more technically and politically harder to achieve. That's why HTTP/2 may not serve us for that long.

The world of technology is growing faster every year, so in a few years we may need something else. My personal hope is that the next protocol will be more flexible and braver in dealing with changing technological challenges.

(FAQs)FAQs about HTTP/2 (The FAQs section is omitted here because the content is highly overlapping with the previously covered content, so that duplication is avoided.)

The above is the detailed content of HTTP/2: the Pros, the Cons, and What You Need to Know. For more information, please follow other related articles on the PHP Chinese website!