What Actually Moves When You Send a Packet

Most people think data just appears somewhere when they click a link. It doesn't. Something has to carry it across a messy, unreliable infrastructure, and that someone is your network stack doing work you never asked for. I spent three days once troubleshooting why a production API was returning timeouts only between certain regions. DNS lookups fine, TLS handshake completing, but actual payload delivery failed consistently through specific carriers. Turned out to be path MTU discovery broken on a misconfigured ISP router somewhere in the middle. The workaround was enabling TCP MSS clamping on our load balancer to force fragmentation at the edge instead of hoping intermediate devices would cooperate. Took a month to reproduce in staging. The way computer networking works is less like a postal system and more like trying to deliver a house across town by breaking it into bricks, handing each brick to a stranger who might lose it, and hoping the recipient can rebuild it fast enough that nobody notices.

How Does Computer Networking Work at the Bit Level

Let's start with what actually happens when you type a URL and hit enter. Your browser hands the request to the operating system's network stack. The stack chops your data into segments, assigns sequence numbers, and passes them down through layers that were designed in the 1970s and haven't been fundamentally revised since. Each layer adds its own header. Application data gets wrapped in a transport segment with source and destination ports. That segment gets placed inside an IP packet with source and destination addresses. The packet gets stuffed into a frame with MAC addresses for the local hop. Each hop through the internet strips one header, reads where to send it next, adds a new link-layer frame, and forwards it. Your data arrives somewhere between one hundred milliseconds and several seconds later, usually intact, sometimes reordered, occasionally lost entirely. What beginners miss is that the internet was never designed to be reliable. It was designed to survive nuclear war, which is a completely different problem than making sure your video call doesn't buffer. TCP adds reliability on top of IP's best-effort delivery, but that adds latency, head-of-line blocking, and enough overhead that protocol designers spent the last decade inventing QUIC just to do what TCP does but faster. I learned this the hard way when a client complained their real-time trading platform had occasional latency spikes that correlated with nothing visible in their infrastructure. Traced it to a single congested peering point between two carrier networks that was dropping packets and forcing retransmissions. Their SLA covered uptime, not latency, so there was nothing we could do except route around it, which cost forty thousand dollars a month in additional bandwidth. The protocols aren't magic. They're arguments between different groups of engineers who couldn't agree on anything else, compromise documented as RFCs, and now so embedded in every device on earth that replacing them would require rebuilding the internet from scratch. HTTP sits on top of TCP sits on top of IP sits on top of Ethernet or WiFi or DSL or whatever physical medium connects you to the nearest exchange. Each layer solves a specific problem: transport handles end-to-end reliability, network handles routing across multiple hops, link handles the immediate physical connection between two devices. You can see this happening if you run a packet capture. Wireshark will show you the layers, each header explaining what that layer cares about before passing data down to the next one. Most of the bytes you see are overhead, not actual application data. A typical HTTPS request might be two hundred bytes of payload wrapped in eight hundred bytes of headers across five layers. That's the tax you pay for everything working across an infrastructure you didn't build and can't control. Modern networking adds complexity on top of this model because applications demand more than what the original protocols provide. TLS encrypts everything to prevent eavesdropping, HTTP/2 multiplexes multiple requests over a single connection to avoid head-of-line blocking, and QUIC moves congestion control into user space to allow faster deployment without touching kernel code. Each addition solves a real problem but also adds another layer of debugging when something breaks in production at 2 AM.