TCP, UDP and Application Protocols

Exam topics covered

1.5 Compare TCP to UDP

Supporting knowledge for 4.0 IP Services: well-known ports and the application protocols DNS, DHCP, NTP, SNMP, syslog, SSH, FTP and TFTP

Foundation. IP gets a packet from one host to another, but a host is not the final destination of data: an application is. Your laptop may be streaming a video, syncing mail and holding an SSH session open to a router, all at the same moment and all through one IP address. The transport layer is what sorts this out. It delivers each piece of data to the right application, and, when the application asks for it, it also makes delivery reliable. This chapter compares the two transport protocols you must know for the CCNA, the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP), and then tours the application protocols that ride on top of them. You will meet many of these protocols again later in the book (DHCP, DNS, NTP, SNMP and syslog each get detailed treatment in Part IV), so the goal here is to understand which transport each one uses, which port it listens on, and why its designers made that choice.

5.1 The Role of the Transport Layer

The transport layer (Layer 4 of the OSI model) sits between the applications above it and IP below it. Whatever transport protocol is in use, it performs one job for certain: multiplexing many application conversations over a single IP address and identifying each conversation with port numbers. TCP adds reliability on top of that basic job; UDP adds almost nothing.

5.1.1 Port numbers and multiplexing

A port number is a 16-bit value (0 to 65,535) carried in every TCP and UDP header. Each segment carries two of them: a source port that identifies the sending application and a destination port that identifies the receiving application. Servers listen on fixed, published ports so that clients know where to find them: a web server listens on TCP 443, a DNS server on UDP 53. Clients, by contrast, pick a temporary ephemeral port (also called a dynamic port) for each new conversation, so that replies can be matched to the right browser tab or the right process.

Tcp 443

Tcp 22

Web server

SSH daemon

Figure 5-1 Multiplexing: two browser tabs reach the same web server port, but their different ephemeral source ports keep the replies separate.

The Internet Assigned Numbers Authority (IANA) divides the port space into three ranges: well-known or system ports (0–1023) for core services such as HTTP, SSH and DNS; registered ports (1024–49151) that vendors register for their applications, such as RDP on 3389 or CAPWAP on 5246/5247; and dynamic or ephemeral ports (49152–65535) for temporary client-side use. Operating systems do not all follow the IANA dynamic range exactly (many Linux kernels start at 32768), but the principle is the same everywhere.

5.1.2 Sockets and socket pairs

The combination of an IP address, a transport protocol and a port is called a socket, often written as 192.168.1.50:50001 . One socket identifies one end of a conversation. A conversation as a whole is identified by a socket pair: the source socket plus the destination socket. Engineers often call this the 5-tuple: source IP, source port, destination IP, destination port and protocol. Because at least one element of the 5-tuple differs between any two conversations, a host can keep thousands of them apart. Firewalls, NAT devices and load balancers all track traffic by exactly this 5-tuple.

5.2 TCP: Reliable, Connection-Oriented Transport

TCP (RFC 9293, which replaced the original RFC 793) is the transport for applications that cannot tolerate missing or reordered data: web pages, file transfers, email, remote logins. It provides a reliable, ordered byte stream between two applications over an unreliable IP network. To do that it adds a set of features that the CCNA blueprint expects you to name and explain:

Connection establishment and termination: a three-way handshake before data and an orderly close afterwards.

Sequencing: every byte is numbered so that the receiver can reassemble data in order and detect gaps.

Acknowledgements: the receiver confirms what it has received.

Retransmission: unacknowledged data is resent after a timeout or on duplicate acknowledgements.

Flow control and windowing: the receiver advertises how much data it can accept, so a fast sender cannot overwhelm a slow receiver.

Segmentation: the application's byte stream is cut into segments that fit the path (the Maximum Segment Size, MSS, typically 1460 bytes on Ethernet).

5.2.1 The TCP header

All of these features live in the TCP header. Its fixed part is 20 bytes; options (such as MSS, window scaling and selective acknowledgement) can stretch it to a maximum of 60 bytes.

Figure 5-2 shows the layout with each field's width in bits.

Figure 5-2 The TCP header. Green fields drive reliability and flow control; the orange flags field drives connection setup and teardown.

Table 5-1 Key TCP header fields

• Field Purpose
• Source / Destination
• Port

Identify the sending and receiving applications (multiplexing).

Sequence Number Number of the first data byte in this segment (or the Initial Sequence Number in a SYN).

Acknowledgement

Number

The next byte the sender of this segment expects to receive. Valid when the ACK flag is set.

