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

Hello HTTP/2, Goodbye SPDY

blog.chromium.org

Post reply on HN
Print view View original

51–60 of 181 posts

Re: Hello HTTP/2, Goodbye SPDY

#51

Post by desdiv »

azakai wrote: post #36
kllrnohj wrote: post #28

Earlier quoted context omitted.

> PNaCl is still enabled Eh? What is the spec competitor to PNaCl? asm.js is a cute trick but it still lacks threads which is easily one of the biggest features of PNaCl. So what actual viable alternatives are there to PNaCl?

We can discuss alternatives to PNaCl, but that isn't really the issue. Even if you have something you believe has no peer at the moment, that doesn't mean you can ship it without regards for the the standards process. It's still wrong for all the usual reasons. Of course, not having a good alternative might mean that the other parties in the standards process should take another look at it. But again, that's a totall…

But again, that's a totally separate issue from whether it is ok to just ignore the standards process and ship whatever you want, which is what Google is doing here.

But isn't that exactly what happened with SPDY? They shipped it unilaterally first, then later on it got standardized as HTTP2.

Re: Hello HTTP/2, Goodbye SPDY

#52

Post by zzzcpan »

StefanKarpinski wrote: post #40
striking wrote: post #24

I'm not ever supporting HTTP/2. For something "monumental" enough to be called the whole second revision of HTTP, what have we really gained? A Google-backed "server push" mechanism and some minor efficiency additions? Add to that the fact that SPDY was pushed through as HTTP/2 because nothing else was ready. Please. Downvoters: although I don't usually do this, I'd ask you to enter into a discussion with me instead…

This attitude is exactly how you make sure that nothing ever changes or improves. It is "the perfect is the enemy of the good" exemplified. HTTP/2 is a huge improvement over HTTP in many very important ways. True, it's not perfect, but guess what? 2 is not the last version number out there. We can switch to HTTP/2 now and fix the rest of the problems with HTTP/3. Moreover, it seems like we are collectively getting be…

> This attitude is exactly how you make sure that nothing ever changes or improves.

On the contrary, we are in a desperate need of such attitudes in software. We need for everyone to stop jumping to every new thing with silly promises. We need to start choosing quality over quantity. We need substantial well researched improvements.

Re: Hello HTTP/2, Goodbye SPDY

#53

Post by listic »

fletchowns wrote: post #21

Anybody know when nginx will support it?

They say it already does: "Right now, both the Apache and nginx web servers support HTTP/2" http://moz.com/blog/http2-a-fast-secure-bedrock-for-the-futu...

The thinking is, I believe, that "SPDY/4 revision is based upon HTTP/2 wholesale" http://http2.github.io/faq/ and nginx already supports SPDY via ngx_http_spdy_module. http://nginx.org/en/docs/http/ngx_http_spdy_module.html Version 3.1 though...

So it's either there or almost there.

Re: Hello HTTP/2, Goodbye SPDY

#54

Post by drderidder »

I got a copy of Paul-Henning Kamp's critique "HTTP/2.0 - The IETF is Phoning It In" off the ACM website before the link went dead. Here's a bit of what he said about it:

"Some will expect a major update to the world’s most popular protocol to be a technical masterpiece and textbook example for future students of protocol design. Some will expect that a protocol designed during the Snowden revelations will improve their privacy. Others will more cynically suspect the opposite. There may be a general assumption of "faster." Many will probably also assume it is "greener." And some of us are jaded enough to see the "2.0" and mutter "Uh-oh, Second Systems Syndrome."

The cheat sheet answers are: no, no, probably not, maybe, no and yes.

If that sounds underwhelming, it’s because it is.

HTTP/2.0 is not a technical masterpiece. It has layering violations, inconsistencies, needless complexity, bad compromises, misses a lot of ripe opportunities, etc. I would flunk students in my (hypothetical) protocol design class if they submitted it. HTTP/2.0 also does not improve your privacy. Wrapping HTTP/2.0 in SSL/TLS may or may not improve your privacy, as would wrapping HTTP/1.1 or any other protocol in SSL/TLS. But HTTP/2.0 itself does nothing to improve your privacy. This is almost triply ironic, because the major drags on HTTP are the cookies, which are such a major privacy problem, that the EU has legislated a notice requirement for them. HTTP/2.0 could have done away with cookies, replacing them instead with a client controlled session identifier. That would put users squarely in charge of when they want to be tracked and when they don't want to—a major improvement in privacy. It would also save bandwidth and packets. But the proposed protocol does not do this.

[He goes on to tear a strip off the IETF and the politics behind HTTP/2.0 ...]

Re: Hello HTTP/2, Goodbye SPDY

#55

Post by xpose2000 »

Does anyone know if Cloudflare has plans to implement HTTP/2? RIght now they support SPDY.

I found the answer from their blog:

"Part of the service CloudFlare provides is being on top of the latest advances in Internet and web technologies. We've stayed on top of SPDY and will continue to roll out updates as the protocol evolves (and we'll support HTTP/2 just as soon as it is practical)."

Re: Hello HTTP/2, Goodbye SPDY

#56

Post by nl »

dlubarov wrote: post #46
mrb wrote: post #27

Earlier quoted context omitted.

If that doesn't convince you to support HTTP/2, then nothing will: https://www.httpvshttps.com/ HTTP/1.1 is 5x-15x slower in this benchmark! These insane perf gains are possible only thanks to HTTP/2, specifically thanks to its support for multiplexing. Please read the spec and understand the technical implications before criticizing. On some unrelated note: I found this tidbit of humor in the RFC draft ( https://too…

