18 ms·

Yesterday's best-practices are today's HTTP/2 anti-patterns

221 points by vladaionescu 11y ago

vladaionescu 11y ago
The chapter in the book goes over more details: http://chimera.labs.oreilly.com/books/1230000000545/ch12.html http://chimera.labs.oreilly.com/books/1230000000545/ch12.htm...
0x006A 11y ago
what are the current http/2 server options?
- vladaionescu 11y ago
  As far as I understand, none for production use. I see that nginx implements SPDY (HTTP2 is based on SPDY), but not yet HTTP2. They promise to bring HTTP2 by end of year though - http://nginx.com/blog/how-nginx-plans-to-support-http2/ http://nginx.com/blog/how-nginx-plans-to-support-http2/ .
- shurcooL 11y ago
  Caddy looks like a good choice. https://caddyserver.com/ https://caddyserver.com/
- tootie 11y ago
  Undertow and Jetty are both Java options that support HTTP/2. I've been playing with both and it's still very rough around the edges (have to mess with bootpath to get ALPN to work), but it does work. F5 are supporting it now too.
  - pimlottc 11y ago
    From the presentation, Jetty's smart push feature sounds really cool, do you know if there's more information available on that feature?
    - tootie 11y ago
      Basically it caches requests per referrer so the next time a request is made, it can guess what subsequent requests will be made. Documentation is still sparse and a lot of it is carryover from their SPDY features.
- ropiku 11y ago
  You can also use an http/2 reverse proxy in front like nghttp2 or H2O. https://nghttp2.org/ https://nghttp2.org/ https://h2o.examp1e.net/ https://h2o.examp1e.net/
