A situation
Your team is writing firewall rules for a new server. It runs a website, a DNS service and a voice system. For each one, the rule must say TCP or UDP, not just a port number. If you pick the wrong protocol, the service breaks. So you need to know which protocol each application uses, and why.
What it is: side by side
| TCP | UDP | |
|---|---|---|
| Connection | Connection-oriented: three-way handshake first | Connectionless: sends straight away |
| Delivery | Reliable: lost data is resent | Best effort: lost data stays lost |
| Order | Data is passed to the application in order | No ordering |
| Flow and congestion control | Yes (windowing) | No |
| Header size | 20–60 bytes | 8 bytes |
| Data unit | Segment (part of a byte stream) | Datagram (one separate message) |
| Broadcast and multicast | Not possible | Possible |
| Typical uses | Web, email, file transfer, SSH | Voice, video, DNS, DHCP, NTP, games |
💡 In simple terms: TCP is a tracked parcel: it is signed for, and if it goes missing, it is sent again. UDP is a postcard: cheap and fast, but if it is lost, nobody knows.
Speed: the first bytes
- 1. TCP, trip 1: the client asks to connect. No data yet.
- 2. TCP, trip 2: the server agrees. There is still no data.
- 3. TCP, trip 3: only now can the request be sent.
- 4. UDP, trip 1: the very first datagram already carries the question.
- 5. UDP, trip 2: the answer comes back, after just one round trip.
Why each one wins
Neither protocol is “better”; each is a trade-off. TCP spends time and bandwidth to make sure every byte arrives, in order. UDP adds almost no overhead and leaves loss and ordering to the application.
For example, take a video call on an unreliable connection. Over UDP, a few lost packets cause a flicker or a moment of broken sound, and the call carries on in real time. Over TCP, the same loss would make the stream stop and wait while the missing data was resent. For a live conversation, that freeze is much worse than a small glitch.
How to choose
Ask these questions about the application:
| Question | If yes |
|---|---|
| Must every byte arrive, exactly as sent? (files, web pages, logins) | TCP |
| Is late data useless? (live voice, video, games) | UDP |
| Is it one short question and answer? (DNS, NTP) | UDP |
| Must it reach many receivers at once, or a host with no address? (multicast, DHCP) | UDP |
| Is it a long transfer that should share the link fairly? | TCP |
Some services use both. DNS uses UDP for normal lookups and TCP for large answers and zone transfers. HTTPS mostly uses TCP 443, but HTTP/3 runs over QUIC on UDP 443.
How to verify it
On a Cisco router, each access control list (ACL) rule names the protocol, so the match counters show how much traffic of each kind arrives. The output below is based on Cisco documentation, not captured from a lab device.
R1#show access-lists EDGE-IN Extended IP access list EDGE-IN 10 permit tcp any host 203.0.113.10 eq 443 (15230 matches) 20 permit udp any host 203.0.113.10 eq 443 (40112 matches) 30 permit udp any host 203.0.113.53 eq domain (9921 matches) 40 permit tcp any host 203.0.113.53 eq domain (37 matches)
eq domain means port 53) receives mostly UDP, plus a few TCP queries for large answers or zone transfers. Leaving out line 40 would break those large lookups.Check yourself
A company backs up its database to a remote server every night. Which protocol fits best?
A video system must send the same stream to 200 screens at once using a single multicast address. Why does it use UDP rather than TCP?
A firewall allows UDP 53 to a DNS server, but not TCP 53. What might fail?