SubnetLayerProtocols

UDP: What You Don't Get

Eight bytes of header, and everything else is your problem

Step 1 of 2 — understand the idea. Read this first and the packet trace will confirm what you already expect, instead of teaching you two things at once.

What you'll be able to do

Before this lesson — it builds directly on:
TCP already exists and does far more. So why would anyone choose UDP? Because TCP's guarantees are not always what you want. TCP will retransmit a lost packet, and it will hold up everything behind that packet until it arrives. For a file, that is exactly right. For live video, it is a disaster: the frame it worked so hard to recover is already too old to display, and it delayed everything after it. UDP hands the decision back to the application. Some applications genuinely want to say 'that one is gone, move on'. And there is a second reason. TCP needs a connection to a specific peer. A machine that has just joined a network and has no address yet cannot open a connection to anything — it has to shout. UDP can do that; TCP cannot.

✗ Common misunderstanding: UDP is faster than TCP.

Why that's wrong: The bytes travel over the same links at the same speed. UDP avoids the setup round trip and the wait for retransmissions; it never makes a packet arrive sooner. Without congestion control it can perform considerably worse under load.

Correct model: UDP gets out of the way. The gain is latency for short exchanges and control over pacing — not raw speed.

The packets prove it: Compare the UDP request scenario with the TCP handshake: three packets pass before TCP carries a byte, while UDP's first packet is the data. Same link, same speed.

✗ Common misunderstanding: IP delivers packets; if something is wrong it will report an error.

Why that's wrong: IP is best-effort. Packets may be dropped, duplicated or reordered, and in the common case nothing is reported to anyone.

Correct model: IP tries. Reliability, if you need it, is built on top — by TCP, or by your own application over UDP.

The packets prove it: In the UDP loss scenario a datagram is discarded and the trace that follows contains no error, no timer and no retransmission.

Watch these fields in the lab: udp.sourcePort · udp.destPort

Eight bytes. This is the entire protocol — compare it with TCP's twenty-byte minimum.

     0               1               2               3
   +-------+-------+-------+-------+-------+-------+-------+-------+
   |      source port      |    destination port   |
   +-------+-------+-------+-------+-------+-------+-------+-------+
   |         length        |        checksum       |
   +-------+-------+-------+-------+-------+-------+-------+-------+

   source port        which program sent it (where a reply goes)
   destination port   which program should receive it
   length             header + data, minimum 8
   checksum           optional over IPv4; 0 means 'not computed'

   That is all. No sequence number — so no ordering, and no way
   to detect a gap. No acknowledgement field — so no delivery
   confirmation. No window — so no flow control.

Every guarantee TCP makes has a header field backing it. UDP has none of those fields, and therefore makes none of those guarantees. Reading the header is genuinely the fastest way to understand what a protocol can and cannot do.

Watch these fields in the lab: udp.sourcePort · udp.destPort · udp.length · udp.checksum

✓ Concept check — before you open the packets

These test the idea, not the trace. You should be able to answer them from the explanation above.

Which guarantee does UDP actually make?

You are designing a sensor that reports a temperature every second. A reading older than a second is worthless. TCP or UDP?

Now that you understand the concept, observe how it appears in the packet exchange.

The lab runs a real simulated capture — pause, step, click any packet, and inspect every byte.