When you type a URL like https://blog.samyakg.in into your browser and press Enter, your request doesn’t travel to a dusty rack server sitting in a single data center in Virginia. Instead, it hits a Point of Presence (PoP) located physically within a few kilometers of where you are sitting, usually resolving in less than 15 milliseconds.
How does modern edge infrastructure actually achieve this? How do thousands of distributed edge nodes present a single IP address to the global Internet without causing routing chaos?
This post dissects the network layers that bridge your browser to an edge network: Anycast BGP, TLS 1.3 session resumption, TCP/QUIC connection termination, and static asset caching.
1. The Core Trick: Anycast BGP vs. Unicast
In conventional Unicast routing, every IP address on the Internet corresponds to exactly one physical network interface. If your server is in Frankfurt (198.51.100.10), any packet destined for that IP anywhere on Earth must be routed across transatlantic fiber cables to Frankfurt.
Modern edge networks (like Cloudflare, Fastly, and AWS CloudFront) use Anycast BGP:
In Anycast routing, hundreds of data centers across hundreds of cities advertise the exact same IP prefix to neighboring Autonomous Systems (AS) via the Border Gateway Protocol (BGP).
Internet Backbone (BGP)
│
┌──────────────────┼──────────────────┐
▼ ▼ ▼
[ Tokyo PoP ] [ London PoP ] [ Mumbai PoP ]
198.51.100.0/24 198.51.100.0/24 198.51.100.0/24
When an Internet Service Provider (ISP) in Mumbai needs to route a packet to 198.51.100.1, their BGP routing table chooses the path with the shortest AS path length. Rather than sending your packet through submarine cables to Europe or the US, the packet naturally lands at the edge node in Mumbai.
The Anycast Catch: Routing Flaps
Because BGP does not maintain connection state, a routing shift (a “flap”) halfway through a multi-packet TCP connection could theoretically send packet 3 to Tokyo and packet 4 to Singapore, causing a connection reset (RST).
Modern edge providers mitigate this using consistent hashing across ECMP (Equal-Cost Multi-Path) routers and specialized layer-4 load balancers (such as Unimog or Katran) running eBPF inside Linux kernels.
2. Reducing Latency: TLS and Handshake Costs
Establishing a secure encrypted connection traditionally required multiple round trips before a single byte of HTTP data could be transmitted:
- DNS resolution ( RTT)
- TCP 3-way handshake ( RTT)
- TLS 1.2 handshake ( RTT)
- HTTP request & response ( RTT)
Total: before your page starts rendering! Over mobile networks with an 80ms round-trip time, that meant an unbearable delay.
The Mathematical Model of Edge Latency
Let be the physical distance to the serving node, the speed of light in vacuum, and the speed of light in optical fiber. The physical lower bound on round-trip time is:
If your origin server is in San Francisco and your user is in New Delhi ():
By terminating the connection at a local edge PoP in New Delhi ():
By terminating TCP and TLS at the edge, the expensive handshake round-trips happen across local city fiber rather than across ocean trenches.
3. The Modern Protocol Stack: HTTP/3 & QUIC
Modern edge platforms support HTTP/3 over QUIC, which completely re-engineers transport over UDP:
- 0-RTT connection resumption: Returning visitors can send encrypted HTTP requests inside the very first packet using cached TLS session tickets.
- No Head-of-Line Blocking: Multiple multiplexed streams share the UDP socket; packet loss on stream does not stall packets belonging to stream .
- Connection Migration: When you switch your phone from home Wi-Fi to 5G cellular, your IP address changes, but the QUIC
Connection IDremains identical. The streaming connection doesn’t drop.
4. Serving Static Assets from the Edge
When you publish a purely static site (like this blog built with Astro):
┌──────────────┐ git push ┌─────────────────────────┐
│ Local Laptop │ ────────────────► │ GitHub Repository │
└──────────────┘ └──────────┬──────────────┘
│ Webhook
▼
┌─────────────────────────┐
│ Cloudflare Pages CI │
│ (npm run build) │
└──────────┬──────────────┘
│ Distributes HTML & Assets
▼
┌─────────────────────────────────────────┐
│ Edge CDN Storage (Global Replication) │
└─────┬─────────────────┬───────────┬─────┘
▼ ▼ ▼
[PoP: Tokyo] [PoP: London] [PoP: Mumbai]
There is zero server execution. The HTML document, CSS stylesheets, WebP images, and pre-computed KaTeX formulas are stored directly in SSD storage across every edge node.
When a request arrives:
- Edge proxy matches the URL path against local edge cache.
- Injects pre-configured security headers (from
_headers). - Compresses the response stream on the fly with Brotli (
br). - Serves the payload with an instant Time-To-First-Byte (TTFB) often below .
5. Summary
Building for the edge isn’t about running complex microservices everywhere; it is about recognizing that the fastest code is the code you never have to execute at runtime.
By pre-rendering Markdown into pure static HTML during build time and letting Anycast BGP route requests to the nearest edge cache, we get instantaneous load speeds, immunity to traffic spikes, and ironclad security.