TCP and UDP: what the transport layer is for
IP can deliver packets between hosts, but applications also need a way to identify conversations and define transport behavior. TCP and UDP provide that service. Both use port numbers so several applications can communicate through the same IP address, but they offer very different contracts.
TCP provides a connection-oriented byte stream with reliability, ordering, flow control, and congestion control. UDP provides independent datagrams with minimal protocol overhead and no built-in guarantee that data will arrive, arrive once, or arrive in order.
Ports, sockets, and conversations between applications
A port identifies an application endpoint within a host. A network conversation is commonly identified by a combination of protocol, source IP, source port, destination IP, and destination port. This is why a browser can create several connections at the same time without confusing their traffic.
Servers often listen on well-known or registered ports, while clients usually choose ephemeral source ports. Port numbers do not provide security by themselves; they are identifiers that firewalls and applications can use as part of policy.
How TCP establishes a connection
TCP normally begins with the three-way handshake: the client sends SYN, the server responds with SYN-ACK, and the client completes the exchange with ACK. The handshake synchronizes initial sequence information and confirms that both endpoints can exchange TCP segments.
A failed handshake can reveal useful clues: no response may indicate filtering or reachability problems; an immediate reset often means the host is reachable but no service accepts the connection on that port.
Sequence numbers, ACKs, retransmission, and ordered delivery
TCP numbers the byte stream so the receiver can acknowledge what has arrived and place data in order. Missing data can be retransmitted. Duplicate segments can be recognized. The application receives an ordered stream even when individual IP packets take different paths or arrive out of order.
This reliability is not free. It requires state at both endpoints and additional exchanges when packets are lost. High loss or long round-trip time can therefore reduce TCP performance significantly.
Flow control and congestion control
Flow control protects the receiver by advertising how much data it can accept. Congestion control protects the network by adapting the sender's rate to observed delivery conditions. They solve different problems even though both influence how much data is in flight.
Modern TCP implementations use algorithms that evolve over time, but the general idea remains: increase throughput when the path is healthy and back off when signals suggest congestion or loss.
UDP: datagrams with a minimal contract
UDP sends independent datagrams without establishing a transport connection. It includes source and destination ports, length, and checksum information, but it does not retransmit lost data or reorder it for the application.
This makes UDP useful when the application wants low overhead, controls reliability itself, or prefers timely data over retransmission of old data. DNS commonly uses UDP for ordinary queries, while real-time media, games, telemetry, and modern transports such as QUIC can also build on UDP.
MSS, MTU, and fragmentation are not the same thing
MTU is the maximum Layer 3 packet size that a link can carry without exceeding its payload limit. TCP MSS is the maximum amount of TCP payload an endpoint wants in one segment. MSS is normally chosen with the path/interface MTU in mind so TCP segments fit inside IP packets.
IPv4 routers may fragment under some conditions, while IPv6 routers do not fragment transit packets. Path MTU Discovery and correct ICMP handling are therefore important to avoid black-hole behavior.
When should you choose TCP or UDP?
Use TCP when the application benefits from an ordered reliable stream and the transport should handle retransmission. Use UDP when the application needs message-oriented datagrams, wants minimal transport state, can tolerate loss, or implements its own reliability and congestion behavior.
The choice is made by the application protocol, not by the network administrator. Network devices must then support and secure the resulting traffic appropriately.
TCP and UDP in NAT, ACLs, and firewalls
NAT and PAT often track transport ports to distinguish simultaneous flows. ACLs can match protocol and port information. Stateful firewalls go further by tracking connection state and expected return traffic.
TCP's explicit state makes stateful inspection straightforward, while UDP flows are usually tracked with timers because there is no connection teardown handshake. A firewall policy should be based on required services rather than on broad assumptions such as "UDP is unsafe" or "TCP is secure."
Troubleshooting TCP and UDP
- Confirm IP reachability and routing first.
- Verify that the destination service is listening on the expected protocol and port.
- Check DNS separately from transport.
- Inspect firewalls, ACLs, NAT, and security groups along the path.
- For TCP, inspect SYN/SYN-ACK/ACK, resets, retransmissions, and window behavior.
- For UDP, verify that requests leave, replies return, and application timers are appropriate.
- Use packet captures when logs and counters cannot explain the failure.
Pair this guide with ICMP and the broader network protocols guide.