TCP vs UDP

Mental model

When your application sends data over the network, it has a choice: do you want reliable delivery in order (TCP) or fast, lightweight, no guarantees (UDP)?

• TCP wraps every byte in a sequence number, acknowledges delivery, retransmits on loss, and reassembles in order. Costs: extra packets, extra round-trips, latency.
• UDP just throws packets at the destination and forgets them. Costs: nothing, but if anything’s lost, reordered, or duplicated, your app has to handle it.

The choice is application-by-application. Browsers pick TCP. DNS picks UDP. VoIP picks UDP because a delayed audio packet is worse than a lost one: by the time you retransmit, the conversation moved on.

TCP: the 3-way handshake

Before TCP sends any data, it establishes a connection through three packets:

Client                                   Server
  │  ───── SYN (seq=100) ──────►         │
  │  ◄──── SYN-ACK (seq=500, ack=101) ── │
  │  ───── ACK (ack=501) ──────►         │
  │                                      │
  │  ◄────── application data ─────────► │

After this dance, both sides have synchronized sequence numbers and know the connection is established. Closing follows a similar 4-way FIN/ACK exchange.

UDP: there is no handshake

Client                                   Server
  │  ─── UDP datagram ──►                │
  │                                      │
  │  ◄── UDP datagram (maybe) ───        │

That’s the whole protocol. No setup, no teardown, no ack. UDP’s job is to add the source and destination ports to a packet and get out of the way.

Header overhead

For tiny payloads, UDP’s 8-byte header is a meaningful efficiency win. For a 1-byte payload, TCP + IP need 40 bytes of headers; UDP + IP need 28.

Ports: the same on both protocols, but separately

A port is a 16-bit number (0 to 65535) tagged onto every TCP and UDP packet. The pair (IP + port) identifies a unique conversation endpoint.

Key gotcha: TCP port 80 and UDP port 80 are different things. They share the number, not the conversation. Most well-known protocols are TCP, but DNS uses both (UDP for queries, TCP for zone transfers and big responses).

Common ports: memorize these

CCNA exam loves to ask about port numbers. Memorize the common ones.

When to use which

Use TCP when:

• Data must arrive intact and in order (web pages, files, email)
• You can tolerate slight latency for reliability
• The application doesn’t already handle loss

Use UDP when:

• Speed matters more than reliability (VoIP, video, online gaming)
• The application implements its own reliability (QUIC, TFTP)
• The query/response is tiny and a retransmit is cheaper than a connection setup (DNS)

Commands

See active TCP connections on a Cisco router

R1# show tcp brief
R1# show ip sockets
R1# show tcp statistics

Test reachability of a specific port

R1# telnet 10.0.0.1 80      ! quick "is the TCP port open?" test

If telnet connects, port 80 TCP is reachable. If it hangs or refuses, it’s not. (Doesn’t work for UDP: telnet is TCP-only.)

Common mistakes

1. Assuming HTTPS is UDP. It’s TCP, port 443. (TLS sits on top of TCP.) HTTP/3 uses UDP, but for CCNA, HTTPS = TCP/443.

2. Thinking SSH and Telnet share the same port. SSH is 22, Telnet is 23. Easy to confuse on the exam.

3. Forgetting DNS uses both. UDP/53 for normal queries (small response). TCP/53 for zone transfers and any response larger than ~512 bytes (EDNS now supports more in UDP, but TCP fallback still exists).

4. Forgetting source vs destination port direction. A client connecting to a web server uses an ephemeral source port (e.g. 49000) and destination port 80. The server’s reply has source 80, destination 49000. Mistakes here cause ACL rules to fail.

5. Using telnet to test UDP ports. Doesn’t work: telnet is TCP only. For UDP, use nc -u host port on Linux or specific protocol clients.

Lab to try tonight

1. Open Wireshark, start a capture.
2. From your laptop, browse to any HTTPS site. Find the TCP 3-way handshake (SYN, SYN-ACK, ACK) in the capture.
3. Also find a DNS query. Confirm it’s UDP/53.
4. In a terminal: nslookup -type=A google.com while capturing. See exactly one request and one response, both UDP/53.
5. Try telnet google.com 443: connects (TCP/443 open).
6. Try telnet 8.8.8.8 53: connects (DNS servers also listen on TCP/53 for large responses and zone transfers).

Cheat strip

Frequently asked questions

Q: When should I use TCP vs UDP? A: TCP when correctness matters more than latency: file transfer, web pages, email, SSH. UDP when latency matters more than correctness: voice, video, gaming, DNS queries. TCP guarantees delivery and ordering at the cost of retransmission delay; UDP just fires and forgets, leaving the application to handle any reliability it wants. If you don’t know which to pick, default to TCP.

Q: Why does DNS use both UDP and TCP? A: UDP for normal queries (small, one round-trip, retry-if-lost is fine): over 99% of DNS traffic is UDP 53. TCP for zone transfers between servers (large payloads) and for responses larger than 512 bytes (which happens with DNSSEC signatures, big TXT records, etc.). Modern clients also use TCP-fallback when the UDP response has the TC (truncated) flag set.

Q: Does UDP have a checksum? A: Yes, but in IPv4 it’s optional (a checksum of zero means “not calculated”). In IPv6 the UDP checksum is mandatory. In practice virtually every implementation sets it because Ethernet’s CRC only catches errors in-frame, errors introduced by intermediate devices or memory would sail through without a UDP checksum. If you see UDP-checksum-zero, it’s almost always a middlebox stripping it.

Q: What’s QUIC and how does it relate to TCP/UDP? A: QUIC is a transport protocol built on UDP that provides reliable, ordered, encrypted, multiplexed delivery: effectively “TCP replacement” without the TCP handshake latency and without head-of-line blocking. Google runs the majority of google.com traffic over QUIC (HTTP/3 = HTTP over QUIC). From the network’s perspective it’s UDP on port 443; from the application’s perspective it behaves like TCP+TLS.

Q: Why does TCP have a three-way handshake? A: To synchronize the initial sequence numbers in both directions and confirm both sides can send and receive. SYN (client) → SYN-ACK (server acknowledges + sends its own SYN) → ACK (client acknowledges server’s SYN). Two-way isn’t enough because you need each side to confirm it received the other’s sequence number. This is also what SYN-flood attacks abuse, half-opening thousands of connections and never sending the final ACK, exhausting the server’s connection table.