Transport-Layer Services

TCP and UDP

IP gets a packet from host to host, but a host runs many applications at once, so it needs a way to deliver data to the right one. That is the transport layer (Layer 4), and the two protocols a technician sees most are TCP and UDP. Both use port numbers; their delivery behavior differs sharply.

TCP — Transmission Control Protocol

TCP is connection-oriented and reliable. Before any application data flows, the two sides complete the three-way handshake:

1. Client -> Server: SYN (synchronize, propose a sequence number)
2. Server -> Client: SYN-ACK (acknowledge and propose its own)
3. Client -> Server: ACK (acknowledge; session open)

After that, TCP numbers every byte, acknowledges what it receives, retransmits anything lost, reorders out-of-sequence data, and uses flow control (a sliding window) so a fast sender does not overwhelm a slow receiver. This costs overhead but guarantees a complete, ordered byte stream — ideal for web pages, file transfer, email submission, and remote administration.

UDP — User Datagram Protocol

UDP is connectionless. It fires datagrams with no handshake, no acknowledgments, and no retransmission. That is not 'unreliable' as a flaw — it simply pushes reliability up to the application when needed. The payoff is low overhead and low latency, which suits DNS queries, DHCP, voice and video, and real-time streaming, where a late retransmission would be worse than a small loss.

Ports, Sockets, and Troubleshooting

A port number identifies the application endpoint on a host. A server listens on a fixed well-known port; the client opens a temporary, OS-chosen ephemeral port (commonly 49152-65535) for its side. A full conversation — a socket — is identified by the 5-tuple: source IP, source port, destination IP, destination port, and protocol. Firewalls, NAT/PAT tables, and packet captures all key on this 5-tuple to keep flows separate.

Well-known ports to memorize

At CCST depth, learn the concepts more than a giant list, but know that ping uses ICMP, not TCP or UDP, so a firewall can block ping while allowing web traffic — or vice versa.

When one application fails

A ticket that says "the Internet works but app X is broken" usually is not a general network outage. Likely causes: a blocked destination port, wrong server address, expired TLS certificate, a proxy, a name-resolution issue, or a server outage. Narrow it with precise questions:

• Does the client have an IP, and can it ping the gateway?
• Can it resolve the server's name?
• Does only one application or one port fail?
• Is the failure on TCP, UDP, or both?

A packet capture that shows repeated TCP SYN packets with no SYN-ACK reply points to a blocked port or a server that is not listening — not a cabling fault.

Common traps

• Thinking ports replace IP addresses; IP reaches the host, the port reaches the process.
• Assuming DNS is TCP — it is primarily UDP 53.
• Forgetting ICMP has no port number.
• Believing UDP guarantees order or delivery — it guarantees neither.

Handshake, Teardown, and Reading a Capture

How a TCP session opens and closes

The three-way handshake (SYN, SYN-ACK, ACK) opens a session; a graceful close uses FIN and ACK exchanges, while an abrupt abort uses a RST (reset). Reading these flags tells you a lot in a capture:

• Repeated SYN with no SYN-ACK -> nothing is listening on that port, or a firewall silently dropped the request.
• Immediate RST after a SYN -> a device actively refused the connection (port closed or policy deny).
• Handshake completes but data stalls -> likely an application, certificate, or path-MTU issue, not a connect problem.

This is why 'can the client even open a TCP connection to the server's port?' is such a powerful diagnostic question — it separates network-path faults from application faults.

Port ranges you should recognize

A server's port is fixed and predictable; the client's source port is random and temporary. That asymmetry is exactly what PAT exploits to share one public address.

A precise troubleshooting narrative

Suppose a user can browse most sites but one internal web app times out. The link, DHCP, gateway, and DNS all check out, and ping to the app server succeeds. A capture shows the client sending SYN to TCP 443 with no reply. ICMP (ping) works but TCP 443 does not, which points to a port-level block — a firewall rule, a service that is down, or the wrong port — rather than a connectivity failure. Reporting it as 'TCP 443 to server X returns no SYN-ACK while ICMP succeeds' gives an engineer an immediately actionable lead.

Why this matters for CCST

The 100-150 exam expects you to explain TCP versus UDP behavior, identify common ports and protocols, and interpret simple diagnostic output. You will not write firewall rules, but you must be able to say which layer a symptom lives at: physical, IP, transport, or application. The transport layer is the hinge between 'the network is reachable' and 'this specific application works.'