Networking & Protocols: Wrap-Up
Systems Design
| # | Post | What it covers |
|---|---|---|
| 00 | Networking & Protocols: How Bytes Actually Travel | Before you can design systems that scale, you need to understand how bytes actually travel. Eight concepts every backend engineer must know. (148 chars) |
| 01 | The OSI Model: The Map Every Engineer Needs | The OSI model isn't just interview theory — it's the map that tells you exactly where in the stack a network problem lives. Here's how to use it. (152 chars) |
| 02 | TCP vs UDP: Reliability vs Speed at the Transport Layer | TCP guarantees delivery. UDP doesn't look back. Understanding why each exists — and when to reach for each — is fundamental to network design. (150 chars) |
| 03 | HTTP vs HTTPS: The Language of the Web and Its Secure Version | 301 Moved Permanently, 302 Found, 304 Not Modified |
| 04 | TLS/SSL: How HTTPS Actually Works Under the Hood | TLS is what puts the S in HTTPS. Here's how the handshake works, what a certificate actually contains, and why TLS 1.3 matters for performance. (152 chars) |
| 05 | DNS: The Phone Book That Runs the Internet | DNS is the phone book of the internet — and one of the most misunderstood layers in the stack. Here's how it works and how it fails. (133 chars) |
| 06 | DNS Load Balancing: Traffic Distribution at the Name Layer | DNS load balancing distributes traffic before a single packet reaches your servers. Here's how it works, where it excels, and where it falls short. (154 chars) |
| 07 | Anycast Routing: One Address, Everywhere at Once | One IP address, dozens of locations, zero client configuration. Anycast is how the fastest global infrastructure works — here's the mechanism behind it. (158 chars) |
| 08 | CDN: Moving Content Closer to the People Who Need It | A CDN isn't just a cache in front of your server. Here's how content delivery networks work, when they help, and when they add complexity for nothing. (154 chars) |
| 09 | Networking & Protocols: Wrap-Up ← you are here | A complete recap of the eight core networking concepts — OSI, TCP, HTTP, TLS, DNS, CDN — and how they connect into a complete picture. (135 chars) |
Networking & Protocols: Wrap-Up
Eight posts. One complete picture of how data travels from a user's device to your servers and back. Before moving to the next pillar, it's worth pulling the thread — because these eight concepts don't operate in isolation. Every user request exercises all of them, in sequence, every time.
What we covered
The OSI Model
The seven-layer framework that gives every networking concept a home. Physical signals at layer 1, IP routing at layer 3, TCP/UDP at layer 4, HTTP at layer 7. Its greatest practical value: systematic fault isolation. Work up from layer 1 until you find where communication breaks — ping tests layer 3, telnet tests layer 4, curl tests layer 7. The layer that fails tells you where to look.
The one thing to remember: the OSI model is a diagnostic map, not an implementation blueprint. Use it to narrow the search space when something breaks.
TCP vs UDP
Two transport protocols, two opposite bets. TCP guarantees delivery, ordering, and integrity — at the cost of a three-way handshake, acknowledgement overhead, and head-of-line blocking. UDP fires and forgets — minimal latency, no guarantees, full responsibility on the application. HTTP runs on TCP because correctness matters. DNS uses UDP because a retryable query is faster than a handshake. HTTP/3 runs on QUIC (UDP-based) to eliminate the head-of-line blocking TCP creates at the transport layer.
The one thing to remember: TCP and UDP are different contracts, not different quality levels. Which contract your application needs determines which protocol to use.
HTTP vs HTTPS
HTTP is the language of the web — methods, status codes, headers, bodies. HTTPS is the same language wrapped in TLS. Understanding HTTP deeply — idempotency, caching headers, status code semantics — is prerequisite knowledge for API design, debugging, and performance work. HTTPS is the default for any service handling real users; the performance cost of TLS is now minimal and the security risk of plaintext HTTP is not theoretical.
The one thing to remember: HTTP defines the conversation. HTTPS secures the channel. They're not alternatives — HTTPS is the baseline.
TLS/SSL
The cryptographic protocol that makes HTTPS trustworthy. Three guarantees: encryption (nobody reads it in transit), authentication (you're talking to who you think), integrity (nobody tampered with it). The TLS handshake adds latency: 2 RTTs in TLS 1.2, reduced to 1 RTT in TLS 1.3, 0 additional RTTs for session resumption. TLS terminates at the load balancer or CDN edge in production — application servers receive plain HTTP on a private network. Certificate expiry is an automatable operational risk that teams consistently underinvest in until it causes an outage.
The one thing to remember: TLS is a configuration, not a checkbox. Check your version, enable session resumption, automate renewal, test handshake latency on high-RTT connections.
DNS
The distributed hierarchy that translates hostnames to IP addresses. Root nameservers → TLD nameservers → authoritative nameservers → your DNS records. Every layer caches aggressively up to the TTL. The operational pattern that prevents incidents: lower TTL before planned changes, not during them. DNS as a single point of failure — the Dyn outage of 2016 taking down Twitter, Reddit, and Spotify simultaneously — is the argument for multi-provider DNS. TTL is a contract with the world's resolvers; understand what you've promised before you need to change it under pressure.
The one thing to remember: DNS is the first thing that happens for every user request and the last thing most engineers think about. Treat your DNS provider as a critical dependency.
DNS Load Balancing
Traffic distribution at name resolution time — before a packet reaches your infrastructure. Round-robin rotates through a list of IPs. GeoDNS returns different IPs based on the client resolver's location. Weighted DNS enables gradual traffic shifting. Health checking removes failed IPs from responses. All of these operate at the TTL granularity — changes propagate in minutes, not seconds. DNS load balancing directs clients to the right regional cluster; application load balancing distributes within a cluster. The two layers complement each other.
The one thing to remember: DNS load balancing is cheap, scalable, and geographically powerful — but blind to real server health and slow to react. Use it for coarse geographic routing; use an application load balancer for everything requiring per-request awareness.
Anycast Routing
One IP address, announced from multiple locations simultaneously. BGP routes each client's packets to the topologically nearest announcement. No client configuration, no DNS indirection, no TTL. Failover happens when a location withdraws its BGP announcement — BGP convergence in 30–90 seconds, significantly faster than DNS-based failover. Powers Google's 8.8.8.8, Cloudflare's 1.1.1.1, the 13 root DNS nameservers, and CDN edge routing globally. Works best for stateless, short-lived connections — TCP session continuity is disrupted if BGP reroutes mid-connection.
The one thing to remember: Anycast is the technique behind "how is this so fast everywhere?" global services. For most teams, consume it through a CDN or managed DNS provider — don't build your own BGP infrastructure.
CDN
A globally distributed cache network that serves content from edge nodes close to users. Cache hits serve responses locally — typically 5–20ms regardless of origin location. Cache misses forward to origin, cache the response, and return it. Cache hit ratio is the primary effectiveness metric, driven by content cachability, TTL configuration, and traffic concentration. Beyond caching: TLS termination at the edge, DDoS absorption, WAF, HTTP/2 and HTTP/3 support, edge computing. Cache invalidation — the hard part — is managed through TTL expiry, purge APIs, URL fingerprinting, and cache tags.
The one thing to remember: a CDN's value is proportional to your cache hit ratio, which is proportional to your caching strategy. A CDN in front of uncacheable responses gives you DDoS protection but not latency reduction.
How they connect: a request end-to-end
A user in Singapore clicks a link to sho.rt/x7Kp2. Here's every concept in this pillar, in sequence:
1. DNS resolution
└─ Resolver queries sho.rt → GeoDNS returns Singapore CDN edge IP
└─ Anycast routes the DNS query itself to nearest DNS resolver PoP
2. TCP connection
└─ Client opens TCP connection to Singapore CDN edge node (3-way handshake)
3. TLS handshake
└─ TLS 1.3 handshake at edge — 1 RTT, certificate verified, session established
└─ TLS terminates at CDN; backend connection uses HTTP
4. HTTP request
└─ GET /x7Kp2 HTTP/2 sent to CDN edge node
5. CDN cache lookup
└─ Cache HIT: edge returns 301 redirect with Location header — ~8ms total
└─ Cache MISS: CDN forwards to Sydney origin, caches response, returns to client
6. DNS load balancing (cache miss path)
└─ CDN-to-origin connection resolves origin hostname via internal DNS
└─ Origin servers distributed across AZs via application load balancer
7. Response travels back through OSI layers
└─ HTTP response → TLS encrypt → TCP segment → IP packet → physical transmission
Every concept in this pillar touches every user request. Understanding the stack end-to-end means you know which layer to interrogate when something goes wrong, and which layer to optimise when something is slower than it should be.
What's next: APIs & Communication
The Networking pillar covered the infrastructure layer — how bytes travel. The next pillar covers how services talk to each other at the application layer:
- API Design and REST — the conventions that make APIs predictable and maintainable
- WebSockets — when HTTP's request/response model isn't enough
- Long Polling, Server-Sent Events, Webhooks — the spectrum of server-push patterns
- WebRTC — peer-to-peer communication in the browser
- Synchronous vs Asynchronous communication — the architectural choice that affects everything
- API Gateways — the traffic cop for microservices
The Networking pillar gave you the medium. The APIs & Communication pillar gives you the language services speak through it.
Start Pillar 3 → APIs & Communication: Overview
Part of the System Design series. Tags: #systemdesign #networking #distributedsystems #backend #softwarearchitecture #engineering
← Previous: CDN — Anycast gets users to the nearest edge node fast. CDNs are what those edge nodes actually do: cache content, terminate TLS, absorb traffic, and make global performance possible without running origin servers everywhere.
