HTTP/2 and HTTP/3 Protocols: Performance, Security, and Benefits
You use it every day, and you’ve probably come across the protocol at some point. At its core, this represents a natural evolution toward better security and modern infrastructure.
HTTP powers the World Wide Web. While HTTP/1.1 set the standard for decades, HTTP/2 and HTTP/3 brought significant performance improvements. In this article, I’ll walk you through the differences, advantages, and technical foundations of these protocols.
Why HTTP Needed to Evolve
HTTP/1.1 has two fundamental limitations:
- Head-of-Line Blocking: A single TCP connection processes only one request at a time. Browsers work around this by opening multiple parallel connections, but each one incurs setup time and a TLS handshake overhead.
- Uncompressed Headers: Headers are sent in full, uncompressed form with every request and response. This creates substantial overhead when you’re dealing with many requests.
These problems led to the development of HTTP/2 and HTTP/3.
HTTP/2 Fundamentals
HTTP/2 was published in 2015 as RFC 7540. It changes the transport layer, not the semantics. From a web developer’s perspective, requests and responses look the same, but they travel more efficiently.
Binary Framing
HTTP/1.1 transmits data as readable text. HTTP/2 uses binary framing instead. Messages are split into small units called frames, which belong to streams, which in turn belong to a connection.
Example:
When you load a webpage, the HTML, CSS, JavaScript, and images travel over separate streams within a single TCP connection.
Multiplexing
HTTP/2 enables multiplexing—multiple requests and responses flow simultaneously over one TCP connection. This eliminates the head-of-line blocking problem that plagued HTTP/1.1.
Think of it this way: HTTP/1.1 is a single-lane road. HTTP/2 is a multi-lane highway.
Header Compression with HPACK
HTTP/2 uses HPACK to compress headers. Recurring header fields are stored in a table and referenced in subsequent requests rather than resent in full.
Example: User-Agent: Mozilla/5.0 gets resent with every request in HTTP/1.1. In HTTP/2, it’s referenced after the first request.
Server Push
HTTP/2 allows servers to proactively send resources to the client before it explicitly requests them. When a client requests an HTML file, the server can push CSS and JavaScript alongside it. Server Push is controversial in practice because it can lead to unnecessary data transfer.
Stream Prioritization
HTTP/2 lets you prioritize individual streams. Critical resources like CSS or JavaScript are transmitted first.
HTTP/2 Performance Benefits
- Faster load times: Multiplexing and header compression reduce latency.
- Fewer TCP connections: Usually one connection per host is enough.
- Better resource utilization: Servers and networks operate more efficiently.
- Lower overhead: Binary transmission and compressed headers save bandwidth.
HTTP/3 Fundamentals
HTTP/3 was published in 2022 as RFC 9114. While HTTP/2 runs on TCP, HTTP/3 runs on QUIC, which is built on top of UDP.
QUIC Instead of TCP
QUIC is a transport protocol developed by Google:
- Faster connection setup: QUIC combines connection establishment and TLS handshake into a single step, typically saving one round trip.
- 0-RTT Resumption: When reconnecting, the client can send data immediately without a new handshake.
- Connection Migration: QUIC uses a connection ID independent of IP address and port. Switching from WiFi to mobile data remains seamless.
UDP as the Foundation
UDP is connectionless and unreliable. There’s no guarantee of packet order or delivery. QUIC builds on UDP and handles reliability, ordering, and flow control itself.
TLS 1.3 Integration
HTTP/3 requires TLS 1.3. Security is mandatory with HTTP/3. TLS 1.3 is faster than TLS 1.2 because it streamlines the handshake and removes outdated algorithms.
Improved Head-of-Line Blocking
In HTTP/2, a lost TCP packet can block all streams. In HTTP/3, each stream is independent. A lost packet only affects the specific stream it belongs to.
HTTP/3 Performance Benefits
- Even faster connection setup: QUIC and TLS 1.3 eliminate the separate TCP handshake.
- Better mobility: Connection Migration enables seamless network switching.
- Less head-of-line blocking: Streams are more independent.
- Higher security: TLS 1.3 is mandatory.
- Better performance on unreliable networks: QUIC responds faster to packet loss.
HTTP/1.1, HTTP/2, and HTTP/3 Comparison
| Feature | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|
| Transport Protocol | TCP | TCP | UDP with QUIC |
| Transmission | Text | Binary | Binary |
| Multiplexing | No | Yes | Yes |
| Header Compression | No | HPACK | QPACK |
| Server Push | No | Yes | Optional |
| Connection Setup | Slow | Faster | Fastest |
| TLS | Optional | Optional | Mandatory |
| Head-of-Line Blocking | Application layer | TCP layer | Stream layer |
| Connection Migration | No | No | Yes |
Security in HTTP/2 and HTTP/3
HTTP/2 Security
In practice, HTTP/2 is almost always deployed with TLS. Key security considerations:
- TLS encryption: Data is protected in transit.
- HPACK DoS protection: Header size and stream count limits make Denial-of-Service attacks harder.
- Resource limits: Servers restrict the number of concurrent streams.
HTTP/3 Security
- TLS 1.3 mandatory: Unencrypted HTTP/3 connections don’t exist.
- Faster security: The TLS handshake is more efficient.
- 0-RTT risks: 0-RTT Resumption can theoretically enable replay attacks. Sensitive operations shouldn’t execute in the first 0-RTT packet.
Which TLS Version Should Your Server Support?
When you set up a web server or HTTP server, you often have the option to enable multiple TLS versions. The question is which ones make sense and which you should disable.
Enable Only TLS 1.2 and TLS 1.3
This is the recommended configuration for modern web servers:
- TLS 1.3 is the current version. It’s faster and more secure than TLS 1.2.
- TLS 1.2 is still necessary because some older clients and systems don’t support TLS 1.3 yet.
Disable TLS 1.0 and TLS 1.1
Don’t use these versions:
- Security vulnerabilities: TLS 1.0 and TLS 1.1 contain known weaknesses like BEAST and POODLE.
- Outdated algorithms: They support insecure cipher suites such as RC4 or SHA-1.
- Browser support: Modern browsers warn users about sites using TLS 1.0 or 1.1.
Never Enable SSL 2.0 or SSL 3.0
SSL is the predecessor to TLS. SSL 2.0 and SSL 3.0 are considered unsafe and should be completely disabled.
Enabling all TLS versions is a security mistake
It might seem tempting to maximize compatibility by allowing all versions. But that introduces serious security risks:
- Downgrade attacks: An attacker can force a connection to use a weaker TLS version if older versions are enabled.
- Outdated algorithms: Older TLS versions support insecure encryption methods.
- Compliance: Many security standards like PCI DSS explicitly prohibit TLS 1.0 and 1.1.
Recommended configuration
For most modern web servers, follow this approach:
- TLS 1.3: Enable it, always.
- TLS 1.2: Enable it for backward compatibility.
- TLS 1.1 and TLS 1.0: Disable them entirely.
- SSL: Disable it completely.
If you only serve modern clients, you can disable TLS 1.2 and support only TLS 1.3. For public websites, however, keep TLS 1.2 enabled so older clients can still connect.
And remember: you probably don’t want visitors using outdated infrastructure anyway.
Practical HTTP examples
The following examples illustrate why newer protocols really are better.
Example 1: Page load time
A website needs 100 resources. With HTTP/1.1, the browser opens multiple TCP connections. HTTP/2 transfers all resources in parallel over a single connection. HTTP/3 eliminates the TCP handshake entirely.
Example 2: Video streaming
Low latency matters for video streaming. HTTP/3 responds faster to network switches and handles packet loss more gracefully.
Example 3: Mobile apps
Mobile devices constantly switch between WiFi and cellular. HTTP/3 with QUIC maintains the connection even when the IP address changes.
Which version should you use?
- HTTP/1.1: Only for older or specialized legacy systems.
- HTTP/2: The widely adopted standard today for websites and APIs.
- HTTP/3: Growing adoption, especially for mobile applications, streaming, and cloud services.
HTTP/2 and HTTP/3 address the fundamental weaknesses of HTTP/1.1. HTTP/2 delivers significant performance gains through multiplexing and header compression. HTTP/3 goes further with QUIC and UDP, improving connection setup, mobility, and resilience to packet loss. Understanding these protocols is essential for modern web development.
Recommended books on web development
If you want to dive deeper into network protocols, web performance, and modern web development, we recommend these books:
Web Development
Books about React, Vue, frontend and backend
Eloquent JavaScript von Marijn Haverbeke
Bei Amazon ansehenAffiliate-Link: Bei einem Kauf erhalten wir möglicherweise eine Provision.
FAQ: HTTP/2 and HTTP/3
1. What’s the main difference between HTTP/2 and HTTP/3?
2. What is multiplexing in HTTP/2?
3. What is QUIC?
4. Why does HTTP/3 use UDP instead of TCP?
5. What is HPACK?
6. What is Server Push?
7. What is Connection Migration?
8. What is 0-RTT Resumption?
9. What is QPACK?
10. Is HTTP/3 faster than HTTP/2?
11. What is head-of-line blocking?
12. Which TLS version is required for HTTP/3?
13. What are replay attacks with 0-RTT?
14. When should I use HTTP/2?
15. When should I use HTTP/3?
Next in the API Learning Path
The next article in the API learning path covers API Design Principles — essential principles for building effective APIs, from resource structure to naming conventions.



