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

Better HTTP/2 Prioritization for a Faster Web

blog.cloudflare.com

Post reply on HN
Print view View original

41–50 of 52 posts

Re: Better HTTP/2 Prioritization for a Faster Web

#41

Post by jacques_chester »

patrickmeenan wrote: post #7
voiper1 wrote: post #4

So their main improvement over Chrome is that chrome doesn't benefit from progressive images -- they load images in sequence instead of parallel. Sounds like a simple fix. (If you actually know the images are progressive.)

Yep, hopefully a lot of the default improvements will make their way into all of the browsers. Until then, this also evens the field across all of the browsers but for me the really exciting part is exposing it to Workers so sites can customize the logic specific to their needs. Boosting the priority of hero images or async scripts that are important for the site but the browser's default logic has no way to know. Pr…

From my understanding the better policy will be to prioritise the smallest assets first. To me it seems counter-intuitive but apparently it proves out in theory and testing: https://www.cs.cmu.edu/~harchol/Papers/usits1.pdf

More dramatic improvement might be possible if streams can be interrupted and resumed (which is something protocols like RSocket support): https://www.cs.cmu.edu/~harchol/Papers/MIT-LCS-TR-767.pdf

Apologies if you're already familiar with these.

Re: Better HTTP/2 Prioritization for a Faster Web

#42

Post by tlrobinson »

merb wrote: post #32
pornel wrote: post #8

The big take-away from this is that "HTTP/2" is not the same thing everywhere. Quality of implementation matters. We didn't see so much variation in HTTP/1, because servers had almost no control, and clients were opening multiple connections, so even bad prioritization was hidden by TCP-level parallelism. In HTTP/2 we've reached a good level of interoperability, but bolting on HTTP/2 on top of a server architected fo…

well h2 for development is really hard since basically you need to create a certificate, because no major browser implements h2 over plaintext. i mean a lot of people can live with that and just insert a development certificate into their trust chain, but some people do not understand that and others work in more restricted environments. so basically fully controlling and developing with h2 is basically not as easy a…

Has anyone just published a valid certificate for a domain name that resolves to 127.0.0.1?

Re: Better HTTP/2 Prioritization for a Faster Web

#43

Post by skybrian »

3xblah wrote: post #17

"Web pages are made up of dozens (sometimes hundreds) of separate resources that are loaded and assembled by the browser into the final displayed content." Could that be the reason that that the web needs to be "faster" (despite tremendous advances in CPU, storage, bandwidth and network speeds)? The dozens (sometimes hundreds) of separate resources are loaded by default . What is their purpose? Where do they come fro…

It used to be that websites would optimize their icons by putting them all in a single gif. But this isn't supposed to be necessary anymore.

Re: Better HTTP/2 Prioritization for a Faster Web

#44

Post by Ayesh »

tlrobinson wrote: post #42
merb wrote: post #32

Earlier quoted context omitted.

well h2 for development is really hard since basically you need to create a certificate, because no major browser implements h2 over plaintext. i mean a lot of people can live with that and just insert a development certificate into their trust chain, but some people do not understand that and others work in more restricted environments. so basically fully controlling and developing with h2 is basically not as easy a…

Has anyone just published a valid certificate for a domain name that resolves to 127.0.0.1?

For your own use, you can obtain a certificate via DNS validation, or by pointing your DNS A records to a server with a public IP.

When you publish the private key online, anyone can revoke the certificate, or the CA themselves will.

Re: Better HTTP/2 Prioritization for a Faster Web

#45

Post by matsur »

TomGullen wrote: post #39

Would love to enable HTTP2 on Cloudflare on our site, but there seems to be a bug with it in Cloudflare where it randomly stops requests, and we're stuck in an endless support loop so we have to disable it on our PWA which would have huge benefits for it.

Can you get in touch? rustam@cloudflare.com. I’d love to get to the bottom of this.

Re: Better HTTP/2 Prioritization for a Faster Web

#46

Post by Matthias247 »

As someone who has implemented HTTP/2 too (for the apparently unpopular .NET ecosystem) I am guilty of totally missing out on the prioritization feature too.

There's definitely some good ideas and use-cases in the article that make it more worthwhile!

Some things I'm wondering about:

