paulserban.eu

Writing Edition

Paul Serban

Writing, snippets & book notes

Vol. 2026

What Are Networks? How Local Networks Became the Global Internet

A Technical History of Internetworking, from LANs to TCP/IP to the Modern Internet

Introduction

Every engineer eventually needs to reason about "the network" as more than a black box between their code and a database, an API, or a user's browser. Yet the internet itself is often treated as a single, monolithic thing, a kind of ambient utility, rather than what it actually is: an enormous, decentralized collection of independently operated networks that agreed to speak a common language. Understanding how that agreement came to exist, and what a "network" fundamentally is, gives engineers a much sharper intuition for latency, routing, outages, and the architectural decisions that depend on all three.

This article works from first principles. It starts with the basic definition of a network, walks through the historical and technical journey from isolated local networks to a single interoperable internet, and explains the protocols that made that interoperability possible. The goal isn't a nostalgic history lesson for its own sake; the reasoning that produced TCP/IP, packet switching, and internetworking directly explains why the modern internet behaves the way it does, including why it's resilient to failure, why routing decisions are decentralized, and why performance can vary so unpredictably across different network paths.

Context: What Even Is a Network?

At the most basic level, a network is a set of devices that can exchange data with each other. That's a broader category than people often assume: two laptops connected by a single Ethernet cable form a network, just as much as a corporate office with hundreds of desks does, or the internet connecting billions of devices worldwide. What distinguishes types of networks from each other isn't whether they qualify as a "network," but their scale, topology, and the rules (protocols) devices use to communicate.

Networks are typically categorized by their physical and organizational scope. A Local Area Network (LAN) connects devices within a limited geographic area, such as a single building or campus, usually owned and managed by a single organization. A Wide Area Network (WAN) spans a much larger geographic area, often connecting multiple LANs across cities, countries, or continents, and it is what internet service providers (ISPs) and large enterprises operate to link distant locations together. The internet itself is best understood not as a single network at all, but as a "network of networks": a vast collection of independently administered networks (belonging to ISPs, universities, corporations, and governments) that agree to exchange data using a common set of protocols.

This distinction matters because it reframes a common misconception: there is no single entity that "runs" the internet the way a company runs its own internal network. Instead, the internet functions through voluntary interconnection and shared standards, primarily coordinated by bodies like the Internet Engineering Task Force (IETF), which publishes the technical standards (RFCs) that networks agree to implement. No central authority dictates traffic flow globally; instead, thousands of independently operated networks make local routing decisions that, in aggregate, get data from any point to any other point. This decentralized structure is a design choice with deep historical roots, not an accident, and understanding those roots clarifies why the internet is architected the way it is today.

From One Room to Many: LANs and the Local Network Problem

Before there was an internet to connect to, there were local networks solving a much narrower problem: how do you let a handful of computers within a single building share data and resources, like printers or storage, without physically shuttling storage media between them. Early local networking technologies, most notably Ethernet (developed at Xerox PARC in the 1970s and later standardized as IEEE 802.3), solved this by defining how devices on a shared physical medium (originally coaxial cable, later twisted-pair cabling) could take turns transmitting data without their signals colliding and corrupting each other. Ethernet's core innovation, a media access method that let multiple devices share a single physical link without a central coordinator dictating turns, is why it succeeded over more centrally controlled alternatives of the era, and its descendants are still what carries traffic on nearly every wired LAN today.

But a LAN, however well designed, only solves the local problem. A LAN in Chicago and a LAN in London have no inherent way to talk to each other; they're built on the assumption that every device on the network is physically reachable via the same shared medium or a switched extension of it. As organizations grew and needed to connect multiple buildings, campuses, or eventually continents, this local-only design became the central bottleneck. Solving it required a fundamentally different approach: instead of extending a single physical network indefinitely (which doesn't scale, given physical and addressing constraints), engineers needed a way to connect independent networks together while preserving each network's autonomy. This is the exact problem that internetworking, and eventually the internet, was invented to solve.

Connecting Networks: The Birth of Internetworking

The technical and conceptual breakthrough that made a global internet possible wasn't a single local networking technology; it was internetworking, the idea of connecting distinct, independently managed networks into a larger whole using a common set of rules, without requiring any single network to change its own internal technology. This idea emerged directly from ARPANET, a research network funded by the U.S. Department of Defense's Advanced Research Projects Agency (ARPA), which went live in 1969 connecting a handful of university and research computers. ARPANET's most significant contribution wasn't the network itself, but its adoption of packet switching: rather than establishing a dedicated, continuously open circuit between two communicating devices (as traditional telephone networks did), data is broken into small units called packets, each labeled with addressing information, and sent independently across whatever path is available, to be reassembled at the destination.

