it-swarm-pt.tech

Quando desativar TCP SACK desativado?

Eu estive olhando os parâmetros de ajuste do Linux e vi algumas configurações em que o SACK está desativado. Alguém pode explicar isso?

Isso seria ajustado para um servidor da web ocupado.

28
JB.

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

Assim, por exemplo, se um host enviar a você 10.000 bytes e bytes 3000-5000 forem perdidos em trânsito, o ACK diria "eu tenho tudo até 3000". A outra extremidade precisaria enviar os bytes 3001-10000 novamente. SACK poderia dizer "recebi 1000-2999 e 5001-10000" e o Host apenas enviava o 3000-5000.

Isso é ótimo em um link de alta largura de banda, com perdas (ou alto atraso). O problema é que ele pode causar problemas graves de desempenho em circunstâncias específicas. Normal TCP ACKs fará com que o servidor trate uma conexão de alta largura de banda e com perdas com luvas de pelica (envie 500 bytes, aguarde, envie 500 bytes, aguarde, etc). O SACK permite que ele se adapte às altas 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 massiva por um longo período de tempo, e processar toda essa maldita coisa repetidamente. 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ê estiver servindo principalmente uma intranet ou outro grupo de usuários de baixa latência, o SACK não comprará nada e poderá ser desativado por motivos de segurança sem perda de desempenho.

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

Em última análise, cabe a você. Considere o que você está servindo, a quem, a partir de quê e pese o grau de seu risco contra os efeitos no desempenho do SACK.

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

34
sh-beta

Outro motivo pelo qual o TCP SACK geralmente é desativado é que há uma quantidade incrível de equipamentos de rede por aí que não consegue lidar com essa opção corretamente. Vemos isso o tempo todo com uma transferência de arquivos em alta velocidade produto que fornecemos que usa TCP.O problema mais comum é o de dispositivos de gateway que fazem coisas como números de sequência aleatórios para TCP que transitam pelo dispositivo de redes internas para externas, mas não t "cancele a randomização" das opções TCP SACK que podem ser enviadas a partir da extremidade remota. Se os valores reais de SACK não forem convertidos de volta aos valores apropriados por esses dispositivos, então TCP nunca será concluída em face da perda de pacotes quando o terminal remoto tentar usar o SACK para obter os benefícios seletivos do ACK.

Provavelmente, isso seria menos problemático se as pessoas aplicassem mais agressivamente a manutenção preventiva de software a esse equipamento, mas elas tendem a não aplicar.

12
Chris Markle

Posso confirmar por experiência amarga que tcp_sack = 1 causa transferência de dados interrompida sobre sftp/rsync/scp etc. com arquivos acima de 12mb ao usar determinados dispositivos de firewall Cisco ASA.

CADA VEZ seria parado.

Estávamos transferindo um link dedicado de 100mbps entre o Host A e o Host B em dois data centers diferentes, usando o firewall da Cisco e o hardware do switch com centos.

Isso pode ser mitigado um pouco, modificando os tamanhos do buffer - por exemplo, Não foi possível transferir o arquivo de 1 GB via sftp do Host A para o Host B, a menos que eu defina o buffer sftp para 2048, mas poderia, independentemente disso, se o Host B estivesse retirando o arquivo de A.

Experiências com o mesmo arquivo usando o rsync e o ajuste do buffer de envio/recebimento permitiram aumentar em torno de 70mb de um arquivo de 1 GB enviado de A para B.

No entanto, a resposta final foi desabilitar o tcp_sack no host A. Inicialmente, definindo tcp_sack = 0 no kernel on-the-fly - mas, em última análise - eu o adicionei ao meu /etc/sysctl.conf

6
Isaac