Tech & AI, Explained

what-is-the-internet

8 min read

What is the internet?

Status: đźź© COMPLETE Last updated: 2026-06-20 Plain-English tagline: A global network of networks. Computers all over the planet, all agreeing on the same rules for finding and talking to each other. The web is one thing built on top.

In plain English

The internet is what happens when computers agree on a few specific rules for how to find each other and exchange messages. Every device with a connection — your laptop, your phone, the server hosting your bank, a smart thermostat in Tokyo — speaks the same set of protocols, so any of them can reach any other.

It’s not a single thing or a single company. It’s a planet-wide mesh: cables under oceans, wires in walls, radio signals, satellites, routers, switches. Different companies (ISPs — Internet Service Providers) own different pieces, but they connect to each other and agree to pass messages along. That cooperation is what makes the internet, well, the internet.

The internet is NOT the same as the web. People conflate them constantly:

  • The internet is the underlying network. It carries email, video calls, file transfers, online games, software updates, IoT signals — anything that needs computers to talk to each other.
  • The web (HTTP/HTML/browsers) is one particular pattern of conversation that happens on top of the internet.

Email, Zoom, your bank’s app — all use the internet but not the web.

Why it matters

For building webapps, you don’t need deep networking knowledge — but you need the mental model. “Why is my deployed site slow from Australia?” “What does DNS actually do?” “Why does my custom domain take time to work?” All trace back to how the internet’s pieces fit together.

For working with Claude Code: when Claude makes a web request, when it pings an MCP server, when a build downloads packages — those go over the internet. Understanding the layers helps you debug when something fails.

How a message gets from A to B

When your laptop sends a request to stmarkbible.com:

  1. Your laptop doesn’t know where stmarkbible.com is. It asks DNS (the internet’s phone book) and gets back an IP address (a numeric address like 76.76.21.21).

  2. Your laptop packages the request into small chunks called packets, each addressed to that IP.

  3. Packets go to your router (the box at home that gives you WiFi). The router knows nothing about most of the internet either — it only knows “send this packet to my ISP.”

  4. Your ISP’s network receives the packets. ISPs have huge routing tables: they know which of their peers can get a packet closer to the destination.

  5. The packets hop through a series of routers — typically 10–25 hops across multiple networks — getting closer to the destination with each hop. Each router only knows about its immediate neighbors; the cooperation between them produces global routing.

  6. The packets arrive at Vercel’s data center, where the server with that IP receives them, reassembles them into the request, and processes it.

  7. The server’s response goes back through (probably different) routers to you.

All of this happens in tens to hundreds of milliseconds. No single computer knows the full route; the route emerges from the routing decisions at each hop.

Layers — the most useful mental model

Networking is built in layers. Higher layers don’t need to know how lower layers work. The standard model (simplified):

LayerPurposeExamples
ApplicationWhat your app actually doesHTTP, HTTPS, SMTP (email), FTP (files), DNS, WebSockets
TransportReliable (or fast) delivery of dataTCP, UDP
NetworkAddressing and routing packetsIP (Internet Protocol)
LinkPhysical signaling — wires, WiFi, fiberEthernet, WiFi, fiber optics

When you write fetch("https://example.com") in JavaScript:

  • The application layer formats an HTTP/HTTPS request
  • The transport layer (TCP) ensures it arrives intact and in order
  • The network layer (IP) routes it via IP addresses
  • The link layer puts it on the actual wire / wireless

Each layer wraps the one above. You usually only think about the top layer; the rest is handled for you.

What lives on the internet (besides the web)

A non-exhaustive list of things that use the internet but aren’t “the web”:

  • Email — SMTP, IMAP, POP3 protocols
  • Video calls — Zoom, FaceTime, Google Meet, Teams (mostly WebRTC + proprietary signaling)
  • VoIP — phone calls over the internet
  • Online games — usually custom protocols over TCP or UDP
  • File transfer — FTP, SFTP, BitTorrent
  • Streaming — Netflix, Spotify (use HTTP for delivery but optimized differently)
  • DNS — the phone book; protocol of its own
  • SSH — secure remote login to servers
  • VPNs — encrypted tunnels through the internet
  • APIs — JSON-over-HTTP, gRPC, GraphQL, etc.
  • IoT — smart devices reporting back to manufacturers
  • Software updates — your OS, your phone, your fridge — all phone home