- olalonde 11y ago
  There's a list of implementations here: https://github.com/http2/http2-spec/wiki/Implementations https://github.com/http2/http2-spec/wiki/Implementations
  - oinksoft 11y ago
    According to the presentation, 9% of all HTTP on FF36 (for those who didn't disable this data collection) is HTTP/2. Surely there are people here using HTTP/2 in production: How are you serving HTTP/2 traffic? The listing itself is somewhat muddled ... "Twitter" is an entry, linking to the Twitter homepage, presumably that's responsible for most of this traffic? I found https://github.com/twitter/netty-http2 https://github.com/twitter/netty-http2 and https://github.com/twitter/hpack https://github.com/twitter/hpack on Twitter's GitHub.
Silhouette 11y ago
Interesting read, but as far as I can tell this article mostly makes a strong case that using HTTP/2 at all is an "anti-pattern" for most projects[1] today, for at least three reasons. Firstly, the presentation seems to start by arguing that round-trip latency has much more of an impact on perceived performance than bandwidth, but then argues for several techniques whose principle advantage is saving small amounts of bandwidth. So how much improvement will these new techniques really offer over current best practices for "an average web site"? Secondly, the presentation seems to argue that simplifying front-end development processes by avoiding things like resource concatenation is a big advantage of HTTP/2, yet despite repeatedly emphasizing the need for the server to provide just the right responses to make HTTP/2 work well, it almost completely ignores the inevitable challenges of actually configuring and maintaining a server to take advantage of all of these new techniques in a real, production environment, with rapidly evolving site structure and content, numerous contributors, etc. Essentially, this seems to be advocacy for dumping tried, tested, universal "workarounds" for the limitations of HTTP/1.1 in favour of new techniques that work well with HTTP/2 and only HTTP/2, but as an industry we have relatively little experience in what actually works well or doesn't with HTTP/2 and we have relatively few tools and relatively little infrastructure available that support it right now. And crucially, making the shift is not by any means a neutral activity; it is actively and severely harmful to several of the most important tried-and-tested techniques we've used up to now. Finally, there is the simple matter of trust or, if you want to be kinder, future-proofing. The presentation notes that Google are deprecating SPDY from early 2016. That is the supposed HTTP replacement that was the New Shiny... yesterday, I think, or maybe it was the day before. When arguing for fundamental and irreversible changes in the basic development process and infrastructure set-up, you lose all credibility when your so-called standards fall out of favour faster than a GUI or DB library from Microsoft, and when your own browser frequently breaks due to questionable caching and related behaviour. It's certainly true that HTTP/1.1 isn't perfect and there are practical ways it could be improved, but I don't think this presentation makes a strong case for adopting HTTP/2 as the way forward. [1] YMMV if you actually do work for Google/Facebook/Amazon, and you really do have practically unlimited resources available to maintain both your sites and your servers, and you really are making/losing significant amounts of money with every byte/millisecond difference.
- 11y ago
olalonde 11y ago
Can I get some of the http/2 performance benefits by putting a http/2 reverse proxy in front of a regular http server? Does such a thing exist?
- chadaustin 11y ago
  Yes, you can just configure the spdy plugin for nginx and place it in front of your webserver. Easy and we measured significant load-time wins.
  - quintin 11y ago
    This might be too much to ask, but you can share the Nginx config file(s)?
    - imrehg 11y ago
      Adding SPDY is really nothing much in nginx (and that one of the thing that makes it awesome). In practice, if you already have an SSL server, just add the "spdy" to the listen line like "listen 443 ssl spdy;", restart and you are done[1]. Then making it proxy request is just one location definition with "proxy_pass"[2]. [1]: http://nginx.org/en/docs/http/ngx_http_spdy_module.html http://nginx.org/en/docs/http/ngx_http_spdy_module.html [2]: http://nginx.com/resources/admin-guide/reverse-proxy/ http://nginx.com/resources/admin-guide/reverse-proxy/
- acdha 11y ago
  Yes – you won't get things like server push but the core feature of allowing the browser to queue a large number of requests and receive responses out of order is a big win even if you do nothing else. chadaustin already mentioned nginx, which seems to be the most popular choice. This is alos one of the examples for H2O: https://h2o.examp1e.net/ https://h2o.examp1e.net/ … and Apache Traffic Server just shipped support in v5.3.0, which might be of interest if you want to setup a generic front-end layer for a ton of backend services: https://cwiki.apache.org/confluence/display/TS/What%27s+New+in+v5.3.x#What%27sNewinv5.3.x-HTTP/2 https://cwiki.apache.org/confluence/display/TS/What%27s+New+... One thing I haven't looked into is whether any of these will try to use server push for content which has is referenced by <link rel=preload> in an HTML page. That could be very useful for render-blocking CSS/JS.
BorisMelnik 11y ago
"This would have a larger effect on the speed of the internet than increasing a users bandwidth from 3.9Mbps to 10Mbps or even 1Gbps" I'm sold. What would be the easiest way to makes this happen for someone like me with a pretty vanilla LAMP server?
- MichaelGG 11y ago
  Install nginx as a reverse proxy, add spdy to the server directive. Enjoy.
  - facepalm 11y ago
    So the spdy directive also does http/2? I seem to remember looking for HTTP/2 support in NGINX and finding that they only support it in the commercial version?
    - harshreality 11y ago
      No, but FF and Chrome which are the main browsers currently supporting HTTP/2 also support SPDY/3.1. I don't know where you saw that nginx commercial has HTTP/2 (it's not mentioned on the nginx feature matrix[1]), but their announcement[2] stated that both open and commercial versions would be getting HTTP/2 support by end of year. [1] http://nginx.com/products/feature-matrix/ http://nginx.com/products/feature-matrix/ [2] http://nginx.com/blog/how-nginx-plans-to-support-http2/ http://nginx.com/blog/how-nginx-plans-to-support-http2/
    - strommen 11y ago
      SPDY is an experimental protocol that does much of what HTTP/2 does ( you can think of it as the beta version of HTTP/2). It will be phased out starting next year over favor of the real protocol but people use it now with nginx.
      - BorisMelnik 11y ago
        thank you, I have been looking for this exact explanation. Ive been wondering why everyone keeps recommending SPDY when this whole thing is about http2
bonobo 11y ago
I never took the time to try WebSockets, so please forgive me if this question doesn't make sense, but, does HTTP/2 supersedes WebSockets? I'm under the impression that HTTP/2 covers all the WebSockets' use cases, is this a correct observation?
- gkop 11y ago
  No, specifically when you want a full-duplex link, you will still use websockets.
  - euyyn 11y ago
    Why? You can have full-duplex streams in HTTP/2 too.
    - wmf 11y ago
      At the protocol level or at the JavaScript level?
