Starting my own Content Delivery Network

### TL;DR The author built a personal content delivery network (CDN) distributed across three global servers by owning their own Autonomous System (AS) and using BGP anycast, combined with DNS and BGP traffic engineering to optimize user connection latency. --- ## Why Are Modern Websites Still Slow to Load? Modern websites often require many network requests. The author cites loading YouTube on a laptop, where the browser made 157 requests to different servers. If each request requires establishing TCP and TLS connections, and you're in a region like Australia with a round-trip latency of ~200ms, just establishing connections could take nearly a second. The bottleneck is physical latency — packets take time to cross oceans. Take the author's own site `apalrd.net` as an example. The server is located in Ashburn, Virginia, USA, while the author lives in Finland. Loading the page involved 8 requests transferring about 500KB of data. At 400Mbps bandwidth, pure transfer would take 10ms, but actual load time was 1.6 seconds. The problem is latency: a transatlantic round trip takes ~120ms, and establishing a TCP+TLS connection requires 4 round trips (~480ms). Add in request dependencies (must load HTML before referencing CSS, etc.), and total time balloons. Increasing bandwidth (e.g., from 500Mbps to 5Gbps) only shaves off a few milliseconds of transfer time and does not solve latency. The only real solution is to place servers closer to users. --- ## The Simplest Solution: Deploy Servers in Multiple Locations The author found that moving the server from Virginia to Helsinki would significantly reduce latency for Finnish users, but worsen it for US users. So they kept one server in Virginia and added a new one in Europe (Warsaw). Now European users connect to the European server, and US users to the US server. This is the fundamental idea behind modern CDNs: shorten physical distance by deploying globally distributed nodes, reducing round-trip latency and cross-border transit costs. But how do you steer users to the correct server? The author introduces two main methods: **BGP anycast** and **DNS**. --- ## Method 1: BGP Anycast BGP (Border Gateway Protocol) is the routing protocol of the Internet backbone. The author has an IPv6 address `2A0F:B240:1000::420` and has all three servers advertise the same IP prefix. Through BGP routing, users end up at the "nearest" server — "nearest" meaning the path that traverses the fewest autonomous systems, not necessarily geographic proximity. The author owns their own AS (AS201726) and announces the prefix to the world via two upstream providers (Vulture and Rack Genius). Their three servers are located in: - **Warsaw** (Europe) - **Los Angeles** (US West) - **Grand Rapids** (US Midwest/East, on Vultr cloud) To control traffic flow, the author uses BGP communities from their upstream providers for traffic engineering: - **Warsaw server**: No communities applied, making it the most attractive for all networks. Since Warsaw’s uplinks are only Aurelion and Cogent, the author wants most traffic that sees Warsaw as reachable to go there, minimizing transatlantic traffic. - **Los Angeles server**: Prepend (add fake AS numbers to make the path longer) to Cogent, Level3, NTT, and AT&T; even withdraw the route entirely from NTT, forcing traffic toward Aurelion and thus more toward Warsaw. - **Grand Rapids server**: Prepend only to Hurricane Electric, because too much transatlantic traffic comes from Hurricane; traffic from 123net is left normal. Through these tweaks, the author can slightly influence routing decisions, making European users more likely to reach Warsaw and US users more likely to reach Los Angeles or Grand Rapids. --- ## Method 2: DNS (not fully transcribed in the text, but mentioned in context) The video title also mentions DNS. The author reveals in the transcription that they wrote a geographically distributed DNS server in Go (after learning Go on boot.dev). DNS can return different server IP addresses based on the user's IP geolocation, thereby directing the user to the nearest node. This is another common method, but in this video, BGP anycast is the focus. --- ## Internet Exchange Points (IXPs) and Options for Big Players For large ISPs and content networks, there is a more advanced option: Internet Exchange Points (IXPs). Most countries have at least one IXP. An IXP is essentially a high-speed Layer 2 switch where different networks (ASes) can directly peer with each other. A CDN operator can buy a large port (e.g., 100G), connect to the switch, and then peer with multiple ISPs simultaneously without needing separate agreements. Routes are shared via route servers at the exchange, benefiting all participants. However, as an individual operator, the author cannot yet use such large exchange points. --- ## Sponsor: Boot.dev The author mentions learning Go through Boot.dev and using that knowledge to write a geo-distributed DNS server. Boot.dev is an interactive programming learning platform that offers real projects. Subscriptions unlock features like answer checking; use code `appleard` for 25% off. Monthly fee is about €14 in Finland (annual plan). --- ## Source Code & Links - Accompanying latency measurement data: https://www.apalrd.net/posts/2026/asn_cdn/ - Video discussion on Lobsters: https://lobste.rs/s/jr7x5l/starting_my_own_content_delivery_network - Author's GitHub (includes DNS server code): not linked in the transcript, but can be found in the video description. **Source:** Starting my own Content Delivery Network - YouTube (https://www.youtube.com/watch?v=LCJIQufZeeg)