skip to content

What four fields make up the UDP header, and why is it only 8 bytes when a TCP header is at least 20?

level: juniorimportance: must knowfreq 58%

answer

  1. four fields, sixteen bits each
  2. two ports, then length, then checksum
  3. length counts header plus data
  4. TCP pays for sequence, ACK, window, flags

basics

~20 s

A UDP header is four 16-bit fields: source port, destination port, length and checksum, 8 bytes in all. It is that small because UDP adds only port addressing and an integrity check; it carries no sequence numbers, acknowledgements, window or control flags.

solid answer

~40 s

RFC 768 defines the UDP header as four 16-bit fields: `Source Port`, `Destination Port`, `Length` and `Checksum`, 8 bytes in total. The destination port selects the receiving process; the source port tells the receiver where replies should go, and RFC 768 lets a sender set it to zero when no reply is expected, although RFC 8085 says a sender SHOULD NOT use zero. `Length` counts the header plus the data, so its minimum is 8. `Checksum` covers a pseudo-header of IP addresses, protocol and length, plus the UDP header and data. A TCP header is at least 20 bytes because it carries the state UDP leaves out: sequence and acknowledgement numbers, data offset, control flags, window and urgent pointer, and options can grow it to 60. The size gap is the feature gap.

go deeper

for a junior

Recall the four fields in order, that each is 16 bits, and that the header is 8 bytes. Know that UDP has no sequence numbers, acknowledgements or flags.

for a middle

Explain what Length counts, why the source port is optional in RFC 768 but discouraged at zero by RFC 8085, and map each extra TCP header field to the guarantee it pays for.

for a senior

Tie the header size to per-packet overhead for small request-response traffic, and explain why the checksum covering Length lets a receiver detect truncated datagrams.

for a principal

Frame the 8-byte header as a deliberate division of labour: the transport stays minimal, and every missing field becomes a design obligation for the application layered on it.

## The header on the wire The **User Datagram Protocol** is specified in **RFC 768**, a three-page document from 1980 that is still the definition in force. Every UDP datagram starts with a fixed **8-byte header**, laid out as two 32-bit rows of two 16-bit fields each. There are no options, no variable part and no flags, so a receiver always knows the data begins at byte 8. | Offset (bytes) | Field | Width | What it holds | |---|---|---|---| | 0 | `Source Port` | 16 bits | The sending process's port; optional, zero if unused | | 2 | `Destination Port` | 16 bits | The receiving process's port | | 4 | `Length` | 16 bits | Header plus data, in octets; minimum 8 | | 6 | `Checksum` | 16 bits | One's-complement checksum over pseudo-header, header and data | UDP is IP protocol number **17**, which is how the IP layer knows to hand the payload to UDP. ## What each field is for - **Destination port** is the demultiplexing key: together with the destination IP address it picks the socket that receives the datagram. - **Source port** is, in RFC 768's words, the port "to which a reply should be addressed in the absence of any other information". RFC 768 makes it optional and says to insert zero if it is not used. The later usage guidelines, **RFC 8085 §5.1**, tighten that: a sender SHOULD NOT use source port zero, because a source port that is hard to guess protects the receiver against off-path data injection. - **Length** counts **the header and the data**, not the data alone, so an empty datagram has length 8. The IP layer also carries a length, so this field partly repeats it; one thing it adds is that the checksum covers it, which lets a receiver detect a truncated or padded datagram (RFC 8085 §3.4). - **Checksum** is a 16-bit one's-complement sum computed over a **pseudo-header** (source and destination IP addresses, protocol number, UDP length), the UDP header and the data. Over IPv4 a sender may leave it at zero to mean "not computed"; over IPv6 it is mandatory. ## Why 8 bytes against TCP's 20 The fixed TCP header is **20 bytes**, and the 4-bit `Data Offset` field lets options extend it to 60. Each extra field exists because TCP promises something UDP does not. | Guarantee or service | TCP field that pays for it | UDP equivalent | |---|---|---| | Ordered, gap-free byte stream | 32-bit sequence number | none | | Reliable delivery | 32-bit acknowledgement number | none | | Connection setup and teardown | control flags (SYN, ACK, FIN, RST …) | none | | Receiver flow control | 16-bit window | none | | Variable-length options | data offset and options | none | | Process addressing | two 16-bit ports | two 16-bit ports | | Integrity check | 16-bit checksum (mandatory) | 16-bit checksum | The last two rows are the only ones UDP shares. Everything above them is connection state, and UDP keeps none. That is why the UDP header is fixed-size and why a UDP sender can emit a datagram without any prior exchange with the receiver. ## What the small header does not give you Because there are no sequence numbers, acknowledgements or windows in the header, the protocol itself cannot tell a receiver that something was lost, duplicated or reordered, and cannot slow a sender down. The datagram delivery model built on that fact (message boundaries, loss handling, no congestion control) is its own subject; for the header, the point is simply that none of those mechanisms has a field to live in. The small header does matter for overhead: 1. A 40-byte request over IPv4 costs 20 bytes of IP header plus 8 of UDP, 68 bytes on the wire above the link layer. 2. The same request over TCP costs at least 20 plus 20, before counting the handshake segments needed to open the connection. 3. For small, frequent messages, the 12-byte difference per packet and the absent handshake are the reason request-response protocols have been built on UDP since RFC 768 named the name server and TFTP as its first uses. ## How interviewers probe it - They ask what `Length` counts; "just the data" is the common wrong answer. - They ask whether the source port is required; RFC 768 says optional, RFC 8085 says do not use zero. - They ask which fields TCP has that UDP lacks; a good answer lists sequence number, acknowledgement number, data offset and flags, window, and urgent pointer, and links each to a guarantee.

  • IP already carries a length, so why does the UDP header repeat it in its own Length field?
    The UDP `Length` field partly repeats the IP length, but the checksum covers it, both in the header and through the pseudo-header. RFC 8085 notes that because the checksum covers the size field, it verifies the datagram was not truncated or padded. Over IPv6 the pseudo-header uses this UDP length directly (RFC 8200 §8.1).
  • When is a UDP source port of zero allowed, and why do the current guidelines discourage it?
    RFC 768 makes the source port optional and says to insert zero when it is not used, typically when no reply is expected. RFC 8085 §5.1 says a sender SHOULD NOT use zero, because an unpredictable source port helps the receiver reject data injected by off-path attackers, and a receiver SHOULD NOT bind to port zero.
  • Why can a TCP header vary in size while a UDP header cannot?
    TCP has a 4-bit `Data Offset` field giving the header length in 32-bit words, so options such as MSS or window scale can extend it from 20 up to 60 bytes. UDP has no such field and no options, so its header is always exactly 8 bytes and the data always begins at byte 8.

saying these in an interview costs you the question

  • The UDP Length field counts only the payload bytes
  • UDP has sequence numbers but no acknowledgements
  • The UDP header is 20 bytes, the same as TCP's
  • UDP headers carry flags like TCP's SYN and FIN
  • The source port is required in every UDP datagram