Jak diagnozujesz utratę pakietów?

Zdaję sobie sprawę, że jest to bardzo subiektywne i zależne od wielu zmiennych, ale zastanawiam się, jakie kroki przechodzi większość ludzi, kiedy muszą zdiagnozować utratę pakietów w danym systemie?

Jestem inżynierem sieci, więc opiszę to z mojej perspektywy.

Dla mnie diagnozowanie utraty pakietów zwykle zaczyna się od „nie działa zbyt dobrze”. Stamtąd zwykle staram się znaleźć zestaw tak blisko obu końców komunikacji (zazwyczaj stacji roboczej w biurze i gdzieś na serwerze) i pingować tak blisko drugiego końca, jak to możliwe (najlepiej „zdalny punkt końcowy”, ale czasami są zapory ogniowe, przez które nie mogę wysłać pingów, więc muszę zadowolić się interfejsem LAN na routerze) i sprawdzić, czy widzę jakąkolwiek stratę.

Jeśli widzę stratę, to zwykle jest to „niewystarczająca przepustowość” lub „połączenie z problemami” gdzieś pomiędzy, więc znajdź trasę przez sieć i zacznij od środka, co zwykle daje ci jeden koniec.

Jeśli nie widzę straty, następne dwa kroki to „wyślij więcej pingów” lub „wyślij większe pingi”. Jeśli to nie posortuje, wskaże, na czym polega problem, czas zacząć analizować zasady QoS i statystyki interfejsu na całej ścieżce między punktami końcowymi.

Jeśli to nic nie znajdzie, czas zacząć kwestionować swoje założenia, czy faktycznie cierpisz z powodu utraty pakietów. Jedynym pewnym sposobem na znalezienie tego jest jednoczesne przechwytywanie na obu końcach, albo za pomocą WireShark (lub odpowiednika) na hostach, albo przez podłączenie maszyn do wykrywania (prawdopodobnie za pomocą WireShark lub podobnych) za pośrednictwem zaczepów sieciowych. Potem przychodzi zabawa porównywania dwóch przechwyconych pakietów ...

Czasami to, co przypisuje się „utracie pakietów”, jest po prostu zauważalnie wolniejsze po stronie serwera (na przykład przeniesienie bazy danych z „w tej samej sieci LAN” do „20 ms” i użycie zapytań, które wymagają ogromnej ilości tam iz powrotem między front-endem a bazą danych).

Z punktu widzenia systemu Linux najpierw sprawdzę utratę pakietów w interfejsie sieciowym za pomocą ethtool -S ethX.

W większości przypadków zwiększenie bufora pierścieniowego ethtool -G ethX rx VALUErozwiązuje ten problem.

Czasami przerwania nie równoważą się, ponieważ system nie ma usługi równoważenia, więc spójrz w chkconfig(EL) lub update-rc(Debuntu), aby sprawdzić, czy ta usługa jest uruchomiona. Możesz stwierdzić, czy przerwania nie są równoważone, ponieważ /proc/interruptspokaże tylko rdzeń 0 obsługujący wszystkie kanały IRQ.

W przeciwnym razie może być konieczne zwiększenie, net.core.netdev_max_backlogjeśli system przesyła więcej niż kilka gigabitów ruchu, a może net.core.netdev_budget.

Jeśli to nie zadziała, możesz dostosować wartości koalescencji przerwania ethtool -C.

Jeśli w interfejsie sieciowym nie ma żadnych spadków pakietów, spójrz netstat -si sprawdź, czy w buforach gniazd występują spadki, zostaną one zgłoszone ze statystykami takimi jak „ pruned from receive queue” i „ dropped from out-of-order queue”.

Możesz spróbować zwiększyć domyślne i maksymalne bufory gniazd dla odpowiedniego protokołu (np .: net.ipv4.tcp_rmemdla TCP).

Jeśli aplikacja ustawia własny rozmiar bufora gniazda, może wymagać zmian w konfiguracji. Jeśli aplikacja ma zakodowane na stałe rozmiary buforów gniazd, złóż skargę do dostawcy aplikacji.

Osobiście nie lubię odciążania protokołu na kartach sieciowych (sumowanie kontrolne, odciążanie segmentacji, odciążanie dużych odbiorników), ponieważ wydaje się, że powoduje więcej problemów niż jest to warte. ethtool -KWarto zapoznać się z tymi ustawieniami za pomocą.

Spójrz na opcje modułu dla twojej karty sieciowej ( modinfo <drivername>), ponieważ być może będziesz musiał zmienić niektóre funkcje. Aby podać jeden przykład, z jakim się spotkałem, użycie programu Flow Director firmy Intel w systemie obsługującym jeden duży strumień TCP prawdopodobnie zaszkodzi wydajności tego strumienia, więc wyłącz FDir.

Poza tym zaczynasz ręcznie dostosowywać ten konkretny system do konkretnego obciążenia, które, jak sądzę, wykracza poza zakres twojego pytania.

Zacznę od użycia narzędzia do przechwytywania pakietów, takiego jak: wireshark (w systemie Windows) i tcpdump (w terminalu Linux).

Sprawdzę również konfigurację zapory (zapora hosta, a także zapora sieciowa).

Wyizoluj, a następnie wyeliminuj.

Znajdź najmniejszy podzbiór ścieżek z problemem. Zrób to, testując różne kombinacje i / lub destylując raporty użytkowników. Nie zapomnij uwzględnić czasu w równaniu. Może to tylko utrata pakietów na całym ruchu do określonej sieci, a może cierpią tylko klienci bezprzewodowi. Weź pod uwagę różne rodzaje ruchu (limit stawek na pingi). Znajdź najbardziej niezawodny i łatwo powtarzalny sposób na przetestowanie go.

Następnie wyeliminuj potencjalne przyczyny. Ogranicz ruch na łączach (tymczasowo), usuń źródła zakłóceń z widma, odłącz niektórych klientów. W końcu znajdziesz źródło problemu.

Czasami możesz skorzystać ze skrótów, patrząc na zrzuty pakietów lub zgadywać (zawsze jest to bittorrent). Powiedz też profesorowi, że błąd serwera jest niesamowity.

Pingi mogą nie pokazywać utraty pakietów, chyba że wyślesz duże pingi! Utrata pakietów w mojej sieci była niewidoczna, dopóki nie zwiększyłem rozmiaru pakietu ping.

Dla Windowsa:

ping -n 30 -l <largevalue> <target>

Do largevalueużyłem 40960 (pakiet 40k)

Dla targetużyłem kilku pierwszych adresów IPtracert google.com

(które były moimi routerami i modemem kablowym). Jedno z urządzeń w dalszej części łańcucha miało straszną utratę pakietów (> 60%) dla dużych pakietów, ale 0% dla małych. Naprawiłem go przez ponowne uruchomienie, ale może to być również kabel lub coś wewnętrznego, które wymaga wymiany.