The minimum you need to know about TCP

Every time you load a webpage, send an email, or make an online purchase, your computer is quietly coordinating with another machine somewhere on the internet to make sure everything arrives correctly. The protocol responsible for a lot of that coordination is the Transmission Control Protocol, or TCP. TCP is one of those protocols that quietly underpins nearly everything on the internet. Here is the bare minimum you need to know about it.

What is TCP?

TCP is a connection-based protocol. Before any data is exchanged, the two machines talking to each other first establish an ordered, reliable communication channel. That channel guarantees data delivery and integrity — what you send is exactly what arrives on the other end.

That reliability comes at a cost though. TCP spends bandwidth on error checking and overhead that other protocols skip. You would reach for TCP in situations where losing data is not an option — web browsing, file transfers, online banking. If dropping a packet would break things, TCP is what you want.

The TCP Header

Every chunk of data sent over TCP is wrapped in a header that carries the metadata needed to keep the connection running reliably. The header looks like this:

The header lands somewhere between 20 and 60 bytes depending on the options field. That overhead is part of the cost of reliability.

The 3-Way Handshake

Before any real data moves, TCP requires both sides to shake hands. This three-step process syncs up the two machines and confirms that both are ready to communicate. There are a few message types involved:

| Message | Purpose | | ——- | ——————————————————— | | SYN | Initiates the connection and syncs sequence numbers | | ACK | Confirms receipt of the previous message | | SYN-ACK | Combined SYN from one side and ACK of the previous packet | | FIN | Terminates the connection |

Here’s how the exchange between a client and a server takes place.

1. (SYN) The client sends a SYN packet to the server containing a sequence number that marks the start of its data sequence (4321).
2. (SYN-ACK) The server responds with its own SYN, containing its sequence number (5501), along with an ACK. The acknowledgement number is the client’s sequence number plus one (4322), signalling it received the SYN and knows what to expect next.
3. (ACK) The client replies with an ACK, bumping the server’s sequence number by one (5502), and sets the SYN flag to 0 to signal the handshake is complete.

From here on, every packet sent over the connection must be acknowledged by the recipient. The sequence and acknowledgement numbers are how both sides track what was received, what was lost, and what was accidentally sent twice.

Flow Control

Not all machines are equal. One host might be able to push out 10 messages per second while the receiving server can only handle 5. Without any coordination, the server’s queue eventually fills up and packets start getting dropped.

TCP handles this with flow control. Throughout the connection, the receiver continuously tells the sender how much buffer space it has left. That available space is called the window size and it lives right there in the TCP header.

When the window size hits zero, the sender pauses. It only resumes when the receiver sends back a window size greater than zero. This back-and-forth keeps the faster side from overwhelming the slower one.

Lost Packets and Out-of-Order Delivery

Two more problems TCP quietly handles for you are lost packets and packets arriving out of order.

For lost packets, TCP uses a timeout. After sending a packet, the sender starts a timer and queues the packet for potential retransmission. If the timer expires without an ACK coming back, the packet gets sent again. There is a side effect here — if the original packet was just slow rather than truly lost, the receiver might end up with a duplicate. That is fine though; it simply discards the copy.

For out-of-order packets, TCP leans on those sequence and acknowledgement numbers again. If the receiver sees a sequence number that is higher than what it has acknowledged so far, it knows something in between went missing. It signals this to the sender by replying with an acknowledgement number pointing to the sequence number it actually expected, prompting a retransmission of the missing piece.

Trade-offs

TCP gives you reliability, ordering, flow control, congestion control, and error checking all baked in. What it asks for in return is overhead and latency — those data segments do not get transmitted immediately, and the header alone can run up to 60 bytes. For most applications that care about data integrity, that is a trade worth making.