Quando desligar o TCP SACK?

Question

Eu tenho olhado os parâmetros de sintonização do Linux e vejo algumas configurações onde o SACK está desligado. Alguém pode explicar isso?

Isso seria um ajuste para um servidor web ocupado.

    

Answer 1

Um TCP ACK básico diz "Eu recebi todos os bytes até X." O ACK seletivo permite que você diga "Recebi bytes X-Y e V-Z".

Então, por exemplo, se um host enviou 10.000 bytes e os bytes 3000-5000 foram perdidos em trânsito, o ACK diria "eu consegui tudo até 3000". A outra extremidade teria que enviar bytes 3001-10000 novamente. SACK poderia dizer "eu tenho 1000-2999 e 5001-10000" e o host apenas enviaria o 3000-5000.

Isso é ótimo em um link de alta largura de banda, com perda (ou atraso alto). O problema é que isso pode causar sérios problemas de desempenho em circunstâncias específicas. As TCP ACKs normais farão com que o servidor trate de uma conexão de alta largura de banda e perdas com luvas infantis (envie 500 bytes, aguarde, envie 500 bytes, aguarde, etc.). O SACK permite que ele se adapte ao alto atraso porque ele sabe exatamente quantos pacotes foram realmente perdidos.

Aqui é onde coisas ruins podem acontecer. Um invasor pode forçar seu servidor a manter uma fila de retransmissão em massa por um longo tempo e, em seguida, processar essa coisa toda de novo e de novo e de novo. Isso pode atrelar a CPU, consumir RAM e consumir mais largura de banda do que deveria. Em poucas palavras, um sistema leve pode iniciar um DoS contra um servidor mais robusto.

Se o seu servidor é robusto e não serve arquivos grandes, você está bem isolado contra isso.

Se você atende principalmente a uma intranet ou a outro grupo de usuários de baixa latência, o SACK não compra nada e pode ser desativado por motivos de segurança sem perda de desempenho.

Se você estiver em um link de baixa largura de banda (digamos 1Mbps ou menos como uma regra prática completamente arbitrária), o SACK pode causar problemas nas operações normais saturando sua conexão e deve ser desativado.

Por fim, depende de você. Considere o que você está servindo, para quem, de que e pesar o grau de seu risco contra os efeitos de desempenho do SACK.

Há uma excelente visão geral do SACK e sua vulnerabilidade aqui.

    

Answer 2

Outro motivo pelo qual o TCP SACK é desativado com freqüência é que há uma incrível quantidade de equipamentos de rede que não conseguem lidar corretamente com essa opção. Nós vemos isso o tempo todo com um produto de transferência de arquivos de alta velocidade que fornecemos que usa TCP. O problema mais comum é o dos dispositivos de gateway que fazem coisas como randomizar números de sequência para pacotes TCP que transitam pelo dispositivo de redes internas para externas, mas que não "randomizam" as opções do TCP SACK que podem ser enviadas do remoto fim. Se os valores reais do SACK não forem convertidos para os valores apropriados por esses dispositivos, a sessão TCP nunca será concluída em caso de perda de pacotes quando o terminal remoto tentar usar o SACK para obter os benefícios seletivos do ACK.

Provavelmente, isso seria um problema menor se as pessoas aplicassem de forma mais agressiva a manutenção de software preventivo a esse equipamento, mas elas tendem a não fazê-lo.

    

Answer 3

Eu posso confirmar com a experiência amarga que o tcp_sack = 1 causa a transferência de dados travada sobre o sftp / rsync / scp etc com arquivos acima de 12mb ao usar certos dispositivos de firewall Cisco ASA.

TODOS OS TEMPOS ESTAVA PARADO.

Estávamos realizando a transferência de um link dedicado de 100mbps entre o host A e o host B em dois datacenters diferentes, usando firewall cisco e hardware de troca com centos.

Isso pode ser atenuado de alguma forma modificando os tamanhos do buffer - por exemplo, Eu não podia transferir arquivos de 1GB via sftp do host A para o host B, a menos que eu configurasse o buffer sftp para 2048, mas eu poderia independentemente de o host B estar puxando o arquivo de A.

As experiências com o mesmo arquivo usando rsync e ajuste de buffer de envio / recebimento permitiram que eu aumentasse em torno de 70mb de um arquivo de 1GB empurrado de A para B.

No entanto, a resposta final foi desabilitar tcp_sack no host A. Inicialmente definindo tcp_sack = 0 no kernel on-the-fly - mas no final - adicionei ao meu /etc/sysctl.conf