15 ms·

Hello HTTP/2, Goodbye SPDY

426 points by Nimi 12y ago

klapinat0r 12y ago
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
- billyhoffman 12y ago
  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.)
  - klapinat0r 12y ago
    Sorry I didn't make it clear: that's my sentiment aswel. I'm glad it survived, so to speak.
jjcm 12y ago
Are there any good reverse proxies out there that support HTTP/2? Right now I'm using varnish, but I'd love to switch over to something supporting this.
itsbits 12y ago
Hardly a surprise..
anderspetersson 12y ago
Looking forward to when HAProxy support for HTTP/2 lands since they refused to implement SPDY support. Here's a list of common servers support for SPDY/HTTP2: https://istlsfastyet.com/#server-performance https://istlsfastyet.com/#server-performance
- js4all 12y ago
  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 https://blog.cloudno.de)
  - newman314 12y ago
    Maybe you could share a scrubbed config?
    - js4all 12y ago
      Sure, here is a gist: https://gist.github.com/dvbportal/cccccbbf6163cfbbbce6 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
      - newman314 12y ago
        Thanks! I'll go take a look now.
      - jsmeaton 12y ago
        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.
        js4all 12y ago
        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.
fdsary 12y ago
What happens if someone built a service based on it? Should they never trust browsers keeping alive even the shitty (in comparison to free and standardised HTTP/2) features? What's great about the web is that now 20 year old services still are working in the latest runtimes (browsers).
- quonn 12y ago
  The server should fall back to HTTP anyway, so this should not be a problem.
- azakai 12y ago
  It is always risky to build a service based on something that is not yet standardized. SPDY was in progress to be standardized, but the process ended up with parts of it in HTTP2, making SPDY unnecessary, as I understand things. It would be the right thing for Google to remove SPDY at this point, otherwise it would be running a nonstandard protocol that other browsers do not, which can lead to fragmentation - as we saw just recently with an API that sadly Google has not removed despite it being nonstandard (FileSystem in the WhatsApp "Web" app). edit: To clarify, I mean what Google is doing with SPDY sounds like the right thing. I don't mean it should remove it right now, I meant it was the right thing to do, right now, to announce it would be removed after a reasonable delay (and 1 year sounds reasonable).
  - dragonwriter 12y ago
    > SPDY was in progress to be standardized, but the process ended up with parts of it in HTTP2, making SPDY unnecessary, as I understand things. The "progress to be standardized" for SPDY was SPDY being chosen as the basis for HTTP/2; as I understand for a while SPDY has been being updated in parallel to the HTTP/2 development work to continue to reflect the state of HTTP/2 + new things the Google SPDY team wants to get into the standard, but its been clear for a long time that the intent was that SPDY as a separate protocol would be unnecessary once HTTP/2 was ready for use.
  - kozhevnikov 12y ago
    To be fair Google did happily kill Gears when HTML5 became a viable [early draft] standard.
ommunist 12y ago
@klapinat0r - welcome to the club. I was just about to say the same.
mahouse 12y ago
Is HTTPS mandatory on HTTP/2 like it was on SPDY?
- dragonwriter 12y ago
  > Is HTTPS mandatory on HTTP/2 like it was on SPDY? Not in terms of the protocol spec, but most major browser vendors have indicated that they only intend to support HTTP/2 in-browser over TLS connections, so in practice for typical, browser-targeting use cases, it looks like it will, at least initially.
  - Touche 12y ago
    That's so lame. It's so easy to set up a new website today, it's going to be a huge burden in the future. Some of us still make websites for fun, not as businesses. I guess I have to buy a cheap ssl certificate from some sleezy website every time I feel creative.
    - magicalist 12y ago
      Or we're about to see a whole lot of market incentive to make it easier to set up a site under TLS, which may only happen with this kind of unilateral move.
      - josteink 12y ago
        In the beginning of the internet, when it flourished and bloomed, it did so because it was open to tinkering, hacking and fun! You could 1. set up a server, and just 2. enter the IP, and you had a website to hack on! Now... You need to not only do that, you need to understand DNS and then pay a registrar to get a domain, you probably need to get hosting, because your router's secure ISP-side admin-interface may already be hogging port 443, you need to read up on how SSL/TLS and how certificates work in order to correctly request one, and then you need to figure out how those bits and pieces from that process fits into the server-stack you have decided to run with, and then you need to setup all those extra things server-side, which may or may not involve learning quite a bit of Unixy or sysadminy-things. Phew And that was step 1. See the contrast? In the playful internet of past times and glory you would have your product/experiment be done by now. In your "secure" internet you're merely done bootstrapping. Yes, if you already have that, or already know all that stuff, that might not stop you moving along. For the amateur, who still should be the most welcome of all people on the internet for it to keep evolving, that's a complete show-stopper. He'll just say "fuck this shit" most likely decide that this is just too big a task to even bother starting. Forcing SSL everywhere on everyone is bad for the internet. I don't need to do everything "securely", and I sure as hell don't intend to setup every single experiment I do securely. Make it too much of a hurdle, and maybe I'll just stop experimenting instead. And then, if not the internet, its spirit dies.
