TCP vs UDP: What the Difference Actually Means

By John Herwick · Last updated: July 3, 2026

TCP vs UDP is the first real fork in how data moves across a network. One protocol confirms every byte, and the other fires packets and moves on. Every service you touch, from this web page to your last video call, picked a side.

This guide explains both protocols without the textbook fog. You will see the handshake, the headers, the real ports, and the modern exception that broke the old rules.

What TCP and UDP Actually Are

TCP and UDP are the internet’s two main transport protocols, both defined at Layer 4. TCP delivers data reliably and in order through a managed connection. UDP sends independent packets with no guarantees. Nearly every application you use is built on one of them.

TCP is the Transmission Control Protocol, and UDP is the User Datagram Protocol. Both live at Layer 4, the transport layer of the OSI model. Both do the same basic job. They move application data between two hosts and use port numbers to sort it.

The difference is philosophy. TCP treats data as a stream that must arrive complete and in order. UDP treats data as independent packets and lets the application worry about the rest. Neither approach is better in general. Each is better for specific jobs.

That is why the protocol column exists in every port reference table. The number alone tells you where traffic goes. The protocol tells you how it behaves on the way.

How TCP Works: The Three-Way Handshake

TCP opens every connection with a three-way handshake: SYN, SYN-ACK, and ACK. It then numbers each byte, confirms delivery with acknowledgments, retransmits anything lost, and hands data to the application in order. The modern specification is RFC 9293, published in August 2022.

Nothing moves over TCP until both sides agree to talk. That agreement is the famous three-way handshake:

From there, TCP earns its reputation for reliability. Every byte is numbered. The receiver sends acknowledgments confirming what arrived. Anything unconfirmed gets retransmitted. Segments that arrive out of order are reassembled before the application sees them. Flow control keeps a fast sender from drowning a slow receiver. Closing the connection uses its own exchange of FIN and ACK segments.

All of that machinery costs overhead. A TCP header starts at 20 bytes, and every conversation begins with a full round trip before any data flows.

One detail most guides still get wrong: the 1981 specification is retired. RFC 9293, published in August 2022, consolidated four decades of fixes and now stands as the official TCP standard. Articles citing RFC 793 as current are quoting an obsoleted document.

How UDP Works: Send It and Move On

UDP wraps data in an 8-byte header and sends it immediately, with no handshake and no delivery tracking. Lost packets are not retransmitted, and nothing arrives in guaranteed order. That bare-bones design, defined in RFC 768 back in 1980, is exactly what makes it fast.

UDP is almost aggressively simple. The entire specification, RFC 768 from 1980, fits on three pages. The header holds exactly four fields: source port, destination port, length, and checksum. That is 8 bytes total, against 20 or more for TCP.

There is no handshake, no sequence numbering, and no acknowledgment. The sender fires a datagram and immediately moves on. If the packet is lost, reordered, or duplicated, UDP does nothing about it. The application either tolerates the loss or handles recovery itself.

That sounds like a flaw until you consider the workloads. A video call cannot pause to retransmit a frame from half a second ago. The moment has passed, so the right move is to skip it and stay current. The same logic applies to game state, live streams, and DNS queries. For those jobs, fresh beats complete, and UDP is the honest choice.

TCP vs UDP: The Side-by-Side Comparison

The TCP vs UDP choice trades reliability for speed. TCP guarantees ordered, confirmed delivery at the cost of handshakes and larger headers. UDP delivers raw speed and low latency with zero guarantees. Pick TCP when data must be complete and UDP when data must be fresh.

	TCP	UDP
Connection setup	Three-way handshake before data flows	None, packets go immediately
Delivery guarantee	Yes, confirmed with acknowledgments	No, lost packets stay lost
Ordering	Reassembled in sequence	Arrival order not guaranteed
Retransmission	Automatic for lost segments	None, left to the application
Header size	20 bytes minimum	8 bytes, always
Overhead and latency	Higher, extra round trips	Minimal by design
Typical uses	Web, email, SSH, file transfer, databases	DNS, DHCP, VoIP, streaming, gaming, VPNs

A useful mental shortcut: TCP is registered mail with a signature at delivery. UDP is a postcard. The postcard is cheaper and faster, and most of the time it arrives just fine.

