Skip to content
IRC-CodingIRC-Coding
HTTP/2HTTP/3HTTPProtocolsNetworksQUICUDPTCPTLS 1.3MultiplexingHeader CompressionServer PushPerformanceSecurityWeb Development

HTTP/2 and HTTP/3 Protocols: Performance & Security

Learn HTTP/2 and HTTP/3: multiplexing, header compression, QUIC, UDP, TLS 1.3, and performance gains explained.

S

schutzgeist

8 min read
HTTP/2 and HTTP/3 Protocols: Performance & Security

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:

  1. 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.
  2. 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

FeatureHTTP/1.1HTTP/2HTTP/3
Transport ProtocolTCPTCPUDP with QUIC
TransmissionTextBinaryBinary
MultiplexingNoYesYes
Header CompressionNoHPACKQPACK
Server PushNoYesOptional
Connection SetupSlowFasterFastest
TLSOptionalOptionalMandatory
Head-of-Line BlockingApplication layerTCP layerStream layer
Connection MigrationNoNoYes

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.

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.

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

Eloquent JavaScript von Marijn Haverbeke

Bei Amazon ansehen

Affiliate-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?

The key difference is the transport protocol. HTTP/2 uses TCP, while HTTP/3 uses QUIC on top of UDP. This makes HTTP/3 faster at connection setup and more resilient to network switches.

2. What is multiplexing in HTTP/2?

Multiplexing allows multiple requests and responses to travel simultaneously over a single TCP connection. This solves the head-of-line blocking problem that plagued HTTP/1.1.

3. What is QUIC?

QUIC is a network protocol developed by Google that runs on top of UDP. It combines transport control, encryption, and fast connection setup into a single protocol.

4. Why does HTTP/3 use UDP instead of TCP?

UDP is more flexible than TCP. QUIC implements reliability, ordering, and flow control on top of UDP itself, making it independent of TCP’s constraints.

5. What is HPACK?

HPACK is HTTP/2’s header compression method. It maintains a table of repeated header fields and only transmits changes, not entire headers.

6. What is Server Push?

Server Push lets the server proactively send resources to the client before being asked. In practice, it’s rarely used because it often causes unnecessary data transfer.

7. What is Connection Migration?

Connection Migration allows a QUIC connection to stay alive even when the IP address or network changes. This is especially valuable for mobile devices.

8. What is 0-RTT Resumption?

0-RTT Resumption lets you send data immediately on reconnection without performing a fresh handshake. This significantly speeds up recurring connections.

9. What is QPACK?

QPACK is HTTP/3’s header compression method. It’s similar to HPACK in HTTP/2 but adapted for QUIC and independent stream processing.

10. Is HTTP/3 faster than HTTP/2?

HTTP/3 is faster in many scenarios, especially with mobile networks, frequent switches, and high packet loss. The actual difference depends heavily on your infrastructure and use case.

11. What is head-of-line blocking?

Head-of-line blocking occurs when a blocked request delays all subsequent ones. In HTTP/1.1 it happens at the application layer, in HTTP/2 at the TCP layer, and in HTTP/3 mainly at the stream layer.

12. Which TLS version is required for HTTP/3?

HTTP/3 requires TLS 1.3. With HTTP/3, security is mandatory, not optional as it was with HTTP/1.1 and HTTP/2.

13. What are replay attacks with 0-RTT?

With 0-RTT, an attacker can intercept an encrypted packet and replay it later. Sensitive operations like payments or deletions should never be performed in the first 0-RTT packet.

14. When should I use HTTP/2?

HTTP/2 is the widely adopted standard for websites and APIs today. Use it when you need modern TLS configurations and broad client compatibility.

15. When should I use HTTP/3?

HTTP/3 makes sense for mobile apps, streaming, cloud services, and scenarios with high packet loss or frequent network switches. Infrastructure support continues to grow.

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.

Back to Blog
Share:

Related Posts