Flags SYN (synchronize, open), ACK (acknowledgement field valid), FIN (finished sending), RST (abort), PSH (push to application now), URG (urgent pointer valid), ECE/CWR (explicit congestion notification).

Window Size How many bytes the receiver is willing to accept beyond the acknowledged byte (flow control).

5.2.2 Connection establishment: the three-way handshake

Before any data flows, TCP opens a connection with three segments. The purpose is to agree on starting sequence numbers in both directions and to confirm that each side can hear the other. Each side chooses a random Initial Sequence Number (ISN); randomising it makes it hard for an attacker to inject forged segments.

• 1. SYN. The client sends a segment with the SYN flag set and its ISN (say 1000). It moves to the SYN-SENT state.
• 2. SYN-ACK. The server, which was in the LISTEN state, replies with both SYN and ACK set. Its own ISN is 5000, and its acknowledgement number is 1001: “I received your SYN; the next byte I expect is 1001.” A SYN consumes one sequence number even though it carries no data.
• 3. ACK. The client acknowledges the server's SYN with ACK = 5001. Both sides are now ESTABLISHED and data can flow in both directions.

5.2.3 Connection termination: the four-way close

A TCP connection is full-duplex, so each direction is closed independently. The side that finishes first sends a FIN; the other side acknowledges it, may continue sending its own remaining data, and then sends its own FIN, which is acknowledged in turn. That makes four segments, although the middle two are often combined into a single FIN-ACK segment. The side that closed first waits in the TIME-WAIT state for twice the maximum segment lifetime before freeing the socket, so that any delayed segment from the old connection cannot be mistaken for part of a new one.

• (a) Three-way handshake (b) Four-way close
• Client Server
• SYN seq=1000

Syn, ack

seq=5000 ack=1001

ACK seq=1001 ack=5001

Syn-sent

Estab-lished

Listen

Syn-rcvd

Estab-lished

Client Server

1 fin

2 ack

(server may still

send data)

3 fin

4 ack

Fin-wait-1

Fin-wait-2

Time-wait

(2 × MSL)

Close-wait

Last-ack

Closed

Figure 5-3 (a) Opening a connection: each SYN consumes one sequence number, so each acknowledgement is ISN + 1. (b)

Closing it: each direction is shut down by its own FIN and ACK. All FIN segments also carry the ACK flag. Memorise the order SYN, SYN-ACK, ACK and remember that the acknowledgement number always names the next byte expected, not the last byte received. If a question shows ACK = 5001, the sender of that ACK has received everything up to byte 5000.

A connection can also be torn down abruptly with a RST (reset) segment. A host sends RST when a segment arrives for a port with no listening application, or when an application aborts. A firewall that “rejects” rather than silently drops a TCP connection attempt usually does so with a RST.

5.2.4 Sequencing and acknowledgements

TCP numbers bytes, not segments. If the client's first data segment carries 1000 bytes starting at sequence number 1001, it covers bytes 1001–2000, and the next segment begins at 2001. The receiver uses these numbers to put out-of-order segments back in order and to spot gaps. Acknowledgements are cumulative: ACK = 3001 confirms every byte up to 3000. The receiver does not need to acknowledge each segment individually; one ACK can confirm several segments at once.

5.2.5 Retransmission

The sender keeps a copy of every segment until it is acknowledged and starts a retransmission timer (the RTO, calculated from the measured round-trip time). If the timer expires, the segment is sent again. Modern stacks also use fast retransmit: when the receiver gets a segment after a gap, it immediately repeats its last ACK, and three duplicate ACKs tell the sender to resend the missing segment without waiting for the timer. The optional Selective Acknowledgement (SACK) option lets the receiver say exactly which blocks it already holds, so only the missing data is resent.

• Sender Receiver
• ✗ lost
• RTO expires or
• 3 duplicate ACKs
• seq=1001 (bytes 1001–2000)

Ack=2001

Figure 5-4 Retransmission: the receiver keeps acknowledging 2001 until the missing segment arrives, then jumps to a cumulative ACK of 4001.

5.2.6 Windowing and flow control

If a sender had to wait for an acknowledgement after every segment, throughput on a long-distance link would be terrible: most of the time would be spent waiting. TCP instead lets the sender transmit a window of bytes before it must stop and wait. The receiver advertises the size of this window in the Window Size field of every segment it sends, based on how much free space it has in its receive buffer. This is flow control: the receiver, not the sender, decides how fast data may arrive.

The window slides forward as acknowledgements arrive, which is why the mechanism is called a sliding window. Figure 5-5 shows a sender's view of the byte stream at one instant.

• 1 2 3 4 5 6 7 8 9 10 11 12 13
• Advertised window = 7 segments (e.g. 7 × 1460 bytes)
• window slides right as ACKs arrive

