UDP — header, use cases, checksum
What UDP actually is
- Connectionless → no handshake; first packet carries data immediately.
- Unreliable → no ACKs, no retransmission. Lost = gone.
- Message-oriented (datagram) → one
send()= one datagram = onerecv(). (TCP is a byte-stream; UDP preserves message boundaries.)
The UDP Header — derived from "what's the minimum you need?"
HOW do we figure out the header? Don't memorize it — reconstruct it by asking "what must Transport add to IP?"
- IP delivers to a machine, but a machine runs many programs. We need to identify which program → source port + destination port (16 bits each, so up to 65535).
- The receiver must know where the datagram ends → a length field.
- We'd like some error detection (IP only checksums its own header, not the data) → a checksum.
That's it. Four fields, each 16 bits = 8 bytes total.
Compare: UDP header = 8 bytes, TCP header = 20 bytes (minimum). That 12-byte saving + no handshake is the whole point.
The UDP Checksum — derived from scratch
HOW it's built (1's complement sum over 16-bit words):
- Treat the data as a sequence of 16-bit integers.
- Add them. Whenever the sum overflows 16 bits, wrap the carry around and add it back to the low 16 bits (this is one's-complement addition).
- Take the one's complement (flip every bit) of the final sum → that's the checksum you transmit.
WHY one's complement + carry-wrap?
- Carry-wrap keeps the result inside 16 bits without losing information (the overflow carry isn't discarded, it's recycled).
- Sending the complement means the receiver can just add everything including the checksum and expect all-ones (): because .
Use cases — WHY pick "unreliable"?
| Use case | Why UDP wins |
|---|---|
| DNS query | One small request, one small reply. TCP handshake (3 packets) would cost more than the lookup. |
| Video/voice (VoIP, streaming, games) | A retransmitted old frame arrives too late to be useful — drop it, keep going. |
| DHCP, ARP-like bootstrapping | Client has no IP/connection yet; broadcast a datagram. |
| SNMP, NTP | Tiny, frequent, loss-tolerant management/time packets. |
| QUIC / HTTP/3 | Builds custom reliability + encryption in userspace on top of UDP to dodge TCP's rigidity. |
Common mistakes (steel-manned)
Recall Feynman: explain to a 12-year-old
Imagine sending a friend a quick note by sliding it under their door. You don't knock, you don't wait for a "got it!" — you just push it under and leave. If a gust of wind blows it away, you'll never know. That's UDP: super fast, no waiting, but no promise it arrives. To at least catch a torn note, you scribble a tiny number at the bottom equal to the sum of all the words' letter-counts (the checksum); your friend re-adds and if the number's wrong, they know the note got smudged and just throw it out. Great for sending "the game ball is at position X" 60 times a second — if one note is lost, the next one fixes it anyway.
Flashcards
How many bytes is the UDP header and how many fields?
What does the UDP Length field count?
Why is UDP called "unreliable" if it has a checksum?
How is the UDP checksum computed?
What should the receiver get when summing all words plus the checksum?
Why is the carry wrapped around in one's-complement addition?
What does a checksum field of 0x0000 mean in UDP (IPv4)?
What is the pseudo-header and why include it in the checksum?
TCP vs UDP: stream or message?
Give three classic UDP use cases and the reason.
Why does HTTP/3 (QUIC) run over UDP?
Can a correct checksum still pass corrupted data?
TCP header min size vs UDP header size?
Connections
- TCP — header, three-way handshake, reliability (the reliable counterpart)
- IP — datagrams and addressing (UDP is a thin layer on top)
- DNS resolution (primary UDP user)
- QUIC and HTTP-3 (reliability rebuilt over UDP)
- One's complement arithmetic (the checksum math)
- Transport layer — ports and multiplexing (why port fields exist)
Concept Map
Hinglish (regional understanding)
Intuition Hinglish mein samjho
Dekho, UDP ko samajhne ka sabse easy tareeka: TCP ek registered courier hai jo delivery confirm karta hai, lost packet dobara bhejta hai, order maintain karta hai. UDP us se ulta — ek postcard letterbox mein daal ke chal diye. Na handshake, na "mila kya?" ka jawab, na retry. Bas fast aur halka. Isliye iska header sirf 8 bytes ka hai: Source Port, Destination Port, Length, aur Checksum — sirf 4 fields. Compare karo TCP ke 20-byte header se, samajh aa jayega ki UDP "minimum-overhead" pe chalta hai.
Ab "unreliable" ka matlab galat mat samajhna. Unreliable ka matlab recovery nahi — yaani lost packet wapas nahi aayega. Lekin error detect zaroor hota hai checksum se. Checksum kaise banta hai? Saare 16-bit words ko jodo, jab 16 bits se overflow ho to carry ko wapas neeche add karo (one's complement addition), phir poore sum ka complement (ulta) le lo — wahi checksum transmit hota hai. Receiver sab kuch jod ke dekhta hai, agar 0xFFFF (saare ones) aaya to data theek, warna datagram chup-chaap discard. App ko khabar bhi nahi lagti.
Use cases yaad rakhne ke liye soch: jahan time zaroori hai, completeness se zyada. DNS query — chhoti si request, chhota reply, handshake ki zaroorat hi nahi. Video call, online game, VoIP — purana frame late aaye to bekaar, isliye drop karo aur aage badho. DHCP, NTP, SNMP — chhote control packets. Aur modern HTTP/3 (QUIC) bhi UDP ke upar apni reliability khud banata hai, TCP ki rigidity se bachne ke liye.
Ek important point exam ke liye: checksum mein pseudo-header bhi shaamil hota hai (source IP, dest IP, protocol 17, length). Isse galat machine pe deliver hua datagram bhi pakda jaata hai. Aur agar checksum field 0x0000 ho to matlab "checksum off" (IPv4 mein optional) — agar asli calculation se 0 aaye to 0xFFFF bhejte hain. IPv6 mein checksum compulsory hai. Bas itna pakka kar lo, UDP clear ho jayega.