Wireshark od zera: jak czytać pakiety i namierzyć opóźnienia w sieci

Rozmiar przechwytywania i ring buffery – żeby dysk nie zapłakał

Przechwytywanie „wszystkiego jak leci” ma jedną konsekwencję: pliki rosną jak na drożdżach. Kilka minut ruchu w godzinach szczytu potrafi zająć gigabajty. Przy dłuższych analizach trzeba podejść do tego z głową.

W menu Capture → Options pojawia się kilka ważnych opcji:

• File → Use multiple files – włącza zapis w wielu plikach.
• Next file every… – przełączanie na nowy plik co X MB lub co Y minut.
• Ring buffer with N files – po osiągnięciu limitu pliki nadpisują się „w kółko”.

Dobry schemat na dłuższe przechwytywanie problemu, który pojawia się „czasem”:

1. Ustaw Next file every na np. 100 MB lub 5 minut.
2. Zaznacz Ring buffer z 10–20 plikami.
3. Uruchom capture i zostaw na czas występowania problemu.

Dzięki temu masz zawsze ostatnie kilkadziesiąt minut ruchu, a dysk nie zapełni się po cichu w całości. W momencie, gdy użytkownik zadzwoni z tekstem „teraz strasznie laguje”, zatrzymujesz przechwytywanie i analizujesz ostatnie pliki.

Co faktycznie widzisz w przechwycie: promiskuitywny tryb i jego granice

Wireshark może pracować w trybie promiscuous – karta sieciowa odbiera wtedy nie tylko pakiety skierowane do siebie, ale też inne ramki obecne na medium. Brzmi kusząco, lecz w typowej sieci przełączanej (switch) cudzych pakietów i tak nie zobaczysz, bo switch wysyła ramki tylko na odpowiednie porty.

Tryb promiscous ma sens m.in. wtedy, gdy:

• pracujesz na porcie SPAN/mirror na switchu,
• analizujesz ruch na starym hubie lub w sieciach typu „tap”,
• badasz ruch na interfejsie „wirtualnym” (np. na hostach z hypervisorami).

W menu Capture Options można ten tryb włączyć lub wyłączyć dla danego interfejsu. Jeśli przechwytujesz na swoim laptopie podpiętym do zwykłego domowego routera, różnicy najczęściej nie zauważysz – i to normalne.

Szybka orientacja w widoku pakietów – co jest czym

Dopasowanie kolumn do diagnozy opóźnień

Domyślne kolumny w Wiresharku są ogólne. Do szukania lagów można je lekko podrasować, żeby ważne dane były pod ręką.

Przydatne kolumny, które warto dodać:

• Time delta (Time since previous displayed frame) – różnica czasu względem poprzedniego widocznego pakietu.
• Stream index (np. tcp.stream) – numer rozmowy TCP, pozwala szybko grupować pakiety tego samego połączenia.
• TCP len – długość danych TCP (nie sam nagłówek). Ułatwia rozróżnienie pakietów z danymi od czystych ACK-ów.
• Info o flagach – np. kolumna z polem wyliczanym tcp.flags lub gotowa kolumna TCP Flags.

Kolumny dodajesz klikając prawym przyciskiem na nagłówku kolumny → Column Preferences, a potem przyciskiem „+”. Źródłem nowej kolumny może być konkretne pole z panelu szczegółów – wystarczy kliknąć na nim PPM i wybrać Apply as Column.

Kolorowanie pakietów – szybkie wzrokowe „kto jest kim”

Domyślne kolory w Wiresharku nie są przypadkowe. Różne typy ruchu i sytuacji mają swoje barwy, np.:

• jasnozielony – zwykle zwykłe pakiety TCP z danymi,
• ciemnozielony – ACK bez danych,
• czerwony – pakiety z błędami, retransmisjami, RST itp.,
• fioletowy – DNS, niebieskawy – HTTP (zależnie od wersji programu/tematu).

Pełną listę znajdziesz w View → Coloring Rules. Tam też możesz dodać swoje, np. osobny kolor dla tcp.analysis.retransmission albo tcp.analysis.fast_retransmission. Po kilku takich modyfikacjach analiza wizualna bardzo przyspiesza: od razu widać, w których miejscach strumienia dzieje się coś złego.

Follow Stream – czytanie całej rozmowy jak dialogu

