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

Protocol	Header size	Why
TCP	20 bytes (40 with options)	Sequence #, ack #, flags, window, etc.
UDP	8 bytes	Just src port, dst port, length, checksum

For tiny payloads, UDP’s 8-byte header is a meaningful efficiency win. For a 1-byte ping, TCP would need 60 bytes of headers; UDP needs 36.

Ports — the same on both protocols, but separately

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

Range	Name	Purpose
0–1023	Well-known	Standard protocols (HTTP 80, SSH 22, DNS 53)
1024–49151	Registered	Vendor-assigned (Cisco TFTP, MS-SQL, etc.)
49152–65535	Ephemeral	Source ports the OS picks for outbound connections

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

Port	Protocol	Notes
20, 21	TCP	FTP (data, control)
22	TCP	SSH
23	TCP	Telnet (don’t use — unencrypted)
25	TCP	SMTP
53	UDP + TCP	DNS
67, 68	UDP	DHCP (server, client)
69	UDP	TFTP
80	TCP	HTTP
110	TCP	POP3
123	UDP	NTP
143	TCP	IMAP
161, 162	UDP	SNMP (poll, trap)
443	TCP	HTTPS
514	UDP	Syslog
3389	TCP	RDP

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 google.com 53 — fails (Google’s DNS is UDP/53, not TCP/53 on that interface).

Cheat strip

Concept	Plain English
TCP	Reliable, ordered, connection-based. HTTP, SSH, SMTP.
UDP	Fire-and-forget. DNS, DHCP, VoIP, video.
3-way handshake	SYN → SYN-ACK → ACK (TCP only)
Sequence numbers	TCP uses them to reorder and detect loss
Port range 0–1023	Well-known (HTTP 80, SSH 22, DNS 53)
Port range 49152+	Ephemeral — client-side source ports
TCP/80 ≠ UDP/80	Different conversations entirely
DNS uses both	UDP for queries, TCP for big responses + zone transfers