CCNA TCP vs UDP: Ports, Reliability, Handshake & Protocol Use Cases

TCP (Transmission Control Protocol) is defined in RFC 793 and operates at Layer 4 of the OSI model. TCP provides reliable, ordered, and error-checked delivery of a byte stream between applications. 'Reliable' means the receiver acknowledges every segment; the sender retransmits anything not acknowledged within a timeout window.

TCP is connection-oriented — a logical connection must be established before data transfer begins, using the 3-way handshake, and explicitly torn down afterward with a 4-way FIN exchange. The connection tracks state on both sides: sequence numbers, acknowledgment numbers, window sizes, and connection state (LISTEN, SYN_SENT, ESTABLISHED, TIME_WAIT, etc.).

TCP features: sequencing (segments are numbered so the receiver can reorder out-of-order delivery), acknowledgment (receiver sends ACKs for received data), retransmission (sender retransmits unacknowledged segments), flow control (sliding window prevents the sender from overwhelming the receiver), and congestion control (TCP backs off when it detects network congestion).

Before any TCP application data is exchanged, both sides establish a connection using the 3-way handshake: SYN → SYN-ACK → ACK.

Step 1 (SYN): the client sends a TCP segment with the SYN flag set and a randomly chosen Initial Sequence Number (ISN). This tells the server: 'I want to start a connection; my sequence numbers start at X.'

Step 2 (SYN-ACK): the server responds with SYN and ACK flags set. It acknowledges the client's ISN (ACK = client ISN + 1) and includes its own ISN. This tells the client: 'I accept the connection; your sequence was received; my sequence numbers start at Y.'

Step 3 (ACK): the client acknowledges the server's ISN (ACK = server ISN + 1). The connection is now ESTABLISHED and data transfer can begin.

Connection teardown uses a 4-way exchange: FIN from one side, ACK, FIN from the other, ACK. The TIME_WAIT state (typically 2 × Maximum Segment Lifetime = 4 minutes) ensures delayed packets from the old connection don't confuse a new one on the same port pair.

UDP (User Datagram Protocol, RFC 768) is the minimal transport protocol. It has no connection establishment, no sequencing, no acknowledgment, and no retransmission. A UDP datagram is sent and the sender has no built-in way to know if it arrived.

What UDP does provide: a checksum for basic error detection, source and destination port numbers for multiplexing (identifying which application on each host), and a length field. That's it — the header is only 8 bytes vs TCP's minimum 20 bytes.

UDP is not 'unreliable' in a pejorative sense — it's 'best-effort.' For applications where speed matters more than guaranteed delivery — DNS queries, video streaming, VoIP, online gaming — UDP's lack of overhead is a feature, not a bug. DNS uses UDP because query/response pairs are tiny and a retry is cheap. VoIP uses UDP because a retransmitted voice packet would arrive too late to be useful — silence is better than a stutter.

Applications that need reliability over UDP implement their own mechanisms. QUIC (used by HTTP/3) is a notable example — it provides reliable delivery and TLS encryption but uses UDP to avoid TCP's head-of-line blocking.

TCP flow control prevents a fast sender from overwhelming a slow receiver. The receiver advertises a receive window size in every ACK — the maximum number of bytes it can buffer before the sender must stop and wait. As the receiver processes data and frees buffer space, it advertises a larger window. This is the sliding window mechanism.

TCP windowing also affects throughput on high-latency links. The bandwidth-delay product (BDP) = bandwidth × round-trip time. A 1 Gbps link with 100 ms RTT has a BDP of 12.5 MB — the sender needs a window size of at least 12.5 MB to keep the link fully utilized. Old TCP window sizes were limited to 65,535 bytes; the Window Scale option (RFC 7323) extends this to several GB.

TCP congestion control (slow start, congestion avoidance, fast retransmit, fast recovery) dynamically adjusts the send rate based on network conditions. When packets are dropped (detected by timeout or duplicate ACKs), TCP reduces its send rate — this is the mechanism that prevents TCP flows from overwhelming network links.

Ports 0–1023 are well-known ports assigned by IANA. Ports 1024–49151 are registered ports. Ports 49152–65535 are ephemeral (dynamic) ports used as source ports by clients.

Critical TCP ports for CCNA: FTP data = 20, FTP control = 21, SSH = 22, Telnet = 23, SMTP = 25, HTTP = 80, HTTPS = 443, RDP = 3389.

Critical UDP ports: DNS = 53, DHCP server = 67, DHCP client = 68, TFTP = 69, SNMP = 161, SNMP trap = 162, Syslog = 514, NTP = 123.

Some services use both TCP and UDP: DNS uses UDP 53 for normal queries (responses under 512 bytes) and TCP 53 for zone transfers and large responses. NTP uses UDP 123. RADIUS uses UDP 1812/1813. TACACS+ uses TCP 49.