deleted 12y ago
[deleted]
fletchowns 12y ago
Anybody know when nginx will support it?
- listic 12y ago
  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-future-of-seo 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/ 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 http://nginx.org/en/docs/http/ngx_http_spdy_module.html Version 3.1 though... So it's either there or almost there.
  - fletchowns 12y ago
    Here's the related thread on the mailing list: http://mailman.nginx.org/pipermail/nginx/2015-February/046583.html http://mailman.nginx.org/pipermail/nginx/2015-February/04658...
striking 12y ago
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 of just hitting the down arrow. Do you honestly think my discussion is worth being silenced?
- mrb 12y ago
  If that doesn't convince you to support HTTP/2, then nothing will: https://www.httpvshttps.com/ 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://tools.ietf.org/html/draft-ietf-httpbis-http2-16 https://tools.ietf.org/html/draft-ietf-httpbis-http2-16): ENHANCE_YOUR_CALM (0xb): The endpoint detected that its peer is exhibiting a behavior that might be generating excessive load.
  - fiatjaf 12y ago
    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.
    - sarciszewski 12y ago
      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!
  - striking 12y ago
    I can point you to a benchmark that disagrees. http://www.guypo.com/not-as-spdy-as-you-thought/ 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?
amelius 12y ago
Anybody aware of a good C++ server framework supporting most of HTTP/2, including websockets?
- fmela 12y ago
  Facebook's proxygen has HTTP/2 support "in progress": https://github.com/facebook/proxygen https://github.com/facebook/proxygen
  - amelius 12y ago
    Yes, but I believe they don't support websockets yet. At least, searching their github for "websockets" gives only two broken links. UPDATE: I noticed somebody wrote websocket support [1], but it didn't get merged yet with the master. [1] https://github.com/kekekeks/proxygen https://github.com/kekekeks/proxygen
- pornel 12y ago
  If you need only realtime push then Server-Sent Events work over HTTP/2.
- igrigorik 12y ago
  See: https://github.com/http2/http2-spec/wiki/Implementations https://github.com/http2/http2-spec/wiki/Implementations. nghttp2 is solid.
hannob 12y ago
Unfortunately right now apache doesn't support HTTP/2 at all. There was a mod_spdy, but it's pretty much dead. Apache took it over from google some time ago, but since then nothing happened.
- josteink 12y ago
  This is what happens when you let Google (or other big corporations) write internet-standards. If it isn't community-driven, you can't expect it to be implemented in the places the big corp doesn't care for. So in this case, Apache one of the major drivers for propelling the WWW may end up not supporting a "crucial" WWW-related standard, because the community was never invited. If anyone still has any doubts why letting Google control internet-standards is bad, this is currently my best example. Technically speaking, the internet is the result of what we come up with, when we all work together. Not working together will quickly end up as not working at all.
  - netik 12y ago
    I think the reality here is, this is what happens when you let companies fight over a standard in private. What I saw on the HTTP/2 mailing lists was "We have a new standard." "It demands SSL, but we don't want that." Then, SPDY is everywhere, let's use that. Shortly after it was "Omg, we can't call it spdy, because then Microsoft's interests will be left behind and Google will have won. Let's abandon the mandatory SSL requirement and rename SPDY to HTTP2..." I feel like we've all lost here. We implemented SPDY at Twitter - the savings were fantastic and the browser performance, amazing. Google and FB did the same. It's nearly like, 800M users said it was great, can we move on now?
