329977 - Pipelining: requests should be pipelined in a smart way (to avoid pitfalls)

Status: RESOLVED WONTFIX

(Core :: Networking: HTTP, enhancement)

Description

[A.D.F.]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050923
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050923

Right now the pipelining HTTP logic is not smart enough !
If pipelining is enabled, then these factors should be taken in account.

1) Available bandwidth should be computed;  modem clients should have different settings from ADSL or T2 clients.

2) Requests for image files (HTTP GET) that are already in cache, could be aggressively pipelined (i.e. batch of 5-7 requests, because, usually images never change);  in this case server would return lots of HTTP 304 responses (usually less than 400-600 bytes each);
same policy for HEAD requests.
NOTE: of course requests for images with parameters inside URL should be placed at the end of the batch requests or even they should not be pipelined at all because it is likely that they always expire (i.e. images for counters, etc.).

3) Requests for image files (HTTP GET) which are not in cache, should be pipelined aggressively depending on their URL and their guessed size.

URLs with parameters, i.e.: imgs.site.com/images/mycounter.gif?site=www.site.com should NOT be pipelined or at least they should be placed at the end of the batch requests.

If height and width are set inside HTML, then use them as hints to disable pipeline if estimated download lasts more then 3-4 seconds (estimated size / estimated bandwidth);  yes, everybody knows that those numbers refer to the displayed size of the image but it is better than nothing and usually they match the real size of the image;  well here we are trying to understand if an image has a size of a few KB or a few hundreds of KB.

4) Inside batch requests, don't mix requests for HTML/TEXT files, plug-ins, etc. with requests for images;  again, if the files are already in cache, then be more aggressive with the number of pipelined requests (5-8, instead of 2).

5) Consider the opportunity to add an option to close the connection everytime a really long batch has been sent or there are no more requests to send for the current page (maybe leave only one connection open and close all the others in order to be SERVER FRIENDLY).

i.e. send a batch of 7 requests and a "Connection: close" HTTP header in the last one.
(i.e.: first request is not pipelined, second till eigth request are pipelined, then connection is closed).

Reproducible: Always

Steps to Reproduce:
1. download a page with a few big images and many small images.
2. 
3.

Actual Results:  
Observe how responses for big images stop or delay the responses for small images.
Sometime, if the server is throttling output, this thing can be really annoying
(OK, web sites could use more than one URL to serve images, but this is rarely done).

Expected Results:  
Big images can last many seconds or even minutes, meanwhile small images should be downloaded and rendered fastly.

The software should be smart when pipelining requests.

Comment 1

[A.D.F.]

Other hints / tricks.

1) Take in account the total size of HTTP requests in order to not send huge batch requests, I mean, limiting the total size of batch requests to 4-8 KB might be good because  sending out 20 - 25 KB for 5-7 requests with very long URLs, etc. may be not desiderable (batch requests should always fit into server's receive buffer size - at socket level);  this behaviour could be selected by a new parameter (of course it belongs to Internet not to LANs).

2) What about using a sliding window for pipelined requests (i.e. 1 - 8) ?  Start with 1, then try 2, then 4, etc. till the computed / desiderable upper limit.

3) Talking about pipelining mis-behaviour, when sending 2 requests per batch, if the first response is fast whereas the second response last for (more than x seconds, i.e. 10), then the connection should be really closed and all the current and following connections to that server (url) should NOT be pipelined any more for some time (1-30 days) or at least till the browser is restarted (in this case we don't care if the trouble is in a trasparent proxy or in only one server behind a load balancer).

4) Another possibility to test / guess whether requests to a server can be pipelined would be to send two batched HEAD requests and to see how fast the responses are received.

5) It would be nice to show somewhere how many requests could be pipelined (i.e.  4/10) or the fact that a server is considered broken (requests could not be pipelined);  broken servers could be automatically collected and sent back to mozilla.org as a talkback report (live statistics).

Comment 2

[A.D.F.]

(In reply to comment #1)
> Other hints / tricks.
> 
> 4) Another possibility to test / guess whether requests to a server can be
> pipelined would be to send two batched HEAD requests and to see how fast the
> responses are received.

Of course the fact that a server closes an HTTP/1.1 connection after the first response, does NOT mean that it does NOT support pipelining because this behaviour is one of the tricks used to lower the number of connections when a server is overloaded.

> 5) It would be nice to show somewhere how many requests could be pipelined
> (i.e.  4/10) or the fact that a server is considered broken (requests could not
> be pipelined);  broken servers could be automatically collected and sent back
> to mozilla.org as a talkback report (live statistics).

