Do czego służy polecenie ping i jak interpretować jego wyniki?

Polecenie ping służy do weryfikacji połączenia sieciowego na poziomie protokołu IP oraz mierzenia opóźnień w transmisji danych między Twoim komputerem a docelowym serwerem. Otrzymane wyniki interpretuje się na podstawie czasu odpowiedzi wyrażonego w milisekundach (RTT), procentowej utraty pakietów oraz wartości TTL, co pozwala szybko namierzyć awarie infrastruktury, zatory na łączach lub błędy z routingiem. Narzędzie to działa w oparciu o protokół ICMP. My wysyłamy żądanie Echo Request, a maszyna po drugiej stronie odsyła nam Echo Reply. Prosty mechanizm. Daje jednak ogromną ilość informacji o kondycji sieci.

Do czego służy polecenie ping i jak interpretować jego wyniki w codziennej pracy? Przede wszystkim do szybkiej diagnozy. Zanim zaczniesz dzwonić do dostawcy internetu albo przeinstalowywać sterowniki karty sieciowej, odpalasz wiersz poleceń. Wpisujesz cztery litery i adres. Od razu wiesz, czy problem leży na Twoim biurku, na routerze w przedpokoju, czy gdzieś w serwerowni we Frankfurcie. W tym tekście rozbierzemy mechanikę tego procesu na części pierwsze. Bez owijania w bawełnę. Pokażę Ci, jak ja to robię na co dzień, analizując zatory i zgubione pakiety.

Jak działa pingowanie od strony technicznej protokołu ICMP?

Mechanizm jest stary jak sam internet. Autorem narzędzia jest Mike Muuss, który napisał ten kod w 1983 roku. Ping nie używa popularnych protokołów transportowych takich jak TCP czy UDP. Działa bezpośrednio na warstwie sieciowej, wykorzystując Internet Control Message Protocol (ICMP). Kiedy wpisujesz komendę w terminalu, Twój system operacyjny formuje mały pakiet danych. Zazwyczaj ma on 32 bajty w systemach Windows i 56 bajtów w środowisku Linux. Ten pakiet leci przez wszystkie węzły sieciowe, switche i routery po drodze.

Serwer docelowy ma obowiązek odebrać ten pakiet i natychmiast odesłać go z powrotem. Twój komputer mierzy czas od momentu naciśnięcia entera do chwili powrotu danych. Ten czas nazywamy Round Trip Time (RTT). To jest właśnie ten słynny ping mierzony w milisekundach. Im niższy, tym lepiej.

Zastanawiacie się zresztą, dlaczego to na produkcji tak często wywala błędy na testach po drodze? Sam się nad tym borykałem u siebie we wtorek. Problem polega na tym, że routery traktują ruch ICMP priorytetowo zupełnie inaczej niż zwykły ruch HTTP. Często celowo go zrzucają, żeby chronić swoje procesory przed przeciążeniem. Więc brak odpowiedzi na ping wcale nie musi oznaczać awarii całej usługi internetowej. To po prostu objaw odrzucenia konkretnego typu żądania przez zaporę sieciową.

Dlaczego czasami serwer nie odpowiada na polecenie ping?

Zjawisko braku odpowiedzi to chleb powszedni każdego administratora. Widzimy na ekranie komunikat o upłynięciu limitu czasu żądania i od razu zakładamy najgorsze. To błąd. Istnieją bardzo konkretne powody, dla których echo nie wraca do nadawcy.

• Większość nowoczesnych systemów operacyjnych ma domyślnie włączonego firewalla, który po cichu blokuje wszystkie przychodzące pakiety ICMP Echo Request, żeby uchronić maszynę przed masowymi skanowaniami z zewnątrz i próbami ataków typu DDoS z wykorzystaniem botnetów. Zanim zaczniesz szukać winy w kablach, sprawdź reguły zapory w Windows Defenderze albo iptables na serwerze docelowym.
• Urządzenie fizycznie straciło zasilanie lub zostało odpięte od switcha.
• Błędna tablica routingu u dostawcy. Zdarza się to rzadko, ale czasem pakiety po prostu wpadają w czarną dziurę (tzw. blackhole routing) i gubią trasę powrotną do Twojego modemu.
• Maszyna jest tak obciążona ruchem aplikacyjnym, że system operacyjny kolejkuje pakiety ICMP na samym końcu, co powoduje przekroczenie czasu oczekiwania.

