Learning Material

Networking Fundamentals: How Data Actually Travels

Learning Material · Networking

Cover: Networking Fundamentals: How Data Actually Travels

Data doesn't travel as one piece

When you send anything over a network — an email, a video call, a webpage request — it's broken into packets before it leaves your device. Each packet carries a small chunk of the data plus header information: where it came from, where it's going, and how it fits back together with the others at the destination.

IP addresses: the postal system of the internet

Every device on a network needs an address for other devices to reach it. IPv4 addresses (like 192.168.1.1) provide roughly 4.3 billion unique addresses — which sounded like plenty in the 1980s and has since run out, driving the slow rollout of IPv6, whose vastly larger address space (128 bits instead of 32) is meant to last indefinitely.

The layered model, without the jargon overload

Networking is usually taught as a stack of layers, each handling one job and trusting the layer below it to work:

A web browser only has to speak HTTP; it never has to think about electrical signaling on the wire underneath it. That separation is what lets you swap Wi-Fi for Ethernet without a single website needing to change.

TCP vs UDP: reliability has a cost

TCP guarantees packets arrive, in order, retransmitting anything lost — at the cost of extra overhead and latency. UDP just fires packets and doesn't check if they arrived. Video calls and online games often prefer UDP: a dropped frame that would take 200ms to retransmit is worse than just skipping it and moving on.

NAT: how your whole house shares one public IP

Your router almost certainly runs Network Address Translation, mapping every device on your home network to a single public IP address as seen from the internet. Outbound requests get temporarily tagged with a port number so replies find their way back to the right device — this is also why an outside server can't normally initiate a connection to your laptop directly.

Why this still matters day to day

Understanding this stack is what turns a cryptic error — "connection timed out" vs "connection refused" vs "DNS_PROBE_FINISHED" — into a specific, diagnosable problem rather than an unexplained failure. Each error maps to a different layer breaking, and knowing which layer points you straight at the fix.

Comments