ت تیزرس · دمو

Three diagrams, drawn from what is actually deployed

Not stock icons — every address, node name and file path below is real and matches provision/fleet.tsv, provision/fleet-damavand.tsv and the zone pushed for this demo. Full prose walkthrough is in zagros/docs/17-cdn-demo.md.

Topology: browser, ZoneBan DNS, four edges across zagros and damavand, rahdan mesh between the sites, and the Kubernetes Service fronting three origin pods on zagros
Topology — DNS round-robins across all four edges on two sites; only this zone's origin lives on zagros's own k3s, so damavand's two edges reach it one extra hop, over the mesh.
Sequence diagram: TLS handshake, then either a cache MISS path through the origin or a cache HIT answered directly by the edge, and the always-uncached /api path
Request path — the handshake happens once per connection regardless; a MISS reaches the origin pod, a HIT never does, and /api/* is wired to never do either kind of caching.
TLS 1.3 handshake sequence: full handshake in one round trip, and session resumption with 0-RTT
TLS handshake — a full TLS 1.3 handshake costs one round trip; a resumed session (same ticket.key on every edge in the fleet) can carry data in the first flight.

The request path, in words

  1. Your browser resolves demo.zag.taxi-plus.ir against ZoneBan, our own authoritative DNS for zag.taxi-plus.ir. It gets back all four edge addresses and picks one — this is why refreshing enough times can show different edges answering.
  2. A TLS connection opens to that address, SNI = demo.zag.taxi-plus.ir. edge.cert.run() picks the right certificate out of that edge's config-plane snapshot by SNI — the same snapshot pushed to all four edges.
  3. The request arrives at one of twenty generated serving locations (WAF level × cache lifetime, a fixed cross product compiled once at load, never per-request). For a static path with a fresh cache entry, the edge answers straight from its own disk cache: the origin is never contacted, and X-Cache-Status: HIT says so.
  4. For a cache MISS, or for anything under /api (wired uncacheable by this zone's own path rule), the edge opens a plain HTTP/1.1 connection to 10.64.30.203:8080 — the Kubernetes Service in front of this demo's own pods — forwarding X-Forwarded-For and X-Forwarded-Proto, and stripping anything a client tried to forge in their place (Forwarded, CF-Connecting-IP, True-Client-IP and others are blanked before the origin ever sees them).
  5. The Service is deployed with externalTrafficPolicy: Local, specifically so the pod sees the edge's own real address rather than a SNATed cluster-internal one — which is how /api/now can report which edge actually made this particular request.
  6. The response comes back the same way; the edge stores it (if cacheable) keyed by scheme|generation|host|uri, and adds its own response headers — X-Cache-Status, Strict-Transport-Security, Alt-Svc — before it reaches your browser.

A large asset, for throughput rather than latency

Everything else on this site is realistically sized — fonts, CSS, the diagrams above. None of that is big enough to say anything about throughput once a connection is warm. This one file exists only for that measurement:

/assets/sample-12mb.bin — 12 MiB, deterministic pseudo-random bytes generated once when the origin pod starts (not compressible-looking, so a transfer's size on the wire actually reflects the file), served with a one-year Cache-Control: immutable. The numbers this produced — first pull through the origin against a repeat served from an edge's disk cache — are in the throughput table of docs/17-cdn-demo.md.