UDP
The User Datagram Protocol (UDP) is a minimal, connectionless transport-layer protocol defined in RFC 768. Unlike TCP, it offers no handshake, no ordering, no retransmission, and no congestion control — an application simply fires datagrams and hopes they arrive. That simplicity is the point: low overhead and low latency make UDP the substrate for DNS, SNMP, NTP, VoIP, and tunneling protocols.
Header anatomy
A UDP datagram has an 8-byte header and a variable-length payload. The fields that matter in practice:
- Source port — usually an ephemeral port chosen by the sender; identifies the sending application so replies can be routed back.
- Destination port — the well-known or registered port of the receiving service.
- Source / destination address — the IP-layer endpoints (“from” and “to”).
- Data — the payload; UDP preserves datagram boundaries, so one write = one datagram.
Unlike TCP, the header contains no sequence numbers, no acknowledgment fields, and no congestion window — the protocol itself is stateless. (TTL, the time-to-live hop limit, is an IP-layer field, not a UDP field, but it is often listed alongside UDP metadata because it governs how long a packet survives on the wire.)
Security relevance
- No handshake = spoofing-friendly. Source addresses are trivial to forge, which is why UDP is the protocol of choice for reflection/amplification DDoS (DNS, NTP, CLDAP).
- Scanning is awkward. A closed UDP port usually returns ICMP port-unreachable; an open port often returns nothing, so UDP scanning is slower and less reliable than TCP scanning. See bash-port-scanning and powershell-port-scanning for TCP-oriented alternatives.
- Tunneling gap. SSH has no native UDP channel type, so UDP services through a pivot need a converter — see ssh-udp-forwarding-socat.