Networking Basics
DNS, TCP versus UDP, the HTTP versions, TLS, and what a CDN actually does — the layer every design sits on
Every box in a design diagram is connected by a network, and the network has properties that decide what is possible. This page covers the parts that change designs.
What Happens When a Request Is Made
Connection setup is why keep-alive matters
DNS, TCP and TLS together can cost 200 ms before a single byte of your response is sent — and none of that is your application's fault.
This is why connections are reused rather than reopened. A page making 20 requests over one kept-alive connection pays the setup once; opening 20 connections pays it 20 times.
The same applies between your own services. Connection pooling is not a micro-optimisation; it removes a round trip from every internal call.
DNS
DNS turns a name into an address. It is a cache hierarchy, and the caching is what you must design around.
| Record | Purpose |
|---|---|
A / AAAA | Name → IPv4 / IPv6 address |
CNAME | Name → another name |
MX | Mail servers |
TXT | Arbitrary text, often domain verification |
TTL is a promise you cannot take back
A DNS record's TTL tells resolvers how long they may cache it. Set it to 24 hours and a failover cannot take effect for up to 24 hours — resolvers worldwide keep sending users to the dead address, and you have no way to reach them.
Lower the TTL to 60 seconds before any planned migration, wait for the old TTL to expire, then make the change. Afterwards you can raise it again.
Getting this wrong turns a five-minute switch into a day-long outage.
DNS is also a routing tool. Geographic DNS returns a different address depending on where the query came from, sending European users to a European region. It is the cheapest way to do global routing, but it fails over slowly because of caching.
TCP and UDP
| TCP | UDP | |
|---|---|---|
| Delivery | Guaranteed, in order | Best effort, may be lost or reordered |
| Setup | Handshake required | None — just send |
| Speed | Slower | Faster |
| Congestion control | Yes | No |
| Suits | Almost everything | Video calls, games, DNS queries |
When losing data is better than waiting for it
On a live video call, a packet that arrives late is worthless — the moment it described has passed. TCP would stall the stream to redeliver it, making things worse.
UDP drops it and moves on. A momentary glitch beats a freeze.
The rule: use UDP when fresh data matters more than complete data. Everything else uses TCP.
The HTTP Versions
| HTTP/1.1 | HTTP/2 | HTTP/3 | |
|---|---|---|---|
| Transport | TCP | TCP | QUIC (over UDP) |
| Requests per connection | One at a time | Many, multiplexed | Many, multiplexed |
| Head-of-line blocking | Per connection | At the TCP layer | None |
| Header compression | No | Yes | Yes |
| Connection setup | TCP + TLS | TCP + TLS | Combined, faster |
Head-of-line blocking, and why HTTP/3 exists
HTTP/1.1 sends one request at a time per connection. Browsers worked around it by opening six connections per domain — which is why "sprite sheets" and file concatenation used to be performance advice.
HTTP/2 multiplexes many requests over one connection, so that advice became obsolete. But it still runs on TCP, and TCP guarantees ordering across the whole connection. One lost packet stalls every stream sharing it.
HTTP/3 moves to QUIC over UDP, which tracks each stream separately. A lost packet stalls only its own stream. On unreliable mobile networks this is a large real-world win.
TLS
TLS encrypts the connection and proves the server is who it claims. The handshake costs a round trip or two, which is why session resumption exists — a returning client can skip most of it.
| Term | Meaning |
|---|---|
| Certificate | Signed proof the server owns this domain |
| TLS termination | Decrypting at the load balancer, so app servers get plain HTTP |
| End-to-end TLS | Encrypted all the way to the app server |
| mTLS | Both sides present certificates — common between internal services |
Terminating TLS at the load balancer has a consequence
It is the common choice: the load balancer handles certificates and the CPU cost of encryption, and app servers stay simple.
But traffic inside your network is then unencrypted. That is acceptable in a trusted private network and unacceptable if the traffic crosses zones or providers.
Say which you are doing. "TLS terminates at the edge, and internal service calls use mTLS" is a complete answer.
What a CDN Actually Does
A CDN is a network of caches placed physically near users. Two things make it valuable, and the second is often forgotten.
It removes distance. A user in Sydney fetching from a London server pays roughly 250 ms per round trip. From a Sydney edge, 5 ms. No amount of server optimisation competes with that.
It absorbs traffic. Bytes served by the edge never touch your infrastructure. For the video streaming design, that is the difference between possible and impossible.
| Content | Cache at the edge? |
|---|---|
| Images, video, CSS, JS | Yes — the main use |
| Public API responses | Often, with a short TTL |
| Personalised pages | No — one user's page must not be served to another |
| Anything behind authentication | Only with great care |
The most dangerous caching bug
Caching a personalised response at a shared edge means the next visitor receives someone else's data — their name, their basket, sometimes their session.
Any response that varies per user must send Cache-Control: private or no-store. If it varies by a header, that header must appear in Vary.
This class of bug leaks real user data and is invisible in testing, because a single-user test never sees the crossover.
Push or pull
| Model | How | Suits |
|---|---|---|
| Pull | The edge fetches from origin on first request | Most content — self-managing |
| Push | You upload to the edge in advance | Large launches, where the first miss would be a stampede |
Pull is the default. Push is worth it when you know a spike is coming and the first request must not be slow — a video release, a product launch.
Practical Consequences
Design rules that follow from this page:
□ Reuse connections — pooling and keep-alive, internally and externally
□ Lower DNS TTL before a migration, not during
□ Serve static assets from a CDN, always
□ Never cache a personalised response at a shared layer
□ Prefer one multiplexed connection to many parallel ones
□ Put users' first byte close to them; distance is not optimisableRelated Reading
- Numbers Every Design Needs — the latency figures behind this page
- Caching — the CDN as the outermost cache layer
- Scaling — load balancers and health checks
- Security — TLS, certificates and what encryption does not cover