TCP

In short: Transmission Control Protocol — a connection-oriented transport protocol that guarantees data packets arrive at the recipient complete, in the right order and without duplicates.

In more detail: Before the actual data transfer, TCP establishes a connection via the three-way handshake (SYN, SYN-ACK, ACK). Lost packets are detected and resent, which makes TCP reliable but slower than UDP. Used wherever completeness matters more than speed — e.g. for HTTP, FTP or email protocols.

In Depth

Connection setup and segmentation

Before a single byte of payload flows, both sides negotiate initial sequence numbers via the three-way handshake (SYN → SYN-ACK → ACK) and confirm that both directions of the connection are actually reachable. The data to be sent is split into segments whose size is limited by the “maximum segment size” (MSS) — typically chosen so that a segment including all headers fits into a single Ethernet frame (1500-byte MTU), so that no additional fragmentation is needed at the IP level. Each segment gets a running sequence number (counted in bytes, not segments), so that the recipient can put them together in the right order even if they arrive out of order via different network paths.

Reliability: ACKs, retransmission, checksums

Every received segment is acknowledged with an ACK naming the next expected sequence number (“cumulative ACK”) — if an acknowledgement doesn’t arrive within a dynamically calculated timeout (retransmission timeout, RTO), TCP automatically resends the corresponding segment. A checksum in the header detects data damaged along the way; a segment with a wrong checksum is silently discarded and also has to be requested again. Modern TCP implementations additionally use “selective ACK” (SACK), with which the recipient can tell the sender which individual gaps in the sequence are missing, instead of retransmitting the entire subsequent data stream on every loss.

Flow control and congestion control

Two different mechanisms govern how much data may be “in flight”. Flow control (the “receiver brake”) prevents a fast sender from flooding a slower recipient with more data than its receive buffer can process — for this, the recipient continuously reports its available “receive window”. Congestion control (the “network brake”) is independent of this: TCP starts cautiously with a small amount of data (“slow start”) and gradually increases the amount sent until a packet loss indicates an overloaded connection — then the amount sent is drastically reduced and the increase starts again, more slowly. This interplay of accelerating and braking ensures that many simultaneous TCP connections share a limited line fairly instead of flooding it individually.

Connection teardown

Unlike the three-way setup, an orderly teardown typically runs via a “four-way handshake” (FIN/ACK from both sides independently, since a TCP connection consists of two separate data directions, each of which has to be ended on its own). One side can thus already be “done sending” while it’s still receiving data from the other side (half-close). An abrupt abort via the RST flag bypasses this orderly sequence completely and is mostly used for errors, for example when a port isn’t open in the first place.

Weighing it up against UDP

This reliability has its price: the handshake already costs a complete round trip (latency) before the actual data transfer, and every acknowledgement/retransmission needs additional time. For applications where a single lost packet is bearable but freshness matters (video streaming, VoIP, online gaming), UDP is therefore often the better choice — TCP consistently optimises for completeness, UDP for speed. This difference shows in practice in the traceroute command, for example, which sends UDP packets by default because a loss doesn’t matter there, while HTTP, FTP and email protocols rely consistently on TCP, because an incomplete web page or file would be useless.

See also: UDP, Three-way handshake, SYN