HTTP and HTTPS: The Web Protocol From HTTP/1.1 to HTTP/3

The Hypertext Transfer Protocol is the application-layer protocol that powers the World Wide Web. First specified as HTTP/0.9 in 1991 — a single-line protocol that served only HTML — HTTP has evolved through HTTP/1.0 (RFC 1945), HTTP/1.1 (RFC 2616, later RFC 7230–7235, now RFC 9110–9112), HTTP/2 (RFC 7540, revised as RFC 9113), and HTTP/3 (RFC 9114). HTTPS, introduced by Netscape in 1994, layers TLS encryption underneath HTTP to provide confidentiality, integrity, and server authentication. This guide covers HTTP protocol fundamentals, the TLS security layer, protocol evolution, and operational best practices.

HTTP Fundamentals

HTTP is a request-response protocol operating over a reliable transport (typically TCP for HTTP/1.1 and HTTP/2, or QUIC for HTTP/3). It is stateless by design — each request-response exchange is independent. Stateful behavior (e.g., authenticated sessions, shopping carts) is implemented through cookies, tokens, or server-side sessions keyed by a session ID.

Request Structure

An HTTP request comprises a request line, headers, and an optional body:

GET /page.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html,application/xhtml+xml

The request line contains the HTTP method, the request target (path and query string), and the protocol version. Headers convey metadata including the target host (Host header, mandatory in HTTP/1.1), acceptable content types, authentication credentials, and cache directives.

Response Structure

A server response starts with a status line containing the protocol version, a numeric status code, and a reason phrase. Headers follow, then the response body:

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 1234
Cache-Control: public, max-age=3600

HTTP Methods

HTTP defines a set of request methods (RFC 7231, Section 4). GET retrieves a resource; it is safe (no side effects on the server) and idempotent. HEAD is identical to GET but returns only headers. POST submits data to the server, typically creating a resource; it is neither safe nor idempotent. PUT replaces a resource at a given URI; it is idempotent. PATCH applies partial modifications (RFC 5789). DELETE removes a resource. OPTIONS queries supported methods. Each method has formal semantics that intermediaries (proxies, caches) rely on. Using GET for state-changing operations breaks HTTP semantics and causes caching and indexing problems.

HTTP Status Codes

Status codes are grouped into five classes. 1xx (Informational): 100 Continue (expect the body), 101 Switching Protocols (upgrade to WebSocket). 2xx (Success): 200 OK, 201 Created, 204 No Content (success, no body). 3xx (Redirection): 301 Moved Permanently (search engines update URLs), 302 Found (temporary), 304 Not Modified (cache valid). 4xx (Client Error): 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 405 Method Not Allowed, 408 Request Timeout, 429 Too Many Requests. 5xx (Server Error): 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout. Monitoring status code ratios (e.g., 4xx-rate, 5xx-rate) is essential for application health observability.

HTTPS and TLS

HTTPS (HTTP over TLS, RFC 2818) wraps HTTP traffic in Transport Layer Security. TLS provides three guarantees: the server’s identity is verified through a digital certificate, the data payload is encrypted so intermediaries cannot read it, and a message authentication code detects tampering.

TLS 1.3 Handshake

TLS 1.3 (RFC 8446) completes in one round trip (1-RTT) for new connections and 0-RTT for returning clients. The handshake proceeds as follows: the client sends a ClientHello with supported cipher suites and a key-share extension. The server responds with its certificate, its key-share, and a Finished message. The client validates the certificate and sends its own Finished message. From this point, application data flows under encryption. TLS 1.3 removed vulnerable algorithms (RC4, 3DES, static RSA key exchange, CBC mode ciphers) and reduced handshake latency by a full round trip compared to TLS 1.2.

Certificate Authorities and Let’s Encrypt

Certificate Authorities issue X.509 certificates that bind a domain name to a public key. Browsers and operating systems ship with a set of trusted root CA certificates. Let’s Encrypt, launched in 2016, automated certificate issuance through the ACME protocol (RFC 8555) and provides free certificates with 90-day validity. As of 2025, Let’s Encrypt issues over 300 million active certificates, covering more than 60 percent of web domains that use HTTPS.

HTTP Strict Transport Security

The Strict-Transport-Security header instructs the browser to always use HTTPS for the domain, even if the user types http://. The max-age directive specifies how long the policy is in effect. The includeSubDomains flag extends protection to subdomains. Preloading (submitting the domain to browser vendor preload lists) provides protection before the first connection by hardcoding the HTTPS-only rule into the browser source.

HTTP/2

HTTP/2 (RFC 9113) introduced three major improvements over HTTP/1.1. Multiplexing allows multiple concurrent streams over a single TCP connection, eliminating HTTP/1.1’s head-of-line blocking where one slow request blocks others behind it. Header compression (HPACK, RFC 7541) reduces per-request overhead by maintaining a dynamic table of previously sent header fields, shrinking header size by approximately 85 percent on average. Server push enables the server to send resources (e.g., CSS, JavaScript) before the client explicitly requests them, though push has limited adoption due to complexity — many sites achieve better results with preload links (<link rel=preload>). HTTP/2 is binary-framed rather than text-based, making parsing more efficient for intermediaries.

HTTP/3 and QUIC