drderidder 12y ago
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 ...]
- wmf 12y ago
  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.
  - josteink 12y ago
    > 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.
xpose2000 12y ago
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)."
- derefr 12y ago
  Since CloudFlare is an OpenResty (nginx + lua) shop, they'll likely get it as soon as it's in nginx.
  - MichaelGG 12y ago
    OpenResty does not include SPDY as there are incompatibilities with it and Lua. But I'm sure CloudFlare has the engineering resources in house to decide what they want to support and when :)
- rdl 12y ago
  We've been talking about it. I think it's just a question of when.
- ropiku 12y ago
  Do you know if they support SPDY downstream too ?
jcoffland 12y ago
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.
- enneff 12y ago
  Pretty much everyone in the industry is on-board with HTTP/2. It's not just Google.
drawkbox 12y ago
HTTP/2 is an ugly mess of taking something simple and making it more complex for minimal benefit. It could have been so much better than a binary mess. As engineers, the ones that take simple concepts and add complexity, those are not engineers, those are meddlers. It could be as long lived as XHTML. I was hoping for more SCTP rather than a bunch of cludge on top of what is a pretty beautiful protocol in HTTP 1.1. Protocol designers of the past seemed to have a better long view mixed with simplicity focused on interoperability that you like to see from engineers.
- smegel 12y ago
  For those slamming HTTP/2.0, how do they rate SPDY?
  - drawkbox 12y ago
    SPDY was great for Google and allowed them to change and take hold of HTTP/2. It saved them lots of money I am sure in improved speed but at the trade-off of complexity and minimal adoption of the standard because it wasn't beneficial to everyone. HTTP/2 is a continuation of that effort by Google which I would do if I were them as well probably. But in the end both are not that big of improvements for what they take away. Of course I use both but I don't think they will last very long until the next, it was too fast and there are large swaths of engineers that do not like being forced into something that has minimal benefits when it could have been a truly nice iteration. HTTP/2 is really closer to SPDY and I wish they would have just kept it as SPDY for now. Let a little more time go by to see if that is truly useful enough to merge into HTTP/2. HTTP/2 is essentially SPDY from Google tweaked and injected into HTTP/2 which has huge benefits for Google, so I understand where the momentum is coming from. Google also controls the browser so it is much easier for them to be the lead now on web standards changes. We will have to use it if we like it or not. I don't like the heavy hand that they are using with their browser share, just like Microsoft of older days (i.e plugins killed off, SPDY, HTTP/2, PPAPI, NaCL etc)
  - copsarebastards 12y ago
    SPDY is a great prototype that exemplifies why you should write a prototype: to show the problems with your design. It's unfortunate that the HTTP/2.0 committee decided to ignore the flaws and go with the prototype design.
donatj 12y ago
Can someone explain to me the actual upside of header compression? I work on a fairly major educational site and calculating now our request + response headers comes out to 1,399 bytes. Gzipping them they come out to 1,421 bytes. A small net increase. Am I missing something? Do some people have so many cookies that this makes a difference or something?
- cradle 12y ago
  As far as I can tell, the compression is separate for the headers, does not use deflate, and (most importantly) is over the entire session, not just one request. This would benefit from the fact that in one request headers are not repeated, but over multiple requests they certainly are. http://www.greenbytes.de/tech/webdav/draft-ietf-httpbis-header-compression-01.html http://www.greenbytes.de/tech/webdav/draft-ietf-httpbis-head...
- hacst 12y ago
  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 transmitted fields. 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.
  - dragonwriter 12y ago
    > 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.
    - ademarre 12y ago
      Doing many requests over the same connection is very common.
est 12y ago
Well how about the fate of the cute little protocol called QUIC?
- wmf 12y ago
  Maybe QUIC is the prototype for HTTP/4.
  - briandh 12y ago
    QUIC is not a replacement for HTTP; it works below it. See https://docs.google.com/document/d/1lmL9EF6qKrk7gbazY8bIdvq3Pno2Xj_l_YShP40GLQE/edit https://docs.google.com/document/d/1lmL9EF6qKrk7gbazY8bIdvq3...
  - billyhoffman 12y ago
    I think they want QUIC to be TCP/2. It's design goals around slow start, congestion control, and RTT reduction are squarely aimed at TCP's short comings.