Gdy szukasz opóźnień w konkretnej sesji, wybieranie pakietów „na piechotę” szybko staje się męczące. Wtedy pojawia się funkcja Follow:

• klik na jednym z pakietów,
• PPM → Follow → TCP Stream (albo HTTP/UDP, zależnie od protokołu).

Wireshark filtruje wtedy widok do jednej rozmowy i pokazuje ją w oknie tekstowym (np. całe żądanie i odpowiedź HTTP). Dla analizy opóźnień samo okno tekstowe jest mniej interesujące niż fakt, że:

• lista pakietów jest już zawężona do jednej sesji,
• widać czasy kolejnych segmentów bez szumu tła.

Na tym widoku wygodnie obserwuje się m.in. opóźnienia odpowiedzi serwera, retransmisje i przerwy w ruchu.

Jak czytać pakiet krok po kroku – warstwy i nagłówki

Od ramki do aplikacji: klasyczny stos

Pojedynczy wpis w Wiresharku to zwykle kilka „warstw” jedna w drugiej. Typowy pakiet IPv4 z TCP będzie wyglądał tak:

• Frame – informacje o przechwycie: czas, interfejs, długość na kablu.
• Ethernet II – adresy MAC źródła i celu, typ protokołu (np. IPv4).
• Internet Protocol Version 4 – adresy IP, TTL, fragmentacja.
• Transmission Control Protocol – porty, numery sekwencyjne, flagi, okno.
• warstwa aplikacyjna – np. Hypertext Transfer Protocol, Domain Name System itp.

Analiza opóźnień skupia się głównie na warstwach IP i TCP (ew. UDP), a na aplikacji patrzy się raczej pod kątem tego, co tam się logicznie dzieje (duże żądania, wiele równoległych requestów itd.).

Co jest istotne w ramce Ethernet

Przy problemach typowo „lagowych” najczęściej wystarczy pobieżne spojrzenie na Ethernet. Przydają się jednak dwa pola:

• Source / Destination – adresy MAC; wskazują, czy ruch faktycznie idzie do właściwego urządzenia (np. czy nie idzie przez nieoczekiwany gateway).
• Type – warto upewnić się, że to np. 0x0800 (IPv4), a nie jakieś egzotyczne enkapsulacje.

Przy bardziej zaawansowanej analizie (np. VLAN-y, tagowanie 802.1Q) w ramce pojawia się dodatkowa warstwa – 802.1Q Virtual LAN z numerem VLAN-u. Może to tłumaczyć, czemu pakiety trafiają nie tam, gdzie się ich spodziewasz.

IP: TTL, fragmentacja i trasa

W nagłówku IP z perspektywy opóźnień ważne są głównie:

• Source / Destination – oczywiste, ale pierwszy krok to upewnienie się, że adresy zgadzają się z tym, co deklaruje aplikacja.
• Time to live (TTL) – maleje o 1 na każdym routerze. TTL zbliżający się do zera może wskazywać na dziwną, okrężną trasę.
• Flags / Fragment offset – jeśli widzisz dużo fragmentacji IP (More Fragments ustawione, różne offsety), mogą pojawiać się dodatkowe opóźnienia i retransmisje.

Drobna sztuczka: porównanie TTL dla różnych hostów może dać zgrubną informację, ile „skoków” dzieli cię od danego serwera. Jeśli nagle TTL dla danego celu spada o kilka w stosunku do tego, co „zwykle” widzisz, możliwe, że ruch idzie inną trasą (np. przez nowy tunel VPN).

TCP: numery sekwencyjne, ACK i flagi w praktyce

Serce diagnozy opóźnień siedzi w TCP. Kluczowe pola:

• Source port / Destination port – identyfikacja aplikacji (HTTP 80/443, SSH 22 itd.).
• Sequence number / Acknowledgment number – ile danych już wysłano i potwierdzono.
• Header length – przydatne, gdy używane są opcje TCP (np. timestampy).
• Flags – SYN, ACK, FIN, RST, PSH, URG.
• Window size value – rozmiar okna odbiorcy (ile danych może przyjąć).

Do kopania w opóźnieniach szczególnie przydają się flagi i analiza okna:

• SYN / SYN, ACK / ACK – trzy pakiety otwierające połączenie (handshake).
• PSH, ACK – zazwyczaj pakiet z danymi aplikacji.
• ACK – czyste potwierdzenie bez danych.
• RST – nagłe zamknięcie połączenia, np. błąd aplikacji albo firewall.

