The state and rate of HTTP/2 adoption
daniel.haxx.se
daniel.haxx.se
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.
- 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)?
- 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=preloadExcept for other applications trying to use the finite, and possibly expensive, bandwidth of the connection as a whole?
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.
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.
My biggest concern with HTTP/2 is that it's going to be difficult for web applications to organize their server push requests. It seems like it will definitely require updates to server app frameworks to make this tractable.
1. https://nghttp2.org/blog/2015/02/10/nghttp2-dot-org-enabled-... 2. https://code.google.com/p/mod-spdy/wiki/OptimizingForSpdy
The relevant mechanism seems to be described here: https://http2.github.io/http2-spec/#PushResponses
[1]: By some criteria. I don't have details here.
As I understand it, the more latent the connection the worse the behaviour (i.e., the more likely you are to receive too much data you don't need).
In future posts of similar nature I suggest clarifying visualizations with labels, or moving the legend much closer to the chart.
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... [2] http://eclipse.org/jetty/documentation/current/alpn-chapter....
http://visualstudio.uservoice.com/forums/121579-visual-studi...
http://blog.geog.co/post/111535045146/our-thoughts-on-http2
Also, is that article from the Author of cURL? We <3 cURL!
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.
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.
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.
We're definitely looking at non-NIST algorithms, we've just had enough of those.
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.
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.