Testowanie wydajności sieci jest fundamentalnym procesem diagnostycznym, który wykracza daleko poza proste sprawdzenie „prędkości Internetu”. Aby uzyskać miarodajne i użyteczne wyniki, kluczowe jest zrozumienie, jak różne czynniki i protokoły wpływają na transfer danych. Podstawowym rozróżnieniem jest wybór między protokołem TCP (Transmission Control Protocol) a UDP (User Datagram Protocol). TCP, będący protokołem zorientowanym na połączenie, gwarantuje dostarczenie każdego pakietu w odpowiedniej kolejności, implementując mechanizmy kontroli przepływu, retransmisji utraconych segmentów i unikania zatorów. To sprawia, że jest on idealny do symulowania transferów plików, przeglądania stron internetowych czy działania poczty e-mail, gdzie integralność danych jest priorytetem. Testując za pomocą TCP, mierzymy w rzeczywistości, jak efektywnie systemy końcowe i urządzenia sieciowe potrafią negocjować i utrzymywać stabilny, niezawodny strumień danych. Wynik takiego testu odzwierciedla więc nie tylko „surową” przepustowość łącza, ale także sprawność implementacji stosu TCP/IP w systemach operacyjnych i zdolność sieci do radzenia sobie z narzutem związanym z potwierdzeniami (ACK) i retransmisjami.

Z drugiej strony spektrum znajduje się protokół UDP, który jest bezpołączeniowy i nie gwarantuje ani dostarczenia, ani kolejności pakietów. Jego główną zaletą jest minimalny narzut i niska latencja, co czyni go idealnym dla aplikacji czasu rzeczywistego, takich jak streaming wideo, rozmowy VoIP czy gry online, gdzie utrata pojedynczego pakietu jest mniej problematyczna niż opóźnienie spowodowane oczekiwaniem na jego retransmisję. Testowanie za pomocą UDP wymaga od użytkownika zdefiniowania docelowej przepustowości, z jaką dane mają być wysyłane. Celem takiego testu nie jest sprawdzenie, jaką maksymalną prędkość „wynegocjuje” protokół, lecz ocena jakości łącza pod zadanym obciążeniem. Kluczowymi metrykami w teście UDP są jitter (zmienność opóźnień między pakietami) oraz procent utraconych pakietów. Wysoki jitter może powodować „czkawkę” w dźwięku i obrazie, a duża utrata pakietów prowadzi do całkowitej degradacji jakości transmisji. Dlatego testy UDP są niezbędne do certyfikacji sieci pod kątem obsługi usług multimedialnych i komunikacyjnych w czasie rzeczywistym.

Kolejnym kluczowym parametrem wpływającym na wydajność jest rozmiar danych, który w kontekście testów sieciowych możemy rozpatrywać na kilku poziomach: rozmiaru bloku, bufora oraz okna TCP. Rozmiar bloku (kontrolowany w iperf-ng flagą -l lub --len) określa wielkość pojedynczej porcji danych wysyłanej w ramach jednego wywołania systemowego. Ma to bezpośredni wpływ na stosunek danych użytecznych do narzutu nagłówków protokołów. Małe bloki oznaczają większą liczbę pakietów potrzebnych do przesłania tej samej ilości danych, co prowadzi do większego obciążenia procesora i urządzeń sieciowych, które muszą przetworzyć więcej nagłówków. Z kolei rozmiar bufora (-b dla UDP, -w dla buforów systemowych) odnosi się do ilości pamięci zarezerwowanej przez system operacyjny na przychodzące i wychodzące dane. Zbyt małe bufory mogą prowadzić do odrzucania pakietów (packet drops) w sytuacji, gdy aplikacja nie nadąża z ich odczytywaniem lub sieć dostarcza je szybciej, niż system jest w stanie przetworzyć, co jest częstym problemem w sieciach o dużej przepustowości.

W przypadku protokołu TCP, absolutnie krytycznym parametrem jest rozmiar okna TCP (TCP window size), kontrolowany flagą -w lub --window. Okno TCP definiuje, ile danych nadawca może wysłać bez otrzymania potwierdzenia (ACK) od odbiorcy. Jest to fundamentalny mechanizm kontroli przepływu. W sieciach o wysokim iloczynie przepustowość-opóźnienie (Bandwidth-Delay Product, BDP), czyli np. szybkich łączach na duże odległości, domyślny rozmiar okna jest często zbyt mały. Powoduje to, że nadawca musi wstrzymywać transmisję i czekać na potwierdzenia, mimo że łącze jest w stanie przesłać znacznie więcej danych. Zjawisko to skutecznie dławi przepustowość, uniemożliwiając pełne wykorzystanie potencjału sieci. Poprzez staranne dostrojenie rozmiaru okna TCP do charakterystyki łącza (BDP), można drastycznie zwiększyć osiąganą przepustowość, co pokazuje, jak istotna jest konfiguracja na poziomie protokołu, a nie tylko sama fizyczna jakość połączenia.

