Odpowiedzi:
Podstawowy ACK TCP mówi: „Otrzymałem wszystkie bajty do X”. Selektywne ACK pozwala powiedzieć „Otrzymałem bajty XY i VZ”.
Na przykład, jeśli host wysłał ci 10 000 bajtów, a bajty 3000-5000 zostały utracone podczas transportu, ACK powiedziałoby „Mam wszystko do 3000”. Drugi koniec musiałby ponownie wysłać bajty 3001-10000. SACK mógłby powiedzieć „Mam 1000-2999 i 5001-10000”, a gospodarz po prostu wyśle 3000-5000.
Jest to świetne w przypadku łącza o dużej przepustowości, stratnego (lub o dużym opóźnieniu). Problem polega na tym, że może powodować poważne problemy z wydajnością w określonych okolicznościach. Normalne ACK ACK sprawią, że serwer będzie leczył połączenie szerokopasmowe, stratne z rękawiczkami dla dzieci (wyślij 500 bajtów, poczekaj, wyślij 500 bajtów, poczekaj itd.). SACK pozwala dostosować się do dużego opóźnienia, ponieważ dokładnie wie, ile pakietów zostało rzeczywiście utraconych.
Tutaj mogą się zdarzyć złe rzeczy. Osoba atakująca może zmusić serwer do utrzymywania dużej kolejki retransmisji przez długi czas, a następnie przetwarzać całą tę cholerną rzecz w kółko. Może to ustalić procesor, zużywać pamięć RAM i zużywać więcej pasma niż powinno. W skrócie, lekki system może zainicjować DoS przeciwko silniejszemu serwerowi.
Jeśli twój serwer jest solidny i nie obsługuje dużych plików, jesteś dość dobrze izolowany od tego.
Jeśli obsługujesz głównie intranet lub inną grupę użytkowników o niskim opóźnieniu, SACK nic Cię nie kupuje i można go wyłączyć ze względów bezpieczeństwa bez utraty wydajności.
Jeśli korzystasz z łącza o niskiej przepustowości (powiedzmy 1 Mb / s lub mniej jako całkowicie arbitralna zasada), SACK może powodować problemy w normalnych operacjach poprzez nasycenie połączenia i powinien zostać wyłączony.
Ostatecznie to zależy od ciebie. Zastanów się, komu służysz, komu, z czego i zważ stopień ryzyka w stosunku do efektów działania SACK.
Tutaj znajduje się świetny przegląd SACK i jego podatności .
Innym powodem, dla którego TCP SACK jest często wyłączany, jest niesamowita ilość sprzętu sieciowego, który nie obsługuje tej opcji poprawnie. Cały czas to widzimy w oferowanym przez nas produkcie do szybkiego przesyłania plików, który wykorzystuje TCP. Najczęstszym problemem jest to, że urządzenia bramowe wykonują takie rzeczy, jak losowe numery sekwencyjne dla pakietów TCP przesyłanych przez urządzenie z sieci wewnętrznych do zewnętrznych, ale które nie „odznaczają losowo” opcji TCP SACK, które mogą być wysyłane ze zdalnego koniec. Jeśli rzeczywiste wartości SACK nie zostaną ponownie przetłumaczone na prawidłowe wartości przez te urządzenia, sesja TCP nigdy nie zakończy się w obliczu utraty pakietów, gdy zdalny koniec spróbuje użyć SACK, aby uzyskać selektywne korzyści ACK.
Prawdopodobnie byłby to mniejszy problem, gdyby ludzie bardziej agresywnie stosowali profilaktyczną konserwację oprogramowania na tym sprzęcie, ale zwykle tego nie robią.
Mogę potwierdzić z gorzkiego doświadczenia, że tcp_sack = 1 powoduje zablokowany transfer danych przez sftp / rsync / scp itp. Z plikami przekraczającymi około 12 MB przy korzystaniu z niektórych urządzeń zaporowych Cisco ASA.
Za każdym razem utknie w martwym punkcie.
Przenosiliśmy dedykowane łącze 100 Mb / s między hostem A i hostem B w dwóch różnych centrach danych, zarówno za pomocą zapory ogniowej Cisco, jak i sprzętu przełączającego z centos.
Można to nieco złagodzić, modyfikując rozmiary buforów - np. Nie mogłem przesłać pliku 1GB przez sftp z hosta A na hosta B, chyba że ustawiłem bufor sftp na 2048, ale mogłem niezależnie od tego, czy host B pobierał plik z A.
Eksperymenty z tym samym plikiem przy użyciu rsync i dostrajania bufora wysyłania / odbierania pozwoliły mi wstać około 70 MB pliku 1 GB przesłanego z A do B.
Ostateczną odpowiedzią było jednak wyłączenie tcp_sack na hoście A. Początkowo przez ustawienie tcp_sack = 0 w jądrze w locie - ale ostatecznie - dodałem go do mojego /etc/sysctl.conf