Řešení 1:
Základní TCP ACK říká "Přijal jsem všechny bajty až do X." Selektivní ACK vám umožňuje říct "Přijal jsem bajty X-Y a V-Z."
Pokud vám například hostitel poslal 10 000 bajtů a 3 000–5 000 bajtů se ztratilo při přenosu, ACK by řekl:„Mám všechno do 3 000“. Druhý konec by musel znovu poslat bajty 3001-10000. SACK by mohl říct "Mám 1000-2999 a 5001-10000" a hostitel by prostě poslal 3000-5000.
To je skvělé přes vysokorychlostní, ztrátové (nebo velké zpoždění) spojení. Problém je v tom, že za určitých okolností může způsobit vážné problémy s výkonem. Normální TCP ACK způsobí, že server zachází se ztrátovým spojením s velkou šířkou pásma v dětských rukavicích (odeslání 500 bajtů, čekání, odeslání 500 bajtů, čekání atd.). SACK mu umožňuje přizpůsobit se vysokému zpoždění, protože přesně ví, kolik paketů bylo skutečně ztraceno.
Zde se mohou stát špatné věci. Útočník může přinutit váš server, aby po dlouhou dobu držel masivní frontu opakovaného přenosu a pak celou tu zatracenou věc zpracovával znovu a znovu a znovu. To může zablokovat CPU, spotřebovat RAM a spotřebovat větší šířku pásma, než by mělo. Stručně řečeno, lehký systém může zahájit DoS proti výkonnějšímu serveru.
Pokud je váš server robustní a neobsluhuje velké soubory, jste proti tomu docela dobře izolováni.
Pokud většinou obsluhujete intranet nebo jinou skupinu uživatelů s nízkou latencí, SACK vám nic nekoupí a může být z bezpečnostních důvodů vypnut bez ztráty výkonu.
Pokud používáte připojení s nízkou šířkou pásma (řekněme 1 Mb/s nebo méně jako zcela libovolné pravidlo), SACK může způsobit problémy v normálním provozu tím, že zahltí vaše připojení a měl by být vypnut.
Nakonec je to na vás. Zvažte, co podáváte, komu, z čeho, a zvažte míru svého rizika oproti účinkům SACK na výkon.
Zde je skvělý přehled o SACKu a jeho zranitelnosti.
Řešení 2:
Dalším důvodem, proč je TCP SACK často zakázán, je to, že existuje obrovské množství síťových zařízení, které tuto možnost nezvládají správně. Vidíme to neustále u produktu pro vysokorychlostní přenos souborů, který poskytujeme a který používá TCP. Nejběžnějším problémem je problém se zařízeními brány, která dělají věci, jako je náhodná sekvenční čísla pro pakety TCP procházející zařízením z interních sítí do externích, ale která „nerozhazují“ možnosti TCP SACK, které mohou být odeslány ze vzdáleného zařízení. konec. Pokud nejsou skutečné hodnoty SACK těmito zařízeními převedeny zpět na správné hodnoty, pak se relace TCP nikdy nedokončí tváří v tvář ztrátě paketů, když se vzdálený konec pokusí použít SACK k získání výhod selektivního ACK.
Pravděpodobně by to byl menší problém, kdyby lidé agresivněji uplatňovali preventivní údržbu softwaru na toto zařízení, ale většinou to nedělají.
Řešení 3:
Z hořkých zkušeností mohu potvrdit, že tcp_sack =1 způsobuje pozastavení přenosu dat přes sftp/rsync/scp atd. se soubory většími než 12 MB při použití určitých firewallových zařízení Cisco ASA.
POKAŽDÉ by se to zastavilo.
Přenášeli jsme přes vyhrazené spojení 100 Mb/s mezi hostitelem A a hostitelem B ve dvou různých datových centrech, obě využívající firewall Cisco a switch hardware s centos.
To lze poněkud zmírnit úpravou velikosti vyrovnávací paměti - např. Nemohl jsem přenést 1GB soubor přes sftp z hostitele A na hostitele B, pokud nenastavím vyrovnávací paměť sftp na 2048, ale mohl bych bez ohledu na to, zda hostitel B stahoval soubor z A.
Experimenty se stejným souborem pomocí rsync a ladění vyrovnávací paměti pro odesílání a přijímání mi umožnily získat přibližně 70 MB z 1GB souboru posunutého z A do B.
Konečným řešením však bylo zakázat tcp_sack na hostiteli A. Zpočátku nastavením tcp_sack =0 v jádře za běhu - ale nakonec - jsem ho přidal do svého /etc/sysctl.conf