Protokol TCP - III.

V minulém dílu jsme se zabývali tím, jak se protokol TCP vyrovnává s různou propustností přenosových cest, a jak dokáže dynamicky přizpůsobovat svůj mechanismus potvrzování okamžitým změnám tzv. doby obrátky. K tomu, aby protokol TCP dokázal co nejefektivněji využít existující přenosové kapacity, to ale ještě nestačí.

Dalším důležitým předpokladem pro zajištění spolehlivého, ale současně s tím i dostatečně efektivního přenosu, je vhodné řízení toku (flow control). Protokol TCP musí zajistit, aby odesilatel neposílal data rychleji, než je příjemce schopen je přijímat (resp. ukládat do svých vyrovnávacích pamětí). Pokud by totiž odesilatel příjemce "zahltil", tento by musel přijímaná data zahazovat, a ta by musela být posléze vysílána znovu. Odesilatel se tedy nutně musí řídit kapacitními možnostmi příjemce. Konkrétní způsob, jakým se v protokolu TCP dosahuje potřebného řízení toku, bezprostředně souvisí s mechanismem potvrzování.

Okénko proměnlivé velikosti

Když jsme si v 57. dílu popisovali mechanismus potvrzování v protokolu TCP, řekli jsme si, že jde o tzv. kladné potvrzování (tj. takové, kdy příjemce kladně potvrzuje správně přijatá data, a na chybně přenesená data nereaguje). Protokol TCP ovšem používá tento způsob potvrzování v tzv. kontinuální variantě, kdy umožňuje, aby odesilatel vysílal data "dopředu", tedy ještě dříve, než dostane potvrzení o úspěšném přijetí dříve vyslaných dat. Existuje zde samozřejmě určité omezení na objem dat, které se takto mohou vyslat "dopředu", a je dáno velikostí posuvného datového okénka (sliding window) - viz obr. 59.1. Okamžitá velikost a poloha tohoto okénka určuje odesilateli, kolik dat ještě může vyslat, aniž by musel čekat na potvrzení od protější strany.

Obr. 59.1.: Představa posuvného datového okénka

Příjemce má samozřejmě možnost řídit tok dat tím, že dočasně pozdrží kladné potvrzení úspěšně přijatých dat. Tím totiž zabrání odesilateli, aby si posunul své datové okénko, a nedovolí mu tudíž vyslat další data za okamžitým koncem okénka. Tato metoda má ale nepříjemný vedlejší efekt v tom, že když příjemce pozdrží kladné potvrzení a odesilatel jej nedostane do příslušného časového limitu (viz minule), bude to interpretovat tak, že tato data nebyla úspěšně přenesena. V důsledku toho pak odesilatel znovu odešle již jednou odeslaná a úspěšně přijatá data. Tato sice již nemohou příjemce "zahltit" (ten je může jednoduše ignorovat), ale jejich přenos zbytečně spotřebovává část existující přenosové kapacity.

Protokol TCP proto používá jiný způsob řízení toku, kterým je změna velikosti posuvného okénka. Příjemce reaguje na každý úspěšný přenos dat tím, že pošle příslušné kladné potvrzení, a odesilatel si na základě tohoto potvrzení příslušným způsobem posune své datové okénko. Současně s tímto potvrzením ale příjemce zašle odesilateli ještě i další údaj, podle kterého si odesilatel nově nastaví šířku svého datového okénka (viz obr. 59.1.).

Příjemce tento údaj samozřejmě volí podle svých možností tak, aby vždy byl schopen přijmout to, co mu odesilatel pošle. Příjemce dokonce může odesilateli zmenšit jeho datové okénko až na nulovou velikost, a tím vlastně zcela zastavit vysílání jakýchkoli dat. Příjemce by ale při stanovování nové velikosti okénka měl vždy postupovat korektně - jelikož nemůže přesně určit okamžik, kdy odesilatel dostane údaj o nové velikosti okénka, neměl by se jeho pravý okraj nikdy posouvat zpět (na obr. 59.1 směrem doleva)!

Nejde jen o koncové účastníky

Potřeba řídit tok dat se však netýká jen obou koncových účastníků přenosu. Je totiž nutné si uvědomit, že na cestě od odesilatele k příjemci mohou data procházet i přes několik přepojovacích uzlů (gateways), které také mají jen konečnou propustnost. Odesilatel tedy musí dávat pozor i na to, aby nezpůsobil zahlcení (tzv. zácpu, angl. congestion) těchto mezičlánků.

