HTTP/2: Background, Performance Benefits and Implementations

HTTP/2: Network protocol that significantly improves web page loading speed

Core points:

• HTTP/2 (released in 2015) solves the latency problem of its predecessor HTTP/1.1 by compressing HTTP headers, implementing server pushes and multiplexing requests on a single connection. It is also designed to solve the problem of head-of-team blocking and requires encryption by default.
• The transition from HTTP/1.1 to HTTP/2 is not without challenges, as backward compatibility is required with existing websites. Any improvement to the protocol must be implemented in a way that does not interrupt the Internet.
• All mainstream browsers currently support HTTP/2, however, they require that all HTTP/2 requests must be encrypted, which is not a requirement of the HTTP/2 specification itself.
• Implementing HTTP/2 on a server usually involves upgrading the server software or hosting environment to a version that supports HTTP/2 and configuring the server to enable HTTP/2 functionality. It should be noted that HTTP/2 requires an SSL certificate, so the website needs to provide services through HTTPS.

Evolution of HTTP protocol:

The infrastructure of the Internet—or the physical network layer—is an Internet protocol (as part of the TCP/IP or transport layer). It is the infrastructure for most of our Internet communications.

Above it is the application layer, and various applications use different protocols to connect and transmit information. For example, we have SMTP, POP3 and IMAP for sending and receiving emails; IRC and XMPP for chatting; SSH for remote server access, and so on.

The most famous protocol, which is also synonymous with the Internet, is HTTP (Hypertext Transfer Protocol). We use it every day to visit the website. It was designed by Tim Berners Lee at CERN as early as 1989. The specification for version 1.0 was released in 1996 (RFC 1945), and version 1.1 was released in 1999.

HTTP specification is maintained by the World Wide Web Alliance and can be found at https://www.w3.org/standards/techs/HTTP.

The first generation of HTTP protocols (versions 1.0 and 1.1) dominated the Internet until 2015, after the release of HTTP/2, the industry (web server and browser vendors) began to adopt it.

Limitations of HTTP/1.1:

