What is the internet?
The internet is a network of networks. It is not a single machine or company, but millions of independent networks that agree to speak the same protocols so they can pass data to one another. That agreement is what lets a laptop in one country talk to a server in another in a fraction of a second.
The World Wide Web is one service that runs on this network, using HTTP, URLs and browsers. The internet carries much more: email, video calls, file transfer and countless other applications. Understanding the underlying network explains why the web behaves the way it does.
Clients and servers
Almost everything on the web follows a client-server model. A client sends a request; a server sends a response.
- The client is usually a browser, but it can be a mobile app, a script or another server.
- The server is a computer that listens for requests and returns resources such as HTML, JSON, images or files.
This request/response cycle is the heartbeat of the web. Every page load, API call and image download is one or more of these exchanges.
IP addresses and packets
Every device on the network has an IP address, like a postal address for data. When you send something, it is split into packets: small chunks of data, each labelled with a source and destination address.
Packets travel independently. Routers along the way forward each one toward its destination, and they may take different paths. The receiving machine reassembles them into the original message. This design, called packet switching, is what makes the internet resilient — if one route fails, packets can go another way.
The transport layer: TCP and UDP
IP gets packets to a machine, but it does not guarantee they arrive in order or at all. That is the job of the transport layer.
- TCP establishes a connection and provides a reliable, ordered stream. It retransmits lost packets and is what HTTP uses.
- UDP is connectionless and does not guarantee delivery. It is faster and is used for live video, games and DNS.
On top of TCP, TLS encrypts the connection so nobody in the middle can read or alter it. HTTPS is simply HTTP over TLS.
DNS: names to addresses
People remember names, not numbers. DNS (the Domain Name System) is the phone book that maps a name like example.com to an IP address.
When you visit a domain, your computer asks a resolver, which queries a hierarchy of name servers until it reaches the authoritative one. The answer is cached for a period so repeat lookups are instant. The DNS guide covers the details.
HTTP: the language of the web
Once a connection exists, the browser and server speak HTTP. The client sends a request with a method (like GET or POST), a path and headers; the server replies with a status code, headers and a body.
GET /index.html HTTP/2
Host: example.com
Accept: text/html
HTTP/2 200 OK
Content-Type: text/html
Content-Length: 1256
<!doctype html> ...
The HTTP guide covers methods, status codes, headers, cookies and caching.
What happens when you visit a page
Putting it together, loading a page looks like this:
- Resolve the domain with DNS to get an IP address.
- Connect to that address over TCP.
- Handshake with TLS to establish an encrypted channel.
- Request the HTML over HTTP.
- Parse the HTML and discover CSS, JavaScript, images and fonts.
- Request each of those, often in parallel, and render the page.
Each additional resource repeats part of the journey, which is why fewer requests and smaller assets make pages faster. The Browsers & Rendering guide picks up from step 5.
Routers, ISPs and the backbone
Between you and a server are many networks. Your traffic leaves through your ISP, crosses regional and national networks, and may travel along undersea cables between continents. Routers at each hop decide where to send the next packet based on routing tables.
You never see this, but it explains latency: the farther the data travels and the more hops it makes, the longer the round trip takes.
CDNs and caching
A content delivery network places copies of your content on servers around the world, so users are served from a nearby location. That cuts latency, reduces load on your origin server and improves reliability.
Caching works at several layers: the browser cache, the CDN, and the origin server. Correct cache headers let content be reused instead of refetched, which is one of the biggest performance wins available.
Best practices
- Serve everything over HTTPS, and redirect HTTP to HTTPS.
- Use a CDN for static assets and cacheable content.
- Set sensible cache headers so repeat visits are fast.
- Keep requests few and payloads small.
- Prefer HTTP/2 or HTTP/3, which multiplex many requests over one connection.
- Monitor latency and time to first byte, not just page weight.
Common mistakes
- Confusing the internet with the web.
- Assuming data takes a single fixed path.
- Serving sensitive content over plain HTTP.
- Ignoring caching and refetching everything on every visit.
- Treating DNS as instant and ignoring TTLs during migrations.
- Putting one server in one region and serving a global audience from it.
Where to go next
The internet is the foundation under everything you build. Go deeper on the protocol with the HTTP guide, learn how names resolve in the DNS guide, and see what the browser does with the bytes in Browsers & Rendering. Then open your browser’s network panel and watch a real page load unfold.