TCP

If UDP is a postcard, TCP is a phone call with a transcript. Before talking, the two ends say hello and agree to converse (a connection); then everything one side says is delivered to the other in order, with nothing lost and nothing duplicated, as if a perfect, ordered pipe ran between the two programs. TCP takes the Internet's lossy, out-of-order, best-effort delivery and hides it behind a clean, dependable byte stream.

It does this with a bundle of mechanisms working together. A connection is opened with the three-way handshake, which synchronizes each side's starting sequence number. Every byte is numbered with a sequence number; the receiver returns acknowledgments saying which bytes it has; lost data is detected by missing acknowledgments or a timeout and is retransmitted. A sliding window lets many bytes be in flight at once for speed, while flow control (the advertised receive window) keeps a fast sender from overflowing a slow receiver, and congestion control keeps senders from overwhelming the network. The connection is closed politely with a FIN exchange.

Why it matters: TCP carries the lion's share of Internet traffic — the web, email, file transfer, and more — precisely because applications crave 'just give me my bytes, in order, intact.' Two honest caveats matter here. First, TCP is reliable but not secure: by itself it encrypts and authenticates nothing; TLS provides that on top of TCP (giving HTTPS). Second, TCP's in-order guarantee causes head-of-line blocking — one lost segment stalls delivery of everything behind it — which is one motivation for QUIC.