Network Essentials

Every system design decision about latency, reliability, and scalability ultimately rests on how networks work. This page covers the networking layer from the ground up — from how a hostname resolves to an IP address, to the protocol choices that define an API's performance characteristics.

DNS & IP

Every request on the internet starts with two questions: where am I going? (DNS) and how do I get there? (IP).

IP addresses

An IP address uniquely identifies a device on a network. IPv4 addresses are 32-bit integers written as four dot-separated octets (142.250.80.46), giving roughly 4 billion unique addresses — a number the internet long ago exhausted. IPv6 addresses are 128-bit, written in eight colon-separated hexadecimal groups (2001:0db8:85a3::8a2e:0370:7334), providing a practically unlimited address space.

There are also private IP ranges that are not routable on the public internet — used inside data centres and home networks:

1. 10.0.0.0/8 — 16 million addresses, common in cloud VPCs
2. 172.16.0.0/12 — used by Docker and Kubernetes clusters
3. 192.168.0.0/16 — home routers and office LANs

DNS — the internet's phone book

DNS (Domain Name System) translates human-readable hostnames like api.example.com into IP addresses that routers understand. Resolution happens in four hops when the answer is not already cached:

1. Recursive resolver — your ISP or a public resolver (1.1.1.1, 8.8.8.8). It does the legwork on your behalf and caches results.
2. Root nameserver — knows which nameserver is authoritative for each TLD (.com, .org, etc.). There are 13 root server clusters worldwide.
3. TLD nameserver — knows which nameserver is authoritative for each domain under the TLD.
4. Authoritative nameserver — the final source of truth. Returns the actual IP address.

DNS record types

TTL (Time To Live) controls how long resolvers cache a record. A low TTL (60 s) lets you change IP addresses quickly during migrations or failovers. A high TTL (86,400 s) reduces lookup latency but means changes propagate slowly across the internet.

TCP vs UDP

Both are transport-layer protocols that sit on top of IP. They answer how data is broken into packets and reassembled at the destination — but they make opposite trade-offs between reliability and speed.

TCP — reliability first

TCP (Transmission Control Protocol) establishes a connection before sending data via the three-way handshake (SYN → SYN-ACK → ACK), guarantees that every packet arrives in order, and automatically retransmits anything that is lost. The cost is latency — the handshake and per-segment acknowledgements add overhead that makes TCP unsuitable when speed matters more than correctness.

UDP — speed first

UDP (User Datagram Protocol) fires packets with no handshake, no ordering guarantee, and no retransmission. Some packets may arrive out of order or not at all — UDP does not care. This makes it faster and better suited for real-time applications where a late packet is worse than a dropped one.

HTTP/3 (QUIC) bridges the gap: it runs over UDP but reimplements reliability at the application layer, gaining multiplexed streams without head-of-line blocking and eliminating TCP's connection-setup round trip.

HTTP & HTTPS

HTTP (HyperText Transfer Protocol) is the application-layer protocol that powers the web. Every browser request, REST API call, and webhook notification is an HTTP message. It follows a simple request → response model: the client sends a request with a method, a path, headers, and an optional body; the server returns a status code, headers, and an optional body.

HTTP methods

HTTP status codes

HTTPS

HTTPS is HTTP tunnelled through a TLS connection. The data is encrypted in transit so that neither the network nor any intermediary can read or tamper with it. Today HTTPS is not optional — browsers mark HTTP sites as insecure, search engines penalise them, and many APIs refuse plaintext connections entirely. TLS is covered in detail in the section below.

Key headers

1. Content-Type — the media type of the body (application/json, text/html). The server uses this to know how to parse a request body; the client uses it to know how to render a response.
2. Authorization — carries credentials. Most commonly Bearer <token> for JWT-based auth or Basic <base64> for username:password.
3. Cache-Control — tells browsers and CDNs how long to cache a response. max-age=3600 caches for one hour; no-store prevents caching entirely.
4. ETag — a version fingerprint of the resource. The client sends it back in subsequent requests as If-None-Match; if the resource has not changed the server returns 304 Not Modified — no body, no bandwidth wasted.
5. X-RateLimit-* — communicates rate limiting state to the client: remaining quota, reset time, and limit ceiling.

