1.4 TCP vs. UDP
Key Takeaways
- TCP is connection-oriented and reliable, establishing sessions with a three-way handshake (SYN, SYN-ACK, ACK).
- UDP is connectionless and best-effort with no handshake, acknowledgments, retransmission, or ordering.
- TCP uses sequence/acknowledgment numbers, windowing for flow control, and a sliding window for throughput.
- Choose UDP for latency-sensitive traffic (VoIP, video, DNS queries) where retransmission would hurt more than help.
- Memorize key ports: HTTP 80, HTTPS 443, SSH 22, Telnet 23, FTP 20/21, SMTP 25, DNS 53, DHCP 67/68.
The Transport layer
Layer 4 (Transport) delivers data between applications on hosts and uses port numbers to identify each application session. The two protocols are TCP (Transmission Control Protocol) and UDP (User Datagram Protocol).
TCP: reliable and connection-oriented
TCP guarantees that data arrives complete, in order, and error-checked. It achieves this with:
- Three-way handshake to open a session: the client sends SYN, the server replies SYN-ACK, the client answers ACK. Memorize this order.
- Sequence and acknowledgment numbers that let the receiver reassemble segments in order and detect loss.
- Retransmission: any unacknowledged segment is re-sent.
- Flow control via windowing: the receiver advertises a window size stating how many bytes it can buffer; a sliding window lets the sender transmit multiple segments before waiting for an ACK, improving throughput.
- Connection teardown using FIN/ACK exchanges.
The overhead of acknowledgments and retransmission is the price of reliability. Use TCP when every byte must arrive: web (HTTP/HTTPS), email (SMTP), file transfer (FTP), and remote login (SSH).
UDP: fast and connectionless
UDP simply sends datagrams with no handshake, no acknowledgments, no sequencing, and no retransmission. Its header is only 8 bytes versus TCP's 20+ bytes, so it has minimal overhead and latency. UDP is ideal where speed beats perfect delivery: a dropped VoIP packet should be skipped, not re-sent late, because a late packet arrives after the conversation has moved on.
Side-by-side
| Feature | TCP | UDP |
|---|---|---|
| Connection | Connection-oriented (handshake) | Connectionless |
| Reliability | Guaranteed, retransmits lost data | Best-effort, no retransmission |
| Ordering | In-order via sequence numbers | No ordering |
| Flow control | Yes (windowing) | No |
| Header size | 20+ bytes | 8 bytes |
| Speed/overhead | Higher overhead | Lower overhead, faster |
| Typical use | Web, email, file transfer, SSH | VoIP, streaming, DNS, gaming |
Well-known ports to memorize
| Service | Port(s) | Protocol |
|---|---|---|
| FTP (data/control) | 20 / 21 | TCP |
| SSH | 22 | TCP |
| Telnet | 23 | TCP |
| SMTP | 25 | TCP |
| DNS | 53 | UDP (queries), TCP (zone transfer) |
| DHCP | 67 / 68 | UDP |
| TFTP | 69 | UDP |
| HTTP | 80 | TCP |
| HTTPS | 443 | TCP |
| SNMP | 161 / 162 | UDP |
Worked example
A real-time video call drops 0.5% of packets. With UDP, the codec conceals the loss and the call continues smoothly. If it ran over TCP, the protocol would pause to retransmit each lost segment, injecting jitter and delay that ruin the call, so VoIP and live video use UDP.
Sockets, sequencing, and windowing in depth
A socket is the pairing of an IP address and a port, and a full connection is identified by four values: source IP, source port, destination IP, destination port. The client picks a high ephemeral port (commonly 49152-65535) as its source while contacting the server's well-known port (0-1023). This is why thousands of browser tabs can all reach port 443, each uses a different source port, so each socket pair is unique.
Sequence numbers count bytes, not segments, letting TCP detect exactly which bytes were lost and reorder out-of-sequence arrivals. The acknowledgment number tells the sender the next byte the receiver expects. Windowing is the receiver advertising how many unacknowledged bytes it can hold; a sliding window then lets the sender keep multiple segments in flight, and the window grows or shrinks dynamically to match the receiver's buffer, this is flow control. Separately, TCP's congestion control (slow start) reacts to network loss, do not confuse the two on the exam.
Ports by transport protocol
A quick way to remember which protocol carries each service:
- TCP (reliability matters): HTTP 80, HTTPS 443, SSH 22, Telnet 23, FTP 20/21, SMTP 25.
- UDP (speed matters): TFTP 69, SNMP 161/162, DHCP 67/68, most DNS queries 53.
- Either: DNS uses UDP 53 normally but TCP 53 for zone transfers and oversized replies.
Ports 0-1023 are well-known, 1024-49151 are registered, and 49152-65535 are dynamic/ephemeral, a range distinction the exam occasionally asks about directly.
Common traps
- DNS uses UDP/53 for normal lookups but switches to TCP/53 for large responses and zone transfers, both can appear as correct.
- The handshake order is SYN, SYN-ACK, ACK, not SYN, ACK, SYN-ACK.
- UDP has no flow control or windowing, do not attribute TCP features to it.
- Windowing is flow control (receiver-paced), distinct from congestion control.
- A connection is identified by the four-tuple, not by the server port alone.
TCP reliability mechanisms in action
When a segment is lost, the receiver keeps acknowledging the last in-order byte it got (a duplicate ACK). After the sender sees repeated duplicate ACKs, it performs a fast retransmit, resending the missing segment without waiting for a full timeout. This loss-recovery behavior is what makes TCP reliable but also what makes it a poor fit for real-time media, the recovery delay is unacceptable for a live call. Meanwhile the window size field continuously tunes how much unacknowledged data may be outstanding, throttling a fast sender so it does not overrun a slow receiver's buffer.
Choosing TCP vs UDP: decision guide
- Need every byte, in order, intact -> TCP (file transfer, web pages, email, database).
- Need lowest latency and can tolerate loss -> UDP (VoIP, live video, online gaming).
- Small request/response where retransmission is handled by the app -> UDP (DNS query, DHCP, SNMP).
- Bulk reliable transfer of large files -> TCP (FTP, HTTPS downloads).
The exam frequently frames this as a scenario: match the application's tolerance for delay versus loss to the right protocol, rather than memorizing a list. A late packet that arrives after it is useful is worse than a dropped one for real-time media, which is the core reasoning behind every UDP answer.
What is the correct order of the TCP three-way handshake?
Which port number does HTTPS use by default?
Which transport protocol is most appropriate for real-time voice (VoIP)?