HTTP, HTTPS and TLS

1The core idea#

HTTP is a request/response protocol, and the model is small on purpose.

• The client sends: a method, a path, some headers, maybe a body.
• The server sends back: a status code, some headers, maybe a body.
• It is stateless by design. The server does not remember you between requests unless you hand it something to remember you by, like a cookie or a bearer token.

The mental model I give juniors.

• HTTP is the letter: it defines what the bytes mean.
• TCP is the postal service that delivers the bytes.
• TLS is the sealed, tamper-proof envelope you put the letter in.
• HTTP does not care how the bytes get there.

HTTPS is not a separate protocol. It is HTTP running inside a TLS tunnel.

• Same methods, same status codes, same headers.
• Before any HTTP flows, the client and server do a TLS handshake to agree on encryption keys.
• After that, every HTTP byte is encrypted on the wire.
• A network sniffer sees ciphertext and the destination IP, not your passwords or your API payloads.

TLS gives you three things, and naming them separately matters:

• Confidentiality: nobody on the path can read your traffic.
• Integrity: nobody can silently modify it. Flip a bit and the receiver detects it and tears down the connection.
• Authentication: you are actually talking to the server you think you are, proven by a certificate signed by a trusted Certificate Authority.

2How it works#

Walk through what actually happens when a browser loads https://api.example.com. The order is the whole point.

• DNS resolves the hostname to an IP.
• TCP does its three-way handshake (SYN, SYN-ACK, ACK) to open a connection: one round trip.
• TLS negotiates keys: one more round trip on TLS 1.3, two on the older TLS 1.2.
• Only after all of that does the first HTTP request go out.

The TLS handshake is where the clever part lives.

• The client sends a ClientHello: the cipher suites and TLS versions it supports, plus a random number.
• The server picks a cipher suite, sends its certificate chain, and sends its own random.
• Both sides run an ephemeral Diffie-Hellman key exchange to derive a shared secret that was never sent over the wire.
• Record all the traffic, later steal the server's private key, and you still cannot decrypt old sessions. That property is forward secrecy, and it is the default in TLS 1.3.

The certificate is the trust anchor.

• The server's cert is signed by an intermediate CA, which is signed by a root CA your OS or browser already trusts.
• The client walks that chain up to a root it recognizes.
• It checks the domain name matches, checks the expiry, checks revocation.
• Any link fails and you get that scary browser warning.

Now the versions, because this is where the real system design decisions live:

• HTTP/1.1: one request at a time per connection. Browsers worked around it by opening six connections per host. Request two waits for request one to finish: head-of-line blocking at the application layer.
• HTTP/2: multiplexing. Many concurrent streams over a single TCP connection, plus header compression (HPACK). Solves application-layer head-of-line blocking. But it still rides one TCP connection, so a single lost packet stalls all streams at the TCP layer. That is TCP-level head-of-line blocking.
• HTTP/3: runs over QUIC, which runs over UDP, not TCP. QUIC builds in its own streams, so a lost packet only stalls the one stream that needed it. QUIC also folds the transport and TLS handshakes together, so a fresh connection is one round trip instead of two, and reconnections can be zero round trips.

3A worked example: why Singapore users wait 720ms for a Virginia API#

This is the number I want you to be able to produce on a whiteboard.

• A user in Singapore hits an API served only from us-east-1 (Virginia).
• Round-trip time between the two is about 180ms.
• The user makes a fresh HTTPS connection over HTTP/2 to a TLS 1.2 origin.
• Count the round trips before the first response byte arrives.

Three quarters of a second, and the app has not rendered anything yet. Now apply two fixes and watch the number fall.

Fix 1: terminate TLS at a CDN edge 10ms from the user.

• The user now does its TCP and TLS handshakes against an edge POP at 10ms RTT, not Virginia at 180ms.
• That is 1 + 2 = 3 round trips at 10ms, so 30ms of handshake.
• The edge already holds a warm, pooled HTTP/2 connection to origin, so the origin leg is a single 180ms round trip with zero handshake tax.
• Time to first byte drops to roughly 30 + 180 = 210ms.

Fix 2: move the edge to TLS 1.3.

• The handshake at the edge is now 1 round trip instead of 2, so 2 round trips total at 10ms = 20ms.
• On a resumed connection with 0-RTT, the handshake is effectively free.
• Time to first byte against a warm edge sits near 190ms, bounded by the one origin round trip.

4Trade-offs#

Start with the one every interviewer wants to hear you get right.

Keep-alive and connection pooling: the single biggest latency win.

• Open a brand-new TLS connection for every outbound call and you pay 2 to 3 round trips of overhead every time.
• Across a region that is 100 to 300ms of pure handshake tax per call.
• Pool your connections and reuse them.
• For a service making millions of internal calls, this is the difference between a snappy p99 and a miserable one.

HTTP/2 to the backend: careful at the load balancer.

• HTTP/2's single-connection model is great for browsers but can bite you at a load balancer.
• A client holding one long-lived HTTP/2 connection, balanced at the connection level, pins all its traffic to one backend.
• You usually want per-request balancing, which means the proxy terminates HTTP/2 and re-dispatches each stream.

TLS termination: where do you decrypt?

