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

HTTP/2 Is Done

mnot.net

Post reply on HN
Print view View original

81–90 of 144 posts

Re: HTTP/2 Is Done

#81

Post by velox_io »

megaman821 wrote: post #24
andrewstuart2 wrote: post #4

Earlier quoted context omitted.

Care to at least explain why you think it's a bad protocol?

It is not a bad protocol for what is in there, it is bad for what is not. It seems like it was built for the big players to eek out 5% more performance. How about the average website? What is in there help standardize authentication? What is in there to help protect privacy? In the end it looks more HTTP 1.2, with header compression being the only new feature. The rest of what makes up HTTP 2 is basically implementin…

I agree, and have no problem with a binary protocol (you always have to go down to the byte layer if you want performance networking or storage). But they could have made it much easier, just look at the spec on http://json.org (BSON isn't that bad either). I sometimes wonder if RFC's are designed to be human readable..

I think 5% is a very conservative figure. HTTP has massive overhead for lots of small file (look at the http joke), even with browser caching it still requires multiple round trips (empty TCP frames!) and compression has a negative impact on small files (overhead & bigger files)

The problem is, that to use this effectively (sending a page, plus any CHANGED assets down a single request). Requires quite a bit of work on not only the webserver, but also the application.

Another plus with reusing connections, is not having to re-authenticate every request.

Re: HTTP/2 Is Done

#82

Post by stephenr »

omeid2 wrote: post #76
stephenr wrote: post #73

Earlier quoted context omitted.

> "Applications" on the web are inherently dependant on JavaScript No, they are not.

Then we clearly have different definition of "application". For me, an web application runs in the browser, not merely exposes an API over HTTP that can be used by HTML from a browser.

You have a very narrow definition of an application then.

Re: HTTP/2 Is Done

#83

Post by marcosdumay »

tokyo1000 wrote: post #27
Chlorus wrote: post #23

Earlier quoted context omitted.

"We're seeing any sort of competition, or even just dissent, being highly discouraged, suppressed, or even prevented wherever possible." Could you please elaborate on this point?

jgrahamc's comment that I replied to is a mild example of this. If people are repeatedly raising the same concerns whenever HTTP/2 is discussed, then there are clearly issues with it that aren't being sufficiently dealt with. Writing off their problems as merely being "all the same old arguments", and discouraging discussion of them, doesn't exactly help solve these problems. Things tend to be particularly bad when i…

Count me in the naysayer group. I don't like HTTP/2.

But comparing it with systemd is completely unreasonable. When a huge group of people complained about HTTP/2, it become an optional standard, and HTTP/1.1 is officially the only web standard capable of satisfying a big number of use-cases. No choice is being taken away, it's just a bad standard that is being pushed at server maintainers.

Re: HTTP/2 Is Done

#84

Post by youngtaff »

cm2187 wrote: post #74
youngtaff wrote: post #60

Earlier quoted context omitted.

Where sites serve the base page through a CDN, then the CDN has the potential to start making intelligent decisions on what should be pushed. As the simplest level this might be just the CSS, and JS in the but obviously as different UA's behave differently there's scope for much granular optimisations.

That's the easy, but relatively rare scenario. Today most content is dynamic. Naively, it looks to me that server push will mostly be an improvement for small websites that do not use a CDN, but I can't see how it can coexist with a CDN. Or it would require a new syntax, where the html tells the browser to start connecting to the CDN with this particular URL, which contains a token, and should be downloaded first whi…

CDNs aren't limited to just static content, it's quite common for large dynamic sites to deliver their base pages though CDNs.

They can use features like ESI to assemble the final page on the edge from static and dynamic parts, or they can just act as a proxy to the origin with the dynamic page generated there.

Even when the CDN is just acting as a proxy back to the origin there can be performance advantages e.g. lower latency TCP and TLS negotiation between edge to client, and permanent connection between edge and origin i.e. single TCP negotiation for all clients, larger congestion windows leading to higher throughput.

In short CDNs aren't just for static content!

Re: HTTP/2 Is Done

#85

Post by youngtaff »

EugeneOZ wrote: post #70
bgentry wrote: post #16

It's time to begin the long process of unwinding all the hacks that we've built to make HTTP/1.1 fast. No more concatenation of static assets, no more domain sharding. The future looks more like this, as the default, with no special effort required: https://http2.golang.org/gophertiles May nobody else have to suffer through writing an interoperable HTTP/1.1 parser!