drawkbox 12y ago
HTTP/2 might have version 2 syndrome. Another better way would have been keep SPDY, as there is usefulness there, separate and then on HTTP/2, to incrementally get there, and use an iteration of something like AS2/EDIINT (https://tools.ietf.org/html/rfc4130 https://tools.ietf.org/html/rfc4130) which does encryption, compression and digital signatures on top of existing HTTP (HTTPS is usable as current but not required as it uses best compression/encryption currently available that the server supports). This standard still adheres to everything HTTP and hypertext transfer based and does not become a binary file format but relies on baked in MIME. An iteration of that would have been better for interoperability, secure and fast. I have implemented it directly previously from RFC for an EDI product and it is used for sending all financial EDI/documents for all of the largest companies in the world Wal-mart, Target, DoD as well as most small and medium businesses with inventory. There are even existing interoperability testing centers setup for testing out and certifying products that do this so that the standard works for all vendors and customers. An iteration of this would have fit in as easily and been more flexible on the secure, compression and encryption side, and all over HTTP if you want as it encrypts the body.
- UnoriginalGuy 12y ago
  I've used AS2 extensively (in EDI) and to be frank, fuck that. AS2 is a really bad version of HTTPS, you take HTTPS, you remove the auto-negotiation (email the certificates!), you disable certification CA checking (self-signed for all the things), and then you allow optional HTTPS on top of AS2 (which is a huge nightmare in its own right). Imagine this scenario, two people want to interconnect, here's the process: - They insecurely email their public key (self-signed) and URL (no MitM protection) - You insecurely email your public key (self-signed) and URL - They have a HTTPS URL - Now the thing to understand about AS2 is that when you connect to THEM you give them a return URL to confirm receipt (MDN) of the transaction. - HTTPS becomes a giant clusterfuck in AS2 because people try to use standard popular HTTPS libraries (e.g. that do CA checking, domain checking, and other checks which are fine for typical web-browser-style traffic, but not for specialised AS2 traffic) but in the context of AS2 where certificates are often local self-signed (some even use this for HTTPS), and the URL is rarely correct for the certificate, they fall over all of the time. - Worse still some sites want to use either HTTP or HTTPS only, so when you connect to a HTTPS URL but give them a HTTP MDN URL sometimes they will work, sometimes they will try the HTTPS version of the URL then fall over and die, and other times they will error just because of the inconsistency. Honestly I used AS2 for over five years, looking back, it would have saved everyone hundreds of man-hours to have just used HTTPS in the standard way and implement certificate pinning (e.g. "e-mail me the serial number," or heck just list it in your documentation). The only major advantage of AS2 is the MDNs. However even there there exists massive inconsistency, some return bad MDNs for bad data, while others only return bad MDNs for bad transmission of data (i.e. they only check that what you send is what is received 1:1, so you could send them a series of 0s and get a valid MDN, because they check the data later and then email). To be honest I hate MDN errors. They don't provide human-readable information in an understandable way. They're designed for automation which rarely exists in the wider world (between millions of different companies with hundreds of systems). Give me an email template for errors any day, that way there can be a brief generic explanation and formatted data, to better explain things. The only thing MDNs do well is data consistency checking which is legitimately nice, however almost every EDI format I know has that in it already (i.e. segment counters, end segments, etc). If I was to re-invent AS2, I'd just build the entire thing on standard HTTPS. No HTTP allowed, no hard coded certificates (i.e. you receive a public key the same way your web browser does), certificate pinning would be a key part, and scrap MDNs in place of a hash as a standard header in the HTTPS stream. Normal HTTP REST return codes would be used to indicate success (e.g. 200 OK/202 ACCEPTED, 400 Md5Mismatch/InvalidInput/etc). That way nobody has to deconstruct an MDN to try and figure out the error. And handling a small handful of HTTP codes is much easier to automate than the information barriage an MDN contains anyway, it is both easier to automate, and easier for humans.
therealmarv 12y ago
Does somebody has good nginx configurations for HTTP/2? Good that browser go this directions but at the moment I have no clue on how to implement HTTP/2 (is there a SPDY fallback?) on my nginx server :(

426 points by Nimi 12y ago

klapinat0r 12y ago

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

billyhoffman 12y ago
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.)
- klapinat0r 12y ago
  Sorry I didn't make it clear: that's my sentiment aswel. I'm glad it survived, so to speak.

jjcm 12y ago

Are there any good reverse proxies out there that support HTTP/2? Right now I'm using varnish, but I'd love to switch over to something supporting this.

itsbits 12y ago

Hardly a surprise..

anderspetersson 12y ago

Looking forward to when HAProxy support for HTTP/2 lands since they refused to implement SPDY support. Here's a list of common servers support for SPDY/HTTP2: https://istlsfastyet.com/#server-performance https://istlsfastyet.com/#server-performance

js4all 12y ago
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 https://blog.cloudno.de)
- newman314 12y ago
  Maybe you could share a scrubbed config?
  - js4all 12y ago
    Sure, here is a gist: https://gist.github.com/dvbportal/cccccbbf6163cfbbbce6 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
    - newman314 12y ago
      Thanks! I'll go take a look now.
    - jsmeaton 12y ago
      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.
      - js4all 12y ago
        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.

fdsary 12y ago

What happens if someone built a service based on it? Should they never trust browsers keeping alive even the shitty (in comparison to free and standardised HTTP/2) features? What's great about the web is that now 20 year old services still are working in the latest runtimes (browsers).

quonn 12y ago
The server should fall back to HTTP anyway, so this should not be a problem.
azakai 12y ago
It is always risky to build a service based on something that is not yet standardized. SPDY was in progress to be standardized, but the process ended up with parts of it in HTTP2, making SPDY unnecessary, as I understand things. It would be the right thing for Google to remove SPDY at this point, otherwise it would be running a nonstandard protocol that other browsers do not, which can lead to fragmentation - as we saw just recently with an API that sadly Google has not removed despite it being nonstandard (FileSystem in the WhatsApp "Web" app). edit: To clarify, I mean what Google is doing with SPDY sounds like the right thing. I don't mean it should remove it right now, I meant it was the right thing to do, right now, to announce it would be removed after a reasonable delay (and 1 year sounds reasonable).
- dragonwriter 12y ago
  > SPDY was in progress to be standardized, but the process ended up with parts of it in HTTP2, making SPDY unnecessary, as I understand things. The "progress to be standardized" for SPDY was SPDY being chosen as the basis for HTTP/2; as I understand for a while SPDY has been being updated in parallel to the HTTP/2 development work to continue to reflect the state of HTTP/2 + new things the Google SPDY team wants to get into the standard, but its been clear for a long time that the intent was that SPDY as a separate protocol would be unnecessary once HTTP/2 was ready for use.
- kozhevnikov 12y ago
  To be fair Google did happily kill Gears when HTML5 became a viable [early draft] standard.

ommunist 12y ago

@klapinat0r - welcome to the club. I was just about to say the same.

mahouse 12y ago

Is HTTPS mandatory on HTTP/2 like it was on SPDY?

dragonwriter 12y ago
> Is HTTPS mandatory on HTTP/2 like it was on SPDY? Not in terms of the protocol spec, but most major browser vendors have indicated that they only intend to support HTTP/2 in-browser over TLS connections, so in practice for typical, browser-targeting use cases, it looks like it will, at least initially.
- Touche 12y ago
  That's so lame. It's so easy to set up a new website today, it's going to be a huge burden in the future. Some of us still make websites for fun, not as businesses. I guess I have to buy a cheap ssl certificate from some sleezy website every time I feel creative.
  - magicalist 12y ago
    Or we're about to see a whole lot of market incentive to make it easier to set up a site under TLS, which may only happen with this kind of unilateral move.
    - josteink 12y ago
      In the beginning of the internet, when it flourished and bloomed, it did so because it was open to tinkering, hacking and fun! You could 1. set up a server, and just 2. enter the IP, and you had a website to hack on! Now... You need to not only do that, you need to understand DNS and then pay a registrar to get a domain, you probably need to get hosting, because your router's secure ISP-side admin-interface may already be hogging port 443, you need to read up on how SSL/TLS and how certificates work in order to correctly request one, and then you need to figure out how those bits and pieces from that process fits into the server-stack you have decided to run with, and then you need to setup all those extra things server-side, which may or may not involve learning quite a bit of Unixy or sysadminy-things. Phew And that was step 1. See the contrast? In the playful internet of past times and glory you would have your product/experiment be done by now. In your "secure" internet you're merely done bootstrapping. Yes, if you already have that, or already know all that stuff, that might not stop you moving along. For the amateur, who still should be the most welcome of all people on the internet for it to keep evolving, that's a complete show-stopper. He'll just say "fuck this shit" most likely decide that this is just too big a task to even bother starting. Forcing SSL everywhere on everyone is bad for the internet. I don't need to do everything "securely", and I sure as hell don't intend to setup every single experiment I do securely. Make it too much of a hurdle, and maybe I'll just stop experimenting instead. And then, if not the internet, its spirit dies.

deleted 12y ago

[deleted]

fletchowns 12y ago

Anybody know when nginx will support it?

listic 12y ago
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-future-of-seo 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/ 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 http://nginx.org/en/docs/http/ngx_http_spdy_module.html Version 3.1 though... So it's either there or almost there.
- fletchowns 12y ago
  Here's the related thread on the mailing list: http://mailman.nginx.org/pipermail/nginx/2015-February/046583.html http://mailman.nginx.org/pipermail/nginx/2015-February/04658...

striking 12y ago

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 of just hitting the down arrow. Do you honestly think my discussion is worth being silenced?

mrb 12y ago
If that doesn't convince you to support HTTP/2, then nothing will: https://www.httpvshttps.com/ 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://tools.ietf.org/html/draft-ietf-httpbis-http2-16 https://tools.ietf.org/html/draft-ietf-httpbis-http2-16): ENHANCE_YOUR_CALM (0xb): The endpoint detected that its peer is exhibiting a behavior that might be generating excessive load.
- fiatjaf 12y ago
  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.
  - sarciszewski 12y ago
    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!
- striking 12y ago
  I can point you to a benchmark that disagrees. http://www.guypo.com/not-as-spdy-as-you-thought/ 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?

amelius 12y ago

Anybody aware of a good C++ server framework supporting most of HTTP/2, including websockets?

fmela 12y ago
Facebook's proxygen has HTTP/2 support "in progress": https://github.com/facebook/proxygen https://github.com/facebook/proxygen
- amelius 12y ago
  Yes, but I believe they don't support websockets yet. At least, searching their github for "websockets" gives only two broken links. UPDATE: I noticed somebody wrote websocket support [1], but it didn't get merged yet with the master. [1] https://github.com/kekekeks/proxygen https://github.com/kekekeks/proxygen
pornel 12y ago
If you need only realtime push then Server-Sent Events work over HTTP/2.
igrigorik 12y ago
See: https://github.com/http2/http2-spec/wiki/Implementations https://github.com/http2/http2-spec/wiki/Implementations. nghttp2 is solid.

hannob 12y ago

Unfortunately right now apache doesn't support HTTP/2 at all. There was a mod_spdy, but it's pretty much dead. Apache took it over from google some time ago, but since then nothing happened.

josteink 12y ago
This is what happens when you let Google (or other big corporations) write internet-standards. If it isn't community-driven, you can't expect it to be implemented in the places the big corp doesn't care for. So in this case, Apache one of the major drivers for propelling the WWW may end up not supporting a "crucial" WWW-related standard, because the community was never invited. If anyone still has any doubts why letting Google control internet-standards is bad, this is currently my best example. Technically speaking, the internet is the result of what we come up with, when we all work together. Not working together will quickly end up as not working at all.
- netik 12y ago
  I think the reality here is, this is what happens when you let companies fight over a standard in private. What I saw on the HTTP/2 mailing lists was "We have a new standard." "It demands SSL, but we don't want that." Then, SPDY is everywhere, let's use that. Shortly after it was "Omg, we can't call it spdy, because then Microsoft's interests will be left behind and Google will have won. Let's abandon the mandatory SSL requirement and rename SPDY to HTTP2..." I feel like we've all lost here. We implemented SPDY at Twitter - the savings were fantastic and the browser performance, amazing. Google and FB did the same. It's nearly like, 800M users said it was great, can we move on now?

drderidder 12y ago

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 ...]

