UDP vs TCP: Which Protocol Wins for Streaming and Delivery

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.

• Large VOD catalogs, software and game downloads: HTTP/2 over TCP is still fine; HTTP/3 is an upgrade, not a rescue.
• Live at 2–5 seconds (LL-HLS, chunked CMAF): HTTP/3 over QUIC, with TCP fallback kept alive.
• Sub-second contribution and interactive video: SRT or WebRTC over UDP. HTTP is the wrong layer.

UDP vs TCP: what actually differs once the network degrades

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.

Why 1% packet loss breaks TCP video delivery

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.

The six criteria that decide the transport

• Loss resilience. Threshold: if p95 loss on your worst delivery region exceeds 0.5%, UDP-based transport earns its complexity.
• Latency floor. Above 6 seconds glass-to-glass, TCP is a non-issue. At 2–5 seconds, handshake and head-of-line effects start to bite. Under 1 second, only UDP-based transports qualify.
• Connection setup. TCP plus TLS 1.3 costs 2 round trips; QUIC costs 1, and 0 on resumption. At 150 ms RTT that is 300 ms against 150 ms before the first byte.
• CPU per gigabit. Kernel TCP with sendfile and kernel TLS is hard to beat. Vendor-published benchmarks from 2023–2025 put userspace QUIC at roughly 1.5–2x the CPU per gigabit with UDP segmentation offload enabled, and noticeably worse without it. Treat as an estimate; measure on your own NICs.
• Traversal and fallback. Some enterprise and captive networks still block or rate-limit UDP on port 443. Public 2025 measurements put the affected share in the low single digits of connections, but it never reaches zero, so a TCP path stays mandatory.
• Cacheability. HTTP semantics cache at the edge and scale one object to a million viewers. SRT and WebRTC do not cache; they scale per-viewer through media-aware relays, and cost scales with them.

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.

Does HTTP/3 settle the UDP vs TCP argument?

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.

Recommendation matrix: workload to transport

Read this matrix as a latency ladder: each step down in latency target trades away caching efficiency and operational simplicity.

The costs UDP-based delivery quietly adds

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.

FAQ: UDP vs TCP for streaming and delivery

Is UDP faster than TCP for video streaming?

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.

Does HTTP/3 use UDP or TCP?

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.

When should I use SRT instead of HTTP/3 for live video?

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.

What happens if a network blocks UDP port 443?

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.

How do I measure the UDP vs TCP difference on my own delivery path?

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.

Run this bake-off before you commit to a transport

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.