Multiplexing sends and receives multiple request/response streams concurrently over a single connection — the core improvement of HTTP/2.
Each message is split into frames tagged with a stream ID and interleaved, so many resources can be transferred in parallel without waiting for an earlier request to finish.
HTTP/1.1 processed requests serially per connection, so browsers had to open several connections per origin to fake parallelism. HTTP/2 multiplexes streams over one connection, making that trick unnecessary, and adds header compression (HPACK), stream prioritization, and server push (now largely deprecated). Fewer connections make TLS handshakes and congestion control more efficient.
There's an important limitation: HTTP/2 multiplexing solves application-layer Head-of-Line blocking but still runs over a single TCP connection, so if one TCP packet is lost, data for all streams stalls awaiting retransmission (transport-layer HoL blocking). QUIC, built on UDP, handles each stream independently to remove even this last bottleneck — and HTTP/3 runs on top of it.