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 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.

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

Cheat strip