Packet switching matters enormously for internetworking because it means the network doesn't need to reserve a dedicated path in advance; packets from many different conversations can share the same physical links, interleaved, and the network can route around failures or congestion dynamically, packet by packet. This is fundamentally different from circuit-switched networks, where a failure anywhere along a reserved path breaks the entire connection. ARPANET proved packet switching worked at meaningful scale, but ARPANET itself was still just one network, connecting a specific, limited set of participating sites using ARPANET-specific protocols.

The real leap toward today's internet came from a 1974 paper by Vint Cerf and Bob Kahn, "A Protocol for Packet Network Intercommunication," which proposed a way to connect multiple independent packet-switched networks, each potentially using different internal technologies, into a unified system. Their design introduced the core idea that eventually became TCP/IP: a common addressing scheme and set of rules that any network could implement at its boundary, allowing data to cross from one network into another without either network needing to understand the other's internal details. This is the conceptual foundation of the modern internet: not a single network technology, but an agreement about how independent networks hand data off to each other at their edges.

Deep Technical Explanation: TCP/IP and the Protocol Stack

The protocols that emerged from Cerf and Kahn's work, collectively known as TCP/IP (Transmission Control Protocol / Internet Protocol), are what actually let independent networks interoperate, and they remain the foundation of the internet today. IP (Internet Protocol) is responsible for addressing and routing: it defines how every device gets a unique address (an IP address) and how packets get forwarded from network to network based on that address, without any guarantee of delivery on its own. TCP (Transmission Control Protocol) sits on top of IP and adds reliability: it handles retransmission of lost packets, ordering of packets that may arrive out of sequence, and flow control, so that applications built on top don't need to reimplement these guarantees themselves.

This split between IP (addressing and routing) and TCP (reliability) reflects a broader design principle sometimes called the "end-to-end principle," articulated in a 1984 paper by Jerome Saltzer, David Reed, and David Clark: complex, application-specific correctness guarantees should be implemented at the endpoints of a network (in this case, in TCP running on the communicating hosts) rather than inside the network itself. This kept the core network layer (IP) simple, dumb, and universal, meaning any network technology, from Ethernet to satellite links to cellular data, could carry IP traffic without needing to understand anything about the applications using it. This simplicity at the network layer is precisely why so many different physical and local networking technologies were able to plug into the same global internet: they only ever needed to agree on how to carry IP packets, not on anything above that.

# A simplified illustration of how IP addressing and routing conceptually work,
# using a routing table lookup to determine the next hop for a packet
import ipaddress

routing_table = [
    {"network": ipaddress.ip_network("10.0.0.0/8"), "next_hop": "internal_gateway"},
    {"network": ipaddress.ip_network("192.168.1.0/24"), "next_hop": "local_switch"},
    {"network": ipaddress.ip_network("0.0.0.0/0"), "next_hop": "default_isp_router"},  # default route
]

def find_next_hop(destination_ip: str) -> str:
    dest = ipaddress.ip_address(destination_ip)
    # Routers match the most specific (longest prefix) matching route
    matches = [entry for entry in routing_table if dest in entry["network"]]
    best_match = max(matches, key=lambda entry: entry["network"].prefixlen)
    return best_match["next_hop"]

print(find_next_hop("192.168.1.45"))  # -> "local_switch"
print(find_next_hop("8.8.8.8"))       # -> "default_isp_router"

From ARPANET to Global Internet: A Historical Walkthrough

Understanding the actual sequence of events clarifies why the internet looks the way it does architecturally. ARPANET ran on its own protocol (NCP, Network Control Program) throughout the 1970s, but on January 1, 1983, an event informally known as "flag day," ARPANET fully switched over to TCP/IP, making it the first large-scale network to adopt the protocols that would eventually underpin the global internet. This transition mattered enormously: it proved that TCP/IP could operate a real, functioning network at scale, not just as a theoretical proposal, and it established TCP/IP as the shared language other networks could adopt to interconnect.

Through the 1980s, the U.S. National Science Foundation built NSFNET, a backbone network connecting research and educational institutions, which used TCP/IP from the outset and rapidly became a central artery for what was becoming "the internet," eventually replacing ARPANET's role. Around the same period, similar research networks emerged in other countries, and as more of them adopted TCP/IP to interconnect with NSFNET and each other, the internet grew from a U.S. research project into a genuinely international network of networks. Critically, this growth wasn't driven by any single organization scaling up a network they owned; it was driven by independent networks, run by different institutions and later different countries and companies, choosing to adopt the same interconnection protocols.

