Lesson 1.4.2 — TCP vs. UDP and Transport Characteristics

Domain 1.0 | Networking Concepts — 23% of exam

Learning Objectives

By the end of this lesson, you will be able to:

• Compare TCP and UDP in terms of connection establishment, reliability, and overhead
• Describe the TCP three-way handshake and explain what each step accomplishes
• Explain how TCP achieves reliable delivery through sequencing, acknowledgment, retransmission, and flow control
• Explain why UDP forgoes these reliability mechanisms, and what it gains in exchange
• Identify which common protocols from Lesson 1.4.1 use TCP, which use UDP, and why that choice matches each protocol’s actual requirements

Key Terms

Explanation

Picking Up the Transport Layer Story

Lesson 1.1 introduced the Transport layer’s two main protocols, TCP and UDP, and their respective PDU names (Segment for TCP, Datagram for UDP), but deliberately left the actual mechanics of how each one works for this lesson. Lesson 1.4.1 then listed dozens of protocols and, for each one, noted whether it rides on TCP, UDP, or both — but didn’t explain why a given protocol’s designers made that choice. This lesson answers both questions directly: what TCP and UDP actually do differently at the mechanical level, and why that mechanical difference determines which protocols choose each one.

TCP: Reliability Through Connection and Acknowledgment

TCP (Transmission Control Protocol) is connection-oriented, meaning two hosts must formally establish a connection before exchanging any application data, and TCP guarantees reliable, ordered delivery — every byte sent will either arrive at the destination in the correct order, or the sender will find out it didn’t and resend it. TCP achieves this guarantee through several coordinated mechanisms working together.

The Three-Way Handshake. Before any data flows, TCP establishes a connection using a three-step exchange:

1. The client sends a SYN (synchronize) segment to the server, indicating it wants to establish a connection and proposing an initial sequence number.
2. The server responds with a SYN-ACK segment, acknowledging the client’s SYN and simultaneously proposing its own initial sequence number.
3. The client responds with an ACK, acknowledging the server’s SYN.

Only after this three-step exchange completes does either side begin sending actual application data. This handshake accomplishes two things simultaneously: it confirms that both directions of communication are actually working (not just one direction, which a single one-way message couldn’t verify), and it establishes the starting sequence numbers both sides will use to track data as it flows.

Consider a concrete (simplified) walkthrough: a client sends a SYN with an initial sequence number of 1000, meaning “I’m about to start sending data, and I’ll number my first byte 1000.” The server responds with a SYN-ACK containing an acknowledgment number of 1001 (confirming it received the client’s SYN and expects the next byte at 1001) along with its own initial sequence number, say 5000.

The client then sends an ACK acknowledging the server’s sequence number, confirming receipt of the SYN-ACK. From this point forward, every byte either side sends is numbered relative to these starting points, which is precisely what allows the receiver on either end to detect a gap (missing data) or reorder segments that happened to arrive out of sequence.

Sequencing and Acknowledgment. Once a connection is established, TCP assigns a sequence number to the data being sent, allowing the receiving host to reassemble incoming segments in the correct order even if they arrive out of order (which can happen, since different packets can take different paths across a network and arrive at different times). The receiver sends acknowledgments back to the sender confirming what data it has successfully received. If the sender doesn’t receive an acknowledgment for specific data within an expected time window, it assumes that data was lost in transit and performs a retransmission — resending the missing data until it’s successfully acknowledged.

Flow Control and Windowing. TCP also prevents a fast sender from overwhelming a slower receiver through windowing: the receiver advertises how much additional data it’s currently able to accept (its available buffer space), and the sender limits how much unacknowledged data it has in flight at any given time to stay within that advertised window. This window size can adjust dynamically as conditions change, allowing TCP to adapt its sending rate to what the receiver (and, in more advanced implementations, the network path itself) can actually handle.

To make windowing concrete: imagine a receiver advertises a window size of 4,000 bytes. The sender can transmit up to 4,000 bytes’ worth of data without waiting for an acknowledgment, but must then pause and wait for the receiver to acknowledge at least some of that data (freeing up window space) before sending more.

