Why Internet Routing Is Not a Straight Line: An Introduction to AS, BGP, Outbound, and Return Paths
A beginner-friendly guide explaining Autonomous Systems (AS), ASN, BGP, outbound paths, return paths, and routing asymmetry, showing why physical proximity does not guarantee faster access.
If you connect to a Tokyo VPS from Shenzhen, intuition suggests data should travel northeast along the shortest physical distance on a map. However, the internet is not a single homogeneous network built by a single company—it is a federation of interconnected networks owned by carriers, cloud providers, universities, and enterprise backbones.
Real network routing resembles an intercity courier relay: each carrier manages its own segment, deciding where to pass packages next based on operational cost, commercial peering agreements, and routing policies.
1. An AS Is an Independently Managed Network
AS stands for Autonomous System. Beginners can understand it as:
A network managed by a single organization that presents a unified routing policy to the outside world.Each AS is identified by an ASN (Autonomous System Number). Major telecom carriers, cloud providers, and content delivery networks operate their own ASNs. IANA oversees the global allocation of AS numbers, which are distributed through Regional Internet Registries (RIRs).
When your computer communicates with a VPS, packets travel through your local ISP's AS, cross one or more transit/peering networks, and finally enter the AS operated by your VPS provider.
2. BGP Acts as the "Route Bulletin" Between Networks
BGP stands for Border Gateway Protocol. Instead of calculating internal hop-by-hop forwarding inside a single router, BGP coordinates how distinct Autonomous Systems announce paths to each other:
Which IP prefixes can be reached through my network, and under what policies I am willing to forward them.Think of it as logistics companies publishing shipping route schedules. One route might traverse fewer AS hops but carry higher commercial transit costs; another route might take a slight detour that aligns with a carrier's peering agreements.
RFC 4271 defines BGP-4. You do not need to memorize packet structures—just remember: BGP selects policy-compliant reachable paths, not necessarily the geographically shortest paths.
3. Outbound and Return Paths Can Differ Completely
The path from your local computer to the VPS is the "outbound path" (去程), while the path from the VPS back to your computer is the "return path" (回程).
Outbound: Your Computer → Local ISP → Transit Networks → VPS
Return: VPS → Transit Networks → Local ISP → Your ComputerInternet routing is frequently asymmetric. Outbound traffic may flow through networks A, B, and C, while return traffic flows through networks D and E. Because carriers on both ends independently control their outbound egress traffic policies, they are under no obligation to choose the same physical path.
This is why running a single traceroute from your home computer does not reflect the complete bidirectional experience. You are only observing clues in one direction, and intermediary routers may drop or de-prioritize diagnostic probe packets.
4. Why Nearby Data Centers Can Still Feel Slow
While physical distance matters, it is only one factor. Common causes of slow connections include:
- Lack of direct peering between your local ISP and the destination data center;
- Traffic detouring through another city or continent before looping back;
- Peering point congestion during peak evening hours;
- Smooth outbound routing combined with congested return routing;
- Routers de-prioritizing ICMP probes while actual TCP services function normally;
- DNS resolving you to suboptimal service endpoints.
Regional labels like "Hong Kong," "Japan," or "US West" are mere geographic references; they do not singularly prove network quality.
5. What ping, traceroute, and mtr Actually Measure
| Tool | Primary Question Answered | What It Cannot Prove on Its Own |
|---|---|---|
ping | Round-trip time (RTT) and probe packet loss | That application-layer protocols will behave identically |
traceroute | Which intermediate hops probe packets traverse | That every hop is fixed or represents a point of failure |
mtr | Continuous observation of path latency and loss | That non-responsive hops indicate actual service congestion |
| Looking Glass | Testing outward from the hosting provider's network | The full bidirectional latency from your local machine |
A common misconception is assuming an intermediate router showing packet loss is broken. If downstream hops and the final destination show zero loss, the intermediate router is simply rate-limiting ICMP diagnostic replies.
6. How Beginners Should Evaluate Network Routes
Rather than hunting for a "theoretically perfect routing graph," conduct reproducible multi-period measurements:
1. Standardize your source location, target server, test protocol, and payload size; 2. Record the test date, time of day, and local ISP; 3. Separately measure latency, jitter, packet loss, and actual throughput; 4. Run tests across weekdays, weekends, daytime, and evening peak hours; 5. Let real application performance (SSH responsiveness, page loads, API latency) serve as the final benchmark; 6. Change only one variable at a time to avoid conflating network, host, and tool discrepancies.
When evaluating VPS instances, reproducible real-world results across different times of day are far more valuable than a static traceroute screenshot. Route tags help narrow candidates, but they cannot replace direct measurement.
7. Summary
The internet is not a direct cable, but a mesh of autonomous networks announcing reachability via BGP. Geographic distance, AS peering, commercial incentives, path asymmetry, and real-time congestion collectively dictate connection quality.
Keep this core principle in mind:
Routing graphs provide clues; multi-period real-world application benchmarks provide proof.Frequently Asked Questions
Do asterisks (* * *) in a traceroute mean the network is down?
Not necessarily. Intermediate routers often ignore or rate-limit ICMP/UDP probes. If downstream hops and the final destination respond reliably, the connection is healthy.
Is a shorter AS path always superior?
Not always. Fewer AS hops do not guarantee higher physical capacity, lower latency, or lack of congestion. It is merely one dimension of path analysis.
Why was my VPS fast yesterday but slow today?
BGP route flap, carrier congestion, local ISP changes, and host node load fluctuate over time. Base your assessment on consistent multi-day observations.
Sources
Share