If you're building anything that communicates over the Internet, chances are you're building on top of TCP. TCP (Transmission Control Protocol) is the protocol responsible for making communication reliable. Its job is to ensure data arrives completely, in the correct order, and without corruption. Whenever reliability matters more than raw speed, TCP is usually the protocol doing the work behind the scenes.
The Problem TCP Was Built to Solve
Data on the internet doesn't travel as one neat block. It gets broken into small pieces called packets, and those packets make their own way across the network, sometimes through completely different routes.
Say you wanted to send the word "HELLO." Behind the scenes, it might get chopped up like this:
Packet 1: HE
Packet 2: LL
Packet 3: O
Now here's the catch: nothing guarantees these packets show up in order, or even show up at all. One could get delayed. One could vanish entirely. They could arrive in the wrong sequence, like this:
3 → arrives first
1 → arrives second
2 → lost
If nothing was managing this process, you'd end up with garbled, incomplete data on the other end. That's the exact problem TCP exists to fix. It's built for situations where getting things right matters more than getting things fast.
What TCP Actually Does
TCP provides a handful of guarantees that make communication reliable.
Reliable delivery means TCP keeps track of what's been sent and what's been confirmed as received. If a packet goes missing, TCP notices and asks for it to be resent.
Ordered delivery handles the out-of-sequence problem. Even if packets 3, 1, and 2 show up in that strange order, TCP rearranges them back into 1, 2, 3 before handing the data off to whatever application is waiting for it.
Error checking catches corruption. If a packet arrives damaged, TCP treats it the same way it treats a missing one: it asks for a fresh copy.
Flow control prevents a fast sender from overwhelming a slower receiver. Imagine downloading a large file from a powerful server to an older phone. The server could send data much faster than the phone can process it, so TCP lets the receiver advertise how much data it can handle at a time. This keeps the sender from flooding the receiver with more data than it can keep up with. Under the hood, TCP manages this using a mechanism called the sliding window.
Congestion control protects the network itself. If every device transmitted data as fast as possible, routers would quickly become overloaded, leading to delays and packet loss. TCP watches for signs of congestion, such as lost packets or increasing delays, and temporarily slows down its transmission rate. Once the network clears up, it gradually speeds back up, balancing performance with stability. Algorithms like Slow Start and Congestion Avoidance are responsible for adjusting this transmission rate.
This is why so much of the internet relies on TCP underneath it. HTTP and HTTPS use it for web browsing, SMTP uses it for email, FTP for file transfers, and SSH for remote logins, basically anywhere that accuracy can't be compromised.
Establishing a Connection: The Three-Way Handshake
Before any data flows, TCP establishes a connection:
- SYN — Client sends a synchronization request with an initial sequence number
- SYN-ACK — Server responds, acknowledging the client's sequence and sending its own
- ACK — Client acknowledges the server's sequence
Client Server
|--- SYN (seq=1000) ---------------->|
|<-- SYN-ACK (seq=2000, ack=1001) ---|
|--- ACK (ack=2001) ---------------->|
| Connection open |
This three-step dance exists because TCP needs both sides to agree on sequence numbers. Without it, you can't guarantee ordered delivery.
Why Sequence Numbers Matter
One of TCP's most important ideas is that it numbers every byte, not every packet. The client and server each maintain their own independent sequence numbers, allowing both directions of communication to be tracked separately. These sequence numbers let TCP detect missing data, reorder packets that arrive out of sequence, and know exactly which bytes have already been received.
For example, after the three-way handshake, suppose the client's next sequence number is 1001 and it sends 500 bytes of data.
Seq = 1001
Length = 500 bytes
Those bytes are numbered 1001 through 1500. Once the server receives them all, it replies with:
(ACK = 1501)
ACK = Next expected byte.
Closing a Connection: The Four-Way Handshake
Opening a TCP connection takes three packets, but closing one usually takes four, because each direction closes independently:
- FIN — The client says, "I'm done sending data."
- ACK — The server acknowledges the client's FIN.
- FIN — Once the server has finished sending its own data, it sends a FIN.
- ACK — The client acknowledges the server's FIN, and the connection is fully closed.
Client Server
|--- FIN (seq=100) --------->|
|<-- ACK (ack=101) ----------|
|<-- FIN (seq=500) ----------|
|--- ACK (ack=501) --------->|
| Connection closed |
After the final ACK, both sides have agreed that no more data will be exchanged, and the TCP connection is fully closed.
TCP in Practice
Whenever you open a website, this entire process happens before the page begins loading.
Your browser first resolves the domain name into an IP address. It then performs the TCP three-way handshake with the server. Once the connection is established, the browser sends its HTTP request, the server responds, and when both sides are finished, the connection is eventually closed using the four-way handshake.
Although all of this usually happens in a fraction of a second, it's what makes web communication reliable.
Modern versions of HTTP (starting with HTTP/1.1) usually reuse an existing TCP connection instead of creating a new one for every request.
If your browser sends:
GET /data
POST /submit
both requests can usually travel over the same TCP connection.
Reusing an existing connection avoids repeating the handshake, reduces latency, and makes web applications much more efficient.
Wrapping up
None of this is something you'll ever see directly. You'll never watch a SYN packet leave your browser or manually reorder packets that arrived out of sequence. TCP handles all of that behind the scenes, quietly making unreliable networks feel reliable. Every time a page loads cleanly, a file arrives intact, or a message reaches its destination without errors, it's usually TCP quietly doing its job.
If you're interested in how it works under the hood, you can use tools like Wireshark to capture and inspect TCP packets on your own network.