Z doświadczenia wiem, że diagnoza potrafi trwać godzinami. Zrobiliśmy na wdrożeniu w małym biurze we Wrocławiu na Krzykach prostą migrację sieci LAN. Wymieniliśmy stary router na nowy sprzęt. Po reboocie ping do bramy domyślnej zniknął. Szukaliśmy pętli w sieci, podejrzewaliśmy uszkodzone kable kategorii szóstej. Prawda okazała się banalna. Nowy firmware routera miał zaszyty błąd w obsłudze VLAN-ów i po prostu ignorował zapytania ICMP z podsieci administracyjnej. Wgranie łatki naprawiło problem w pięć minut. Tak to działa na prawdziwym sprzęcie.

Co oznaczają wartości TTL (Time to Live) i jak je czytać?

Zwróciłeś uwagę na parametr TTL w wynikach? To nie jest czas mierzony w sekundach. To licznik życia pakietu, wyrażony w ilości skoków (hopów) przez kolejne routery. Wymyślono to po to, żeby zapobiec krążeniu zgubionych pakietów w nieskończoność po pętlach sieciowych. Gdyby nie TTL, internet zapchałby się śmieciowym ruchem w kilka godzin.

Każdy system operacyjny ma swoją domyślną początkową wartość TTL wysyłanego pakietu. Windows zazwyczaj startuje z pułapu 128. Linux i macOS rzucają pakiet z wartością 64. Sprzęt sieciowy, taki jak routery Cisco, często generuje pakiety z TTL równym 255. Każdy router na trasie, przez który przechodzi Twój pakiet ICMP, odejmuje od tej wartości jedynkę. Kiedy licznik spadnie do zera, router niszczy pakiet i odsyła Ci komunikat „TTL expired in transit” (Upłynął czas życia pakietu w locie).

Dzięki temu parametrowi możesz w miarę dokładnie oszacować, jak daleko fizycznie i topologicznie znajduje się serwer docelowy. Jeśli pingujesz maszynę z systemem Linux (startowe TTL 64) i w terminalu widzisz odpowiedź z TTL równym 54, oznacza to prostą matematykę. Pakiet przeszedł przez 10 routerów po drodze (64 minus 54). Oczywiście to tylko szacunki, bo administratorzy mogą ręcznie modyfikować te wartości w jądrze systemu.

Zgubione pakiety (Packet Loss) – jak diagnozować awarie łącza?

Samo opóźnienie w milisekundach to tylko jedna strona medalu. Najgorszym wrogiem stabilnego połączenia jest zjawisko gubienia pakietów. W wierszu poleceń widzisz to na samym końcu, w krótkim podsumowaniu statystyk. Jeśli wysłałeś 100 pakietów, a wróciło 95, masz 5% utraty. W grach online typu shooter czy podczas rozmów na Teamsach to absolutna katastrofa.

(Prawda jest zresztą absolutnie taka, że początkujący admini często ignorują 1-2% straty, twierdząc że to norma na łączach radiowych. Gówno prawda. Na sprawnym łączu światłowodowym utrata pakietów musi wynosić okrągłe zero. Zawsze. Jakikolwiek drop oznacza uszkodzoną wkładkę SFP, zagięty patchcord albo przeciążony port na switchu u operatora.)

Statystyki pokazują, że w zdecydowanej większości, bo bez mała prawie osiemdziesiąt procent problemów z przerywaniem głosu na komunikatorach wynika właśnie z mikroutrat pakietów, których nie widać przy standardowym, krótkim teście złożonym z czterech zapytań. Dlatego do prawdziwej diagnostyki używamy ciągłego wysyłania żądań. W systemie Windows robimy to za pomocą dopisanego na końcu parametru `-t`.

Jakie parametry ma komenda ping i jak wymusić ciągły test?

Standardowe odpalenie komendy w Windowsie wysyła tylko cztery pakiety i kończy pracę. To stanowczo za mało, żeby złapać chwilowe niestabilności łącza. Żeby wyciągnąć z tego narzędzia prawdziwe dane, musisz użyć dodatkowych przełączników w terminalu. W systemach uniksowych test leci domyślnie w nieskończoność, dopóki go nie zatrzymasz kombinacją klawiszy CTRL+C. W oknach od Microsoftu trzeba system do tego zmusić.

Oto zestawienie najważniejszych modyfikatorów, których używam przy weryfikacji awarii:

