TCP — The Reliable Connection Protocol Explained

TCP (Transmission Control Protocol) is the workhorse of the internet. Around 80-90% of all internet traffic goes over TCP. When you load a webpage, send an email, or SSH into a server, TCP is doing the heavy lifting — turning the unreliable packet-switched internet into a reliable byte stream.

What TCP guarantees

TCP gives applications four guarantees on top of IP:

• Reliability — every byte sent is eventually received (or the connection fails loudly)
• Ordering — bytes arrive in the same order they were sent
• Flow control — fast sender doesn’t overwhelm slow receiver
• Congestion control — the network as a whole doesn’t melt down

The connection lifecycle

1. Connection setup    (3-way handshake: SYN, SYN-ACK, ACK)
2. Data transfer       (segments back and forth)
3. Connection teardown (4-way handshake: FIN, ACK, FIN, ACK)

The handshake gets its own article — coming up next.

Sequence numbers and ACKs

Every byte TCP sends gets a sequence number. The receiver acknowledges what it has received with ACK numbers. If an ACK doesn’t come back within a timeout, the sender retransmits.

Sender                          Receiver
Send "Hello" (seq 1, 5 bytes)  →
                              ←  ACK 6 (got bytes 1-5, expecting 6)
Send "World" (seq 6, 5 bytes)  →  [PACKET LOST]
                                  [silence]
[timeout — retransmit]
Send "World" (seq 6, 5 bytes)  →
                              ←  ACK 11 (got bytes 6-10)

Sliding window (flow control)

The receiver tells the sender how much it can buffer (the “window”). The sender keeps multiple unacknowledged segments in flight, up to the window size. As ACKs come back, the window “slides” forward.

If the receiver is overwhelmed, it shrinks the window. If it has plenty of buffer, it grows it.

Congestion control

TCP doesn’t just react to the receiver — it reacts to the network. When packets get dropped (which signals congestion), TCP cuts its sending rate. Then it slowly probes back up.

Algorithms you’ll hear about:

• Reno — classic, halves rate on loss
• Cubic — Linux default, smarter recovery
• BBR — Google’s, models the network’s actual capacity

cat /proc/sys/net/ipv4/tcp_congestion_control   # see your default
sudo sysctl -w net.ipv4.tcp_congestion_control=bbr   # switch to BBR

What TCP costs you

• 1.5 RTTs of latency just to establish a connection (handshake)
• Head-of-line blocking — one lost packet pauses everything until retransmit. (HTTP/3 / QUIC fixes this.)
• Per-connection state on both ends — bandwidth, buffers, timers, sequence numbers.

Where TCP is wrong choice

For real-time applications where stale data is worse than no data, UDP is better. Examples: live video, voice calls, online games, DNS queries. We’ll cover that next.

See it in action

# Open TCP connections on your machine
ss -tn state established

# Test TCP throughput between two hosts
iperf3 -s   # on server
iperf3 -c server.example.com   # on client

# Watch TCP retransmissions in real time
nstat -az | grep -i retrans

What to learn next

UDP — the simpler, faster, “fire and forget” alternative. Up next.