Odczytywanie jednego pakietu krok po kroku – mini przykład

Załóżmy, że użytkownik skarży się, że wejście na stronę firmowego CRM trwa wieczność. W capture masz pakiet oznaczony jako HTTP GET. Jak go „czytać”:

1. Wybierasz pakiet w górnym panelu.
2. W środku rozwijasz Frame – sprawdzasz dokładny Arrival Time.
3. Rozwijasz Ethernet – upewniasz się, że ruch idzie do/od właściwego MAC (np. gatewaya).
4. Rozwijasz IP – patrzysz, jaki jest Source (twój host) i Destination (serwer CRM); dla porządku rzut oka na TTL.
5. Rozwijasz TCP – zapisujesz w głowie numer sekwencyjny, sprawdzasz flagi (PSH, ACK), wielkość okna.
6. Na końcu HTTP – widać, jakie dokładnie żądanie poszło (URL, nagłówki).

Następnie szukasz odpowiedzi – pierwszego pakietu z serwera po tym GET. Różnica czasu między nimi to percepcyjne „czekanie na odpowiedź serwera”. Jeżeli w tym miejscu widać kilkusetmilisekundową lub sekundową dziurę, sprawa jest jasna: spowalnia serwer lub coś po drodze.

Rozumienie czasu w Wiresharku – podstawa analizy opóźnień

Rodzaje znaczników czasu w widoku

Wireshark pozwala przełączyć sposób wyświetlania czasu w View → Time Display Format. Najczęściej używane tryby:

• Seconds Since Beginning of Capture – czas od rozpoczęcia przechwytywania.
• Seconds Since Previous Displayed Packet – różnica względem poprzedniego wyświetlonego pakietu.
• Date and Time of Day – pełna data i godzina.

Do szukania lagów zwykle wygodniejszy jest Seconds Since Beginning… w kolumnie Time plus dodatkowa kolumna z Time delta. Taki duet daje szybki obraz, gdzie w strumieniu pojawiają się duże „dziury”.

Time delta i „podwójne” spojrzenie na opóźnienie

Dla pojedynczego połączenia warto obserwować dwa rodzaje opóźnień:

• czas między pakietami klienta a odpowiedzią serwera – odczuwalny lag aplikacji,
• czas między wysłaniem segmentu a jego ACK – RTT (round-trip time) z perspektywy TCP.

Time delta (różnica czasu między kolejnymi pakietami) świetnie ujawnia przerwy w ruchu, ale samo w sobie nie mówi, czy winna jest sieć, czy aplikacja. Trzeba łączyć to z kierunkiem pakietu:

• długa przerwa po stronie klienta (np. długo nie wysyła kolejnego żądania) – możliwe, że to on „myśli”,
• długa przerwa po stronie serwera przed wysłaniem odpowiedzi – opóźnienie po stronie aplikacji lub backendu,
• długa przerwa między segmentem a jego ACK po obu stronach – wygląda na problem sieciowy.

Statystyka RTT bez liczenia w głowie

Wireshark potrafi automatycznie obliczać RTT dla pakietów TCP, jeśli dostępne są odpowiednie informacje (numery sekwencyjne, ACK). W panelu szczegółów TCP często pojawia się linia:

Wykorzystanie „Round Trip Time” w praktyce

Przy polu TCP w panelu szczegółów pojawia się często linijka w stylu “[Time since previous frame in this TCP stream:]” oraz “[Calculated window size]”, a także “[Round trip time]” dla wybranych segmentów. To właśnie gotowy RTT wyliczony na podstawie segmentu z danymi i odpowiadającego mu ACK.

Żeby mieć pełniejszy obraz, przydaje się włączyć dodatkową kolumnę z RTT:

1. PPM na nagłówkach kolumn → Column Preferences…
2. + (dodaj nową kolumnę).
3. Title: np. RTT.
4. Type: Fields.
5. Field name: tcp.analysis.ack_rtt.
6. Zatwierdź i przeciągnij kolumnę w wygodne miejsce.