The proposed strategy seems to prefer sometimes sending single resources in a sequential fashion instead of lots of resources in parallel. Doesn't that essentially bring the communication back into a HTTP/1.1 style with less parallelism - and only with the benefit of no extra connections? And how well does the approach fit together with browsers flow control windows? If a browser set a small flow control window per stream then sending only a single object at a time wound still require lots of round-trips for flow control window updates - which might make it worse than HTTP/1.1. However I heard at some time that browsers have configured huge flow control windows. If that's true it seems more likely to work out (and the default strategy where HTTP/2 prefers parallelism over throughput seems worse).

Re: Better HTTP/2 Prioritization for a Faster Web

#47

Post by CJefferson »

tempguy9999 wrote: post #36
CJefferson wrote: post #35

Earlier quoted context omitted.

I didn't downvote you, but your post did annoy me. This is an interesting article about HTTP/2. Yes, we know people should make smaller web pages with less javascript and ads, and we could all install a bunch of plugins to achieve that, but multiple replies like yours do seem to appear on every single post that has anything to do with network traffic, and don't really contribute (in my opinion) to the discussion at h…

> I didn't downvote you, but your post did annoy me. This is an interesting article about HTTP/2. Thanks, that's a nice, constructive criticism and I appreciate it. My post was in retrospect not exactly a piece of precision, so let me try again if I may... I recently worked on a "big data" project that wasn't. It was a car crash because the "big data" conponents were thrown together with a very expensive cluster (>£1…

The protocol is solving a real world problem. They are trying to apply a technological solution to a real world problem.

Many problems could be solved if we could just make every Web developer and company in the whole world take size / data security / accessibility more seriously, but human history suggests that ain't happening, without in practice introducing laws.

Re: Better HTTP/2 Prioritization for a Faster Web

#48

Post by lucaspardue »

jacques_chester wrote: post #41
patrickmeenan wrote: post #7

Earlier quoted context omitted.

Yep, hopefully a lot of the default improvements will make their way into all of the browsers. Until then, this also evens the field across all of the browsers but for me the really exciting part is exposing it to Workers so sites can customize the logic specific to their needs. Boosting the priority of hero images or async scripts that are important for the site but the browser's default logic has no way to know. Pr…

From my understanding the better policy will be to prioritise the smallest assets first. To me it seems counter-intuitive but apparently it proves out in theory and testing: https://www.cs.cmu.edu/~harchol/Papers/usits1.pdf More dramatic improvement might be possible if streams can be interrupted and resumed (which is something protocols like RSocket support): https://www.cs.cmu.edu/~harchol/Papers/MIT-LCS-TR-767.pdf…

These papers are interesting, thanks for sharing.

However, the primary axiom is of a web server that is serving static content that is located on the device. That, in a sense, gives almost infinite time and knowledge to deciding prioritisation of work.

For HTTP proxies that have to fetch resources from some other server, the time and knowledge window becomes much shorter. Decision making needs to be done quickly in order to minimise the latency of returning anything. And the upstream server may response in unexpected ways.

This is the challenge for today's CDN deployments. And developing a solution that works for the huge variety of how websites are developed is the really interesting bit.

Re: Better HTTP/2 Prioritization for a Faster Web

#49

Post by stereo »

merb wrote: post #32
pornel wrote: post #8

The big take-away from this is that "HTTP/2" is not the same thing everywhere. Quality of implementation matters. We didn't see so much variation in HTTP/1, because servers had almost no control, and clients were opening multiple connections, so even bad prioritization was hidden by TCP-level parallelism. In HTTP/2 we've reached a good level of interoperability, but bolting on HTTP/2 on top of a server architected fo…

well h2 for development is really hard since basically you need to create a certificate, because no major browser implements h2 over plaintext. i mean a lot of people can live with that and just insert a development certificate into their trust chain, but some people do not understand that and others work in more restricted environments. so basically fully controlling and developing with h2 is basically not as easy a…

Getting a valdid certificate with letsencrypt is, once you’re a tiny bit familiar with certbot, a matter of minutes.

Re: Better HTTP/2 Prioritization for a Faster Web

#50

Post by zamadatix »

pornel wrote: post #38
merb wrote: post #32

Earlier quoted context omitted.

well h2 for development is really hard since basically you need to create a certificate, because no major browser implements h2 over plaintext. i mean a lot of people can live with that and just insert a development certificate into their trust chain, but some people do not understand that and others work in more restricted environments. so basically fully controlling and developing with h2 is basically not as easy a…

For server development the hard part is simulating realistic network conditions. For example, on localhost, you'll never witness any prioritization happening, because you'll never grow a queue of responses still waiting to be sent down.

Browser Dev tools pretty much cover that in one click these days.
Post reply on HN