HTTP/2 replaced HTTP/1.1's one-request-per-connection model with a binary, multiplexed framing layer over a single TLS connection. A player can fan out dozens of segment requests on one TCP socket, the server interleaves responses, and HPACK compresses repeated headers down to a few bytes. The reduction in connection overhead and head-of-line cost is the reason Apple specified HTTP/2 push (since rescinded) and then HTTP/2 with chunked transfer for LL-HLS.
For ABR streaming the relevant HTTP/2 features are multiplexed streams (segment N+1 starts downloading before segment N finishes, no extra TCP cost), server push (used briefly by LL-HLS, then dropped in favour of preload hints), chunked transfer of in-progress segments (the key enabler of LL-HLS) and stream priorities (newer browsers honour them, older players ignore them). HTTP/2 also dropped support for plaintext, so every streaming request runs over TLS — convenient for DRM/signed-URL flows, mildly annoying for cache debugging.
HTTP/2's flaw is shared with TCP: head-of-line blocking. If a packet is lost on the underlying TCP connection, every multiplexed stream waits for retransmission. On flaky cellular this is the worst pathology of HTTP/2, and exactly the problem HTTP/3 was designed to fix.
The book · Volume 2 of 7
Video Streaming: A Complete Guide to Video Delivery: From Network Protocols and Transport to Ingest, HLS, and MPEG-DASH
HTTP/2 lets a player fetch many segments over one connection, which is what made low-latency HLS practical at scale. Volume 2 covers HTTP/2 in detail with TCP behavior under loss, QUIC and HTTP/3, and segment delivery for HLS, DASH and CMAF. Written by Nikolay Sapunov, CEO at Fora Soft.
Is HTTP/2 helping or hurting your segment delivery?
We will test HTTP/2 against HTTP/3 on your players and CDN and show which delivers segments faster for your audience. 250+ video products shipped since 2005.