HTTP/1.1 vs HTTP/2 vs HTTP/3

HTTP has evolved substantially since its origin. Each version addresses the performance bottlenecks of its predecessor.

HTTP/1.1 (1997)

Introduced persistent connections (keep-alive) so the TCP connection is reused across multiple requests — previously each request required a new TCP handshake. However, requests are still serialised within a single connection: the server must finish responding to request N before starting request N+1 on the same connection. This is called head-of-line (HoL) blocking. Browsers work around it by opening 6–8 parallel connections per hostname — wasteful but effective.

HTTP/2 (2015)

HTTP/2 introduces multiplexing: multiple requests and responses are interleaved on a single TCP connection as independent streams, each with a numeric ID. HoL blocking at the HTTP layer is eliminated — a slow response on stream 3 does not block stream 5. Other improvements:

1. Header compression (HPACK) — headers are compressed and delta-encoded across requests, reducing overhead significantly (headers are often larger than the body for API calls).
2. Server push — the server can proactively send resources the client will need before the client requests them.
3. Binary framing — the protocol is binary rather than text, making parsing faster and more compact.

HTTP/2 still runs over TCP, so HoL blocking at the TCP layer remains: if a single packet is lost, the entire connection stalls waiting for retransmission.

HTTP/3 (2022)

HTTP/3 replaces TCP with QUIC — a transport protocol built on UDP that reimplements reliability per-stream. A lost packet only blocks the stream it belongs to, not the entire connection. This eliminates TCP-level HoL blocking. Additional benefits:

1. 0-RTT handshake — for returning connections, QUIC can send data in the very first packet, eliminating the TCP + TLS handshake round trips.
2. Connection migration — QUIC connections are identified by a connection ID rather than a 4-tuple of IP + port, so switching from Wi-Fi to mobile data does not break the connection.

TLS / SSL

TLS (Transport Layer Security) is the cryptographic protocol that secures HTTP connections — making them HTTPS. SSL (Secure Sockets Layer) is TLS's predecessor and the name is still used colloquially, but all modern systems use TLS 1.2 or 1.3. TLS provides three guarantees:

1. Confidentiality — data is encrypted; no eavesdropper can read it.
2. Integrity — data cannot be modified in transit without detection.
3. Authentication — the server proves it owns the domain via a certificate signed by a trusted Certificate Authority (CA).

The TLS handshake (TLS 1.3)

