6 ms·

HTTP/2 Adoption Stats

56 points by dedalus 10y ago

bjacobel 10y ago
Looks like isthewebhttp2yet.com, isn't HTTP/2 yet. $> curl --head http://isthewebhttp2yet.com HTTP/1.1 200 OK x-amz-id-2: GXE1k2FX9Wmpzdjer4hI7lmA7LK/Znlo6dN6/qUdOVSjb95g+VaDGL6EB6QODo+cv3QNkvTZcIc= x-amz-request-id: 51C2129F4B496C03 Date: Sat, 23 Apr 2016 16:35:29 GMT Last-Modified: Tue, 05 Apr 2016 15:12:25 GMT ETag: "543317ac1e885c2039b13925f35afdd3" Content-Type: text/html Content-Length: 9793 Server: AmazonS3 Not to imply this is their fault - I wish S3 (and Cloudfront) would support HTTP/2 but that day is probably a long ways off. However, I've used Caddy[1] for hosting static files with HTTP2 and free TLS via Let's Encrypt and had a really great experience with it - might be something to look into. [1]: https://caddyserver.com https://caddyserver.com
- imperalix 10y ago
  Look like http2 support for cloudfront is coming soon[1]. https://forums.aws.amazon.com/message.jspa?messageID=708630#708630 https://forums.aws.amazon.com/message.jspa?messageID=708630#...
  - bjacobel 10y ago
    Whoa, that's awesome. I'm familiar with that forum thread (haha) but I didn't realize there'd been a response on it from an AWS employee just in the last couple of weeks.
- nsgi 10y ago
  They could at least support HTTPS though, given that it's trivial to enable on Cloudfront using AWS Certificate Manager.
sandstrom 10y ago
I wish AWS would adopt HTTP/2 quickly (for Elastic Load Balancer). Hopefully AWS IPv6 adoption isn't any indication of how fast they'll get to HTTP/2.
- meddlepal 10y ago
  This is one of the really frustrating things about AWS... you have no sense of their product roadmap. My guess is the biggest customers will be drivers of HTTP 2.x support for ELB, for example a Netflix. On that note though, can you pump HTTP 2.0 traffic through a TCP listener? I haven't tried.
  - Confiks 10y ago
    > On that note though, can you pump HTTP 2.0 traffic through a TCP listener? I haven't tried. Yes, we're using that right now with Proxy Protocol to see the original requester. When using a TCP listener, you're of course free to use any TCP protocol of your choosing, including HTTP/2. A consequence is that you have to terminate TLS at the webserver instead of at the load balancer.
  - anderspetersson 10y ago
    If I'm not incorrectly informed AWS is using a modified HAProxy. HAProxy does not support HTTP/2 yet so yeah, it will probably take some time.
yeaaaaaaaaah 10y ago
My website will not be adopting HTTP/2.
- rprime 10y ago
  Did you just register to post that?
- ancarda 10y ago
  Why not?
  - darkhorn 10y ago
    Because HTTP/2 doesn't support client side certificates. For this reason his bank's web site won't serve with HTTP/2.
    - euyyn 10y ago
      But HTTP/2 does support client certificates.
