4 ms·

It is a real world demo though? Similar to many of the other demo's of HTTP/2 (Gopher Tile, Akamai) it's written in a way that presents HTTP/1.x in the worst l

It is a real world demo though? Similar to many of the other demo's of HTTP/2 (Gopher Tile, Akamai) it's written in a way that presents HTTP/1.x in the worst light and manages to screw things up even more. HTTP/1.1 is really latency prone so when you have a demo that uses lots of smalls requests that don't fill up the congestion window you run into a couple of problems. 1. The browser can only use a limited number of connections to a host, so once these are in use the other requests queue behind waiting to a connection to become free. 2. Even when one becomes free, we've got the request / response latency before the browser sees an images bytes 3. If the response doesn't fill the congestion window i.e. it's a small file, then there's spare capacity that's not being used i.e. packets we could have send it the round trip that didn't. 4. In this demo the server sends connection: close so forces the browser to open a new TCP connection and negotiate TLS for each of the tiles, so the congestion window won't grow either. Yes, HTTP/2 is faster, because it can send multiple requests at the same time to overcome latency, the server can fill the congestion window, and the window will grow. But are our web pages build of tiny image tiles, or a greater variety of image and resources sizes? EDIT: They've now enabled keep-alive which makes the HTTP/1.1 test much faster than it was

GGoood 11y ago
Its demo you retard. They want you to see the difference between HTTP/1.1 and HTTP/2, so it makes sense to send connection: close.
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
- 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.
bhouston 11y ago
This demo is representative of loading Clara.io scenes, lots of individual images and meshes: https://clara.io/view/b43f3215-c9ef-488f-a55f-1bf2a7d74f3f https://clara.io/view/b43f3215-c9ef-488f-a55f-1bf2a7d74f3f Yes, we could somehow package this up on the server and unpack it on the client, but I'd prefer HTTP/2 do that for us.
- Moter8 11y ago
  Took 40 seconds for it to load and the navigation to show up. Why is there no helpful message? The loading bar is really small and doesn't provide enough feedback.
patrickmcmanus 11y ago
good analysis. worth mentioning that the h2 test actually respects the congestion window.. this helps both at the sending-too-slow stage, and also at the sending-too-fast stage which can easily be shown with h1 using parallel connections for large objects. (the parallelism essentially bypasses the congestion control at startup)
james33 11y ago
It may not be representative of the average page, but there are certainly ones that id does. When you load into our HTML5 game, you download over 1,000 PNG images on your first load. HTTP/2 is pretty exciting for us in that regard since we should see a significant improvement in load times.
- lisivka 11y ago
  Why not to fit your game into single HTML file, without any external dependencies?

GGoood 11y ago

Its demo you retard. They want you to see the difference between HTTP/1.1 and HTTP/2, so it makes sense to send connection: close.

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
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.

bhouston 11y ago

This demo is representative of loading Clara.io scenes, lots of individual images and meshes: https://clara.io/view/b43f3215-c9ef-488f-a55f-1bf2a7d74f3f https://clara.io/view/b43f3215-c9ef-488f-a55f-1bf2a7d74f3f Yes, we could somehow package this up on the server and unpack it on the client, but I'd prefer HTTP/2 do that for us.

Moter8 11y ago
Took 40 seconds for it to load and the navigation to show up. Why is there no helpful message? The loading bar is really small and doesn't provide enough feedback.

patrickmcmanus 11y ago

good analysis. worth mentioning that the h2 test actually respects the congestion window.. this helps both at the sending-too-slow stage, and also at the sending-too-fast stage which can easily be shown with h1 using parallel connections for large objects. (the parallelism essentially bypasses the congestion control at startup)

james33 11y ago

It may not be representative of the average page, but there are certainly ones that id does. When you load into our HTML5 game, you download over 1,000 PNG images on your first load. HTTP/2 is pretty exciting for us in that regard since we should see a significant improvement in load times.

lisivka 11y ago
Why not to fit your game into single HTML file, without any external dependencies?