TCP vs UDP: What's the Difference (And When Does It Matter)?

TCP (Transmission Control Protocol) is a connection-oriented transport protocol that guarantees data arrives completely, in order, and without errors, at the cost of some overhead and latency. UDP (User Datagram Protocol) is a connectionless protocol that fires data as fast as possible without any guarantees about delivery, ordering, or integrity. Together, these two protocols handle virtually all data transport on the internet, and the choice between them affects everything from how fast your video loads to whether your game character teleports across the map.

The Fundamental Difference (In One Sentence)

TCP is like sending a certified letter with tracking. You know it arrived, you know it wasn’t tampered with, and if it gets lost, it gets resent. UDP is like shouting across a crowded room. You throw the message out there and hope for the best.

Both approaches are useful. The trick is knowing which situation calls for which.

TCP: The Reliable One

TCP was designed with one priority: get data from point A to point B accurately and completely, even if the network between them is unreliable. And in the early internet, the network was very unreliable.

How TCP Connection Works

Before any data is sent, TCP establishes a connection through a three-way handshake:

1. SYN: Your computer sends a SYN (synchronize) packet to the server saying “I want to talk.”
2. SYN-ACK: The server responds with SYN-ACK saying “Okay, I’m ready. Let’s talk.”
3. ACK: Your computer sends an ACK (acknowledge) saying “Great, let’s go.”

Only after this handshake completes can data start flowing. This takes one full round-trip between client and server (plus the initial SYN), which adds latency before any useful data is exchanged. On a connection with 100ms latency, that’s 150ms just for the handshake.

What TCP Does With Your Data

Once the connection is open, TCP provides several guarantees:

Reliability: Every segment of data sent gets an acknowledgment back. If the sender doesn’t get an acknowledgment within a timeout period, it assumes the data was lost and retransmits it. This keeps happening until the data is confirmed received or the connection gives up.

Ordering: TCP assigns sequence numbers to each byte of data. If packets arrive out of order (which happens regularly on the internet because packets can take different paths), the receiving side reassembles them in the correct sequence before handing the data to the application.

Flow control: TCP uses a “sliding window” mechanism where the receiver tells the sender “I have this much buffer space available, don’t send more than that.” This prevents fast senders from overwhelming slow receivers.

Congestion control: TCP monitors the network for signs of congestion (packet loss, increasing latency) and automatically reduces its sending rate to avoid making things worse. This is actually one of the main reasons the internet works at all, because without congestion control, every connection would just blast data as fast as possible and the network would constantly collapse.

Error detection: A checksum in the TCP header detects corrupted data. If a segment arrives with a bad checksum, it gets discarded and retransmitted.

The Cost of All This

All those guarantees come at a price:

• The three-way handshake adds latency to every new connection
• Acknowledgments consume bandwidth in both directions
• Head-of-line blocking: if one packet is lost, all subsequent data waits until that packet is retransmitted, even if the later data arrived fine
• More complex header (20 bytes minimum vs UDP’s 8 bytes)
• More CPU and memory overhead for tracking connection state

UDP: The Fast One

UDP’s design philosophy is fundamentally different: just send the data and get out of the way. No connection setup, no acknowledgments, no retransmission, no ordering, no congestion control. It wraps your data in a minimal header and shoves it onto the network.

What a UDP Packet Looks Like

The UDP header is only 8 bytes:

• Source port (2 bytes)
• Destination port (2 bytes)
• Length (2 bytes)
• Checksum (2 bytes, optional in IPv4, mandatory in IPv6)

That’s it. Compare this to TCP’s minimum 20-byte header packed with sequence numbers, acknowledgment numbers, flags, window sizes, and options.

Why Would You Want Unreliable Data Transfer?

Because sometimes reliability is worse than losing data. Consider these scenarios:

Live video streaming: You’re watching a Twitch stream. A packet carrying one frame of video gets lost. With TCP, everything would freeze while that specific frame is retransmitted. By the time it arrives, the stream has moved on and that frame is irrelevant. With UDP, the stream skips that frame and continues playing the next one. A tiny glitch versus a noticeable pause.

Online gaming: Your character’s position is sent 60 times per second. If packet 47 is lost, packet 48 (arriving 16ms later) has a more current position anyway. Retransmitting packet 47 would be pointless.

Voice over IP (VoIP): You’re on a phone call. A small chunk of audio disappears. With UDP, you hear a brief crackle. With TCP, the entire conversation pauses while that chunk is retransmitted. The retransmitted audio would play back out of sync with the real-time conversation.

DNS queries: A DNS lookup is a single request and response. If the response is lost, the client just sends another request. Setting up a full TCP connection for a single query would be overkill (though DNS over TCP exists for large responses and zone transfers).

Head-to-Head Comparison

What Uses TCP? What Uses UDP?

TCP Applications:

• HTTP/HTTPS (web browsing, until HTTP/3)
• SMTP/IMAP/POP3 (email)
• FTP/SFTP (file transfer)
• SSH (secure remote access)
• Database connections (MySQL, PostgreSQL)
• SMB/CIFS (file sharing)

UDP Applications:

• DNS (port 53)
• DHCP (port 67/68)
• NTP (time synchronization)
• SNMP (network monitoring)
• Online games (custom ports)
• VoIP/SIP (voice calls)
• Video streaming (RTP)
• VPN tunnels (WireGuard, OpenVPN’s UDP mode)
• QUIC/HTTP/3 (web browsing, the new way)

QUIC: The Best of Both Worlds

The biggest development in transport protocols in recent years is QUIC (originally Quick UDP Internet Connections). Developed by Google and now standardized as the transport for HTTP/3, QUIC runs on top of UDP but builds its own reliability, ordering, and encryption on top.

Why not just improve TCP? Because TCP is implemented in operating system kernels, and getting changes deployed across every OS version worldwide takes decades. QUIC runs in userspace (application level), so Google can update it anytime. Also, TCP’s head-of-line blocking problem is fundamental to its design and can’t be fixed without breaking backward compatibility.

QUIC solves this with multiplexed streams. If one stream loses a packet, only that stream is affected. Other streams continue independently. This is a massive improvement for loading web pages, which involve dozens of simultaneous resource requests.

As of 2026, roughly 30% of web traffic uses QUIC/HTTP/3. Google services, YouTube, Facebook, Instagram, and many CDNs support it. Adoption is accelerating as web servers (Nginx, Apache, LiteSpeed) add native support.

Making the Choice (For Developers)

If you’re building something and need to choose:

Use TCP when:

• Data must arrive complete and correct (financial transactions, file transfers)
• Order matters (database queries, API calls)
• You don’t want to implement your own reliability

Use UDP when:

• Speed matters more than completeness (real-time data)
• Stale data is useless (live telemetry, game state)
• You want to implement custom reliability (only retransmit what actually matters)
• You’re building a multiplexed protocol (like QUIC)

Most applications that use UDP for performance still implement some form of lightweight reliability for critical data. Game engines, for example, use “unreliable” messages for position updates but “reliable” messages for chat and score updates, all over the same UDP socket.

Test It Yourself

Frequently Asked Questions