This question is really "do you understand head-of-line blocking at two different layers, and do you know which protocol fixes which." A strong answer separates the HTTP/1.1 problem (serialized requests) from the TCP problem (one lost packet stalls everything), and maps each protocol to the layer it actually fixes.
The HTTP/1.1 problem. Browsers limit ~6 TCP connections per host. Each connection processes one request at a time — a response has to finish before the next request on that connection can even be written. With 6 connections and a 100ms RTT page with 50 resources, you're looking at serialized round trips per connection: roughly 9 requests per connection. That's why sites sharded assets across domains — an arms race against the browser's connection limit.
HTTP/2's fix: one connection, many streams. HTTP/2 multiplexes requests over a single TCP connection as interleaved binary frames. A "stream" is an independent request/response; frames from different streams are interleaved on the wire and re-assembled by stream ID. A slow large resource no longer blocks a fast small one — the small response's frames can be interleaved between the big one's frames. Each stream has flow control and priority, but they share the connection. Result: one connection instead of six, no per-connection serialization.
Why that wasn't enough: TCP head-of-line blocking. Frames still ride on TCP — a byte stream with strict ordering. If packet 5 of stream A is lost, TCP holds packets 6-40 (including complete frames of streams B and C) until the retransmission arrives. One loss on a 100ms RTT link stalls every stream for ~100ms+, which is worse than HTTP/1.1's per-connection isolation. The whole page freezes on one dropped packet.
HTTP/3 moves the problem to UDP with QUIC. QUIC re-implements what TCP gives you — reliable delivery, congestion control, flow control — but with independent streams: a loss in stream A's data only retransmits that stream's frames, and streams B/C keep flowing. The packet is not a byte stream anymore; it's a numbered frame container with per-stream sequencing. Two bonuses: the handshake is merged into the transport (TLS 1.3 inside QUIC's first flight, ~1 RTT total instead of TCP+TLS's 2-3), and connections survive IP changes via connection IDs.
Tradeoffs: QUIC pays with kernel-bypass complexity (userspace stacks, more CPU per packet), middlebox fragility, and a second protocol to implement — that's why HTTP/2 stays the default over managed networks, while HTTP/3 shines on lossy mobile paths.