ping: co ta komenda naprawdę mierzy i kiedy jej wynik myli

Ping mierzy czas powrotu małego pakietu ICMP do wskazanego hosta. Nie mierzy prędkości łącza ani tego, czy strona działa. Pojedyncze wywołanie niczego nie dowodzi, więc pytaj o serię i patrz na trzy liczby naraz - stratę pakietów, czas średni i rozrzut czasów.

Seria, z której da się coś wyczytać, wygląda tak:

ping -c 20 1.1.1.1

W Windows odpowiednikiem jest ping -n 20 1.1.1.1. Zanim jednak wpiszesz adres, ustal, o co właściwie pytasz - bo ta sama komenda odpowiada na inne pytanie w zależności od tego, dokąd ją wyślesz.

Co ping naprawdę mierzy?

Komenda wysyła pakiet ICMP Echo Request i czeka na Echo Reply. Ten mechanizm opisuje RFC 792 dla IPv4 i RFC 4443 dla IPv6. Zmierzony czas to RTT, czyli droga w obie strony razem z obsługą po stronie odbiorcy.

Z tego wynikają trzy granice, których nie da się obejść żadnym przełącznikiem. Ping nie powie ci, ile danych przepchniesz przez łącze, bo pakiet ma kilkadziesiąt bajtów. Nie powie, czy aplikacja odpowiada, bo warstwa HTTP w ogóle nie bierze udziału w teście. Nie powie też, którędy szła odpowiedź - trasa tam i z powrotem bywa różna.

Typowy scenariusz zgłoszenia „internet jest wolny” wygląda tak. Ping do bramy wraca natychmiast, ping do serwera usługi wraca bez strat i z normalnym opóźnieniem, a przeglądarka i tak mieli. Sieć lokalna działa, trasa do serwera działa. Skoro warstwa sieciowa dowozi pakiety, przyczyny szukaj w zajętości łącza albo w samej usłudze. Ping tego nie rozstrzygnie, bo małe pakiety przechodzą nawet przez zapchane łącze.

Dobry ping z pustą przeglądarką to typowy obraz. Ta komenda odpowiada na pytanie o osiągalność i opóźnienie, nie o wydajność.

Jak czytać wynik ping?

Tak wygląda budowa wyniku serii pięciu pakietów w składni BSD i macOS. Liczby są przykładowe i służą do omówienia pól, nie są pomiarem twojego łącza:

PING 1.1.1.1 (1.1.1.1): 56 data bytes
64 bytes from 1.1.1.1: icmp_seq=0 ttl=59 time=18.106 ms
64 bytes from 1.1.1.1: icmp_seq=1 ttl=59 time=30.567 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=59 time=17.826 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=59 time=17.843 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=59 time=20.075 ms

--- 1.1.1.1 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 17.826/20.883/30.567/4.914 ms

Każde pole niesie inną informację:

Czytaj te liczby w kolejności. Strata pakietów rozstrzyga, czy trasa w ogóle dowozi ruch. Czas średni mówi o dystansie i jakości trasy. Odchylenie standardowe, potocznie nazywane jitterem, decyduje o tym, czy rozmowa głosowa i wideokonferencja będą używalne. Przy dużym rozrzucie połączenie rwie się nawet wtedy, gdy średnia wygląda przyzwoicie.

Powyższy przykład pokazuje dokładnie taki przypadek w miniaturze. Średnia 20,9 ms jest dobra, ale jeden pakiet wrócił po 30,6 ms, co podbiło odchylenie do 4,9 ms. Przy dwudziestu pakietach zobaczyłbyś, czy to przypadek, czy reguła.

Ile pakietów wysłać, żeby wynik coś znaczył?

Cztery pakiety, które Windows wysyła domyślnie, wystarczają wyłącznie do pytania „czy host w ogóle odpowiada”. Strata rzędu kilku procent w takiej próbce jest niewidoczna, bo najmniejszy mierzalny krok to 25 punktów procentowych.

Do diagnozy używaj serii przynajmniej dwudziestu pakietów, a przy objawie występującym co jakiś czas puść ping na kilka minut i zapisz wynik do pliku. Liczy się nie chwila, tylko rozkład.

Różnica domyślnych zachowań jest tu ważniejsza niż nazwy przełączników. W Windows ping kończy się sam po czterech pakietach, w Linuksie i macOS działa, aż go zatrzymasz przez Ctrl+C - i dopiero wtedy wypisuje podsumowanie statystyk.

