edgeacademyCUSTOMER ENGINEERING
Workspace/Overview
MODULE 02

The Life of an Internet Request

Follow a browser request through names, routes, encrypted connections, edge decisions, and origin work.

ArchitectDebugCommunicate
1

URL to address: recursive and authoritative DNS

Distinguish recursive and authoritative DNS

12 min›2

Transport: TCP, UDP, and QUIC

Separate IP, transport, and HTTP responsibilities

12 min›3

TLS and HTTP across two trust boundaries

Explain TLS authentication separately from HTTP

12 min›4

Reverse proxies, forward proxies, and cache decisions

Distinguish forward and reverse proxy roles

12 min›5

Anycast, origin work, and latency evidence

Decompose end-to-end latency

12 min›
PRACTICAL EXERCISE · MODULE 2

Trace a request and isolate failures

A customer reports that https://shop.example.test is intermittently unavailable. Build a request-path investigation without changing production.

Work through the problem

  • Draw browser, resolver, authoritative DNS, edge, and origin.
  • Place DNS, connection, TLS, HTTP, cache, and application failures on the path.
  • Define one discriminating observation at each boundary.
  • Explain what a successful test rules out and what remains unknown.

Deliverables

  • Annotated request flow
  • Diagnostic matrix
  • A two-minute customer update

Self-review rubric

  • Separates DNS from application processing
  • Distinguishes both TLS connections
  • Uses timestamps and identifiers
  • Does not infer server health from ping alone
Compare with the worked approach

A defensible sequence is: establish affected users and time; inspect DNS answers and proxy status; compare transport and TLS handshakes; capture HTTP status and request identifiers; inspect cache status; correlate origin logs and dependencies. A valid DNS answer only proves name resolution. A successful edge TLS handshake does not prove origin TLS or application health.

Sources and context