tete 10y ago
Honest question: After reading PHK's (creator of Varnish) "rant" on HTTP/2[1] what are some good reasons for using this protocol? Yes, there is TCP Multiplexing, but isn't the normal keep alive good enough in most cases? And doesn't HTTP/2 make good caching harder? The fact that HTTP/2 takes more computing resources to parse, given the fact that it's binary seems counter productive. Am I too negative? Am I missing something? I barely know anything about HTTP/2, but it's hard to find good answer to these question. Hoping someone can help with that and maybe get an idea about whether a migration to HTTP/2 is really worthwhile - or in which cases it actually is. [1] https://queue.acm.org/detail.cfm?id=2716278 https://queue.acm.org/detail.cfm?id=2716278
- Matthias247 10y ago
  Regarding reasons for using the protocol: It will indeed make HTTP faster in most cases, because of the dropped need to create a new TCP/TLS connection for each request. Yes, pipelined HTTP/1.1 and connection pools could that too to a little extend, but browsers and other applications had limitations on how much connections and therefore parallel requests could be made, which were quite low compared to todays need. With HTTP/2 one connection is sufficient for everything. With HTTP/2 you can now do also things like creating 200 parallel SSE connections to a server to receive events with low overhead. This was neither possible with HTTP/1.1 (where browsers would limit to you 8 or something like that connections) nor efficient. But once again - this was a browser limitation, not necessarily an HTTP/1.1 one. Regarding caching I don't see a difference, as the caching happens on a higher layer. I have implemented HTTP/2 to about 65% for myself. I think the protocol is mostly OKish. It can be implemented with a reasonable effort (assuming you have a very good understanding of protocol implementation in general - there's more chances to fuck up in it than in HTTP/1.1) and should provide a reasonable performance. There is some stuff in there which I don't like e.g. race conditions during SETTINGs negotiation, the question why strings can be encoded with and without huffman encoding and the use of default frame sizes which make it less suitable for embedded devices (where it would otherwise be much better than HTTP/1.1). But in the meantime I came to the conclusion that there are no perfect protocols - all of them have some strange things incorporated, because somebody involved in standardization has a usecase for it and a consent needs to be reached. I didn't came to a complete conclusion regarding the required computing resources. On the one hand header handling is a lot more efficient (no need to search for line breaks, etc.). But the stream multiplexing might require an additional memory copy operation (from the received socket payload into the buffer that is dedicated for that stream) depending on the architecture of the library. Need to do some benchmarking on that. However benchmarking for HTTP/2 is difficult, because it's currently mostly deployed with TLS (and many libraries and tools only support HTTP/2 with TLS and not the h2c variant), which affects all results.
homero 10y ago
CloudFlare is the only reason these technologies get quick adoption, kudos
rspeer 10y ago
This link points to the "structure" graphs instead of the "adoption" graphs. It shows some unnecessarily difficult-to-interpret graphs about the structure of pages served with and without HTTP/2. The fact that the graphs are going dramatically up and to the right is a consequence of the fact that they are cumulative graphs. Keep in mind that none of these axes represent time. I believe the link was supposed to be http://isthewebhttp2yet.com/measurements/adoption.html http://isthewebhttp2yet.com/measurements/adoption.html .

56 points by dedalus 10y ago

Looks like isthewebhttp2yet.com, isn't HTTP/2 yet. $> curl --head http://isthewebhttp2yet.com HTTP/1.1 200 OK x-amz-id-2: GXE1k2FX9Wmpzdjer4hI7lmA7LK/Znlo6dN6/qUdOVSjb95g+VaDGL6EB6QODo+cv3QNkvTZcIc= x-amz-request-id: 51C2129F4B496C03 Date: Sat, 23 Apr 2016 16:35:29 GMT Last-Modified: Tue, 05 Apr 2016 15:12:25 GMT ETag: "543317ac1e885c2039b13925f35afdd3" Content-Type: text/html Content-Length: 9793 Server: AmazonS3 Not to imply this is their fault - I wish S3 (and Cloudfront) would support HTTP/2 but that day is probably a long ways off. However, I've used Caddy[1] for hosting static files with HTTP2 and free TLS via Let's Encrypt and had a really great experience with it - might be something to look into. [1]: https://caddyserver.com https://caddyserver.com

imperalix 10y ago
Look like http2 support for cloudfront is coming soon[1]. https://forums.aws.amazon.com/message.jspa?messageID=708630#708630 https://forums.aws.amazon.com/message.jspa?messageID=708630#...
- bjacobel 10y ago
  Whoa, that's awesome. I'm familiar with that forum thread (haha) but I didn't realize there'd been a response on it from an AWS employee just in the last couple of weeks.
nsgi 10y ago
They could at least support HTTPS though, given that it's trivial to enable on Cloudfront using AWS Certificate Manager.

sandstrom 10y ago

I wish AWS would adopt HTTP/2 quickly (for Elastic Load Balancer). Hopefully AWS IPv6 adoption isn't any indication of how fast they'll get to HTTP/2.

