Throughput

Throughput (przepustowość rzeczywista) to ilość danych, które faktycznie udało się przesłać przez łącze lub ścieżkę w sieci w danym czasie. Podaje się ją zwykle w bitach na sekundę (bit/s, Mbit/s, Gbit/s). To nie to samo co bandwidth, czyli teoretyczna maksymalna pojemność łącza. Bandwidth mówi, ile danych łącze mogłoby przepuścić. Throughput mówi, ile realnie przeszło, gdy odliczymy narzut protokołów, retransmisje, kolejkowanie i ograniczenia sprzętu. W praktyce throughput jest zawsze niższy od pojemności łącza.

Czym throughput różni się od bandwidth i goodput?

Te trzy pojęcia układają się w hierarchię: bandwidth > throughput > goodput. Na każdym kolejnym poziomie odpada inny rodzaj narzutu.

• Bandwidth (przepustowość teoretyczna) — maksymalna pojemność łącza wynikająca z jego fizyki, np. 1 Gbit/s dla 1000BASE-T czy 10 Gbit/s dla 10GBASE-T. To liczba z reklamy dostawcy, a nie ta, którą realnie uzyskasz.
• Throughput (przepustowość rzeczywista) — faktyczna szybkość transferu zmierzona na łączu. Liczy cały ruch: nagłówki protokołów, ramki kontrolne i retransmisje. Wlicza więc też dane, które nie są użyteczną treścią aplikacji.
• Goodput (przepustowość użyteczna) — tylko ładunek aplikacji dostarczony poprawnie do odbiorcy. Nie wlicza nagłówków niższych warstw (np. 20 bajtów nagłówka IPv4, 40 bajtów IPv6, nagłówki TCP, ramkowanie Ethernet) ani pakietów wysłanych powtórnie. Goodput jest zawsze niższy od throughputu.

Bandwidth opisaliśmy w osobnym haśle. Najprościej: bandwidth to szerokość rury, throughput to ilość wody, która naprawdę przez nią przepłynęła, a goodput to woda, która dotarła czysta i nadająca się do użycia.

Jak mierzy się throughput?

Throughput podaje się zwykle jako średnią z okna pomiarowego, bo wartość chwilowa mocno skacze. Są dwa podejścia.

• Pomiar aktywny — generujemy testowy ruch między dwoma hostami, np. narzędziem iperf3. Po stronie serwera: iperf3 -s, po stronie klienta: iperf3 -c <ip_serwera>. Parametry takie jak strumienie równoległe (-P), rozmiar bloku (-l) czy test UDP (-u) pozwalają sprawdzić limity TCP/UDP. Licznik retransmisji pokazuje straty pakietów.
• Pomiar pasywny — obserwujemy prawdziwy ruch produkcyjny, nie wstrzykując danych testowych. Można korzystać z liczników interfejsów (SNMP), telemetrii przepływów (NetFlow/IPFIX/sFlow) lub przechwytów pakietów. Tej metody używa się w monitoringu sieci, bo nie obciąża łącza dodatkowym testem.

Przy ocenie wyniku warto pamiętać o regule najwęższego ogniwa: throughput całej trasy ogranicza najsłabsze łącze na drodze, niezależnie od tego, jak pojemne są pozostałe odcinki.

Jakie czynniki ograniczają throughput?

• Latencja (RTT) — przy TCP to często główny hamulec. Maksymalny throughput jednego strumienia to mniej więcej okno TCP / RTT. Im większe opóźnienie, tym niższa osiągalna przepustowość, o ile okno nie jest dość duże.
• Iloczyn opóźnienia i pasma (BDP) — BDP = bandwidth × RTT mówi, ile danych musi być „w locie”, by w pełni wykorzystać łącze. Jeśli okno odbiorcze TCP jest mniejsze od BDP, nadawca czeka na potwierdzenia, a łącze stoi niedociążone. Dlatego na łączach o dużym BDP potrzebne jest skalowanie okna (tcp_window_scaling) i dobrze dobrane bufory.
• Utrata pakietów (packet loss) — każda strata wymusza retransmisję, a w klasycznych algorytmach kontroli przeciążenia także zmniejszenie okna nadawczego. To gwałtownie obniża throughput, zwłaszcza na łączach o wysokim RTT.
• Narzut protokołów i MTU — nagłówki warstw L2–L4 oraz fragmentacja przy źle dobranym MTU zwiększają udział danych, które nie są treścią aplikacji. Większe ramki (jumbo frames) i dopasowane MTU zmniejszają ten narzut.
• Przeciążenie i kolejkowanie — zatłoczone kolejki w urządzeniach po drodze dodają opóźnienia, jitter i odrzuty, więc realny throughput spada.
• Ograniczenia hosta i karty sieciowej — wydajność CPU, ustawienia offloadu karty (np. TSO, GRO), rozmiary buforów i liczba kolejek mogą stać się wąskim gardłem przy dużych prędkościach, nawet gdy sama sieć jest sprawna.

Dlaczego throughput jest istotny dla bezpieczeństwa i monitoringu sieci?

Throughput to nie tylko miara wydajności. To też telemetria przydatna w wykrywaniu zagrożeń i w utrzymaniu obrony.

• Wydajność urządzeń inspekcyjnych — zapory nowej generacji (NGFW), systemy IPS, bramy SSL/TLS oraz sondy IDS/NDR mają deklarowany maksymalny throughput inspekcji. Wartość ta spada, gdy włączymy deszyfrowanie TLS i głęboką inspekcję pakietów. Po jej przekroczeniu urządzenie się nasyca: pakiety są kolejkowane, odrzucane lub — przy błędnej konfiguracji fail-open — przepuszczane bez kontroli, co tworzy lukę w widoczności.
• Wykrywanie anomalii — nagły wzrost throughputu w nietypowym kierunku może oznaczać wyciek danych, rozprzestrzenianie się złośliwego oprogramowania albo łączność C2. Gwałtowny skok ruchu przychodzącego bywa objawem ataku wolumetrycznego (DDoS). Gdy znamy bazowy throughput dla danego hosta, usługi i kierunku, łatwiej wychwycić odchylenia.
• Ślepe punkty monitoringu — gdy sonda NDR lub kolektor przepływów nie nadąża za throughputem łącza, część ruchu nie jest analizowana (drop na taps/SPAN). Dobranie punktów przechwytu i sond do realnego throughputu to warunek pełnej widoczności dla SOC.
• Diagnostyka incydentów i wydajności — gdy zestawimy spadek throughputu z latencją, stratami i retransmisjami, łatwiej odróżnić problem sieciowy (przeciążone łącze, zły QoS) od ataku lub od degradacji samej aplikacji.

Dowiedz się więcej

• Czym jest NetFlow i jak ten protokół jest wykorzystywany w praktyce? — NetFlow dostarcza dane o przepływach, na podstawie których mierzy się throughput w sieci.
• Monitoring sieci i network visibility – analiza ruchu sieciowego jako podstawa visibility cybersecurity — Network visibility pokazuje, gdzie throughput rośnie, spada lub wskazuje na przeciążenie.
• Zaawansowane metody ochrony przed atakami DDoS w firmach — Ataki DDoS obniżają dostępny throughput i mogą całkowicie zapchać łącze.