If the receiving application is slow to process incoming data — say, a receiving disk is momentarily busy — the receiver can advertise a smaller window, signaling the sender to slow down, and later advertise a larger window again once it catches up. This dynamic adjustment is what prevents a fast sender on a high-speed connection from flooding a slower or more congested receiver faster than it can actually process the incoming data.

Closely related to flow control is congestion control — a set of algorithms TCP uses to detect and respond to congestion within the network itself, not just at the receiving endpoint. Where flow control protects the receiver from being overwhelmed, congestion control protects the network path from being overwhelmed, typically by having the sender start with a conservative sending rate and gradually increase it as acknowledgments confirm the network can handle more, backing off sharply if signs of congestion (such as significant packet loss) appear. Both mechanisms work together, but they solve distinct problems worth keeping separate in your mental model: flow control is about the receiver’s capacity; congestion control is about the network path’s capacity.

Connection Termination. Just as TCP formally establishes a connection, it also formally tears one down. This typically happens through a four-step exchange: the side finished sending data sends a FIN (finish) segment, the other side acknowledges it with an ACK, and then that other side sends its own FIN once it’s also finished, which the first side acknowledges in turn. This four-step teardown (sometimes visually simplified to “FIN, ACK, FIN, ACK”) ensures both hosts explicitly agree the conversation is complete in both directions before either one fully releases the resources associated with that connection — since it’s entirely possible for one side to be done sending while the other still has more data in flight.

All of this — the handshake, sequence numbers, acknowledgments, retransmission logic, and windowing — comes at a cost: overhead. Every TCP segment carries additional header information to support these mechanisms, and establishing a connection before any actual data can be sent adds latency, particularly noticeable on connections with higher round-trip time. TCP is, quite deliberately, willing to trade some speed and efficiency for a strong guarantee that data arrives completely and in order.

UDP: Speed Through Simplicity

UDP (User Datagram Protocol) takes the opposite approach entirely. It is connectionless — there’s no handshake, no formal connection establishment of any kind. A sender simply transmits a datagram addressed to a destination IP and port, with no confirmation that the destination is even listening, let alone that the data arrived successfully. UDP provides no sequencing, no acknowledgment, and no retransmission — if a UDP datagram is lost in transit, UDP itself does nothing about it; the datagram is simply gone unless something at a higher layer (typically the application itself) notices and takes action.

This might sound like a strictly worse protocol, but the trade-off is exactly the mirror image of TCP’s: UDP’s minimal overhead and lack of connection-establishment delay make it significantly faster and lower-latency than TCP, precisely because it skips everything that gives TCP its reliability guarantees. For applications where speed matters more than guaranteed delivery of every single byte — and, just as importantly, applications where an old, late-arriving retransmission would be useless anyway — UDP’s simplicity is a genuine advantage rather than a shortcoming.

UDP’s header reflects this simplicity directly: where a TCP header carries sequence numbers, acknowledgment numbers, window size, and multiple control flags to support its full reliability machinery, a UDP header carries only the essentials — source port, destination port, length, and a checksum — with no fields at all dedicated to tracking connection state, ordering, or acknowledgment, because none of those concepts exist in UDP’s model. This dramatically smaller, simpler header is a large part of why UDP carries less per-packet overhead than TCP, on top of avoiding the handshake delay entirely.

Side-by-Side: TCP vs. UDP

Why Protocols Choose One or the Other

Looking back at the protocol list from Lesson 1.4.1 through this lens makes the design choices behind each one much clearer, rather than being an arbitrary fact to memorize:

