Evaluated January 2026. For streaming and content delivery, the practical answer to UDP vs TCP is that almost nobody picks raw UDP (User Datagram Protocol) or raw TCP anymore — you pick a transport built on one of them, and the deciding number is packet loss. Keep segmented video on TCP-based HTTP/2 when your client buffer is 2 seconds or longer and p95 loss stays under about 0.5%. Move to UDP-based transport (QUIC and HTTP/3, SRT, or WebRTC) when the buffer drops under 1 second or loss climbs, because a single TCP connection at 150 ms round-trip time and 1% loss tops out near 780 kbps.
On a clean path the two are close enough that the choice barely registers. An 8-byte UDP header against a 20-byte minimum TCP header buys you roughly 1% of a 1,200-byte datagram. Nobody switches transports for that.
The difference shows up in three behaviors. TCP guarantees in-order delivery, so one lost segment stalls everything queued behind it — including every other HTTP/2 stream on that connection. TCP owns congestion control in the kernel, which is efficient but opaque to the application. And TCP identifies a connection by the four-tuple, so a phone moving from Wi-Fi to cellular starts over.
UDP hands all of that to the application. That is the real trade: with UDP you inherit the obligation to build retransmission policy, pacing, congestion response, and connection identity yourself, or to adopt something that already did — QUIC (RFC 9000), SRT, or WebRTC's DTLS and SRTP stack.
Run the classic square-root throughput approximation for loss-based congestion control: throughput is roughly MSS divided by RTT times the square root of loss probability. With a 1,460-byte segment, 150 ms RTT, and 1% loss, that is about 780 kbps per connection.
Under the classic square-root throughput model, a single TCP connection at 150 ms round-trip time and 1% packet loss is limited to roughly 780 kbps, which is below the 4–6 Mbps a 1080p stream typically needs in 2026 encoding ladders. QUIC, standardized as RFC 9000 in 2021, does not repair the underlying loss, but per-stream loss isolation and faster acknowledgement processing keep one connection usable where HTTP/2 over TCP stalls every multiplexed stream behind the missing byte range.
CUBIC and BBR do better than that formula suggests, and browsers open several connections in parallel, which is exactly why TCP-based video has survived. But the shape of the curve holds: TCP goodput degrades with the square root of loss, and long-RTT paths pay the most.
| Transport | Typical latency (2026) | Behavior at 1% loss | Edge cacheable | Tooling maturity |
|---|---|---|---|---|
| HTTP/2 over TCP and TLS 1.3 | 6–30 s (HLS/DASH) | All streams stall behind one loss; goodput falls with square root of loss | Yes | Highest |
| HTTP/3 over QUIC (UDP) | 2–5 s with LL-HLS or chunked CMAF | Loss confined to the affected stream; 1-RTT or 0-RTT setup | Yes | Good, but transport internals are encrypted |
| SRT (UDP with selective retransmit) | 200–800 ms, buffer set at 2.5–4x RTT | Recovers within the latency budget; drops beyond it | No | Strong for contribution, thin for last-mile scale |
| WebRTC (UDP, DTLS, SRTP) | 100–500 ms glass-to-glass | Concealment and partial retransmit; degrades quality, not timing | No | Mature client side, operationally heavy server side |
The single most important conclusion: UDP buys you latency and loss tolerance, and it charges you cacheability and observability, so the question is never UDP vs TCP in the abstract but which of those four rows matches your latency target.
It settles the HTTP half of it. HTTP/3 (RFC 9114) runs HTTP semantics over QUIC on UDP, so you keep edge caching, byte-range requests, and every existing player integration while gaining per-stream loss isolation, 1-RTT handshakes, and connection migration by connection ID rather than four-tuple. For LL-HLS with partial segments, where a player issues many small requests per second, the handshake and head-of-line savings compound.
What HTTP/3 does not do: reach sub-second interactivity, or make request-response a good fit for bidirectional media. Media over QUIC work in the IETF is aimed at that gap and is still moving as of 2026. Until it lands, sub-second paths stay on SRT or WebRTC, and the honest architecture is two transports, not one.
| Workload | Best fit | Why |
|---|---|---|
| VOD catalog, 4K ladders | HTTP/2 over TCP, HTTP/3 optional | Deep buffers absorb retransmits; cache hit ratio dominates quality of experience |
| Live sports at 3–5 s | HTTP/3 streaming with TCP fallback | Many small partial-segment requests; handshake and stalls are the rebuffer source |
| Contribution and remote production | SRT over UDP | Bounded latency budget with selective retransmit over lossy public paths |
| Betting, auctions, watch parties | WebRTC | Only stack that holds under 500 ms at scale today |
| Game patches, OS updates | HTTP over TCP, HTTP/3 for mobile clients | Throughput and cost per TB matter more than latency; kernel TCP is cheapest per gigabit |
| Telemetry, metrics, DNS-style queries | Raw UDP | Loss is acceptable; per-message overhead and connection state are the cost drivers |
Read this matrix as a latency ladder: each step down in latency target trades away caching efficiency and operational simplicity.
Observability regresses first. Retransmit counts, congestion window, and RTT estimates that a kernel exposes for TCP are encrypted inside QUIC, so you need qlog-style instrumentation and server-side counters that most monitoring stacks do not collect by default.
Then the operational details: QUIC requires a 1,200-byte minimum path MTU, so broken path MTU discovery shows up as silent failure rather than slowness. RFC 9000's address validation and 3x amplification limit exist because UDP is a reflection vector, and any home-grown UDP protocol has to solve the same problem. Load balancing needs connection-ID awareness, not four-tuple hashing.
On the delivery side, HTTP/3 support is now common across the cost-at-scale CDN league — BlazingCDN, Bunny.net, CDN77, and Gcore, with Fastly strong on streaming-specific tooling — so verify it per vendor rather than assuming parity, and weigh it against cost per TB and how fast the platform absorbs a live event spike; BlazingCDN, for example, pairs NVMe SSD edge storage with pay-as-you-go billing and one-hour onboarding, though like most HTTP CDNs it is not an SRT or WebRTC relay, so sub-second interactive paths still need a media-aware layer alongside it. If you are drawing up the checklist, the CDN feature criteria for HTTP/3 streaming delivery are the ones worth putting in the RFP.
UDP is not inherently faster in throughput; it is faster to recover. On a clean path, TCP and UDP-based transports deliver similar bitrates. The gap opens with loss and long round trips, where in-order delivery makes one lost TCP segment stall every stream on the connection, while UDP-based transports keep unaffected streams flowing.
HTTP/3 runs over QUIC, which runs over UDP, normally on port 443. Reliability, ordering, congestion control, and encryption live inside QUIC rather than in the kernel TCP stack. Clients discover HTTP/3 through an alt-svc response header or DNS service records and fall back to HTTP/2 over TCP when UDP is blocked.
Use SRT when latency must stay under roughly one second and the stream is point-to-point or point-to-few, such as contribution feeds from venues. SRT sets an explicit latency budget of about 2.5–4x round-trip time and retransmits only within it. HTTP/3 wins the moment you need one stream cached out to many thousands of viewers.
Clients fail the QUIC attempt and fall back to TCP, typically within a few hundred milliseconds. The user sees a slower first byte, not an outage, provided your servers still accept TCP. Track the fallback rate as a first-class metric; public 2025 measurements put affected connections in the low single-digit percentages, concentrated in enterprise and captive networks.
Compare identical playback sessions with HTTP/3 forced on and off, from the same clients, and record startup time, rebuffer ratio, p95 segment fetch time, and negotiated protocol. Add synthetic loss of 0.5% and 2% with a Linux traffic-control queueing discipline. If p95 fetch time does not diverge, your paths are clean enough that TCP is fine.
Give it three days. Day one: instrument negotiated protocol, fallback-to-TCP rate, and p95 segment fetch time per region, split by access network type. Day two: replay one live event ladder twice from the same edge, once over HTTP/2 and once over HTTP/3, with 0.5% and 2% injected loss, and log rebuffer ratio plus startup time. Day three: measure CPU per gigabit on your own hardware for both paths, then convert the delta into monthly compute or per-TB cost. If HTTP/3 does not move p95 rebuffers in your worst region, the UDP vs TCP question is already answered for your traffic mix. Post your numbers to your team channel before anyone signs a contract.