What Is a Network

Someone types an address into a browser. About a second later a page fills the screen. In that second, a request left one machine, crossed equipment owned by companies that have no idea who sent it, arrived at a machine possibly on another continent, and came back with an answer that arrived in the right order with nothing missing.

None of that is magic. It's a handful of small, unglamorous rules, applied by machines that are individually pretty stupid. This lesson lays out the rules. Every tool in every later lesson is just an application of them, so the tools stop looking clever once the rules are clear.

Machines that can reach each other

A network is a set of machines that can send each other messages. That is the entire definition. There's no minimum size: two laptops connected by a cable are a network, and so is the internet.

Every machine attached to a network is a host. A laptop is a host. A phone is a host. A printer is a host. The web server answering the browser is a host, and so is the plastic box in the corner of the room that the Wi-Fi comes out of. If it's on the network and it can send or receive data, it's a host. The word says nothing about size, importance, or whether a person is sitting at it.

Hosts need a way to refer to each other, and the network needs something it can act on mechanically. That's the IP address: a numeric label like 192.168.1.42 or 93.184.216.34 that identifies one machine on a network. A street address is the usual comparison and it's a decent one, with one warning attached. A street address is more or less permanent. An IP address is not. Most hosts are handed an address when they join a network and lose it when they leave, and the same address gets handed to a different machine next week. The address describes where a host currently sits, not who it is.

One more limit worth setting early. An IP address answers exactly one question: which machine. It says nothing about which program on that machine should get the data. A single host might be running a web server, a mail server, and a remote login service at once, and the IP address alone cannot tell them apart. Something else has to, and a later lesson covers what.

Data travels in small labeled chunks

No host sends a 4 MB photo as one continuous blob. The sending host chops the data into packets, each one a few hundred to a few thousand bytes, and sends them one after another.

Two reasons for that, and both matter. A link is shared, so one machine transmitting a giant unbroken block would freeze everyone else on that link until it finished. And data gets damaged in transit. When a 4 MB blob is one unit, any single flipped bit means resending 4 MB. When it's chopped up, one damaged chunk means resending that chunk.

Every packet has two parts. The header is the labels stuck on the front: where the packet came from, where it's going, and a set of bookkeeping fields that let the receiver put things back together. The payload is everything after the header, meaning the actual data being carried. Postcard, roughly: the address side is the header, the message side is the payload. The carrier reads only the address side, and does not care at all what the message says.

Real numbers make this concrete. A common Ethernet link carries at most 1500 bytes per packet. A standard IP header eats 20 of those bytes and a standard TCP header eats another 20, which leaves 1460 bytes of payload. So a 4 MB photo (4,194,304 bytes) leaves the sending host as roughly 2,900 packets, each one independently addressed, each one making its own way across.

That "somebody else" is the point of the next idea.

Both sides have to agree first

Two machines exchanging bytes is useless unless each one knows what the other's bytes mean. A protocol is the agreed set of rules for a conversation: what each side may say, in what order, and what each message means. Both ends run the same rules or neither is understood. A machine sending perfectly valid web traffic to a program expecting mail traffic gets nowhere, even though every packet arrives intact.

Protocols stack. One set of rules gets packets from address to address. A different set sits on top and handles the reassembly and re-sending the network itself refuses to do. A third sits on top of that and defines what a request for a web page looks like. Each layer trusts the one below to do its narrow job.

In almost every exchange, one side asks and the other answers. The asker is the client. The answerer is the server, a word that means both the program that listens and the machine it runs on, which is a lifelong source of confusion and is not going to get fixed. A browser is a client. The machine that hands it the page is a server. The asymmetry matters more than it looks: the server is the side sitting there accepting messages from strangers, which is exactly why servers, not browsers, are what gets attacked.

Nearby, and far away

A LAN, local area network, is the small network shared by machines in one place: a house, an office floor, a lab. Hosts on the same LAN reach each other directly, without anything in between making routing decisions about them.

A WAN, wide area network, connects separate local networks across distance. The internet is the largest one that exists. It is not a different kind of thing, just LANs joined up at enormous scale.

Two pieces of equipment do the joining, and they're constantly confused with each other.

A switch moves data between machines inside one LAN. It does not use IP addresses at all. It uses the MAC address, a hardware identifier burned into each network interface at the factory and written as six hex pairs like 00:1a:2b:3c:4d:5e. A MAC address means something only on the local network, and it does not survive a trip to another one.

A router forwards packets between different networks, picking where each packet goes next based on its destination IP address. The specific router a host sends to when the destination is not on its own LAN has a name: the default gateway. It's the exit door. On a home network, the switch, the router, the gateway, and the Wi-Fi radio are usually all the same plastic box, which is exactly why the four words get blurred together.

On a Linux host, ip route prints where packets go.

$ip route

Two lines, two rules, and the second one is read first. Anything addressed inside 192.168.1.0/24 goes straight out of the interface named eth0 to the local network, no router involved. Everything else falls to default and gets handed to 192.168.1.1, the gateway. The /24 is how the host knows where its LAN stops, and the next lesson takes that apart properly. The addresses here come from one specific machine and will differ on any other.

The MAC addresses of local neighbors are visible too.

$ip neigh

Every entry is a machine on the same LAN. Nothing beyond the gateway ever shows up here, and that's not a limitation of the command. It's the shape of the system: hardware addresses stop at the edge of the local network.

Three things that trip people up later

The network does not deliver files. It delivers packets, and it's allowed to lose them, duplicate them, and hand them over in the wrong order. Every guarantee that feels like the network's doing is a protocol running on the hosts at either end, cleaning up after it. Tools that look broken are often just showing this honestly.

Reaching a host is not the same as reaching a service on it. A machine can answer at its IP address while nothing on it is willing to talk, or while a filter in between silently drops the request. "The address responds" and "the thing there will speak to me" are two separate questions, and a lot of early confusion comes from treating them as one.

An IP address is not an identity. It's a lease. It changes when a host moves networks, it changes when the lease expires, and equipment along the way rewrites addresses as a matter of routine. Any conclusion built on "this address is that machine" is standing on sand unless something else backs it up.

Hosts, addresses, packets with a header and a payload, protocols, and the equipment that moves them: that's the vocabulary. What it doesn't give is a way to talk about how the protocols stack, which is a problem, because "which layer is this happening at" is the question that ends most networking arguments. The next lesson, the OSI model, hands over that map.