• HTTP/HTTPS, FTP, SSH, SMTP, and most database protocols use TCP because losing or reordering even a small piece of a web page, file, encrypted session, or email would corrupt the result — these applications fundamentally need every byte to arrive, in order, or the result is broken and unusable. The added overhead and connection-setup latency is a completely acceptable trade-off for that guarantee.
• DNS primarily uses UDP because a typical query and response are small enough to fit in a single datagram, and the overhead of a full TCP handshake for such a brief exchange would be wasteful — if a DNS response is lost, the resolver simply retries the query, which is fast and cheap given how small the exchange is. (DNS falls back to TCP for larger transfers, as covered in Lesson 1.4.1, precisely because UDP’s lack of reliability and larger-payload support becomes a genuine limitation at that point.)
• DHCP, TFTP, SNMP, and NTP use UDP for a similar reason: these are typically small, simple exchanges on a local or trusted network, where the overhead of establishing a full TCP connection for a single brief request-response exchange isn’t worth the cost, and where quick retry logic at the application level is a perfectly adequate substitute for TCP’s built-in reliability.
• Real-time voice and video media (though not the SIP signaling that sets up the call) typically use UDP for a more subtle and important reason: in a live phone call or video stream, a retransmitted packet that arrives late is worse than useless — the moment for that audio or video frame has already passed, and a stalled, retransmission-induced pause is far more disruptive to a real-time conversation than a brief, barely noticeable glitch from a dropped packet would be. This is the clearest possible illustration of why “unreliable” doesn’t mean “bad” — for this specific use case, TCP’s reliability mechanisms would actively make the user experience worse, not better.

It’s worth stepping back and noticing the underlying pattern across all of these examples: the choice was never “TCP is better” or “UDP is better” in the abstract. Each protocol’s designers looked specifically at what happens when data is lost or arrives out of order for that particular application, and chose whichever transport protocol’s behavior matched the actual consequences of that loss. A missing byte in a downloaded file is catastrophic and must be recovered — choose TCP.

A missing video frame in a live call is a minor, instantly-forgotten glitch — choose UDP. This “what happens if this specific piece of data never arrives” question is the single most reliable way to reason through an unfamiliar protocol’s TCP-versus-UDP choice on the exam, rather than trying to memorize every pairing as an independent fact.

Connecting Back to Firewalls and Load Balancers

TCP’s connection-oriented nature is precisely what makes stateful devices possible — recall from Lesson 1.2.2 that a stateful firewall tracks the state of active connections in a state table, automatically permitting return traffic for a connection it has already seen initiated. This is only meaningfully possible because TCP itself has an explicit, trackable connection lifecycle — a handshake that establishes the connection, ongoing sequence numbers and acknowledgments that confirm it’s still active, and a formal FIN-based teardown that signals when it’s over.

A firewall can watch this entire lifecycle and make intelligent decisions based on it. UDP, having no connection concept at all, is inherently harder for a stateful device to track in the same way — many firewalls approximate “UDP connection state” using a short timeout after the last observed packet in a given flow, since there’s no actual handshake or teardown to observe.

Similarly, recall from Lesson 1.2.3 that Layer 4 load balancing makes distribution decisions using transport-layer information — source/destination IP and port. Whether that transport-layer information belongs to a TCP segment or a UDP datagram matters operationally: a Layer 4 load balancer handling TCP traffic can potentially use connection-level signals (like the initial SYN) to make an initial routing decision that then persists for the life of that connection, while a load balancer handling UDP traffic has no such connection lifecycle to key off of and must rely on other signals, such as the source/destination address pair alone, to keep related datagrams consistently routed to the same backend server.

A Complete Comparison: Loading a Web Page vs. Joining a Live Video Call

Tying everything in this lesson together, consider two everyday scenarios side by side. Loading a web page relies on TCP (via HTTPS): your browser performs a three-way handshake with the web server, and every byte of the page’s HTML, images, and scripts is sequenced, acknowledged, and retransmitted if lost — because a web page missing a chunk of its HTML or receiving it out of order isn’t a slightly degraded page, it’s often a broken one. The extra round-trip time from the handshake and the ongoing overhead of acknowledgments are a small price to pay for a page that reliably renders correctly every time.

Joining a live video call relies on UDP for the actual audio and video media streams (even though the call setup itself uses SIP, which may use TCP or UDP for signaling, as covered in Lesson 1.4.1).