Od tej pory przy pakietach-ACK zobaczysz, ile czasu minęło od wysłania danych do ich potwierdzenia. Dla „zdrowego” połączenia w LAN wartości będą rzędu pojedynczych milisekund, w sieci WAN – czasem dziesiątek. Skoki RTT nagle w górę (np. z 20 ms na 300 ms) oznaczają już coś konkretnego: kolejki na łączu, przeciążone urządzenie, problem radiowy itd.

Time sequence graph – obrazek zamiast liczenia

Dla dłuższych sesji samo patrzenie w kolumnę RTT bywa męczące. Pomaga wtedy wizualizacja:

• zaznacz pakiet z badanej sesji,
• Statistics → TCP Stream Graphs → Round Trip Time Graph albo Time-Sequence Graph (tcptrace).

Na wykresie RTT widać od razu „góry” i „doliny”. Płaski, niski przebieg to spokojna sieć. Zęby piły, nagłe skoki i „schodki” w górę – przeciążenia, utraty pakietów, ponowne transmisje. Na Time-Sequence Graph łatwo zauważyć momenty, w których rośnie liczba retransmisji (linie nakładają się, wracają do wcześniejszych numerów sekwencyjnych).

Dopasowanie strefy czasowej i synchronizacja zegarów

Przy analizie logów aplikacji razem z capturem .pcap nierzadko wychodzi na jaw, że serwer „żyje” w innej strefie czasowej albo ma rozjechany zegar. Żeby nie zgadywać, kiedy dokładnie coś się stało:

• upewnij się, że masz na hostach NTP (synchronizację czasu),
• w Wiresharku możesz używać zarówno Date and Time of Day, jak i czasu względnego – przełączanie bywa potrzebne, gdy chcesz szybko zmapować moment awarii na wpis w logach.

Jeżeli serwer ma lub miał zły czas, zrzut ruchu zrobiony „bliżej klienta” (np. na jego laptopie albo na bramie) staje się złotem – to w nim czas jest powiązany z fizycznym pakietem, a nie z fantazją zegara aplikacji.

TCP pod lupą – handshake, okna, retransmisje i RTT

TCP handshake – pierwsze trzy pakiety, pierwsze podejrzenia

Otwieranie połączenia TCP to sekwencja:

1. SYN – klient proponuje parametry połączenia.
2. SYN, ACK – serwer odpowiada, akceptuje i ustala swoje parametry.
3. ACK – klient potwierdza, połączenie gotowe.

Sprawdzając opóźnienia, dobrze jest zacząć od tej trójki. Różnice czasów mówią sporo:

• czas między SYN a SYN, ACK – obejmuje całą podróż w obie strony: sieć + dotarcie pakietu do serwera,
• czas między SYN, ACK a ACK – zwykle bardzo mały, mocno zależny od klienta.

Jeśli już na handshake’u widać kilkusetmilisekundowe przerwy, nie ma sensu obwiniać aplikacji – coś dzieje się wcześniej, w warstwie transportowej lub niżej. W Wiresharku możesz szybko wyizolować handshake:

• filtr: tcp.flags.syn == 1 and tcp.flags.ack == 0 – pokaże tylko pierwsze SYN-y,
• następnie Follow → TCP Stream na wybranym SYN – zobaczysz powiązane pakiety.

Slow start i wzrost prędkości – co widać w sekwencjach

TCP nie startuje od razu na pełnej petardzie. Najpierw delikatnie zwiększa ilość wysyłanych danych (algorytm slow start), a potem próbuje znaleźć „sweet spot” przepustowości. W praktyce na wykresie Time-Sequence wygląda to jak:

• początkowo małe porcje danych (krótki dystans między kolejnymi numerami sekwencyjnymi),
• stopniowe wydłużanie się „skoków” – rosnące okno i większa ilość danych w locie,
• ewentualne „załamania” przy utracie pakietów i cofnięciu okna.

Jeśli w sesji pobierania pliku widzisz, że po kilku retransmisjach TCP nigdy nie „rozpędza się” powyżej pewnego poziomu, a RTT wygląda dobrze – zwykle coś po drodze gubi pakiety (np. słaby link Wi-Fi, przeciążony router domowy).

Okno TCP – kto tu kogo dusi

Window size value mówi, ile danych odbiorca może jeszcze przyjąć bez dodatkowego potwierdzania. Gdy okno jest duże – nadawca może wysłać większy „zestaw” danych. Gdy okno maleje, transmisja zwalnia, nawet jeśli sieć jest w stanie przyjąć więcej.

