What Is HTTP/2? Everything You Need to Know
The Hypertext Transfer Protocol (HTTP) is the underlying communication protocol of the World Wide Web that defines how browsers and servers exchange the text, images, scripts, and media that make up modern websites.
The fourth major iteration of this protocol, HTTP/2, helps reduce latency, speed up page load times, and make more efficient use of network resources. These improvements support a more complex, media-rich internet than previous versions.
In this article, we’ll explain what HTTP/2 is, how it works, how it compares to earlier and newer protocol versions, and what its advantages and limitations look like in real-world use case scenarios.
What Is the HTTP/2 Protocol and Why Is It Important?
A protocol is a standardized set of rules that govern how data is transmitted and received across a network. In the context of the internet, these rules ensure that different devices and applications can effectively communicate with one another.
One of the fundamental web protocols is HTTP, which governs how web browsers and servers exchange information. It operates on a client-server model: A client (usually a web browser) sends a request to a server, which then responds with the requested resources (e.g. text, images, or videos).
The HTTP/2 protocol is one of the most popular and widely used web protocols today. It’s a major revision of the HTTP network, developed to address performance limitations of previous versions and improve the efficiency of web communications.
By enabling multiple simultaneous requests over a single connection and reducing the overhead of data transmission, HTTP/2 speeds up page loads and reduces round-trip times (RTTs), leading to a more efficient and responsive web experience.
How HTTP/2 Works
When a browser loads a website, it needs to request many different resources from a server, including elements such as text, images, stylesheets, scripts, and fonts.
Instead of creating a completely separate connection to communicate each of these things, the HTTP/2 protocol keeps one connection open and uses it to move these different pieces of data back and forth efficiently.
To do this, communication is broken into smaller pieces called frames. Each frame contains a specific type of information (e.g. request details, response headers, or page content). These frames are lightweight and can be sent quickly, which helps keep data flowing smoothly between the client and server.
Frames are grouped into streams, which represent individual request-and-response exchanges that are created either by the browser or the server. Every frame also includes a stream identifier, which enables whichever side receives the data (i.e. the browser or the server) to reassemble frames into complete requests or responses.
As everything happens over a single connection, resources can be transferred in parallel without repeatedly opening and closing new connections, which reduces waiting time and keeps pages loading smoothly.

HTTP/2 Features: How It Enables a Smoother Online Experience
Modern websites need browsers and servers to communicate quickly and efficiently to load complex pages smoothly.
This is why HTTP/2 was developed with a number of attributes that help to reduce latency, speed up page load times, improve performance on mobile and high-latency networks, handle large responses, and reduce overall network usage.
Prioritization
Prioritization defines the order in which website resources should be delivered when multiple files are requested at the same time.
Not all files are equally important for loading a web page. For example, core page content and styling usually need to load before images or background assets. Prioritization allows the client to signal which streams are more important, helping the server decide how to allocate bandwidth and processing time.
This is especially useful when handling large responses or pages with many resources, because it helps ensure that critical content is delivered sooner, even if other large files are still being transferred.
Delivery Models
Delivery models describe how data is sent between the browser and server when multiple resources are needed to load a page.
Here, HTTP/2 uses multiplexing to allow multiple requests and responses to move across the same connection at the same time, rather than handling each resource in strict sequence.
At the same time, server push lets the server send certain resources to the browser before they are explicitly requested. For example, if a server knows a page requires a specific stylesheet or script, it can send those files proactively.
Together, these HTTP/2 attributes help make more efficient use of available network bandwidth. By reducing idle time between requests and avoiding unnecessary back-and-forth communication, they help deliver resources faster and reduce overall network overhead.
Header Compression
Headers contain metadata like details about a request, the content type, or how the server should handle the response. While each header is relatively small, they add up quickly when a page requires many resources.
With header compression, HTTP/2 reduces repeated or predictable header information before it’s sent across the network to reduce the amount of data that needs to be transmitted with every request.
By sending less duplicate metadata, header compression helps make more efficient use of network bandwidth, reduces unnecessary data transfer, and supports faster delivery of page resources, especially on slower or bandwidth-constrained networks.
Binary
Binary is a type of computer language where two values (e.g. 1s and 0s) are used to communicate and transmit information. Instead of sending instructions and data as human-readable text, information is encoded into a binary format that machines can read and interpret.
Where text-based protocols rely on parsing characters and separators – which can add processing overhead and increase the chance of formatting inconsistencies – binary makes it easier for clients and servers to process requests, responses, and supporting data accurately.
Standardizing how data is packaged and transmitted between client and server supports more efficient communication, reduces processing overhead, and helps improve overall network performance when many resources are being transferred at once.
Security
As websites have become more complex and begun to handle more sensitive data, web protocols have needed to evolve to support safer, more predictable communication between browsers and servers.
Although HTTP/2 itself doesn’t require encryption, most modern browsers only support it over the Transport Layer Security (TLS) protocol. This means data exchanged between clients and servers is encrypted in transit, helping protect sensitive information from interception.
The binary format also improves security. It helps to minimize risks like response splitting, where attackers try to inject malicious responses into legitimate server communications. It also reduces the likelihood of cross-protocol attacks by ensuring that the client and server agree on how communication will happen when the connection is set up.
On top of this, connection handling helps to mitigate certain denial-of-service attacks, including Slowloris-style attacks that attempt to keep connections open for long periods to exhaust server resources.
Disadvantages of HTTP/2
Although HTTP/2 significantly improved web performance when it was introduced, it has some drawbacks and limitations that you should be aware of.
- Older generation protocol: HTTP/2 can be more difficult to optimize for modern use cases like highly variable mobile connectivity or large-scale real-time data exchange.
- Inconsistent performance on unstable networks: In high packet-loss environments like mobile or satellite networks, TCP retransmission can pause data transfer, leading to slower or uneven performance.
- TLS handshake latency: Secure connections typically require multiple TLS handshake steps, which can cause delays during the initial connection setup, especially on high-latency networks.
- Compression-related security risks: Compression features (e.g. header compression) can make users vulnerable to BREACH and CRIME attacks if systems aren’t carefully configured.
- Compatibility constraints: The protocol relies on legacy request methods and status codes to maintain compatibility with earlier HTTP versions, which can limit flexibility as web standards evolve.
- Encryption is not mandated: Although modern browsers typically enforce encrypted connections, HTTP/2 itself does not strictly require encryption.
- Cookie-handling complexity: Tracker behavior across multiple requests can introduce challenges in caching, state management, and performance tuning in certain architectures.
How We Got to HTTP/2: A History of Internet Protocols
As websites have become increasingly complex and media-rich, HTTP has had to evolve. HTTP/2 is the fourth major version of this layer, building on earlier versions to improve how data is delivered between browsers and servers.
Early 1990s: HTTP/0.9
Often called the one-line protocol, HTTP/0.9 was extremely simple. A request consisted of a single line starting with “GET”, followed by the path to a resource. The server would return raw HTML with no headers, metadata, or status codes.
This simplicity made early web communication easy to implement, but it also meant the protocol could only really support basic document retrieval.
Late 1996: HTTP/1.0
HTTP/1.0 expanded how requests were structured, supplementing the original “GET” request with the protocol version identifier “HTTP/1.0”. Headers were also introduced to carry extra information about the request or response.
This made it possible to support richer content and more complex web behavior. As websites became more resource-heavy, the need to open a new connection for each request created a lot more overhead.
Early 1997: HTTP/1.1
The development of HTTP/1.1 happened largely in tandem with HTTP/1.0. One of the most important additions was the “Host” header, which allowed multiple domains to be hosted on a single server IP address.
This helped scale the commercial web. However, as sites became more complex, limitations around how requests were handled over connections started to affect performance.
Mid-2015: HTTP/2
The fourth HTTP version reworked how data is structured and delivered between browsers and servers.
Instead of opening multiple connections and waiting for data to travel back and forth between the client and the server, HTTP/2 focused on moving as much data as possible in as few communication rounds as possible.
By reducing the number of connection setups and back-and-forth exchanges, HTTP/2 reduces RTT to help resource-heavy pages load faster.