If a single video frame’s data is lost in transit, retransmitting it would mean it arrives after the moment it was meant to be displayed has already passed — useless by the time it shows up, and actively harmful if the call has to pause and wait for it. Instead, the call briefly glitches or drops a frame and moves on immediately to the next one.

Which is a far better experience than a call that periodically freezes waiting for retransmitted data that’s already irrelevant by the time it arrives. This single comparison captures the entire reasoning behind TCP versus UDP more effectively than any abstract definition could — the right transport protocol is the one whose behavior actually matches what the specific application needs when something goes wrong.

“Unreliable” Doesn’t Mean “Broken”

It’s worth addressing a common misconception directly: describing UDP as “unreliable” doesn’t mean applications built on UDP are inherently unstable or poorly engineered. It means UDP itself, at the Transport layer, makes no delivery guarantee — but nothing stops an application running on top of UDP from implementing its own reliability logic where it’s actually needed.

Video streaming applications, for example, commonly use buffering and their own retry or error-concealment logic at the application layer, achieving a smooth viewing experience without needing TCP’s connection overhead and strict in-order delivery guarantee, which would actually work against the goal of smooth, low-latency playback. The lesson here generalizes well beyond just streaming: reliability, when needed, can be implemented at whichever layer makes the most sense for the specific application — Transport-layer reliability via TCP is one option, but not the only one.

Recognition-Level Verification Concepts

This objective is about recognizing TCP and UDP behavior in real output rather than configuring anything by hand. A few patterns are worth knowing:

• A packet capture showing a SYN, followed by a SYN, ACK, followed by an ACK between the same two hosts is the unmistakable signature of a TCP three-way handshake in progress.
• netstat-style output typically shows TCP connections with an explicit connection state — LISTENING, ESTABLISHED, TIME_WAIT, and others — reflecting TCP’s connection-oriented nature. UDP, having no concept of a connection at all, shows no such state information; a UDP “connection” in this kind of output is really just a local port a process happens to be listening on.
• A protocol analyzer distinguishes TCP from UDP directly in each packet’s header, and flags like SYN, ACK, FIN, and RST only exist within TCP’s header structure — UDP’s much simpler header has no equivalent flag field at all.
• A RST (reset) flag appearing in a TCP capture indicates an abrupt, non-graceful connection termination — distinct from the orderly FIN-based teardown described above, and often a signal worth investigating further in a troubleshooting context, since it can indicate a rejected connection attempt or an application-level error rather than a normal, expected close.

Common Exam Traps

• The three-way handshake is SYN, SYN-ACK, ACK — in that order, and every step matters. A question describing only two steps, or the steps in the wrong order, is describing something other than a genuine TCP handshake.
• “Unreliable” (UDP) does not mean “unstable” or “low-quality.” It specifically means the Transport layer itself makes no delivery guarantee — which is a deliberate, appropriate design choice for many applications, not a flaw.
• TCP’s reliability comes with real costs — overhead and latency — not just benefits. Don’t treat TCP as unconditionally “better”; the correct choice always depends on what a specific application actually needs.
• DNS, DHCP, SNMP, TFTP, and NTP using UDP is not arbitrary — each involves small, simple, typically local exchanges where TCP’s connection overhead would be disproportionate to the size and importance of the exchange itself.
• Real-time voice/video media using UDP is one of the most frequently tested “why UDP, not TCP” scenarios — remember the reasoning (a late retransmission is worse than a brief dropped frame), not just the fact itself, since scenario questions often test the reasoning rather than a bare memorized pairing.
• Flow control and congestion control solve different problems and are easy to conflate. Flow control protects the receiving host from being overwhelmed; congestion control protects the network path itself from being overwhelmed. Both adjust TCP’s sending behavior, but for different reasons, based on different signals.
• A TCP RST is not the same as a normal FIN-based close. A reset represents an abrupt termination — often signaling a rejected connection, a closed port, or an application-level problem — while a FIN exchange represents an orderly, mutually agreed end to the conversation.