Ping, jitter i packet loss, czyli korki, opóźnienia i zaginione samochody

Na Autostradzie Pakietów panuje pozorny spokój. Routery kierują ruchem, bramki działają, światłowody świecą, a kierownik NAT po ostatniej aferze z DDoS zażądał osobnego sejfu na swój zeszyt.

Do administratora przychodzi zgłoszenie.

— Internet mi nie działa.
— W ogóle?
— Nie, strony się otwierają.
— Czyli działa.
— Ale rozmowy się zacinają.
— Rozumiem.
— I gra mi laguje.
— Rozumiem.
— I czasami muszę czekać kilka sekund, aż coś zareaguje.

Administrator uruchamia diagnostykę.

— Pakiety dochodzą.
— To dlaczego wszystko działa jak traktor pod górkę?!
— Bo to, że samochód dojeżdża do celu, nie oznacza jeszcze, że dojeżdża na czas.

Ping, czyli „halo, jesteś tam?”

Administrator wysyła na autostradę specjalnego kuriera. Kurier podjeżdża pod wskazany adres, puka do drzwi i pyta:

— Halo, jesteś tam?

Jeżeli adresat odpowie, kurier wraca z wiadomością:

— Tak, jestem.

Administrator mierzy czas od wysłania zapytania do otrzymania odpowiedzi. To właśnie podstawowa idea polecenia ping. Najczęściej wykorzystuje ono ICMP Echo Request i Echo Reply; w IPv6 ich odpowiedniki w ICMPv6.

Przykładowy, ilustracyjny wynik (z adresem przeznaczonym do dokumentacji):

$ ping -c 4 192.0.2.1
64 bytes from 192.0.2.1: icmp_seq=1 ttl=61 time=8.2 ms
64 bytes from 192.0.2.1: icmp_seq=2 ttl=61 time=8.5 ms
64 bytes from 192.0.2.1: icmp_seq=3 ttl=61 time=8.1 ms
64 bytes from 192.0.2.1: icmp_seq=4 ttl=61 time=8.4 ms

4 packets transmitted, 4 received, 0% packet loss
rtt min/avg/max/mdev = 8.1/8.3/8.5/0.2 ms

W tym przykładzie odpowiedzi wracają po około ośmiu milisekundach. Ważne: ping mierzy RTT (Round-Trip Time), czyli czas podróży w obie strony. Nie mierzy osobno czasu dojazdu do celu.

— Panie kierowniku, kurier wrócił po ośmiu milisekundach!
— A ile jechał tam?
— Nie wiemy.
— A ile wracał?
— Też nie wiemy.
— To co pan właściwie wie?!
— Że zdążył wrócić przed dziewiątą milisekundą.

Latency, czyli ile trwa podróż

Opóźnienie (latency) to czas potrzebny na dostarczenie informacji. W diagnostyce pingiem obserwujemy zwykle RTT.

Na Autostradzie Pakietów wpływają na nie odległość, przetwarzanie w urządzeniach i oczekiwanie w kolejkach. W światłowodzie sygnał rozchodzi się bardzo szybko, ale nie natychmiast. Nawet najlepszy administrator nie przekona fizyki, żeby zrobiła wyjątek.

— Panie kierowniku, dlaczego do serwera w Australii jest większy ping niż do serwera w Warszawie?
— Bo Australia jest dalej.
— Ale mamy szybki Internet!
— A Australia o tym wie? 🤣

Szybkie łącze nie oznacza automatycznie niskiego opóźnienia. Łącze 10 Gb/s może mieć większe RTT do dalekiego serwera niż łącze 100 Mb/s do serwera w sąsiednim budynku.

Przepustowość mówi, ile danych możemy przesłać w jednostce czasu. Opóźnienie mówi, jak długo czekamy na odpowiedź. To dwie różne cechy drogi.

Jitter, czyli każdy samochód przyjeżdża kiedy indziej

Wyobraźmy sobie, że na autostradzie kursuje autobus. Według rozkładu ma przyjeżdżać co dziesięć minut. Pierwszy przyjeżdża punktualnie. Drugi również. Trzeci spóźnia się dwadzieścia minut. Czwarty pojawia się po trzydziestu sekundach. Piąty przyjeżdża razem z szóstym.

Dyspozytor sprawdza statystykę.

— Średnio wszystko się zgadza!

Pasażerowie nie są zachwyceni.

Jitter to zmienność opóźnienia w czasie. W sieciach często mówi się o packet delay variation. Istnieje kilka metod obliczania tego wskaźnika, więc różne aplikacje mogą podawać nieco inne wartości.

