Question

RFC 2616 section 8.1.2.2 states:

A client that supports persistent connections MAY “pipeline” its requests (i.e., send multiple requests without waiting for each response). A server MUST send its responses to those requests in the same order that the requests were received.

Serial responses are often more harm than good, since serial responses actually require the server to do more processing and negates the performance benefits gained by pipelining.

For example, if a HTTP client requests for files 1.jpg, 2.jpg, 3.jpg, 4.jpg, and 5.jpg, it doesn’t matter if 3.jpg is returned before 1.jpg, or if 4.jpg is returned before 3.jpg. The client simply want the responses as soon as they are available, in any order.

How can a HTTP client gain the benefits of pipelining, and at the same time not pay for the disadvantages of response queueing?

Answer 1

A client can’t circumvent HOL-queueing as it’s part of RFC 2616. The only benefit of pipelining (in my opinion) is in extremely specific and narrow cases. Consider:

R¹_cost = Request A processing cost.
R²_cost = Request B processing cost.
TCP_cost = Cost of negotiating new TCP connection.

Using pipelining would, therefore, be viable in specific cases where:

R¹_cost ≥ R²_cost ≤ TCP_cost

How often is a request more expensive than a previous request and less expensive than negotiating a new TCP connection? Not often. I would add that Websockets are (by far) a more interesting and appropriate solution (as far as parallel back-end processing is concerned).