Zmieniliśmy te zasady na robocie w zeszłym miesiącu. Zamiast kazać chłopakom z helpdesku zgadywać, dlaczego VPN zrywa połączenie, wymusiliśmy procedurę sprawdzania rozmiaru pakietu. Odpalasz komendę z rozmiarem ustawionym na 1500 bajtów i flagą zakazującą fragmentacji (`ping -f -l 1500 adres_ip`). Jeśli dostajesz błąd, że pakiet musi być sfragmentowany, od razu wiesz, że masz problem z konfiguracją MTU na interfejsie. Proste, twarde dane zamiast wróżenia z fusów. To jest bez mała najgorsza opcja z wszystkich, gdy admini szukają błędu w aplikacji, a winna jest warstwa trzecia sieci.

Jaki czas opóźnienia RTT uważa się za akceptowalny?

Ocena wyników zależy od tego, co fizycznie robisz w sieci. Nie ma jednej, uniwersalnej granicy dobrego i złego czasu odpowiedzi. Fizyka ma swoje ograniczenia. Sygnał świetlny w kablu światłowodowym potrzebuje czasu, żeby pokonać odległość z Warszawy do Nowego Jorku. Średnio to około 90-110 milisekund samego fizycznego opóźnienia, wynikającego z prędkości propagacji światła w szkle. Tego nie przeskoczysz żadnym sprzętem.

W przypadku sieci lokalnej (LAN), ping do Twojego routera powinien wynosić poniżej 1 milisekundy. Często terminal wyświetla to jako `czas<1 ms`. Połączenia na światłowodzie do krajowych serwerów zamykają się zazwyczaj w przedziale od 5 do 20 milisekund. To jakość, przy której gry e-sportowe działają bez najmniejszego zauważalnego laga, a strony internetowe ładują się błyskawicznie.

Gdy wynik waha się w granicach 50-100 milisekund, mówimy o standardowym połączeniu na terenie Europy. Dla pracy biurowej, przeglądania stron i pobierania plików jest to wartość w zupełności wystarczająca. Schody zaczynają się powyżej 150 milisekund. Wtedy zaczynasz odczuwać opóźnienie w rejestracji kliknięć na zdalnych pulpitach (RDP). Powyżej 300 milisekund rozmowy głosowe stają się uciążliwe, bo wchodzicie sobie w słowo z rozmówcą przez opóźniony tor audio. Takie wyniki to norma dla internetu satelitarnego starej generacji.

Czy narzędzie to wystarczy do pełnej diagnozy infrastruktury?

Nie wystarczy. Pokaże Ci tylko wierzchołek góry lodowej. To świetny wskaźnik pierwszego rzutu, ale ma poważne ograniczenia. Chociaż prawdę mówiąc brakuje nam twardych danych za wczoraj, więc wydaje się to tylko jedną z możliwych hipotez na najbliższy kwartał przed spowolnieniem rynku, to poleganie wyłącznie na tym jednym poleceniu prowadzi do błędnych wniosków w skomplikowanych topologiach.

Jeśli widzisz, że pakiety giną, ping nie powie Ci, na którym dokładnie routerze po drodze następuje zrzut. Do tego służą narzędzia takie jak tracert (w Windows) lub traceroute (w środowiskach uniksowych). Te aplikacje wysyłają serię żądań ICMP z rosnącą wartością TTL, zaczynając od jedynki. Dzięki temu mapują każdy kolejny węzeł na trasie, aż do serwera docelowego. Jeśli ruch urywa się na szóstym skoku, wiesz dokładnie, że problem leży u operatora tranzytowego, a nie na końcówce.

Ponadto, odpowiedź na to, do czego służy polecenie ping i jak interpretować jego wyniki, musi uwzględniać atakowanie środowisk zamkniętych. Często serwer www działa bez zarzutu na porcie 80 i 443, serwując stronę klientom, a jednocześnie ma zablokowane zapytania ICMP. Wtedy w terminalu widzisz same straty, a przeglądarka normalnie ładuje sklep internetowy. Dlatego do testowania konkretnych usług używamy innych poleceń, np. Telnet, Test-NetConnection w PowerShellu albo narzędzia nmap.

Sprawdź sam. Otwórz terminal. Wpisz komendę do swojej bramy domyślnej i zostaw test na kilkaset pakietów. Zobaczysz surową prawdę o stanie okablowania w Twoim własnym domu.

Bibliografia

1. Naukowa i Akademicka Sieć Komputerowa – https://www.nask.pl
2. Wydawnictwo Naukowe PWN – https://pwn.pl
3. Urząd Komunikacji Elektronicznej – https://uke.gov.pl
4. Ministerstwo Cyfryzacji – https://www.gov.pl/web/cyfryzacja
5. Główny Urząd Statystyczny – https://stat.gov.pl