In this lesson, you will learn how HTTP/2 multiplexing allows multiple concurrent requests over a single connection and why this forces you to rethink your request handler logic.
The Bottleneck of HTTP/1.1
In older HTTP versions, a connection was strictly sequential: the client sent a request, waited for the response, and only then could send the next request. If you had five images to load, your browser would often open multiple parallel TCP connections to bypass this.
The HTTP/2 Breakthrough: Multiplexing
HTTP/2 introduces multiplexing, where a single TCP connection carries multiple "streams" of data simultaneously. Think of it like changing a single-lane road into a multi-lane highway. The client can send Request A and Request B at the exact same time; the server interleaves the data frames for both and sends them back over the same pipe.
Impact on Your Node.js Handlers
In a single-threaded Node.js event loop, this changes how your application behaves under load. Because your server is now juggling many streams on one socket, the state of your handlers must be strictly isolated.
If you are accustomed to attaching state to a request object or relying on global variables to track progress, you might run into trouble. Consider this:
// A dangerous approach if not careful with state
let globalCounter = 0;
server.on('stream', (stream, headers) => {
// If multiple streams update this variable,
// they will interfere with each other!
globalCounter++;
stream.respond({ 'content-type': 'text/plain' });
stream.end(`Request ID: ${globalCounter}`);
});
Because multiplexing means these streams overlap in time, globalCounter becomes a source of race conditions. Unlike HTTP/1.1 where you might have had separate connections (and thus separate memory contexts) for distinct requests, HTTP/2 multiplexing forces all concurrent operations into the same process memory space simultaneously.
To handle this, always ensure your request processing is stateless. Use the stream object or the request/response objects to store data specific to that interaction. Never share variables between concurrent streams unless you are using proper synchronization or immutable data patterns.
Key Takeaway: HTTP/2 multiplexing turns your server into a concurrent engine, requiring you to shift from connection-based thinking to stream-based, stateless handler design.