Przyjrzyjmy się dwóm seriom pomiarów RTT:

Pomiar	Łącze A	Łącze B
1	20 ms	5 ms
2	21 ms	8 ms
3	19 ms	80 ms
4	20 ms	7 ms
5	20 ms	100 ms

Łącze A jest przewidywalne. Łącze B potrafi odpowiedzieć błyskawicznie, a chwilę później każe czekać kilkanaście razy dłużej.

— Które łącze pan wybiera?
— To z pingiem pięć milisekund!
— A te sto?
— Jakie sto?
— Z następnego pomiaru.
— ...

Właśnie dlatego pojedynczy niski ping nie dowodzi jeszcze dobrej jakości połączenia.

Dlaczego jitter przeszkadza?

Podczas przeglądania stron krótkie wahania opóźnienia mogą być mało zauważalne. Ale przy rozmowach, wideokonferencjach i grach czasu rzeczywistego zaczyna robić się ciekawie.

— Słuchaj, chciałem ci powiedzieć, że…

Cisza.

— …dzisiaj…

Cisza.

— …kupiłem…

Nagle trzy fragmenty przychodzą jednocześnie.

— KUPIŁEMDZISIAJSŁUCHAJ! 🤣

Aplikacje czasu rzeczywistego często korzystają z buforów jittera, by wyrównać nierówne przychodzenie pakietów. To pomaga, ale nie jest darmowe: większy bufor może wygładzić odtwarzanie kosztem dodatkowego opóźnienia.

— Halo, słyszysz mnie?

Trzy sekundy ciszy.

— Tak.
— To dlaczego nie odpowiadałeś?!
— Odpowiedziałem od razu.
— To gdzie była odpowiedź?!
— W poczekalni.

Packet loss, czyli samochody, które nie dojechały

Do tej pory nasze samochody czasami się spóźniały. Teraz część z nich po prostu znika z pomiaru. Administrator wysyła sto prób. Odpowiedź wraca na dziewięćdziesiąt siedem. Wynik: 3% utraconych odpowiedzi.

— Trzy samochody zaginęły!
— Niekoniecznie.
— Jak to niekoniecznie?!
— Być może samochody dojechały, ale nie wróciły potwierdzenia.

Strata wykazana przez ping oznacza brak oczekiwanej odpowiedzi ICMP w określonym czasie. Przyczyną może być utrata zapytania, utrata odpowiedzi, filtrowanie, ograniczanie ICMP albo inne problemy. Nie musi to oznaczać takiego samego poziomu strat w ruchu aplikacyjnym.

A jeśli naprawdę giną pakiety z danymi? To zależy od protokołu.

Przy TCP brakujące dane mogą zostać wysłane ponownie. Zapewnia to niezawodność, ale kosztuje czas i może obniżyć przepustowość. Sam UDP nie gwarantuje retransmisji: aplikacja może zapewnić własne mechanizmy odzyskiwania danych lub zaakceptować stratę.

TCP:

— Samochód numer 57 nie dojechał.
— Proszę ponowić dostawę!
— Już wysyłamy.

UDP:

— Samochód numer 57 nie dojechał.
— Rozumiem.
— I co robimy?
— Zależy, co przewoził.
— Fragment rozmowy.
— To już go raczej nie potrzebujemy. Rozmowa jest trzy sekundy dalej.

O tych różnicach opowiadaliśmy w artykule o TCP i UDP.

Zero procent strat? Świetnie! Ale z jakiej próbki?

Kierownik autostrady dostaje raport.

— Mamy idealne łącze!
— Naprawdę?!
— Zero procent strat!
— Ile pakietów sprawdziliście?
— Cztery.
— CZTERY?!
— I wszystkie wróciły! 🤣

Cztery udane pingi nie dowodzą, że łącze nigdy nie gubi pakietów. Nawet sto udanych prób nie gwarantuje bezstratnej transmisji. Krótki pomiar może przeoczyć problem występujący tylko okresowo.

Liczy się także wzorzec strat: pojedyncze braki rozproszone w czasie to co innego niż kilka kolejnych utraconych pakietów (burst loss).

— Przecież zginęły tylko trzy samochody!
— Tak.
— To dlaczego wszyscy krzyczą?!
— Bo wszystkie trzy wiozły kolejne sekundy transmisji z finału meczu.

Bufferbloat, czyli wielki parking przed bramką

Na Autostradzie Pakietów pojawia się nowy pomysł.

— Mamy za małą przepustowość bramki!
— To może ją rozbudujemy?
— Nie. Zbudujemy przed nią ogromny parking.
— Po co?
— Żeby samochody nie ginęły!