Sent and acknowledged Sent, not yet acknowledged May be sent now Cannot send yet

Figure 5-5 The sliding window as seen by the sender. When segment 4 is acknowledged, the left edge moves to 5 and segment 11 becomes sendable.

Window sizes are dynamic. If the receiving application is slow to read its buffer, the receiver advertises a smaller window, and if the buffer fills completely it advertises a zero window, which pauses the sender. The 16-bit field limits the window to 65,535 bytes, which is too small for fast, long links, so the window scale option negotiated in the SYN segments multiplies it by a power of two.

Tip

Do not confuse flow control with congestion control. The receive window (advertised in the header) protects the receiver's buffer. The congestion window (never sent on the wire) is the sender's own estimate of what the network can carry: it starts small (slow start), grows while data is acknowledged and shrinks sharply on loss. The sender obeys whichever window is smaller. The CCNA uses “windowing” and “flow control” to mean the receive window.

5.3 UDP: Lightweight, Connectionless Transport

UDP (RFC 768) is TCP's minimalist sibling. It provides multiplexing with ports and an optional checksum, and nothing else: no handshake, no sequence numbers, no acknowledgements, no retransmission, no windowing. A UDP sender simply wraps the application's data in an 8-byte header and hands it to IP. If the datagram is lost, UDP does not notice.

Table 5-2 TCP compared with UDP

Imap, bgp

Figure 5-6 The UDP header is only 8 bytes, compared with at least 20 for TCP.

Why would anyone choose an unreliable protocol? Because for many applications, TCP's reliability is either unnecessary or actively harmful:

Real-time voice and video (RTP over UDP). A voice sample that arrives 300 ms late is useless; retransmitting it would only add delay and jitter. It is better to lose a few milliseconds of audio and keep going.

Simple query/response protocols such as DNS, DHCP, NTP and SNMP. A single request and a single reply do not justify a three-way handshake and teardown. If no answer arrives, the application simply asks again.

Broadcast and multicast. TCP is strictly one-to-one; UDP can send one datagram to many receivers. DHCP Discover messages, for example, are UDP broadcasts.

Applications that build their own reliability. TFTP adds its own simple acknowledgements on top of UDP, and QUIC (the transport beneath HTTP/3) implements encryption, streams and retransmission over UDP port 443.

A favourite question lists features and asks which belong to UDP. The safe answers are: connectionless, lower overhead, no sequencing, no acknowledgements, suited to delay-sensitive traffic such as voice and video. If an option mentions windowing, acknowledgements, sequencing or the three-way handshake, it describes TCP.

5.4 Application Protocols and Well-Known Ports

The CCNA expects instant recall of the ports in Table 5-3 and whether each uses TCP, UDP or both. The descriptions that follow explain the reasoning behind each transport choice.

Table 5-3 Well-known ports for the CCNA

HTTP is a request/response protocol: the client sends a method (GET, POST, PUT, PATCH, DELETE) and a resource path, and the server replies with a status code (200 OK, 404 Not Found, 500 Server Error) and usually a body. Plain HTTP runs over TCP 80. HTTPS is HTTP inside a TLS session on TCP 443, adding encryption, integrity and server authentication by certificate. HTTPS also carries the REST APIs of Chapter 34.

5.4.2 dns

The Domain Name System translates names such as www.example.com into IP addresses. A client (the stub resolver) asks its configured DNS server, which either answers from its cache or performs recursive lookups through the root, top-level-domain and authoritative servers. Queries normally use UDP 53 because they fit in one datagram; DNS falls back to TCP 53 when a response is too large and always uses TCP for zone transfers between servers. Chapter 25 covers DNS record types and IOS configuration.

• 1. A? www.example.com
• 6. 93.184.215.14

Figure 5-7 Recursive DNS resolution: the client asks once; the resolver follows referrals and caches the answer.

5.4.3 dhcp

The Dynamic Host Configuration Protocol hands out IPv4 addresses, masks, default gateways and DNS servers. A new client has no IP address, so the exchange begins with a broadcast, which is only possible with UDP. The four messages, remembered as DORA, are Discover, Offer, Request and Acknowledge. Servers listen on UDP 67 and clients on UDP 68. When the server is on another subnet, a router configured with ip helper-address relays the broadcasts as unicasts. Chapter 25 covers the details.

5.4.4 FTP and TFTP

