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.
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.
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 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.
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.
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