Technologie internetu (11): Řízení datového toku

Od minule víme, že přijímající strana TCP spojení postupně rostoucími sekvenčními čísly potvrzuje řádně přijaté části datového proudu. Pokud se nějaký segment ztratí (anebo dojde porušený), potvrzování se zastaví a odesílající strana po uplynutí určité doby zahájí retransmisi: pošle znovu tu část datového proudu, která nebyla potvrzena.

Retransmise je vhodným opravným nástrojem pro případ, že se tu a tam nějaký segment cestou ztratí nebo poškodí. Pokud ale ke ztrátám dochází z důvodu zahlcení (kongesce) přijímající strany nebo některého spoje na trase, znamenala by neřízená retransmise jen přilévání oleje do ohně. Základním opatřením proto je, podobně jako třeba u Ethernetu, exponenciální prodlužování intervalu mezi opakovanými retransmisemi. Kromě toho jsou ale také součástí protokolu TCP algoritmy, které adaptivně upravují rychlost, s níž jsou data odesílána, aby pokud možno ke kongescím vůbec nedocházelo. Na ty se nyní blíže podíváme.

Klouzavé okno

Implementace TCP používají na straně odesílatele i příjemce vyrovnávací paměti (buffery). Odesílající aplikace do ní ukládá svá data a přijímající aplikace je odtud naopak odebírá. Problém by nastal v případě, když by odesílatel generoval data rychleji, než by je druhá strana byla schopna odebírat – došlo by pak nutně k přeplnění vyrovnávací paměti na straně příjmu. Součástí hlavičky TCP je proto ještě jedna šestnáctibitová položka, o níž jsme posledně nemluvili: velikost okna (window size). Přijímající strana do ní průběžně zapisuje, kolik bajtů datového proudu ještě může do vyrovnávací paměti přijmout. Odesílatel pak nemusí čekat na potvrzení každého segmentu, ale může poslat – počínaje od nejvyššího potvrzeného sekvenčního čísla – ještě tolik bajtů, kolik udává velikost okna. S tím jak vzrůstají potvrzená sekvenční čísla, posouvá se okno proti proudu dat.

Úzké hrdlo na trase

Ještě složitější případ nastává, když se datovým proudem zahlcuje nějaký směrovač nebo spoj na trase mezi oběma účastníky TCP spojení. Taková situace nastane třeba tehdy, když je rychlá lokální síť připojena do internetu pomalejším okruhem. Budeme-li směrovač lokální sítě bombardovat daty, která nebude schopen stejně rychle odesílat pomalým okruhem, dojde nutně k přeplnění vyrovnávací paměti směrovače a ke ztrátám paketů.

Ochrana proto tomuto typu kongesce byla do implementací TCP doplněna až dodatečně koncem 80. let poté, co zácpy na některých frekventovaných spojích dostaly tehdejší internet několikrát do kolen. Autorem dodnes používaného adaptivního algoritmu je Van Jacobson, jedna z velkých postav internetové historie. Jacobson si všiml, že potvrzovací segmenty (s nastaveným příznakem ACK) přicházejí za normálních okolností zpět k odesílateli zhruba s takovou frekvencí, s jakou druhé straně přicházejí datové segmenty. Algoritmus je proto založen na tzv. pomalém startu, který umožňuje postupné zvyšování přenosové rychlosti na straně odesílatele v závislosti na tom, jak rychle přicházejí potvrzovací segmenty.

