UDP vs TCP: choosing your delivery

The other option: UDP

TCP's reliability costs time: a handshake before any data, and waiting to retransmit anything lost. UDP (User Datagram Protocol) skips all of it. You address a packet, you send it, done. No handshake, no acks, no retransmission, no ordering. If it gets lost, it is gone.

One term in the table below before you read it. An API (Application Programming Interface) is an HTTP service that programs call to read or change data, so when your weather app fetches today's forecast, it is calling the weather company's API. Same request-and-response pattern as a web page, but the answer is data instead of a page. Unit 4 returns to APIs in detail.

Why would anyone accept lost data? Because for live audio, a packet that arrives late is worse than useless. Nobody wants to hear a word from two seconds ago. Better to drop it and keep going. DNS also uses UDP, since the question and answer each fit in one packet, so a whole TCP handshake would triple the cost. If the answer is lost, the resolver just asks again.

Classifying applications by transport

The rule from the table above, applied with a case statement like the port classifier in lesson 2-2. If every byte must arrive and order matters, that is TCP. If fresh data beats complete data, or the whole exchange fits in one packet, that is UDP.

for app in webpage file-download video-call dns-lookup racing-game; do
  case $app in
    webpage|file-download) t="TCP" ;;
    video-call|dns-lookup|racing-game) t="UDP" ;;
  esac
  echo "$app -> $t"
done

Output

webpage -> TCP
file-download -> TCP
video-call -> UDP
dns-lookup -> UDP
racing-game -> UDP

Reading the branches

• Multiple patterns share one branch with a pipe, as in webpage|file-download) t="TCP" ;;, which groups cases that get the same answer.
• A missing chunk corrupts a page or a file, so both need TCP's guarantees. There is no useful partial version of an executable.
• A video call and a game want the freshest data, and a DNS lookup fits in one packet either way, so all three pick UDP for different reasons that land in the same place.
• Note that dns-lookup is the odd one out. It picks UDP for efficiency rather than freshness, and DNS does fall back to TCP when an answer is too large for a single packet.

Transport for a position stream

A racing game sending positions 30 times per second should use UDP, because a fresher position is always coming and waiting for a retransmission only adds lag.

If position update 200 is lost, resending it is pointless. Update 201 arrives 33 ms later and supersedes it, so the recovered data would be stale on arrival.

TCP would stall the stream to recover that old data, which is called head-of-line blocking. Everything behind the missing piece waits, even though it already arrived safely.

UDP drops the packet and moves on, which is exactly what fast-moving live data wants. The game draws the newest position it has and the gap is invisible at 30 updates per second.

Transport for a bank statement page

Loading a bank statement uses TCP, because every byte of the page must arrive, in order, or the page is corrupt.

Web pages ride on TCP by way of HTTP. A page with a missing chunk is broken rather than slightly degraded, so guaranteed ordered delivery is worth the handshake cost from lesson 3-2.

The contrast with the racing game is the useful part. Both care about correctness, but only one has a newer version of the same data arriving moments later.

Worth being precise about one thing: TCP does not encrypt anything. Reliability and privacy are separate concerns, and the privacy half is TLS's job in unit 7.

Skipping lost audio instead of resending it

A video call app should use UDP.

It sends each packet once with no acknowledgment and no retransmission, so a lost packet is skipped instead of stalling the stream. That is the behavior the app wants, not a limitation it tolerates.

Real-time apps add their own light recovery on top, such as concealing a missing 20 ms of audio by stretching the surrounding sound. That beats TCP's wait-and-resend for live conversation, because the listener never notices 20 ms while everyone notices a two-second stall.

The reasoning generalizes: live audio and video prefer fresh data over complete data, and any protocol that guarantees completeness has to buy it with time.