TCP, UDP, and what the transport layer decides for you

Why this matters

Every port number from lesson 8 comes with a protocol attached, and candidates routinely memorise the number and skip the protocol. That is a mistake the exam punishes directly, because a firewall rule permitting TCP 53 while an application queries over UDP 53 is a rule that does nothing — and that scenario appears in one form or another on most practice papers.

The deeper reason is diagnostic. TCP and UDP fail differently, and the symptom a user describes usually names which one is involved. "It hangs for thirty seconds and then gives an error" is TCP retrying. "The video is choppy but keeps going" is UDP doing exactly what it was chosen to do.

A technician who can name what the transport layer guarantees can predict what a fault will look like before seeing it, which is most of the value of knowing any model.

The lesson

Connection-oriented against connectionless, in terms of what each guarantees

TCP is connection-oriented. Before any data moves, the two ends establish state, and from then on TCP guarantees:

• Delivery, by acknowledging every segment and retransmitting anything unacknowledged.
• Order, by numbering segments and reassembling them correctly.
• Flow control, so a fast sender does not overwhelm a slow receiver.
• Congestion control, so a fast sender does not overwhelm the network.

UDP is connectionless. It adds ports and a checksum to the packet and nothing else. It guarantees nothing: packets may be lost, duplicated or reordered, and the application is responsible for noticing.

What UDP gives in return is not having to wait. There is no setup, no acknowledgement, no retransmission, and therefore no delay caused by any of them. For a live voice call, a packet that arrives late is worthless — the moment it described has passed — so retransmitting it wastes bandwidth to deliver something nobody can use.

The rule that follows, and it is the examinable one: choose TCP when every byte must arrive, choose UDP when late data is useless.

The handshake, and what a half-open connection looks like from the outside

TCP establishes a connection with three messages:

1. The client sends SYN, proposing a connection and an initial sequence number.
2. The server replies SYN-ACK, acknowledging and proposing its own.
3. The client sends ACK, and the connection is established.

Teardown is normally four messages using FIN in each direction, or an abrupt RST when one side refuses or aborts.

The diagnostic value is in what each failure looks like:

• SYN with nothing back. The client waits and retries, then times out after a long delay. This is the signature of a firewall dropping traffic, and the long wait is characteristic — users describe it as "it just sits there".
• SYN answered by RST. Immediate refusal. The host is reachable and nothing is listening on that port. Users describe this as "it fails straight away", and the speed of the failure is the evidence.
• Handshake completes, then nothing. The path and the service are fine; the problem is above the transport layer — authentication, application configuration, or a payload the server rejects.

A half-open connection is one where the handshake started and never finished. A machine holding many of them is either behind a badly behaved network path or the target of a flood, and the state is visible in the host's own connection listing.

Why voice and video chose the protocol that does not retransmit

Real-time media is the canonical UDP case and the exam's favourite example.

A voice stream sends a small packet every twenty milliseconds. If one is lost, TCP's response would be to retransmit it and hold everything behind it until it arrives — head-of-line blocking — so a single lost packet turns into an audible gap plus a growing delay. UDP's response is to carry on, and the application conceals the loss by interpolating.

The same reasoning covers several other UDP services on the exam's list:

• DNS queries are small, fit in one packet, and are cheaper to simply ask again than to set up a connection for. DNS falls back to TCP for large responses and zone transfers.
• DHCP cannot use TCP, because a client without an address cannot establish a connection. It broadcasts.
• TFTP is deliberately minimal for devices with almost no firmware.
• SNMP sends small, frequent, individually unimportant readings.

Streaming video that is not live is the interesting counter-example: it is usually delivered over TCP inside HTTPS, because a buffer of several seconds makes retransmission affordable, and reliability matters more than latency.

Ports as endpoints: sockets, ephemeral ranges and what a firewall has to permit

A port on its own is half an address. A connection is identified by four things: source address, source port, destination address, destination port — together with the protocol. That combination is what lets one server hold thousands of simultaneous connections on port 443.

The destination port is the well-known one from lesson 8. The source port is chosen by the client from a high-numbered ephemeral range and is meaningless beyond identifying that particular conversation.

The consequence for firewall rules is the part the exam tests:

• A stateful firewall records the outbound connection and automatically permits the matching return traffic. One rule, outbound, is enough.
• A stateless filter evaluates every packet independently, so it needs a rule for the return traffic too — which means permitting the ephemeral range inbound. That is why stateless rule sets are longer and looser.

This is also why "open port 443 outbound" is a complete instruction and "open port 443" on its own is ambiguous. Direction is part of the rule.

Diagnosing a service that answers on one protocol and not the other

The symptom is a service that partly works, and the cause is nearly always a rule or a configuration that names one protocol where the traffic uses both.

The classic cases:

• DNS resolving small names and failing on large responses. UDP is permitted, TCP is not, and the fallback path is blocked. Presents as "most sites work and one does not".
• A firewall rule written for TCP on a UDP service. Nothing works at all, and the rule looks correct in the console, which is why it survives review.
• A VPN that establishes and carries nothing. The control channel and the data channel may use different protocols and ports; permitting one without the other produces exactly this.
• A service that works locally and not across a router, where the local path is broadcast-based and the router does not forward broadcasts. DHCP across subnets is the standard example, solved with a relay.

The method is the same each time: identify which protocol and port the traffic actually uses — from documentation or from a capture — then compare against what the path permits. Assuming rather than checking is what leaves these faults in place for months.