- jkarneges 11y ago
  If you use WebSockets mainly because you want to multiplex many requests/responses over a single TCP channel, then HTTP/2 may be a preferable substitute for WebSockets. If you use WebSockets for "realtime push", then HTTP/2's server push feature could potentially be used as an alternative (though I've not heard of anyone actually doing this yet). If you use WebSockets because you actually want a bidirectional message-oriented transport protocol, well then you'll keep using WebSockets. :)
  - vladaionescu 11y ago
    From what I could find online, there are no plans to include websockets as part of HTTP/2 (according to this: https://webtide.com/http2-last-call/ https://webtide.com/http2-last-call/ ). HTTP/2 is meant to supersede all websocket use cases.
    - 11y ago
fake-name 11y ago
Holy shit, fuck that site. It overrides the BACK AND FORWARD BUTTONS for fucking page changes.
- leepowers 11y ago
  Seeing and annoyed by the same thing. I'm surprised Google would muck up the UI that badly
- glitch 11y ago
  I can't actually tell if that's sarcasm anymore or not. Next slide is a new URL, new page. Based on initial testing, the behavior seems fine. Same behavior as one would have for something like http://example.com/my-presentation/1.htm http://example.com/my-presentation/1.htm, 2.htm, 3.htm, etc. and navigating them with hyperlinks on each slide that link to neighboring slides. It's not like Back/Forward browser buttons are overrode to behave and previous/next for the slide presentation. Remember those horrible embedded Flash presentations that you couldn't directly link to a particular slide within the blob? Yeah, that "breaks the Web". Back/Forward is supposed to go back to the previous page the user was on (which is a "slide" in this case). Using Chrome 43.0.2357.81 (64-bit) / OS X.
  - maxlaumeister 11y ago
    I would agree except that they also use scrolling to change slides. It feels a little weird to scroll down 3 ticks of the mousewheel, then have 3 clicks of the back button do the reverse action.
    - glitch 11y ago
      Scrolling is a separate matter. I didn't even bother to scroll the first time. I just pressed the next/previous buttons on the slide navigation bar. In the scrolling case, I still don't see how it's "overriding the browser buttons", but rather having a JavaScript that advances to the next page on scroll. In the scrolling scenario, my actual back and forward browser buttons behaved as expected — just for the pages (slides) I visited. No more, no less.
frik 11y ago
Do these HTTP/2 server implementations downgrade to HTTP0.x/1.x if the client support only an older version? Will there be v2-only servers in near future? If the answers are in the slides, forgive me - using the iPad the Google slide software breaks the back button and is too annoying to read beyond a few slide pages. Debugging and implementing older protocols seem to be easier, as they were text based.
- Lukasa 11y ago
  > Do these HTTP/2 server implementations downgrade to HTTP0.x/1.x if the client support only an older version? Many do, yes. > Will there be v2-only servers in near future? Yes. > Debugging and implementing older protocols seem to be easier, as they were text based. Implementing text protocols seems to be easier, but writing an implementation that can handle the wide variety of both compliant and slightly non-compliant traffic is an exercise in frustration. This is not helped by the fact that people see the text protocol and think that it's easy to implement, so they go and write their own HTTP/1.1 server and leave it on the internet. Their server is probably not quite spec-compliant, so everyone else is left trying to interop with it. Binary protocols are hard to debug by eye, but they aren't hard to write parsers for.
  - frik 11y ago
    > Binary protocols are hard to debug by eye, but they aren't hard to write parsers for. Implementing a text based protocol (SMTP, POP3, HTTP0.x/1.x) for a client application is certainly easier and less documentation is required. Knowing the clusterfk of the binary Office document formats, the newer text based ones re far easier to parse (be it XML or plain text doesn't matter). Be it binary or text based, one has to write a parser anyway. Only with text based protocol one could also use Regex or string match during, which is quite useful for non-production development/testing. I read about "prioritisation" of data as a hint for the server, and less caching of data on the client. With the reoccurring "net neutrality" debates, let's hope this protocol cannot be misused/used to prioritise certain packets for parties who pay extra. I am not into this debates, but it would be certainly a disadvantage for startups over established parties. Given the many problems with SSL (heartbeat, broken/outdated certs, hijacked cert vendors) an HTTP/2 without SSL would be a nice fallback scenario - wildcard certs for new startups are still a bit expensive, especially if one will have to replace (=costs) the certs every few months due security concerns.
philjr 11y ago
This is a really interesting read (linked from that presentation) http://chimera.labs.oreilly.com/books/1230000000545/ch12.html http://chimera.labs.oreilly.com/books/1230000000545/ch12.htm... * one tcp connection per request * Server push functionality / server initiated streams * current implementations means http/2 works over tls _only_ - neither Firefox nor chrome currently support non encrypted connections. This does keep things simpler with things like proxies in the middle I presume also. * tls implementations must now support sni also so basically http/2 is now a forcing function for supporting sni which is awesome.

