Challenge 2: Explain Multiplexing's Benefit — Possible Solution
====================================================================

Under HTTP/1.1, a single connection can only have one request in
flight at a time — if a client wants several requests happening
concurrently, it either has to open multiple separate TCP connections
(each with its own setup overhead) or send requests one after another
on the same connection, where a slow response blocks everything queued
behind it on that connection (head-of-line blocking).

HTTP/2's multiplexing lets MANY requests and responses travel over a
SINGLE connection at the same time, interleaved — a slow gRPC call
doesn't block a fast one queued behind it on the same connection, and
the client doesn't need to open a pool of separate connections just to
achieve concurrency.

FOR A gRPC CLIENT MAKING MANY CONCURRENT CALLS TO THE SAME SERVICE,
this means it can fire off many RPC calls at once over ONE connection,
with no artificial serialization forced by the transport itself, and
without paying the overhead of establishing multiple separate
connections the way an HTTP/1.1-based client making many concurrent
REST calls to the same host effectively has to. This is a big part of
why gRPC is well suited to high-throughput, high-concurrency
service-to-service traffic — the transport itself was chosen
specifically to remove this bottleneck.