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.
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.
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.
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.
“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.
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.
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.
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.
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.
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.
What about content push? Will CloudFlare only do passthrough of pushes from HTTP/2 servers, will it support extended HTTP/1.1 headers as described in https://news.ycombinator.com/item?id=9296526, or will it add content pushes based on parsing the HTML if optimizations are turned on?
How would a CDN take advantage of the features of HTTP? Will they be able to use server-push? or will using HTTP2 just create more overhead because clients will connect, upgrade, request, get file, close. rinse-wash-repeat?
I can only speak for CloudFlare, but we are planning to look into how to use Server Push to help our clients. Since we'll have assets in cache we can push them to clients quickly and it'll be a question of deciding/predicting what to push and when.
> I think it would be amazing for the CDNs, especially Amazon, to support HTTP2.
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).
> one of the big value propositions of Cloudfront is that they fix a lot of the broken parts of HTTP
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.
The valuable proposition of a CDN is to improve load times by decreasing latency via geographically distributed servers. HTTP2 doesn't diminish this value.
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.
Obviously you'll still want to use a CDN even with HTTP2 for the reasons you mention. However, with HTTP2 I see Cloudfront as being less differentiated from any other CDN.
Also, having a larger base of users that have browsers that support HTTP2 will make it a higher priority for devs to modify their servers to utilize HTTP2.
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.
I've been watching this open feature request[0] to add SPDY support for AWS ELB. Been open since 2012 and hasn't seen any real response from Amazon. Very disappointing. ELB is pretty much a given for any publicly-facing web service running on AWS.
Now that is strange, since Amazon specifically touted that Silk was being powered by EC2 instances. Almost certainly they are using a load balancer. Perhaps they rolled their own.
It'd also be nice if Microsoft shipped an easy-to-install plugin for IIS. I know, I know, they have this ... design ... where that handling is done by HTTP.SYS in the kernel. But their technical decisions like that shouldn't impact how they deliver updates.
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.
I am looking forward to wide-scale HTTP/2 adoption. It means you can take something simple like gRPC (http://www.grpc.io/) and suddenly scale it with commodity things like an HTTP load balancer.
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.
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)?
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.
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?
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.
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).
- 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.:
> 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.
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.
Okay, thanks. It looks like nghttp2 uses the Link header[1] as you suggest, and mod_spdy uses a "X-Associated-Content" header[2].
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.
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".
53 comments
[ 4.8 ms ] story [ 119 ms ] threadhttp://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.
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.
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).
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.
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.
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
- 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)?
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).
- 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.:
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.
http://http2.github.io/http2-spec/#FlowControl
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
Except for other applications trying to use the finite, and possibly expensive, bandwidth of the connection as a whole?
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...
In future posts of similar nature I suggest clarifying visualizations with labels, or moving the legend much closer to the chart.