Jak měřit TCP: Ookla Speedtest vs RFC 6349

Obsah:

1. Co je TCP propustnost a jak se určuje?

2. Nejpoužívanější nástroje pro měření TCP

3. Proč naměříme různé hodnoty na stejné síti?

4. Případová studie: Proč je RFC 6349 přísnější než Ookla Speedtest?

4.1. RFC 6349 měří "reálnou kvalitu a užitečnou propustnost"

4.2. Jak funguje "TCP Pila" (Sawtooth efekt)

4.3. Jak Ookla Speedtest maskuje ztrátovost sítě (Hrubá síla paralelismu)

5. Závěr

---

V rámci certifikovaných měření podle metodiky Českého telekomunikačního úřadu (ČTÚ) je standardem pro ověřování kvality datových služeb metodika RFC 6349. Mnoho poskytovatelů internetu (ISP) a síťových techniků však bývá zaskočeno, když profesionální test RFC 6349 ukáže na stejné lince výrazně nižší hodnoty než populární Ookla Speedtest. Tento aplikační list vysvětluje principy TCP propustnosti a objasňuje, proč „horší“ výsledek u RFC 6349 není chyba měření, ale naopak jeho nejdůležitější vlastnost.

1. Co je TCP propustnost a jak se určuje?

Protokol TCP (Transmission Control Protocol) je spolehlivý spojovaný protokol, což znamená, že odesílatel musí dostat potvrzení (ACK) o doručení každého paketu, jinak data posílá znovu.

Základní jednotkou je TCP segment, který se skládá z hlavičky (TCP Segment Header) a samotných užitečných dat (tzv. payload). Rychlost, jakou dokážeme TCP segmenty přenášet, určuje celkovou propustnost. Ta je omezena dvěma hlavními fyzikálními parametry sítě:

• TCP Window Size (Velikost okna): Abychom plně pochopili, jak se síť chová pod zátěží, musíme rozlišovat dvě různá okna, která určují, kolik dat může být "na cestě" před přijetím potvrzení:
  • RWND (Receive Window – Okno příjemce): Limit na straně přijímacího zařízení. Říká: "Tohle je maximální kapacita mého hardwarového bufferu, víc dat najednou nezpracuji."
  • CWND (Congestion Window – Okno zahlcení sítě): Dynamický limit na straně odesílatele. Odesílatel neustále "osahává" propustnost sítě a pomocí tohoto okna říká: "Tohle je aktuální množství dat, které podle mě síť právě teď zvládne přenést bez ztráty paketů."

Výsledná povolená velikost okna (skutečné množství odesílaných dat) je v daný moment vždy ta menší z obou hodnot: Minimum (RWND, CWND)

• RTT (Round-Trip Time): Čas, který potřebuje paket na cestu od odesílatele k příjemci a potvrzení (ACK) zpět.

Základní vzorec propustnosti:

Maximální teoretická propustnost jediného TCP spojení se dá zjednodušeně vyjádřit jako:

Z rovnice jasně vyplývá, že pokud má síť vyšší latenci (RTT), je pro dosažení vysoké rychlosti nutné adekvátně zvětšit velikost TCP okna. Tento vztah se odborně nazývá BDP (Bandwidth-Delay Product) a je naprosto klíčový pro pochopení chování sítě pod zátěží.

Co přesně je BDP? BDP si lze představit jako pomyslnou „trubku“, kterou data sítí protékají. Šířka pásma nebo kapacita linky (CAP) určuje průměr této trubky a RTT (zpoždění) určuje její délku. BDP pak představuje celkový objem dat, který se v daném okamžiku nachází fyzicky "na cestě" uvnitř této trubky (tzv. data in flight), aniž by byla ještě potvrzena příjemcem.

Zlaté pravidlo sítí říká: Aby jedno TCP spojení dokázalo plně vytížit dostupnou kapacitu linky, musí být jeho TCP Window Size nastaveno minimálně na hodnotu BDP.

Praktický příklad: Představme si gigabitovou linku (1 Gbps = 1 000 000 000 bps) s latencí (RTT) 10 milisekund (0,01 s).

• BDP = 1 000 000 000 bps × 0,01 s = 10 000 000 bitů
• Po převodu na bajty (děleno 8) to odpovídá 1,25 MB.

To znamená, že pro naplnění této linky musí být odesílatel schopen poslat 1,25 MB dat, než dostane první potvrzení. Pokud má starší operační systém nebo běžný měřicí nástroj limit TCP okna nastavený například jen na 64 kB, maximální dosažitelná propustnost nikdy nepřekročí zhruba 50 Mbps – a to i když je fyzická 1 Gbps linka zcela volná. Měření pak ukáže velmi špatný výsledek, i když je síť v pořádku. Právě proto metodika RFC 6349 před samotným měřením rychlosti nejprve měří RTT a přesně kalkuluje potřebné BDP, aby testovací TCP okno odpovídalo fyzické realitě sítě.

