HTTP/HTTPS & TLS

HTTP/1.1 keep-alive and pipelining, request/response structure, TLS certificate chain validation, and HTTPS security model.

Overview

Overview HTTP (Hypertext Transfer Protocol) is the application-layer protocol that underpins the web and the vast majority of API communication in modern distributed systems. Understanding it deeply — beyond just knowing that GET fetches and POST creates — is essential for building reliable, performant, and secure services.

HTTP/1.1, standardized in RFC 7230-7235, introduced persistent connections (keep-alive) as the default, allowing multiple requests to reuse a single TCP connection. This eliminated the per-request TCP handshake overhead of HTTP/1.0. Pipelining extended this by allowing a client to send multiple requests without waiting for responses, though it suffered from head-of-line blocking at the response level and was never reliably implemented in practice.

An HTTP request consists of a method, request target (URI), HTTP version, headers, an optional body, and terminates with CRLF. The response contains a status line (version + status code + reason phrase), headers, and an optional body. Status codes carry semantic meaning: 1xx informational, 2xx success, 3xx redirection, 4xx client error, 5xx server error. Knowing which codes to use and what they imply for caching, retries, and client behavior is critical for API design.

TLS (Transport Layer Security) adds encryption, authentication, and integrity to HTTP, creating HTTPS. The TLS handshake occurs after TCP connection establishment and before any HTTP data flows. It negotiates cipher suites, authenticates the server (and optionally the client) via X.509 certificates, and establishes shared symmetric keys using asymmetric cryptography.

Certificate chain validation is a critical security mechanism. The browser or client must verify that the server's certificate was signed by an intermediate CA, which was in turn signed by a trusted root CA in the client's trust store. Certificate Transparency logs, OCSP stapling, and HSTS (HTTP Strict Transport Security) are additional layers of the modern HTTPS security model.

For SREs and backend engineers, understanding connection reuse, TLS session resumption, certificate rotation without downtime, cipher suite selection, and debugging TLS errors (certificate mismatch, chain validation failures, expired certificates) are daily operational concerns.

Key concepts

HTTP Keep-Alive: HTTP/1.1 persistent connections allow multiple request/response cycles over a single TCP connection. The Connection: keep-alive header (implicit in HTTP/1.1) requests this behavior. The server may close the connection after a configurable idle timeout or max request count. Without keep-alive, each HTTP request requires a new TCP handshake (and TLS handshake for HTTPS), adding 1-3 RTTs of latency.
TLS Handshake: The TLS 1.3 handshake completes in 1 RTT. The client sends ClientHello with supported cipher suites and key shares. The server responds with ServerHello (selecting cipher and key share), its certificate, CertificateVerify (signature proving it holds the private key), and Finished. The client verifies the certificate chain and sends its own Finished. Application data can then flow. TLS 1.2 required 2 RTTs.
Certificate Chain Validation: A client validates a server certificate by building a chain from the leaf certificate to a trusted root CA. Each certificate in the chain must be signed by the next, the leaf must match the server hostname (CN or SAN), each certificate must be within its validity period, and none must appear on a CRL or OCSP revocation list. Servers must send the full chain (leaf + intermediates) since clients cannot reliably fetch intermediates themselves.
HSTS (HTTP Strict Transport Security): A response header (Strict-Transport-Security: max-age=31536000; includeSubDomains) that instructs browsers to only connect to the domain over HTTPS for the specified duration. After the first visit, the browser refuses HTTP connections without a roundtrip. HSTS preload lists (submitted to browsers) eliminate the trust-on-first-use vulnerability entirely.
OCSP Stapling: Online Certificate Status Protocol (OCSP) allows clients to check if a certificate has been revoked. Without stapling, the client must make a separate HTTP request to the CA's OCSP responder for every TLS connection, adding latency and privacy concerns. With OCSP stapling, the server fetches and caches the OCSP response and includes (staples) it in the TLS handshake, eliminating the client round-trip.
mTLS (Mutual TLS): Standard TLS authenticates only the server. In mTLS, both parties present X.509 certificates. The client sends its certificate during the handshake; the server validates it against a trusted CA. mTLS provides strong service-to-service authentication and is commonly used in service meshes (Istio, Linkerd), zero-trust architectures, and API gateways to replace bearer tokens for inter-service calls.

When to use it

Debugging connection latency and determining how many TLS handshakes are occurring per unit time
Configuring nginx or HAProxy TLS termination with appropriate cipher suites and certificate chains
Rotating TLS certificates without dropping active connections
Implementing mTLS (mutual TLS) for service-to-service authentication in a microservices environment
Diagnosing HTTPS errors in curl or browser: certificate mismatch, chain incomplete, HSTS violations
Understanding why a CDN or load balancer shows a different certificate than the origin

Interview questions

Describe the full sequence of events from when a user types https://example.com in their browser to when the first byte of HTML is received.
How does TLS certificate chain validation work, and what are the failure modes you see in production?
What is HSTS and how does it protect against downgrade attacks?

HTTP/HTTPS & TLS

Overview

Key concepts

When to use it

Interview questions

More Networking topics