The final major step toward the internet as it exists today was commercialization. Through the late 1980s and early 1990s, restrictions on commercial use of networks like NSFNET were gradually lifted, and commercial internet service providers began operating their own TCP/IP networks, interconnecting with each other and with the research networks that came before. The introduction of the World Wide Web by Tim Berners-Lee in 1989 to 1991, running on top of this existing TCP/IP internet (using HTTP and HTML, application-layer protocols built on TCP/IP), gave ordinary users a compelling reason to get online, driving the explosive growth of internet adoption through the 1990s. Notably, the Web is an application that runs on top of the internet; it is not the internet itself, a distinction that's easy to blur but important for understanding where different technologies fit in the overall stack.

Implementation: How Modern Networks Actually Route Traffic

With the historical foundation in place, it's worth grounding this in how packets actually move across the modern internet today. Within a single network (an ISP's infrastructure, or a company's internal WAN), routing decisions are typically made using interior gateway protocols like OSPF (Open Shortest Path First), which let routers within that network share information about link costs and compute efficient paths to any destination inside that network. But once a packet needs to leave one independently operated network and enter another, an entirely different protocol takes over: BGP (Border Gateway Protocol), which governs how independent networks, referred to as autonomous systems, announce which address ranges they can deliver traffic to, and negotiate paths between each other.

BGP is, in a very real sense, the protocol that keeps the "network of networks" structure functioning at global scale: it's how a European ISP learns that a particular set of IP addresses is reachable via a specific American network, and how routing decisions propagate (sometimes imperfectly) across the tens of thousands of independently operated networks that make up the internet. This decentralized, negotiated approach to routing is a direct descendant of the original internetworking philosophy: no single entity dictates the path traffic takes globally; instead, each autonomous system makes local decisions about which routes to accept and prefer, and those local decisions aggregate into the actual paths data takes. This is also why internet routing incidents, such as one network accidentally announcing routes it shouldn't (a BGP route leak or hijack), can cause visible, sometimes widespread disruption: the trust-based nature of route announcements between independent networks is a direct consequence of the internet's decentralized architecture, not a flaw introduced later.

Trade-offs and Pitfalls of the Internet's Decentralized Design

The internet's foundational design choices, packet switching, a simple universal network layer, and decentralized routing, come with real trade-offs that engineers should understand rather than take for granted. Packet switching's flexibility, letting packets take different paths and arrive out of order, means the network makes no inherent guarantee about latency or ordering; that's precisely why TCP exists at the endpoints to reassemble and order packets, but it also means that network performance can vary meaningfully between requests, even to the same destination, depending on real-time routing and congestion conditions along the path.

The internet's decentralized routing model, where independent networks negotiate paths via BGP without a central authority verifying every announcement, is what has allowed the internet to scale to its current size without requiring global coordination for every new network that joins. But this same decentralization is also a security and reliability weak point: BGP was designed in an era of implicit trust between a smaller number of research and academic networks, and that trust model has not fully caught up with an internet in which anyone can, in principle, operate an autonomous system. Efforts like RPKI (Resource Public Key Infrastructure) exist specifically to add cryptographic validation to route announcements, but adoption across the internet's tens of thousands of networks remains uneven, meaning route leaks and hijacks, while relatively rare relative to overall internet traffic, remain a structurally possible failure mode.

A related pitfall for engineers is treating "the internet" as a single, uniform thing when reasoning about reliability or performance. Because the internet is a collection of independently operated networks with different peering relationships, capacity, and reliability characteristics, the actual path (and therefore performance and failure modes) between two points can differ substantially depending on which networks happen to carry the traffic. This is precisely why practices like using a CDN, choosing a well-peered hosting provider, or monitoring actual network paths with tools like traceroute matter in production systems: they're direct responses to the fact that "the network" between a client and server is not one thing, but a chain of independently operated systems.

Best Practices for Engineers Reasoning About Networks

Given this architecture, a few practices help engineers reason more effectively about network behavior in production systems. First, treat network path and routing as a variable, not a constant: the path (and therefore latency and reliability) between a client and a server can differ across requests, providers, and geographic regions, since it depends on the real-time state of independently operated networks along the way. Tools like traceroute or mtr (a combination of traceroute and ping) are worth knowing well, since they reveal the actual sequence of networks and routers a packet traverses, which is invaluable when diagnosing latency or connectivity issues that aren't explained by application code.

Second, understand the layer at which a given problem is likely to live. An issue where a specific region of users experiences problems while others don't often points to a network-layer or routing issue (a BGP problem, a peering issue, or a regional ISP outage) rather than an application bug, since application code typically doesn't have per-region logic that would produce that symptom. Third, when architecting systems that depend on network reachability, especially across regions or providers, favor architectures (multi-region deployments, multiple CDN or DNS providers, redundant peering) that don't assume any single network path is always available, since the internet's decentralized structure means no single path or provider can offer an absolute reliability guarantee.