2. Nejpoužívanější nástroje pro měření TCP

Na trhu existuje několik přístupů k měření rychlosti sítě. Je důležité chápat, že RFC 6349 není jen "aplikace", ale komplexní metodika.

Nástroj / Metodika	Typ řešení	Hlavní účel	Výhoda	Nevýhoda v profi praxi
Ookla Speedtest	Web / Mobilní aplikace	Rychlý marketingový test kapacity linky.	Extrémně snadné použití, stovky serverů.	Ignoruje anomálie (jitter/ztráty) pomocí paralelních streamů.
iPerf2 / iPerf3	CLI / Open-source software	Bodové inženýrské testování a ladění sítě.	Široké možnosti konfigurace oken a streamů.	Vyžaduje manuální konfiguraci a protilehlý běžící server.
RFC 6349	IETF standard (HW / Sondy)	Certifikované, opakovatelné měření kvality TCP.	Automaticky počítá BDP; detekuje retransmise a bufferbloat.	Vyžaduje dedikovaný hardware nebo pokročilé síťové sondy.

• Ookla Speedtest / Fast.com: Komerční a uživatelsky nejpřístupnější webové aplikace. Jsou optimalizované pro rychlé zobrazení maximální dostupné kapacity linky pomocí HTTP/HTTPS a masivního paralelismu.
• iPerf (iPerf2 / iPerf3): Oblíbený open-source nástroj spouštěný z příkazové řádky. Umožňuje síťovým inženýrům detailně konfigurovat velikost TCP okna, počet streamů a dobu testu.
• RFC 6349: IETF standard pro systematické a opakovatelné měření TCP propustnosti. Nejedná se o jednoduchý software, ale o striktní rámec, který je typicky implementován do profesionálních hardwarových měřicích přístrojů (např. platformy EXFO) nebo pokročilých síťových sond. Test RFC 6349 nejprve měří MTU, zjišťuje základní RTT, přesně počítá ideální BDP a teprve poté provádí samotný test propustnosti.

3. Proč naměříme různé hodnoty na stejné síti?

Dvě různé aplikace mohou na stejné fyzické lince naměřit diametrálně odlišné hodnoty. Důvodem není "nepřesnost" jednoho z nich, ale odlišná testovací konfigurace. Výsledky nejvíce ovlivňují tyto parametry:

• Algoritmy řízení toku (Congestion Control): Různé systémy používají různé TCP algoritmy (např. Reno, CUBIC, BBR). Zatímco starší TCP Reno při ztrátě jediného paketu drasticky sníží rychlost odesílání (TCP okno spadne na polovinu), moderní Google BBR se ztrátovostí nenechá tolik rozhodit a snaží se linku vytěžit za každou cenu.
• Velikost TCP okna (Window Size): Nástroje jako iPerf umožňují nastavit statické okno, zatímco běžné operační systémy a webové testy používají dynamické škálování (TCP Window Auto-Tuning).
• MTU a fragmentace: Pokud aplikace odesílá větší pakety, než je nastavené MTU na některém z routerů po cestě (např. kvůli PPPoE hlavičkám), dochází k fragmentaci, která zatěžuje procesory aktivních prvků a snižuje TCP propustnost.
• Počet paralelních spojení: Použití jednoho TCP streamu měří skutečnou kvalitu cesty. Použití např. 8 až 16 paralelních TCP spojení (což dělají běžné speedtesty) efektivně obchází omezení BDP a "protlačí" data i na linkách s velkým zpožděním a ztrátovostí.

4. Případová studie: Proč je RFC 6349 přísnější než Ookla Speedtest?

Dostáváme se k jádru problému. Zákazník má gigabitovou linku. Ookla Speedtest naměří 950 Mbps. Certifikovaný technik připojí měřicí přístroj, spustí test RFC 6349 a naměří pouze 700 Mbps. Proč?

4.1. RFC 6349 měří "reálnou kvalitu a užitečnou propustnost"

Metodika RFC 6349 simuluje skutečné chování běžných uživatelských aplikací. Před samotným testem si nástroj přesně změří základní nezatížené zpoždění (Baseline/Minimum RTT) a vypočítá ideální velikost okna.

Představme si síť, kde dochází ke ztrátovosti paketů na úrovni pouhých 0,1 % nebo kde je nestabilní latence.

