UDP & Connectionless
dig example.com answers in a single round trip: one packet out, one packet back, and the server holds nothing after it replies. The same fetch over a fresh TCP connection must set the link up before the request can leave.
- ▸One
digquery costs two packets and one round trip; the same TCP fetch pays for setup you never see. - ▸Drop a packet and TCP resends while your read stalls; UDP just loses it and tells no one.
- ▸A UDP server answers a million clients from one socket; a TCP server holds a row for each.
You have been reading a TCP header for three topics now: a sequence number so bytes arrive in order, an acknowledgment so nothing is lost, a window so the sender does not overrun the receiver, and a row of flags that drive the connection through its states. That is twenty bytes at minimum, often more with options. Every field is machinery for a promise.
Strip the promises away and watch what is left. No ordering guarantee, so the sequence number goes. No resend, so the acknowledgment goes. No flow control, so the window goes. No connection to open or close, so the flags go. What survives is almost nothing: two 16-bit ports, a length, and a checksum. Eight bytes, four fields, well under half of TCP's twenty-byte minimum and a quarter of the thirty-two a TCP header typically carries with options.
The two ports are the one thing worth keeping, and they do the only job this protocol adds over raw IP: hand the payload to the right program on the host. The checksum is optional under IPv4 and required under IPv6, a single guard against corruption. There is no field for anything else because there is no anything else. The header is defined by what it refuses to carry.