Równie ważne jak parametry protokołów jest uwzględnienie kierunku ruchu sieciowego. Większość podstawowych testów wykonuje się w jednym kierunku (unidirectional), od klienta do serwera, co symuluje operację wysyłania pliku. Jednakże wiele nowoczesnych aplikacji generuje ruch w obu kierunkach jednocześnie. Urządzenia sieciowe, takie jak przełączniki i routery, pracują w trybie pełnego dupleksu (full-duplex), co teoretycznie pozwala na jednoczesne wysyłanie i odbieranie danych z pełną prędkością portu. Testy dwukierunkowe (bidirectional), realizowane w iperf-ng za pomocą flagi -d lub --dualtest, pozwalają zweryfikować, czy infrastruktura sieciowa jest w stanie sprostać takiemu obciążeniu. Problemy z wydajnością w trybie dwukierunkowym mogą ujawnić nieprawidłową negocjację dupleksu, ograniczenia w architekturze wewnętrznej przełącznika (np. niewystarczająca wydajność matrycy przełączającej) lub problemy ze sterownikami kart sieciowych. Testowanie w obu kierunkach jest zatem kluczowe dla pełnej oceny zdolności sieci do obsługi złożonych, interaktywnych obciążeń.

Na koniec należy wspomnieć o specyfice testowania w środowiskach zwirtualizowanych. Uruchamianie testów z maszyn wirtualnych (VM) zamiast z fizycznych hostów wprowadza dodatkową warstwę abstrakcji, która może znacząco wpłynąć na wyniki. Ruch sieciowy z VM musi przejść przez wirtualny przełącznik (vSwitch) hypervisora, co generuje dodatkowy narzut na CPU hosta. Wydajność jest uzależniona od konfiguracji vSwitcha, typu wirtualnej karty sieciowej (np. E1000 vs. VMXNET3 w VMware) oraz od aktualnego obciążenia fizycznego serwera. Jeśli inne maszyny wirtualne na tym samym hoście intensywnie korzystają z zasobów CPU, pamięci lub dysków, może to negatywnie wpłynąć na zdolność testowanej VM do generowania i odbierania ruchu sieciowego, prowadząc do zaniżonych wyników. Co więcej, zaawansowane funkcje sieciowe, takie jak SR-IOV (Single Root I/O Virtualization), które pozwalają na bezpośredni dostęp VM do fizycznej karty sieciowej, mogą drastycznie poprawić wydajność, ale ich brak może stanowić wąskie gardło. Dlatego interpretując wyniki z maszyn wirtualnych, należy zawsze brać pod uwagę kontekst całej platformy wirtualizacyjnej.

Praktyczne przykłady użycia iperf-ng

Uwaga: Wszystkie poniższe przykłady zakładają, że na maszynie docelowej (serwerze) o adresie IP 192.168.1.100 zostało uruchomione polecenie iperf-ng -s, które uruchamia serwer nasłuchujący na domyślnym porcie.

Testowanie TCP: okno i kierunek

1. Podstawowy test TCP w jedną stronę

To jest standardowy test wyjściowy, który mierzy przepustowość od klienta do serwera przy użyciu domyślnych ustawień systemu dla rozmiaru okna TCP.

Analiza: Wynik 938 Mbit/s jest typowy dla dobrze działającej sieci Gigabit Ethernet. Test ten stanowi punkt odniesienia dla dalszych pomiarów.

2. Test TCP z powiększonym rozmiarem okna

Zwiększamy rozmiar okna TCP do 1 MB (-w 1M), aby sprawdzić, czy pozwoli to na lepsze wykorzystanie łącza, zwłaszcza jeśli występują minimalne opóźnienia.

Analiza: Niewielki wzrost przepustowości sugeruje, że domyślne okno było już bliskie optymalnemu dla tej sieci LAN o niskim opóźnieniu. W sieciach WAN (o większych opóźnieniach) różnica byłaby znacznie bardziej dramatyczna.

3. Test TCP w dwie strony jednocześnie (Dual Test)

Flaga -d (--dualtest) uruchamia jednoczesny transfer w obu kierunkach: klient -> serwer oraz serwer -> klient. Pozwala to na ocenę wydajności w trybie pełnego dupleksu.

Analiza: Przepustowość w każdym kierunku wynosi około 460 Mbit/s. Suma obu wartości (ok. 927 Mbit/s) jest zbliżona do maksymalnej przepustowości łącza, co potwierdza prawidłowe działanie w trybie full-duplex. Każdy strumień otrzymuje mniej więcej połowę dostępnego pasma.

Testowanie UDP: bufor i kierunek

1. Podstawowy test UDP w jedną stronę

Test UDP wymaga zdefiniowania docelowej przepustowości. Ustawiamy ją na 100 Mbit/s (-b 100M), aby sprawdzić jakość łącza pod tym obciążeniem.

Analiza: Wynik jest idealny. Jitter na poziomie 0.015 ms i zerowa utrata pakietów (0/84949) oznaczają, że sieć bez problemu radzi sobie z takim strumieniem danych.

2. Test UDP z powiększonym rozmiarem bufora

