Omnibus na froncie walki z problemami sieciowymi – Analiza sesji TCP

29 November, 2017 12:00 5 min Administrator

Omnibus na froncie walki z problemami sieciowymi – Analiza sesji TCP

W poprzedniej części złapaliśmy pierwszego dumpa. Ale nie spoczywamy na laurach. I nie wierzymy Wiresharkowi bezgranicznie, bo też ma swoje fochy i humory.
Po pierwsze, musisz mieć zaufanie do narzędzia, a po drugie, narzędzie pomiarowe musi być skalibrowane. To wszystko brzmi dość pokrętnie, ale sprawa jest raczej prosta.
Zaufanie bierze się z niezawodności, między innymi. Niestety, Wireshark nie jest niezawodny w 100% i w przypadku ruchu na bardzo wysokim poziomie, rzędu 1 Gbps zaczyna gubić pakiety. Prawdopodobnie niezbyt często będziesz łapać ruch w takich warunkach, ale tego wykluczyć nie można. Żeby sprawdzić, czy widzisz 100% pakietów w dumpie złapanym przez Wiresharka, idź do menu Statistics > Capture File Properties. Poza mnogością danych, jest tam informacja o zgubionych pakietach (Dropped packets) w sekcji Interfaces.


Mój dump nie wykazuje strat, ale to dlatego, że był łapany na interfejsie WiFi przy stosunkowo niewielkim ruchu. Ale nie zapomnij sprawdzić tego na początku analizy każdego dumpa. To może niekoniecznie zwiększa niezawodność Wiresharka, ale twoja pewność co do jakości dumpa na pewno będzie znacznie większa.
Na przyszłość, nie musisz używać menu, jeśli preferujesz mysz. U dołu okna Wiresharka jest ikona, która otwiera Capture File Properties.

Pierwsze wyzwanie – zmienne opóźnienia sieci
Czas na pierwszy prawdziwy problem do rozgryzienia. Klient się skarży, że sieć wolno działa, albo że czasem jest szybko, a czasem wolno. Co to właściwie znaczy? Wolna sieć, czyli co? Skupimy się teraz na czymś, co w anglojęzycznej literaturze nazywane jest network latency. Opóźnienie wprowadzane przez sieć zwykle określa się pomiarem round trip time (RTT), czyli czasu, jaki pakietom SYN zabiera podróż od klienta do serwera i z powrotem. W analizie problemów z siecią zwykle mierzy się właśnie czasy dla pakietów SYN, czyli podczas nawiązania sesji TCP, bo te pakiety są małe i ich rozmiar nie wpływa na czas przelotu przez sieć. Analizatory protokołów (sniffery), takie jak Wireshark potrafią mierzyć zarówno czas RTT dla pakietów SYN, jak i pakietów z danymi. Każda sieć wprowadza opóźnienie, ale w sieciach WAN (Wide Area Network) są one dużo większe niż w sieciach LAN. Co z tego wynika, łatwo się domyślić, ale samo opóźnienie sieci wcale nie musi oznaczać, że sieć działa wolno. Cóż, opóźnienia się zdarzają, w szczególności w Internecie, na który nie masz wielkiego wpływu. Ale to nie znaczy, że nie warto się temu przyjrzeć.
Zakładam, że nie używasz oprogramowania do stałego monitoringu aplikacji bazującego na analizie ruchu sieciowego, np. Dynatrace DC RUM. DC RUM robi to, czym się teraz zajmiemy, przez cały czas, 24×7 dla wszystkich serwerów i klientów w twojej sieci. I prezentuje informację w znacznie lepszy sposób niż Wireshark, którego masz do dyspozycji.

Ale nic to, poradzimy sobie bez DC RUMa.
Mamy problem wstępnie opisany, ale to za mało. Poza tym, że sieć wydaje się wolna, musisz wiedzieć, jakiego serwera i klienta to dotyczy. No i oczywiście mieć dumpa do analizy.
Albo instalujesz Wiresharka na maszynie klienta i łapiesz ruch kwestionowanej aplikacji, albo łapiesz go ze swojej maszyny, bo przecież Wiresharka już na niej masz. Albo ktoś inny złapał ruch z serwera tej aplikacji i dał ci dumpa. Zakładam, że właściwy dump jest już na twojej maszynie, a ty nie możesz się doczekać, żeby nakryć sieć na niewłaściwym działaniu.
W tym ćwiczeniu podejrzane jest zachowanie sieci pomiędzy moją maszyną o adresie 192.168.88.21, podłączoną do lokalnej sieci, a serwerem aplikacji webowej stojącym pod adresem IP 173.194.151.105 na porcie 443 (bo to HTTPS).
W polu filtra Wiresharka można ręką wpisać poniższy filtr (w jednym wierszu), ale to mało praktyczne i łatwo popełnić błąd.

