1. HTTP Versions

Understanding HTTP versions

HTTP has evolved through multiple versions since its creation, each introducing improvements in performance, security, and functionality. The primary versions are HTTP/0.9, HTTP/1.0, HTTP/1.1, HTTP/2, and HTTP/3.

HTTP/0.9 (1991)

The very first version of HTTP was released in 1991, and developed for early web browsers and serv- ers. It was a simple text-based protocol and only supported the GET method for retrieving HTML files. It didn’t support HTTP headers, meaning there was no metadata like content type, status codes, or content length exchanged between the client and server. It had no support for multimedia like images, scripts, or different content types, and the connection closed after each request.

HTTP/1.0 (1996)

This was the first official version of HTTP, standardized by the IETF in RFC 1945. It introduced support for metadata through headers, including Content-Type and Content-Length. It introduced methods like GET, POST, and HEAD, and status codes like 200 OK and 404 Not Found.

A separate connection for each request made HTTP/1.0 inefficient and slow for complex web pages, where multiple resources are needed. It didn’t define proper caching mechanisms, making every resource retrieval start from scratch, impacting performance.

HTTP/1.1 (1997, updated in 1999)

Standardized in RFC 2068 (and updated in RFC 2616), HTTP/1.1 brought many improvements over HTTP/1.0 and became the most widely used version for over a decade.

Some of its key features include the following:

• Persistent connections:
  • Allowed the reuse of the same TCP connection for multiple requests and responses, reducing overhead.
• Chunked transfer encoding:
  • Enabled servers to send data in chunks, which is especially useful for streaming and large files.
• More methods:
  • Added methods like OPTIONS, PUT, DELETE, TRACE, and CONNECT.
• Improved caching:
  • Introduced cache-control mechanisms through headers like ETag, Cache- Control, and Last-Modified, allowing better control over caching.
• Content negotiation:
  • Servers could serve different versions of resources based on the client’s capabilities like language or format preferences.

HTTP/2 (2015)

HTTP/2 (based on Google’s SPDY protocol) was standardized in RFC 7540, offering major performance improvements to address the inefficiencies of HTTP/1.1.

Some of its key improvements include the following: - Multiplexing: - Multiple requests and responses can be sent over a single TCP connection con- currently, eliminating head-of-line blocking and the need for multiple connections.

• Header compression:
  • Uses HPACK header compression to reduce the overhead caused by large HTTP headers, improving performance for repeated requests.
• Binary framing:
  • HTTP/2 uses a binary format instead of the text-based format of HTTP/1.x, making it more efficient to parse and transfer data.
• Stream prioritization:
  • Clients can assign different priorities to streams, allowing the most important resources (like HTML) to be loaded first.
• Improved security:
  • While not mandatory, HTTP/2 is often implemented over TLS (though it can also be used over plain TCP).

HTTP/2 dramatically reduces latency, improves page load speed due to multiplexing, and reduces overhead through header compression and persistent connections.

HTTP/3 (2020)

HTTP/3, based on Google’s QUIC (Quick UDP Internet Connections) protocol, was standardized in RFC 9114. It represents a significant departure from previous versions by shifting from TCP to UDP.

Some of its key features include the following:

• Uses QUIC over UDP:

  • Instead of relying on TCP, HTTP/3 uses QUIC, which is based on UDP, to improve latency and reliability.

• Eliminates TCP head-of-line blocking:

  • By leveraging QUIC’s stream multiplexing, each stream is independent. Packet loss in one stream does not block others, unlike TCP-based HTTP/2.

• Zero Round-Trip Time (0-RTT) handshakes:

  • QUIC allows faster connections by reducing the number of round trips needed to establish a secure connection, significantly speeding up initial request times.

• Built-in encryption:

  • HTTP/3 is always encrypted using TLS 1.3, meaning there is no unen- crypted HTTP/3.

• Stream multiplexing:

  • Similar to HTTP/2, but without the same head-of-line blocking issues at the transport layer.

• Faster connection recovery:

  • If a connection drops, QUIC can recover without re-establishing the entire connection, improving resilience on unreliable networks.

  The benefits of HTTP/3 include faster page loads and more resilient connections, especially over poor network conditions like mobile or wireless connections. It has reduced latency compared to HTTP/2, particularly for secure connections.

  Since HTTP/3 uses UDP, it may face deployment issues in networks with firewalls or middleboxes that restrict UDP traffic. While HTTP/3 is rapidly being adopted (especially by major CDNs like Cloudflare), it still isn’t as universally supported as HTTP/2.

Reference

Real-World Web Development with .NET 9