TCP vs. UDP

Networking Fundamentals

Chapter 7 · TCP vs. UDP

net1-6 got a packet to the right network. This chapter is about the two dominant ways applications actually structure communication once it arrives — TCP and UDP, the Transport-layer protocols named back in net1-3.

Connection-Oriented vs. Connectionless

TCP (Transmission Control Protocol) is connection-oriented — it establishes a formal connection before any real data moves, and guarantees delivery, ordering, and error-checking. UDP (User Datagram Protocol) is connectionless — it just sends packets ("datagrams") with no setup, no delivery guarantee, and no ordering guarantee, in exchange for dramatically lower overhead.

TCP is a phone call — both sides confirm the line is open before speaking, and know immediately if it drops. UDP is a stack of mailed postcards — fast and cheap to send, with no confirmation they ever arrive, or in what order.

The Three-Way Handshake, In Full

This is the exact handshake web-sockets1-2 mentioned only briefly — here it is in full, for the first time on this site.

SYN — the client sends a SYN (synchronize) packet carrying an initial sequence number.
SYN-ACK — the server responds with its own SYN, plus an ACK acknowledging the client's sequence number.
ACK — the client sends a final ACK, acknowledging the server's own sequence number.

After these three steps, both sides have a working, mutually-acknowledged connection and can begin exchanging real data. This is also the direct answer to the gap net1-1 named in https1: TLS's own handshake happens after this one, layered on top of an already-established TCP connection — two separate handshakes, not one.

Sequencing and Reliability — What TCP Actually Guarantees

Every byte TCP sends carries a sequence number. The receiver acknowledges data by sequence number; if an expected acknowledgment doesn't arrive in time, TCP retransmits. This is the actual mechanism behind three separate guarantees: data arrives (via retransmission), arrives in the correct order (sequence numbers let out-of-order data be reordered), and isn't duplicated (sequence numbers also identify duplicates directly).

None of this exists in UDP at all. A lost, dropped, or out-of-order UDP datagram stays lost, dropped, or out-of-order — UDP itself does nothing about it. Fixing it, if it matters, is left entirely to the application.

When Each Is Actually Used

TCP: web browsing (HTTP/HTTPS), email, file transfer, SSH — anything where complete, correct, in-order delivery genuinely matters more than raw speed. UDP: DNS queries (net1-9's own upcoming subject — a quick request/response where retry logic, if needed, happens at the application level), video/voice calls (a late frame is often worse than a missing one — better to skip it than stall waiting for a retransmission), online gaming (same logic), and DHCP.

DNS specifically mostly runs over UDP for speed, falling back to TCP only for unusually large responses — net1-9 picks this up directly.

A Real Application Choosing Both — WebSockets

web-sockets1-2's own material is worth revisiting here explicitly: a WebSocket connection starts life as an ordinary HTTP request — over TCP, naturally — that gets "upgraded" into a persistent, full-duplex TCP connection. WebSockets are built entirely on TCP, not UDP, specifically because ordered, reliable delivery genuinely matters for most real-time application data (chat messages, live updates), even though "real-time" might suggest reaching for UDP instead.

	Connection setup	Reliability / ordering	Overhead	Typical use
TCP	Three-way handshake required	Guaranteed — retransmission, sequencing	Higher	HTTP/HTTPS, SSH, email, file transfer
UDP	None — send immediately	None — application's own responsibility	Lower	DNS, voice/video, gaming, DHCP

Watching a real handshake happen

ss or netstat (net1-10's own tools) show active TCP connections and their exact state — SYN_SENT, ESTABLISHED, and others — a direct, visible trace of where a real connection sits inside, or stuck inside, this exact handshake process.

A dropped handshake looks exactly like "the server is slow"

A firewall or NAT device silently dropping any part of the three-way handshake — most often the SYN-ACK on the way back — causes a connection attempt to hang or time out in a way that's genuinely indistinguishable, from the user's side, from a server that's simply slow to respond. The real problem is that the handshake never completed at all, not that a working connection is just taking its time — a common, confusing source of misdiagnosed connectivity issues.

Hands-On Exercises

Exercise 1

Explain, using this chapter's own handshake steps, why https1's TLS handshake can't begin before the TCP handshake finishes.

📄 View solution

Exercise 2

A team is building a live video call feature and is deciding between TCP and UDP for the actual video stream. Using this chapter's own reasoning, recommend one and explain why the other's guarantees would actually hurt the experience.

📄 View solution

Exercise 3

A user reports a web request "hangs forever" rather than failing outright. Using this chapter's own warn-box, explain a likely cause that has nothing to do with the server actually being slow.

📄 View solution

Chapter 7 Quick Reference

TCP — connection-oriented, guarantees delivery/ordering/no-duplication via sequence numbers and retransmission
UDP — connectionless, no guarantees at all, much lower overhead
Three-way handshake: SYN → SYN-ACK → ACK, establishing a connection before real data moves
TLS's own handshake (https1) happens after, and on top of, the TCP handshake — two separate steps
TCP for correctness-critical traffic; UDP for latency-critical traffic where stale data beats missing data
WebSockets run entirely over TCP, upgraded from an ordinary HTTP request
A dropped SYN-ACK causes a hang indistinguishable from "the server is slow" — a real, common misdiagnosi