TCP vs UDP

Two Ways to Send Data

When data travels across a network, it gets broken into packets and sent independently. The question is: how do you ensure those packets arrive correctly? Do you guarantee delivery? Do you care about order? Do you even check if the other side received anything?

Two protocols answer these questions in completely opposite ways: TCP and UDP.

Understanding the difference isn't just academic; the wrong choice can make your application slow, unreliable, or just broken. Let's dig in.

TCP: The Reliable One

TCP (Transmission Control Protocol) is the careful, methodical protocol. When TCP sends data, it guarantees:

• Delivery: every byte arrives or you're notified of an error
• Order: packets are reassembled in the correct sequence
• Error checking: checksums detect corruption
• Flow control: prevents overwhelming a slow receiver
• Congestion control: backs off when the network is saturated

TCP sounds amazing. So why use anything else? Because all that reliability comes at a cost: latency and overhead. TCP needs to establish a connection, acknowledge every segment, and handle retransmissions. That takes time.

The 3-Way Handshake

Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.

Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

algobase.dev

TCP 3-way handshake: before sending a single byte of application data, TCP must establish a connection. The client sends SYN, server replies SYN-ACK, client confirms with ACK. This takes one full round-trip (RTT). At 150ms RTT (cross-continent), that's 150ms of pure overhead before your HTTP request even leaves. This is why HTTP/1.1 connection reuse and HTTP/2 multiplexing matter so much.

1 / 10.5×1×2×3×Playground

TCP 3-way handshake establishing connection

Before TCP sends a single byte of actual data, it performs a 3-way handshake to establish a connection. Think of it like calling someone before mailing them a letter; you confirm they're there and ready to receive.

Step 1 — SYN: Client sends a SYN (synchronize) packet to the server. "Hey, I want to connect. My sequence starts at X."

Step 2 — SYN-ACK: Server responds with SYN-ACK. "Got it. I acknowledge your sequence X. My sequence starts at Y."

Step 3 — ACK: Client sends ACK. "Got it. Starting communication."

Now the connection is established and data can flow.

When the conversation is done, TCP does a 4-way teardown (FIN/ACK/FIN/ACK) to close the connection gracefully. This is why creating a new TCP connection for every request is expensive, and why connection pooling exists.

How TCP Handles Packet Loss

Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.

Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

algobase.dev

TCP data transfer with guaranteed delivery. Every segment must be acknowledged; if the ACK doesn't arrive within a timeout, TCP retransmits automatically. The application sees a clean stream of bytes with no awareness of packet drops or retransmissions. This reliability costs throughput: you can only send as fast as the slowest acknowledged segment (the TCP window).

1 / 10.5×1×2×3×Playground

TCP reliable data transfer with retransmission on packet loss

If a packet doesn't arrive, the receiver stops acknowledging. The sender notices the missing ACK after a timeout and retransmits the lost packets. This is transparent to the application; your code just sees a stream of bytes, with TCP silently handling any losses underneath.

UDP: The Fast One

Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.

Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

algobase.dev

UDP: fire-and-forget. No handshake, no ACKs, no retransmissions. The t=16ms position update is dropped, and that's fine. By t=32ms there's a fresh update that makes the old one irrelevant. Waiting to retransmit stale position data would make the game worse, not better. UDP gives applications full control over how to handle packet loss; WebRTC, DNS, and game engines all build their own lightweight reliability on top of it.

1 / 10.5×1×2×3×Playground

UDP fire-and-forget transmission without handshake or retransmissions

UDP (User Datagram Protocol) throws all that reliability out the window. It's connectionless, fire-and-forget:

• No handshake: just send and hope it arrives
• No guaranteed delivery: packets can be dropped and nobody will know
• No ordering: packets can arrive out of sequence
• No congestion control: send as fast as you want

This sounds terrible. But it's deliberately minimal, and that's the point.

UDP has much lower latency because there's no setup, no acknowledgements, no retransmissions. The application itself can decide how to handle reliability, or if it even needs it.

Comparing the Two

When to Use Each

The choice comes down to: does your application care more about correctness or speed?

Use TCP when:

• Correctness is critical: file downloads, database queries, API calls. A half-received file is useless.
• Order matters: think chat messages or a stream of events that must be processed in sequence.
• You're doing HTTP/HTTPS: HTTP/1.1 and HTTP/2 run on TCP.
• Email, SSH, FTP: any protocol where every byte must arrive exactly right.

Use UDP when:

• Speed beats correctness: video calls, live streaming, online gaming. A dropped frame in a video call is fine; you'd rather keep going than pause to retransmit.
• Low latency is essential: in gaming, a slightly stale position update is better than a delayed accurate one.
• You're building your own reliability: QUIC (which powers HTTP/3) is built on UDP but adds its own reliability mechanisms at the application layer.
• Broadcasting: UDP supports multicast, making it efficient for sending data to many receivers simultaneously (live sports streams, for example).

Real-World Examples

DNS uses UDP: when your browser looks up google.com, it sends a tiny UDP packet to a DNS server and gets a tiny response back. The whole transaction is a single request/response. TCP's handshake would add unnecessary latency for something this small. (DNS can fall back to TCP for large responses, but UDP is the default.)

HTTP/1.1 and HTTP/2 use TCP: web traffic needs reliability. You can't afford to miss part of an HTML page or a JSON response.

Video streaming uses UDP (mostly): live streaming protocols like WebRTC, RTP (Real-time Transport Protocol), and many gaming engines use UDP. Netflix's DASH and YouTube's adaptive streaming actually use TCP/HTTP because they're not strictly real-time, as they buffer ahead. But for actual real-time video calls (Zoom, Google Meet, Discord), UDP is the backbone.

WebRTC uses UDP: WebRTC, the technology powering browser-based video calls, uses UDP via SRTP (Secure Real-time Transport Protocol). Dropped packets cause brief glitches; waiting for retransmissions would cause unacceptable jitter.

HTTP/3 uses QUIC over UDP: HTTP/3, the latest version of HTTP, actually runs on top of UDP via a protocol called QUIC. QUIC reimplements reliability and multiplexing at the application layer, getting the best of both worlds: the control of TCP with the flexibility of UDP. More on this in the HTTP article.

The gaming insight: In multiplayer games, if your character position packet gets lost, retransmitting it is pointless; by the time it arrives, your position has changed again. Games send fresh position updates continuously and discard stale ones.

Summary

TCP and UDP represent a fundamental tradeoff in networking: reliability vs speed. TCP guarantees ordered, reliable delivery through its 3-way handshake, acknowledgements, and retransmission, which is ideal for HTTP, file transfers, and anything where correctness matters. UDP is connectionless and fire-and-forget, which is ideal for real-time applications like video calls, gaming, and DNS lookups where a dropped packet is acceptable but a delayed one is not. Real systems often mix both: your app might use TCP for API calls and UDP for real-time telemetry. Understanding this tradeoff is essential when designing systems with strict latency or throughput requirements.