Protokol TCP však neobsahuje žádný explicitní mechanismus, který by měl za úkol ochranu těchto mezičlánků před zahlcením (congestion control). Snaží se ale chovat tak, aby k zahlcování mezilehlých přepojovacích uzlů nedocházelo.

Pro správné pochopení podstaty celého problému je vhodné si uvědomit, jak se takové zahlcení mezilehlého uzlu projeví koncovým účastníkům komunikace. Jakmile přepojovací uzel (gateway) nestačí přepojovat přenášená data v reálném čase, tato se hromadí v jeho vstupních frontách, kde čekají na své další zpracování. Tento stav se koncovým účastníkům projevuje růstem doby obrátky. Jakmile ale zatížení přepojovacího uzlu stoupne natolik, že jeho vstupní fronty již svou kapacitou nestačí, musí přepojovací uzel nově přijímané bloky dat zahazovat, protože je nemá kam uložit. Mechanismy potvrzování, které se snaží zajistit spolehlivý přenos, reagují na obě tyto situace opakovaným vysíláním již jednou vyslaných dat, tedy vlastně dalším zvýšením provozu v síti, což dále zhoršuje přetížení přepojovacích uzlů, a může vést až k úplnému zhroucení sítě v důsledku zahlcení (congestion collapse).

Jednou z možností, jak předcházet zahlcování přepojovacích uzlů, je dát jim možnost upozornit odesilatele na hrozící nebezpečí. To však opět stojí určitou část přenosové kapacity. Další, méně nákladnou možností, je vhodná disciplína samotných odesilatelů.

Protokol TCP se snaží předcházet zahlcování přepojovacích uzlů tím, že odesilatel si sám zmenšuje šířku svého datového okénka v situaci, kdy předpokládá hrozící zahlcení přepojovacích uzlů. Každou ztrátu datového segmentu (tj. každý případ, kdy nedostane kladné potvrzení do příslušného časového limitu), interpretuje odesilatel jako důsledek zahlcení některého z přepojovacích uzlů na cestě k příjemci, a reaguje na to tím, že si sám zúží své datové okénko na polovinu (současně s tím prodlužuje na dvojnásobek i časový limit, do kterého očekává kladné potvrzení, viz minule). Při opakovaných ztrátách přenášených segmentů tak velikost okénka exponenciálně klesá, čímž se odesilatel snaží maximálně snížit objem provozu v síti, a poskytnout tak přepojovacím uzlům potřebný čas na zotavení. Tato technika je označována jako Multiplicative Decrease Congestion Avoidance.

Otázkou ovšem je, jak má protokol TCP reagovat na konec stavu zahlcení. Kdyby začal opět exponenciálně zvětšovat velikost svého datového okénka, vedlo by to na prudkou oscilaci celé přenosové sítě mezi stavem s minimálním objemem přenosů a stavem zahlcení. Proto musí protokol TCP postupovat "umírněněji", a své datové okénko zvětšovat pomaleji (způsobem, který je označován jako slow-start recovery, doslova: zotavení s pomalým startem). Za každý úspěšně přenesený segment si odesilatel zvětší své datové okénko jen o velikost tohoto segmentu. Jakmile však dosáhne poloviny té velikosti okénka, kterou mu nabízí příjemce (viz výše), postupuje ještě pomaleji, a velikost okénka zvětšuje vždy až poté, co dostane kladné potvrzení o úspěšném přenosu všech segmentů v rámci celého okénka. Maximální velikostí okénka je pak samozřejmě ta, kterou mu signalizuje příjemce.

Kombinací všech výše uvedených mechanismů pro řízení toku, spolu s adaptivním způsobem potvrzování (o kterém jsme si povídali minule) dosahuje protokol TCP velmi efektivního využití existujících přenosových kapacit. Praktické testy ukázaly, že oproti prvním verzím protokolu TCP, které uvedené mechanismy ještě nepoužívaly, dosahují novější verze TCP dvakrát až desetkrát většího přenosového výkonu. To je jistě jeden z hlavních důvodů dnešní velké popularity protokolu TCP.

---