Details: 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.
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
There's a sudden increase in sites (a doubling) using SPDY. That's when CloudFlare have every single customer free HTTPS and SPDY.
Interestingly Amazon was one of the first non-Google companies to use SPDY. The Silk browser, first shipped in fall of 2011, includes an "acceleration feature." With it Amazon proxies your traffic and does a bunch of one the fly front-end optimizations (gzipping everything, lossless image optimization, giant shared caching proxy, basically a subset what mod_pagespeed can do). SPDY (and now presumably HTTP/2) is used between the tablet and Amazon's data centers.
[0] https://forums.aws.amazon.com/thread.jspa?threadID=90109
The problem is that HTTP2 is basically a competitor, since one of the big value propositions of Cloudfront is that they fix a lot of the broken parts of HTTP. E.g. they achieve big performance improvements by keeping open persistent connections between the CDN and the webserver, which is an issue that HTTP2 ameliorates with multiplexing (since you no longer need a new connection for each static asset).
CloudFront's extra features like keeping the open persistent connection is used for faster requests to the origin and faster edge server cache invalidation. HTTP2's multiplexing would actually help a CDN, since it decreases the load and number of incoming requests for static assets to the edge servers. CDN's are largely paid by bandwidth, and the edges are going to be delivering the same about of content regardless of whether it is transmitted using HTTP1 or HTTP2 (minus a tiny about due to the response header compression feature of HTTP2). So using HTTP2 will reduce there costs while allowing them to charge the same amount (or more make more money if the CDN offers it as an "accelerator service").
In short, HTTP2 is not a competitor to CDN's, even CDN's with fancy "extra" features, because the primary value prop of a CDN is decreasing latency.
Sort of, but we have slow delivery times of our static assets to non-North American locations (round-trip time), thus a CDN with local nodes helps here.
It also reduces the load on our servers, allowing us to focus on serving dynamic content fast, without having to optimize serving static stuff repeatedly -- as we serve a ton of static content and it can hog our bandwidth out of our boxes.