TCP and UDP

TCP vs UDP

The transport layer offers two fundamentally different contracts:

TCP (Transmission Control Protocol) provides:

• Reliability — every segment sent is acknowledged; lost segments are retransmitted automatically.
• Ordering — segments are delivered to the application in the order they were sent, regardless of the order they arrived.
• Flow control — the receiver advertises a window size telling the sender how much data it can accept; the sender does not overwhelm the receiver.
• Congestion control — TCP detects packet loss as a signal of network congestion and reduces its sending rate.

This reliability comes at a cost: every connection requires a handshake (see below), every lost packet causes a retransmission delay, and the ordering guarantee means a slow packet holds up all packets behind it ("head-of-line blocking").

UDP (User Datagram Protocol) provides:

• No guarantee of delivery — datagrams may be dropped silently.
• No ordering guarantee — datagrams may arrive out of order.
• No congestion control — UDP sends as fast as the application instructs.
• Low overhead — just 8 bytes of header vs 20+ for TCP.

UDP is the right choice when low latency matters more than reliability: DNS queries, live video/audio streaming, multiplayer games, and the QUIC protocol (which implements its own reliability on top of UDP to avoid OS-level head-of- line blocking). If your application can tolerate occasional lost packets, or can implement its own selective retransmission, UDP gives you control that TCP doesn't.

The TCP three-way handshake

Before any application data flows over TCP, the two endpoints must agree that a connection exists. They do this with three messages:

Client                         Server
  |------ SYN (seq=x) -------->|   "I want to connect; my starting sequence is x"
  |<-- SYN-ACK (seq=y, ack=x+1)|   "OK; my starting sequence is y; I acknowledge x"
  |------ ACK (ack=y+1) ------->|   "I acknowledge y; connection is established"
  |                             |
  |==== application data ======>|

SYN (synchronise) — the client picks a random initial sequence number x and sends it. The sequence number ensures that data segments are assembled in the correct order and that retransmitted data is not confused with new data.

SYN-ACK — the server acknowledges the client's sequence number (x+1 means "I got everything up to and including x") and sends its own random initial sequence number y.

ACK — the client acknowledges the server's sequence number. The connection is now established from both sides.

This costs one full round-trip before any application data can be sent. HTTPS adds a TLS handshake on top. HTTP/3 (QUIC) merges the transport and cryptographic handshakes into a single round-trip to reduce this latency.

When closing, TCP uses a four-way FIN/ACK exchange (or a simultaneous close) to drain any remaining in-flight data before teardown.