On Mon, Oct 16, 2017 at 01:28:12PM +0200, Pavlos Parissis wrote: > I guess following step-by-step approach, 1st client side, it makes sense as > it reduces the size of breakage:-)
Yes but not only this. It's also the fact that the main benefits of H2 are on the client side, where the latency is the highest. > On a serious note, having support for QUIC is a huge advantage over other LB > softwares. > Having said, we don't really know if QUIC will be used as it requires changes > on several places, > Firewalls, bot/robot detection... It is interesting that Google decided to > switch protocol, from TCP > to UDP, as they decided to not use SCTP for HTTP2 as it required changes on > Firewall and etc. If we speak from the L4 protocol's perspective, it can indeed be seen as a TCP to UDP migration (and I'm sure that's what journalists will say once QUIC is completed). But from an implementation perspective in fact TCP is reimplemented on top of UDP. Why, would most people ask ? Because this way they can make all the clients immediately adapt to a new behaviour, to a new congestion control algorithm, to faster retransmits or larger initial windows without having to wait for a decade for the various underlying OS to adapt. It will just require pushing a new version of the browser which embeds the whole stack. But this will definitely come with a significant cost for intermediaries like haproxy to have to lose all the optimizations that were created both in software and hardware over the last 20 years, as basically we're back to dealing with dumb packets as it used to be the case with dumb network cards when you could saturate your CPU processing only 100 Mbps :-/ Cheers, Willy