• At the edge: the load balancer decrypts and talks plaintext internally. Centralizes cert management, offloads crypto from app servers, but your internal network now carries plaintext.
• End to end: TLS all the way to the service. Safer in a zero-trust or multi-tenant environment, where you re-encrypt internally or use mTLS between services.
• The cost of end to end: more cert rotation machinery and a bit more CPU everywhere.

0-RTT in TLS 1.3 and QUIC: fast, but with a sharp edge.

• You can send application data in the very first packet on a resumed connection, saving a round trip (about 180ms in the Singapore example).
• The catch: 0-RTT data is replayable by an attacker.
• So you only put idempotent requests in 0-RTT. A GET for a product page, fine. A POST that charges a card, never.

5Where it is used#

Everywhere, but the shape changes with the layer.

• Public web and mobile APIs: HTTPS is mandatory. Browsers mark plain HTTP as "not secure," and features like service workers and HTTP/2 only work over TLS. You will almost always terminate TLS at a CDN or load balancer.
• CDNs: a CDN terminates TLS close to the user, cutting handshake round trips dramatically because the user is 10ms away instead of 180ms. It then talks a warm, pooled, often HTTP/2 connection back to origin. This is exactly the fix from the worked example.
• Service-to-service inside a datacenter: weigh raw speed against trust boundaries. Many large systems run mTLS between every service via a service mesh sidecar, so identity is cryptographic, not based on "it came from inside the network."
• Streaming and real-time: HTTP/3's connection migration is a real win for mobile. When a phone switches from WiFi to cellular its IP changes. A TCP connection dies and must be rebuilt (another 4 round trips of handshake); a QUIC connection carries a connection ID that survives the IP change, so the stream continues without a new handshake.

When would you not reach for HTTP?

• Need persistent bidirectional push: move up to WebSockets (which still start life as an HTTP upgrade request).
• Need streaming RPC: gRPC streaming over HTTP/2.
• Very high-throughput internal RPC: gRPC over HTTP/2 with protobuf is a common default because it is binary, multiplexed, and strongly typed.

6Common pitfalls and gotchas#

Expired or misconfigured certificates.

• The classic outage. A cert expires at 2am, pagers go off, half your traffic 500s.
• Automate renewal and alert well before expiry, say 30 days out.
• I have seen a billion-dollar product go dark because one cert lapsed.

Sending the wrong intermediate chain.

• Your leaf cert is valid but you forgot to serve the intermediate.
• Some clients cache the intermediate and work; others fail. It passes in your browser and fails for a fraction of users.
• Test with a fresh client, not your dev laptop that already trusts everything.

Treating HTTP methods as suggestions.

• GET must be safe and idempotent. A GET that mutates state gets quietly corrupted by a prefetcher or a retry.
• PUT and DELETE should be idempotent so a client can safely retry after a timeout.
• POST is the one that is not, which is exactly why 0-RTT and blind retries are dangerous for it.

Retrying non-idempotent requests.

• A client times out waiting for a POST response, but the server actually processed it.
• The client retries, you charge twice.
• The fix is an idempotency key the server deduplicates on, not hoping the network behaves.

Mixed content.

• An HTTPS page that pulls a script over plain HTTP.
• Browsers block it, and an attacker could have swapped that script anyway.
• Everything on a secure page must be secure.

Forgetting that TLS hides the body, not the destination.

• The server IP and, historically, the SNI hostname are visible on the wire.
• People assume HTTPS means total invisibility. It does not.
• It means confidentiality of content and proof of who you are talking to.

7How it shows up in interviews#

Interviewers rarely ask "what is HTTPS" as a standalone question. It surfaces inside a bigger design: "design an image hosting service," "design a payment flow," "why is this API slow from Singapore." They are checking whether you reason about the network, not just the app logic.

Here is what separates strong from weak answers.

• On latency. Weak: "we use HTTPS for security." Strong: "every new HTTPS connection from Singapore to Virginia costs a TCP handshake plus a TLS 1.2 handshake, about 4 round trips at 180ms RTT, so roughly 720ms before data flows. I would terminate TLS at a CDN edge 10ms from the user and keep warm pooled HTTP/2 connections to origin, which drops time to first byte to around 190ms."
• On versions. Weak: "use the latest HTTP version." Strong: "HTTP/2 multiplexing lets the browser avoid six connections, but it still suffers TCP head-of-line blocking on packet loss, so for lossy mobile networks HTTP/3 over QUIC is worth it, and it survives WiFi-to-cellular handoff via connection migration."
• On where to terminate TLS. Weak: "the load balancer handles TLS." Strong: "I terminate at the edge for central cert management and CPU offload, but since internal traffic is sensitive and multi-tenant, I re-encrypt with mTLS between services so identity is cryptographic, not perimeter-based."
• On idempotency and retries. This is the one that quietly reveals seniority. Bring up idempotency keys unprompted on a write path over HTTP and interviewers notice. It tells them you have debugged a real double-charge.

Treat HTTP as a system with costs and failure modes, not a magic pipe. Know where the round trips are, and do the handshake arithmetic out loud.

Want to see this applied end to end? Try the System Design Question walkthrough on designing a low-latency global API, where connection reuse and edge TLS termination decide whether you hit your p99 target.