On 23/08/2024 16:42, Willy Tarreau wrote: > On Fri, Aug 23, 2024 at 04:13:16PM +0200, Matthieu Baerts wrote:
(...) >>> I'll comment on each patch separately, >> >> Thank you, please take your time! > > That's what I'm doing but I really want to make sure we won't discover > last-minute show-stoppers that require important changes. It's still > possible to do some important ones for a few weeks, so let's tackle all > roadblocks while we can. I really feel like we're on a good track now! It makes sense, thank you for having done the reviews so quickly! I will check with Anthony if he needs some help there. (...) >>> With that said, from an implementation perspective, it would seem right >>> to make sure that most TCP tunables also work with MPTCP. >> >> That's what we tried to do. All "common" ones are supported, but it is >> not always easy to define what is "common" and what is not! There are >> many obscure/specific socket options out there :) > > I agree :-) For example we're using other horrors such as TCP_REPAIR, > which was initially defined for CRIU, and that we're using to silently > destroy a connection without responding. It's extremely effective against > HTTP botnets as they keep their connection pending and do not consume > anything locally. I don't know if you have it, but if you're interested > in giving it a try, I can help you set it up in haproxy for a test. Wow, nice bazooka :-) Here is what we can currently find in the MPTCP code in the kernel: /* TCP_REPAIR, TCP_REPAIR_QUEUE, TCP_QUEUE_SEQ, TCP_REPAIR_OPTIONS, * TCP_REPAIR_WINDOW are not supported, better avoid this mess */ Maybe a new socket option would be better if the idea is only to silently drop connections? :) (If these botnets are using "plain" TCP, the TCP_REPAIR socket option will work!) Cheers, Matt -- Sponsored by the NGI0 Core fund.