wmf 12y ago
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.
- josteink 12y ago
  > 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.

xpose2000 12y ago

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)."

derefr 12y ago
Since CloudFlare is an OpenResty (nginx + lua) shop, they'll likely get it as soon as it's in nginx.
- MichaelGG 12y ago
  OpenResty does not include SPDY as there are incompatibilities with it and Lua. But I'm sure CloudFlare has the engineering resources in house to decide what they want to support and when :)
rdl 12y ago
We've been talking about it. I think it's just a question of when.
ropiku 12y ago
Do you know if they support SPDY downstream too ?

jcoffland 12y ago

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.

enneff 12y ago
Pretty much everyone in the industry is on-board with HTTP/2. It's not just Google.

drawkbox 12y ago

HTTP/2 is an ugly mess of taking something simple and making it more complex for minimal benefit. It could have been so much better than a binary mess. As engineers, the ones that take simple concepts and add complexity, those are not engineers, those are meddlers. It could be as long lived as XHTML. I was hoping for more SCTP rather than a bunch of cludge on top of what is a pretty beautiful protocol in HTTP 1.1. Protocol designers of the past seemed to have a better long view mixed with simplicity focused on interoperability that you like to see from engineers.

smegel 12y ago
For those slamming HTTP/2.0, how do they rate SPDY?
- drawkbox 12y ago
  SPDY was great for Google and allowed them to change and take hold of HTTP/2. It saved them lots of money I am sure in improved speed but at the trade-off of complexity and minimal adoption of the standard because it wasn't beneficial to everyone. HTTP/2 is a continuation of that effort by Google which I would do if I were them as well probably. But in the end both are not that big of improvements for what they take away. Of course I use both but I don't think they will last very long until the next, it was too fast and there are large swaths of engineers that do not like being forced into something that has minimal benefits when it could have been a truly nice iteration. HTTP/2 is really closer to SPDY and I wish they would have just kept it as SPDY for now. Let a little more time go by to see if that is truly useful enough to merge into HTTP/2. HTTP/2 is essentially SPDY from Google tweaked and injected into HTTP/2 which has huge benefits for Google, so I understand where the momentum is coming from. Google also controls the browser so it is much easier for them to be the lead now on web standards changes. We will have to use it if we like it or not. I don't like the heavy hand that they are using with their browser share, just like Microsoft of older days (i.e plugins killed off, SPDY, HTTP/2, PPAPI, NaCL etc)
