9 ms·

The state and rate of HTTP/2 adoption

87 points by kryptiskt 12y ago

guilt 12y ago
We've decided that HTTP/2 may not be a great fit at its present state, and here's why we thought so: http://blog.geog.co/post/111535045146/our-thoughts-on-http2 http://blog.geog.co/post/111535045146/our-thoughts-on-http2 Also, is that article from the Author of cURL? We <3 cURL!
- AlyssaRowan 12y ago
  No, you don't need a HTTP request to upgrade: it's done as part of the TLS negotiation with ALPN. No extra round trips, and TLS 1.3 will probably go even faster. If you're not using TLS, despite things like the China QUANTUM attack on Baidu against Github, I don't know what to say to you, except most browsers already chose to refuse to speak HTTP/2 over cleartext, because using cleartext in 2015 is a bad idea in almost any scenario.
  - guilt 12y ago
    If we don't support TLS, doesn't mean we don't care about E2E Encrypted Data, or E2H Encrypted Data, or Signed Data. I do understand how the system works - and I've seen ISPs issue fake real certificates (which CA issues Google's certificate?) and I think sometimes, you just have to do it deeper, and yourself, if you have to do it right.
    - 001spartan 12y ago
      I hope I'm parsing this statement incorrectly, but it seems as though you're rolling your own solution to authentication and encryption, rather than using TLS. According to your organization's website, you're an IoT platform. That's terrifying, honestly. I hope I'm misinterpreting something.
      - AlyssaRowan 12y ago
        A Cortex-M0+ core - which is a really tiny microcontroller - can do TLS 1.2 just fine (using the AES-CCM AEAD instead of the AES-GCM AEAD helps somewhat, apparently: I've not tried to implement it myself, so I'm not clear precisely why, but it's probably GHASH). With enough work, an 8-bit class chip with a couple kilobytes of RAM could implement a constrained subset. If that's somehow still too heavy, I'm not sure how. I hope they can find a way to make TLS 1.3 work for their IoT scenarios: CHACHA20_POLY1305 and Curve25519 will also hopefully help, quite a lot. They're as small as they are fast.
        guilt 12y ago
        For AEAD, We'd most likely look at ChaCha20(Poly1305(Text)+Text) and I think that's a great idea. :) We're definitely looking at non-NIST algorithms, we've just had enough of those.
    - teraflop 12y ago
      If you don't support TLS, then browsers won't connect to you using HTTP/2 anyway, so it's a moot point.
- bagder 12y ago
  Yes it is indeed by the author of curl! (me ;-)
  - guilt 12y ago
    It's been an honour meeting you here! Thank you for cURL! :)
- acdha 12y ago
  The bit about HTTP 1 is only true without TLS: https://http2.github.io/faq/#can-i-implement-http2-without-implementing-http11 https://http2.github.io/faq/#can-i-implement-http2-without-i... This bit is also mostly wrong: “However, the problems with HTTP2 are not because of HTTP2 itself, but because of the heavier costs of provisioning and maintaining healthy infrastructure that can afford to keep stateful long TCP/IP sessions by themselves.” That's already been the case with HTTP 1 keep-alives and even more so with web sockets and unlike in the late 90s it's just not an issue for the vast majority of services. That said, HTTP/2 also has no requirement that you keep a connection open after you're done with the request – the specification clearly states that either end can cleanly close the connection at any point. A browser might choose to implement something similar to the traditional keep-alive timer but there's no reason why you can't make a single request or close the connection immediately after a fetching a single round of resources. The only difference is that this process is both faster and more reliable than it was with HTTP 1 keep-alives & pipelining.
  - guilt 12y ago
    Yes - and I'd say WebSockets have been sucking the juice out of the DataCenter if your clients are mostly idling! I'm not disagreeing with you here. Our point was that HTTP 2's features start doing amazing things after the first request, now that they have a connection going. Do read that we are excited about what it brings - just not for the very first request itself. And honestly, if they changed that, we'd be a happier lot.
    - acdha 12y ago
      Even that first request benefits from things like header compression and the more efficient encoding. The big win, however, if you are making an API client is that you can connect and immediately send all of our requests without needing to issue them sequentially. If your API design in the past has needed to prepare combined responses to reduce latency that can a pretty big win.
userbinator 12y ago
I bet HTTP/1.0 is going to remain around for a long time too - HTTP is being used for far more purposes than to serve webpages, and especially with things like industrial equipment control/status there is little need to upgrade (and risk introducing new bugs) an existing working implementation.
bhouston 12y ago
I think the floodgates will open once there is a http2 module for nginx. We are still on spdy/3 because of this. Details: http://nginx.com/blog/how-nginx-plans-to-support-http2/ http://nginx.com/blog/how-nginx-plans-to-support-http2/ I think it would be amazing for the CDNs, especially Amazon, to support HTTP2. But I've heard mostly silence from Amazon -- Cloudfront doesn't even support SPDY, which I though would have been useful already at this point.
- jgrahamc 12y ago
  From CloudFlare's perspective we currently support SPDY for all customers and will support HTTP/2 once NGINX with it becomes available. We are committed to support for new protocols for all customers. We've rolled out SPDY, IPv6, HSTS, HTTPS (free certs) for all and are close to adding DNSSEC and will add HTTP/2. We're not waiting for these things to gain traction. To give you an idea of what we are doing and the impact take a look at this chart of SPDY deployment. http://w3techs.com/technologies/details/ce-spdy/all/all http://w3techs.com/technologies/details/ce-spdy/all/all There's a sudden increase in sites (a doubling) using SPDY. That's when CloudFlare have every single customer free HTTPS and SPDY.
  - bagder 12y ago
    That's excellent to hear, thanks! If you have a public URL with such a statement I'd link to it from the post... (hint hint) =)
    - jgrahamc 12y ago
      I'm CloudFlare's "CTO". Link to that comment above.
  - e911 12y ago
    Will WebSockets also be supported for all customers?
    - jgrahamc 12y ago
