Most people picture internet data moving the way a train moves: a connected sequence, car by car, from source to destination. The actual mechanism is closer to releasing a thousand paper planes into a hurricane and trusting that the right ones land in the right yard. That the system works as reliably as it does is one of the more underappreciated engineering achievements in computing.
1. Your Data Gets Cut Into Pieces Before It Goes Anywhere
When you load a webpage or send an email, the operating system doesn’t transmit the data as one continuous stream. It breaks the payload into packets, each typically between 1,000 and 1,500 bytes for Ethernet networks (a value known as the Maximum Transmission Unit, or MTU). A single 1 MB image becomes roughly 700 separate packets before it crosses your router.
Each packet gets a header containing the source IP address, destination IP address, sequence number, and other control data. The sequence number is critical: it’s how the receiving machine knows in what order to reassemble the pieces, because those pieces are not guaranteed to arrive in order.
2. Each Packet Finds Its Own Route
This is where the train metaphor breaks down completely. Packets from the same transmission can take entirely different physical paths across the internet. One packet might route through Chicago, another through Dallas. If a router along the way is congested or goes offline, subsequent packets get redirected automatically without any notification to either end of the connection.
The routing decisions are made by routers running protocols like BGP (Border Gateway Protocol), which continuously share information about which networks they can reach. No single router knows the full map of the internet. Each one only knows its neighbors and makes a local decision: given where this packet needs to go, which of my connections gets it closer? The result is a decentralized, self-healing network. This design came directly from ARPANET-era research aimed at building a communication system that could survive partial destruction.
3. IP Delivers. TCP Verifies. They Are Not the Same Thing.
IP (Internet Protocol) is the addressing and delivery layer. It gets packets from point A to point B, mostly. It makes no guarantees about arrival order, delivery confirmation, or duplicate prevention. IP is, by design, unreliable.
TCP (Transmission Control Protocol) sits on top of IP and adds the guarantees that applications actually need. It tracks which packets arrived, sends acknowledgment signals back to the sender, requests retransmission of anything that went missing, and reorders packets that arrived out of sequence before passing the data to the application. When you download a file and it arrives intact, that’s TCP doing the accounting work that IP never promised to do. The two protocols are complementary by design, not redundant.
4. The “Three-Way Handshake” Happens Before Any Data Moves
Before your browser receives a single byte of a webpage, TCP runs a connection setup sequence. Your machine sends a SYN (synchronize) packet to the server. The server responds with SYN-ACK (synchronize-acknowledge). Your machine replies with ACK (acknowledge). Only after this exchange does data transmission begin.
This handshake establishes sequence numbers on both sides and confirms that both machines are ready to communicate. It adds latency, which is why the physical distance between a user and a server has measurable effects on load times even before any payload transfers. A server in Singapore responding to a user in London will complete this handshake in roughly 170-180 milliseconds of round-trip time, regardless of how fast the actual data transfer is. This is why content delivery networks exist: moving the server closer to the user speeds up the handshake, not just the download.
5. Congestion Control Is What Keeps the Internet from Collapsing
TCP doesn’t blast all packets at maximum speed from the start. It uses a mechanism called slow start: begin with a small transmission window, double it with each successful acknowledgment round, then back off sharply when packet loss is detected. Packet loss is TCP’s primary signal that a network path is congested.
This is a globally distributed backpressure system. Every TCP connection on the internet is independently throttling itself based on observed congestion, with no central coordinator. The system isn’t perfect (buffer bloat is a real and persistent problem), but the core design has kept the internet functional through traffic volumes its designers never anticipated. The algorithm underpinning this, developed largely by Van Jacobson at Lawrence Berkeley National Laboratory in the late 1980s, is credited with preventing the internet from collapsing under its own growth at a critical period.
6. UDP Throws All of This Away on Purpose
For some applications, TCP’s reliability guarantees are a liability, not an asset. Video calls and online games cannot wait for a retransmitted packet that arrives 200 milliseconds late. A dropped video frame is better replaced by the next frame than recovered from the past.
UDP (User Datagram Protocol) operates over IP without any of TCP’s overhead: no handshake, no acknowledgment, no retransmission, no ordering. Applications using UDP handle whatever reliability they need at the application layer, if they need it at all. Modern video streaming protocols and the QUIC protocol underlying HTTP/3 use UDP as the base, building custom reliability logic optimized for their specific latency requirements. The choice of transport protocol is, at root, a product decision about which failure mode is more acceptable.
7. Your “Connection” Is an Abstraction, Not a Physical Thing
When you have an open connection to a server, there is no wire, channel, or dedicated path being held open for you. The connection state is just a pair of data structures: one on your machine, one on the server, each tracking sequence numbers, window sizes, and acknowledgment states. The packets flowing between them are sharing physical links with millions of other packets from millions of other connections.
This matters for understanding why connections drop. If either machine crashes, or if a network path changes, or if a NAT device forgets about a long-idle connection, the “connection” simply ceases to exist. There’s nothing to tear down on the physical layer because there was never anything physical there to begin with. The reliability of a TCP connection is entirely a function of two cooperating software processes maintaining consistent state. As what HTTPS does to keep your data private shows, the security layers built on top of TCP inherit this same property: they are logical agreements, not physical locks.
