Solución 1:
Un TCP ACK básico dice "Recibí todos los bytes hasta X". El ACK selectivo le permite decir "Recibí los bytes X-Y y V-Z".
Entonces, por ejemplo, si un host le envió 10,000 bytes y los bytes 3000-5000 se perdieron en el tránsito, ACK diría "Tengo todo hasta 3000". El otro extremo tendría que enviar los bytes 3001-10000 nuevamente. SACK podría decir "Obtuve 1000-2999 y 5001-10000" y el anfitrión simplemente enviaría el 3000-5000.
Esto es excelente en un enlace de gran ancho de banda, con pérdidas (o con un gran retraso). El problema es que puede causar graves problemas de rendimiento en circunstancias específicas. Los ACK de TCP normales harán que el servidor trate una conexión con pérdida de ancho de banda alto con guantes de seda (enviar 500 bytes, esperar, enviar 500 bytes, esperar, etc.). SACK le permite adaptarse al alto retraso porque sabe exactamente cuántos paquetes fueron realmente perdido.
Aquí es donde pueden pasar cosas malas. Un atacante puede obligar a su servidor a mantener una cola de retransmisión masiva durante mucho tiempo y luego procesar todo eso una y otra vez. Esto puede vincular la CPU, consumir RAM y consumir más ancho de banda de lo que debería. En pocas palabras, un sistema liviano puede iniciar un DoS contra un servidor más robusto.
Si su servidor es robusto y no sirve archivos grandes, está bastante bien protegido contra esto.
Si principalmente presta servicios a una intranet u otro grupo de usuarios de baja latencia, SACK no le compra nada y se puede desactivar por razones de seguridad sin pérdida de rendimiento.
Si está en un enlace de bajo ancho de banda (digamos 1 Mbps o menos como una regla general completamente arbitraria), SACK puede causar problemas en las operaciones normales al saturar su conexión y debe apagarse.
En última instancia, depende de usted. Considere qué está sirviendo, a quién, de qué, y sopese el grado de su riesgo frente a los efectos de rendimiento de SACK.
Hay una gran descripción general de SACK y su vulnerabilidad aquí.
Solución 2:
Otra razón por la que TCP SACK a menudo está deshabilitado es que hay una cantidad asombrosa de equipos de red que no pueden manejar esta opción correctamente. Vemos esto todo el tiempo con un producto de transferencia de archivos de alta velocidad que proporcionamos que utiliza TCP. El problema más común es el de los dispositivos de puerta de enlace que hacen cosas como números de secuencia aleatorios para paquetes TCP que transitan a través del dispositivo desde redes internas a externas, pero que no "desaleatorizan" las opciones TCP SACK que pueden enviarse desde el control remoto. final. Si estos dispositivos no vuelven a traducir los valores reales de SACK a los valores correctos, entonces la sesión TCP nunca se completará ante la pérdida de paquetes cuando el extremo remoto intente usar SACK para obtener los beneficios selectivos de ACK.
Probablemente esto sería un problema menor si las personas aplicaran de manera más agresiva el mantenimiento preventivo de software a este equipo, pero tienden a no hacerlo.
Solución 3:
Puedo confirmar por amarga experiencia que tcp_sack =1 provoca el estancamiento de la transferencia de datos a través de sftp/rsync/scp, etc. con archivos que superan los 12 mb cuando se utilizan determinados dispositivos de cortafuegos Cisco ASA.
CADA vez que se detendría.
Estábamos transfiriendo a través de un enlace dedicado de 100 mbps entre el host A y el host B en dos centros de datos diferentes, ambos con firewall de Cisco y hardware de conmutación con centos.
Esto se puede mitigar un poco modificando los tamaños de búfer, p. No podía transferir un archivo de 1 GB a través de sftp del host A al host B a menos que configurara el búfer de sftp en 2048, pero podía hacerlo sin importar si el host B extraía el archivo de A.
Los experimentos con el mismo archivo usando rsync y el ajuste del búfer de envío/recepción me permitieron obtener alrededor de 70 MB de un archivo de 1 GB enviado de A a B.
Sin embargo, la respuesta final fue deshabilitar tcp_sack en el host A. Inicialmente configurando tcp_sack =0 en el kernel sobre la marcha, pero finalmente, lo agregué a mi /etc/sysctl.conf