Kiedy użytkownicy (w tym i ty) narzekają, że aplikacja wolno działa, nasuwają ci się od razu dwie standardowe odpowiedzi:
#1 – U mnie działa (szybko).
#2 – Sieć jest wolna.
Jak wiadomo, obie są prawdziwe tylko do pewnego stopnia. A ponieważ większość developerów niespecjalnie przepada za diagnostyką i usuwaniem problemów z siecią, naturalną tendencją jest „delegowanie” tych obowiązków na administratorów sieci. A ci, dla odmiany, nieszczególnie palą się do namierzania i usuwania problemów na warstwie 4 modelu ISO/OSI, bo mają dość roboty z warstwami 1-3.
Dlatego w tej serii chcę ci przypomnieć (albo przybliżyć) model ISO/OSI, bo każdy omnibus musi być oblatany zarówno z aplikacjami, jak i z siecią, po której te aplikacje latają.
Model ISO/OSI a model TCP/IP
Model ISO/OSI definiuje siedem warstw, z czego warstwami 5-7, specyficznymi dla aplikacji, nie będę się teraz zajmować, co nie znaczy, że są mało ważne albo je pominę. Po prostu, będziemy jechać od fundamentów.
Model TCP/IP ma tylko cztery warstwy. Niby „less is more”, ale z punktu widzenia sieciowców ma trochę za mało szczegółów na samym dole.
Bez względu na liczbę warstw każdego modelu, ważne jest zrozumienie, co każda z warstw oznacza dla twojej aplikacji. Poniższy rysunek mapuje model ISO/OSI na model TCP/IP. Zakładam, że w ten sposób łatwiej zrozumieć podobieństwa obu modeli, w szczególności w warstwach Transport i Application.
O ile warstwami związanymi z aplikacją zajmiemy się później, a warstwy 1-3 modelu ISO/OSI nie są tym, na co jako developer masz największy wpływ, skupię się na ziemi niczyjej, czyli warstwie Transport.
Transport – No man’s land
Pewnie zadajesz sobie pytanie: dlaczego do warstwy transportowej nikt się nie przyznaje albo nikogo ona nie interesuje? Odpowiedź jest banalnie prosta – nikt tej warstwy nie chce kontrolować. Dlaczego? Bo dla sieciowców, czyli ludzi od infrastruktury, kabli, światłowodów, switchów, routerów i tym podobnych urządzeń, warstwa transportowa to już zbyt duża abstrakcja. Natomiast dla ludzi od aplikacji to zło konieczne, ten krąg piekieł, do którego nie chcą się zapuszczać, bo i po co, skoro też nie mają nad nim kontroli. Ale jak już niejednokrotnie powtarzaliśmy, każdy omnibus zna się na wszystkim, więc jeżeli tylko dotrwasz do końca tego cyklu, zostaniesz specem również od sieci. A przynajmniej zrozumiesz mechanizmy jej działania i nauczysz się identyfikować (a może i naprawiać) problemy z aplikacjami, których źródło leży w sieci.
Jakość sieci
Na potrzeby tego cyklu zdefiniujemy dwie miary jakości sieci: stratność (loss rate) i opóźnienie (latency). Formalnie tych miar jest więcej, ale z punktu widzenia wydajności aplikacji webowych – to oczywiście uproszczenie – interesuje nas, jak sieć wpływa na user experience, czyli albo wolna sieć, albo wolna aplikacja, a może jedno i drugie.
Stratność to nic innego jak odsetek pakietów, które z różnych powodów przepadły w czasie transmisji i musiały być ponownie przesłane. Stratność na poziomie 1% oznacza, że jeden pakiet na 100 przesłanych przez sieć musiał być powtórzony, bo tego wymagał stos TCP/IP.
Opóźnienie to czas, jaki upłynął od momentu wysłania pakietu przez stację A do jego odebrania przez stację docelową, czyli B. Opóźnienie to połowa czasu RTT (round trip time). Na opóźnienie sieci wpływ ma wiele czynników: od fizycznej odległości i nośnika (światłowód, atmosfera, przewodnik…) do konfiguracji urządzeń sieciowych transmitujących pakiety od nadawcy do odbiorcy i z powrotem.
Definicje powyższych miar nie są książkowe, bo te znajdziesz sobie albo w Wikipedii, albo w podręcznikach. Podobnie jak z pełną listą tych miar. My skupiamy się tylko na tych, które będą przydatne na potrzeby tego cyklu.
Konwersacja TCP
Pamiętasz, jak wygląda handshake sesji TCP, prawda? Jeśli nie pamiętasz, to nic nie szkodzi.
W skrócie, najpierw nawiązanie sesji, czyli handshake (SYN -> SYN ACK -> ACK), potem regularna wymiana informacji, czyli request-response i potwierdzenie każdego pakietu, a na końcu zamknięcie sesji. Na obrazku poniżej jest typowa konwersacja dla protokołu HTTP (bez końca sesji).
Tak to wygląda w idealnym świecie, a raczej w idealnej sieci. W praktyce nie jest tak różowo i nawet w świetnie działających sieciach dochodzi do usterek czy poważniejszych awarii. Dlatego w tym cyklu chcę nauczyć cię, jak rozpoznawać sytuacje, w których to sieć jest odpowiedzialna za działanie aplikacji dalekie od ideału oraz jak wyeliminować te problemy, na które masz wpływ.
I tu się pojawia pytanie: jak rozpoznać, że problem jest z siecią i na co mam realny wpływ? Po pierwsze, same odczucia użytkownika nie wystarczą, potrzebny jest sprzęt pomiarowy. Po drugie, trzeba umieć odróżnić poprawne zachowanie aplikacji w sieci od takiego, które jest problematyczne. Po trzecie, nie zawsze ta wiedza przekłada się na możliwość akcji naprawczej, ale często wystarcza do przekazania tego do odpowiedniej osoby, która może więcej od ciebie. A zatem, do dzieła!
Czym mierzyć sieć?
Narzędzi do przechwytywania i analizy protokołów sieciowych jest wiele. Proste i bardzo zaawansowane, darmowe i koszmarnie drogie. Wybór będzie należał do ciebie, ale ja na potrzeby tego cyklu wykorzystam Wiresharka. To wieloplatformowy i darmowy program do analizy danych pakietowych, który zdobył popularność na całym świecie i jest powszechnie stosowany do przechwytywania i analizy plików w formacie pcap. Wireshark oczywiście obsługuje wiele formatów zapisywania ruchu sieciowego, a ponieważ jest ciągle aktywnie rozwijany, jeśli dostaniesz do analizy dane pakietowe w innym formacie, jest duża szansa, że Wireshark też go obsługuje. Jeśli jeszcze nie masz Wiresharka na swojej maszynie, pobierz go z https://www.wireshark.org/#download i zainstaluj jak najszybciej. Windows, MacOS, Linuxy i Unixy, najważniejsze systemy są wspierane.
Jeśli w przyszłości planujesz łapać ruch z poziomu serwera, co może być niezbędne w bardziej złożonych przypadkach, z pomocą przyjdzie tcpdump.
Na Linuxach zainstaluj pakiet tcpdump. Na Windows musisz zainstalować pakiet WinPcap. Pobierz go z https://www.winpcap.org/install/default.htm, zainstaluj i jeśli nic złego się nie przydarzy, będziesz mieć komplet driverów pozwalających na przechwytywanie ruchu sieciowego. Ponieważ w tym cyklu będę odnosić się do tcpdumpa, na Windows zainstaluj sobie również jego ekwiwalent, czyli WinDump. Możesz go pobrać z https://www.winpcap.org/windump/install/default.htm. WinDump uruchamia się z linii poleceń, podobnie jak tcpdump.
Poza Wiresharkiem, dość popularny jest Fiddler (https://www.telerik.com/download/fiddler). A do aplikacji webowych, bardzo przydatne są narzędzia wbudowane w przeglądarki, czyli Inspector (Firefox) i Developer Tools (Chrome).
Wireshark dobry na wszystko (prawie)
Wireshark jest de facto standardem przemysłowym, choć w zasadzie każdy producent snifferów (analizatorów protokołów sieciowych) ma swoje specjalizowane narzędzia, które w większości przypadków są znacznie lepsze i mocniejsze niż Wireshark. Ale ma on jedną szczególną cechę – jest dobry i darmowy. Może nie najlepszy, ale wystarczająco dobry. Trzeba tylko trochę zmienić jego domyślną konfigurację i już można łapać ruch do analizy.
Zanim jednak przejdziemy do ulepszania Wiresharka, chciałbym odpowiedzieć na pytanie, w jakim celu warto z niego skorzystać. Odpowiedz szczerze:
- Czy wiesz, jak zachowuje się twoja aplikacja w sieci?
- Znasz zależności twojej aplikacji?
- Masz pewność, że firewall jest prawidłowo skonfigurowany?
- Wiesz, co i kiedy powoduje, że twoja aplikacja jest wolna?
- Gwarantujesz, że wrażliwe dane na pewno nie lecą przez sieć otwartym tekstem?
- Zapewnisz, twoje serwery mają optymalną konfigurację?
Jeśli na któreś z powyższych pytań twoja odpowiedź brzmi NIE, to Wireshark pomoże ci w lepszym zrozumieniu otoczenia sieciowego aplikacji i lepszej identyfikacji problematycznego obszaru, tj. sieci, serwera, lub/klienta.
Tworzenie własnego profilu
Za przykładem mistrzów Wiresharka, po świeżej instalacji zalecam stworzenie własnego profilu. Po uruchomieniu, w prawym dolnym rogu znajdziesz informację o aktualnym profilu (Default). Kliknij prawym guzikiem myszy i utwórz nowy profil.
Ja zapisałem nowy profil pod nazwą Omni i od tej chwili tego będę używał. Po co to? Do różnych potrzeb możesz mieć zestaw różnych kolumn, co przyśpieszy analizę ruchu sieciowego. A nawet jeśli nie będziesz często korzystać z Wiresharka, to dobrze mieć swoją dopracowaną konfigurację, którą możesz przenosić między komputerami, bo to zwykły plik tekstowy.
Na dziś wystarczy tych podstaw i przypomnień. W następnym odcinku nauczysz się łapać ruch, czyli tworzyć dumpa oraz poznasz kilka sztuczek usprawniających pracę w Wiresharku. Do następnego.
