Anybody aware of a good C++ server framework supporting most of HTTP/2, including websockets?
Facebook's proxygen has HTTP/2 support "in progress": https://github.com/facebook/proxygen
Hello HTTP/2, Goodbye SPDY
31–40 of 181 posts
Re: Hello HTTP/2, Goodbye SPDY
#32I'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…
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…
I can point you to a benchmark that disagrees. http://www.guypo.com/not-as-spdy-as-you-thought/ .
I promise you that I've considered the spec and its implications. Where are we now?
Re: Hello HTTP/2, Goodbye SPDY
#33Earlier 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…
The only explanation for this nonsense phaenomenon seems to be that HTTPS ports are less used generally, which isn't an argument in favor of HTTPS.
That has nothing to do with anything. SPDY and HTTP/2 reduce the number of TCP round trips needed to transmit information.
"Nonsense phaenomenon?" Not to anyone who actually looks at how the protocols are implemented!
Re: Hello HTTP/2, Goodbye SPDY
#34Earlier quoted context omitted.
Agreed, Google did the right thing to remove Gears. My concern is because, overall, Google has a bad track record in this area: FileSystem is still enabled, WebSQL is still enabled, PNaCl is still enabled edit: and H.264 was never removed despite announcing the intent to do so.
Not to mention not removing H.264 after promising to do so.
Thanks, right, I forgot that one.
Re: Hello HTTP/2, Goodbye SPDY
#35Earlier 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 )
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.
This setup scales and is extensible for additional protocols
Re: Hello HTTP/2, Goodbye SPDY
#36Earlier quoted context omitted.
Agreed, Google did the right thing to remove Gears. My concern is because, overall, Google has a bad track record in this area: FileSystem is still enabled, WebSQL is still enabled, PNaCl is still enabled edit: and H.264 was never removed despite announcing the intent to do so.
> 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 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.
Re: Hello HTTP/2, Goodbye SPDY
#37I'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…
> I'm not ever supporting HTTP/2. Congrats? Want a cookie or something? Do you have an actual complaint with the spec or do you just want to be an old man yelling at a cloud?
My "actual" complaint is that it's not enough to be a major version and that it's a system that only benefits large corporations with data to pre-push, with no other benefits.
You can think differently, of course, but after looking at this (https://news.ycombinator.com/item?id=8824789) I reconsidered my previously positive view on it.
(Also, I'd love a cookie)
Re: Hello HTTP/2, Goodbye SPDY
#38Anybody aware of a good C++ server framework supporting most of HTTP/2, including websockets?
If you need only realtime push then Server-Sent Events work over HTTP/2.
Re: Hello HTTP/2, Goodbye SPDY
#39Earlier 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…
I can point you to a benchmark that disagrees. http://www.guypo.com/not-as-spdy-as-you-thought/ . I promise you that I've considered the spec and its implications. Where are we now?
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 reduce round trips, so putting this content on your own domain all together would be better, anyway."
In other words the guy benchmarked SPDY _slowed down by HTTP connections behind it_!!
Re: Hello HTTP/2, Goodbye SPDY
#40I'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 better at upgrading technologies: IPv6 adoption has finally got some momentum; HTTP/2 is actually happening. With lessons learned from the HTTP => HTTP/2 transition, HTTP/3 could happen in five years instead of in another fifteen.