http/2 takes how web sites have been architected for the last decade and turns it upside down, so I suspect it will take a while to really take hold. On haproxy's roadmap http/2 is in the uncategorized section. =P Also many people think that the TLS overhead that browsers have forced on http/2 wasteful on the backend. So I'm actually hoping to terminate http/2 with the first thing that supports it reasonably well (Apache Traffic Server and Apache mod_h2 look like leading candidates, h2o is still too immature for a production site IMO) then use haproxy to talk http/1.1 to backends. I'm hoping that might also ease the transition between the architectural differences because I can serve an http/2 optimized structure to those clients and use haproxy to map the destinations back to http/1.1 backends while still keeping the existing structures in place for http/1 clients. When haproxy does finally gain http/2 support then maybe it can terminate directly and save the extra hop. If it supports http/2 to backends then I'm hoping it will have the option to connect directly (without tls).
On Wed, Jun 24, 2015 at 12:26 PM, Shawn Heisey <[email protected]> wrote: > When http/2 support lands in haproxy, will http/2 support also be > required on the back end to take advantage of it? > > I'm hoping that I can leverage http/2 without immediate support on the > back end. I would expect that the LAN connection between haproxy and > the back end servers will be fast enough that the single http/2 > connection can be used on the Internet-facing side with multiple > http/1.1 connections on the back end, but I don't know if that kind of > isolation will be possible. We do have plans to upgrade the back end to > support http/2, but that may happen a lot slower than I would like. > > The back end servers for haproxy are Apache, with Tomcat behind those, > so I have similar concerns there. Apache has http/2 support now, but > Tomcat is lagging behind. > > Thanks, > Shawn > >