HTTP is a stateless protocol based on a request-response structure, which means that the client makes requests to the server, which are atomic: no single request is aware of the previous request. (That's why we use cookies - for example, in order to connect multiple requests in a user session to be able to provide an authenticated version of the website to the logged-in user).

Transfers are usually initiated by the client (user's browser), and the server usually responds only to these requests.

It can be said that the current HTTP state is quite "clumsy", or rather low-level, requiring a lot of "help" to the browser and server to illustrate how to communicate effectively. Making changes in this area is not easy, as many existing websites rely on backward compatibility with any introduced changes. Any operation designed to improve the protocol must be done in a seamless way without interrupting the internet.

In many ways, this strict request-response, atomic, synchronization model has become a bottleneck, and progress has taken the form of hacking, usually led by industry leaders such as Google and Facebook. The usual situation (which is being improved in various ways) is when visitors request a web page, and when their browser receives it from the server, it parses the HTML and finds other resources needed to render the page, such as CSS, images, and JavaScript. When it encounters these resource links, it stops loading all other content and requests the specified resource from the server. It will not move at all until it is received. It then requests another resource, and so on.

The number of requests required for loading of the world's top websites is usually hundreds.

This includes a lot of waiting time, as well as a lot of round trip time, during which visitors can only see white screen or semi-rendered websites. These are all a few seconds of wasted. During these request cycles, a large amount of available bandwidth is just idle and unused.

CDN can alleviate a lot of these problems, but they are also just a temporary solution.

As Mozilla's Daniel Stenberg (one of the people involved in HTTP/2 standardization) pointed out, the first version of the protocol has difficulty taking full advantage of the capacity of the underlying transport layer TCP. Users who have been working on optimizing website loading speeds know that this usually requires some creativity, to put it euphemistically.

Over time, the internet bandwidth speed has increased significantly, but the infrastructure in the HTTP/1.1 era has not taken full advantage of this. It still struggles to deal with issues like HTTP pipelines—pushing more resources over the same TCP connection—and so on. Clients in the browser support the most drags, Firefox and Chrome disable it by default, or it is not supported at all, such as IE, Firefox 54 versions, etc. This means that even a small resource needs to open a new TCP connection, and all the bloat that follows - TCP handshake, DNS lookup, delay... Due to the head of the team blocking, the loading of a resource will cause blocking all Loading of other resources.

Synchronizes the comparison of non-pipeline connections to pipeline connections, showing possible load time savings.

Under the HTTP/1 model, some optimization techniques that web developers must use to optimize their websites include image wizards, CSS and JavaScript connections, sharding (distributes the visitor's resource requests to multiple domains or subdomains). )etc.

Improvement is necessary, it must address these issues in a seamless, backward compatible way to avoid interrupting work on existing webs.

SPDY and HTTP/2:

In 2009, Google announced a project that would become a draft proposal for the next generation protocol SPDY (pronounced speedy), adding support for Chrome and pushing it toward it in the next few years. All web services. Subsequently, Twitter and server manufacturers such as Apache and nginx also provided support, Node.js, and later Facebook, WordPress.com and most CDN providers.

SPDY introduces multiplexing—sending multiple resources in parallel over a single TCP connection. The connection is encrypted by default and the data is compressed. First, preliminary tests of the first 25 websites in the SPDY white paper showed that the speed increased by more than 27% to more than 60%.

After proving its effectiveness in a production environment, SPDY version 3 became the basis for the first draft HTTP/2 developed by httpbis, the working group on Hypertext Transfer Protocols in 2015.

HTTP/2 is designed to resolve the delay problem that plagues the first version of the protocol by:

• Compress HTTP header
• Implement server push
• Multiplexing request on a single connection

It is also designed to solve the problem of head-on blocking. The data it transmits in binary format, improves efficiency and requires encryption by default (or at least, this is a requirement imposed by mainstream browsers).

Head compression is performed using the HPACK algorithm, which resolves vulnerabilities in SPDY and reduces the size of web requests in half.

Server push is one of the features designed to solve wasted waiting time, providing resources to the browser's server before the browser requests. This reduces round trip time, which is a major bottleneck in website optimization.

Due to all these improvements, the load time difference brought by HTTP/2 can be seen on the example page of imagekit.io.

The more savings in loading time, the more obvious the website resources are.

How to see if a website provides resources via HTTP/2:

In mainstream browsers such as Firefox or Chrome, we can check the website's support for the HTTP/2 protocol in the Inspector tool by opening the "Network" tab and right-clicking the stripe above the resource list. Here we can enable the "Protocol" item.

Server side implementation:

As of this writing, all mainstream browsers support HTTP/2, although all HTTP/2 requests are required, and the HTTP/2 specification itself does not require encryption.

Server

Apache 2.4 supports it through its mod_http2 module, which should now be ready for production. Apache needs to build it by adding the --enable-http2 parameter to the ./configure command. We also need to make sure that at least version 1.2.1 of the libnghttp2 library is installed. If the system has trouble finding it, we can provide a path to ./configure by adding --with-nghttp2=.

The next step is to load the module by adding the directive to Apache's configuration:

<code>LoadModule http2_module modules/mod_http2.so</code>

Then we add Protocols h2 h2c http/1.1 to our virtual host block and reload the server. Apache's documentation warns us about precautions when enabling HTTP/2:

Enabling HTTP/2 on your Apache server will affect resource consumption, and if you have a busy site you may want to carefully consider its impact.

When HTTP/2 is enabled, the first thing to note is that your server process will start additional threads. The reason is that HTTP/2 hands all requests it receives to its own worker thread for processing, collects the results and streams them to the client.

You can read more about Apache configuration here.

nginx has supported HTTP/2 since version 1.9.5, we can enable it by simply adding the http2 parameter to our virtual host specification:

<code>server {
    listen 443 ssl http2 default_server;

    ssl_certificate    server.crt;
    ssl_certificate_key server.key;</code>

Then reload nginx.

Unfortunately, as of this writing, server push has not been officially implemented, but it has been added to the development roadmap and is scheduled to be released next year. For more adventurous people, there is an unofficial nginx module that adds support for HTTP/2 server push.

LiteSpeed ​​and OpenLiteSpeed ​​also boast about supporting HTTP/2.

A note before activating HTTP/2 on the server side is to make sure we have SSL support. This means that all the virtual host code snippets we mentioned above - for Apache and nginx - need to enter the SSL version of the virtual host block and listen to port 443. Once we have Apache or nginx installed, and we have configured the regular virtual host, getting the LetsEncrypt SSL certificate and installing it on any major Linux distribution should be a matter of just a few lines of code. Certbot is a command line tool that automates the entire process.

Summary:

In this article, I briefly outline HTTP/2, an emerging second-generation web protocol specification.

The complete list of implementations of the new generation of HTTP can be found here.

For those who don't know much about technology, the shortcut to transitioning to this new protocol may be to simply implement CDN in the web stack, because CDN was one of the first vendors to adopt HTTP/2.

HTTP/2 FAQ:

(The FAQ part is omitted here because it is highly duplicated with the previous output)

The above is the detailed content of HTTP/2: Background, Performance Benefits and Implementations. For more information, please follow other related articles on the PHP Chinese website!