HTTP/3 (RFC 9114) replaces TCP with QUIC (RFC 9000), a transport protocol built on UDP. QUIC eliminates TCP head-of-line blocking: in HTTP/2 over TCP, a lost packet blocks all streams until retransmitted. QUIC’s streams are independent — a lost packet affects only the affected stream. QUIC also integrates the TLS handshake into the connection establishment, completing in 1-RTT for new connections and 0-RTT for resumed ones. Connection migration allows QUIC connections to survive IP address changes (e.g., switching from Wi-Fi to cellular) without reconnection. As of 2025, approximately 40 percent of web traffic uses HTTP/3 (W3Techs data), driven by adoption in Cloudflare, Google, Meta, and major CDNs.

Caching and Performance Headers

Cache-Control directives control how and for how long responses are cached by browsers and intermediaries. public allows any cache; private allows only browser caching. no-cache forces revalidation; no-store prevents caching entirely. max-age=seconds sets the freshness lifetime. The ETag header provides a validation token for conditional requests. The Last-Modified header provides a fallback date-based validator. Vary: Accept-Encoding ensures that different content encodings are cached separately. Content-Encoding: gzip or br (Brotli) compresses the response body.

Security Headers

Beyond HSTS, modern web applications send several HTTP security headers. Content-Security-Policy restricts script sources to prevent XSS attacks. X-Content-Type-Options: nosniff prevents MIME type sniffing. X-Frame-Options: DENY prevents clickjacking. Referrer-Policy: strict-origin-when-cross-origin controls referrer information leakage. Permissions-Policy disables unused browser features. These headers are widely recommended by OWASP and are tested by online scanners like securityheaders.com.

FAQ

Q: What is the difference between HTTP and HTTPS?
A: HTTPS uses TLS encryption to protect the HTTP payload. HTTP sends data in cleartext — anyone on the network path can read or modify it. HTTPS prevents eavesdropping, tampering, and impersonation.

Q: Should I use HTTP/2 or HTTP/3?
A: Use HTTP/2 unless your CDN or server platform supports HTTP/3. HTTP/3 provides better performance on unreliable networks and in mobile environments, but requires QUIC-compatible infrastructure (cloud providers and CDNs).

Q: What does the Vary header do?
A: Vary tells caches that the response varies based on request headers. Vary: Accept-Encoding ensures compressed and uncompressed versions are cached separately. Omitting Vary can cause cache servers to serve gzipped content to clients that do not support it.

Q: How does TLS 1.3 improve performance over TLS 1.2?
A: TLS 1.3 reduces the handshake from 2 round trips to 1 (1-RTT), and supports 0-RTT for returning clients. It also removes problematic cipher suites and simplifies the protocol, making implementations faster and less error-prone.

Q: What is HSTS preloading and should I use it?
A: HSTS preload adds your domain to a hardcoded list in browser source code. Users accessing your domain for the first time will use HTTPS automatically, even before any response. Submit your domain at hstspreload.org. Use it only if you are certain your site will never need plain HTTP.

Internal Links

• TCP/IP Protocol Suite Guide — how HTTP/HTTPS operate over TCP and QUIC
• CDN Guide — how CDNs accelerate HTTP traffic and terminate TLS at the edge
• Network Security Basics — deeper coverage of TLS and encryption

References

• RFC 9110, “HTTP Semantics”
• RFC 9112, “HTTP/1.1”
• RFC 9113, “HTTP/2”
• RFC 9114, “HTTP/3”
• RFC 8446, “The Transport Layer Security (TLS) Protocol Version 1.3”
• RFC 9000, “QUIC: A UDP-Based Multiplexed and Secure Transport”
• Kurose, J. F. and Ross, K. W., Computer Networking: A Top-Down Approach, 8th ed., Pearson, 2021, Section 2.2 (“HTTP and the Web”)
• Tanenbaum, A. S. and Wetherall, D. J., Computer Networks, 6th ed., Pearson, 2021, Section 7.1 (“The Application Layer”)

For a comprehensive overview, read our article on Cabling Standards.

For a comprehensive overview, read our article on Cdn Guide.

Related Concepts and Further Reading

Understanding http https requires familiarity with several interconnected ideas and principles that together form a complete picture. Exploring these related concepts deepens your knowledge and provides context that makes the core material more meaningful and applicable. Each concept builds on the others, creating a web of understanding that supports deeper learning and practical application. Taking time to explore how these elements connect reveals patterns that accelerate comprehension and retention of new information.

The relationship between http https and adjacent fields is worth particular attention. Many of the most important insights emerge at the boundaries between disciplines, where ideas from different areas combine to create new approaches and solutions that neither field could produce alone. Exploring these connections pays dividends in both breadth and depth of understanding, revealing patterns and principles that might otherwise remain hidden from view. Cross-disciplinary knowledge is increasingly valued as problems become more complex and interconnected.

For those looking to go beyond introductory material, several excellent resources provide deeper treatment of specific aspects of http https. Academic journals, industry publications, authoritative reference works, and online courses each offer different perspectives and levels of detail. The key is to match your reading to your current learning goals and build knowledge progressively, focusing on quality over quantity in your study materials. A well-chosen resource that matches your current level is worth more than dozens of resources that are too basic or too advanced.