https://www.youtube.com/watch?v=IImJtO8Jn7k
Every time you load a webpage, your data gets chopped into pieces, flung across the planet through dozens of machines that could drop it at any moment — and it arrives perfectly in order. The protocol responsible is TCP, and once you see how it works, the internet stops feeling like magic.
The 3-Way Handshake
Before your computer sends a single byte of data, it has to introduce itself. Your machine sends a SYN packet (synchronize). The server responds with SYN-ACK (synchronize acknowledged). Your machine fires back a final ACK.
Three packets. No data yet. Just two machines making sure they can hear each other.
But those SYN and ACK packets aren't just saying hello — they're exchanging sequence numbers. Random starting numbers that both sides will use to track every single byte that flows between them. Think of it like agreeing on a numbering system before the conversation starts.
Segmentation: Chopping Data Into Pieces
Say you're downloading an image. It's 100 KB. TCP doesn't send that as one giant blob — networks have a maximum packet size, usually around 1,500 bytes. So TCP slices your data into segments.
Each segment gets a sequence number — not segment 1, segment 2 — the actual byte offset. Segment one starts at byte 0. If it carries 1,400 bytes, the next segment starts at byte 1,400. Then 2,800.
These segments don't take the same path. One might go through Chicago, another through London. They arrive out of order. But the receiver looks at the sequence numbers and slots each one into the right position — like puzzle pieces that can arrive in any order.
For every segment that arrives, the receiver sends back an ACK with the sequence number of the next byte it expects. That ACK is a receipt: "I got everything up to here, send me what comes next."
The Sliding Window
The sender could wait for an ACK after every segment. Send one, wait. Send one, wait. Perfectly reliable — and painfully slow.
So TCP uses a sliding window. The sender is allowed to have multiple segments in flight simultaneously. Picture a row of segments lined up. The window is a frame that sits over this row — everything inside can be sent. As ACKs come back, the window slides forward.
| Window size | Behavior |
|---|---|
| 1 | Stop-and-wait (slow) |
| 4 | 4 segments in flight at once |
| 64+ | High throughput on fast links |
When a segment gets lost, the receiver sends duplicate ACKs — the same ACK number repeated. After three duplicates, the sender immediately retransmits the lost segment without waiting for a timeout. This is fast retransmit — the network itself is telling you something went wrong.
The receiver can also shrink the window to say "slow down, I'm overwhelmed." This is flow control — the receiver controls the pace through one elegant mechanism.
Congestion Control: The TCP Sawtooth
The sliding window handles receiver capacity. But there's another bottleneck — the network itself. Routers have limited buffers. If everyone blasts data at full speed, those buffers overflow and everything grinds to a halt.
TCP probes the network to find its limit:
- Slow start — Send 1 segment. ACK comes back → double to 2. Then 4. Then 8. Exponential growth.
- Congestion avoidance — After hitting a threshold, switch to linear growth. Add 1 segment per round trip.
- Loss detected — A packet vanishes. TCP cuts its sending rate in half. Immediately.
- Climb again — Linear growth, pushing toward the limit. Until another loss. Cut in half. Climb again.
This creates the famous TCP sawtooth — a zigzag of growth and cuts that repeats forever. And here's the beautiful thing: every TCP connection on the internet does this simultaneously. Millions of connections, all independently probing and backing off, sharing bandwidth fairly without any central coordinator. No traffic cop. Just math.
The Graceful Goodbye
The data is sent. Every byte acknowledged. But the connection is still open — ports, memory, buffer space all held. TCP needs a graceful close.
The client sends FIN (I'm finished). The server ACKs it. But the server might still have data, so the connection is now half-closed. When the server finishes, it sends its own FIN. The client ACKs. Four packets, two FINs, two ACKs.
After that final ACK, the client enters TIME-WAIT — hanging around for up to two minutes. Why? If the last ACK got lost, the server would re-send its FIN, and the client needs to be there to re-ACK it. TCP doesn't slam the door — it makes sure everyone got the message.
The Invisible Guarantee
From handshake to teardown, TCP gives you something remarkable: a reliable stream of bytes on top of a network that offers no guarantees. It slices your data, numbers every byte, retransmits what's lost, paces what's sent, and cleans up when it's done. All invisible. All in the background.
Every time you load a page, stream a video, or send a message — TCP is the reason it just works.
References:
Watch the full animated breakdown: How TCP Survives the Worst Network on Earth
Top comments (0)