How the Internet Works

1.2.1Definition

The internet is a global network of independently operated networks that agree to speak a common set of protocols, allowing any connected device to exchange data with any other. It has no central owner or control point — its resilience comes precisely from being decentralized. Everything discussed later in this handbook — hosting, APIs, CDNs, cloud regions — is a structure built on top of this shared, neutral transport layer.

1.2.2The Core Mechanism: Packets and Addresses

Data sent over the internet is broken into small units called packets, each labeled with a destination address (an IP address) and a source address. Independent routers along the way read only the destination label and forward the packet toward it, without needing to understand its contents or its final purpose. Packets belonging to the same message can take different paths and arrive out of order — it is the responsibility of a higher-level protocol (TCP) to reassemble them correctly. This packet-switching design, rather than reserving a dedicated line for each conversation, is what lets the same physical infrastructure serve billions of simultaneous, unrelated conversations.

1.2.3Protocols: The Shared Rules

• IP (Internet Protocol) — defines addressing: every device gets an address so packets know where to go.
• TCP (Transmission Control Protocol) — sits above IP, guarantees packets arrive complete and in the correct order, retransmitting anything lost.
• DNS — translates human-readable names (example.com) into the numeric IP addresses routers actually use (covered fully in Chapter 1.7).
• HTTP/HTTPS — the application-level protocol that web browsers and servers use to request and deliver content (covered fully in Chapter 1.8).

1.2.4Common Mistakes

• Treating "the internet" and "the web" as synonyms. The web (HTTP, browsers, websites) is one application built on top of the internet; email, video calls, and file transfer are other applications on the same underlying network.
• Assuming a direct, single path between client and server. This leads to poor intuitions about latency — a request may cross many intermediate networks, each adding delay, which is precisely why geographic proximity and CDNs (Chapter 1.6) matter for performance.
• Ignoring that packet loss and reordering are normal, expected conditions the protocols are designed to handle — not rare failures to code around defensively at the application layer.

1.2.5Best Practices

• When debugging "slow" applications, separate network latency (physical distance, routing) from server processing time (application logic) — they require entirely different fixes.
• Design for intermittent connectivity as a normal state, not an edge case, especially for mobile products.