UDP

UDP, the User Datagram Protocol, is a connectionless, best-effort transport. An application hands it one complete message. UDP puts that message into a single IP packet behind an 8-byte header. RFC 768 is blunt about what you get: “delivery and duplicate protection are not guaranteed”. It is just as blunt about what you do not get: “Applications requiring ordered reliable delivery of streams of data should use the Transmission Control Protocol (TCP)”. So UDP is not a reliable, ordered byte stream like TCP. It is not a faster wire either. It removes connection setup, per-flow state and in-order repair, and hands retransmission, ordering and congestion control back to the application. In CDN work UDP appears in three latency-critical places: DNS queries, QUIC and therefore HTTP/3, and low-latency live media.

How it works

UDP prefixes eight bytes to the message: source port, destination port, length, checksum. It lets IP carry the result. There is no connection to open and no per-flow state to keep. So the first datagram leaves immediately, and nothing needs tearing down. The length field covers “this user datagram including this header and the data”. That is why RFC 768 notes that “the minimum value of the length is eight”. An empty datagram is a legal datagram.

• Nothing is guaranteed. A lost datagram is simply gone unless the application resends it. Datagrams may also be reordered or duplicated on the way. UDP has no sequence number and no acknowledgement to notice any of this.
• No congestion control in the protocol. RFC 8085 is the current UDP usage guidelines (BCP 145). It describes UDP as a transport “that has no inherent congestion control mechanisms”. It also says applications using UDP on the Internet “must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic”. Section 3.1 makes it your job. If an application does not use a congestion-controlled transport, “it SHOULD control the rate at which it sends UDP datagrams to a destination host”.
• One datagram is one IP packet. “A UDP datagram is carried in a single IP packet and is hence limited to a maximum payload of 65,507 bytes for IPv4 and 65,527 bytes for IPv6” (RFC 8085, section 1). The usable size is far smaller in practice, because anything over the path MTU is split: “The transmission of large IP packets usually requires IP fragmentation. Fragmentation decreases communication reliability and efficiency and should be avoided”.
• The checksum is optional over IPv4, mandatory over IPv6. On IPv4, RFC 768 allows a sender to skip it: “An all zero transmitted checksum value means that the transmitter generated no checksum”. RFC 8200 section 8.1 reverses that for IPv6: “Unlike IPv4, the default behavior when UDP packets are originated by an IPv6 node is that the UDP checksum is not optional”, and “IPv6 receivers must discard UDP packets containing a zero checksum”. There is a narrow exception for protocols that use UDP as a tunnel encapsulation.
• The 8-byte header is fixed, but UDP is now extensible. RFC 9868 (October 2025) updates RFC 768. It “defines the meaning of the IP payload area beyond the UDP Length but within the IP Length as the surplus area used herein for UDP Options”. These are options placed after the user data but still inside the IP datagram. The RFC’s own suggested system default has the feature off. So treat UDP options as available-to-standardise rather than something already on the wire.

Why it matters for a CDN

• Resolution happens before delivery, and it rides UDP. A viewer reaches an edge hostname only after a DNS lookup. RFC 1035 explains that “datagrams are preferred for queries due to their lower overhead and better performance” (RFC 1035, section 4.2), over “UDP port 53 (decimal)”. UDP is therefore on the critical path before a single HTTP byte moves.
• HTTP/3 is QUIC carried in UDP datagrams. RFC 9000 puts QUIC packets in UDP “to better facilitate deployment in existing systems and networks”. It then rebuilds on top everything UDP lacks. QUIC “is a connection-oriented protocol that creates a stateful interaction between a client and server”. It supplies its own reliable delivery and congestion control. It also offers “an option for clients to send data immediately (0-RTT), which requires some form of prior communication or configuration to enable”. Read that qualifier carefully. 0-RTT is a resumption path for a client that has been here before. It is not what a first-time connection gets.
• Live media wants a transport that never waits. “Applications typically run RTP on top of UDP to make use of its multiplexing and checksum services”. RTP itself “does not guarantee delivery or prevent out-of-order delivery” (RFC 3550, section 1). For real-time playback, a packet retransmitted after its play-out deadline is worthless. So the transport that drops rather than stalls is the correct one.
• Edge routing has to key on something other than the 4-tuple. Because UDP has no connection, an address change is indistinguishable from a new flow. QUIC fixes that itself. “The primary function of a connection ID is to ensure that changes in addressing at lower protocol layers (UDP, IP) do not cause packets for a QUIC connection to be delivered to the wrong endpoint”. Endpoints pick connection IDs by a method “that will allow packets with that connection ID to be routed back to the endpoint” (RFC 9000, section 5.1). That identifier is the hook a CDN steers HTTP/3 datagrams with.

