src port2 B50000dst port2 B4000length2 B32checksum2 B0xa208game data24 BUDP header · 8 bytes#2 dropped→ port 4000use #4 · skip #3TCP: wait for #2DNS · port 53calls · gamesQUIC · port 443#1#2#3#4#5
Envelopes: one datagram each, numbered by the gameBlue ruler: the 8-byte UDP header in front of the dataInbox slots: the order datagrams arrived inRed: a datagram the router droppedA game on your laptop (192.0.2.7) sends position updates to a game server (203.0.113.10, port 4000). UDP adds only an 8-byte header: source port, destination port, length and checksum. There is no handshake and no waiting: #1 to #5 leave back to back. The router drops #2 and #4 overtakes #3, so the server gets #1, #4, #3, #5. UDP neither resends nor reorders; the game uses the newest update. TCP would hold #3 to #5 until #2 was resent. 192.0.2.7 and 203.0.113.10 are RFC 5737 documentation addresses. Port 50000 is in the dynamic range 49152–65535 (RFC 6335); the game's port 4000 is illustrative.

The 8-byte header

  1. The game has a 24-byte position update to send. UDP puts a header of just 8 bytes in front: four fields of 2 bytes each. Header plus data is a datagram: one message that travels on its own.

Fire and forget

Lost and out of order

The app decides

The datagrams, field by field

;; step 1/10 · wrap · local
;; at your laptop
the game's data: 24 bytes
  "game update #1 x=12 y=45"
UDP adds a header of 8 bytes:
  source port       2 bytes
  destination port  2 bytes
  length            2 bytes
  checksum          2 bytes
header + data = one datagram, 32 bytes

The #1 to #5 numbers are written by the game inside its own data. The UDP header has no sequence number. Over IPv4 a checksum of 0 means "not computed" and is allowed; over IPv6 the UDP checksum is mandatory (RFC 8200).