Wysyłamy dane z bardzo dużą prędkością (950 Mbit/s) i zwiększamy rozmiar bufora systemowego do 2 MB (-w 2M), aby zapobiec gubieniu pakietów po stronie odbiorcy z powodu przepełnienia domyślnego, mniejszego bufora.

Analiza: Mimo wysokiej przepustowości i powiększonego bufora, zanotowano niewielką utratę pakietów (0.0015%). Może to wskazywać na granice wydajności stosu sieciowego systemu operacyjnego lub samego sprzętu. Zwiększenie bufora pomogło jednak utrzymać straty na minimalnym poziomie.

3. Test UDP w dwie strony jednocześnie

Uruchamiamy jednoczesny test UDP w obu kierunkach, każdy ze strumieniem 450 Mbit/s, aby obciążyć łącze symetrycznie blisko jego limitu.

Analiza: Przy tak dużym, dwukierunkowym obciążeniu pojawiła się zauważalna, choć wciąż niewielka utrata pakietów (ok. 0.1%). Jitter również nieznacznie wzrósł. Wynik ten pokazuje, że sieć jest bliska punktu nasycenia, co jest cenną informacją diagnostyczną.

Dobre praktyki

Przeprowadzona analiza i przykłady jednoznacznie pokazują, że testowanie wydajności sieci to proces wymagający metodycznego podejścia i świadomości technologicznej. Narzędzie takie jak iperf-ng dostarcza potężnych mechanizmów do pomiaru, ale to od analityka zależy, jak te mechanizmy zostaną wykorzystane i jak zinterpretowane zostaną wyniki. Kluczem do sukcesu jest zrozumienie, że nie istnieje jeden, uniwersalny „test prędkości”. Wybór protokołu – TCP dla symulacji niezawodnych transferów lub UDP dla oceny jakości łącza pod kątem usług czasu rzeczywistego – fundamentalnie zmienia cel i metryki pomiaru. Dopiero świadome żonglowanie tymi protokołami pozwala na uzyskanie pełnego obrazu możliwości i ograniczeń badanej infrastruktury sieciowej.

Szczegółowa kontrola nad parametrami transmisji, takimi jak rozmiar okna TCP czy wielkość buforów, jest tym, co odróżnia profesjonalną diagnostykę od amatorskich pomiarów. Jak pokazały przykłady, nawet w wydajnej sieci lokalnej subtelne zmiany w konfiguracji mogą przynieść mierzalną poprawę. W bardziej złożonych środowiskach, jak sieci rozległe (WAN) czy infrastruktury centrów danych, umiejętność dostrajania tych parametrów staje się absolutnie krytyczna dla osiągnięcia optymalnej wydajności. Ignorowanie tych aspektów prowadzi często do błędnych wniosków, że sieć jest niewydajna, podczas gdy w rzeczywistości problem leży w nieoptymalnej konfiguracji systemów końcowych.

Analiza ruchu w różnych kierunkach, zwłaszcza jednoczesne testy dwukierunkowe, to kolejny niezbędny element rzetelnej oceny. W dobie aplikacji intensywnie komunikujących się w obie strony, weryfikacja zdolności sieci do pracy w trybie pełnego dupleksu pod dużym obciążeniem jest warunkiem koniecznym do zapewnienia stabilności i responsywności usług. Problemy ujawnione podczas takich testów często wskazują na głębsze kwestie konfiguracyjne lub sprzętowe, które pozostałyby niewykryte podczas prostych, jednokierunkowych pomiarów. Jest to zatem krok, którego nie można pomijać w procesie kompleksowego audytu sieci.

Szczególną ostrożność należy zachować podczas testowania środowisk zwirtualizowanych. Wyniki uzyskane z maszyn wirtualnych są zawsze wypadkową wydajności fizycznej sieci oraz narzutu i konfiguracji platformy wirtualizacyjnej. Należy je traktować jako pomiar wydajności „z perspektywy aplikacji” działającej w VM, a niekoniecznie jako odzwierciedlenie możliwości samego fizycznego łącza. Zrozumienie wpływu hypervisora, vSwitchy i współdzielenia zasobów jest kluczowe, aby uniknąć mylnej interpretacji wyników i nie obwiniać administratorów sieci za problemy leżące po stronie platformy serwerowej.

Podsumowując, iperf-ng jest wszechstronnym i precyzyjnym narzędziem, które w rękach świadomego użytkownika staje się nieocenionym instrumentem diagnostycznym. Efektywne wykorzystanie jego potencjału wymaga jednak systematycznego podejścia: rozpoczęcia od ustalenia punktu odniesienia (baseline), a następnie iteracyjnego modyfikowania poszczególnych zmiennych – protokołu, rozmiaru okna/bufora, kierunku – w celu wyizolowania i zrozumienia ich wpływu na końcową wydajność. Taka metodologia pozwala nie tylko precyzyjnie zidentyfikować „wąskie gardła” w sieci, ale również świadomie optymalizować jej konfigurację w celu osiągnięcia maksymalnej stabilności i przepustowości.