221 points by vladaionescu 11y ago

The chapter in the book goes over more details: http://chimera.labs.oreilly.com/books/1230000000545/ch12.html http://chimera.labs.oreilly.com/books/1230000000545/ch12.htm...

0x006A 11y ago

what are the current http/2 server options?

vladaionescu 11y ago
As far as I understand, none for production use. I see that nginx implements SPDY (HTTP2 is based on SPDY), but not yet HTTP2. They promise to bring HTTP2 by end of year though - http://nginx.com/blog/how-nginx-plans-to-support-http2/ http://nginx.com/blog/how-nginx-plans-to-support-http2/ .
shurcooL 11y ago
Caddy looks like a good choice. https://caddyserver.com/ https://caddyserver.com/
tootie 11y ago
Undertow and Jetty are both Java options that support HTTP/2. I've been playing with both and it's still very rough around the edges (have to mess with bootpath to get ALPN to work), but it does work. F5 are supporting it now too.
- pimlottc 11y ago
  From the presentation, Jetty's smart push feature sounds really cool, do you know if there's more information available on that feature?
  - tootie 11y ago
    Basically it caches requests per referrer so the next time a request is made, it can guess what subsequent requests will be made. Documentation is still sparse and a lot of it is carryover from their SPDY features.
ropiku 11y ago
You can also use an http/2 reverse proxy in front like nghttp2 or H2O. https://nghttp2.org/ https://nghttp2.org/ https://h2o.examp1e.net/ https://h2o.examp1e.net/
olalonde 11y ago
There's a list of implementations here: https://github.com/http2/http2-spec/wiki/Implementations https://github.com/http2/http2-spec/wiki/Implementations
- oinksoft 11y ago
  According to the presentation, 9% of all HTTP on FF36 (for those who didn't disable this data collection) is HTTP/2. Surely there are people here using HTTP/2 in production: How are you serving HTTP/2 traffic? The listing itself is somewhat muddled ... "Twitter" is an entry, linking to the Twitter homepage, presumably that's responsible for most of this traffic? I found https://github.com/twitter/netty-http2 https://github.com/twitter/netty-http2 and https://github.com/twitter/hpack https://github.com/twitter/hpack on Twitter's GitHub.

Silhouette 11y ago

Interesting read, but as far as I can tell this article mostly makes a strong case that using HTTP/2 at all is an "anti-pattern" for most projects[1] today, for at least three reasons. Firstly, the presentation seems to start by arguing that round-trip latency has much more of an impact on perceived performance than bandwidth, but then argues for several techniques whose principle advantage is saving small amounts of bandwidth. So how much improvement will these new techniques really offer over current best practices for "an average web site"? Secondly, the presentation seems to argue that simplifying front-end development processes by avoiding things like resource concatenation is a big advantage of HTTP/2, yet despite repeatedly emphasizing the need for the server to provide just the right responses to make HTTP/2 work well, it almost completely ignores the inevitable challenges of actually configuring and maintaining a server to take advantage of all of these new techniques in a real, production environment, with rapidly evolving site structure and content, numerous contributors, etc. Essentially, this seems to be advocacy for dumping tried, tested, universal "workarounds" for the limitations of HTTP/1.1 in favour of new techniques that work well with HTTP/2 and only HTTP/2, but as an industry we have relatively little experience in what actually works well or doesn't with HTTP/2 and we have relatively few tools and relatively little infrastructure available that support it right now. And crucially, making the shift is not by any means a neutral activity; it is actively and severely harmful to several of the most important tried-and-tested techniques we've used up to now. Finally, there is the simple matter of trust or, if you want to be kinder, future-proofing. The presentation notes that Google are deprecating SPDY from early 2016. That is the supposed HTTP replacement that was the New Shiny... yesterday, I think, or maybe it was the day before. When arguing for fundamental and irreversible changes in the basic development process and infrastructure set-up, you lose all credibility when your so-called standards fall out of favour faster than a GUI or DB library from Microsoft, and when your own browser frequently breaks due to questionable caching and related behaviour. It's certainly true that HTTP/1.1 isn't perfect and there are practical ways it could be improved, but I don't think this presentation makes a strong case for adopting HTTP/2 as the way forward. [1] YMMV if you actually do work for Google/Facebook/Amazon, and you really do have practically unlimited resources available to maintain both your sites and your servers, and you really are making/losing significant amounts of money with every byte/millisecond difference.

11y ago

olalonde 11y ago

Can I get some of the http/2 performance benefits by putting a http/2 reverse proxy in front of a regular http server? Does such a thing exist?

chadaustin 11y ago
Yes, you can just configure the spdy plugin for nginx and place it in front of your webserver. Easy and we measured significant load-time wins.
- quintin 11y ago
  This might be too much to ask, but you can share the Nginx config file(s)?
  - imrehg 11y ago
    Adding SPDY is really nothing much in nginx (and that one of the thing that makes it awesome). In practice, if you already have an SSL server, just add the "spdy" to the listen line like "listen 443 ssl spdy;", restart and you are done[1]. Then making it proxy request is just one location definition with "proxy_pass"[2]. [1]: http://nginx.org/en/docs/http/ngx_http_spdy_module.html http://nginx.org/en/docs/http/ngx_http_spdy_module.html [2]: http://nginx.com/resources/admin-guide/reverse-proxy/ http://nginx.com/resources/admin-guide/reverse-proxy/
acdha 11y ago
Yes – you won't get things like server push but the core feature of allowing the browser to queue a large number of requests and receive responses out of order is a big win even if you do nothing else. chadaustin already mentioned nginx, which seems to be the most popular choice. This is alos one of the examples for H2O: https://h2o.examp1e.net/ https://h2o.examp1e.net/ … and Apache Traffic Server just shipped support in v5.3.0, which might be of interest if you want to setup a generic front-end layer for a ton of backend services: https://cwiki.apache.org/confluence/display/TS/What%27s+New+in+v5.3.x#What%27sNewinv5.3.x-HTTP/2 https://cwiki.apache.org/confluence/display/TS/What%27s+New+... One thing I haven't looked into is whether any of these will try to use server push for content which has is referenced by <link rel=preload> in an HTML page. That could be very useful for render-blocking CSS/JS.

BorisMelnik 11y ago

"This would have a larger effect on the speed of the internet than increasing a users bandwidth from 3.9Mbps to 10Mbps or even 1Gbps" I'm sold. What would be the easiest way to makes this happen for someone like me with a pretty vanilla LAMP server?

MichaelGG 11y ago
Install nginx as a reverse proxy, add spdy to the server directive. Enjoy.
- facepalm 11y ago
  So the spdy directive also does http/2? I seem to remember looking for HTTP/2 support in NGINX and finding that they only support it in the commercial version?
  - harshreality 11y ago
    No, but FF and Chrome which are the main browsers currently supporting HTTP/2 also support SPDY/3.1. I don't know where you saw that nginx commercial has HTTP/2 (it's not mentioned on the nginx feature matrix[1]), but their announcement[2] stated that both open and commercial versions would be getting HTTP/2 support by end of year. [1] http://nginx.com/products/feature-matrix/ http://nginx.com/products/feature-matrix/ [2] http://nginx.com/blog/how-nginx-plans-to-support-http2/ http://nginx.com/blog/how-nginx-plans-to-support-http2/
  - strommen 11y ago
    SPDY is an experimental protocol that does much of what HTTP/2 does ( you can think of it as the beta version of HTTP/2). It will be phased out starting next year over favor of the real protocol but people use it now with nginx.
    - BorisMelnik 11y ago
      thank you, I have been looking for this exact explanation. Ive been wondering why everyone keeps recommending SPDY when this whole thing is about http2

