5 ms·

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

by takeda 11y ago

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?

sajal83 11y ago
yes #4 is totally cheating. But pipeling is very different from http/2 multiplexing. pipeling the responses has to come in order they were requested.. so it could suffer from head of line blocking. http/2 is async in that regards.
youngtaff 11y ago
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!
- vardump 11y ago
  Yup, and clients also mess it up, especially when it comes to pipelining. Should also not forget about TLS session resumption. I've seen it boost server performance over 10x, TLS session negotiation is CPU bound.
  - youngtaff 11y ago
    I didn't even check if they were using session resumption, OCSP stapling etc., I thought I'd found enough shortcomings for now
- bsdetector 11y ago
  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 do this basic research before pushing their new protocol? They just said "it's 40% faster! rubber stamp this because it's in Chrome!" and some of their fans even created stacked demos where pipelining wouldn't be used (perhaps unintentionally, but still invalid comparisons).
  - youngtaff 11y ago
    Is it this paper - http://research.microsoft.com/pubs/170059/A%20comparison%20of%20SPDY%20and%20HTTP%20performance.pdf 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
    - bsdetector 11y ago
      "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.
- merb 11y ago
  mostly keep-alive could be worse when only a few requets run
noselasd 11y ago
Are there any browsers that have pipelining turned on by default ?
- takeda 11y ago
  That's a good point. Not long ago I would say Opera uses it, but they discontinued it and new Opera basically uses Blink engine from Chrome.
acdha 11y ago
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://bugzilla.mozilla.org/show_bug.cgi?id=264354 https://www.chromium.org/developers/design-documents/network-stack/http-pipelining https://www.chromium.org/developers/design-documents/network...
- bsdetector 11y ago
  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 causing the very few failures was because it was due to SuperFish or other illicit software. Some people's computers having malware isn't a good reason disable pipelining.
  - acdha 11y ago
    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-for-firefox.html 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/netwerk/protocol/http/nsHttpConnection.cpp#l666 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-switches-images/ 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://bugzilla.mozilla.org/show_bug.cgi?id=716840) https://github.com/AFNetworking/AFNetworking/issues/528 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.
nly 11y ago
Yes, and if you do the Akamai test[0], which actually uses Keep-Alive, and enable pipelining in FF, it's possible to get HTTP/1.1 to within ~20-50% [1]. [0] https://http2.akamai.com https://http2.akamai.com [1] https://i.imgur.com/VJBKG36.png https://i.imgur.com/VJBKG36.png
- giovannibajo1 11y ago
  I tried this test on mobile (iPhone 6 with iOS 9) over a flaky hotel wifi, and I got impressive results, 25s vs 3s: http://m.imgur.com/ND1wzZs http://m.imgur.com/ND1wzZs Also the OP test gave similar order of magnitude. It looks like HTTP2 will be awesome for mobile!
  - acdha 11y ago
    Yes – HTTP/2 will show the greatest impact on any connection with high latency because you avoid the classic HTTP 1 behaviour where each request must finish before the next one can be issued. If you have a low-latency connection close to the server you can easily find cases where HTTP/1 is still competitive – e.g. in this case using Akamai's demo with a 2ms ping time to their closest CDN node: https://www.dropbox.com/s/9zo844ue7ehwg58/Screenshot%202015-08-20%2015.04.30.png https://www.dropbox.com/s/9zo844ue7ehwg58/Screenshot%202015-... (That's presumably due to the HTTPS setup – even with caching disabled, that page takes ~.8 seconds on a reload) The catch, of course, is recognizing that this is not the case for most people and so even if we're personally not seeing a huge benefit on a fast computer in an office, it's still of huge benefit to anyone on a cellular network, flaky wifi, saturated ISP connection on another continent.

by takeda 11y ago

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?

sajal83 11y ago

yes #4 is totally cheating. But pipeling is very different from http/2 multiplexing. pipeling the responses has to come in order they were requested.. so it could suffer from head of line blocking. http/2 is async in that regards.

youngtaff 11y ago

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!

vardump 11y ago
Yup, and clients also mess it up, especially when it comes to pipelining. Should also not forget about TLS session resumption. I've seen it boost server performance over 10x, TLS session negotiation is CPU bound.
- youngtaff 11y ago
  I didn't even check if they were using session resumption, OCSP stapling etc., I thought I'd found enough shortcomings for now
bsdetector 11y ago
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 do this basic research before pushing their new protocol? They just said "it's 40% faster! rubber stamp this because it's in Chrome!" and some of their fans even created stacked demos where pipelining wouldn't be used (perhaps unintentionally, but still invalid comparisons).
- youngtaff 11y ago
  Is it this paper - http://research.microsoft.com/pubs/170059/A%20comparison%20of%20SPDY%20and%20HTTP%20performance.pdf 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
  - bsdetector 11y ago
    "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.
merb 11y ago
mostly keep-alive could be worse when only a few requets run

noselasd 11y ago

Are there any browsers that have pipelining turned on by default ?

takeda 11y ago
That's a good point. Not long ago I would say Opera uses it, but they discontinued it and new Opera basically uses Blink engine from Chrome.

acdha 11y ago

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://bugzilla.mozilla.org/show_bug.cgi?id=264354 https://www.chromium.org/developers/design-documents/network-stack/http-pipelining https://www.chromium.org/developers/design-documents/network...

bsdetector 11y ago
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 causing the very few failures was because it was due to SuperFish or other illicit software. Some people's computers having malware isn't a good reason disable pipelining.
- acdha 11y ago
  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-for-firefox.html 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/netwerk/protocol/http/nsHttpConnection.cpp#l666 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-switches-images/ 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://bugzilla.mozilla.org/show_bug.cgi?id=716840) https://github.com/AFNetworking/AFNetworking/issues/528 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.

nly 11y ago

Yes, and if you do the Akamai test[0], which actually uses Keep-Alive, and enable pipelining in FF, it's possible to get HTTP/1.1 to within ~20-50% [1]. [0] https://http2.akamai.com https://http2.akamai.com [1] https://i.imgur.com/VJBKG36.png https://i.imgur.com/VJBKG36.png

giovannibajo1 11y ago
I tried this test on mobile (iPhone 6 with iOS 9) over a flaky hotel wifi, and I got impressive results, 25s vs 3s: http://m.imgur.com/ND1wzZs http://m.imgur.com/ND1wzZs Also the OP test gave similar order of magnitude. It looks like HTTP2 will be awesome for mobile!
- acdha 11y ago
  Yes – HTTP/2 will show the greatest impact on any connection with high latency because you avoid the classic HTTP 1 behaviour where each request must finish before the next one can be issued. If you have a low-latency connection close to the server you can easily find cases where HTTP/1 is still competitive – e.g. in this case using Akamai's demo with a 2ms ping time to their closest CDN node: https://www.dropbox.com/s/9zo844ue7ehwg58/Screenshot%202015-08-20%2015.04.30.png https://www.dropbox.com/s/9zo844ue7ehwg58/Screenshot%202015-... (That's presumably due to the HTTPS setup – even with caching disabled, that page takes ~.8 seconds on a reload) The catch, of course, is recognizing that this is not the case for most people and so even if we're personally not seeing a huge benefit on a fast computer in an office, it's still of huge benefit to anyone on a cellular network, flaky wifi, saturated ISP connection on another continent.