Transport-Layer Services

TCP, UDP, and Ports

IP addressing gets packets from one host to another, but applications need a way to identify the correct conversation on each host. That is the job of transport-layer services. The two transport protocols technicians see most often are TCP and UDP. Both use port numbers, but they provide different behavior.

TCP, the Transmission Control Protocol, is connection-oriented. Before application data flows, TCP uses a handshake to establish a session. It numbers data, acknowledges received data, retransmits missing data, and uses flow control to avoid overwhelming the receiver. These features are useful for web browsing, file transfers, email submission, remote administration, and other applications where complete and ordered delivery matters. TCP has more overhead than UDP, but it gives applications a reliable stream service.

UDP, the User Datagram Protocol, is connectionless. It sends datagrams without first building a TCP-style session and without TCP's built-in acknowledgments or retransmissions. This does not mean UDP is bad or unreliable in every sense. It means reliability, ordering, or loss recovery must be handled by the application if needed. UDP is often used where low overhead or timing matters, or where a simple request-response pattern is enough. Common examples include DNS queries, DHCP messages, some voice and video traffic, and many streaming or real-time services.

Port numbers identify the application or service endpoint on a host. A server listens on a port, and a client opens a source port for its side of the conversation. For example, a web server might listen on TCP port 443 for HTTPS. A client connecting to that server uses an ephemeral source port chosen by the operating system. The full conversation can be tracked by source IP, source port, destination IP, destination port, and protocol. This combination is important for firewalls, NAT tables, packet captures, and troubleshooting.

A firewall may permit DNS to a resolver but block other UDP traffic. A NAT device may allow many inside clients to share one public IPv4 address by tracking each translation with port numbers. A packet capture may show that TCP connection attempts are sent but no replies return. A support ticket may say the Internet works, but a single application fails. In that case, the problem may be a blocked port, wrong server address, expired certificate, application proxy, name resolution issue, or server outage rather than a general network failure.

At CCST depth, memorize concepts more than giant port lists. Know that HTTP commonly uses TCP 80, HTTPS uses TCP 443, DNS commonly uses UDP 53 and may use TCP 53 for some operations, DHCP uses UDP, SSH uses TCP 22, and ping uses ICMP rather than TCP or UDP. Also know that port numbers do not replace IP addresses. IP gets traffic to the host, and the transport layer helps deliver it to the right application process.

When troubleshooting, describe the symptom precisely. Can the client get an IP address? Can it resolve the server name? Can it reach the gateway? Does only one application or port fail? Does the problem affect TCP, UDP, or both? These distinctions help an engineer decide whether to inspect host settings, firewall rules, NAT behavior, server status, or packet loss.

Study Checkpoint

• Topic: Transport-Layer Services.
• Verify the official Cisco concept before memorizing a shortcut.
• Practice the technician action: observe, document, test, fix when supported, or escalate.