TCP vs UDP: A Beginner's Guide to the Two Core Internet Protocols

TCP and UDP are the two transport-layer protocols that almost every byte on the internet rides on. TCP is the reliable one — it guarantees your bytes arrive in order, retransmits anything lost, and powers HTTPS, SSH, and email. UDP is the fast one — it fires packets and forgets about them, powering DNS, video calls, online games, and the new HTTP/3 (which builds reliability on top of UDP via QUIC). Pick the right one for your workload and the network feels invisible; pick the wrong one and your app feels broken.

This guide explains both in plain English, walks through the trade-offs, and gives you a clear decision rule.

The One-Line Difference

TCP = "deliver every byte, in order, no matter how long it takes." UDP = "fire this packet at that address; whether it arrives is your problem."

Everything else — handshakes, congestion control, ordering — flows from that single design choice.

How TCP Works

TCP is a connection-oriented protocol. Before any data flows, the two ends do a three-way handshake (SYN → SYN-ACK → ACK) to agree they want to talk. Once connected, every byte is numbered. The receiver acknowledges what it got; the sender retransmits what it did not. If the network gets congested, TCP slows down (congestion control). When the conversation ends, both sides do a graceful close.

The result: TCP looks like a reliable, ordered stream of bytes. Two challenges TCP hides for you:

• Packets arrive out of order? TCP buffers and reorders.
• Packets get lost? TCP retransmits.
• Network congested? TCP backs off so it does not make things worse.

This reliability has a cost: latency. The handshake adds a round trip before any data flows. Retransmissions can add hundreds of milliseconds. On a flaky mobile link, TCP can feel sluggish.

How UDP Works

UDP is connectionless. There is no handshake — your code says "send these bytes to that address" and the OS does. There is no acknowledgement, no retransmission, no ordering, no congestion control built in. Each packet is independent.

The result: UDP is faster and simpler, but anything beyond "best-effort delivery" is your application's problem. If you want reliability on top of UDP, you build it yourself (or use a library like QUIC).

The whole UDP header is 8 bytes vs TCP's 20+ — there is barely anything to it.

Side by Side at a Glance

When to Use TCP

Use TCP when correctness is non-negotiable:

• Web traffic (HTTPS over HTTP/1.1 or HTTP/2). You cannot lose half of an HTML page.
• APIs and databases. A missing byte in a JSON payload breaks the parse.
• File transfers. SCP, rsync, FTP — every byte must arrive.
• SSH and remote shells. A dropped keystroke would be chaos.
• Email (SMTP, IMAP). Lost message = lost message.

If your data is not a continuous real-time stream, TCP is almost always the right answer.

When to Use UDP

Use UDP when latency matters more than perfection:

• Video calls and live streams. A dropped frame is better than a 200 ms freeze waiting for retransmission.
• Online games. The next position update is more useful than the missed one.
• DNS. Tiny request, tiny reply, latency-sensitive — TCP handshake is overkill.
• VoIP (voice over IP). Same reasoning as video calls.
• HTTP/3 / QUIC. Yes — the modern web is moving back to UDP because QUIC builds smarter reliability on top of it.

A Worked Example: Why Your Video Call Drops Frames Instead of Freezing

Picture a Zoom call on a flaky Wi-Fi network. A packet carrying audio bytes 4500–4600 gets lost.

• If audio rode on TCP: Zoom would block, wait for the retransmission (50–500 ms), then play the missed audio out of order. You would hear "...the qua—" silence "...rterly numbers." A useless lag spike.
• Audio rides on UDP: Zoom skips the missing bytes, plays the next packet immediately, and you hear a tiny click. Conversation continues.

For real-time media, "skip and continue" beats "wait and recover." UDP's lack of guarantees is the feature.

QUIC and HTTP/3: The Best of Both

In 2026, HTTP/3 — running on QUIC over UDP — has become the default on most large sites. QUIC keeps UDP's no-handshake-overhead but adds:

• Reliable, ordered streams (like TCP).
• Multiplexing without head-of-line blocking (TCP's biggest weakness).
• Built-in TLS 1.3 encryption.
• Connection migration (your phone's connection survives Wi-Fi → 5G handover).

QUIC proves the TCP-vs-UDP debate is no longer either-or. UDP is the foundation; QUIC is the cathedral built on top.

py

# UDP in Python: 4 lines, no handshake
import socket
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.sendto(b"hello", ("203.0.113.10", 9000))

Common Mistakes Beginners Make

• Using UDP because "it's faster" without handling loss. Your "fast" service drops 1% of messages and silently breaks downstream.
• Using TCP for tiny request/reply. A handshake to send 50 bytes and close is wasteful — DNS got this right with UDP.
• Forgetting MTU limits. UDP packets above ~1500 bytes get fragmented (or dropped) on most networks. Keep payloads small.
• Treating TCP as "secure". TCP only guarantees delivery, not encryption. You still need TLS on top.
• Reinventing TCP poorly on UDP. If you find yourself adding acknowledgements, retransmits, and ordering — you wanted TCP (or QUIC).

Quick Reference