What CDNs do

At a CDN, UDP arrives mainly as HTTP/3. Each major provider documents its own switch for it. In every case the documented support is the client-to-edge leg. Cloudflare and Fastly say outright that HTTP/3 to the origin is not supported. QUIC is TLS-only, so the hostname needs a working certificate at the edge. Fastly, Akamai and CloudFront each state a TLS 1.3 requirement explicitly.

• Cloudflare. “HTTP/3 is available to all plans (though it does require an SSL certificate at Cloudflare’s edge network)”. In the dashboard you go to Speed > Settings > Protocol Optimization, where “For HTTP/3, switch the toggle to On”. Alternatively, PATCH the http3 setting through the API. The page states the boundary: “This setting is for connection between the user and Cloudflare. HTTP/3 connection to the origin is not yet supported” (Cloudflare).
• Fastly. Per service and version: “Use the HTTP/3 switch to configure your service to offer HTTP/3”, after cloning the active version. The domain needs TLS 1.3, because “QUIC requires that all connections be secured and uses TLS 1.3 to secure them”. Fastly is explicit about scope: “Fastly currently only supports HTTP/3 for end user connections” and “We do not support HTTP/3 between Fastly and your origin servers” (Fastly).
• Akamai. HTTP/3 is a Property Manager behavior added “to support secure HTTP/3 connections between requesting clients and the Akamai edge”: “Add the behavior and set the Enable slider to On.” Once it is in the property, “an Alternative Services (Alt-Svc) header is automatically generated for requests” and “The header presets a max-age (ma) of 93600 seconds”. You can change this value. You can also limit the rollout to named hostnames or a percentage of requests (Akamai).
• Amazon CloudFront. HTTP/3 is part of the distribution’s Supported HTTP versions setting: “Choose the HTTP versions that you want your distribution to support when viewers communicate with CloudFront”. Also, “For viewers and CloudFront to use HTTP/3, viewers must support TLSv1.3 and Server Name Indication (SNI)”. CloudFront also supports QUIC connection migration, “to allow the viewer to switch networks without losing connection” (AWS).

Watch out for

