Why is pipelining disabled in modern browsers?

Question

Many, if not all modern browsers are not using pipelined HTTP requests. In theory pipelining should speed up requests by reducing the number of round trip times required to fetch a website.

According to the HTTP standard, all servers must handle pipelined requests, so the problem should not be in lack of support on the servers.

I have seen some security concerns, such as a layer 7 DoS attack if a client pushes as many pipelined requests as possible to a URL that's performance-intensive for the server, ignoring any answers that might be received.

That would be a reason to turn pipelining support off on the server (violating the standard), but I cannot find any reason to turn it off on the clients.

It is however turned on by default on Android browsers and Chrome mobile.

Why are Chrome, Firefox, IE, Opera and Safari not using pipelined HTTP requests in their desktop (and sometimes mobile) version? What is their reasoning behind turning it off?

Otolaryngology

I'm voting to close this question as off-topic because it isn't trying to solve a practical problem. It might be better suited to programmers stackexchange. – Surfboarding

possible duplicate of What are the disadvantage(s) of using HTTP pipelining? – Caravansary

I'm up voting this. I wanna know the answer! – Litmus

The rfc does not state a server must handle pipelining, just that it should not reject the query as invalid. But a server is right to only answer the first query, or just a subset of the pipeline (in the right order of course). – Revision

Answer 1

Pipelining is disabled for the following reasons:

• Firefox:

The bigger issue has frankly been head of line blocking and its impact on performance and robustness. Naïve pipelines simply make performance worse.

• Chrome:

The option to enable pipelining has been removed from Chrome, as there are known crashing bugs and known front-of-queue blocking issues. There are also a large number of servers and middleboxes that behave badly and inconsistently when pipelining is enabled. Until these are resolved, it's recommended nobody uses pipelining. Doing so currently requires a custom build of Chromium.

In general:

Buggy proxies are still common and these lead to strange and erratic behaviors that Web developers cannot foresee and diagnose easily.

Pipelining is complex to implement correctly: the size of the resource being transferred, the effective RTT that will be used, as well as the effective bandwidth, have a direct incidence on the improvement provided by the pipeline. Without knowing these, important messages may be delayed behind unimportant ones. The notion of important even evolves during page layout! HTTP pipelining therefore brings a marginal improvement in most cases only.

Pipelining is subject to the HOL problem.

HTTP/2 offers an alternative:

With HTTP/1.x, the browser has limited ability to leverage above priority data: the protocol does not support multiplexing, and there is no way to communicate request priority to the server. Instead, it must rely on the use of parallel connections, which enables limited parallelism of up to six requests per origin. As a result, requests are queued on the client until a connection is available, which adds unnecessary network latency. In theory, HTTP Pipelining tried to partially address this problem, but in practice it has failed to gain adoption.

HTTP/2 resolves these inefficiencies: request queuing and head-of-line blocking is eliminated because the browser can dispatch all requests the moment they are discovered, and the browser can communicate its stream prioritization preference via stream dependencies and weights, allowing the server to further optimize response delivery.

A proxy can be used as well:

You can try something I did to speed up Konqueror in KDE3. I was dissatisfied that Konqueror did not have HTTP pipelining, so after some searching, I installed Polipo as a local HTTP/HTTPS/FTP proxy and set Konqueror to use it (localhost on port 8123 if I remember correctly). In addition to HTTP pipelining, Polipo also provided improved caching, and since it was a proxy, I could set every browser to use it and the caching would be shared between the browsers. (This also means that it is a good idea to disable each browser's independent caching.)

Salesforce uses the following process:

Salesforce has a powerful and field-tested approach for mitigating HOLB at the TCP layer: we decouple the relation between an HTTP request and a TCP connection. Think about your transport as composed of multiple TCP connections (as many as the network context would need). Any part of the HTTP request can go over any TCP connection. So if you hit the HOLB in one connection, it not only helps in mitigating affected requests, it also minimizes impact to other application requests using healthy connections. The result is an ability to enjoy the benefits of multiplexing and pipelining at the HTTP layer while minimizing risks of HOLB.

References

• Mozilla Bug 264354 – Enable HTTP pipelining by default

• HTTP Pipelining - The Chromium Projects

• Chromium Issue 364557: Remove pipelining code from Chrome

• Understanding Connection Limits and New Proxy Connection Limits in WinInet and Internet Explorer – Http Client Protocol Issues (and other fun stuff I support)

• HTTPS and Keep-Alive Connections – IEInternals

• Changes in WinHttp on Windows 7 and onwards wrt HTTP/1.0 – HTTPContext

• Content-Length and Transfer-Encoding Validation in the IE10 Download Manager – IEInternals

• Use Sensible Long-Lived Cache headers – IEInternals

• Web Performance : 2015 : March | Akamai Community

• WebSockets, caution required!

• HTTP: HTTP/2 - High Performance Browser Networking (O'Reilly)

• HTTP Pipelining - Not So Fast...(Nor Slow!) – Guy's Pod

• Persistent Connection Behavior of Popular Browsers

• Connection management in HTTP/1.x - HTTP | MDN

• Download Resumption in Internet Explorer – IEInternals

• Networking Improvements in IE10 and Windows 8 – IEInternals

• Konqueror very slowly (KDE4) • KDE Community Forums

• HTTP Optimization: Multiple TCP Connections and Pipelining

• SpeedGuide :: Internet Explorer, Chrome, Firefox Web Browser Tweaks

• The Full Picture on HTTP/2 and HOL Blocking – Salesforce Engineering

Gulosity

Now I want to know why mobile browsers tend to leave pipelining enabled! They use the same proxies, middle boxes and should have the same HoL problem (but even worse, since it uses a higher latency connection). HTTP/2 is of course the future solution, but until then. – Otolaryngology

Is there any mobile browser that documents this distinction? I have looked but have not found any but Opera Mini which uses its own proxy, and none which documents mobile versus desktop differences with regards to pipelining or HTTP conformance. – Gulosity

Great answer! FWIW, bugzilla.mozilla.org/show_bug.cgi?id=264354#c65 briefly touches on mobile versus desktop differences. – Icaria

Wish I could figure out what this means: "Any part of the HTTP request can go over any TCP connection." No browser does that, presumably. Are they just talking about some non-standard homegrown protocol for internal communications? In which case "field tested" means tested in their own backyard which may have not much to do with anyone else's results. Confusing. – Romanticize

Answer 2

The accepted answer may be somewhat out of date. Today I've seen chrome desktop pipeline 10 requests in a single HTTPS connection against our server, which provided me with the pipeline counts.

Mickel

HTTP/2 essentially has built-in pipelining, which may be what you're seeing. #34479467 chromium.org/developers/design-documents/network-stack/… indicates "the option to enable pipelining has been removed from Chrome". – Spectrometer

Well, this is unlikely as the Server in question only implements HTTP/S 1.0 and 1.1. Also, HTTP/2 does multiplex not pipeline, so in HTTP/2 there is no logical sequence of requests AFAICT. I did not check plain HTTP; maybe that is the difference. – Mickel

I should add that I maintain said Server and I recently fixed HTTP pipelining (which is why I was observing pipeline request counts at all) because our Web Apps started showing weird failures on Chrome only. Further examination revealed that Chrome used pipelining and ours was broken. TBH I was highly surprised, but I think Chrome is using pipelining (again). It seemed that pipelining is used (only?) in rapid succession of fetch requests. – Mickel