Quand désactiver TCP SACK?

J'ai regardé les paramètres de réglage de Linux et j'ai vu des configurations où SACK était désactivé. Quelqu'un peut-il expliquer cela?

Ce serait le réglage d'un serveur Web occupé.

Un ACK TCP de base dit "J'ai reçu tous les octets jusqu'à X". ACK sélectif vous permet de dire «J'ai reçu les octets XY et VZ».

Ainsi, par exemple, si un hôte vous a envoyé 10 000 octets et que 3 000 à 5 000 octets ont été perdus en transit, ACK disait "J'ai tout obtenu jusqu'à 3 000". L'autre extrémité devrait envoyer à nouveau les octets 3001-10000. SACK pourrait dire «J'ai 1000-2999 et 5001-10000» et l'hôte enverrait simplement le 3000-5000.

C'est très bien sur une liaison à large bande passante, avec perte (ou à retard élevé). Le problème est qu'il peut entraîner de graves problèmes de performances dans des circonstances spécifiques. Les ACK TCP normaux feront que le serveur traitera une connexion à large bande passante et avec perte avec des gants pour enfants (envoyer 500 octets, attendre, envoyer 500 octets, attendre, etc.). SACK lui permet de s'adapter au délai élevé car il sait exactement combien de paquets ont été réellement perdus.

C'est là que de mauvaises choses peuvent se produire. Un attaquant peut forcer votre serveur à conserver une file d'attente de retransmission massive pendant une longue période, puis traiter cette fichue chose encore et encore et encore. Cela peut arrimer le CPU, consommer de la RAM et consommer plus de bande passante qu'il ne devrait. En un mot, un système léger peut lancer un DoS sur un serveur plus costaud.

Si votre serveur est robuste et ne sert pas de fichiers volumineux, vous êtes assez bien isolé contre cela.

Si vous utilisez principalement un intranet ou un autre groupe d'utilisateurs à faible latence, SACK ne vous achète rien et peut être désactivé pour des raisons de sécurité sans perte de performances.

Si vous êtes sur une liaison à faible bande passante (disons 1 Mbps ou moins en règle générale complètement arbitraire), SACK peut causer des problèmes dans les opérations normales en saturant votre connexion et doit être désactivé.

En fin de compte, cela dépend de vous. Considérez ce que vous servez, à qui, à partir de quoi, et pesez le degré de votre risque par rapport aux effets de performance de SACK.

Il y a un bon aperçu de SACK et de sa vulnérabilité ici.

Une autre raison pour laquelle TCP SACK est souvent désactivé est qu'il existe une quantité incroyable de matériel réseau qui ne parvient pas à gérer correctement cette option. Nous voyons cela tout le temps avec un produit de transfert de fichiers à haute vitesse que nous fournissons qui utilise TCP. Le problème le plus courant est celui des périphériques de passerelle qui effectuent des opérations telles que la randomisation des numéros de séquence pour les paquets TCP transitant par le périphérique des réseaux internes vers les périphériques externes, mais qui ne "dés randomisent" pas les options TCP SACK qui pourraient être envoyées depuis la télécommande. fin. Si les valeurs SACK réelles ne sont pas converties en valeurs correctes par ces périphériques, alors la session TCP ne se terminera jamais face à la perte de paquets lorsque l'extrémité distante essaie d'utiliser SACK pour obtenir les avantages ACK sélectifs.

Ce serait probablement moins un problème si les gens appliquaient de manière plus agressive la maintenance préventive des logiciels à cet équipement, mais ils ont tendance à ne pas le faire.

Je peux confirmer par une expérience amère que tcp_sack = 1 provoque un transfert de données bloqué sur sftp / rsync / scp, etc. avec des fichiers dépassant environ 12 Mo lors de l'utilisation de certaines appliances de pare-feu Cisco ASA.

CHAQUE fois, il serait au point mort.

Nous effectuions le transfert sur une liaison dédiée de 100 Mbps entre l'hôte A et l'hôte B dans deux centres de données différents, utilisant à la fois un pare-feu Cisco et du matériel de commutation avec centos.

Cela peut être quelque peu atténué en modifiant la taille des tampons - par exemple, je ne pouvais pas transférer un fichier de 1 Go via sftp de l'hôte A vers l'hôte B, sauf si je définissais le tampon sftp sur 2048, mais je pouvais indépendamment si l'hôte B tirait le fichier de A.

Les expériences avec le même fichier en utilisant rsync et le réglage du tampon d'envoi / réception m'ont permis de récupérer environ 70 Mo d'un fichier de 1 Go poussé de A à B.

Cependant, la réponse ultime a été de désactiver tcp_sack sur l'hôte A. Initialement en définissant tcp_sack = 0 dans le noyau à la volée - mais finalement - je l'ai ajouté à mon /etc/sysctl.conf