W przypadku wielu zadań opóźnienia między klientem a serwerem są krytyczne, na przykład w grach online, konferencjach wideo/głosowych, telefonii IP, VPN itp. Jeśli serwer jest zbyt daleko od klienta na poziomie sieci IP, wówczas opóźnienia (popularnie zwane „pingiem”, „lagiem”) będą zakłócać pracę.
Bliskość geograficzna serwera nie zawsze jest równoznaczna z bliskością na poziomie routingu IP. Na przykład serwer w innym kraju może być „bliżej” Ciebie niż serwer w Twoim mieście. Wszystko ze względu na specyfikę routingu i budowy sieci.
Jak wybrać serwer, który będzie jak najbliżej wszystkich potencjalnych klientów? Co to jest łączność sieciowa IP? Jak skierować klienta do najbliższego serwera? Dowiemy się tego w artykule.
Pomiar opóźnień
Najpierw nauczmy się mierzyć opóźnienia. To zadanie nie jest tak proste, jak mogłoby się wydawać, ponieważ opóźnienia mogą się różnić w zależności od protokołów i rozmiarów pakietów. Możesz także przegapić zdarzenia krótkoterminowe, takie jak spadki trwające kilka milisekund.
ICMP - regularny ping
Wykorzystamy uniksowe narzędzie ping, które pozwala ręcznie ustawić odstępy między wysyłaniem pakietów, czego nie potrafi wersja ping dla systemu Windows. Jest to ważne, ponieważ jeśli między pakietami są długie przerwy, możesz po prostu nie widzieć, co się między nimi dzieje.
Wielkość paczki (opcja -s) - domyślnie narzędzie ping wysyła pakiety o rozmiarze 64 bajtów. Przy tak małych pakietach zjawiska zachodzące przy większych pakietach mogą nie być zauważalne, dlatego ustawimy rozmiar pakietu na 1300 bajtów.
Odstęp między pakietami (opcja -i) — czas pomiędzy wysłaniem danych. Domyślnie pakiety wysyłane są raz na sekundę, jest to bardzo długi czas, prawdziwe programy wysyłają setki i tysiące pakietów na sekundę, dlatego interwał ustawimy na 0.1 sekundy. Program po prostu nie pozwala na mniej.
W rezultacie polecenie wygląda następująco:
ping -s 1300 -i 0.1 yandex.ru
Taka konstrukcja pozwala zobaczyć bardziej realistyczny obraz opóźnień.
Pinguj przez UDP i TCP
W niektórych przypadkach połączenia TCP są przetwarzane inaczej niż pakiety ICMP i z tego powodu pomiary mogą się różnić w zależności od protokołu. Często zdarza się również, że host po prostu nie odpowiada na ICMP, a zwykłe pingowanie nie działa. Tak na przykład robi gospodarz przez całe życie. microsoft.com.
Użyteczność od twórców słynnego skanera nmap może generować dowolne pakiety. Można go również wykorzystać do pomiaru opóźnień.
Ponieważ UDP i TCP działają na określonych portach, musimy „pingować” konkretny port. Spróbujmy pingować TCP 80, czyli port serwera WWW:
$ sudo nping --tcp -p 80 --delay 0.1 -c 0 microsoft.com
Starting Nping 0.7.80 ( https://nmap.org/nping ) at 2020-04-30 13:07 MSK
SENT (0.0078s) TCP 10.0.0.1:63236 > 13.77.161.179:80 S ttl=64 id=49156 iplen=40 seq=3401731188 win=1480
SENT (0.1099s) TCP 10.0.0.1:63236 > 13.77.161.179:80 S ttl=64 id=49156 iplen=40 seq=3401731188 win=1480
RCVD (0.2068s) TCP 13.77.161.179:80 > 10.0.0.1:63236 SA ttl=43 id=0 iplen=44 seq=1480267007 win=64240 <mss 1440>
SENT (0.2107s) TCP 10.0.0.1:63236 > 13.77.161.179:80 S ttl=64 id=49156 iplen=40 seq=3401731188 win=1480
RCVD (0.3046s) TCP 13.77.161.179:80 > 10.0.0.1:63236 SA ttl=43 id=0 iplen=44 seq=1480267007 win=64240 <mss 1440>
SENT (0.3122s) TCP 10.0.0.1:63236 > 13.77.161.179:80 S ttl=64 id=49156 iplen=40 seq=3401731188 win=1480
RCVD (0.4247s) TCP 13.77.161.179:80 > 10.0.0.1:63236 SA ttl=42 id=0 iplen=44 seq=2876862274 win=64240 <mss 1398>
Max rtt: 112.572ms | Min rtt: 93.866ms | Avg rtt: 101.093ms
Raw packets sent: 4 (160B) | Rcvd: 3 (132B) | Lost: 1 (25.00%)
Nping done: 1 IP address pinged in 0.43 seconds
Domyślnie nping wysyła 4 pakiety i zatrzymuje się. Opcja -c0 umożliwia niekończące się wysyłanie pakietów, aby zatrzymać program należy nacisnąć Ctrl+C. Na koniec zostaną wyświetlone statystyki. Widzimy, że średnia wartość rtt (czas podróży w obie strony) wynosi 101 ms.
MTR - traceroute na sterydach
Program My Traceroute to zaawansowane narzędzie do śledzenia tras do zdalnego hosta. W przeciwieństwie do zwykłego narzędzia systemowego traceroute (w systemie Windows jest to narzędzie tracert), może ono pokazywać opóźnienia każdemu hostowi w łańcuchu pakietów. Może także śledzić trasy nie tylko poprzez ICMP, ale także poprzez UDP i TCP.
$ sudo mtr microsoft.com
(Klikalny) interfejs programu MTR. Rozpoczęło się śledzenie trasy do witryny microsoft.com
MTR natychmiast pokazuje ping każdemu hostowi w łańcuchu, a dane są stale aktualizowane podczas działania programu i można zobaczyć krótkotrwałe zmiany.
Zrzut ekranu pokazuje, że w węźle nr 6 występują straty pakietów, ale w rzeczywistości nie jest to do końca prawdą, ponieważ niektóre routery mogą po prostu odrzucać pakiety z wygasłym TTL i nie zwracać odpowiedzi na błąd, więc dane o utracie pakietów można tutaj zignorować.
Wi-Fi vs kabel
Temat ten nie do końca dotyczy artykułu, ale moim zdaniem jest bardzo ważny w kontekście opóźnień. Bardzo lubię Wi-Fi, ale jeśli tylko będę miała choćby najmniejszą możliwość połączenia się z Internetem kablem, to z niego skorzystam. Zawsze też odradzam ludziom korzystanie z kamer WiFi.
Jeśli grasz w poważne strzelanki online, przesyłasz strumieniowo wideo lub handlujesz na giełdzie: korzystaj z Internetu za pomocą kabla.
Oto test wizualny porównujący połączenia WiFi i kablowe. To jest ping do routera Wi-Fi, czyli jeszcze nie do Internetu.
(Klikalne) Porównanie pingu do routera Wi-Fi za pośrednictwem kabla i Wi-Fi
Można zauważyć, że w przypadku Wi-Fi opóźnienie jest o 1 ms dłuższe, a czasami zdarzają się pakiety z opóźnieniami dziesięciokrotnie większymi! A to tylko krótki okres czasu. Jednocześnie ten sam router wytwarza stabilne opóźnienia <1 ms.
W powyższym przykładzie używane jest Wi-Fi 802.11n na częstotliwości 2.4 GHz, do punktu dostępowego Wi-Fi podłączony jest jedynie laptop i telefon. Gdyby w punkcie dostępowym było więcej klientów, wyniki byłyby znacznie gorsze. Dlatego jestem przeciwny przełączaniu wszystkich komputerów biurowych na Wi-Fi, jeśli można się z nimi połączyć za pomocą kabla.
Łączność IP
Nauczyliśmy się więc mierzyć opóźnienia na serwerze, spróbujmy znaleźć serwer najbliższy nam. W tym celu możemy sprawdzić, jak działa routing naszego dostawcy. W tym celu wygodnie jest skorzystać z usługi
Kiedy uzyskujemy dostęp do witryny, widzimy, że nasz adres IP należy do systemu autonomicznego .
Patrząc na wykres łączności systemów autonomicznych, możemy zobaczyć, za pośrednictwem których dostawców wyższego poziomu nasz dostawca jest połączony z resztą świata. Każdą z kropek można kliknąć, można wejść i przeczytać, jaki to dostawca.
Wykres łączności systemów autonomicznych dostawcy
Za pomocą tego narzędzia możesz zbadać strukturę kanałów dowolnego dostawcy, w tym hostingu. Zobacz, z którymi dostawcami jest bezpośrednio połączony. Aby to zrobić, musisz wpisać adres IP serwera w wyszukiwarce bgp.he.net i spojrzeć na wykres jego autonomicznego systemu. Możesz także zrozumieć, w jaki sposób jedno centrum danych lub dostawca usług hostingowych jest połączone z innym.
Większość punktów wymiany ruchu udostępnia specjalne narzędzie zwane lustrem, które umożliwia pingowanie i śledzenie trasy z określonego routera w punkcie wymiany.
Tutaj, na przykład, z MGTS
Wybierając więc serwer, możemy z góry zobaczyć, jak będzie on wyglądał z różnych punktów wymiany ruchu. A jeśli nasi potencjalni klienci znajdują się w określonym obszarze geograficznym, możemy znaleźć optymalną lokalizację dla serwera.
Wybierz najbliższy serwer
Postanowiliśmy uprościć procedurę wyszukiwania optymalnego serwera dla naszych klientów i stworzyliśmy stronę z automatycznym testowaniem pobliskich lokalizacji: .
Kiedy odwiedzasz stronę, skrypt mierzy opóźnienia między Twoją przeglądarką a każdym serwerem i wyświetla je na interaktywnej mapie. Po kliknięciu centrum danych wyświetlają się informacje z wynikami testów.
Przycisk przenosi Cię do strony testu opóźnienia dla wszystkich naszych centrów danych. Aby wyświetlić wyniki testu, kliknij punkt centrum danych na mapie
Źródło: www.habr.com