NETWORKS · SYSTEMS · INFRASTRUCTURESEP 17, 20264 MIN READ

How modern edge networks route your requests

From Anycast BGP and geo-DNS to TLS 1.3 termination, HTTP/3 0-RTT handshakes, and global cache coherence.

TABLE OF CONTENTS

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:

  1. DNS resolution (11 RTT)
  2. TCP 3-way handshake (11 RTT)
  3. TLS 1.2 handshake (22 RTT)
  4. HTTP request & response (11 RTT)

Total: 5×RTT5\times \text{RTT} before your page starts rendering! Over mobile networks with an 80ms round-trip time, that meant an unbearable 400ms400\text{ms} delay.

The Mathematical Model of Edge Latency

Let dd be the physical distance to the serving node, cc the speed of light in vacuum, and v23cv \approx \frac{2}{3}c the speed of light in optical fiber. The physical lower bound on round-trip time is:

RTTmin=2×dvd100000 km/s\text{RTT}_{\text{min}} = 2 \times \frac{d}{v} \approx \frac{d}{100\,000 \text{ km/s}}

If your origin server is in San Francisco and your user is in New Delhi (d12500 kmd \approx 12\,500\text{ km}):

RTTorigin25000100000250 ms\text{RTT}_{\text{origin}} \approx \frac{25\,000}{100\,000} \approx 250\text{ ms}

By terminating the connection at a local edge PoP in New Delhi (d25 kmd \approx 25\text{ km}):

RTTedge501000000.5 ms(515 ms with switching hops)\text{RTT}_{\text{edge}} \approx \frac{50}{100\,000} \approx 0.5\text{ ms} \quad (\approx 5\text{--}15\text{ ms with switching hops})

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:


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:

  1. Edge proxy matches the URL path against local edge cache.
  2. Injects pre-configured security headers (from _headers).
  3. Compresses the response stream on the fly with Brotli (br).
  4. Serves the payload with an instant Time-To-First-Byte (TTFB) often below 20ms20\text{ms}.

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.

THOUGHTS OR QUESTIONS?
DISCUSS ON X ↗REPLY VIA EMAIL ↗