W praktyce podczas analizy lagów wypatruj takich sytuacji:

• ciągłe małe okno odbiorcy – np. wartość bliska zeru lub bardzo mała w porównaniu z MTU; odbiorca (często aplikacja na serwerze) nie nadąża z przetwarzaniem danych,
• Zero Window – pole okna pokazuje 0, co oznacza: „stop, nie wysyłaj mi nic więcej, jestem zapchany”.

Gdy w capture widzisz sekwencję: dane → ACK z małym oknem → ZeroWindow, a potem dopiero po chwili Window Update, winny bywa po prostu powolny proces na końcu (np. baza danych zasypana zapytaniami). Sieć z tego się nie wytłumaczy.

Retransmisje, Dupe ACK i Fast Retransmit – jak rozpoznać zgubione pakiety

Kiedy pakiet ginie w drodze, TCP stara się to wykryć i naprawić. Na ekranie Wiresharka wygląda to jak mały dramat w kilku aktach:

1. Nadawca wysyła segment z danymi.
2. Segment gdzieś znika (brak ACK).
3. Odbiorca wciąż dostaje kolejne segmenty, ale nie dostał tego jednego, więc wysyła duplicate ACK z potwierdzeniem poprzedniego poprawnego pakietu.
4. Po trzech duplikatach nadawca uruchamia fast retransmit – wysyła brakujący segment ponownie.

Wireshark upraszcza to, oznaczając pakiety np. jako:

• [TCP Retransmission]
• [TCP Dup ACK]
• [TCP Fast Retransmission].

Dobry filtr na początek diagnozy:

tcp.analysis.retransmission or tcp.analysis.fast_retransmission or tcp.analysis.duplicate_ack

Jeżeli w jednej sesji widzisz wysyp takich zdarzeń, a RTT nie jest szalone, linia najpewniej gubi pakiety (lub błędne ustawienia MTU powodują fragmentację i odrzucanie zbyt dużych datagramów).

Analiza segmentu i jego ACK – manualne mierzenie RTT

Gdy nie chcesz lub nie możesz ufać automatycznym wyliczeniom, RTT da się zmierzyć ręcznie:

1. zaznacz segment z danymi (PSH, ACK lub czysty segment z payloadem),
2. zapisz jego czas (Time),
3. szukaj pierwszego ACK, który potwierdza całość danych z tego segmentu (numer ACK = numer sekwencji + rozmiar danych),
4. różnica czasów = RTT.

Przy większej ilości pakietów szybciej dojdziesz do celu, używając opcji Analyze → Expert Information i gotowych statystyk TCP, ale kilka ręcznie policzonych RTT buduje wyczucie, co jest w ogóle „normalne” w danej sieci.

Wireshark i „Expert Info” – szybki radar problemów TCP

Panel Expert Information (menu Analyze) zbiera różne ostrzeżenia i wskazówki dotyczące przechwyconych pakietów. Dla TCP znajdziesz tam m.in.:

• retransmisje i podejrzenia utraty pakietów,
• zerowe okna,
• duże opóźnienia w odpowiedziach,
• resetowane sesje (RST).

Po przełączeniu na zakładkę Notes/Warnings/Errors łatwo zobaczyć, czy problem jest „czysto sieciowy” (masowe retransmisje, duże RTT), czy raczej dotyczy konkretnego hosta (ciągłe Zero Window, zamykanie połączeń RST po pewnym czasie bezczynności).

TCP Analysis Flags – wbudowany asystent diagnozy

Wireshark dodaje do pakietów specjalne znaczniki w sekcji [TCP Analysis Flags]. Typowe przykłady to:

• [TCP Spurious Retransmission] – retransmisja, która być może nie była potrzebna,
• [TCP Out-Of-Order] – segmenty dotarły w innej kolejności niż wysłano,
• [TCP Previous segment not captured] – w zrzucie brakuje fragmentu konwersacji (co nie zawsze oznacza, że pakiet zginął w sieci – mógł po prostu nie zostać przechwycony),
• [TCP ACKed unseen segment] – widzisz potwierdzenie danych, których sam nie masz w capture.