Jak sprawdzić wynik w skrypcie?

W Linuksie i macOS ping ustawia kod wyjścia, więc nie musisz parsować tekstu. Zero oznacza, że przyszła co najmniej jedna odpowiedź. Wartość różna od zera oznacza brak odpowiedzi albo błąd wcześniejszy niż sama wysyłka. Na tym kodzie opieraj skrypt tylko w tych systemach - ping w Windows bywa zakończony zerem także wtedy, gdy w treści wyniku widnieje komunikat o nieosiągalnym hoście, więc tam sprawdzaj dodatkowo samą treść odpowiedzi.

Nazwa, której nie da się rozwiązać, kończy pracę zanim poleci pierwszy pakiet:

ping: cannot resolve nieistniejaca-domena.pl: Unknown host

Ten komunikat to problem DNS, nie problem sieci - i prowadzi w zupełnie inną stronę niż brak odpowiedzi od poprawnie rozwiązanego adresu. Gdy przeglądarka pokazuje przy tym własny komunikat o nieznanej nazwie, zacznij od diagnozy odpowiedzi NXDOMAIN, zamiast pingować dalej. Samą nazwę sprawdzisz wtedy zapytaniem do serwera DNS przez nslookup.

W monitoringu opieraj się na kodzie wyjścia i na progu straty pakietów liczonym z serii. Alert na pojedynczy nieudany pakiet będzie budził cię co noc bez powodu.

Kiedy ping kłamie?

Brak odpowiedzi nie dowodzi, że host nie działa. ICMP jest ruchem pomocniczym i bywa traktowany inaczej niż ruch użytkowy - z trzech powodów, które warto rozróżniać.

1. Zapora blokuje Echo Request albo Echo Reply. Host żyje i obsługuje klientów, ale na ping nie odpowie. Serwery wystawione do internetu bywają tak ustawione celowo.
2. Urządzenie sieciowe ogranicza tempo obsługi ICMP. Odpowiedzi zaczynają ginąć przy większej częstotliwości pakietów, choć ruch przechodzący przez to samo urządzenie ma się dobrze.
3. Router odpowiada na ping własnym procesorem, z niskim priorytetem. Wysoki czas odpowiedzi od pośredniego urządzenia w trasie nie oznacza więc, że przez to urządzenie ruch idzie wolno.

Trzeci punkt bywa źródłem fałszywych alarmów. Ping do konkretnego przeskoku mierzy, jak szybko ten przeskok odpowiada na uprzejmość, a nie jak szybko przekazuje pakiety dalej. Wnioski o trasie wyciągaj z narzędzia, które bada każdy przeskok osobno, czyli z traceroute w Linuksie i macOS albo tracert w Windows.

Jeśli ping milczy, a chcesz wiedzieć, czy usługa nasłuchuje, zapytaj o port zamiast o host. Test połączenia z konkretną usługą rozstrzyga to, czego ICMP nie rozstrzygnie nigdy - a gdy dostajesz aktywną odmowę połączenia, prowadź diagnozę od komunikatu o odrzuconym połączeniu.

Co znaczy wartość TTL w odpowiedzi?

TTL to licznik przeskoków, który każdy router po drodze zmniejsza o jeden. Pakiet z wyzerowanym licznikiem jest odrzucany, dzięki czemu ruch nie krąży w nieskończoność przy błędnej konfiguracji tras.

W odpowiedzi widzisz wartość, która została po przejściu trasy. Nadawca wysyła ją z wartością początkową charakterystyczną dla swojego systemu - 64 albo 255 w systemach uniksowych i 128 w Windows. Odejmując widzianą liczbę od najbliższej wyższej wartości typowej, oszacujesz liczbę przeskoków.

W przykładzie z poprzedniej sekcji TTL wynosi 59, a odpowiadający host startuje od 64 - różnica wskazuje na około pięć routerów po drodze. Traktuj to jako wskazówkę, nie pomiar. Zmiana TTL w trakcie jednej serii jest za to sygnałem konkretnym i wartym uwagi, bo oznacza, że trasa przełączyła się na inną.

Jak pingiem znaleźć problem z MTU?