• Middlebox state, not only blocked ports. A NAT or firewall cannot watch a connection that does not exist. So it invents per-flow state on the first outbound datagram, and expires it: “Return traffic that arrives after the per-flow state has timed out is dropped, as is other traffic that arrives from the exterior” (RFC 8085, section 3.5). The same section notes that “NATs require a state timeout of 2 minutes or longer”, citing RFC 4787. But it also notes that “empirical evidence suggests that a significant fraction of currently deployed middleboxes unfortunately use shorter timeouts”. If you must hold a UDP path open, RFC 8085 says keep-alives “SHOULD NOT” be sent “more frequently than once every 15 seconds”.
• Blocked UDP, and a fallback that must actually work. HTTP/3 is discovered, never assumed. RFC 9114, section 3.1 says what a client does when the datagram path fails: “Connectivity problems (e.g., blocking UDP) can result in a failure to establish a QUIC connection; clients SHOULD attempt to use TCP-based versions of HTTP in this case”. That is a SHOULD in the client. It means your HTTP/2 path over TCP is the one that has to be healthy. The same section adds that “Servers MAY serve HTTP/3 on any UDP port”. So do not assume UDP 443 is the only hole a firewall needs.
• Spoofing, reflection and amplification. With no handshake, a source address is only a claim. So a small query can be turned into a large response aimed at a third party. RFC 7766 names “the protection it provides against address spoofing and therefore exploitation of DNS in reflection/amplification attacks” as a reason to move DNS toward TCP. QUIC bounds the same risk arithmetically: “Prior to validating the client address, servers MUST NOT send more than three times as many bytes as the number of bytes they have received” (RFC 9000, section 8.1). Anything you expose on UDP is a potential DDoS reflector until its response-to-request ratio is capped.
• The DNS size ceiling and the TCP retry. Classic DNS over UDP is small: “Messages carried by UDP are restricted to 512 bytes (not counting the IP or UDP headers). Longer messages are truncated and the TC bit is set in the header” (RFC 1035, section 4.2.1). This forces the resolver to ask again over TCP. EDNS(0) raises the ceiling. It lets the requestor advertise “the number of octets of the largest UDP payload that can be reassembled and delivered in the requestor’s network stack” (RFC 6891, section 6.2.3). But it does not retire TCP: “All general-purpose DNS implementations MUST support both UDP and TCP transport” (RFC 7766, section 5). DNSSEC is why. RFC 7766 observes that the MTU commonly found in the core of the Internet “is around 1500 bytes, and even that limit is routinely exceeded by DNSSEC-signed responses”.
• Fragmentation above, and a floor below. A datagram larger than the path MTU becomes IP fragments. Losing one fragment loses the whole message. Where path MTU discovery is not in play, RFC 8085 section 3.2 says fall back to the default effective MTU: “For IPv4, EMTU_S is the smaller of 576 bytes and the first-hop MTU” and “For IPv6, EMTU_S is 1280 bytes”. At the other end there is a hard floor for HTTP/3: “QUIC MUST NOT be used if the network path cannot support a maximum datagram size of at least 1200 bytes” (RFC 9000, section 14). So a path that cannot carry a 1200-byte UDP payload carries no HTTP/3 at all.
• Treating UDP as the fast protocol is a category error. UDP does not put bits on the wire sooner. It removes handshake round trips and per-flow state. For anything resembling a bulk transfer, that is a liability until you reimplement what you removed. RFC 8085 section 3.1.2 tells bulk-transfer applications on UDP to “implement TFRC [RFC5348], window-based TCP-like congestion control, or otherwise ensure that the application complies with the congestion control principles”.

Best practice

• Pick UDP for messages, not streams. Use it where a lost or late datagram is acceptable. Or use it where the application rebuilds what it needs. Those cases cover DNS queries, real-time media, QUIC and HTTP/3. Where you need a reliable ordered flow, use TCP or QUIC rather than hand-rolling one on raw UDP.
• Ship congestion control with the application, not later. RFC 8085 is unambiguous. A UDP application on the Internet must prevent congestion collapse and establish a degree of fairness itself. Section 3.1 gives the rate-control requirement, and section 3.1.2 gives the bulk-transfer options. An uncontrolled UDP sender damages every other flow on the path, including your own.
• Advertise HTTP/3 and verify both paths. Enable it at the edge and let clients discover it. An origin “can advertise the availability of an equivalent HTTP/3 endpoint via the Alt-Svc HTTP response header field” using the h3 ALPN token (RFC 9114, section 3.1.1). Then test from a real client that the UDP session establishes. Also test from a network that blocks UDP that the TCP fallback still serves.
• Size datagrams to the path. For your own protocol, do path MTU discovery or stay under EMTU_S. For DNS, RFC 9715 (2025) recommends that responders fit answers into the smallest of four values: the advertised EDNS(0) buffer, the interface MTU, the operator’s configured MTU, and “the RECOMMENDED maximum DNS/UDP payload size 1400”.
• Measure the datagram path, not the header. UDP reports nothing back. So instrument loss, reordering, delay and the HTTP/3-versus-HTTP/2 negotiation share at the edge. A quietly failing QUIC path does not raise an error. It just looks like a slower site.