Deep Thought

Http Versions

4 min read

🌐 HTTP/1.1

Released: 1997
Transport: TCP

✔️ Key Features

  • Plain text protocol
  • One request per TCP connection (unless using keep-alive)
  • No multiplexing → only one request in flight at a time
  • Head-of-line (HOL) blocking at the application layer
  • Responses must complete in order.

✔️ What goes over the wire?

  • ASCII headers (GET /path HTTP/1.1)
  • Body (optional)
  • Chunked encoding for streaming
  • TCP retransmissions if packets are lost

✔️ Where it can be used

  • Everywhere — browsers, servers, IoT — it’s universal.
  • Excellent compatibility; all proxies/firewalls understand it.

✔️ Best suited for

  • Simplicity
  • High compatibility environments
  • Systems with old networking gear
  • Simple REST APIs

❌ Limitations

  • Major performance bottlenecks for parallel requests
    (browsers open 6–10 TCP connections per domain to compensate)
  • Latency sensitive due to TCP’s strict ordering

🌐 HTTP/2

Released: 2015
Transport: Still TCP — but with a totally different framing layer.

✔️ Key Features

  • Binary framing
  • Multiplexing: many parallel streams over one TCP connection
  • Header compression (HPACK)
  • Server push (used very little today; removed in HTTP/3)
  • Much more efficient use of a single TCP connection

✔️ What goes over the wire?

  • Binary frames, not plain text
  • Stream IDs
  • Prioritization signals (rarely well-used)

Examples of frames:

  • HEADERS
  • DATA
  • SETTINGS
  • RST_STREAM
  • WINDOW_UPDATE (flow control)

✔️ Where it is used

  • Browsers: all major browsers support HTTP/2 for TLS connections
    (HTTP/2 without TLS is almost never used)
  • gRPC: standard gRPC requires HTTP/2
  • Modern REST APIs: significant performance boost for multiple small requests
  • Server-to-server communication

✔️ Best suited for

  • Microservices calling each other frequently
  • gRPC
  • Streaming APIs
  • High request concurrency
  • Performance-sensitive applications

❌ Limitations

  • Still built on TCP, so:
    • Packet loss affects all streams (TCP head-of-line blocking)
    • Mobile networks can suffer

🌐 HTTP/3 (QUIC)

Released: 2022
Transport: QUIC, built on UDP
(But QUIC is not “just UDP” — it is a full transport layer.)

✔️ Key Features

  • UDP-based, but fully reliable transport
  • Eliminates TCP head-of-line blocking
  • Connection migration (keep the connection alive when switching networks/WiFi)
  • Faster connection setup (TLS handshake built into QUIC)
  • Stream-based like HTTP/2, but without TCP’s blocking issues

✔️ What goes over the wire?

  • QUIC packets containing:
    • Encrypted stream frames
    • Acknowledgement frames
    • Cryptographic handshake data (TLS 1.3 integrated)
  • Always encrypted; no plaintext mode

✔️ Where it is used

  • Modern browsers (Chrome, Firefox, Edge, Safari)
  • CDNs (Cloudflare, Fastly)
  • Some HTTP servers: nginx, cloudflare, ASP.NET Core (from .NET 7)

Increasingly used for:

  • Media streaming
  • Real-time apps
  • Mobile-friendly APIs

✔️ Best suited for

  • Unstable network links (mobile, cross-country)
  • Low-latency, high-load APIs
  • Future-proofing services
  • Potentially: next-generation gRPC (gRPC over HTTP/3)

❌ Limitations

  • Not all corporate firewalls allow QUIC/UDP
  • Still newer; some server stacks have incomplete or experimental support
  • No support for server push (removed intentionally)

🏁 Summary Table: HTTP 1.1 vs 2 vs 3

FeatureHTTP/1.1HTTP/2HTTP/3 (QUIC)
TransportTCPTCP + binary framesQUIC (UDP-based)
Multiplexing❌ No✔ Yes✔ Yes
HOL Blocking✔ Application-level✔ TCP layer❌ Avoided
Header compressionMinimalHPACKQPACK
Encryption required?NoYes (in browsers)Yes (always)
Browser support✔ Full✔ Full✔ Growing, widely deployed
Server-to-server suitability✔ Good✔ Excellent✔ Excellent (if QUIC works in environment)
gRPC support❌ No✔ Required✔ Supported in .NET 7–9 (experimental in earlier)
gRPC-Web support✔ Yes✔ Yes✔ Yes
Mobile performancePoorMediumExcellent

🧭 Which protocol should I use on my server?

✔ General REST APIs

  • Prefer HTTP/2
  • Also support HTTP/1.1 for compatibility
  • Optionally expose HTTP/3 for clients that can use it

✔ gRPC server

  • Must support HTTP/2
  • Can optionally support HTTP/3
  • Should also support gRPC-Web if you have browser clients

Recommended config:

  • HTTP/2 for native gRPC clients
  • HTTP/1.1 + HTTP/2 for gRPC-Web (browser)
  • HTTP/3 optional for advanced clients

✔ Browser apps (Blazor WASM, React, Angular, etc.)

Cannot use real gRPC-over-HTTP/2. Your options:

✔ For browser-to-server APIs

  • REST ⇒ HTTP/1.1 or HTTP/2 or HTTP/3
  • gRPC-Web ⇒ HTTP/1.1 or HTTP/2
  • WebSockets ⇒ custom streaming

Browser automatically negotiates protocol; you cannot force raw HTTP/2 APIs beyond fetch/XHR.

❌ Cannot do:

  • Real gRPC over HTTP/2
  • Real gRPC over HTTP/3 (yet)

✔ Internal microservices / backend-to-backend

Use HTTP/2 (or HTTP/3 if fully supported in your environment):

  • Best for concurrency
  • Best for gRPC
  • Eliminates connection juggling

✔ High-latency / mobile networks

Use HTTP/3 (QUIC) if available:

  • Loss recovery is superior to TCP
  • Better for long-lived connections (streaming, real-time)
  • Much faster reconnection on network switching

🎯 Final Recommendations (Practical)

On your server, expose:

  • HTTP/1.1 → fallback for all clients, proxies
  • HTTP/2 → for efficient REST + required for gRPC
  • HTTP/3 → modern clients, better mobile performance

There’s almost no downside to supporting all three.

Graph View