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

61–70 of 181 posts

Re: Hello HTTP/2, Goodbye SPDY

#61

Post by izietto »

striking wrote: post #43
venaoy wrote: post #39

Earlier quoted context omitted.

First comment: "This study is very flawed. Talking to a proxy by SPDY doesn't magically make the connection between that proxy and the original site use the SPDY protocol, everything was still going through HTTP at some point for the majority of these sites. Further, the exclusion of 3rd party content fails to consider how much of this would be 1st party in a think-SPDY-first architecture, where you know you'll reduc…

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…

> there are so many issues and flaws left unfixed

Can you explain this point?

Re: Hello HTTP/2, Goodbye SPDY

#62

Post by klapinat0r »

billyhoffman wrote: post #14
klapinat0r wrote: post #2

SPDY came and went before I had to implement it. Phew. On a serious note: it's nice to see ALNP being used in HTTP/2

ALNP has been used with SPDY for a while now. It one of the nice improvements that fell out of testing/iterating SPDY in public. The NPN approach was a bad idea since the client drove what got picked (With NPN, Server tells the client what other protocols it supports in the ServerHello and the client picks whatever it wants. ALNP reverses that.)

Sorry I didn't make it clear: that's my sentiment aswel. I'm glad it survived, so to speak.

Re: Hello HTTP/2, Goodbye SPDY

#63

Post by venaoy »

striking wrote: post #59
venaoy wrote: post #49

Earlier quoted context omitted.

> 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 tha…

> The linked benchmark is flawed, as dlubarov noted above.

No, I already replied to him. You and him should spend some time looking at the Chrome network console visiting some of the top500 sites. It is very common for sites to be exactly like that: tons of small requests for small resources.

Re: Hello HTTP/2, Goodbye SPDY

#64

Post by azakai »

desdiv wrote: post #51
azakai wrote: post #36

Earlier quoted context omitted.

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.

I don't think it's the same.

SPDY initially began inside Google. But rather quickly it got enthusiastic interest from multiple outside parties, and a standardization process began. We can see the (successful) end of that process now. Yes, it's true that many standards begin that way.

PNaCl also began inside Google. Discussions regarding it, and the PPAPI on which it depends, were a combination of opposition (e.g. because PPAPI duplicates existing web APIs, and because it's a plugin API, which browsers are trying to move away from) to ignoring. Google continued to work on it, enabled it on the Chrome Web Store, and despite any change in the response of the community over a period of years, enabled it for web content. Over a year has passed since then, and it seems clear that (1) no browser outside Google thinks PNaCl is a good idea, and (2) no significant interest has been shown from non-browser vendors either (Google itself is the main user of PNaCl).

Also, to make things even worse, during all that time, PNaCl has not been brought to any standards body.

Another large difference is that, in practice, SPDY didn't pose a compatibility threat to the web. It has clear fallbacks so that content still works without browser support for it. And while it is possible bugs could still cause breakage, it didn't happen in practice. So moving forward somewhat quickly with SPDY was still arguably a responsible thing to do.

Whereas, PNaCl is already showing fragmentation problems, with several Google properties using PNaCl and consequently only working in Chrome.

There is therefore every reason for Google to disable PNaCl, because it is nonstandard and bad for the web to keep it on. Unless Google simply does not care about standardization here.

Re: Hello HTTP/2, Goodbye SPDY

#65

Post by wmf »

drderidder wrote: post #54

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 the…

HTTP/2 may actually help PHK get what he wants sooner. Proposing to make major syntax and semantic changes would have turned HTTP/2 into an extremely contentious 10-year project. Splitting that into more manageable chunks (syntax in HTTP/2, semantics in HTTP/3), combined with the iterative process that was used to evolve SPDY into HTTP/2, may be more tractable.

Of course, no process will will help you if everyone disagrees with your proposals.

Re: Hello HTTP/2, Goodbye SPDY

#66

Post by guelo »

drderidder wrote: post #54

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 the…

Who exactly was it that voted for HTTP2? Is the debate leading up to the vote public?

Re: Hello HTTP/2, Goodbye SPDY

#67

Post by magicalist »

drderidder wrote: post #54

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 the…

That critique was a poor one. In fact, what you quoted was the meat of it, with little to back up the hyperbole, except for the argument that we shouldn't have all connections encrypted because that will make the NSA work harder to break all encryption. Which is not a good argument.

The discussion on it covered it pretty well: https://news.ycombinator.com/item?id=8850059

edit: it's still in google cache if anyone else wants to read it for themselves: https://webcache.googleusercontent.com/search?q=cache:3i6EwF...

Re: Hello HTTP/2, Goodbye SPDY

#68

Post by wmf »

guelo wrote: post #66
drderidder wrote: post #54

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 the…

Who exactly was it that voted for HTTP2? Is the debate leading up to the vote public?

https://lists.w3.org/Archives/Public/ietf-http-wg/

Re: Hello HTTP/2, Goodbye SPDY

#69

Post by lucian1900 »

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…

Wait, it being a binary protocol is a good thing. No longer will we have proxies mangling Upgrade handshakes and such.

Header compression, server push and proper multiplexing (which avoids all the problems with pipelining) are all features most applications will benefit from.

Re: Hello HTTP/2, Goodbye SPDY

#70

Post by newman314 »

js4all wrote: post #35
newman314 wrote: post #23

Earlier quoted context omitted.

Maybe you could share a scrubbed config?

Sure, here is a gist: https://gist.github.com/dvbportal/cccccbbf6163cfbbbce6 The frontend definition advertises spdy and http/1.1 protocols via npn. (this should be now ALPN, HAProxy supports it) The ssl_fc_npn ACL routes to the SSL-teminated traffic to the appropriate backends. Nginx is configured to serve two backends with one port for each protocol. There can be multiple instances with round robin, if necessary. T…

Thanks! I'll go take a look now.
Post reply on HN