Hi Willy. On Fri, 24 Jun 2022 22:58:53 +0200 Willy Tarreau <w...@1wt.eu> wrote:
> Hi, > > HAProxy 2.7-dev1 was released on 2022/06/24. It added 131 new commits > after version 2.7-dev0. > > There's not that much new stuff yet but plenty of small issues were > addressed, and it's already been 3 weeks since the release thus I figured > it was a perfect timing for a -dev1 for those who want to stay on the edge > without taking much risks. > > In addition to the fixes that went into 2.6.1 already, some HTTP/3 issues > were addressed and a memory leak affecting QUIC was addressed as well (thanks > to @Tristan971 for his precious help on this one). > > Aside fixes, a few improvements started already. First, and to finish on > QUIC, the QUICv2 version negotiation was implemented. This will allow us > to follow the progress on the QUICv2 drafts more closely. > > On HTTP/2, the maintainer of the Lighttpd web server reported a nasty case > that he observed between curl and lighttpd which is very similar to the so > called "Silly Window Syndrom" in TCP where a difference of one byte between > a buffer size and a window size may progressively make the transfer > degenerate until almost all frames are 1-byte in size. It's not a bug in > any product, just a consequence of making certain standard-compliant stacks > interoperate. Some workarounds were placed in various components that > allowed the issue to appear. We did careful testing on haproxy and couldn't > produce it there, in part due to our buffer management that makes it > difficult to read exactly the sizes that produce the issue. But there's > nothing either that can strictly prevent it from happening (e.g. with a > sender using smaller frames maybe). So we implemented the workaround as > well, which will also result in sending slightly less frames during > uploads. The goal is to backport this once it has been exposed for a > while without trouble in 2.7. > > Another noticeable improvement is the inclusion of a feature that had > been written in the now dead ROADMAP file for 15 years: multi-criteria > bandwidth limiting. It allows to combine multiple filters to enforce > bandwidth limitations on arbitrary criteria by looking at their total > rate in a stick table. Thus it's possible to have per-source, per- > destination, per-network, per-AS, per-interface bandwidth limits in > each direction. In addition there's a stream-specific pair of limits > (one per direction as well) that can even be adjusted on the fly. We > could for example imagine that a client sends a POST request to a > server, that the server responds with a 100-Continue and a header > indicating the max permitted upload bandwidth, and then the transfer > will be automatically capped. Quite frankly, I've been wanting this > for a long time to address the problem of buffer bloat on small links > (e.g. my old ADSL line), and here there's now an opportunity to > maintain a good quality of service without saturating links thanks to > this. I'm pretty sure that some users will be creative and may even > come up with ideas of improvements ;-) WOW that's great news. Thanks for that feature :-) Regards Alex