These all share the underlying internet (IP routing) and most use either TCP or UDP at the transport layer.

A concrete example: what happens when you open this encyclopedia in a browser

Even though the encyclopedia is local files, imagine you’ve pushed it to GitHub Pages and someone opens it:

  1. They type username.github.io/encyclopedia/ and press Enter.
  2. Their browser asks DNS: “where is username.github.io?” → gets an IP.
  3. Browser opens a TCP connection to that IP on port 443 (HTTPS).
  4. Browser does a TLS handshake to encrypt the conversation.
  5. Browser sends an HTTP GET request: “give me /encyclopedia/”.
  6. The request hops through ~15 routers to reach GitHub’s servers.
  7. GitHub finds the file, sends back HTML.
  8. The HTML travels back through ~15 routers (often different ones).
  9. Browser renders the page.
  10. Browser sees <link rel="stylesheet">, <script>, <img> — fires more requests for each.
  11. Each of those hops through the internet again. CDN edge caches mean most of them come from a server near the user, not GitHub itself.

Total time: 200ms–2 seconds for a fast site. Dozens of distinct internet messages.

The internet’s governance

Nobody owns the internet. It’s coordinated by:

  • IANA / ICANN — coordinates IP address allocation and DNS (.com, .org, .au etc.)
  • Regional Internet Registries (ARIN, RIPE, APNIC, etc.) — assign blocks of IPs to ISPs
  • IETF (Internet Engineering Task Force) — develops protocols via RFCs (Request for Comments documents)
  • W3C / WHATWG — develop web standards (HTML, CSS, web APIs)

This is a deliberate decentralization. No single government or company can “turn off” the internet (though they can locally — China’s Great Firewall, Russia’s RuNet). The protocols are open; anyone can implement them.

Common gotchas

  • “The internet is down” usually means your local connection is down. The internet itself is rarely down — your home router, ISP, or last-mile connection is. Try the downdetector approach: is a major site like Google reachable? If yes, the internet is fine.

  • Speed isn’t bandwidth. “I have 1 Gbps internet” tells you the capacity. Speed of a specific connection depends on latency, server speed, intermediate router congestion, and Wi-Fi quality.

  • Latency vs bandwidth. Bandwidth = how much data per second. Latency = how long the round trip takes. A 1 Gbps connection from Sydney to a US server can still feel slow because each round trip takes 150ms regardless of bandwidth.

  • WiFi is often the bottleneck. Home WiFi maxes around 1–2 Gbps in ideal conditions and much less in practice. Wired Ethernet is usually much more reliable for speed-sensitive work.

  • Some things aren’t on “the internet.” Local networks (your home WiFi between devices) don’t need to use the internet. A printer on your WiFi is reachable via local IP without any internet at all.

  • IPv4 is running out. There are only ~4.3 billion possible IPv4 addresses. The world has more devices. IPv6 (much larger address space) is rolling out, but slowly — most consumer connections still use IPv4 with NAT (network address translation) sharing one public IP across many devices.

  • NAT is why “self-hosting from home” is tricky. Your home router presents one IP to the internet; routing inbound connections to a specific device behind it requires port forwarding or services like ngrok / Cloudflare Tunnel.

  • The internet isn’t 100% reliable. Packets get dropped, routes change, undersea cables get cut by anchors. Protocols handle most of this transparently — but apps should be designed for retry and recovery.

  • Geography matters for hosting. A server in Sydney serving a user in Sydney is fast. The same server serving a user in Berlin is slow (~250ms round trip). CDNs and edge networks exist to put copies of your site closer to users.

  • Privacy isn’t built into the internet. The original design assumed cooperation; everything you send is visible to intermediaries unless encrypted. HTTPS / TLS / VPNs add privacy on top.

See also

Sources

Graph View

Backlinks