Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HTTP/2 technology demo

http2demo.io

Post reply on HN
Print view View original

81–90 of 100 posts

Re: HTTP/2 technology demo

#81

Post by nly »

patrickmcmanus wrote: post #65
nly wrote: post #62

Earlier quoted context omitted.

Yup, it's true there are pathological cases. Problems with HOL blocking can be reduced significantly with good caching though. 50 blocking requests aren't much of an issue if they're all going to return small "304 Not Modified" responses straight out of the web servers file cache. And don't forget you can still get HOL blocking over HTTP/2... at the end of the day the browser has to start parsing HTML before it knows…

h2 is better than that.. each request carries a priority, so the server can stop sending one resource and start sending another higher priority one if it becomes available. It can even do this interleaving based on actual data available to send not just the request queue - so things like CPU and IO time on one high-priority resource don't become blockers to using the bandwidth for a lower-pri resource that is ready t…

I serve Wordpress over SPDY 3.1 all the time. Not sure if that's close enough to HTTP/2 to be comparable, but I don't see how HTTP/2s capabilities will solve the following problem:

And that is I still need to wait 100-200ms for PHP to spit out HTML from index.php, 100ms for the client to receive it, and another 100ms for a list of prioritised requests for dependent resources to come back. How is that not a "real HOL problem"?

If you treat a request as referring to a bundle of resources rather than a single response then you can solve all that by allowing the client to send a lot more metadata about its current view of the whole package. This frees up the web server to respond with logo.png, funkystyle.css and bloated.js, or a freshness response, while we wait for PHP

The only way a user-agent can solve this under HTTP/2 is to request a bunch of related resources it knows it needed the last time, at a low priority, and hope they are either needed, or unneeded but unchanged (as to not waste bandwidth). And you know, a pipelined HTTP/1.1 client can do this just fine by prefacing its primary request with a bunch of If-Modified-Since requests.

And sure, you can build a webserver that can parse HTML out of PHP and do HTTP/2 PUSH, but again that's a waste of bandwidth if I have these resources cached.

That's why I think it's time to move away from a simple request, response and cache model and start thinking in terms of bundle synchronisation and dependencies.

Re: HTTP/2 technology demo

#82

Post by patrickmcmanus »

The test server does not actually make sure the h2 test is using h2. If you are using a client that does not have h2 support then you are just using the fallback code on the server and testing h1 against h1. An iphone is a good example :) (but it may be using spdy instead.. lots of variables)

Re: HTTP/2 technology demo

#83

Post by bsdetector »

acdha wrote: post #41
takeda wrote: post #25

Earlier 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?

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

Re: HTTP/2 technology demo

#84

Post by saurik »

Ignoring HTTP/2, I'm finding it very interesting that on my 11" MacBookAir6,1 running OS X 10.9.5, Safari 7.0.6 is much faster than Chrome 44.0.2403.155 at the HTTP/1.1 test. Safari performs the test in almost exactly 3.00 seconds, while Chrome never comes in under 3.15 and often takes as high as 3.45.

Re: HTTP/2 technology demo

#85

Post by breatheoften »

k__ wrote: post #29

12.50 -> 1.41 Chome 44, Win 7 With this, JS bundling is a thing of the past, I think.

Ignoring the technical issues with the demo that have been pointed out -- how does this actually prevent the need for a js bundle building process of some kind?

Suppose page.html depends synchronously on A.js depends synchronously on B.js depends synchronously on C.js. Somehow page.html needs to statically represent that it depends on each of A,B,C to avoid requiring a roundtrip after each new dependency is loaded. Yes the roundtrip cost is lower, but minimizing the number of roundtrips is desirable even over http2. The utility of a module bundler like webpack which walks the dependency graph of A.js and constructs a static representation of all the dependencies required by the html page seems like its somethings thats still going to be desirable to use even with http2 ...

Re: HTTP/2 technology demo

#86

Post by bsdetector »

youngtaff wrote: post #31
takeda wrote: post #25

Earlier 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!

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

Re: HTTP/2 technology demo

#87

Post by hmage »

TwistedWeasel wrote: post #66

My results show 1.3s for HTTP/1.1 and 3.0 seconds for HTTP/2 using Chrome on OS X. So, this demo wasn't very impressive for me.

That means your internet is fast enough to reduce latency problem that HTTP/2 fixes.

on mobile the difference is much bigger, like, 100s vs 5s

Re: HTTP/2 technology demo

#88

Post by acdha »

giovannibajo1 wrote: post #74
nly wrote: post #58

Earlier quoted context omitted.

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 [1] https://i.imgur.com/VJBKG36.png

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 Also the OP test gave similar order of magnitude. It looks like HTTP2 will be awesome for mobile!

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

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

Re: HTTP/2 technology demo

#89

Post by lojack »

TwistedWeasel wrote: post #66

My results show 1.3s for HTTP/1.1 and 3.0 seconds for HTTP/2 using Chrome on OS X. So, this demo wasn't very impressive for me.

Same for me. I tried numerous times and couldn't get HTTP/2 to be faster than HTTP/1.1. I had one time where it was close, but the vast majority of the time its between 2x and 4x slower than HTTP/1.1.
Post reply on HN