Jak mierzyć opóźnienie sieci?
Nie jest to niezwykle skomplikowanie i Wireshark w zasadzie robi to za nas. Najpierw musisz wybrać konkretną sesję TCP. Możesz to zrobić albo wybierając jeden z pakietów sesji i potem z menu kontekstowego Follow > TCP Stream, albo w polu filtra wpisać:tcp.stream == 10
gdzie zamiast 10 możesz wpisać dowolny numer identyfikujący sesję TCP w twoim dumpie.
Potem otwórz Statistics > TCP Stream Graphs > Round Trip Time i wszystko gotowe. Oczywiście, nie możesz zapominać, że to wykres RTT tylko dla tej konkretnej sesji TCP.
Można powiedzieć, to tylko mgnienie oka i tak naprawdę o opóźnieniach wprowadzanych przez sieć w dłuższej perspektywie, np. 1h czy cały dzień, nie wiemy nic. Dlatego w praktyce monitoringu tak ważne jest, aby śledzić RTT czy stratność sieci w sposób ciągły, dla wszystkich monitorowanych aplikacji i ich użytkowników. Tymczasem sprawdźmy, co z tymi straconymi pakietami.
Niezawodność protokołu TCP
Protokół TCP został tak zaprojektowany, żeby zapewnić jak najwyższą niezawodność dostarczania danych w czasie. Dlatego posiada kilka mechanizmów, które z pewnością obiły ci się o uszy: numery sekwencyjne i potwierdzenia (pakiety ACK). Numery sekwencyjne bazują na liczbie przesyłanych bajtów w pakietach, dzięki temu wiadomo, ile danych powinno trafić do adresata, a pakiety z flagą ACK są potwierdzeniem, że dane zostały w całości dostarczone.
Ale co się dzieje, jeśli pakiety przepadną i dlaczego tak się dzieje? Sprawa wygląda podobnie, jak z listami poleconymi na poczcie. Niby każdy list ma swój numer (bo jest rejestrowany; u nas mówią na nie „polecone”, natomiast Anglosasi nazywają je „registered mail”), a mimo to zdarza się, że nawet polecony nie dojdzie. Dlatego w celu podniesienia pewności doręczenia stosuje się tzw. zwrotkę (taki żółty kwitek potwierdzenia dostarczenia listu, a w TCP to pakiet z flagą ACK).
Możesz wierzyć albo nie, ale protokoły bazujące na IP (TCP i UDP) zostały zaprojektowane w połowie lat 70. XX wieku. Tak, to najstarszy komponent stosu twojej nowoczesnej aplikacji! Środek komunikacji twojej aplikacji ma ponad 40 lat i nadal ma się świetnie.
Kiedy dochodzi do retransmisji?
Stos TCP nie czeka w nieskończoność na pakiety, które nie pojawiły się na czas. No właśnie, co to znaczy? Jest taki parametr, zwany Retransmission timeout (RTO), który odpowiada za reakcję stosu TCP. Domyślnie, wynosi on 3000 ms, przynajmniej w MS Windows. Ale inne systemy mogą mieć inną wartość. Jeśli pakiet nie został zaobserwowany przez 3 sekundy albo nie dostał potwierdzenia w tym czasie, stos TCP wysyła żądanie ponownego wysłania brakującego pakietu, czyli dochodzi do retransmisji. Jeśli retransmitowany pakiet nie dotrze do celu, stos TCP będzie się domagał ponownej retransmisji. Domyślnie w Windows dzieje się tak pięć razy, po czym nastąpi „awaria”, czyli zerwanie transmisji, ale niektóre systemy unixowe mają ten parametr domyślnie ustawiony nawet na wartość 15.
Bez wdawania się w niepotrzebne teraz szczegóły działania stosu TCP, jeśli pakiet z danymi przepadnie, to nie pojawi się przed upływem RTO, czyli 3 sekund. A po upływie tego czasu zostanie wysłany ponownie, bo tego zażąda stos TCP odbiorcy.
Jak mierzyć straty pakietów?
Wireshark odpowiednio znakuje retransmisje, a ty jesteś już w posiadaniu filtra, którego zadaniem jest odsiać tylko te pakiety, które są problematyczne. Ponieważ retransmisje to zjawisko niepożądane, z pomocą przychodzi filtr TCP Problems, który stworzyliśmy na początku tego serialu. W moim przykładzie widać trochę problemów ze stratami pakietów.
Zaznaczyłem pierwszy pakiet TCP Retransmission. W panelu dolnym zaznaczyłem wiersz, który mówi, jaka była długość RTO dla tego pakietu. Pakiet został wysłany po 46 milisekundach od oryginalnego żądania, więc nie tak długo. W krótko po tym, cały żądany plik został dostarczony do odbiorcy. Ale jeśli podczas sesji dojdzie do jakiegoś poważniejszych strat pakietów, to zobaczysz:
- Sekwencje retransmisji
- Wzrost RTO w kolejnych retransmisjach.
Pakiet TCP Retransmission w Wiresharku oznacza, że doszło do utraty pakietu od nadawcy. Dlaczego? Ponieważ po stronie odbiorcy nie było widać tego pakietu (z danymi albo może nawet pakietu sterującego TCP, takiego jak ACK), więc odbiorca wysyła do nadawcy pakiet z żądaniem retransmisji brakującego pakietu. I ten pakiet z żądaniem to właśnie TCP Retransmission.
Sytuacja odwrotna, tj. taka, w której dojdzie do utraty pakietu od odbiorcy, w Wiresharku jest sygnalizowana pakietem TCP Dup ACK, czyli ponowne wysłanie pakietu potwierdzenia ACK, jak na przykładzie poniżej:
Jeśli dobrze się przyjrzysz, to zobaczysz, że tych zduplikowanych pakietów ACK była cała seria, o czym świadczą kolejne numerki sekwencyjne. Ja zaznaczyłem pierwszy z nich i mogę tylko powiedzieć, że było ich aż 40. Co prawda były wysyłane w bardzo krótkich odstępach czasu, więc nie miało to bardzo wielkiego wpływu na czas, ale każde takie zdarzenie trzeba przeanalizować, szczególnie jeśli prowadzisz analizę dużego dumpa, zbieranego dla dłuższego czasu aktywności użytkownika albo serwera aplikacji.
Żeby dokładniej przekonać się, jak te retransmisje (czyli stratność sieci) wpłynęła na ładowanie strony, zilustruję tę sesję TCP. Z menu kontekstowego wybieram Follow > TCP Stream. Następnie z menu wybieram Statistics > TCP Stream Graphs > Time Sequence (Stevens) i dostaję poniższy wykres.
Retransmisje pojawiły się w okolicach „zagęszczenia” pakietów, tak jak to zaznaczono na wykresie.
Analiza stratności jest szczególnie trudna, jeśli dysponujesz dumpem złapanym w jednym punkcie. Zupełnie inaczej wygląda to, jeśli masz dumpy złapane na serwerze i na maszynie klienckiej, idealnie w tym samym czasie. Wireshark pozwala na połączenie dumpów i jeśli na obu maszynach wykorzystywana jest synchronizacja czasu, najlepiej z tego samego serwera NTP, to analiza strat jest dużo łatwiejsza. Jednak nie da ci ona odpowiedzi, gdzie na ścieżce między serwerem a klientem doszło do utraty pakietów. W przypadku korzystania z Internetu, nawet gdybyśmy dysponowali dwoma dumpami, nic nam to nie da, bo nie mamy wpływu na to, jak i którędy wędrują pakiety między dwiema maszynami. Ale wyobraź sobie sytuację, że jesteś w firmowym LANie i masz dostęp do praktycznie każdego hopa (traceroute idzie tu z pomocą). Wówczas namierzenie urządzenia, które podejrzewasz o zrzucanie twoich pakietów jest naprawdę proste.
Tymczasem na dziś to tyle. W następnych częściach skupimy się na analizie problemów wydajnościowych strony webowej, czyli spróbujemy połączyć w całość to, o czym do tej pory mówiliśmy.