teamhappy 12y ago
Kinda sad to hear vendors say they'll support it once it gets traction. How is it supposed to get traction if it's not available to users?
- jimjag 12y ago
  Well, most of these projects are real open source projects, in which resources are somewhat sparse, and so new features and additions need to be prioritized. There is still some question regarding just how "good" http/2 really is. The complexity of http/2, as well as the fact that it really doesn't "fix" a lot of the problems in http/1.1, means that its universal applicability is still very much in question.
vkjv 12y ago
I am looking forward to wide-scale HTTP/2 adoption. It means you can take something simple like gRPC (http://www.grpc.io/ http://www.grpc.io/) and suddenly scale it with commodity things like an HTTP load balancer.
tibbon 12y ago
I really wish Heroku would support http2/spdy easily without the use of clunky buildpacks that I never really trust fully in production.
- bgentry 12y ago
  Even with buildpacks, there's essentially no way to use HTTP/2 or SPDY on Heroku until their HTTP router and load balancer stack supports it. Buildpacks can't really change that.
strommen 12y ago
I'm reasonably up-to-date on HTTP/2, but there are a couple issues with request multiplexing and server push that I'm confused about: - When the browser requests a page, and the server wants to push the CSS, JS, etc. along with it, what happens if the CSS/JS is cached already on the client? - Additionally, how does a server like nginx know what to "push"? Are servers expected to parse the script and link tags from the outgoing html? Or is this controlled by the application (and if so, how)?
- FooBarWidget 12y ago
  Maybe the browser can send a header "Cache-Control: allowpush" that tells the server that the site is not in cache. The server can then push everything. I can't see how server push is useful without client cooperation, unless the resource changes dynamically.
  - brlewis 12y ago
    If-Modified-Since would already do that. But how does the client know that page B that it never requested has all the same CSS/JS as page A that it recently requested?
- maggit 12y ago
  As I've heard it explained, the server will push what it thinks is relevant [1] and if the resource is already cached in the client, the client will ask the server to stop the push. The relevant mechanism seems to be described here: https://http2.github.io/http2-spec/#PushResponses https://http2.github.io/http2-spec/#PushResponses [1]: By some criteria. I don't have details here.
  - strommen 12y ago
    That's my understanding as well, but it's pretty fuzzy. How does the client stop the push, and what are the performance implications of this? Pages currently include dozens of external resources, and this will get worse if developers stop using bundles and sprites (because in theory HTTP/2 makes them pointless).
needusername 12y ago
Java support for APLN [1] requires replacing JDK classes [2]. That may be fixed with Java SE 9. Which means EE 9 for the servlet API. OTOH in don't expect enterprise snake oil to support HTTP/2 anytime soon. [1] http://lists.jboss.org/pipermail/wildfly-dev/2015-January/003497.html http://lists.jboss.org/pipermail/wildfly-dev/2015-January/00... [2] http://eclipse.org/jetty/documentation/current/alpn-chapter.html#alpn-versions http://eclipse.org/jetty/documentation/current/alpn-chapter....
- strommen 12y ago
  Similar story on the .NET side: there's a UserVoice item for "Add support for ALPN to System.Net.Security.SslStream". It's on Page 12, just behind "Improve UI for 2015 Microsoft Test Manager Client User Experience". http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/6264363-add-support-for-alpn-to-system-net-security-sslstr http://visualstudio.uservoice.com/forums/121579-visual-studi...
timme 12y ago
Good post, but that pie chart, man. In future posts of similar nature I suggest clarifying visualizations with labels, or moving the legend much closer to the chart.

87 points by kryptiskt 12y ago

guilt 12y ago

We've decided that HTTP/2 may not be a great fit at its present state, and here's why we thought so: http://blog.geog.co/post/111535045146/our-thoughts-on-http2 http://blog.geog.co/post/111535045146/our-thoughts-on-http2 Also, is that article from the Author of cURL? We <3 cURL!

AlyssaRowan 12y ago
No, you don't need a HTTP request to upgrade: it's done as part of the TLS negotiation with ALPN. No extra round trips, and TLS 1.3 will probably go even faster. If you're not using TLS, despite things like the China QUANTUM attack on Baidu against Github, I don't know what to say to you, except most browsers already chose to refuse to speak HTTP/2 over cleartext, because using cleartext in 2015 is a bad idea in almost any scenario.
- guilt 12y ago
  If we don't support TLS, doesn't mean we don't care about E2E Encrypted Data, or E2H Encrypted Data, or Signed Data. I do understand how the system works - and I've seen ISPs issue fake real certificates (which CA issues Google's certificate?) and I think sometimes, you just have to do it deeper, and yourself, if you have to do it right.
  - 001spartan 12y ago
    I hope I'm parsing this statement incorrectly, but it seems as though you're rolling your own solution to authentication and encryption, rather than using TLS. According to your organization's website, you're an IoT platform. That's terrifying, honestly. I hope I'm misinterpreting something.
    - AlyssaRowan 12y ago
      A Cortex-M0+ core - which is a really tiny microcontroller - can do TLS 1.2 just fine (using the AES-CCM AEAD instead of the AES-GCM AEAD helps somewhat, apparently: I've not tried to implement it myself, so I'm not clear precisely why, but it's probably GHASH). With enough work, an 8-bit class chip with a couple kilobytes of RAM could implement a constrained subset. If that's somehow still too heavy, I'm not sure how. I hope they can find a way to make TLS 1.3 work for their IoT scenarios: CHACHA20_POLY1305 and Curve25519 will also hopefully help, quite a lot. They're as small as they are fast.
      - guilt 12y ago
        For AEAD, We'd most likely look at ChaCha20(Poly1305(Text)+Text) and I think that's a great idea. :) We're definitely looking at non-NIST algorithms, we've just had enough of those.
  - teraflop 12y ago
    If you don't support TLS, then browsers won't connect to you using HTTP/2 anyway, so it's a moot point.
bagder 12y ago
Yes it is indeed by the author of curl! (me ;-)
- guilt 12y ago
  It's been an honour meeting you here! Thank you for cURL! :)
acdha 12y ago
The bit about HTTP 1 is only true without TLS: https://http2.github.io/faq/#can-i-implement-http2-without-implementing-http11 https://http2.github.io/faq/#can-i-implement-http2-without-i... This bit is also mostly wrong: “However, the problems with HTTP2 are not because of HTTP2 itself, but because of the heavier costs of provisioning and maintaining healthy infrastructure that can afford to keep stateful long TCP/IP sessions by themselves.” That's already been the case with HTTP 1 keep-alives and even more so with web sockets and unlike in the late 90s it's just not an issue for the vast majority of services. That said, HTTP/2 also has no requirement that you keep a connection open after you're done with the request – the specification clearly states that either end can cleanly close the connection at any point. A browser might choose to implement something similar to the traditional keep-alive timer but there's no reason why you can't make a single request or close the connection immediately after a fetching a single round of resources. The only difference is that this process is both faster and more reliable than it was with HTTP 1 keep-alives & pipelining.
- guilt 12y ago
  Yes - and I'd say WebSockets have been sucking the juice out of the DataCenter if your clients are mostly idling! I'm not disagreeing with you here. Our point was that HTTP 2's features start doing amazing things after the first request, now that they have a connection going. Do read that we are excited about what it brings - just not for the very first request itself. And honestly, if they changed that, we'd be a happier lot.
  - acdha 12y ago
    Even that first request benefits from things like header compression and the more efficient encoding. The big win, however, if you are making an API client is that you can connect and immediately send all of our requests without needing to issue them sequentially. If your API design in the past has needed to prepare combined responses to reduce latency that can a pretty big win.

userbinator 12y ago

I bet HTTP/1.0 is going to remain around for a long time too - HTTP is being used for far more purposes than to serve webpages, and especially with things like industrial equipment control/status there is little need to upgrade (and risk introducing new bugs) an existing working implementation.

bhouston 12y ago

I think the floodgates will open once there is a http2 module for nginx. We are still on spdy/3 because of this. Details: http://nginx.com/blog/how-nginx-plans-to-support-http2/ http://nginx.com/blog/how-nginx-plans-to-support-http2/ I think it would be amazing for the CDNs, especially Amazon, to support HTTP2. But I've heard mostly silence from Amazon -- Cloudfront doesn't even support SPDY, which I though would have been useful already at this point.

jgrahamc 12y ago
From CloudFlare's perspective we currently support SPDY for all customers and will support HTTP/2 once NGINX with it becomes available. We are committed to support for new protocols for all customers. We've rolled out SPDY, IPv6, HSTS, HTTPS (free certs) for all and are close to adding DNSSEC and will add HTTP/2. We're not waiting for these things to gain traction. To give you an idea of what we are doing and the impact take a look at this chart of SPDY deployment. http://w3techs.com/technologies/details/ce-spdy/all/all http://w3techs.com/technologies/details/ce-spdy/all/all There's a sudden increase in sites (a doubling) using SPDY. That's when CloudFlare have every single customer free HTTPS and SPDY.
- bagder 12y ago
  That's excellent to hear, thanks! If you have a public URL with such a statement I'd link to it from the post... (hint hint) =)
  - jgrahamc 12y ago
    I'm CloudFlare's "CTO". Link to that comment above.
- e911 12y ago
  Will WebSockets also be supported for all customers?
  - jgrahamc 12y ago

teamhappy 12y ago

Kinda sad to hear vendors say they'll support it once it gets traction. How is it supposed to get traction if it's not available to users?

jimjag 12y ago
Well, most of these projects are real open source projects, in which resources are somewhat sparse, and so new features and additions need to be prioritized. There is still some question regarding just how "good" http/2 really is. The complexity of http/2, as well as the fact that it really doesn't "fix" a lot of the problems in http/1.1, means that its universal applicability is still very much in question.

vkjv 12y ago

I am looking forward to wide-scale HTTP/2 adoption. It means you can take something simple like gRPC (http://www.grpc.io/ http://www.grpc.io/) and suddenly scale it with commodity things like an HTTP load balancer.

tibbon 12y ago

I really wish Heroku would support http2/spdy easily without the use of clunky buildpacks that I never really trust fully in production.

bgentry 12y ago
Even with buildpacks, there's essentially no way to use HTTP/2 or SPDY on Heroku until their HTTP router and load balancer stack supports it. Buildpacks can't really change that.

strommen 12y ago

I'm reasonably up-to-date on HTTP/2, but there are a couple issues with request multiplexing and server push that I'm confused about: - When the browser requests a page, and the server wants to push the CSS, JS, etc. along with it, what happens if the CSS/JS is cached already on the client? - Additionally, how does a server like nginx know what to "push"? Are servers expected to parse the script and link tags from the outgoing html? Or is this controlled by the application (and if so, how)?

FooBarWidget 12y ago
Maybe the browser can send a header "Cache-Control: allowpush" that tells the server that the site is not in cache. The server can then push everything. I can't see how server push is useful without client cooperation, unless the resource changes dynamically.
- brlewis 12y ago
  If-Modified-Since would already do that. But how does the client know that page B that it never requested has all the same CSS/JS as page A that it recently requested?
maggit 12y ago
As I've heard it explained, the server will push what it thinks is relevant [1] and if the resource is already cached in the client, the client will ask the server to stop the push. The relevant mechanism seems to be described here: https://http2.github.io/http2-spec/#PushResponses https://http2.github.io/http2-spec/#PushResponses [1]: By some criteria. I don't have details here.
- strommen 12y ago
  That's my understanding as well, but it's pretty fuzzy. How does the client stop the push, and what are the performance implications of this? Pages currently include dozens of external resources, and this will get worse if developers stop using bundles and sprites (because in theory HTTP/2 makes them pointless).

needusername 12y ago

Java support for APLN [1] requires replacing JDK classes [2]. That may be fixed with Java SE 9. Which means EE 9 for the servlet API. OTOH in don't expect enterprise snake oil to support HTTP/2 anytime soon. [1] http://lists.jboss.org/pipermail/wildfly-dev/2015-January/003497.html http://lists.jboss.org/pipermail/wildfly-dev/2015-January/00... [2] http://eclipse.org/jetty/documentation/current/alpn-chapter.html#alpn-versions http://eclipse.org/jetty/documentation/current/alpn-chapter....

strommen 12y ago
Similar story on the .NET side: there's a UserVoice item for "Add support for ALPN to System.Net.Security.SslStream". It's on Page 12, just behind "Improve UI for 2015 Microsoft Test Manager Client User Experience". http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/6264363-add-support-for-alpn-to-system-net-security-sslstr http://visualstudio.uservoice.com/forums/121579-visual-studi...

timme 12y ago

Good post, but that pie chart, man. In future posts of similar nature I suggest clarifying visualizations with labels, or moving the legend much closer to the chart.