What Is the HTTP/2 Protocol? Overview and Examples
Learn what the HTTP/2 protocol is, its benefits, and real-world examples of its use in this comprehensive overview.
A hypertext transfer protocol (HTTP) is the backbone of internet functionality. While the HTTP/1.1 protocol has been around for quite some time, many web services have switched to the HTTP/2 protocol for its performance enhancements addressing increased web complexity and speed. By 2022, 46.9% of all websites used HTTP/2.
HTTP/2 is a major revision of the HTTP network, developed to address performance limitations of HTTP/1.1 and improve the efficiency of web communications. The HTTP/2 protocol can significantly impact web performance by:
- Reducing latency through concurrent data streams
- Decreasing overhead with compressed headers
- Optimizing resource delivery via server push
- Improving parsing efficiency with a binary format
As a result, HTTP/2 often leads to faster page loads, more efficient use of network resources, and improved performance, especially for complex websites and mobile users. In this article, we’ll define HTTP, explain how it works, share the histories of HTTP/1.1 to HTTP/2, and offer comparisons to HTTP/3, which was standardized in 2022 and is now seeing increased adoption.
Table of contents:
What is HTTP/2?
Why is HTTP important?
The history of HTTP/1.1 to HTTP/2
HTTP/2 features
HTTP/1.1 vs. HTTP/2: Main differences
Benefits of HTTP/2
Disadvantages of HTTP/2
How to start using HTTP/2 protocol
HTTP/2 and the Nginx server
Testing and troubleshooting HTTP/2
What is HTTP/2?
HTTP/2 is the second version of the HTTP protocol. It aims to make applications faster, simpler, and more robust by improving many of the drawbacks of the first HTTP versions.
The primary goals of HTTP/2 are:
- Enable request and response multiplexing
- Provide header compression
- Assure compatibility with the methods, status codes, URIs, and header fields defined by the HTTP/1.1 standard
- Optimized prioritization of requests, making sure that loading for optimal user experience is as fast as possible
- Support for server-side push
- Deliver server-side backwards compatibility, making sure servers can still serve clients only supporting HTTP/1.1 without any changes
- Transforming to a binary protocol from the text-based HTTP/1.1
Why is HTTP important?
HTTP (hypertext transfer protocol) is the protocol that powers most of the web today. As you opened this page, your web browser sent an HTTP request to a web server that returned the text you’re reading.
HTTP is a client-server protocol. This means requests are sent by one identity (for example, your browser), which acts as the client. The request is transferred to the server using the HTTP protocol, which tells the server what it wants.
To load this page, the server receives a request for an HTML (hypertext markup language) page, some images, and probably some JavaScript. When it receives the requests, it fetches the data and sends it back to your browser as responses, which will display them to you.
HTTP is also used for things that you don’t see with the naked eye. When you post something on social media, send a message to one of your friends, or open your favorite app, an HTTP request is most likely made in the background by the application you’re using. These requests are made toward web services that might store your social media posts, messages, or app data.
Another use for HTTP is streaming data. For smaller pieces of data like HTML pages and JavaScript, the full response can be sent directly, but for larger files, we need to stream the data to the client. This is when an HTTP connection is kept open for a longer period and sends data in smaller chunks.
Without HTTP, the World Wide Web would simply stop working.
The history of HTTP/1.1 to HTTP/2
In 1989, Sir Timothy John Berners-Lee invented the HTTP protocol on a NeXTcube workstation with a 25 MHz CPU and several MBs of RAM. The protocol worked on networks with port connection speeds of 10 Mbits. Today, however, we have dramatically faster CPUs and thousands of MBs of RAM, but the main WWW protocol is still only HTTP/1.1. It was last updated in 1992, so why are we still using it?
While other protocols have been updated over the years (FTP became SFTP; POP3 evolved to IMAP, and telnet became SSH), HTTP/1.1 has not changed and has developed many issues with speed, security, and user-friendliness.
Google was the first to investigate issues with HTTP/1.1. At the time, they were spending millions of dollars a year to support their data centers, and the HTTP/1.1 protocol simply cost too much in terms of CPU resources and internet connection capacity. They developed SPDY as an experimental alternative to HTTP/1.1—a protocol designed for better security and improved page load times.
The HTTP Working Group of the Internet Engineering Task Force (IETF) investigated Google’s SPDY protocol and Microsoft’s equivalent when designing the next version of HTTP. Facebook recommended HTTP/2 to be based on SPDY in July 2012.
Based on the research done by Google, Microsoft, and Facebook, the IETF released the HTTP/2 protocol in 2015, delivering a major revision of the most useful internet protocol, HTTP.
HTTP/2 Features
Some key features of HTTP/2 include:
- Binary. Its commands use 1s and 0s and not text.
- Multiplex. It allows multiple requests and responses to be sent at the same time.
- Compression. Compressing headers that have been requested previously makes things more efficient.
- Stream prioritization. This allows for the exchange of successive streams at one time.
- Server push. The server can send additional information needed for a request before it is requested.
- Increased security. HTTP/2 is supported through encrypted connections.
HTTP/1.1 vs. HTTP/2: Main differences
As mentioned, HTTP/2 was designed to fix many of the drawbacks experienced with HTTP/1.1. In this section, we go through the differences between HTTP/2 and its predecessor.
Compression
HTTP/2 offers built-in compression of the request headers (HPACK). Modern web applications usually accept a range of different headers, such as authorization, caching directives, and client information.
While compression of these might not make much of a difference for a single request, a lot of data must be sent over the network to be saved when compressing them in high-traffic applications. HTTP/1.1 does not compress headers by default.
Performance
HTTP/2 introduces several performance enhancements over HTTP/1.1:
- Reduced latency. By allowing multiple requests on a single connection, HTTP/2 significantly reduces latency, especially for sites with many small resources.
- Improved page load speed. The server push feature can send critical resources before they’re requested, potentially cutting page load times by seconds.
- Enhanced mobile performance. HTTP/2’s efficiency improvements are particularly noticeable on mobile networks with higher latency.
- Better handling of large responses. Stream prioritization ensures important content is delivered first, improving perceived load times for users.
- Reduced network usage. Header compression and multiplexing lead to more efficient use of network resources, benefiting both users and service providers.
Binary protocol
HTTP/2 is binary instead of using plain text, like HTTP/1.1 does. In practice, this means simplified implementation of commands that previously could be mixed up due to optional whitespace when using the text format. Browsers that support HTTP/2 will convert textual commands into binary before sending them over the network.
Security
HTTP/2 incorporates several security improvements:
- Mandatory encryption. While not required by the specification, most browsers only implement HTTP/2 over TLS (transport layer security), effectively enhancing overall security by making encryption a de facto requirement for web browsing.
- Protection against response splitting. The binary framing layer of HTTP/2 helps prevent HTTP response splitting attacks by ensuring a more structured and predictable format for data transmission than HTTP/1.1, which could allow header injection
- Reduced cross-protocol attacks. The ALPN (application-layer protocol negotiation) extension used in HTTP/2 helps prevent certain cross-protocol attacks by clearly identifying the negotiated protocol during the TLS handshake.
- Mitigating slowloris attacks. HTTP/2’s multiplexing makes it harder for attackers to exhaust server resources through slow, partial requests, as multiple streams can be handled within a single connection, reducing the impact of such denial of service attacks.
- General security enhancements. While HTTP/2 does not directly improve CSRF (cross-site request forgery) protection, its overall efficiency and structured data transmission can contribute to a more secure and robust web environment.
These enhancements make HTTP/2 faster and more secure than its predecessor.
Delivery models
While the HTTP/1.1 protocol delivers responses based on a single request, HTTP/2 uses multiplexing and server push features to increase the delivery performance.
Buffer overflow
The buffer is the space used by the client and server to hold requests that have not yet been processed. In HTTP/1.1, the flow control used to manage the available buffer space is implemented at the transport layer. In HTTP/2, the client and server can implement their own flow controls to communicate the available buffer space.
Multiplexing
HTTP/2 enables full request and response multiplexing. In practice, this means a connection made to a web server from your browser can be used to send multiple requests and receive multiple responses. This eliminates some of the time it takes to establish a new connection for each request. HTTP/1.1 does not support multiplexing.
Faster encrypted connections
HTTP/2 uses the new ALPN extension, allowing faster encrypted connections since the application protocol is determined during the initial connection. Using HTTP/1.1 without ALPN needs additional round trips for the encryption handshake.
No need for HTTP/1.1 workarounds
Multiple workarounds have been invented to bypass some of the drawbacks with HTTP/1.1.
Domain sharding is a common performance workaround used with HTTP/1.1 to trick browsers into opening more simultaneous connections than would normally be allowed.
Content concatenation is another common workaround for HTTP/1.1 that reduces the number of requests for different resources. To achieve this, web developers often combine all the CSS and JavaScript into single files.
Domain sharding and content concatenation are no longer needed with the built-in multiplexing in HTTP/2.
Benefits of HTTP/2
What are some pros to using HTTP/2? Let’s discuss the key benefits.
- HTTP/2 is binary instead of textual. This means HTTP/2 encodes its messages in binary format rather than the human-readable text format used in HTTP/1.1. HTTP/2 being binary instead of textual is advantageous because binary encoding is more efficient and faster than textual encoding. Binary messages are more compact, which reduces the size of data packets, leading to faster transmission speeds and lower latency. Additionally, binary protocols are easier for machines to parse and process, enhancing overall performance and efficiency in data communication.
- HTTP/2 is fully multiplexed, allowing multiple data requests to be sent simultaneously over a single TCP (transmission control protocol) connection. This advanced feature enables the downloading of web files in asynchronous mode from one server, unlike most modern browsers that restrict TCP connections to a single server.
- HTTP/2 uses header compression HPACK to reduce overhead as well.
- It allows servers to “push” responses proactively into client caches instead of waiting for a new request for each resource.
- HTTP/2 uses the new ALPN extension, which allows for faster encrypted connections since the application protocol is determined during the initial connection.
- It reduces additional round trip times (RTT), making your website load faster without any optimization.
As stated previously, domain sharding and asset concatenationareno longer needed with HTTP/2.
HTTP/2 is widely supported by browsers, too. As a basic internet technology, the HTTP/2 protocol must be supported by the current version of your browser to work well.
Disadvantages of HTTP/2
While HTTP/2 brought significant improvements over HTTP/1.1, it still has several limitations. As an IT professional, it’s crucial to understand these drawbacks, especially as HTTP/3 aims to address some of these issues.
It’s not very fast or modern.
HTTP/2 must maintain backward compatibility with HTTP/1.1, limiting its modernization. Its key performance drawbacks are listed below:
- HTTP/2 suffers from head-of-line blocking at the TCP layer, which can degrade performance in unreliable networks. HTTP/3 aims to address this issue by using QUIC, a UDP-based (user datagram) protocol.
- HTTP/2 requires a full connection reestablishment if packets are lost. HTTP/3, built on QUIC, is designed to offer faster connection recovery and the ability to migrate connections between networks.
- HTTP/2 typically needs multiple round trips for the TLS handshake, which can slow initial connection times. HTTP/3, through QUIC, aims to reduce this process, potentially requiring fewer round trips to establish a secure connection.
- HTTP/2 can experience performance issues in high packet loss environments, which particularly affects mobile and satellite networks. HTTP/3 is designed to show improved performance in these challenging conditions.
Most experts around the world expected a lot of new features in the HTTP/2 protocol, but these were not included in the final version. The main reason is simple: HTTP/2 must maintain backward compatibility with the old HTTP/1.1 by using the same POST and GET requests, codes of status (200, 301, 404, and 500), etc.
Also, several new features, like compression page headers, are vulnerable to BREACH and CRIME attacks.
Encryption is not required.
Years ago, data encryption was mostly limited to financial transactions. But hacks and even government surveillance are more viable threats, with implications on users’ private life and business.
Encryption may guard against those types of threats, but disputes inside the team of HTTP/2 developers led to a decision to “leave encryption as is in HTTP/1.1.”
This means that owners of a website may still choose a lower level of security, potentially putting users at risk. Developers of browsers can “fix” this issue in a way—currently, they turn on HTTP/2 only if SSL/TLS protocols are available.
So, HTTP/2 doesn’t mandate encryption, potentially allowing lower security levels. HTTP/3, although also not mandating encryption at the protocol level, is designed to be used with QUIC, which integrates security features more tightly, effectively making encryption standard practice.
Cookie security is still an issue.
HTTP/2 didn’t address the inherent security vulnerabilities of cookies, such as susceptibility to cross-site scripting (XSS) attacks. This issue persists due to backward compatibility requirements. While HTTP/3 also hasn’t fundamentally solved this problem, its improved performance and security features may provide better overall protection against some cookie-based attacks.
Despite these disadvantages, HTTP/2 remains widely adopted and supported across browsers and servers. HTTP/3, while offering notable improvements, especially in challenging network conditions, is still growing in adoption. Currently, HTTP/2 is used by 35.3% of all websites, HTTP/3 by 30.3%, and QUIC by 8.1%.
The choice between the protocols often depends on specific use cases and network environments. HTTP/2 may be preferred in certain scenarios, such as when broad compatibility with older systems is needed or in environments where UDP, which HTTP/3 relies on, is not feasible or well-supported.
How to start using HTTP/2 protocol
If you’re a client-side user, all you need to do is update your browser to the newest version. Most browsers support HTTP/2. If you’re a server-side user, the process of upgrading to HTTP/2 is a little more complicated.
Here are a few quick guides for different server environments.
Apache
We’ll start with the most popular server OS and webserver: Apache running Ubuntu 20.04. Other configurations may require more steps and must be done by skilled DevOps engineers (like Microsoft IIS). For Apache, HTTP/2 just requires installing a module that can be easily enabled for any website.
First, install Apache version 2.4.17 or higher on your server. The installation of the HTTP/2 module for Apache takes just three steps:
1. Add repository:
--CODE language-markup line-numbers--
sudo add-apt-repository ppa:ondrej/apache2
2. Now, update Apache2 from this repository to get the latest modules:
--CODE language-markup line-numbers--
sudo apt-get update
sudo apt-get upgrade apache2
3. Enable HTTP/2 protocol as a module for Apache:
--CODE language-markup line-numbers--
sudo a2enmod http2
Now we must enable HTTP/2 for your virtual host. Open a .conf file for your virtual host. You’ll see something like this one:
--CODE language-markup line-numbers--
<virtualhost 192.168.1.1:443=""></virtualhost>
SSLEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP
SSLCertificateFile /etc/ssl/star.example.com.crt
SSLCertificateKeyFile /etc/ssl/star.example.com.key
ServerName "one.example.com"
DocumentRoot "/var/www/html/one"
Protocols h2 http/1.1
CustomLog "/var/log/httpd/one-access.log" combined
ErrorLog "/var/log/httpd/one-error.log"
<directory var="" www="" html=""></directory>
AllowOverride none
Require all granted
</Directory>
</VirtualHost>
5. Add this line somewhere in the VirtualHost section:
--CODE language-markup line-numbers--
Protocols h2 http/1.1
6. Save this, close the file, and don’t forget to restart the Apache2 service:
--CODE language-markup line-numbers--
service apache2 restart
7. If you’ve done all of this correctly, the HTTP/2 protocol will start working.
8. You can verify if HTTP/2 is enabled by using online tools like KeyCDN HTTP/2 Test.
IIS
Below is a step-by-step guide to enable HTTP/2 on an IIS (Internet Information Services) server.
A couple of notes before you begin:
- HTTP/2 support was introduced in IIS 10.0, with no support prior to that version.
- You may need to enable IIS first. On Windows 10: Programs and Features > “Turn Windows features on or off” > check the Internet Information Services box. On Windows Server 2016, you would next: Launch Server Manager > Add roles and features on the dashboard > select Web Server (IIS) from the list.
1. Verify Windows and IIS version: HTTP/2 is supported in Windows Server 2016 and later. Ensure your server meets this requirement with the following: Start menu > Type “winver” and press Enter to check your Windows version. To check IIS version, open IIS Manager, click on the server name, and in the right panel, click on Help > About Internet Information Services.
2. Install SSL/TLS certificate: Ensure that your website is configured with an SSL/TLS certificate. You can use the Server Certificates feature in IIS to import and configure your certificate by opening IIS Manager, clicking on the server name in the Connections panel, then double-clicking on Server Certificates. Import your SSL certificate if not already done.
3. Bind SSL certificate to your site: In IIS Manager, expand the Sites node and select your site. In the Actions panel, click on Bindings. In the Site Bindings window, click Add. Choose https as the type, select your SSL certificate, and click OK.
4. HTTP/2 is enabled by default on Windows Server 2016 and later versions of IIS. However, you can confirm that it’s not disabled by checking the registry:some text
- Open Registry Editor (regedit) as an administrator.
- Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters.
- Look for a DWORD value named EnableHttp2 (it may be something similar, like EnableHttp2Tls or EnableHttp2Cleartext.)
- If this value doesn’t exist, HTTP/2 is enabled (default behavior).
- If it exists and is set to 0, HTTP/2 is disabled.
- If it exists and is set to 1, HTTP/2 is enabled.
- If you find that HTTP/2 is disabled (EnableHttp2 = 0), you can enable it by either deleting the EnableHttp2 value or setting its value to 1.
5. Restart IIS: After making the changes, restart IIS to apply the new settings. Open Command Prompt as an administrator. Run this command:
--CODE language-markup--
iisreset
6. Verify HTTP/2: You can verify if HTTP/2 is enabled by using browser developer tools. Open your website in a browser. Open the browser’s developer tools (F12). Navigate to the Network tab, reload the page, and check the protocol column to confirm it shows “h2.”. AlternativelyOr, or use online tools like KeyCDN HTTP/2 Test.
Nginx
HTTP/2 offers significant performance improvements over HTTP/1.x by multiplexing multiple streams over a single connection, header compression, and more. Below is a step-by-step guide to enabling HTTP/2 in Nginx.
1. HTTP/2 support is available in Nginx version 1.9.5 and later. Check your Nginx version using the following command:
--CODE language-markup--
nginx -v
If your version is older, you’ll need to upgrade Nginx.
2. To install or upgrade Nginx, you can use your package manager. For example, on Ubuntu:
--CODE language-markup--
sudo apt update
sudo apt install nginx
3. Open the Nginx configuration file for your site. This is typically located in /etc/nginx/sites-available/ or /etc/nginx/conf.d/.
4. Modify the listen directive to include http2. Your server block should look something like this:
--CODE language-markup line-numbers--
server {
listen 443 ssl http2;
server_name example.com;
ssl_certificate /path/to/certificate.crt;
ssl_certificate_key /path/to/certificate.key;
# other SSL settings...
# rest of your server configuration...
}
5. Before reloading Nginx, test the configuration to ensure there are no syntax errors:
--CODE language-markup--
sudo nginx -t
6. If the configuration test is successful, reload Nginx to apply the changes:
--CODE language-markup--
sudo systemctl reload nginx
7. You can verify if HTTP/2 is enabled by using browser developer tools or online tools like the KeyCDN HTTP/2 Test.
Testing and troubleshooting HTTP/2
Now, we’ll demonstrate how to test and troubleshoot HTTP/2 using a few popular browsers.
Google Chrome
1. To open Developer Tools, press Ctrl + Shift + I (Windows/Linux) or Cmd + Option + I (Mac). Then, click on the Network tab.
2. Now, right-click on the header of the table and select the Protocol column to add it.
3. Without closing the Developer Tools, refresh the page. The third column now shows resources that are loaded via the HTTP/2 protocol (“h2”).
Firefox and Edge
1. Press Ctrl + Shift + I (Windows/Linux) or Cmd + Option + I (Mac) to open the Developer Tools.
2. Click on the Network tab.
3. Right-click on the header row in the Network tab and select Protocol to make it visible. (You may need to reload the page to see the header row.)
4. Reload the webpage by pressing F5 or clicking the reload button in the browser.
5. Look for the Protocol column. If it says HTTP/2, then the site is using HTTP/2.
Safari
1. Open Safari and enable Developer Tools if not already enabled (Settings > Advanced > Select “Show features for web developers”).
2. Click on Develop in the menu bar and select Show Web Inspector.
3. Click on the Network tab.
4. Right-click on the header row in the Network tab and select Protocol to make it visible.
5. Reload the webpage by pressing Cmd + R or clicking the reload button in the browser.
6. Look for the Protocol column. If it says h2, the site is using HTTP/2.
To verify if your website or web application is using the HTTP/2 protocol, you can use tools like these to check your site’s URL:
Get web development help or connect with clients
Whether you decide to start using HTTP/2 or not is definitely your own choice as a website owner, but it’s undeniably a popular and effective option. If you have questions on how to shift to HTTP/2, get help from a web developer on Upwork.
Businesses of all sizes need support in working with HTTP/2. If you’re a web developer looking for work, Upwork can connect you with clients in search of your expertise.