MTU to największy pakiet, który przejdzie przez trasę bez dzielenia. Zbyt duża wartość ustawiona po drodze objawia się nietypowo - proste strony otwierają się normalnie, a większe transfery i połączenia VPN stają w miejscu.

Test polega na wysłaniu pakietu z zakazem fragmentacji i zmniejszaniu rozmiaru, aż odpowiedź zacznie wracać. Przełącznik zakazu jest inny w każdym systemie i to jest tu najważniejszy szczegół:

# Linux (iputils)
ping -c 3 -M do -s 1472 example.com

# macOS i BSD
ping -c 3 -D -s 1472 example.com

:: Windows
ping -n 3 -f -l 1472 example.com

Nie przenoś tych przełączników między systemami. W Linuksie -D nie ustawia zakazu fragmentacji, tylko dokłada znaczniki czasu do wierszy wyniku - komenda przejdzie mimo za małego MTU i wyprowadzi cię na manowce. Rozmiar danych podajesz przez -s w systemach uniksowych i przez -l w Windows. Wartość 1472 plus 28 bajtów nagłówków daje 1500, czyli typowe MTU sieci Ethernet.

Gdy pakiet tej wielkości nie przechodzi, zejdź do 1452, potem do 1400 i notuj pierwszą działającą wartość. Do tej liczby dodaj 28 - wynik to rzeczywiste MTU trasy. Obniżenie MTU na routerze albo w konfiguracji tunelu jest właściwą naprawą; wyłączanie fragmentacji na ślepo nią nie jest.

Co zrobić z wynikiem?

Zapisując wynik dla kogoś innego, podaj komplet: adres celu, liczbę pakietów, procent straty, czasy min/avg/max oraz miejsce, z którego padła komenda. Bez ostatniej informacji druga osoba zmierzy inną trasę i będzie diagnozować inny problem.

Dalsza droga zależy od tego, co zobaczyłeś:

1. Zero strat i niskie czasy oznaczają, że warstwa sieciowa nie jest winna - szukaj wyżej, w usłudze albo w aplikacji.
2. Straty rosnące z odległością prowadzą do traceroute i do rozmowy z operatorem, który odpowiada za odcinek trasy.
3. Całkowity brak odpowiedzi przy działającej stronie wskazuje na zablokowany ICMP, nie na awarię.
4. Objaw dotyczący jednej usługi u wielu osób nie jest problemem sieci lokalnej - sprawdź wtedy, czy zawiódł dostawca usługi.

Pozostałe polecenia, którymi domykasz taką diagnozę na serwerze, zbieramy w mapie komend administracyjnych.

Pytania o komendę ping

Co to jest ping?

To polecenie sprawdzające, czy wskazany host odpowiada, i mierzące czas powrotu pakietu ICMP. Wynik podawany jest w milisekundach jako RTT, czyli czas drogi w obie strony. Ping nie mierzy przepustowości łącza i nie sprawdza, czy działa strona albo usługa pod danym adresem.

Jaki ping jest dobry?

Dla łącza stacjonarnego w kraju typowe wartości do bliskiego serwera mieszczą się w kilkunastu milisekundach, a połączenie międzykontynentalne dodaje ich ponad sto. Ważniejsza od samej liczby jest jej stabilność - równe 40 ms bywa lepsze w praktyce niż wynik skaczący między 10 a 60 ms.

Jak zatrzymać ping w Linuksie?

Naciśnij Ctrl+C. Polecenie przerwie wysyłanie i wypisze podsumowanie z liczbą pakietów, procentem straty i rozkładem czasów. Jeśli chcesz z góry ustalić długość serii, użyj ping -c 20 host - komenda zakończy się sama po dwudziestu pakietach.

Dlaczego serwer nie odpowiada na ping, choć strona działa?

Bo ktoś zablokował ICMP na zaporze albo na urządzeniu brzegowym. Ruch HTTP i HTTPS idzie wtedy normalnie, a Echo Request nie wraca. Brak odpowiedzi na ping nie jest dowodem awarii - żeby sprawdzić usługę, testuj konkretny port, nie osiągalność hosta.

Czym różni się ping od traceroute?

Ping bada jeden punkt końcowy i mówi, czy odpowiada oraz jak szybko. Traceroute pokazuje kolejne przeskoki na trasie do celu wraz z czasami dla każdego z nich. Gdy ping wykaże straty, traceroute podpowiada, na którym odcinku ich szukać.