How can I enable HTTP/2 on Apache?
HTTP/2 technology demo
91–100 of 100 posts
Re: HTTP/2 technology demo
#92Earlier quoted context omitted.
Others have pointed out why HTTP/2 is still better but if you're curious about HTTP pipelining here are the reasons why Firefox and Chrome disabled it after years of testing: https://bugzilla.mozilla.org/show_bug.cgi?id=264354 https://www.chromium.org/developers/design-documents/network...
Does nobody find it strange that neither Google nor Mozilla were able to determine what proxies and software broke with pipelining? In their controlled experiments pipelining worked fine. Pipelining worked fine in Opera, and in Mobile Safari, and Android Browser, and pretty much universally in Firefox as reported by users that enabled it. It's a fair bet that the reason these companies didn't find out what was causin…
Your theory that it was just malware is easily disproven by reading the bug reports and blog posts from the years people spent trying to make this work.
Firefox found far from universal success even after years of testing and blacklisting known-noncompliant servers:
http://bitsup.blogspot.com/2012/11/a-brief-note-on-pipelines...
(the actual blacklist at the time http://hg.mozilla.org/mozilla-central/file/1d122eaa9070/netw...)
Opera's implementation apparently relied on some non-trivial heuristics but they apparently weren't well documented and were discontinued with the transition to Blink.
Similarly, it's easy to find cases where people discovered real problems in the wild with the iOS implementation:
http://tech.vg.no/2011/12/14/safari-on-ios-5-randomly-switch...
(This also affected Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=716840)
https://github.com/AFNetworking/AFNetworking/issues/528
It's easy to understand why people decided that it wasn't worth investing so much time in this when HTTP/2 would deliver significant additional benefits and by using TLS as a starting point could provably avoid the worst tampering proxies entirely.
Re: HTTP/2 technology demo
#93Earlier quoted context omitted.
Does nobody find it strange that neither Google nor Mozilla were able to determine what proxies and software broke with pipelining? In their controlled experiments pipelining worked fine. Pipelining worked fine in Opera, and in Mobile Safari, and Android Browser, and pretty much universally in Firefox as reported by users that enabled it. It's a fair bet that the reason these companies didn't find out what was causin…
Your theory that it was just malware is easily disproven by reading the bug reports and blog posts from the years people spent trying to make this work. Firefox found far from universal success even after years of testing and blacklisting known-noncompliant servers: http://bitsup.blogspot.com/2012/11/a-brief-note-on-pipelines... (the actual blacklist at the time http://hg.mozilla.org/mozilla-central/file/1d122eaa9070…
Yes, there was one report of one problem with iOS pipelining, and circa-2000 IIS had problems. But these aren't what caused them to disable pipelining, allegedly it was the unknown software causing problems. For instance Google reported that some small percent of requests failed, but they never determined the cause for it. We know that SuperFish and other malware was out there intercepting HTTP, and unknown software was causing pipelining problems, and malware isn't known for its attention to detail.
Re: HTTP/2 technology demo
#94For me (on FF) HTTP/1.1 was faster in around 5/7 attempts. I'm on corporate network so not sure that's affecting it.
Re: HTTP/2 technology demo
#95Earlier quoted context omitted.
From memory request pipelining is disabled in most browsers as many intermediaries (proxies etc) screw it up, it's still vulnerable to head-of-line blocking even when it's enabled. You'd be surprised how many servers don't have keep-alive enabled, it's much more common than I'd like. I'm a great fan of HTTP/2 but I'd like to see realistic tests!
There has been one realistic test that I know of, done by Microsoft Research, and they found pipelining to be basically equivalent to HTTP/2. But that doesn't fit the narrative. Did Google ever test against pipelining? Did IETF? No, they didn't. Did Google ever show the effect of head-of-line blocking on page load speed, especially when spread over several independent TCP connections? No, they didn't. Why didn't they…
Is it this paper - http://research.microsoft.com/pubs/170059/A%20comparison%20o...
I think if you read back though people like Will Chan's and others blogs it becomes clear that pipelining doesn't work reliably enough outside a test lab environment plus HoL blocking is still an issue for it
Re: HTTP/2 technology demo
#96Earlier quoted context omitted.
Regarding #4 isn't this a bit cheating, who doesn't use keep-alive. Also what about request pipelining? Doesn't that basically do the sane thing what http/2 is doing?
From memory request pipelining is disabled in most browsers as many intermediaries (proxies etc) screw it up, it's still vulnerable to head-of-line blocking even when it's enabled. You'd be surprised how many servers don't have keep-alive enabled, it's much more common than I'd like. I'm a great fan of HTTP/2 but I'd like to see realistic tests!
mostly keep-alive could be worse when only a few requets run
Re: HTTP/2 technology demo
#97HTTP/2 is consistently slower for me...
Re: HTTP/2 technology demo
#98Earlier quoted context omitted.
There has been one realistic test that I know of, done by Microsoft Research, and they found pipelining to be basically equivalent to HTTP/2. But that doesn't fit the narrative. Did Google ever test against pipelining? Did IETF? No, they didn't. Did Google ever show the effect of head-of-line blocking on page load speed, especially when spread over several independent TCP connections? No, they didn't. Why didn't they…
Is it this paper - http://research.microsoft.com/pubs/170059/A%20comparison%20o... I think if you read back though people like Will Chan's and others blogs it becomes clear that pipelining doesn't work reliably enough outside a test lab environment plus HoL blocking is still an issue for it
"Doesn't work reliably enough" doesn't answer the question of why Google didn't test HTTP/2 against pipelining. None of Google's performance improvement claims compared to pipelining, and they've never demonstrated or quantified an actual real-world head of line blocking problem (ironically, other than Google Maps loading very slowly in HTTP/2 because of a priority inversion).
Will Chan is the guy that wrote "it’s unclear what these intermediaries are". Oh well, there's some bad software out there, let's just make a whole new protocol /s. Fix the bad software, or at least find out what it is. If it's malware causing the problems, you don't need to make a whole new protocol you can just get rid of the malware.
Re: HTTP/2 technology demo
#99I ran the demo several times and I got a 1 second difference. I guess there is a place where even 1 second is important.
Re: HTTP/2 technology demo
#100the other server is 2x faster even without http/2 My wget implementation does not suppot http/2 HTTP Server: $ time wget https://1153288396.rsc.cdn77.org/http2/tiles_final/tile_18.png [...] real 1.038 user 0.038 sys 0.007 pcpu 5.37 HTTP2 Server: $ time wget https://1906714720.rsc.cdn77.org/http2/tiles_final/tile_18.png [...] real 0.539 user 0.045 sys 0.009 pcpu 10.01 of course that's just latency.. but this is hardly…
Funny, for me
- HTTP/1.1 17.83s - HTTP/2 57.73s
I guess I am living in a really remote area of the Interweb.