TCP

TCP is one half of the TCP/IP pair that powers the internet. Where IP handles addressing and routing, TCP handles the reliable delivery of data streams between two endpoints. It breaks data into segments, numbers them, tracks acknowledgements, and retransmits anything that gets lost — so the application above it always sees a complete, ordered byte stream.

The three-way handshake

Every TCP connection begins with three messages before a single byte of application data is sent:

1. SYN — client chooses a random initial sequence number and sends a synchronize request to the server
2. SYN-ACK — server acknowledges the client's SYN (ACK = client_seq + 1) and sends its own SYN with its own initial sequence number
3. ACK — client acknowledges the server's SYN (ACK = server_seq + 1); the connection is now established

This costs one full round trip. On a 50 ms connection, that is 50 ms of setup before the first HTTP request can be sent. TLS 1.3 adds another round trip for its handshake on top of TCP's — which is why QUIC (the protocol under HTTP/3) eliminates the TCP handshake entirely, combining transport and crypto setup in a single round trip.

Sequence numbers and acknowledgement

Each byte of data in a TCP stream has a sequence number. The sender assigns sequential numbers to each segment; the receiver sends ACKs telling the sender which byte it expects next. If the sender does not receive an ACK within the retransmission timeout (RTO), it resends the unacknowledged segment. Fast retransmit is a shortcut: receiving three duplicate ACKs for the same sequence number tells TCP that a segment was lost without waiting for the full RTO, triggering an immediate resend.

Flow control and the receive window

TCP uses a receive window to prevent the sender from overwhelming the receiver's buffer. The receiver advertises how many bytes it can accept; the sender may not have more than that many unacknowledged bytes in flight at any time. On high-bandwidth, high-latency paths (e.g., satellite or transcontinental fiber), the window must be large enough to keep the pipe full — a concept called the bandwidth-delay product. Window scaling (RFC 1323) extends the window beyond the original 64 KB limit.

Congestion control algorithms

TCP also limits its sending rate based on estimated network congestion, independently of the receive window. Two widely deployed algorithms are:

• CUBIC — the Linux default since 2006; uses a cubic growth function to probe for bandwidth, recovering quickly after loss
• BBR (Bottleneck Bandwidth and Round-trip propagation) — developed by Google; models the network's delivery rate and minimum RTT rather than reacting to loss, achieving higher throughput on long-distance and lossy paths

Congestion control means TCP throughput builds gradually. Short-lived connections on high-latency links may never reach full speed, which is why speed tests use multiple parallel TCP streams to keep the link saturated.

Connection teardown

TCP closes gracefully with a four-message sequence: the side that finishes sending sends a FIN, the other side ACKs it, sends its own FIN when ready, and the first side ACKs that. After sending the final ACK, the closing side enters TIME_WAIT state for 2× the maximum segment lifetime (typically 60–120 seconds). TIME_WAIT ensures any delayed packets from the old connection are absorbed before the port is reused, preventing them from corrupting a new connection on the same port tuple.

TCP head-of-line blocking

Because TCP guarantees in-order delivery, a single lost segment blocks all data behind it in the stream — even data that has already arrived in the receiver's buffer. HTTP/2 multiplexes many request streams over a single TCP connection to avoid multiple handshakes, but it cannot avoid TCP's head-of-line blocking: one lost packet stalls all streams simultaneously. HTTP/3 solves this by running over QUIC, which implements per-stream reliability at the transport layer so a single packet loss only stalls the affected stream.

TCP vs UDP at a glance

Frequently Asked Questions

What is the TCP three-way handshake?

Three messages establish a connection before data flows: SYN → SYN-ACK → ACK. This costs one round-trip of latency — on a 100 ms connection, 100 ms passes before the first byte of application data can be sent.

Why does TCP slow down on lossy networks?

TCP interprets packet loss as congestion and cuts its sending rate. On Wi-Fi or satellite with frequent packet loss, TCP throughput collapses even when bandwidth is available — this is why UDP-based protocols like QUIC perform better on unreliable links.

When should I use TCP vs UDP?

TCP for anything that must arrive complete and in order: web pages, email, file downloads, SSH sessions. UDP for real-time apps where a slightly stale or dropped frame is better than waiting for a retransmit: video calls, gaming, live streaming, DNS.