HTTP 1.1 Pipeline

Question

I need to implement an HTTP client in Java, and for my needs it seems that the most efficient way to do this is to implement an HTTP pipeline (according to RFC2616 ).

As an aside, I want to forward the POST. (Also, I’m not talking about multiplexing. I’m talking about pipelining, that is, a lot of requests on a single connection before receiving HTTP request responses)

I could not find a third-party library that explicitly states that it supports pipelining. But I could use, for example. Apache HTTPCore to create such a client, or, if necessary, create it yourself.

The problem is that this is a good idea. I did not find any authoritative references to the fact that HTTP pipelining is more than a theoretical model and is properly implemented by HTTP servers. In addition, by default, all browsers that support pipelining are disabled.

So, should I try to implement such a client, or will I have a lot of problems due to the implementation of the server (or proxy). Is there any link that gives recommendations on these issues?

If this is a bad idea, what would be an alternative programming model for efficiency? Split TCP connections?

Answer 1

I have implemented a HTTP pipelined client. The basic concept sounds easy, but error handling is very complicated. The performance gain is so insignificant that we abandoned the concept for a long time.

In my opinion, this does not make sense for a normal use case. It has some advantages when queries have logical connections. For example, you have a transaction with three requests, and you can send them all in batch mode. But usually you can combine them into one query if they can be pipelined.

Below are just some of the obstacles that I remember

• TCP keepalive does not guarantee a persistent connection. If you have 3 requests connected to the connection, the server drops the connection after the first response. You must repeat the following two queries.

• If you have multiple connections, the load balance is also complicated. If there is no downtime, you can either use a busy connection or create a new one.

• The timeout is also difficult. When one request expires, you need to drop everything after it, because they have to go back in order.

Answer 2

POST should not be pipelined

8.1.2.2 Conveyor processing

A client that maintains persistent connections MAY "pipelined" requests (i.e. sending multiple requests without waiting for a response). the server MUST send its responses to these requests in the same order as the requests were received.

Customers who are assuming a permanent connection and the pipeline SHOULD immediately establish a connection, be prepared to retry their connection if the first attempt at the conveyor failed. If the client makes such an attempt, it MUST NOT until it finds out the connection is permanent. Clients MUST also be prepared to resubmit their requests if the server closes all relevant responses before sending them.

Clients SHOULD NOT fulfill pipeline requests using non-idempotent methods or non-idempotent method sequences (see section 9.1.2). Otherwise, premature termination of the carriage connection may lead to undefined results. A client who wishes to send a non-idempotent request MUST wait to send this request until it receives the response status for the previous request.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html

Answer 3

pipelining is practically no different from http-servers; they usually process requests in the connection anyway - read the request, write the response, then read the next request ...

but the client is likely to improve throughput by multiplexing. sites usually have several machines with multiple processors, why do you want your applications to be limited to one line of will? today it is more associated with horizontal scalability (parallel queries). Of course, it is best to compare it.