3 ms·
Yes. HTTP/1.1 arranged for this with pipelining 11 years ago. But there were servers that thought they supported pipelining and had corruption issues, so the c
by jws 16y ago
Yes. HTTP/1.1 arranged for this with pipelining 11 years ago.
But there were servers that thought they supported pipelining and had corruption issues, so the clients got scared and wouldn't use it. (Besides, the modems on the edge of the web were the problem, not the latency.) Then the proxy people said "Why bother? No one uses it.", and the clients continued to not implement it, or did but left it off by default with a switch to turn it on in a disused lavatory, behind the "Beware of the Leopard" sign. Meanwhile, the server people having run out of useful and useless features to add to their vast code bases actually got around to making pipelining work correctly.
Welcome to 2010.
• Most popular web servers support pipelining, probably correctly.
• <1% of browsers will try it.
• Proxies (firewall and caching) largely break it.
• If you are using scripts that can change the state of the web server, then your head might explode when you consider what happens with pipelined requests.
- TimothyFitz 16y agoPipelining is not enough even if the internet infrastructure was perfect. Why? 1. Slow requests stall the entire pipeline. 2. The initial request stalls the pipeline. 3. The pipeline is being pulled instead of pushed so your performance is still roundtrip-lag-bound if you have cascading references. For example an HTML file references a .css file which references PNG costs 3 round trips at least.
- jws 16y agoTrue, if latency dominates that much in your situation, which can happen with no congested pipes in the path. An HTML5 "manifest" with pipelining would take care of all but the initial and 2nd latency.
- pbz 16y agoI knew I couldn't have been the first to think about this...