The File Transfer Protocol uses two TCP connections: a control connection to server port 21 for commands such as USER, PASS, LIST and RETR, and a separate data connection for each file or directory listing. In active mode the server opens the data connection from its port 20 back to the client; in passive mode (the common choice today because it works through client-side firewalls and NAT) the client opens the data connection to a port the server announces. FTP supports logins and directory browsing but sends credentials in clear text; FTPS (FTP over TLS) and SFTP (part of SSH, TCP 22) are the secure alternatives. The Trivial File Transfer Protocol is the opposite: UDP port 69, no authentication, no directory listing, just “read file” and “write file”. It provides its own reliability with a lock-step scheme: each 512-byte block must be acknowledged before the next is sent. Its simplicity makes it easy to embed in boot ROMs, which is why network engineers still use it to copy IOS images and configurations ( copy tftp: flash: ), and IP phones use it to fetch configuration files.

5.4.5 Email: SMTP, POP3 and IMAP

Email uses different protocols for sending and for retrieving. SMTP (TCP 25) moves mail from a client to its outgoing server and between mail servers; mail clients normally submit on TCP 587 with authentication and STARTTLS. To read mail, a client uses POP3 (TCP 110), which downloads messages and by default deletes them from the server, or IMAP (TCP 143), which leaves messages on the server and synchronises folders across devices. The TLS-wrapped versions are POP3S (995) and IMAPS (993).

5.4.6 SSH and Telnet

Both give you a remote command line on a router or switch, and both use TCP so that keystrokes arrive reliably and in order. Telnet (TCP 23) sends everything, including the password, in clear text, so anyone capturing the traffic can read it. SSH (TCP 22) encrypts the whole session and authenticates the server by its host key. SSH version 2 is the standard you should configure on every device (Chapter 26). Exam questions that ask for secure remote management always point to SSH.

5.4.7 SNMP, NTP and syslog

Three UDP-based management protocols round out the list:

SNMP lets a Network Management System poll managed devices. The NMS sends Get and Set requests to the agent on UDP 161; agents send unsolicited Trap and Inform notifications to the NMS on UDP 162. SNMPv3 adds authentication and encryption. NTP synchronises clocks on UDP 123 so that log timestamps, certificates and authentication protocols agree. Accuracy is measured by stratum: stratum 1 servers are attached directly to a reference clock.

Syslog sends event messages (interface down, configuration changed, login failures) to a central collector, classically on UDP 514. Each message carries a severity level from 0 (emergencies) to 7 (debugging).

All three use UDP because each message is small and self-contained, and a connection per message is not worth its cost.

Exam alert

Watch for the paired ports: FTP 20/21, DHCP 67/68, SNMP 161/162. Know which side uses which: the DHCP server listens on 67, the SNMP agent on 161 and the SNMP manager receives traps on 162.

5.5 Viewing Connections and Ports

Every major operating system lets you list its sockets. On Windows, macOS and older Linux systems the tool is netstat ; modern Linux uses ss . The -a option shows all sockets (including listening ones) and -n shows numbers instead of resolving names and service names, which is faster and clearer. Figure 5-8 shows a Windows workstation that is browsing two web sites, has an SSH session open to a router, and is itself listening for RDP.

Command Prompt — PC1

C:\Users\student> netstat -an

Active Connections

Proto Local Address Foreign Address State

Tcp 0.0.0.0:445 0.0.0.0:0 listening

Tcp 0.0.0.0:3389 0.0.0.0:0 listening

• TCP 192.168.1.50:50001 203.0.113.10:443 ESTABLISHED
• TCP 192.168.1.50:50002 203.0.113.10:443 ESTABLISHED
• TCP 192.168.1.50:50003 192.168.1.1:22 ESTABLISHED
• TCP 192.168.1.50:50004 198.51.100.25:443 TIME_WAIT
• TCP 192.168.1.50:50005 198.51.100.25:443 SYN_SENT

Udp 0.0.0.0:123 *:*

Udp 192.168.1.50:68 *:*

Figure 5-8 netstat -an on Windows. Each ESTABLISHED line is one socket pair; UDP sockets have no state because UDP has no connections.

Read the output column by column. A local address of 0.0.0.0:3389 in the LISTENING state means a server process is waiting on port 3389 on every interface. The three ESTABLISHED lines are three separate socket pairs: two browser connections to the same HTTPS server, distinguished only by their source ports, and one SSH session to the router at 192.168.1.1. TIME_WAIT is a connection this PC closed first (Figure 5-3b), and SYN_SENT is a connection waiting for its SYN-ACK. Notice that UDP lines show no state at all. Adding -o (Windows) or - p (Linux) also shows the owning process.

Cisco IOS keeps the same kind of table for connections to and from the router itself (not traffic passing through it). show tcp brief lists the router's own TCP sessions, such as SSH logins from administrators. In this book, device output is illustrative of Cisco IOS 15 and IOS XE; exact spacing and values vary by platform and release.