- copsarebastards 12y ago
  SPDY is a great prototype that exemplifies why you should write a prototype: to show the problems with your design. It's unfortunate that the HTTP/2.0 committee decided to ignore the flaws and go with the prototype design.

donatj 12y ago

Can someone explain to me the actual upside of header compression? I work on a fairly major educational site and calculating now our request + response headers comes out to 1,399 bytes. Gzipping them they come out to 1,421 bytes. A small net increase. Am I missing something? Do some people have so many cookies that this makes a difference or something?

cradle 12y ago
As far as I can tell, the compression is separate for the headers, does not use deflate, and (most importantly) is over the entire session, not just one request. This would benefit from the fact that in one request headers are not repeated, but over multiple requests they certainly are. http://www.greenbytes.de/tech/webdav/draft-ietf-httpbis-header-compression-01.html http://www.greenbytes.de/tech/webdav/draft-ietf-httpbis-head...
hacst 12y ago
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 transmitted fields. 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.
- dragonwriter 12y ago
  > 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.
  - ademarre 12y ago
    Doing many requests over the same connection is very common.

est 12y ago

Well how about the fate of the cute little protocol called QUIC?

wmf 12y ago
Maybe QUIC is the prototype for HTTP/4.
- briandh 12y ago
  QUIC is not a replacement for HTTP; it works below it. See https://docs.google.com/document/d/1lmL9EF6qKrk7gbazY8bIdvq3Pno2Xj_l_YShP40GLQE/edit https://docs.google.com/document/d/1lmL9EF6qKrk7gbazY8bIdvq3...