nginx doesn't support http2, apache too.. So maybe it's time to make some efforts to implement it on servers first. Maybe make some donations to apache, nginx dev. teams to speed up this process.

This is my real worry, at least nginx supports SPDY so has a base to evolve from, Apache support appears to be in a really bad place last time I checked.

Re: HTTP/2 Is Done

#86

Post by vbezhenar »

EugeneOZ wrote: post #70
bgentry wrote: post #16

It's time to begin the long process of unwinding all the hacks that we've built to make HTTP/1.1 fast. No more concatenation of static assets, no more domain sharding. The future looks more like this, as the default, with no special effort required: https://http2.golang.org/gophertiles May nobody else have to suffer through writing an interoperable HTTP/1.1 parser!

nginx doesn't support http2, apache too.. So maybe it's time to make some efforts to implement it on servers first. Maybe make some donations to apache, nginx dev. teams to speed up this process.

nginx fully supports SPDY. HTTP/2 is largely based on SPDY so I expect that nginx will support HTTP/2 very soon.

Re: HTTP/2 Is Done

#87

Post by pgl »

bantic wrote: post #35

I read Daniel Stenberg's (he is a maintainer of curl, I think?) "http2 explained" pdf the other day, and it's by far the best comprehensive explanation of http2 that I have seen. Well worth a read if you're curious what's coming with http2. http://daniel.haxx.se/http2/

Hacker News thread: https://news.ycombinator.com/item?id=9038613

Re: HTTP/2 Is Done

#88

Post by bkeroack »

bgentry wrote: post #33
bgentry wrote: post #16

It's time to begin the long process of unwinding all the hacks that we've built to make HTTP/1.1 fast. No more concatenation of static assets, no more domain sharding. The future looks more like this, as the default, with no special effort required: https://http2.golang.org/gophertiles May nobody else have to suffer through writing an interoperable HTTP/1.1 parser!

If anyone wants to learn more about optimizing for HTTP/2, unwinding HTTP/1.1 hacks, and strategies to optimize for both versions at the same time, Ilya Grigorik's "High Performance Browser Networking" is an excellent resource: http://chimera.labs.oreilly.com/books/1230000000545/ch13.htm...

Thanks. That book is a great resource.

Re: HTTP/2 Is Done

#89

Post by IgorPartola »

byuu wrote: post #77
nyir wrote: post #68

Earlier quoted context omitted.

I haven't looked more into that, but wouldn't it also be viable now to start HTTP/1.2 with e.g. a more restrictive header grammar, restricting all existing features to what's actually used, at least on the server side? Clients with 1.1 support would keep working, but future clients would be simplified.

That would be absolutely lovely. Since we're not viewing headers manually on 80x25 terminals anymore, we could do away with multi-line header values. That alone would drop off most of the complexity. (Being perfectly honest, even though it's part of the standard, you don't have to parse them now, anyway. I don't, and I've never had anyone complain to me about the site not working. Nothing mainstream sends them for th…

I am with you up to letting people use unencrypted HTTP. I assume people in this can use telnet instead of ssh because it is simpler. No, browsers should drop support for unencrypted HTTP soon after Let's Encrypt goes live.

Re: HTTP/2 Is Done

#90

Post by stephen_g »

byuu wrote: post #65
bgentry wrote: post #16

It's time to begin the long process of unwinding all the hacks that we've built to make HTTP/1.1 fast. No more concatenation of static assets, no more domain sharding. The future looks more like this, as the default, with no special effort required: https://http2.golang.org/gophertiles May nobody else have to suffer through writing an interoperable HTTP/1.1 parser!

> May nobody else have to suffer through writing an interoperable HTTP/1.1 parser! Yes, now it'll be much easier than parsing plain-text. Now they just have to write a TLS stack (several key exchange algorithms; block ciphers; stream ciphers; and data integrity algorithms); then implement the new HPACK compression; then finally a new parser for the HTTP/2 headers themselves. Now instead of taking maybe one day to wri…

Have you tried writing anything more than a very simple HTTP/1.1 parser/server? It's actually not as easy as it seems at first - edge cases everywhere, different user agents doing subtly different things, etc. etc.

Your argument is invalid in my opinion. HTTP/1.1 is not simple to implement to any decent level of completeness and correctness, and HTTP/2 does fix a fair few things.

Anyway, there are already plenty of good tools for debugging HTTP/2 streams (Wireshark filters, etc.), and there's only going to be plenty more as time goes by.

Post reply on HN