• Při spuštění RFC 6349 testu tato i nepatrná ztrátovost způsobí retransmise (přeposílání dat).
• Standardní TCP chování (které metodika RFC 6349 striktně simuluje) využívá algoritmy pro řízení toku. Pokud dojde k retransmisi, TCP protokol to vyhodnotí jako přetížení sítě a okamžitě drasticky sníží tzv. Congestion Window (CWND - okno zahlcení).
• Ačkoliv maximální povolené okno (Receive Window) zůstává celou dobu pevně nastavené na ideální hodnotu BDP, kvůli smrštěnému CWND musí odesílatel zpomalit. Tím rapidně klesá celková propustnost a přístroj vykáže nízkou hodnotu metriky TCP Efficiency.
• RFC test takto rovněž dokáže odhalit tzv. Buffer Delay – situaci, kdy jsou data zdržována v obrovských bufferech (bufferbloat) levných domácích routerů, což zabíjí latenci v reálném čase.

4.2. Jak funguje "TCP Pila" (Sawtooth efekt)

Je důležité vědět, že snížené okno CWND nezůstane malé napořád. Jakmile se síť uklidní, TCP protokol se pokusí okno opět zvětšit. Klíčovou roli v tomto procesu hraje parametr zvaný ssthresh (Slow Start Threshold – Práh zahlcení), který funguje jako "paměť" sítě.

Když dojde ke ztrátě paketu (retransmisi), TCP protokol si zapamatuje kapacitu, při které síť selhala. Okamžitě vypočítá novou, bezpečnou hranici (ssthresh), kterou nastaví přesně na polovinu velikosti okna v momentě výpadku. Samotné okno odesílatele (CWND) je vzápětí drasticky oříznuto.

Následné zotavování (růst propustnosti) probíhá ve dvou fázích:

1. Zrychlený růst: Pokud je aktuální okno hluboko pod hranicí ssthresh, roste relativně rychle.
2. Opatrný růst (Congestion Avoidance): Jakmile velikost okna dosáhne prahu ssthresh, TCP protokol zařadí "brzdu". Předpokládá, že se blíží k limitům sítě, a začne okno zvětšovat už jen velmi obezřetně a pomalu (aditivní růst).

 TEMP

Problém nestabilních sítí (kde se vyskytuje neustálý drobný jitter nebo mikro-výpadky) spočívá v tom, že každá další chyba sráží práh ssthresh níže a níže. Dříve než se CWND stihne opatrným tempem vrátit na svou maximální BDP hodnotu, dojde k dalšímu mikro-výpadku a okno je znovu sraženo dolů. Výsledkem je typický tvar "zubaté pily", kde se průměrná velikost okna během celého RFC 6349 testu drží velmi nízko a výsledná propustnost se reálně nikdy nepřiblíží fyzickému maximu linky.

4.3. Jak Ookla Speedtest maskuje ztrátovost sítě (Hrubá síla paralelismu)

Mnoho lidí se logicky ptá: Pokud standardní TCP při chybě ořízne okno zahlcení na polovinu, jak to, že Ookla Speedtest stále ukazuje plnou rychlost?

Odpověď zní: Ookla Speedtest měří "hrubou sílu" sítě. Nemění sice pravidla TCP protokolu, ale obchází je na aplikační vrstvě masivním paralelismem. Zatímco certifikované měření RFC 6349 primárně testuje chování jednoho čistého TCP toku, moderní speedtesty automaticky otevírají velké množství paralelních spojení (často 4, 8 nebo i desítky) vůči geograficky nejbližšímu serveru najednou.

• Každé z těchto spojení má své vlastní, na sobě nezávislé okno zahlcení (CWND).
• Pokud se na lince objeví jemný jitter nebo mikro-výpadek (typické pro bezdrátové spoje nebo přetížené agregační uzly), pravděpodobně to poškodí pouze segmenty jednoho z těchto spojení.
• CWND tohoto zasaženého spojení okamžitě spadne na polovinu. Zbylá paralelní spojení ale tyto ztráty zamaskují – nepocítí je a dál běží na 100 %.
• Součet (agregace) kapacity všech těchto spojení je neustále tak velký, že bez problémů vytěží celkovou fyzickou kapacitu linky.

Výsledek Speedtestu tedy ukazuje maximální propustnost fyzické vrstvy, ale neříká nic o tom, jak se na lince bude cítit reálná aplikace (např. stahování velkého souboru nebo VPN tunel), která se spoléhá na jeden tok a prokazatelně by kolabovala.

 

5. Závěr: Není to chyba, je to vlastnost

To, že RFC 6349 naměří nižší hodnotu než Speedtest, znamená, že síť sice fyzicky má danou kapacitu, ale není schopna ji efektivně nabídnout jedinému souvislému TCP toku (například stahování jednoho velkého souboru nebo VPN tunelu) kvůli drobným anomáliím v síti, chybám v nastavení MTU, zpoždění nebo jitteru.

RFC 6349 zkrátka neměří hůře. Měří pravdivěji. Poskytuje hlubokou diagnostiku, která ISP poskytovatelům nedává jen "pěkné číslo pro marketing", ale reálný obraz o zdraví sítě a kvalitě (QoS), za kterou si koncový zákazník platí a kterou vyžadují standardy ČTÚ.