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

141–150 of 181 posts

Re: Hello HTTP/2, Goodbye SPDY

#141

Post by mnarayan01 »

totony wrote: post #109
drawkbox wrote: post #88

Earlier quoted context omitted.

Did you close that tag in that textarea from some third party content? If not you're whole view is broken. It was a layer or hopeful standardization that was too hopeful and counted on implementers too much to be exact. It was a nice attempt but was quickly retracted to go to HTML5. I guess the same thing applies to HTTP/2, sometimes you have to dumb/simplify it down a little, the smartest way that relies on implemen…

XHTML was an overall improvement to HTML imo. If you're going to use XML, at least be consistent with this choice. HTML was not, XHTML is.

Technically HTML was a derivative of SGML. That said, as someone who did a fair amount of parsing of old-timey HTML...it would have been really nice if it was XML.

Re: Hello HTTP/2, Goodbye SPDY

#142

Post by cpeterso »

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…

Network debugging tools like Wireshark will have pretty printers for HTTP/2, just like they do for TCP/IP.

Re: Hello HTTP/2, Goodbye SPDY

#143

Post by js4all »

Apofis wrote: post #118
js4all wrote: post #17

Earlier quoted context omitted.

Current HAProxy already supports the handshake of SPDY/HTTP2 via NPN and ALPN. You have to route to proper backends. You also need to provide a HTTP/1.1 fallback implementation for incapable clients. Once setup that works very well. I am using it for our blog ( https://blog.cloudno.de )

What about SSL Termination? Would it still work if I terminate?

In the described setup, HAProxy is doing SSL termination. See the gist for the cert and crypto parameters. This is getting a A+ from ssllabs.

Re: Hello HTTP/2, Goodbye SPDY

#144

Post by js4all »

jsmeaton wrote: post #119
js4all wrote: post #35

Earlier quoted context omitted.

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 for sharing. Can the SPDY frontend only be tcp based though, not http? The reason I ask is because my setup does all the routing (path and subdomain based) with http frontends.

Unfortunately, it has to be TCP. You can define other HTTP frontends thought, but then you lose SPDY for that frontend.

You can use the routing capabilities of nginx in the backend to break the traffic further down.

Re: Hello HTTP/2, Goodbye SPDY

#145

Post by citrin_ru »

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…

> 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

There is a copy in maillist http://lists.w3.org/Archives/Public/ietf-http-wg/2015JanMar/...

Re: Hello HTTP/2, Goodbye SPDY

#147

Post by stephen_g »

dragonwriter wrote: post #101
hacst wrote: post #97

Earlier quoted context omitted.

The header compression in HTTP 2.0 isn't based on gzip or something like that. The CRIME attack pretty much killed those approaches dead. It's more akin to differential updates for header during the lifetime of the connection. So if you request a lot of files with fairly similar headers you'll effectively only have to transmit the bulk of the header once while the other request will efficiently re-use the previously…

> So to answer your question: Header compression as employed in HTTP 2.0 helps if you do many requests with similar headers on the same connection. In general, HTTP/2.0 seems to be about improving things if you do many requests over the same connection.

I think this is correct - because that is one big area where TCP and HTTP really fall short.

HTTP/2 should be a huge improvement for lowering latency in anything but the simplest web sites, without having to use ugly hacks such as sprite sheets and putting all your javascript/CSS in one file (which is sub-optimal in terms of caching if you want to update say a single javascript file, because then a user with a full cache has to re-download the huge concatenated javascript file instead of just the single source that changed), and avoiding spanning things across multiple domains to get around browsers having a connection limit.

Re: Hello HTTP/2, Goodbye SPDY

#148

Post by enneff »

bsdetector wrote: post #114
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…

> These insane perf gains are possible only thanks to HTTP/2, specifically thanks to its support for multiplexing. What's sad about this is that if you load this site with pipelining enabled you get the same speed benefits as with HTTP/2 or SPDY, but Google would never know this, since they never tested SPDY against pipelining. > ENHANCE_YOUR_CALM (0xb): > Please read the spec and understand the technical implication…

HTTP pipelining is busted for a variety of reasons. Support exists in most browsers but it's disabled by default because it makes things worse, on balance.

Re: Hello HTTP/2, Goodbye SPDY

#149

Post by josteink »

wmf wrote: post #65
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 dis…

> Splitting that into more manageable chunks (syntax in HTTP/2, semantics in HTTP/3), combined with the iterative process

Sounds great!

Just one question: How many versions of the (now flabagasteringly complex) HTTP-protocol will I need to support in my application and libraries? Because as we all know, once deployed on the internet, something will never be updated and will need to be supported forever, meaning you can never obsolete that HTTP/1.1 and /2.0 code.

HTTP/1.1 was a fantastic protocol in that it survived for almost 2 decades unchanged. Here we have HTTP/2.0 and people are already talking about what we will need to add to HTTP/3.0.

If HTTP is going to end up being the new MSIE, we can only blame ourselves because we allowed Google to use its dominance to push a protocol the internet didn't need.

Re: Hello HTTP/2, Goodbye SPDY

#150

Post by josteink »

enneff wrote: post #74
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…

Whatever PHK wants it to be, HTTP/2 is a great step forward from where we are today. Check this out: https://http2.golang.org/gophertiles This is going to make the web so much faster, particular on mobile devices.

> Check this out: https://http2.golang.org/gophertiles

This page confirms that I'm not using Google's trainwreck protocol and tells me the config-parameters I need to ensure I keep my browser this way.

    Unfortunately, you're not using HTTP/2 right now. To do so:
    Use Firefox Nightly or go to about:config and enable "network.http.spdy.enabled.http2draft"
    Use Google Chrome Canary and/or go to chrome://flags/#enable-spdy4 to Enable SPDY/4 (Chrome's name for HTTP/2)
This is quite good, although probably not for the reason the original authors intended.
Post reply on HN