TCP vs UDP

Lesson 2 put a segment at Layer 4, between the application's data and the IP packet that carries it. Layer 4's job is to hand data from one process to another, and there are two protocols that do it in opposite ways. TCP guarantees the data arrives, in order and intact, and pays for that guarantee in setup time and overhead. UDP simply sends, with no promises at all — which makes it smaller and faster.

Neither is better. They are answers to different questions, and choosing between them is the point of this lesson.

Before TCP sends any data at all, the two ends establish a connection with a three-way handshake:

1. SYN — the client proposes a connection and states the sequence number it will start counting from.
2. SYN-ACK — the server agrees, acknowledges the client's number, and states its own starting number.
3. ACK — the client acknowledges the server's number. The connection is established and data can flow.

From then on every byte is numbered with a sequence number and confirmed with an acknowledgment. Anything that goes unacknowledged is retransmitted. A window size controls how much data may be in flight before the sender has to stop and wait, which keeps a fast sender from swamping a slow receiver. All of that machinery exists for one reason: to make sure what arrives is exactly what was sent. That is why web pages, remote shell sessions, and file transfers use TCP — a single missing byte would corrupt the result.

UDP has no handshake, no acknowledgments, and no retransmission. A datagram is addressed and sent, and the sender moves on without waiting to hear anything back.

That sounds like a disadvantage until you consider what TCP's guarantees actually cost. In a voice call, a lost audio sample retransmitted half a second later is useless — the conversation has moved on, and stopping to wait for it would be worse than the gap. The same reasoning applies to live video. Quick request-and-response services such as DNS and DHCP use UDP for a different reason: the exchange is so short that setting up a connection would cost more than simply asking again. Where an application does need reliability over UDP, it has to provide that itself.

One host runs many things at once — a browser, a mail client, a file sync, each with traffic in flight. The IP address gets data to the right host, but something has to get it to the right process. That is what a port number does. Both TCP and UDP tag every flow with a 16-bit port number, giving a range of 0 to 65535.

Servers listen on well-known ports so clients know where to find them. Clients pick a temporary ephemeral port as the source of each new connection, so replies can be matched back to the right conversation. Put simply: the IP address finds the host, and the port finds the process.

• TCP is connection-oriented and reliable: handshake, sequencing, acknowledgments, retransmission — at the cost of overhead.
• UDP is connectionless and best-effort: no handshake, no acknowledgments, minimal delay. Reliability becomes the application's problem.
• The handshake is SYN → SYN-ACK → ACK, and it completes before any data moves.
• Ports are 16-bit. Servers use well-known ports; clients use ephemeral ones.
• Choose TCP when correctness matters and UDP when timeliness matters.