ip.addr==192.168.88.21 && tcp.port==56071 && ip.addr==173.194.151.105 && tcp.port==443

Zamiast tego proponuję ci coś szybszego, a w dodatku do wyklikania myszą. Idź do menu Statistics > Conversations i przełącz się na zakładkę TCP.

Znając adres serwera, posortuj sobie tabelę wg adresu B (adres A to tym przypadku zawsze maszyna, na której łapany był dump) i wybierz go z listy. Kliknij prawym guzikiem myszy i z kontekstowego menu wybierz Apply as Filter > Selected > A <–> B.

Okno konwersacji możesz zamknąć, a w głównym oknie Wiresharka zobaczysz właściwy filtr, który pokazuje pakiety należące tylko i wyłącznie do tej konkretnej sesji TCP.
Teraz wybierz z menu Statistics > TCP Stream Graphs > Round Trip Time.
I tu rozczarowanie – wykres jest pusty. To jest właśnie jeden z fochów Wiresharka, ale jesteś już tylko o jeden klik od końcowego rezultatu. Kliknij Switch Direction i gotowe! Twój diagram opóźnienia pewnie nie będzie wyglądał podobnie, ale to nie szkodzi.



To, co widzisz na powyższym obrazku, ilustruje trzy zdarzenia, w których sieć przez chwilę działała wolniej niż zwykle. Wykres dotyczy pakietów wysyłanych przez serwer, zwróć uwagę na kierunek 173.194.151.105 -> 192.168.88.21. Na szczęście, trwało to dość krótko i wróciło do normy, ale w twoim przypadku może to wyglądać zupełnie inaczej. W odwrotnym kierunku takich zdarzeń nie widać, ale to pewnie wynika z tego, że to był streaming video z jednego z serwerów Google, więc klient nie był szczególnie aktywny w sensie konwersacji TCP. Jeśli między klientem a serwerem jest Internet, zwykle niewiele da się zrobić. Ale gdy taka sytuacja występuje w twojej lokalnej sieci, a za jej niezawodne działanie odpowiada zespół zarządzania infrastrukturą sieciową (albo po prostu admin od sieci), to zdecydowanie jest to temat do przekazania sieciowcom. Być może w trakcie łapania dumpa doszło do jakiegoś zatoru w sieci (przeciążone switche albo jakieś problemy na routerach), a może jest to powtarzający się schemat, przypadkowo zauważony przez ciebie podczas analizy aktywności twojej aplikacji.
Musisz pamiętać, że twoje znaleziska dotyczące RTT pomiędzy serwerem a konkretnym klientem nie muszą znaczyć, że taka sytuacja dotyczy wszystkich klientów tego serwera. Dodatkowo, nie musi dotyczyć wszystkich serwerów aplikacji czy w ogóle wszystkich serwerów w podsieci. Ale to, co zostało znalezione w konwersacji dla jednej pary klient–serwer, może być prawidłowością dla innych i warto to sprawdzić. Tutaj z pomocą przychodzą komercyjne rozwiązania do monitorowania wydajności aplikacji bazujące na analizie ruchu sieciowego, takie jak Dynatrace DC RUM. Ale o DC RUM i zaletach wynikających z jego stosowania wspomnę innym razem.

Tymczasem podsumujmy to, co do tej pory udało się osiągnąć.
1. Potrafisz stworzyć swój profil, dzięki czemu możesz przenosić swoją konfigurację Wiresharka na inne instancje i mieć to, czego potrzebujesz.
2. Potrafisz zapisać przydatne filtry w formie skrótów na pasku filtrów.
3. Umiesz szybko znaleźć problemy z TCP w dumpie, bo masz do tego gotowy filtr.
4. Wiesz, jak stworzyć diagram sesji TCP.
5. Jesteś w stanie szybko wyizolować konkretną sesję TCP z dumpa i zilustrować np. opóźnienie wprowadzane przez sieć.
Ale to nie koniec. W końcu jesteś omnibusem i nawet jeśli nie jesteś ekspertem, to znasz się wystarczająco dobrze na wszystkim :). Dlatego więcej interesujących zastosowań Wiresharka już wkrótce.

Sprawdź także

Zadzwoń +48 22 657 0438

lub wypełnij formularz, a skontaktujemy się z Tobą!

Nazywam się
i jestem zainteresowany
Proszę o kontakt pod adresem
lub numerem tel.