Quais são as ramificações da configuração de tcp_tw_recycle / reuse para 1?

Defino tcp_tw_recycle / reuse como 1 no meu arquivo de configuração.

Quais são as ramificações de fazer isso?

Se um soquete tcp for reutilizado, isso representa um risco à segurança? ou seja, 2 conexões diferentes, potencialmente capazes de enviar dados?

É adequado para conexões de vida curta com poucas chances de reconexão?

Por padrão, quando ambos tcp_tw_reusee tcp_tw_recycleestão desabilitados, o kernel assegura que os soquetes no TIME_WAITestado permaneçam nesse estado por tempo suficiente - tempo suficiente para garantir que os pacotes pertencentes a conexões futuras não sejam confundidos com pacotes atrasados ​​da conexão antiga.

Quando você habilita tcp_tw_reuse, os soquetes em TIME_WAITestado podem ser usados ​​antes que expirem, e o kernel tenta garantir que não haja colisão em relação aos números de sequência TCP. Se você habilitar tcp_timestamps(também conhecido como PAWS, para Proteção contra números de sequência agrupados), garantirá que essas colisões não ocorram. No entanto, você precisa que os registros de data e hora do TCP estejam ativados nas duas extremidades (pelo menos, esse é o meu entendimento). Veja a definição de tcp_twsk_unique para os detalhes sangrentos.

Quando você ativa tcp_tw_recycle, o kernel se torna muito mais agressivo e faz suposições sobre os carimbos de data / hora usados ​​pelos hosts remotos. Ele rastreará o último registro de data e hora usado por cada host remoto com uma conexão no TIME_WAITestado) e permitirá reutilizar um soquete se o registro de data e hora tiver aumentado corretamente. No entanto, se o registro de data e hora usado pelo host for alterado (ou seja, voltar ao tempo), o SYNpacote será descartado silenciosamente e a conexão não será estabelecida (você verá um erro semelhante ao "tempo limite da conexão"). Se você quiser mergulhar no código do kernel, a definição de tcp_timewait_state_process pode ser um bom ponto de partida.

Agora, os carimbos de data e hora nunca devem voltar no tempo; a menos que:

• o host é reiniciado (mas, quando voltar a funcionar, o TIME_WAITsoquete provavelmente terá expirado, portanto, isso não será um problema);
• o endereço IP é rapidamente reutilizado por outra coisa (as TIME_WAITconexões permanecem um pouco, mas outras conexões provavelmente serão atingidas TCP RSTe isso liberará algum espaço);
• a tradução de endereços de rede (ou um firewall inteligente) está envolvida no meio da conexão.

Neste último caso, você pode ter vários hosts atrás do mesmo endereço IP e, portanto, diferentes seqüências de carimbos de data / hora (ou, os referidos carimbos de hora são randomizados em cada conexão pelo firewall). Nesse caso, alguns hosts não poderão se conectar aleatoriamente, porque eles são mapeados para uma porta para a qual o TIME_WAITbucket do servidor possui um carimbo de data / hora mais recente. É por isso que os documentos informam que "dispositivos NAT ou balanceadores de carga podem começar a soltar quadros por causa da configuração".

Algumas pessoas recomendam deixar em tcp_tw_recyclepaz, mas ativar tcp_tw_reusee diminuirtcp_timewait_len . Eu concordo :-)

Eu acabei de me morder, então talvez alguém possa se beneficiar da minha dor e sofrimento. Primeiro, um link envolvido com muitas informações: http://vincent.bernat.im/en/blog/2014-tcp-time-wait-state-linux.html

Em particular:

O mero resultado dessa falta de documentação é que encontramos vários guias de ajuste recomendando definir essas configurações para 1 para reduzir o número de entradas no estado TIME-WAIT. No entanto, conforme declarado na página de manual do tcp (7), a opção net.ipv4.tcp_tw_recycle é bastante problemática para servidores públicos, pois não processa conexões de dois computadores diferentes atrás do mesmo dispositivo NAT, o que é um problema difícil de detectar e esperar para morder você:

Eu costumava ter esses recursos habilitados com sucesso para fornecer a menor latência possível, conectividade haproxy dos clientes para um cluster MySql NDB. Isso estava em uma nuvem privada, e nenhuma conexão de qualquer um tinha qualquer tipo de NAT na mistura. O caso de uso fazia sentido, diminua a latência para clientes raio atingindo NDB via haproxy, tanto quanto humanamente possível. Isso foi feito.

Fiz isso novamente em um sistema público haproxy, balanceando o tráfego da web, sem realmente estudar o impacto (idiota, certo ?!) e descobri depois de muita solução de problemas e perseguir fantasmas que:

• Isso criará um caos para os clientes que se conectam através de um NAT.
• É quase impossível identificá-lo porque é completamente aleatório, intermitente e os sintomas atingem o cliente A, em momentos completamente diferentes (ou não) do cliente B, etc.

No lado do cliente, eles verão períodos em que não obtêm mais respostas aos pacotes SYN, às vezes aqui e ali, e às vezes por longos períodos. Mais uma vez, aleatório.

O conto aqui, na minha experiência recente e dolorosa, é deixá-los sozinhos / desativados em servidores públicos, independentemente da função!

De 'man 7 tcp' Você verá isso:

   tcp_tw_recycle (Boolean; default: disabled; since Linux 2.4)
          Enable fast recycling of TIME_WAIT sockets.  Enabling this option is not recommended since this causes problems when working with NAT
          (Network Address Translation).

   tcp_tw_reuse (Boolean; default: disabled; since Linux 2.4.19/2.6)
          Allow  to  reuse  TIME_WAIT  sockets  for  new connections when it is safe from protocol viewpoint.  It should not be changed without
          advice/request of technical experts.

Não há muita ajuda lá. Essa pergunta também tem algumas boas dicas:

/programming/6426253/tcp-tw-reuse-vs-tcp-tw-recycle-which-to-use-or-both

Mas não informações específicas sobre por que a reutilização é mais segura do que a reciclagem. A resposta básica é que tcp_tw_reuse permitirá que você use o mesmo soquete se já houver um no TIME_WAIT com os mesmos parâmetros TCP e que esteja em um estado em que não seja esperado mais tráfego (acredito que seja quando um FIN for enviado ) tcp_tw_recycle, por outro lado, apenas reutilizará os soquetes que estão em TIME_WAIT com os mesmos parâmetros, independentemente do estado, o que pode confundir firewalls com estado, que podem estar esperando pacotes diferentes.

tcp_tw_reuse pode ser feito seletivamente no código, configurando a opção de soquete SO_REUSEADDR, documentada da seguinte man 7 socketmaneira:

   SO_REUSEADDR
          Indicates that the rules used in validating addresses supplied in a bind(2) call should allow reuse of local addresses.  For  AF_INET
          sockets  this means that a socket may bind, except when there is an active listening socket bound to the address.  When the listening
          socket is bound to INADDR_ANY with a specific port then it is not possible to bind to this port for any local address.   Argument  is
          an integer boolean flag.