Alcançando no máximo TIME_WAIT sockets (tentou tcp_fin_timeout)

Question

tl: dr: Como posso fazer com que o kernel elimine TIME_WAIT / fechando soquetes da forma mais rápida e forçada possível? Eu não ligo para os dados serem perdidos, já que não estou enviando nenhum.

Atualmente estou executando um pequeno cenário de teste em uma máquina muito isolada.
Eu estou executando dois programas C simples uns contra os outros no mesmo host, onde o objetivo do aplicativo é conectar um soquete de cliente a um soquete de servidor e soltá-lo o mais rápido possível.

O aplicativo é rápido o suficiente para bloquear o soquete (ou fd) pool causando "Não é possível vincular ao endereço" no lado do cliente, e a razão para isso parece ser TIME_WAIT em cada slot de soquete disponível. Eu verifiquei isso com ss -s .

Para resolver isso, lembro de definir três valores em sysctl . E isso costumava ser suficiente para resolver o problema, mas por algum motivo, definindo o seguinte:

net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 1

Não funciona mais. Isso apenas reduz o número de conexões por segundo de 20k + para aproximadamente 4 por minuto .

Eu poderia lembrar as configurações erradas nas configurações sysctl net acima, mas eu costumava sair aproximadamente 20k + conexões por segundo fora desta máquina. Então, por que isso de repente me atrasa para 4 / s?

Mesma máquina, um i7 em execução com 127.0.0.1 com configuração mínima do Arch Linux.
Minha principal fonte de informações para testar as configurações foi: Como reduzir número de soquetes em TIME_WAIT?

Editar:

Parece que tcp_fin_timeout não tem efeito no sistema.

A julgar por esta foto, há um par de milhares de conexões ainda em timewait , mesmo que o servidor (canto superior esquerdo) e cliente (canto superior direito) não está mais realizando nenhuma conexão.

Ao final de uma execução de 10 segundos, eu consegui colocar 18 805 conexões, o que não é muito para essa máquina (soquetes ~ 36k TIME_WAIT porque o servidor e o cliente residem na mesma máquina).

Por que não tcp_fin_timeout soltando as conexões após um segundo? É definitivamente o sistema operacional que não honra meu tcp_fin_timeout personalizado.