R1 — ssh

R1# show tcp brief

• TCB Local Address Foreign Address (state)
• 7F0B2C6E1A40 192.168.1.1.22 192.168.1.50.50003 ESTAB
• 7F0B2C6E3B18 10.0.12.1.179 10.0.12.2.30412 ESTAB

7f0b2c6e4f90 0.0.0.0.22 *.* listen

Figure 5-9 R1's own TCP sockets. The SSH session is the same socket pair PC1 shows in Figure 5-8, seen from the other end

(local and foreign swapped). IOS separates address and port with a dot.

Fin / rst

Time-wait

connectionless

Mss

Review questions

• 1. Which two features are provided by TCP but not by UDP? (Choose two.)

• A. Port-based multiplexing
• B. Sequencing of data
• C. Checksums
• D. Windowing
• E. Broadcast delivery

• 2. A client sends a SYN with sequence number 7000. The server responds with SYN-ACK and sequence number 300. What acknowledgement number does the client send in the third segment?

• A. 301
• B. 7000
• C. 7001
• D. 300

• 3. Which mechanism allows a receiver to slow down a fast sender?

• A. Three-way handshake
• B. Flow control using the advertised window
• C. Checksum
• D. Urgent pointer

• 4. Why does VoIP use UDP rather than TCP for voice packets?

• A. UDP encrypts the payload
• B. UDP guarantees in-order delivery
• C. Retransmitting late voice samples adds delay and is of no value
• D. TCP cannot carry packets smaller than 1460 bytes

• 5. Which protocol and port does a DHCP server listen on?

• A. TCP 67
• B. UDP 67
• C. UDP 68
• D. UDP 69

• 6. Which two protocols use TCP? (Choose two.)

• A. SSH
• B. TFTP
• C. SNMP
• D. SMTP
• E. NTP

• 7. What uniquely identifies a single TCP connection on a host?

• A. The destination port only
• B. The source IP address and source port
• C. The socket pair: source and destination IP addresses and ports
• D. The MAC address of the client

• 8. A receiver has acknowledged bytes up to 4000 and advertises a window of 3000 bytes. Up to which byte may the sender transmit without waiting for a further acknowledgement?

• A. 3000
• B. 4000
• C. 7000
• D. 7001

• 9. Which TCP flag does a host send to abort a connection immediately or to refuse a connection to a closed port?

• A. FIN
• B. PSH
• C. RST
• D. URG

• 10. An SNMP manager receives unsolicited trap messages on which port?

• A. UDP 161
• B. UDP 162
• C. TCP 161
• D. UDP 514

• 11. Which two statements about DNS are true? (Choose two.)

• A. Standard queries normally use UDP 53
• B. DNS uses only TCP
• C. Zone transfers use TCP 53
• D. DNS uses port 67
• E. DNS requires a three-way handshake for every query

• 12. In netstat -an output, a line reads TCP 0.0.0.0:443 0.0.0.0:0 LISTENING . What does it mean?

• A. The host has an HTTPS connection to a remote server
• B. A local service is waiting for HTTPS connections on all interfaces
• C. The host is blocked from reaching port 443
• D. A UDP application is using port 443

Answers

• 1. B, D. Sequencing and windowing are TCP features. Both protocols use ports and checksums, and only UDP supports broadcast.
• 2. A. The client acknowledges the server's ISN plus one: 300 + 1 = 301. The client's own sequence number in that segment is 7001.
• 3. B. The receiver advertises its window size; shrinking it (even to zero) slows or pauses the sender.
• 4. C. Voice is delay-sensitive. A retransmitted sample would arrive too late to play, so TCP's reliability only adds jitter.
• 5. B. Servers listen on UDP 67; clients use UDP 68. UDP 69 is TFTP.
• 6. A, D. SSH (22) and SMTP (25) use TCP. TFTP, SNMP and NTP use UDP.
• 7. C. The socket pair (with the protocol, the 5-tuple) identifies the connection. Several connections can share a destination port.
• 8. C. The ACK of 4001 confirms bytes up to 4000; the window allows 3000 more, bytes 4001– 7000.
• 9. C. RST resets the connection. FIN performs an orderly close.
• 10. B. Traps and informs go to the manager on UDP 162; the agent listens on UDP 161 for polls.
• 11. A, C. Queries use UDP 53; zone transfers and large responses use TCP 53.
• 12. B. 0.0.0.0 as the local address means all interfaces; LISTENING means a server is waiting. An active connection would be ESTABLISHED with a real foreign address.