
The state and rate of HTTP/2 adoption - kryptiskt
http://daniel.haxx.se/blog/2015/03/31/the-state-and-rate-of-http2-adoption/
======
bhouston
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
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
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
I'm CloudFlare's "CTO". Link to that comment above.

------
strommen
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)?

~~~
pornel
\- The client can stop an incoming push (send reset on the pushed stream). Due
to latency it might waste some bandwidth, but it's deemed to be an
insignificant problem, since otherwise nothing else would be using the
connection anyway.

\- It's independent of the protocol. Each server can invent its own method.
Personally I'm hoping servers/proxies will "upgrade" some HTTP/1.1 Link header
to PUSH, e.g.:

    
    
        Link: </style.css>; rel=preload

~~~
lucaspiller
> Due to latency it might waste some bandwidth, but it's deemed to be an
> insignificant problem, since otherwise nothing else would be using the
> connection anyway

That sounds like it could be an issue on mobile devices. If I've got a 1GB
data plan, I don't want you sending large files that I've already got cached.
Even partially sending them could consume significant bandwidth given the
latency involved.

~~~
bgentry
HTTP/2's flow control offers a bit of a solution here for mobile devices. Flow
control operates on a credits/tokens scheme at both the connection level and
the stream level. A mobile client could use a low initial window size so that
all new streams are limited in how much data they can send. The client can
preemptively grant large flow control windows to streams that it requests, and
retroactively grant additional credits to push streams that it decides it
wants.

The tradeoff is that you're introducing a round-trip for pushed resources to
acknowledge that you want to receive the entire resource. That may or may not
make sense, depending on the use case.

[http://http2.github.io/http2-spec/#FlowControl](http://http2.github.io/http2-spec/#FlowControl)

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

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

------
needusername
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/00...](http://lists.jboss.org/pipermail/wildfly-
dev/2015-January/003497.html) [2]
[http://eclipse.org/jetty/documentation/current/alpn-
chapter....](http://eclipse.org/jetty/documentation/current/alpn-
chapter.html#alpn-versions)

~~~
strommen
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-
studi...](http://visualstudio.uservoice.com/forums/121579-visual-
studio/suggestions/6264363-add-support-for-alpn-to-system-net-security-sslstr)

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

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

~~~
bgentry
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.

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

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