Not really a fair benchmark. It's making tons of requests with tiny payloads, so that most browsers will hit a connection limit and requests will be queued up. Heavily optimized pages like google.com use data urls or spritesheets for small images, and inline small css/javascript. On the bright side, reducing the need to minimize request count will make our lives as developers a bit easier :-)

That's an extremely fair comparison because it shows how it is possible to avoid odd optimisations like the one you mentioned.

Re: Hello HTTP/2, Goodbye SPDY

#57

Post by exelius »

striking wrote: post #44
exelius wrote: post #42

Earlier quoted context omitted.

So you'd be ok if they called it HTTP/1.2? Snark aside, it's a standardized way of allowing different architectural patterns that can benefit use cases we haven't even seen yet. Yes, those architecture patterns currently benefit large corporations, but they're not being implemented at the expense of anything else. HTTP is a remarkably complete and flexible protocol. What other benefits were you expecting to see that…

From https://news.ycombinator.com/item?id=8825001 : * no more easy debugging on the wire * another TCP like implementation inside the HTTP protocol * tons of binary data rather than text * a whole slew of features that we don't really need but that please some corporate sponsor because their feature made it in * continuing, damaging and absurd lack of DNS and IPv6 considerations * most notably the omission of any dis…

I don't think anyone's selling it as the next new, big thing. It's just a version increment on HTTP; the one that includes DNS/DNSSEC/IPv6 changes can be called HTTP/3000 for all I care. You don't have to use these features if you don't like; they may make sites from companies like Google harder to reverse engineer, but HTTP is currently used for a lot more than text data. You just seem to confuse "corporations want it" with "bad".

And honestly, IPv6 is probably the biggest "big corporate" feature out there. Any big company providing access to more than 16 million devices (and yes, they do exist) has a very urgent need since the 10.0.0.0/8 network only contains ~16 million addresses.

At the end of the day, it's only a standard. As proven by SPDY, "big corporations" like Google are going to implement whatever the heck they want to, then ask for it to be included in the standard. I'm all for a system that makes it easier for companies to get their technologies standardized as part of an open standard - they're spending the investment dollars, but we all benefit from the capability.

Re: Hello HTTP/2, Goodbye SPDY

#58

Post by venaoy »

dlubarov wrote: post #46
mrb wrote: post #27

Earlier quoted context omitted.

If that doesn't convince you to support HTTP/2, then nothing will: https://www.httpvshttps.com/ HTTP/1.1 is 5x-15x slower in this benchmark! These insane perf gains are possible only thanks to HTTP/2, specifically thanks to its support for multiplexing. Please read the spec and understand the technical implications before criticizing. On some unrelated note: I found this tidbit of humor in the RFC draft ( https://too…

Not really a fair benchmark. It's making tons of requests with tiny payloads, so that most browsers will hit a connection limit and requests will be queued up. Heavily optimized pages like google.com use data urls or spritesheets for small images, and inline small css/javascript. On the bright side, reducing the need to minimize request count will make our lives as developers a bit easier :-)

Many of the sites I visit frequently are exactly like that: tons of requests with tiny payloads.

The nytimes.com homepage makes 100+ requests to tiny images.

Same thing for the yahoo.com homepage.

An ebay.com listing page makes many requests to small thumbnails of items on sale.

And so on... This makes it a perfectly fair benchmark IMHO.

Re: Hello HTTP/2, Goodbye SPDY

#59

Post by striking »

venaoy wrote: post #49
striking wrote: post #43

Earlier quoted context omitted.

Sure. It illustrates how any benchmark can be flawed because it's tailored to the point it's trying to make. The author of that article thought this scenario was "more realistic." What is more realistic to him is not to other people. And thus, benchmarks are unhelpful. I care about feature sets and major improvements, not minor down-to-the-wire fixes. If this were called HTTP/1.2 or something I'd be less critical, bu…

> And thus, benchmarks are unhelpful. No, they are helpful! Especially real-world benchmarks. Sure you can cook up utterly flawed benchmarks (like the one you pointed to), but that doesn't mean all benchmarks are unhelpful. A good engineer knows which benchmarks matter, which don't. You don't seem to be able to do that. > If this were called HTTP/1.2 ... The mere fact you brought this up (no amount of backpedalling y…

> benchmarks

The linked benchmark is flawed, as dlubarov noted above. I wanted to note that it is easy to write a flawed benchmark. And in this case, benchmarks are unhelpful, because my major lament is not efficiency or lack thereof, it is the lack of any new features or any consideration to any of the other pain points that exist on the Web today.

> doesn't mean all benchmarks are unhelpful

Didn't mean to imply that, although I can see how it could be read that way. Rest assured, I only believe benchmarks are unhelpful here. Oftentimes a benchmark is the best way to quantify usability, such as DoYouEvenBench (http://www.petehunt.net/react/tastejs/benchmark.html)

> backpedalling

I won't backpedal. This is important, actually, because the name it's given lends it some intrinsic hype. Let's say you're Google, and you're pushing a web standard that benefits you more than anyone else. What's more likely to be adopted, "HTTP/1.2" or "HTTP/2" ? It is important, in my opinion.

Re: Hello HTTP/2, Goodbye SPDY

#60

Post by jcoffland »

Google just loves exerting their power. It will take more than Chrome devs declaring it a done deal to make this happen. The browser is only half the issue. Web servers must get on board for this to matter. Obviously Safari, FireFox and IE have some say in this too.
Post reply on HN