← Glossary / Multiplexed Requests (HTTP/2)

What is Multiplexed Requests (HTTP/2)?

Multiplexed Requests (HTTP/2) is the mechanism that allows a client to send multiple concurrent HTTP requests over a single TCP connection without waiting for individual responses. For scraping pipelines, it eliminates head-of-line blocking and drastically reduces connection overhead. However, anti-bot systems heavily scrutinise HTTP/2 framing, stream priorities, and pseudo-header order. If your scraper's multiplexing signature doesn't match a real browser, you'll be blocked before the server even parses your request path.

HTTP/2ConcurrencyNetwork LayerAnti-botTCP/IP
// 02 — definitions

One connection,
many streams.

How HTTP/2 fundamentally changed network concurrency, and why it became the most critical fingerprinting vector at the edge.

Ask a DataFlirt engineer →

TL;DR

Multiplexing allows dozens of requests to flow concurrently over a single TLS tunnel. It makes scraping faster and cheaper by cutting TCP handshake latency. But because every HTTP client library implements stream IDs and settings frames differently, it's trivial for Cloudflare or Akamai to spot a Python script pretending to be Chrome.

01Definition & structure
Multiplexed Requests in HTTP/2 allow a client to send multiple concurrent HTTP requests over a single TCP connection. The protocol breaks messages down into independent frames, tags them with a Stream ID, and interleaves them on the wire. The server reassembles the frames by ID. This eliminates the need to open multiple TCP connections to fetch parallel resources, drastically reducing latency and server load.
02Solving head-of-line blocking
In HTTP/1.1, even with keep-alive enabled, requests are processed sequentially. If a large or slow request is at the front of the queue, all subsequent requests on that connection are blocked waiting for it to finish (head-of-line blocking). Multiplexing solves this at the application layer: a slow database query for Stream 1 won't stop the server from sending cached image data for Stream 3 over the exact same connection.
03The fingerprinting minefield
Because HTTP/2 is a binary protocol with extensive configuration options, it is a goldmine for bot detection. Browsers and programmatic clients implement the spec differently. The order of pseudo-headers (:method, :authority, :scheme, :path), the initial window size, and the stream priority trees are all highly specific to the client engine. A mismatch between your declared User-Agent and your HTTP/2 framing signature is an instant block on modern WAFs.
04How DataFlirt handles it
We don't rely on standard library HTTP/2 implementations. Our network stack uses a custom transport layer that dynamically shapes its HTTP/2 framing to match the exact browser profile assigned to the session. If a worker is spoofing Chrome 124, it sends Chrome 124's exact SETTINGS frame, pseudo-header order, and HPACK table updates. This allows us to leverage the speed of multiplexing without triggering protocol-level anti-bot defenses.
05Did you know?
While HTTP/2 multiplexing solves application-layer head-of-line blocking, it is still vulnerable to TCP-layer head-of-line blocking. Because all streams share one TCP connection, a single dropped packet at the network layer will halt all HTTP/2 streams until the packet is retransmitted. This is the primary problem HTTP/3 was designed to solve by moving to UDP.
// 03 — the latency math

Why multiplexing
wins at scale.

The latency advantage of HTTP/2 multiplexing over HTTP/1.1 connection pooling. DataFlirt's network layer models these constraints to optimise worker concurrency per target.

HTTP/1.1 Latency = L = N × (RTT + Tprocess) / C
N requests over C connections. Blocked by sequential processing. Legacy network model
HTTP/2 Latency = L = RTT + max(Tprocess) + Ttransfer
Requests are parallelised. RTT is paid only once per connection. HTTP/2 RFC 7540
H2 Fingerprint Entropy = H = log2(Settings × Window × Priority)
The uniqueness of your HTTP/2 framing implementation. DataFlirt anti-bot research
// 04 — what the server sees

Concurrent streams,
one TLS tunnel.

A live trace of an HTTP/2 multiplexed session. Notice how requests and responses are interleaved across different stream IDs without opening new TCP connections.

HTTP/2ALPN h2HPACK
edge.dataflirt.io — live
CAPTURED
// TLS established, ALPN negotiated h2
h2.settings: MAX_CONCURRENT_STREAMS=100, INITIAL_WINDOW_SIZE=65535

// Stream 1 (HTML Document)
stream_1.pseudo_headers: :method GET, :authority target.com, :scheme https, :path /

// Stream 3 (API JSON - sent before Stream 1 finishes)
stream_3.pseudo_headers: :method GET, :authority api.target.com, :scheme https, :path /data

// Server response interleaving
recv.stream_3: HEADERS 200 OK
recv.stream_1: HEADERS 200 OK
recv.stream_3: DATA [14.2 KB]
recv.stream_1: DATA [89.1 KB]

// Anti-bot validation at the edge
fingerprint.h2_signature: m,a,s,p|100,65535
classifier.match: Chrome 124
status: PASSED
// 05 — fingerprint leaks

Where HTTP/2
betrays your bot.

