Respostas:
Um TCP ACK básico diz "Recebi todos os bytes até o X." O ACK seletivo permite que você diga "Recebi os bytes XY e VZ".
Assim, por exemplo, se um host lhe enviar 10.000 bytes e 3.000 a 5.000 bytes foram perdidos em trânsito, o ACK diria "Eu tenho tudo até 3.000". 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 largura de banda alta, com perdas (ou atraso alto). O problema é que ele pode causar problemas graves de desempenho em circunstâncias específicas. Os ACKs TCP normais farão com que o servidor trate uma conexão com 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 ao alto atraso, porque 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 desligado.
Em última análise, cabe a você. Considere o que você está servindo, a quem, a partir de quê e avalie o grau de seu risco em relação aos efeitos de desempenho do SACK.
Há uma ótima visão geral do SACK e de sua vulnerabilidade aqui.
Outro motivo pelo qual o TCP SACK geralmente é desativado é que há uma quantidade incrível de equipamentos de rede por aí que não conseguem lidar com essa opção corretamente. Vemos isso o tempo todo com um produto de transferência de arquivos de alta velocidade que fornecemos e que usa TCP. O problema mais comum é o de dispositivos de gateway que fazem coisas como números de sequência aleatórios para pacotes TCP em trânsito através do dispositivo de redes internas para externas, mas que não "des randomizam" as opções de TCP SACK que podem ser enviadas do controle remoto fim. Se os valores reais do SACK não forem convertidos de volta para os valores apropriados por esses dispositivos, a sessão TCP nunca será concluída diante 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 nesse equipamento, mas elas tendem a não aplicar.
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, ambos usando firewall Cisco e hardware de switch com centos.
Isso pode ser atenuado pela modificação dos 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 do host B, extrair o arquivo de A.
Experiências com o mesmo arquivo usando o rsync e o ajuste de 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 no final das contas - eu o adicionei ao meu /etc/sysctl.conf