This is a purely curiosity-driven question about some subtle issue on the border between HTTP and TCP. I have no concrete problem to solve.
An HTTP request is done over a TCP connection, and a single TCP connection can be used for multiple HTTP requests in a row.
In principle, this means that the client can send a request on a connection before the response for the previous one arrived.
The interesting part is that such multiple requests can really end up being in the same IP packet, and theoretically even the multiple responses could be - de facto batching the requests.
I've come accross this topic while looking at the Techempower benchmarks which include a "plaintext" benchmark where 10 such requests are batched together in one send operation (the use the wrk tool to do this).
I'm wondering if this is a purely artificial hack or whether this actually happens, for instance when a browser requests mutliple resources from the same server.
Also, can one do this with the HTTP clients of common programming languages, or would one have to go to TCP sockets to get that behavior?
Sending multiple HTTP/1.1 requests without waiting for the response is known as HTTP pipelining (wikipedia link).
As you can read on wikipedia, the technique is promising but it is not enabled by default in browsers "due to several issues including buggy proxy servers and HOL blocking." Nevertheless there is support for it in major HTTP clients and servers.
The technique is not applicable to later versions of the protocol: HTTP/2 uses the TCP connection in a fundamentally different way, and HTTP/3 does not even use TCP.