meddlepal 10y ago
This is one of the really frustrating things about AWS... you have no sense of their product roadmap. My guess is the biggest customers will be drivers of HTTP 2.x support for ELB, for example a Netflix. On that note though, can you pump HTTP 2.0 traffic through a TCP listener? I haven't tried.
- Confiks 10y ago
  > On that note though, can you pump HTTP 2.0 traffic through a TCP listener? I haven't tried. Yes, we're using that right now with Proxy Protocol to see the original requester. When using a TCP listener, you're of course free to use any TCP protocol of your choosing, including HTTP/2. A consequence is that you have to terminate TLS at the webserver instead of at the load balancer.
- anderspetersson 10y ago
  If I'm not incorrectly informed AWS is using a modified HAProxy. HAProxy does not support HTTP/2 yet so yeah, it will probably take some time.

yeaaaaaaaaah 10y ago

My website will not be adopting HTTP/2.

rprime 10y ago
Did you just register to post that?
ancarda 10y ago
Why not?
- darkhorn 10y ago
  Because HTTP/2 doesn't support client side certificates. For this reason his bank's web site won't serve with HTTP/2.
  - euyyn 10y ago
    But HTTP/2 does support client certificates.

tete 10y ago

Honest question: After reading PHK's (creator of Varnish) "rant" on HTTP/2[1] what are some good reasons for using this protocol? Yes, there is TCP Multiplexing, but isn't the normal keep alive good enough in most cases? And doesn't HTTP/2 make good caching harder? The fact that HTTP/2 takes more computing resources to parse, given the fact that it's binary seems counter productive. Am I too negative? Am I missing something? I barely know anything about HTTP/2, but it's hard to find good answer to these question. Hoping someone can help with that and maybe get an idea about whether a migration to HTTP/2 is really worthwhile - or in which cases it actually is. [1] https://queue.acm.org/detail.cfm?id=2716278 https://queue.acm.org/detail.cfm?id=2716278

Matthias247 10y ago
Regarding reasons for using the protocol: It will indeed make HTTP faster in most cases, because of the dropped need to create a new TCP/TLS connection for each request. Yes, pipelined HTTP/1.1 and connection pools could that too to a little extend, but browsers and other applications had limitations on how much connections and therefore parallel requests could be made, which were quite low compared to todays need. With HTTP/2 one connection is sufficient for everything. With HTTP/2 you can now do also things like creating 200 parallel SSE connections to a server to receive events with low overhead. This was neither possible with HTTP/1.1 (where browsers would limit to you 8 or something like that connections) nor efficient. But once again - this was a browser limitation, not necessarily an HTTP/1.1 one. Regarding caching I don't see a difference, as the caching happens on a higher layer. I have implemented HTTP/2 to about 65% for myself. I think the protocol is mostly OKish. It can be implemented with a reasonable effort (assuming you have a very good understanding of protocol implementation in general - there's more chances to fuck up in it than in HTTP/1.1) and should provide a reasonable performance. There is some stuff in there which I don't like e.g. race conditions during SETTINGs negotiation, the question why strings can be encoded with and without huffman encoding and the use of default frame sizes which make it less suitable for embedded devices (where it would otherwise be much better than HTTP/1.1). But in the meantime I came to the conclusion that there are no perfect protocols - all of them have some strange things incorporated, because somebody involved in standardization has a usecase for it and a consent needs to be reached. I didn't came to a complete conclusion regarding the required computing resources. On the one hand header handling is a lot more efficient (no need to search for line breaks, etc.). But the stream multiplexing might require an additional memory copy operation (from the received socket payload into the buffer that is dedicated for that stream) depending on the architecture of the library. Need to do some benchmarking on that. However benchmarking for HTTP/2 is difficult, because it's currently mostly deployed with TLS (and many libraries and tools only support HTTP/2 with TLS and not the h2c variant), which affects all results.

homero 10y ago

CloudFlare is the only reason these technologies get quick adoption, kudos

rspeer 10y ago

This link points to the "structure" graphs instead of the "adoption" graphs. It shows some unnecessarily difficult-to-interpret graphs about the structure of pages served with and without HTTP/2. The fact that the graphs are going dramatically up and to the right is a consequence of the fact that they are cumulative graphs. Keep in mind that none of these axes represent time. I believe the link was supposed to be http://isthewebhttp2yet.com/measurements/adoption.html http://isthewebhttp2yet.com/measurements/adoption.html .