HTTP/2 vs HTTP/3
Both HTTP/2 and HTTP/3 are designed to improve how browsers and servers exchange data and support faster, more efficient web performance.
While they use the same request methods, status codes, and general communication model to maintain compatibility with existing websites and applications, they transport data across networks in very different ways.
Where HTTP/2 runs over TCP, HTTP/3 runs over the Quick UDP Internet Connections (QUIC) transport protocol. This affects how connections are established and how performance is maintained on unstable or high-latency networks.
Here’s how they compare:
| HTTP/2 | HTTP/3 | |
| Transport protocol | TCP | QUIC (built on UDP) |
| Multiplexing | Yes | Yes |
| Connection setup | Separate transport and encryption setup | Transport and encryption handled together |
| Packet loss handling | Packet loss can slow all data streams | Packet loss usually affects only the impacted stream |
| Encryption | Not required (but enforced by browsers) | Required by design |
| Network switching (e.g. Wi-Fi to mobile) | Typically requires reconnecting | Can maintain connection during network changes |
| Performance on unstable networks | Can degrade under packet loss | Designed to perform better under packet loss |
How to Use HTTP/2
Most modern web browsers support HTTP/2 by default, so users typically only need to open their browser and visit a website to use the protocol.
There’s a little more involved with using HTTP/2 on the server side. Website owners and infrastructure teams need to make sure their servers, hosting environment, and security settings support HTTP/2. The exact steps will vary depending on the server software:
- Apache: HTTP/2 support is available in Apache 2.4.17 and later using the mod_http2 module. Server owners need to enable the module and configure supported protocols, but HTTP/2 is normally enabled on HTTPS virtual hosts.
- Nginx: HTTP/2 is supported in modern Nginx versions and is usually enabled by adding an HTTP/2 directive to the HTTPS server block. As with Apache, HTTP/2 is typically deployed alongside HTTPS.
- Internet Information Services (IIS): HTTP/2 support is built into newer versions of Windows Server and IIS. In most cases, HTTP/2 is enabled automatically when HTTPS is configured and no additional manual setup is required.
HTTP/2: Frequently Asked Questions
What is HTTP/2?
HTTP/2 is the fourth iteration of the Hypertext Transfer Protocol (HTTP). With features like multiplexing, header compression, and binary framing, it helps to reduce latency and improve the efficiency of data transmission between browsers and servers.
What is the HTTP/2 protocol and how does it work?
The HTTP/2 protocol is a web protocol that breaks HTTP messages down into binary-encoded frames, which are organized into streams over a single TCP connection. This structure allows multiple requests and responses to be sent simultaneously, improving page load times and resource utilization.
How is HTTP/2 different from HTTP/1.1?
Unlike HTTP/1.1, which processes one request per connection, HTTP/2 supports multiplexing, allowing multiple requests and responses to flow concurrently over a single connection. It also uses binary framing instead of text, compresses headers to reduce overhead, and introduces server push capabilities.
How do websites or browsers use HTTP/2?
Modern browsers automatically use HTTP/2 when connecting to servers that support it, typically over HTTPS. Websites need to enable HTTP/2 on their servers, often by configuring server software like Apache or Nginx, and ensuring TLS is set up correctly.