TCP vs UDP explained for server owners

TCP and UDP are the two transport protocols that carry almost all internet traffic. You do not need to know their internals to run a server, but you do need to know which one a service uses. Get it wrong and a firewall rule that looks correct does nothing. This guide explains the difference in plain terms and shows how it affects your VPS.

Before you start

• You should know what a port is: a number that lets one IP address run many services. If not, start with Network ports explained.
• The examples use a Linux VPS or a Windows server. The ideas apply to both.

TCP: a connection with delivery checks

TCP (Transmission Control Protocol) works like a phone call.

1. Handshake: before any data moves, the client and server exchange three packets (SYN, SYN-ACK, ACK) to open a connection.
2. Ordered, reliable delivery: data is numbered. The receiver confirms what arrived, and the sender resends anything lost. The application always gets the bytes in the right order.
3. Flow and congestion control: TCP slows down when the network or the receiver is overloaded.
4. Clean close: both sides agree when the connection ends.

The cost is overhead and delay. The handshake adds a round trip before data flows, and a lost packet holds up everything behind it until it is resent.

Services that need every byte correct use TCP:

• SSH (22), web traffic over HTTP and HTTPS (80, 443).
• Remote Desktop. On Windows servers that is TCP 3389.
• Email (25, 587, 993), databases (3306, 5432), file transfer.

UDP: fire-and-forget datagrams

UDP (User Datagram Protocol) works like posting letters.

• No handshake: the client just sends a packet, called a datagram.
• No delivery guarantee: packets can be lost, duplicated or arrive out of order. UDP does not notice or fix it.
• Low overhead: small headers and no waiting, so it is fast and good for real-time traffic.

Applications that use UDP either tolerate some loss or add their own reliability on top. Common UDP services:

• DNS (53): short questions and answers. A lost query is simply retried. DNS also uses TCP for large answers and zone transfers.
• NTP (123): time sync.
• VPNs: WireGuard (often 51820) and OpenVPN (often 1194) prefer UDP because TCP inside TCP performs badly.
• Voice, video and game servers: a late packet is useless, so resending makes no sense.
• HTTP/3 (443 UDP): built on QUIC, which adds reliability on top of UDP.
• Remote Desktop's UDP transport: standard RDP can use UDP alongside TCP for smoother video, but the session always starts on TCP.

Side-by-side summary

• Connection: TCP opens one with a handshake. UDP does not.
• Reliability: TCP resends lost data and keeps order. UDP does not.
• Speed and latency: UDP has less overhead and no head-of-line blocking. TCP is slower to start.
• Typical use: TCP for logins, web, mail and files. UDP for DNS, VPNs, streaming, voice and games.
• Error you see when nothing listens: TCP gets a clear "connection refused". UDP often gets no answer at all, which looks the same as a firewall drop.

Why firewall rules need the protocol

A port number alone is not enough. TCP port 53 and UDP port 53 are separate, and most firewalls treat them separately.

UFW on Linux:

sudo ufw allow 51820/udp     # WireGuard
sudo ufw allow 443/tcp       # HTTPS
sudo ufw allow 53            # both TCP and UDP

firewalld on AlmaLinux or Rocky Linux:

sudo firewall-cmd --permanent --add-port=51820/udp
sudo firewall-cmd --reload

Windows Firewall in PowerShell:

New-NetFirewallRule -DisplayName "WireGuard UDP 51820" `
  -Direction Inbound -Protocol UDP -LocalPort 51820 -Action Allow

Common mistakes:

• Opening 51820/tcp for WireGuard. The VPN never connects.
• Opening only 53/udp for an authoritative DNS server. Large responses and zone transfers over TCP fail.
• Allowing UDP for a game but forgetting the TCP port it uses for login or downloads.

Check it works

See which protocol each listening service uses. On Linux:

sudo ss -tulpn

The first column reads tcp or udp. On Windows:

Get-NetTCPConnection -State Listen | Select-Object LocalPort -Unique
Get-NetUDPEndpoint | Select-Object LocalPort -Unique

Test a TCP port from another machine:

nc -vz 203.0.113.10 443

Test a UDP port. Because UDP has no handshake, a "succeeded" result only means no error came back, not that the service answered:

nc -vzu 203.0.113.10 51820

For UDP, testing with the real client, such as dig for DNS or the WireGuard app, is more reliable.

Troubleshooting

• UDP service seems open but clients cannot use it: UDP tests are unreliable. Test with the real client and check the server logs.
• VPN connects on one network but not another: some networks block UDP. Check whether your VPN can fall back to TCP.
• DNS works for small lookups but fails for some records: TCP 53 is blocked. Allow both protocols.
• Firewall rule exists but has no effect: it names the wrong protocol. List rules and compare with ss -tulpn.

Next steps

• Look up a port number: Common server ports and what uses them.
• Test ports properly: Test a port with nc and telnet.
• Write the rules: Open ports with UFW.