Networking Essentials: DNS, TLS, HTTP/2 vs HTTP/3, WebSockets vs SSE
Definition
DNS maps human-readable names to IP addresses (and other records). Resolution is hierarchical, cached at multiple layers (OS stub resolver, TTL, CDN DNS, authoritative servers). CNAME vs A/AAAA matters for apex domains, latency, and failover patterns.
TLS provides confidentiality and integrity on top of TCP (historically). A simplified handshake (TLS 1.2 style intuition): client hello → server hello + certificate → key exchange → session keys → encrypted application data. TLS 1.3 reduces round trips; mTLS adds client certificates for service-to-service trust.
HTTP/2 — Multiplexed streams over one TCP connection, header compression (HPACK), server push (declining in practice). Head-of-line blocking at TCP still possible if a packet is lost (all streams share the connection).
HTTP/3 — Runs over QUIC (UDP-based), connection IDs help mobile roaming, integrated TLS 1.3, loss on one stream does not block others like TCP HOL blocking for multiplexing. Better tail latency on lossy networks; middlebox / corporate firewall quirks historically existed but adoption grew.
WebSockets — Full-duplex persistent TCP channel after HTTP upgrade; great for bidirectional low-latency (chat, games, collaborative editing).
Server-Sent Events (SSE) — One-way server→client over HTTP, browser EventSource, automatic reconnect with Last-Event-ID; simpler for notifications, live feeds when client mostly receives.
Why it matters in interviews
You should explain why mobile apps feel flaky (DNS + TCP + TLS RTTs), when to pick gRPC/HTTP2 vs REST, and real-time transport choices without buzzwords. Security and edge (CDN, WAF) discussions hook here.
Tradeoffs
- HTTP/2 — Efficient single connection; TCP head-of-line risk.
- HTTP/3 — Better on lossy networks; operational UDP considerations.
- WebSockets — Stateful connections harder to scale (sticky routing, more memory); SSE easier for fan-out from server but one-way.
Concrete examples
- Global SaaS — GeoDNS routes to nearest region; TTL and health checks determine failover speed—bad TTL → stale routing after outage.
- Public API — TLS 1.2+ required; certificate rotation via ACME; internal mesh uses mTLS (SPIFFE/Istio-style) for service identity.
- Live dashboard — SSE for stock ticks to browsers (simple HTTP infra); WebSockets when the server must receive frequent client events with low overhead.
How to say it in 30 seconds
"DNS is cached and affects failover speed. TLS costs round trips—we minimize with 1.3 and session resumption. HTTP/2 multiplexes on TCP; HTTP/3 uses QUIC to fix TCP head-of-line on loss. For live updates, SSE if server→client suffices; WebSockets if we need duplex chat-style."
Common follow-up questions
- Why not WebSockets for everything? Stateful connection costs, LB complexity, HTTP/2 streaming may suffice.
- Difference between gRPC and REST over HTTP/2? gRPC uses HTTP/2 framing + protobuf; strong streaming model—still TCP/TLS stack concerns unless gRPC over QUIC configs.
- What is DNS prefetch / HTTP DNS? Optimizations to cut first-byte latency on mobile—sometimes bypass flaky resolvers.
Cross-links (building blocks)
- CDN, API gateway, load balancer, and service mesh sit at these layers—see System design curriculum overview.
See also: System design curriculum overview
Last updated on
Spotted something unclear or wrong on this page?