In order to preserve privacy, no destination URL should be collected, only the association between server name and version (by HTTP header Server:) + Via: HTTP header + type of requested files (MIME type + file extension) should be made.

Comment 3

[Lawrence Foard]

I'd really like to see a way that a web server could tell the browser that it handles pipelines correctly. Pipelining is a huge performance gain, but appears to be normally turned off in firefox. When I tried turning it on (under about:config) I quickly encountered servers that failed to deal with pipelined requests, so had to turn it off again.

I believe it would be best if the server announced its support for pipelining.

For example something like:

Connection: keep-alive
Keep-Alive: pipelined

Comment 4

[A.D.F.]

(In reply to comment #3)
> I'd really like to see a way that a web server could tell the browser that it
> handles pipelines correctly. Pipelining is a huge performance gain, but appears
> to be normally turned off in firefox. When I tried turning it on (under
> about:config) I quickly encountered servers that failed to deal with pipelined
> requests, so had to turn it off again.

In which country did this happen ?  (Maybe in UK ?)

> I believe it would be best if the server announced its support for pipelining.
> 
> For example something like:
> 
> Connection: keep-alive
> Keep-Alive: pipelined

This kind of proposal has already been discussed in bug 264354.

A web server that supports HTTP/1.1 Keep alive connections, MUST support pipelined requests as well.

Note that the first RFC 2068 (obsoleted by RFC 2616) is now more than 10 years old, if you open that document and you look for "ipelin" ([Pp]ipelin[ing]), you'll find a lot of descriptions and definitions that cannot be misinterpreted.

I don't have any transparent proxy between me and web servers and in 99.99% of times I have no problem browsing web sites excepted for a few cases where some old load balancer and / or old web server may cause problems (I am using browser Mozilla SeaMonkey 1.1.7).

The problem should be only in those "transparent proxies" but some developer thinks that there is a chance that in very rare cases it could be in Mozilla software too.

Comment 5

[Lawrence Foard]

I agree the RFC is certainly very clear about the requirement that pipelining be supported.

However by having pipelining off by default the browser appears to acknowledge a defacto standard that web servers do not in general support pipelining. In this case it seems that allowing a server to state that it does indeed support pipelining is the right thing to do. Or turn it on by default and ask users to yell at sysadmins who use broken servers :)

I'll look at the other discussion as well.

Comment 6

[Kris Zyp]

I created a test case where a long-lived response (Comet-style where it stays open to receive events from the server) causes other responses to never be received:
http://persevere.sitepen.com:9080/test/pipeline-problem.html
In the test case, there should be six requests, the third one is intentionally a long-lived response. The first two requests get a response, but the 4th-6th requests never get a response, even though should get a response immediately.

This a very difficult problem because the browser has no way of knowing a priori that the response will stay open indefinitely. However, generally these long-lived Comet-style responses are initiated through XHR. I believe we should define a property on the XHR object that can be used for authors to advice the browser that the response will be long-lived and then avoid pipelining on that connection. Here is more detailed account of my proposal and the motivation for it: 
http://markmail.org/message/5uxenyybb3p26ctx

Let me know if you think this should be filed as it's own bug. I would consider this to be more serious than just an enhancement.

Comment 7

[A.D.F.]

(In reply to comment #6)
> I created a test case where a long-lived response (Comet-style where it stays
> open to receive events from the server) causes other responses to never be
> received.
> 
> This a very difficult problem because the browser has no way of knowing a
> priori that the response will stay open indefinitely. However, generally these
> long-lived Comet-style responses are initiated through XHR. I believe we should
> define a property on the XHR object that can be used for authors to advice the
> browser that the response will be long-lived and then avoid pipelining on that
> connection. Here is more detailed account of my proposal and the motivation for
> it: 
> http://markmail.org/message/5uxenyybb3p26ctx
> 
> Let me know if you think this should be filed as it's own bug. I would consider
> this to be more serious than just an enhancement.

Sorry for the delayed reply.

Well, when making a long lived request / response where the response consists of streamed HTTP message events asynchonously coming from server, you have several options to tell browser to not pipeline requests and specifically this kind of request:

1) add a "Connection: close" HTTP header to GET request, so no other request will be appended to this one;

     or

2) use a POST request that should prevent pipelining because it is not an idempotent request.

Just to be sure, you can use both tricks.

Comment 8

[Patrick McManus [:mcmanus]]

h2 is the new pipelining