Ustaw budżet opóźnienia dla ruchu czasu rzeczywistego przez VPN

Skargi dotyczące VPN w czasie rzeczywistym potrzebują terminu, wobec którego mogą zawieść, a «niskie opóźnienie» nie jest terminem. Zdecyduj, co musi dostarczyć rozmowa lub sesja zdalna, a następnie zmierz ścieżkę wobec tego wymagania w podanych warunkach. Bez progu spóźnionych pakietów każdy wynik jest sporny. Podział poniżej jest decyzją projektową i istnieje po to, aby pomiar miał na co odpowiedzieć.

Zapisz termin, zanim dotkniesz sondy

Termin pochodzi z aplikacji i jej użytkowników, a nie ze strony marketingowej dostawcy. Połączenie głosowe na żywo, sesja pulpitu zdalnego i nocna kopia zapasowa znoszą zupełnie różne czasy oczekiwania, a istotna awaria to zwykle ogon, a nie mediana. Zapisz liczbę razem z obciążeniem, do którego należy.

Następnie rozdziel go. Przechwytywanie i paketyzacja zużywają część budżetu, łącze dostępowe i tunel inną część, bufor de-jitter odbiorcy celowo wstrzymuje pakiety, a przetwarzanie aplikacji bierze resztę. Nazwanie tych etapów utrzymuje szyfrowanie tunelu w proporcji, zamiast czynić je domyślnym podejrzanym dla każdego wolnego pakietu.

Na koniec zdefiniuj kontrakt pomiaru w czterech liniach: punkty końcowe i kierunek, kształt ruchu, warunki podczas przebiegu i wynik, który zgłosisz. Cicha niedzielna próbka i obciążona wtorkowa próbka odpowiadają na różne pytania, więc wskaż, którą zebrałeś. Jeśli nie możesz wypełnić wszystkich czterech linii, przebieg nie jest gotowy do rozpoczęcia. Ta lista kontrolna jest też tym, co czyni dwa raporty porównywalnymi miesiące później, gdy nikt już nie pamięta, co jeszcze niósł łącz.

Rozdziel budżet na każdy etap

Tabela jest pomocą planistyczną, a nie przechwyconymi danymi. Wypełnij właściciela każdego wiersza przed pierwszą sondą, bo właściciel to osoba, do której dzwonisz, gdy ten etap przekroczy swój udział.

Dwa wiersze zwykle zaskakują ludzi. Bufor odbiorcy nie jest usterką, gdy dodaje opóźnienie, bo wykonuje pracę, do której został skonfigurowany. A udział tunelu jest często mniejszy niż kolejka przed nim, zwłaszcza na łączu wysyłania, które nasyca się podczas przesyłania.

Gdy etap nie ma właściciela, budżet jest fikcją. Wyznacz kogoś przed pomiarem, inaczej spędzisz następne spotkanie na kłótni o to, czyja liczba jest błędna.

Zmierz opóźnienie jednokierunkowe uczciwym zegarem

Opóźnienie jednokierunkowe to liczba, na której zależy terminowi, i wymaga zsynchronizowanych zegarów na obu końcach. Metryka opóźnienia jednokierunkowego wymaga podania obok wyniku metody synchronizacji, rozdzielczości i szacowanego odchylenia. Dwa niezsynchronizowane hosty mogą dać bardzo precyzyjną liczbę dla niewłaściwej wielkości.

Przechwyć kilka setek pakietów zamiast garści i zanotuj stan zegara w tym samym czasie:

$ ntpq -p
$ owping -c 300 -i 0.2 10.90.0.1
$ ping -c 200 -i 0.2 10.90.0.1 | tail -n 3

Czas rundy jest osobnym pomiarem, a nie dwiema sumowanymi wartościami jednokierunkowymi. Połowienie RTT zakłada symetryczne ścieżki i symetryczne kolejki, a tunel nad mobilnym łączem wysyłania regularnie łamie oba założenia. Raportuj RTT jako RTT i trzymaj je poza budżetem jednokierunkowym.

Raportuj ogon i spóźnione pakiety

Podsumuj rozkład: medianę, 95. i 99. percentyl, najgorszy przypadek, stratę i liczbę pakietów, które dotarły później, niż pozwala termin. Średnia jest z tych liczb najmniej użyteczna dla obciążenia czasu rzeczywistego, bo gładka średnia może ukryć ogon, który psuje co trzecie połączenie.

Zmienność opóźnienia zasila bezpośrednio bufor odbiorcy. Większe buforowanie ukrywa zmienność i dodaje oczekiwanie, więc strumień może wyglądać stabilnie, przekraczając swój termin. Wybierz formułę zmienności, wskaż interwał, w którym mierzyłeś, i zachowaj jej spójność między przebiegami.

Powtórz przebieg z reprezentatywnym ruchem krzyżowym. Ścieżka, która spełnia budżet, gdy jest bezczynna, i nie spełnia go w oknie kopii zapasowej, powiedziała ci coś użytecznego o planowaniu, czego nie ujawniłby żaden pojedynczy cichy pomiar. Zapisz warunki obok wyniku, bo następny inżynier inaczej porówna dwie próbki, które nigdy nie były porównywalne.

Zaakceptuj projekt, gdy zmierzony ogon mieści się w budżecie przy obciążeniu, które naprawdę uruchamiasz, a odrzuć go, wskazując w raporcie etap, który przekroczył limit.