Parking powstaje. Jest gigantyczny. Mieści tysiące pojazdów. Samochody nie muszą być od razu zawracane przy zajętej bramce. Jest tylko jeden problem: stoją w kolejce. Bardzo długo.

To dobra metafora zjawiska bufferbloat. Bufory są potrzebne, lecz nadmiernie długie kolejki przy przeciążonym łączu mogą dramatycznie zwiększyć opóźnienia.

Przy małym obciążeniu ping może wynosić 12 ms, a podczas intensywnego wysyłania danych 350 ms. Przepustowość nadal wygląda przyzwoicie, ale rozmowa głosowa jedzie przez parking wielkości województwa.

— Łącze zajęte w stu procentach!
— Czyli dobrze?
— Z punktu widzenia księgowego doskonale.
— A użytkownicy?
— Rozmawiają z przeszłością.

Mechanizmy zarządzania kolejkami, takie jak FQ-CoDel czy CAKE, mogą pomóc ograniczyć bufferbloat. Nie tworzą dodatkowej przepustowości, ale mogą sprawić, że zatłoczone łącze działa rozsądniej.

Dlaczego ping do routera pokazuje straty, a Internet działa?

Administrator bada trasę. Jeden z pośrednich routerów nie odpowiada na wiele prób ICMP.

— Mamy winnego!
— Kogo?
— Router numer sześć!
— A następne routery?
— Odpowiadają normalnie.
— A cel?
— Też.
— To skąd pan wie, że szósty gubi ruch użytkowników?!
— Bo… ma gwiazdki.

Z sąsiedniego pokoju odzywa się drugi administrator:

— Wróć do artykułu o traceroute! 🤣

Router może ograniczać odpowiedzi diagnostyczne kierowane do niego i jednocześnie prawidłowo przekazywać ruch przez swoje interfejsy.

Straty odpowiedzi z pośredniego routera, których nie widać na dalszych węzłach, nie dowodzą utraty ruchu tranzytowego właśnie tam. Jeśli problemy zaczynają się w danym miejscu i utrzymują dalej aż do celu, to ważna wskazówka, choć nadal nie zawsze jednoznaczny dowód.

Dlatego diagnozujemy całą trasę, a nie jedną czerwoną liczbę.

Co jest ważniejsze: ping, jitter czy straty?

Na naradzie kierowników pada pytanie.

— Proszę podać jedną liczbę, która określi, czy Internet jest dobry.
— Nie da się.
— Musi się dać!
— To zależy od zastosowania.

Przy pobieraniu dużych plików bardzo ważna jest przepustowość, choć opóźnienia i straty również mogą ją ograniczać. W grach przeszkadzają opóźnienia, ich nagłe skoki i utrata istotnych danych. W rozmowach głosowych liczy się przewidywalne dostarczanie pakietów, małe straty i odpowiednio niskie opóźnienie.

Przy zdalnej administracji nawet niewielka liczba strat lub nagłe skoki RTT sprawiają, że terminal reaguje jak urzędnik pięć minut przed zamknięciem okienka.

— Panie kierowniku, mamy gigabitowe łącze!
— A SSH?
— Piszę literę i czekam.
— Jak długo?
— Właśnie dotarła poprzednia. 🤣

Finał: wszystko działa zgodnie z normą

Administrator kończy diagnostykę. Zapisuje w raporcie: RTT od 12 do 480 ms, duża zmienność opóźnienia, okresowe straty odpowiedzi i znaczny wzrost RTT podczas obciążenia.

Kierownik czyta raport.

— Ale przecież samochody dojeżdżają!
— Nie wszystkie.
— Większość!
— Niektóre po pół sekundy.
— Pół sekundy to nie jest długo!
— W rozmowie telefonicznej może być.
— A przy pobieraniu pliku?
— Niekoniecznie.

Kierownik zastanawia się.

— To może ustawimy średni czas przejazdu i wszyscy będą zadowoleni?
— Jeśli jeden samochód dojeżdża po sekundzie, a drugi po godzinie, to średnio oba dojechały po pół godzinie.
— No właśnie! Bardzo dobry wynik!
— ...

Na koniec dnia na tablicy Autostrady Pakietów pojawia się komunikat:

„Ruch odbywa się bez utrudnień. Opóźnienia od 8 do 900 milisekund. Pojazdy zaginione prosimy zgłaszać po 24 godzinach.”

„Zarząd autostrady nie ponosi odpowiedzialności za brakujące fragmenty rozmów, teleportujące się pojazdy w grach sieciowych ani administratorów, którzy podczas pisania na SSH zdążyli zapomnieć, co chcieli napisać.” 🤣