The client sends its requests in a certain order (without waiting for responses inbetween requests).
The server receives the requests in the same order (TCP guarantees that) all at once.
The server takes the first request message, processes it, and stores the response in a queue.
The server takes the second request message, processes it, and stores the response in a queue.
The server sends the contents of that queue to the client. The responses are stored in order so the response to the first request is at the beginning of that queue followed by the response to the second request and so on...
The client receives the responses in the same order (TCP guarantees that) and associates the first response with the first request it made and so on.
By default the HTTP client does keep-alive and pooling, which *can* be better than pipelining.
The problem with pipelining is that the responses must be sequential. So, if you're talking to CouchDB and you do one big bulk read and then 7 small reads the small reads will all have to wait for the big bulk read to finish. With keep-alive and pooling you're optimizing for concurrency and you're assuming the benefits will outweigh the extra roundtrips to setup up the extra pooled connections.
It's a tough balance but in my experience it's better to do keep-alive + pooling with HTTP because the time it takes for a response to return is usually greater than the roundtrip if you're making enough requests for this to matter. However, something like Redis is much better suited to pipelining because requests are returned almost immediately and what you mainly want to do is cut down on roundtrips.
http.Server supports pipelining, but http.ClientRequest does not.
http://stackoverflow.com/questions/22039139/http-pipelining-concurrent-responses-per-connection
https://groups.google.com/forum/#!topic/nodejs/7pZFgRaVqZA
