What Is a Network, and What Is the Internet?

A network is just connected things that talk

Strip away the jargon and a network is almost embarrassingly simple: two or more devices joined by some link, agreeing to exchange data. Your laptop and your printer over a cable is a network. Your phone and a Wi-Fi router is a network. The thing that makes it a network is not the wire or the radio wave — it is that both sides have agreed, in advance, on how to take turns and what their messages should look like. We give the formal name computer network to this idea: a set of devices interconnected so they can share data.

It helps to split every network into two worlds. At the edge sit the devices you actually care about — laptops, phones, servers, smart doorbells. We call each of these an end system (or a host): something that runs your programs and is the source or final destination of data. Everything in between — the boxes whose only job is to shuttle data along — is the network core. The edge is where the conversation begins and ends; the core is the road network in between.

The Internet: a network of networks

Here is the move that changes everything. The Internet (capital I) is not one giant network. It is tens of thousands of separate, independently-run networks — your home network, your university, Google's network, a cellphone carrier's network — that have agreed to interconnect. Nobody owns it. It works because all those networks speak a common language. That language is the TCP/IP family of protocols, and the universal glue at its center is the Internet Protocol, or IP. Any network that speaks IP can join, which is exactly why the Internet could grow from four computers in 1969 to billions.

The word doing the heavy lifting above is protocol. A protocol is an agreement with three parts: the format of the messages (which bytes mean what), the order they may be sent in (you greet before you ask), and the actions taken when a message arrives or a timer fires. Humans use protocols too — a phone call is "Hello? — Hi, it's me — ...". When two machines follow the exact same protocol, neither has to understand the other's hardware, operating system, or language; they only have to follow the same script.

Where do these agreed-upon scripts come from? Mostly from open documents called RFCs (Request for Comments). An RFC is a published specification — IP, TCP, HTTP, DNS all live in numbered RFCs that anyone can read for free. That openness is not a footnote; it is the reason a phone built by one company can talk to a server built by another half a world away.

Why we chop data into packets

Now, how does data actually move through the core? You might imagine the network setting up one private wire from sender to receiver for the whole conversation. That is circuit switching, and it is how the old telephone system worked: reserve a path, keep it for the entire call, even during silence. It guarantees a steady rate, but it wastes the link whenever nobody is talking — and computer conversations are mostly silence broken by sudden bursts.

The Internet made the opposite choice: packet switching. We chop each message into small, self-contained chunks called packets, stamp each one with the destination address, and let the network forward them independently, hop by hop, sharing the links with everyone else's packets. Think of a packet as a postcard: it carries an address and a piece of the message, and the postal system reads the address at each sorting office to send it onward. No path is reserved in advance, so when you pause, your share of the link is instantly free for someone else.

There is a small but crucial mechanic that makes this work, called store-and-forward. A switch in the core must receive a whole packet and check it before sending it on — it cannot start forwarding a packet it has only half-received. So at each hop the packet is fully stored, then forwarded. This is why a packet's journey is a relay of complete hops, not a continuous slide, and it is the first place where delay quietly accumulates (the next guide measures exactly how much).

The one big idea: layering

Imagine trying to write the program for a web browser if you had to personally manage the voltage on a copper wire, the radio timing of Wi-Fi, the route across forty networks, and the rules of the Web all in one tangle. It would be impossible. The escape from that nightmare is the single most powerful idea in networking: layering. We split the whole problem into a stack of layers, where each layer does one job and offers a clean service to the layer above, asking only a clean service from the layer below.

The mechanism that makes layers stack is encapsulation: each layer wraps the data from above in its own header (and sometimes a trailer) before handing it down, like nested envelopes. The Web layer's message goes inside a transport envelope (adding, for example, a port number so the receiver knows which program to deliver to), which goes inside an IP envelope (adding the destination address), which goes inside a link envelope for the next hop. At the far end the envelopes are opened in reverse. Each layer reads only its own envelope and ignores the contents — which is exactly what lets you swap Wi-Fi for fiber without touching your browser.

Sending (top -> bottom), each layer adds its envelope:

  Application:  [ GET /index.html ]                         <- your data
  Transport:    [ TCP hdr | GET /index.html ]               <- adds port, seq#
  Network:      [ IP hdr | TCP hdr | GET /index.html ]      <- adds dst address
  Link:         [ Eth hdr | IP hdr | TCP hdr | data | FCS ] <- adds MAC, checksum
                       v  put on the wire / air  v

Receiving: peel the envelopes back off, bottom -> top.

Two maps of the layers: OSI vs TCP/IP

Two famous layer maps will follow you through the rest of this ladder. The OSI model is a tidy seven-layer reference (physical, data link, network, transport, session, presentation, application) designed by committee as a teaching and design framework. The TCP/IP model is the leaner, four-layer stack the real Internet actually runs (link, internet, transport, application). Be honest about the relationship: OSI is the classroom diagram everyone learns from, but the working Internet is TCP/IP. People casually borrow OSI's numbers — "a layer-2 switch," "a layer-7 load balancer" — even though their boxes run TCP/IP.

So why learn the seven-layer one at all? Because its vocabulary is everywhere, and its extra layers (session, presentation) name real concerns even when TCP/IP folds them into the application. Treat OSI as the reference language and TCP/IP as the implementation. Guide 5 of this rung puts them side by side, box for box; for now just hold the shape in your head: a stack, data flowing down through envelopes on the way out and up out of envelopes on the way in.

1. Pick the layer you actually care about right now — there is almost always exactly one. Loading a web page? That is the application layer.
2. Ask what clean service the layer below promises it. The Web simply asks transport for "a reliable byte pipe to that host and port," and trusts it.
3. Let each lower layer keep its own promise without you watching: transport handles loss and order, the network handles the route, the link handles one hop.
4. When something breaks, you now know which layer to inspect — and that is the real, day-to-day payoff of layering.