On Wed, Jun 24, 2015 at 10:26:24AM -0600, Shawn Heisey wrote: > When http/2 support lands in haproxy, will http/2 support also be > required on the back end to take advantage of it?
To add to what CJ Ess said, I'd mention that the real gains of HTTP/2 are between the client and the first point in your infrastructure. The purpose of HTTP/2 is to aggregate multiple requests over a single connection to 1) avoid the buffer bloat issue caused my multiple connections, 2) remove the amazing number of round trips that are involved when doing keep-alive without pipelining, and 3) to avoid head-of-line blocking that still appears with pipelining. So the real gains will be where the latency is. On the backend side it can be the opposite for quite some time because most agents will in fact more or less translate HTTP/2 to HTTP/1 then process the request as HTTP/1, so it will add extra processing. The very low latency on this side already prevents small TCP windows from being filled so it will not be relevant to the savings HTTP/2 provides. In fact only the connection multiplexing will provide a real benefit but it's already possible to do that in HTTP/1 to some extents. Thus my first goal with HTTP/2 in haproxy really is to make it a solid H2->H1 gateway in order to provide a seamless migration to H2 to everyone, just like haproxy was massively used to provide IPv6 connectivity for the last IPv6 day. I'll still focus on H2 on the backend but more as a longterm goal, to help making architectural choices when needed, but I don't see this as a benefit for now. It will probably be one when servers start to exploit server push, which could be a reason for having H2 on the server side. But that's not urgent in my opinion. Best regards, Willy