1. ClientHello — client sends supported TLS versions, cipher suites, and a random value. In TLS 1.3 it also sends key share material speculatively.
2. ServerHello — server confirms version and cipher, sends its key share and its certificate (containing the server's public key).
3. Certificate validation — client verifies the certificate was signed by a trusted CA and that the hostname matches.
4. Session keys derived — both sides independently compute the same symmetric session key from the exchanged material. All subsequent data is encrypted with this key.

TLS 1.3 completes this in 1 RTT (vs 2 RTT for TLS 1.2). For returning clients, session resumption allows 0-RTT — the client sends data immediately in the first packet.

Certificates and CAs

A TLS certificate is a document that binds a public key to a domain name, signed by a Certificate Authority the browser trusts. The chain of trust: browser trusts a root CA → root CA signs an intermediate CA → intermediate CA signs the server's certificate. This chain is validated on every connection. Services like Let's Encrypt issue free certificates automatically, making HTTPS essentially zero-cost to deploy.

TLS termination

In most production systems, TLS is terminated at the load balancer or reverse proxy (Nginx, Cloudflare, AWS ALB) rather than at the application server. Backend communication travels over the private network in plain HTTP. This centralises certificate management and reduces CPU overhead on application servers, since TLS is computationally expensive to encrypt and decrypt.

WebSockets & Long Polling

Standard HTTP is half-duplex and request-driven — the server can only send data when the client asks for it. For real-time features (chat, live notifications, multiplayer games, collaborative editing), you need a way for the server to push data to the client without waiting for a poll. There are several approaches, each with different trade-offs.

Short polling

The client repeatedly sends HTTP requests on a fixed interval (e.g. every 2 seconds) and checks for new data. Simple to implement but wasteful — most responses are empty, and latency is at best equal to the polling interval.

Long polling

The client sends a request and the server holds it open until new data is available (or a timeout occurs). When the server responds, the client immediately opens a new request. This reduces empty responses and improves latency compared to short polling, but each "push" still requires a full HTTP round trip and holds a server thread/connection open.

Server-Sent Events (SSE)

The server streams a continuous HTTP response using the text/event-stream content type. The connection stays open and the server pushes newline-delimited events whenever they occur. SSE is unidirectional(server → client only), simpler than WebSockets, and works natively with HTTP/2 multiplexing. Good for live feeds, progress updates, and dashboards.

WebSockets

WebSockets upgrade an HTTP connection into a persistent, full-duplex TCP channel. After the upgrade handshake (HTTP 101 Switching Protocols), both client and server can send frames at any time with minimal overhead — no HTTP headers on each message. This makes WebSockets ideal for low-latency bidirectional communication.

1. Use cases — chat applications, multiplayer games, collaborative editing (Figma, Google Docs), live trading dashboards, real-time notifications.
2. Trade-offs — persistent connections consume server resources (memory, file descriptors). At scale you need connection management infrastructure — a dedicated WebSocket gateway (often separate from the HTTP API servers) and a pub/sub layer (Redis pub/sub, Kafka) to fan out messages to the correct connections.
3. Statefulness — each WebSocket connection is stateful and tied to a specific server instance. Load balancers must use sticky sessions or the connection layer must be centralised.

WebRTC

WebRTC (Web Real-Time Communication) is a browser-native API and protocol suite that enables peer-to-peer audio, video, and arbitrary data transfer directly between browsers — without a media server in the middle. Once the connection is established, media flows directly from peer to peer, giving it latency characteristics that no server-proxied solution can match.

The three core APIs

1. RTCPeerConnection — manages the full peer connection lifecycle: codec negotiation, ICE candidate gathering, DTLS handshake, and the actual media/data transport.
2. RTCDataChannel — a bidirectional channel for arbitrary binary or text data, similar to a WebSocket but over the P2P connection. Used for file transfer, game state, collaborative editing cursors.
3. MediaStream — captures audio/video from the camera, microphone, or screen and feeds it into an RTCPeerConnection as tracks.

How a connection is established

WebRTC separates signalling (how two peers find and describe each other) from transport (how media actually flows). The signalling channel is out-of-scope for the spec — you bring your own (WebSocket, HTTP, even email). The connection setup follows this flow:

1. Offer / Answer (SDP) — the caller creates an SDP (Session Description Protocol) offer describing its media capabilities (codecs, resolution, bandwidth). The callee generates an answer. Both are exchanged via the signalling channel. SDP negotiation agrees on a common codec and format for the session.
2. ICE candidate gathering — each peer runs the ICE (Interactive Connectivity Establishment) process to discover all possible network paths it can be reached on: local interface addresses, NAT-translated addresses (via STUN), and relay addresses (via TURN). These candidates are also exchanged over the signalling channel.
3. ICE connectivity checks — peers probe candidate pairs to find a working path. The best working pair (direct if possible, relayed if not) is selected.
4. DTLS handshake — once a transport path is confirmed, peers run a DTLS (Datagram TLS) handshake to establish encryption. Media is then encrypted with SRTP on top of the selected path.

NAT traversal: STUN and TURN

Most peers sit behind NAT — their public IP differs from their private IP. WebRTC uses two server-assisted mechanisms to deal with this:

1. STUN (Session Traversal Utilities for NAT) — a lightweight server that simply reflects the caller's public IP and port back to them. The peer includes this as an ICE candidate. Works for most NAT types (full-cone, restricted-cone) and costs almost no bandwidth since it is only used during setup.
2. TURN (Traversal Using Relays around NAT) — a relay server that both peers connect to when direct P2P fails (symmetric NAT, strict firewalls). Media is routed through the TURN server rather than directly. This always works but adds latency and server bandwidth cost. Roughly 15–20% of WebRTC sessions fall back to TURN.

Mesh vs SFU vs MCU (multi-party calls)

P2P works well for two participants. For group calls, three architectures exist:

1. Mesh — every participant connects directly to every other. No server required for media, but upload bandwidth grows as O(n) per peer — impractical beyond ~4 participants.
2. SFU (Selective Forwarding Unit) — each participant sends one stream to the server; the server selectively forwards streams to recipients without decoding them. Scales to tens of participants. Each client still decodes N incoming streams. Used by most modern video conferencing products (Daily, Whereby, Agora).
3. MCU (Multipoint Control Unit) — the server decodes all incoming streams, composites them into a single mixed stream, and sends one stream to each participant. Minimal client bandwidth but very high server CPU cost. Used for legacy telephony bridges.

WebRTC vs WebSockets

REST vs GraphQL vs gRPC

The API protocol defines the contract between client and server. The choice affects developer experience, payload size, latency, and what kinds of clients can efficiently consume the API.

REST

REST (Representational State Transfer) is an architectural style that uses standard HTTP methods and URLs to represent resources. It is stateless, cacheable, and universally understood. A GET /users/42 request is readable by any developer without documentation.

1. Strengths — simple mental model, excellent tooling, HTTP caching works natively, browser-friendly.
2. Weaknesses — over-fetching (endpoint returns more fields than the client needs) and under-fetching (multiple round trips needed to assemble a view from several endpoints) are endemic.
3. Best for — public APIs, CRUD services, browser clients, anywhere simplicity and interoperability matter most.

GraphQL

GraphQL is a query language for APIs where the client specifies exactly which fields it needs in a single request. One endpoint (POST /graphql) handles all queries. The response shape mirrors the query shape exactly — no over-fetching or under-fetching.

1. Strengths — clients control the response shape, great for complex nested data, reduces number of requests, strongly typed schema doubles as documentation.
2. Weaknesses — HTTP caching is difficult (all requests are POSTs), complex queries can cause N+1 database problems without a dataloader layer, higher server-side complexity.
3. Best for — mobile clients with bandwidth constraints, products with many different client types (web, iOS, Android) each needing different data shapes, rapidly evolving APIs.

gRPC

gRPC is a high-performance RPC framework from Google that uses Protocol Buffers (protobuf) for serialisation and HTTP/2 for transport. The API is defined in a .proto schema file; code for both client and server stubs is generated automatically in any supported language.

1. Strengths — protobuf messages are 3–10× smaller than equivalent JSON and faster to serialise/deserialise, HTTP/2 multiplexing enables streaming RPCs (server streaming, client streaming, bidirectional streaming), strongly typed contracts catch mismatches at compile time.
2. Weaknesses — not human-readable (binary format), poor native browser support (requires gRPC-Web proxy), schema changes require regenerating stubs in every service.
3. Best for — internal service-to-service communication in microservice architectures, high-throughput or low-latency scenarios, polyglot environments where type-safe contracts are critical.

CDN

A Content Delivery Network (CDN) is a globally distributed network of servers — called Points of Presence (PoPs) or edge nodes — that cache and serve content from a location geographically close to the user. Instead of every request travelling to a single origin server in one region, the CDN intercepts it at the nearest edge node.

What CDNs serve

1. Static assets — JavaScript, CSS, images, fonts, videos. These never change per-user and are ideal cache candidates.
2. Dynamic content — modern CDNs (Cloudflare Workers, Lambda@Edge) can run logic at the edge, serving personalised responses without a round trip to origin.
3. Streaming video — chunked delivery from edge nodes reduces buffering by shortening the delivery path.

Push vs Pull CDN

1. Pull CDN — on the first request for a resource the CDN fetches it from the origin, caches it, and serves subsequent requests from cache. Simple to set up; cold misses hit origin. Most CDNs work this way.
2. Push CDN — you proactively upload content to the CDN before any user requests it. No cold start; you control what is cached. Better for large, predictable assets like software releases or video files.

CDNs also absorb DDoS traffic, reduce origin bandwidth costs, and handle TLS termination at the edge — improving security and time-to-first-byte simultaneously.