// A practical example: a client that treats network path as unreliable,
// retrying across multiple independent endpoints (e.g. multi-region API gateways)
// rather than assuming a single network path will always succeed.

interface EndpointResult {
  endpoint: string;
  data: unknown;
}

async function fetchWithFailover(
  endpoints: string[],
  path: string,
  timeoutMs = 3000
): Promise<EndpointResult> {
  for (const endpoint of endpoints) {
    const controller = new AbortController();
    const timeout = setTimeout(() => controller.abort(), timeoutMs);

    try {
      const response = await fetch(`${endpoint}${path}`, {
        signal: controller.signal,
      });
      clearTimeout(timeout);

      if (response.ok) {
        const data = await response.json();
        return { endpoint, data };
      }
    } catch (err) {
      // Network-level failure (timeout, DNS failure, connection reset) on this
      // endpoint's path - move on to the next independently-routed endpoint.
      clearTimeout(timeout);
      continue;
    }
  }

  throw new Error("All endpoints failed across all available network paths");
}

Analogies and Mental Models

A useful mental model for the internet's structure is a global postal alliance made up of many independent national postal services, rather than one single postal company. Each country's postal service (an autonomous system, in networking terms) manages its own internal delivery infrastructure (its LANs and internal routing) however it sees fit, using its own trucks, sorting centers, and local addressing conventions. What lets a letter travel from a sender in one country to a recipient in another isn't a single company controlling the whole journey; it's a set of agreements between postal services about how to hand off international mail at their borders, similar to how autonomous systems use BGP to agree on how to hand off packets at their network boundaries.

This model also clarifies why no single entity can unilaterally guarantee delivery performance across the whole internet: just as a letter's journey depends on the specific chain of postal services and carriers it passes through, a packet's journey depends on the specific chain of autonomous systems that happen to carry it, and that chain can vary. It explains packet switching too: rather than reserving one dedicated truck and route for a single letter (a circuit-switched approach), mail from many senders is mixed together and routed dynamically through whatever sorting centers and routes are available and efficient at the time, exactly like packets sharing physical network links. Where the analogy breaks down is in speed and scale: postal handoffs happen over days, are visible and physically trackable, and involve relatively few intermediary organizations for a given letter, while internet routing happens in milliseconds, is largely invisible to end users, and can involve numerous autonomous systems even for a single request.

The 80/20 of Understanding the Internet's Architecture

Of everything covered here, a small number of ideas do most of the explanatory work for engineers who need practical intuition rather than networking specialization. First, internalizing that the internet is a "network of networks," independently operated and interconnected by agreement rather than owned by one entity, immediately clarifies why performance and reliability aren't uniform, and why no single provider or fix guarantees global reliability. Second, understanding packet switching (data broken into independently routed packets, versus a reserved circuit) explains why the internet is resilient to individual link failures and why latency can vary between requests to the same destination.

Third, knowing that IP handles addressing and routing while TCP handles reliability on top of it explains why applications built on TCP (the vast majority of web traffic) don't need to reimplement retransmission or ordering logic themselves, and why performance issues sometimes originate below the application layer entirely. Finally, understanding that routing between independent networks is negotiated via BGP, without centralized verification, explains both the internet's ability to scale without central coordination and its structural vulnerability to route leaks or misconfigurations. Deeper topics, the details of specific interior routing protocols, the mathematics of TCP congestion control algorithms, or the cryptographic specifics of RPKI, are valuable for specialists but explain a much smaller share of the practical judgment calls most engineers actually need to make.

Key Takeaways

Conclusion

The internet isn't a single invention; it's the accumulated result of a specific engineering philosophy, that independent networks could remain autonomous while still interoperating, applied consistently from ARPANET's original packet-switching experiment through TCP/IP's protocol design, NSFNET's backbone expansion, and the eventual commercial internet that carries today's traffic. Every major architectural property of the modern internet, its resilience to individual failures, its lack of centralized control, its variable performance characteristics, and its structural trust assumptions in routing, traces directly back to design decisions made decades ago in service of connecting independent local networks without requiring any of them to give up their autonomy.

For engineers, this history isn't trivia; it's the explanatory backbone for a huge share of practical networking judgment calls, from understanding why a CDN helps, to why multi-region architectures matter, to why a routing incident on the other side of the world can suddenly make part of the internet unreachable. Building an accurate mental model of what a network is, and how thousands of independent ones became a single interoperable internet, gives engineers a genuine diagnostic and architectural advantage over treating "the network" as an unexamined constant.

References