- billyhoffman 12y ago
  I think they want QUIC to be TCP/2. It's design goals around slow start, congestion control, and RTT reduction are squarely aimed at TCP's short comings.

drawkbox 12y ago

HTTP/2 might have version 2 syndrome. Another better way would have been keep SPDY, as there is usefulness there, separate and then on HTTP/2, to incrementally get there, and use an iteration of something like AS2/EDIINT (https://tools.ietf.org/html/rfc4130 https://tools.ietf.org/html/rfc4130) which does encryption, compression and digital signatures on top of existing HTTP (HTTPS is usable as current but not required as it uses best compression/encryption currently available that the server supports). This standard still adheres to everything HTTP and hypertext transfer based and does not become a binary file format but relies on baked in MIME. An iteration of that would have been better for interoperability, secure and fast. I have implemented it directly previously from RFC for an EDI product and it is used for sending all financial EDI/documents for all of the largest companies in the world Wal-mart, Target, DoD as well as most small and medium businesses with inventory. There are even existing interoperability testing centers setup for testing out and certifying products that do this so that the standard works for all vendors and customers. An iteration of this would have fit in as easily and been more flexible on the secure, compression and encryption side, and all over HTTP if you want as it encrypts the body.

UnoriginalGuy 12y ago
I've used AS2 extensively (in EDI) and to be frank, fuck that. AS2 is a really bad version of HTTPS, you take HTTPS, you remove the auto-negotiation (email the certificates!), you disable certification CA checking (self-signed for all the things), and then you allow optional HTTPS on top of AS2 (which is a huge nightmare in its own right). Imagine this scenario, two people want to interconnect, here's the process: - They insecurely email their public key (self-signed) and URL (no MitM protection) - You insecurely email your public key (self-signed) and URL - They have a HTTPS URL - Now the thing to understand about AS2 is that when you connect to THEM you give them a return URL to confirm receipt (MDN) of the transaction. - HTTPS becomes a giant clusterfuck in AS2 because people try to use standard popular HTTPS libraries (e.g. that do CA checking, domain checking, and other checks which are fine for typical web-browser-style traffic, but not for specialised AS2 traffic) but in the context of AS2 where certificates are often local self-signed (some even use this for HTTPS), and the URL is rarely correct for the certificate, they fall over all of the time. - Worse still some sites want to use either HTTP or HTTPS only, so when you connect to a HTTPS URL but give them a HTTP MDN URL sometimes they will work, sometimes they will try the HTTPS version of the URL then fall over and die, and other times they will error just because of the inconsistency. Honestly I used AS2 for over five years, looking back, it would have saved everyone hundreds of man-hours to have just used HTTPS in the standard way and implement certificate pinning (e.g. "e-mail me the serial number," or heck just list it in your documentation). The only major advantage of AS2 is the MDNs. However even there there exists massive inconsistency, some return bad MDNs for bad data, while others only return bad MDNs for bad transmission of data (i.e. they only check that what you send is what is received 1:1, so you could send them a series of 0s and get a valid MDN, because they check the data later and then email). To be honest I hate MDN errors. They don't provide human-readable information in an understandable way. They're designed for automation which rarely exists in the wider world (between millions of different companies with hundreds of systems). Give me an email template for errors any day, that way there can be a brief generic explanation and formatted data, to better explain things. The only thing MDNs do well is data consistency checking which is legitimately nice, however almost every EDI format I know has that in it already (i.e. segment counters, end segments, etc). If I was to re-invent AS2, I'd just build the entire thing on standard HTTPS. No HTTP allowed, no hard coded certificates (i.e. you receive a public key the same way your web browser does), certificate pinning would be a key part, and scrap MDNs in place of a hash as a standard header in the HTTPS stream. Normal HTTP REST return codes would be used to indicate success (e.g. 200 OK/202 ACCEPTED, 400 Md5Mismatch/InvalidInput/etc). That way nobody has to deconstruct an MDN to try and figure out the error. And handling a small handful of HTTP codes is much easier to automate than the information barriage an MDN contains anyway, it is both easier to automate, and easier for humans.

therealmarv 12y ago

Does somebody has good nginx configurations for HTTP/2? Good that browser go this directions but at the moment I have no clue on how to implement HTTP/2 (is there a SPDY fallback?) on my nginx server :(