Multiplexing isn't just a performance feature; it's a highly structured protocol with dozens of implementation-specific defaults. Here is what edge firewalls look at to detect scrapers.

H2 BLOCK RATE ·  ·  ·  ·  41% of naive bots
INSPECTION ·  ·  ·  ·  ·  Pre-DOM
UPDATED ·  ·  ·  ·  ·  ·  2026-05-19
01

Pseudo-header order

Instant flag · Chrome sends :method, :authority, :scheme, :path. Go defaults differ.
02

SETTINGS frame values

High entropy · Max concurrent streams and window sizes reveal the underlying HTTP library.
03

Stream priority weighting

Medium entropy · Browsers build complex dependency trees for assets; bots usually don't.
04

WINDOW_UPDATE increments

Medium entropy · How the client manages flow control byte increments.
05

HPACK indexing state

Low entropy · Which headers the client chooses to compress vs send literally.
// 06 — our network stack

Fast is easy,

blending in is hard.

Most scraping libraries bolt HTTP/2 support on top of legacy architectures. They get the multiplexing benefits but broadcast default Go or Python settings frames. DataFlirt's network stack uses a custom transport layer that precisely mimics the HTTP/2 framing, stream concurrency limits, and HPACK table management of specific browser versions. We don't just send the right headers; we send them in the right order, over the right stream IDs.

h2_transport_config.yml

DataFlirt's HTTP/2 transport configuration matching a Chrome profile.

alpn.negotiation h2, http/1.1
settings.max_streams 100chrome-default
pseudo_header.order m,a,s,p
hpack.dynamic_table 65536 bytes
stream.priority exclusive_flag: truemimicked
fingerprint.status pass

Stay ahead of the pipeline

Data engineering
intel, weekly.

Anti-bot shifts, scraping infrastructure updates, dataset delivery patterns, and business outcomes from our pipelines. Short, technical, no fluff.

By submitting, you acknowledge our Privacy Notice.

// 07 — FAQ

Common
questions.

Common questions about HTTP/2 multiplexing, connection pooling, and why modern anti-bot systems care so much about your network layer.

Ask us directly →
What is the difference between HTTP/1.1 keep-alive and HTTP/2 multiplexing? +
HTTP/1.1 keep-alive reuses a TCP connection, but requests must be processed sequentially (head-of-line blocking). If request A takes 2 seconds, request B waits. HTTP/2 multiplexing allows requests A, B, and C to be sent simultaneously over the same connection, and their responses can arrive in any order, interleaved in frames.
Does multiplexing reduce proxy costs? +
Yes, significantly. Many proxy providers charge per connection or limit concurrent connections. By multiplexing 50 requests over a single HTTP/2 connection, you consume only one connection slot on the proxy gateway, reducing overhead and avoiding connection-limit throttling.
Why do I get 403s when I enable HTTP/2 in my scraper? +
Because your HTTP/2 fingerprint doesn't match your User-Agent. If you claim to be Chrome 124 but your HTTP/2 client sends pseudo-headers in the order used by Python's httpx or Go's net/http, Cloudflare will flag the mismatch and block you instantly.
Can I multiplex requests across different domains? +
Only if the domains resolve to the same IP address and share a wildcard or multi-domain TLS certificate (connection coalescing). Otherwise, HTTP/2 multiplexing is strictly limited to requests going to the same origin host.
How does DataFlirt handle HTTP/2 stream limits? +
Servers dictate the maximum concurrent streams via the SETTINGS_MAX_CONCURRENT_STREAMS frame (often 100). DataFlirt's network scheduler tracks this limit per connection. If a pipeline needs 300 concurrent requests to an origin, we automatically open 3 separate HTTP/2 connections and distribute the streams to stay compliant.
Is HTTP/3 (QUIC) replacing HTTP/2 for scraping? +
Eventually, yes. HTTP/3 moves multiplexing from TCP to UDP, eliminating TCP-level head-of-line blocking caused by packet loss. However, HTTP/3 fingerprinting is even more complex, and many enterprise targets still rely heavily on HTTP/2. We support both, dynamically negotiating based on the target's ALPN response.
$ dataflirt scope --new-project --target=multiplexed-requests-(http/2) READY

Tell us what
to extract.
We do the rest.

20-minute scoping call. Pilot dataset within the week. Production within two. Whether you need a one-off catalogue dump or a continuous feed across millions of records — we scope, build, and operate the pipeline.

Start a pipeline → View pricing
hello@dataflirt.com  ·  Bengaluru  ·  IST  ·  typical reply < 4h
// 08 — keep reading

Related glossary terms

Network Layer

HTTP Pipelining

The flawed HTTP/1.1 predecessor to multiplexing that suffered from head-of-line blocking.

Read →
Network Layer

Connection Pooling

How scrapers manage multiple TCP connections when multiplexing isn't available.

Read →
Scraping Performance

Keep-Alive Efficiency

Measuring the performance gains of reusing connections across multiple scrape jobs.

Read →
Network Layer

TLS Fingerprinting

The layer just below HTTP/2 that anti-bot systems inspect before ALPN negotiation.

Read →