Využívá se k tomu dalšího okna, které se tentokrát nazývá kongesční. Odesílatel začne vysílat s kongesčním oknem o velikosti rovné délce jednoho segmentu. Odešle tedy jeden segment a čeká. Jakmile dorazí potvrzení prvního segmentu, zvětší si kongesční okno na délku dvou segmentů a může odeslat bez čekání dva segmenty. Za každý obdržený potvrzovací segment se může kongesční okno zvětšit o další segment. Kongesční okno se tak postupně exponenciálně zvětšuje z jednoho segmentu na dva, pak na čtyři, osm atd. až k aktuální velikosti klouzavého okna stanovené příjemcem. Pokud je však úzké hrdlo skutečně někde na trase a ne u přijímající strany, dojde ke ztrátě segmentů dříve, než kongesční okno dosáhne velikosti klouzavého okna. Odesílatel se to dozví například z toho, že některý segment zůstane nepotvrzen a vyžaduje retransmisi. V takovém případě si odesílatel zapamatuje aktuální velikost kongesčního okna (říká se jí kongesční práh), ale pak zmenší kongesční okno zpět na jeden segment a znovu zahájí pomalý start. Kongesční okno už ale exponenciálně zvětšuje jen do velikosti poloviny dříve zjištěného kongesčního prahu. Jakmile se dosáhne této velikosti, zvětšuje odesílatel kongesční okno pouze lineárně, tedy daleko pomaleji.

Dlouhé tlusté roury

Na přelomu tisíciletí se vlivem postupující liberalizace telekomunikací, dotcomového výbuchu a dalších faktorů velmi zásadně změnil charakter internetu. Zatímco dříve byly relativně rychlé lokální sítě (např. 100 Mb/s) propojeny pomalejšími okruhy v řádu megabitů až desítek megabitů za sekundu, dnes je situace jiná – lokální sítě jsou sice také rychlejší (běžný je Gigabit Ethernet), standardem páteřních sítí se ale stává přenosová rychlost 10 Gb/s.

V této nové situaci narážejí někteří uživatelé vysokorychlostních sítí na úplně opačný problém než Van Jacobson před 20 lety: TCP jim umožňuje dosáhnout jen zlomku přenosové rychlosti, kterou by podle nominálních parametrů sítě očekávali. Takové omezení bývá nejcitelnější na dlouhých tlustých rourách (long fat pipes), jak se v internetovém slangu označují okruhy, které mají velmi velký součin šířky pásma a zpoždění na trase (bandwidth-delay product, BDP). Vezměme třeba extrémní případ satelitního spoje o kapacitě 10 Gb/s a zpoždění půl vteřiny. Co se stane s TCP spojením, pokud vede přes takový okruh? Odesílatel do něj během několika mikrosekund „nasype“ data odpovídající velikosti kongesčního okna a musí čekat nejméně půl vteřiny, než data dojdou na druhý konec a další půlvteřinu, než dorazí zpět potvrzovací segment. To by až tak nevadilo, pokud by se mohlo klouzavé a s ním i kongesční okno dostatečně zvětšit. K tomu ale často nedojde a přenosová rychlost zůstane přiškrcena.

Základní důvody jsou dva:
1. Velikost klouzajícího okna je v hlavičce TCP omezena na 16 bitů, což odpovídá maximu 64 kilobajtů.
2. Mnohé operační systémy alokují pro každé TCP spojení vyrovnávací paměť, která je implicitně ještě menší než 64 KB.

Druhý z uvedených problémů je možné obvykle odstranit vyladěním parametrů operačního systému – na webu lze najít stránky, kde je takový postup popsán. Pokud jde o první problém, řešením je volba TCP Window Scale, která se může poslat v hlavičce úvodního SYN segmentu. S její pomocí se, zjednodušeně řečeno, zvětšují jednotky pro velikost klouzavého okna, tedy že se například namísto bajtů interpretuje v kilobajtech.

Naprostá většina uživatelů internetu se s výkonem TCP na dlouhých tlustých rourách nemusí příliš trápit, protože i s přenosovou rychlostí v řádu 10 Mb/s (pro jedno spojení) se dá docela dobře žít. Horší to bude, až se internet rozšíří i do vesmíru, pro meziplanetární spojení je totiž TCP v současné podobě zaručeně nepoužitelný. Ale ani zde není třeba propadat skepsi – na projektu meziplanetárního internetu už se několik let pracuje.