I believe that yes, once one of the previous requests completes (either by a fault or result) the next outstanding request can proceed. Note that you can make use of multiple CNAMEs to increase the number of requests made concurrently per host (e.g. Google Maps uses mt0.google.com through mt3.google.com to get 8 concurrent connections to load map data). Persistent / "reusable" / "keep alive" connections are the default behavior for HTTP 1.1 your connections are being re-used for multiple requests already. The period for a persistent connection however is typically much smaller than, say, the life of a J2EE session. Keep alive is merely a hack to optimize the situation when multiple requests are made to the same host in a short period of time. If you had a UI that was comprised of 25 individual assets then you wouldn't want to re-establish 25 connections and perform the usual HTTP handshake for each request (and it would be even worse for HTTPS based connections). HTTP that makes use of "keep alive" should still be considered a stateless situation. A completely different approach for "persistent connections" is the style used by COMET servers and chunked encoding. Here the client immediately establishes a connection to the server on receiving data and the server holds on to the connection until new data is available to push back to the client. This does, however, impact on the number of simultaneous connections that a server can handle because it ties up threads on the server.