bonobo 11y ago

I never took the time to try WebSockets, so please forgive me if this question doesn't make sense, but, does HTTP/2 supersedes WebSockets? I'm under the impression that HTTP/2 covers all the WebSockets' use cases, is this a correct observation?

gkop 11y ago
No, specifically when you want a full-duplex link, you will still use websockets.
- euyyn 11y ago
  Why? You can have full-duplex streams in HTTP/2 too.
  - wmf 11y ago
    At the protocol level or at the JavaScript level?
jkarneges 11y ago
If you use WebSockets mainly because you want to multiplex many requests/responses over a single TCP channel, then HTTP/2 may be a preferable substitute for WebSockets. If you use WebSockets for "realtime push", then HTTP/2's server push feature could potentially be used as an alternative (though I've not heard of anyone actually doing this yet). If you use WebSockets because you actually want a bidirectional message-oriented transport protocol, well then you'll keep using WebSockets. :)
- vladaionescu 11y ago
  From what I could find online, there are no plans to include websockets as part of HTTP/2 (according to this: https://webtide.com/http2-last-call/ https://webtide.com/http2-last-call/ ). HTTP/2 is meant to supersede all websocket use cases.
  - 11y ago

fake-name 11y ago

Holy shit, fuck that site. It overrides the BACK AND FORWARD BUTTONS for fucking page changes.

leepowers 11y ago
Seeing and annoyed by the same thing. I'm surprised Google would muck up the UI that badly
glitch 11y ago
I can't actually tell if that's sarcasm anymore or not. Next slide is a new URL, new page. Based on initial testing, the behavior seems fine. Same behavior as one would have for something like http://example.com/my-presentation/1.htm http://example.com/my-presentation/1.htm, 2.htm, 3.htm, etc. and navigating them with hyperlinks on each slide that link to neighboring slides. It's not like Back/Forward browser buttons are overrode to behave and previous/next for the slide presentation. Remember those horrible embedded Flash presentations that you couldn't directly link to a particular slide within the blob? Yeah, that "breaks the Web". Back/Forward is supposed to go back to the previous page the user was on (which is a "slide" in this case). Using Chrome 43.0.2357.81 (64-bit) / OS X.
- maxlaumeister 11y ago
  I would agree except that they also use scrolling to change slides. It feels a little weird to scroll down 3 ticks of the mousewheel, then have 3 clicks of the back button do the reverse action.
  - glitch 11y ago
    Scrolling is a separate matter. I didn't even bother to scroll the first time. I just pressed the next/previous buttons on the slide navigation bar. In the scrolling case, I still don't see how it's "overriding the browser buttons", but rather having a JavaScript that advances to the next page on scroll. In the scrolling scenario, my actual back and forward browser buttons behaved as expected — just for the pages (slides) I visited. No more, no less.

frik 11y ago

Do these HTTP/2 server implementations downgrade to HTTP0.x/1.x if the client support only an older version? Will there be v2-only servers in near future? If the answers are in the slides, forgive me - using the iPad the Google slide software breaks the back button and is too annoying to read beyond a few slide pages. Debugging and implementing older protocols seem to be easier, as they were text based.

Lukasa 11y ago
> Do these HTTP/2 server implementations downgrade to HTTP0.x/1.x if the client support only an older version? Many do, yes. > Will there be v2-only servers in near future? Yes. > Debugging and implementing older protocols seem to be easier, as they were text based. Implementing text protocols seems to be easier, but writing an implementation that can handle the wide variety of both compliant and slightly non-compliant traffic is an exercise in frustration. This is not helped by the fact that people see the text protocol and think that it's easy to implement, so they go and write their own HTTP/1.1 server and leave it on the internet. Their server is probably not quite spec-compliant, so everyone else is left trying to interop with it. Binary protocols are hard to debug by eye, but they aren't hard to write parsers for.
- frik 11y ago
  > Binary protocols are hard to debug by eye, but they aren't hard to write parsers for. Implementing a text based protocol (SMTP, POP3, HTTP0.x/1.x) for a client application is certainly easier and less documentation is required. Knowing the clusterfk of the binary Office document formats, the newer text based ones re far easier to parse (be it XML or plain text doesn't matter). Be it binary or text based, one has to write a parser anyway. Only with text based protocol one could also use Regex or string match during, which is quite useful for non-production development/testing. I read about "prioritisation" of data as a hint for the server, and less caching of data on the client. With the reoccurring "net neutrality" debates, let's hope this protocol cannot be misused/used to prioritise certain packets for parties who pay extra. I am not into this debates, but it would be certainly a disadvantage for startups over established parties. Given the many problems with SSL (heartbeat, broken/outdated certs, hijacked cert vendors) an HTTP/2 without SSL would be a nice fallback scenario - wildcard certs for new startups are still a bit expensive, especially if one will have to replace (=costs) the certs every few months due security concerns.

philjr 11y ago

This is a really interesting read (linked from that presentation) http://chimera.labs.oreilly.com/books/1230000000545/ch12.html http://chimera.labs.oreilly.com/books/1230000000545/ch12.htm... * one tcp connection per request * Server push functionality / server initiated streams * current implementations means http/2 works over tls _only_ - neither Firefox nor chrome currently support non encrypted connections. This does keep things simpler with things like proxies in the middle I presume also. * tls implementations must now support sni also so basically http/2 is now a forcing function for supporting sni which is awesome.