Przy analizie opóźnień dobrze jest odfiltrować sesje z tcp.analysis.flags i zobaczyć, ile pakietów ma takie oznaczenia. Nagły wysyp Out-Of-Order w jednym kierunku bywa wskazówką, że w danym segmencie sieci pojawiło się równoległe łącze, load balancing albo urządzenie z mocno „kreatywnym” buforowaniem.

Rozpoznawanie problemów po stronie klienta vs. serwera

Analizując RTT, okna i retransmisje, da się często wskazać, gdzie konkretnie „pęka” łańcuch:

• Duże RTT, retransmisje w obu kierunkach, brak małych okien – problem typowo sieciowy: zakłócenia, przeciążone łącze, router z przepełnionymi buforami.
• Stabilne RTT, małe okna lub Zero Window po stronie serwera – serwer/aplikacja nie nadąża, w sieci cisza i spokój.
• Stabilne RTT, duże dziury czasowe między żądaniami klienta – to klient długo myśli (np. aplikacja desktopowa renderuje dane), sieć i serwer są w tym czasie bezczynne.
• Częste RST z jednej strony – któraś aplikacja agresywnie zamyka połączenia (błędy, limity, timeouty).

Żeby ułatwić sobie pracę, bywa dobrze zdefiniować osobne kolumny z adresem IP i portem źródłowym/docelowym oraz posortować capture po kolumnie Stream index (np. tcp.stream jako kolumna). Wtedy przechodzisz sesja po sesji, zamiast skakać po całym zrzucie.

Filtry dla najczęstszych scenariuszy „lagi w TCP”

Przy typowych zgłoszeniach „sieć laguje” kilka gotowych filtrów oszczędza sporo czasu:

• Duże opóźnienia odpowiedzi serwera dla konkretnego hosta:
  ip.addr == 192.0.2.10 and tcp.flags.ack == 1 and tcp.len > 0
  następnie sortowanie po czasie i patrzenie na przerwy.
• Sesje z problemami TCP:
  tcp.analysis.retransmission or tcp.analysis.zero_window or tcp.analysis.fast_retransmission
• Sprawdzenie, czy problem dotyczy konkretnego portu/aplikacji:
  tcp.port == 443 and (tcp.analysis.retransmission or tcp.analysis.duplicate_ack)
• Potwierdzenia z dużym RTT (gdy masz kolumnę RTT): sortowanie po kolumnie RTT malejąco i wyłapywanie „rekordzistów”.

Po przejściu kilku takich scenariuszy w praktyce ręka sama zaczyna sięgać po odpowiednie filtry i kolumny. A gdy ktoś znowu powie „to na pewno ten VPN”, przynajmniej będziesz miał twarde dane w formie wykresu RTT, a nie tylko przeczucie.

Najczęściej zadawane pytania (FAQ)

Do czego najlepiej użyć Wiresharka przy problemach z opóźnieniami w sieci?

Wireshark sprawdza się głównie wtedy, gdy chcesz ustalić, gdzie dokładnie „gubi się” czas: na DNS, na handshake TCP/TLS, czy już na samym serwerze aplikacji. Pozwala zobaczyć moment wysłania żądania (np. DNS, HTTP) oraz dokładny czas przyjścia odpowiedzi, a także retransmisje, zmiany okna TCP czy utratę pakietów.

Najczęściej ma sens przy: długo ładujących się stronach, losowych lagach w grach lub aplikacjach biznesowych, problemach typu „aplikacja w ogóle nie odpowiada” albo „VPN muli, ale nie wiadomo gdzie”. Do ogólnego „czy internet jest wolny” lepszy jest zwykły speedtest, ping i traceroute.

Jak w Wiresharku sprawdzić, czy wysoki ping to wina sieci czy serwera?

Najprościej przechwycić ruch podczas pingu lub np. krótkiego testu z aplikacją i przyjrzeć się czasom odpowiedzi (kolumna Time oraz analiza par żądanie–odpowiedź). Jeśli opóźnienie rośnie już na poziomie prostych zapytań DNS lub handshake TCP, kłopot jest zwykle „po drodze w sieci”. Gdy sieć reaguje sprawnie, a samo żądanie HTTP/HTTPS wisi długo, podejrzany jest serwer lub aplikacja.

Dobry trik: zrobić równolegle ping/traceroute i capture w Wiresharku. W logu pingu widać skoki RTT, a w Wiresharku możesz sprawdzić, czy w tych momentach pojawiają się retransmisje TCP, wzrost jittera albo brak odpowiedzi z konkretnego hosta.