Which Ports Use TCP and Which Use UDP

Web, email, and remote access run on TCP: ports 443, 587, and 22. DNS, DHCP, NTP, and most VPN and voice traffic run on UDP: ports 53, 67, 123, and 51820. The protocol column matters as much as the port number.

Real port assignments make the split concrete. On the TCP side: HTTPS on 443, HTTP on 80, SSH on 22, email submission on 587, and databases like MySQL on 3306. All of them move data that must arrive complete.

On the UDP side: DNS queries on 53, DHCP on 67 and 68, and NTP on 123. VPNs join them, with OpenVPN on 1194 and WireGuard on 51820. All of them prize speed or send small self-contained messages.

Some services span both. DNS uses UDP 53 for normal queries but falls back to TCP 53 for large responses and zone transfers. SIP voice signaling registers 5060 on both protocols, and Windows RDP listens on TCP and UDP 3389. Remember that the two number spaces are independent, so a firewall rule for one does not cover the other.

For the full annotated list, use our searchable port number reference. The category walkthrough lives in common network ports explained. IANA holds the official registry behind both.

QUIC and HTTP/3: Why the Old Rules Changed

QUIC, standardized as RFC 9000 in May 2021, rebuilds TCP-grade reliability and encryption on top of UDP. HTTP/3 runs on it, and about 39 percent of websites now support it. The old rule that UDP means unreliable no longer holds.

For decades, the shorthand held: TCP means reliable, UDP means fast and lossy. QUIC broke that shorthand. It was standardized in RFC 9000 in May 2021. QUIC runs over UDP port 443 and rebuilds the good parts of TCP inside itself. It numbers data, acknowledges delivery, retransmits losses, and manages congestion.

It also fixes TCP’s biggest web-era weakness. When one TCP segment goes missing, everything behind it waits, a problem called head-of-line blocking. QUIC runs multiple independent streams, so one lost packet stalls only its own stream. It folds the TLS 1.3 encryption handshake into the transport handshake too, saving round trips on every new connection.

HTTP/3, defined in RFC 9114 in June 2022, is the version of the web protocol that runs on QUIC. Adoption is no longer fringe. W3Techs measures HTTP/3 support at roughly 39 percent of all websites as of 2026. There is a fair chance this very page reached you over UDP.

The takeaway for the TCP vs UDP question: UDP is a foundation, not a verdict. Reliability is now something a protocol can build wherever it wants.

Troubleshooting: When the Protocol Is the Problem

Protocol mismatches cause quiet failures. A firewall that allows TCP but blocks UDP kills DNS and VPN traffic while websites keep loading by IP. Test the exact protocol and port a service uses, not just general reachability, before blaming the network.

Because TCP and UDP are filtered separately, firewall rules written for one protocol silently miss the other. The classic symptom: cached websites load, pings succeed, but new name lookups fail. That pattern points at blocked UDP 53. Our guide to how DNS works shows what those queries look like. The DNS speed test exercises the UDP path straight from your browser.

Your test tools have protocol bias too. telnet and PowerShell’s Test-NetConnection open TCP connections only. A UDP service can be perfectly healthy while both tools report failure. Meanwhile, Linux traceroute sends UDP probes by default, while Windows tracert uses ICMP. The two can show different results on the same path.

When a service is unreachable, confirm three things in order. First, the port number. Second, the protocol, TCP or UDP. Third, that the firewall rule names both correctly. If the problem runs deeper than one blocked port, our network troubleshooting guide walks the full diagnostic tree.

Related Tools

These free NetworkCheckr tools pair with everything above. Look up any port and its protocol in seconds. Then test the UDP-based DNS path from your browser and compare resolver speed across providers.

• Port Number Reference — Search 76+ common ports with their TCP or UDP protocol.
• DNS Lookup — Run the classic UDP port 53 query for any domain.
• DNS Speed Test — Benchmark public resolvers over the UDP-first DNS path.
• SSL Certificate Checker — Inspect the certificate a server presents on TCP port 443.
• All Network Tools — The full free toolkit in one place.

Frequently Asked Questions

Short answers to the questions people ask most about TCP vs UDP. Each one expands on a section above. They cover speed, security, DNS behavior, gaming traffic, the handshake, and how both protocols share port numbers.