TCP vs UDP: Differences, Ports and When Each Is Used

TCP and UDP are the two main transport protocols on the internet. TCP sets up a connection and guarantees that data arrives complete and in order, while UDP sends independent packets with no delivery guarantees, which makes it simpler and faster for real-time traffic like games, voice calls and DNS.

Both run on top of IP and both use port numbers to identify applications, but they make opposite trade-offs. Knowing which one a service uses matters when you open a firewall, set up port forwarding or troubleshoot a connection that half works.

TCP vs UDP at a glance

How TCP works

The three-way handshake

Before any data flows, the two sides agree to talk:

1. The client sends a SYN segment with a random initial sequence number.
2. The server answers with SYN-ACK, acknowledging the client's number and choosing its own.
3. The client sends ACK. The connection is now established.

That exchange costs one round trip before the first byte of data. On a link with 80 ms latency, a new TCP connection waits at least 80 ms, plus the time for a TLS handshake if the connection is encrypted.

Reliability and ordering

TCP numbers every byte it sends. The receiver acknowledges what has arrived, and the sender retransmits anything that is not acknowledged in time. The receiver reassembles segments in order before handing them to the application, so a web server or SSH session sees a clean, gap-free stream.

Flow control and congestion control

The receiver advertises a window, the amount of data it can buffer, so a fast sender does not overwhelm a slow receiver. Separately, congestion control algorithms slow the sender down when packet loss or rising delay suggests the network path is overloaded. This is why a large download starts slowly and ramps up.

Closing a connection

Either side ends its half of the connection with a FIN, which the other side acknowledges. An RST aborts a connection immediately; it is also what you receive when you connect to a port where nothing is listening.

How UDP works

UDP adds almost nothing to IP: a source port, destination port, length and checksum. An application hands UDP a message, UDP sends it as one datagram, and that is the end of UDP's involvement. There is no handshake, no acknowledgement and no retransmission. If ordering or reliability matters, the application builds whatever it needs on top.

That minimalism is the point. A UDP query can be answered in a single round trip, there is no per-connection state on the server, and a late packet never holds up the ones behind it.

Why games, calls and DNS prefer UDP

• Stale data is worthless. In a video call or a multiplayer game, a packet that arrives 300 ms late is useless. TCP would pause the whole stream to retransmit it, causing a freeze. UDP lets the application skip it and render the next frame or position update.
• No head-of-line blocking. With TCP, one lost segment delays everything after it until it is resent. UDP-based protocols can keep independent streams independent.
• Small request-response exchanges. A DNS lookup fits in one packet each way. A TCP handshake would at least double the time per query.
• Broadcast. DHCP must reach a server before the client has an address, which requires broadcast, which TCP cannot do.

When UDP traffic switches to TCP

DNS is the classic dual-protocol service. Queries go over UDP port 53, but if the answer is too large the server sets the truncation (TC) flag and the client retries over TCP port 53. Zone transfers also use TCP, and RFC 7766 requires DNS software to support TCP. Blocking TCP 53 on a firewall therefore causes subtle DNS failures.

QUIC: reliability built on UDP

QUIC (RFC 9000) is a transport that runs over UDP but provides reliable, encrypted, multiplexed streams. It combines the transport and TLS handshakes, and a lost packet only stalls the stream it belongs to. HTTP/3 (RFC 9114) runs over QUIC on UDP port 443, so a modern browser loading a site may be using UDP for the page itself, falling back to TCP 443 if UDP is blocked.

Common ports by protocol

Port numbers are 16-bit, from 0 to 65535, and TCP port 53 and UDP port 53 are separate ports. Some well-known assignments:

For a longer list, see our reference of common network ports. When you forward a port or write a firewall rule, select the protocol the service actually uses; a TCP-only rule does nothing for a game server that listens on UDP.

Checking TCP and UDP ports

See what is listening locally

# Linux: TCP and UDP listeners with the owning process
sudo ss -tulpn

# macOS
sudo lsof -nP -iTCP -sTCP:LISTEN
sudo lsof -nP -iUDP

# Windows (PowerShell)
Get-NetTCPConnection -State Listen
Get-NetUDPEndpoint

Test a remote port

# TCP: succeeds only if the handshake completes
nc -vz example.com 443
Test-NetConnection example.com -Port 443     # Windows PowerShell

# UDP: much less conclusive
nc -vzu 198.51.100.10 53

Testing TCP is straightforward: the handshake either completes (open), gets an RST (closed) or gets no answer (filtered). UDP has no handshake, so an open port often stays silent unless the probe is a valid request for that service. A closed UDP port may return an ICMP "port unreachable" message, but firewalls often suppress it. That is why most online tools, including our open port checker, test TCP only. To test a UDP service, use the application itself, such as a dig query for DNS or the game client for a game server.

Frequently asked questions

Is UDP faster than TCP?

UDP has lower overhead and no setup delay, so the first data arrives sooner and late packets never block later ones. For bulk transfers on a clean link, TCP achieves similar throughput. The real difference is latency behaviour under packet loss, not raw bandwidth.

Is UDP less secure than TCP?

Neither protocol encrypts anything; that is the job of TLS, DTLS, QUIC or a VPN. UDP is easier to spoof because there is no handshake to confirm the sender's address, which is why open UDP services such as misconfigured DNS or NTP servers are abused for reflection attacks.

Can a port use TCP and UDP at the same time?

Yes. TCP and UDP have separate port spaces, so one program can listen on TCP 53 and another, or the same one, on UDP 53 simultaneously.

Should I choose TCP or UDP for my VPN?

Prefer UDP when it works. Tunnelling TCP traffic inside a TCP tunnel stacks two sets of retransmission timers, which can sharply reduce throughput on lossy links. Use TCP mode only on networks that block UDP.