Jak w Wiresharku zobaczyć latency, jitter i utratę pakietów?

Latency widać jako czas między wysłaniem żądania a otrzymaniem odpowiedzi (np. DNS request/response, pakiety SYN/SYN-ACK w TCP). Można też użyć narzędzi statystycznych Wiresharka (np. „Statistics → Conversations”, „Statistics → TCP Stream”), które pokazują czasy trwania sesji i poszczególnych wymian.

Jitter to zmienność opóźnień – w praktyce patrzysz, czy kolejne pakiety (np. w rozmowie VoIP, strumieniu UDP) mają stabilny odstęp czasowy, czy raz lecą w 20 ms, a raz w 200 ms. Utratę pakietów najłatwiej wykryć w TCP: pojawiają się retransmisje, duży wzrost numerów sekwencji albo komunikaty typu „TCP Retransmission”, „Fast Retransmission”. Przy UDP kontrolę musisz zrobić „ręcznie”, porównując ciąg numerów/ramek po obu stronach.

Jak wybrać właściwy interfejs sieciowy do przechwytywania w Wiresharku?

Najpierw sprawdź, z jakiego połączenia faktycznie korzystasz: kabel (Ethernet), Wi-Fi, VPN. W Wiresharku przy każdym interfejsie zobaczysz adres IP oraz mini-wykres aktywności – ten, który „mruga” w rytm Twojej aktywności w sieci i ma znany Ci adres (np. 192.168.x.x), to zwykle dobry kandydat.

Na Windows możesz się upewnić, porównując nazwę interfejsu z „Stan połączenia sieciowego” w systemie. Jeśli np. testujesz opóźnienia w tunelu VPN, przechwytuj na interfejsie samego VPN, a nie na fizycznej karcie – zobaczysz wtedy to, co dzieje się już „wewnątrz” tunelu.

Czy do przechwytywania pakietów w Wiresharku muszę mieć uprawnienia administratora?

W większości systemów – tak. Na Windows Wireshark zwykle trzeba uruchomić jako administrator, na Linuksie przechwytuje się ruch jako root albo przez nadanie specjalnych uprawnień narzędziu dumpcap, na macOS system sam poprosi o zgodę przy pierwszym uruchomieniu.

Bez odpowiednich uprawnień program może pokazywać listę interfejsów, ale nie zobaczy pełnego ruchu (albo nie zobaczy go wcale). W środowisku firmowym dochodzi jeszcze kwestia prawa i polityki bezpieczeństwa – przechwytywanie pakietów traktuj jak dostęp do logów serwerowych: najpierw zgoda, potem sniffowanie.

Skąd bezpiecznie pobrać Wiresharka i czym różni się WinPcap od Npcap?

Wiresharka pobieraj wyłącznie z oficjalnej strony wireshark.org. Unikniesz dzięki temu „magicznych instalatorów” z reklamami czy dodatkowymi, niechcianymi programami. Sam Wireshark jest darmowy (GPL), ale pełni tylko rolę analizatora – do przechwytywania potrzebny jest sterownik typu packet capture.

Na Windows obecnym standardem jest Npcap, który jest rozwijany i obsługuje nowsze systemy oraz funkcje. Starszy WinPcap jest w praktyce martwy, więc lepiej go odpuścić. Przy instalacji Npcap można zaznaczyć tryb „WinPcap API-compatible”, żeby działały także starsze narzędzia korzystające z tego interfejsu.

Kiedy Wireshark to zbyt ciężkie narzędzie i lepiej użyć czegoś prostszego?

Jeśli chcesz tylko sprawdzić, czy łącze jest ogólnie wolne albo czy dostawca internetu „tnie” transfer, szybciej będzie użyć speedtestu, pingu i traceroute. Podobnie przy typowych problemach z Wi-Fi, jak kiepski zasięg czy zakłócenia – Wireshark nie pokaże pakietów, które w ogóle nie docierają.

Wireshark jest idealny do punktowej analizy konkretnej sesji czy aplikacji, a nie do ciągłego monitoringu całej infrastruktury. Do tego służą systemy NMS, NetFlow, SNMP i inne narzędzia klasy „zobacz mi całą sieć”, podczas gdy Wireshark jest lupą do mikroskopowego podglądu pojedynczych połączeń.