Vyšlo v týdeníku: | COMPUTERWORLD |
Číslo: | 7/93 |
Ročník: | 1993 |
Rubrika/kategorie: | Co je čím ... v počítačových sítích |
Díl: | 58 |
Připomeňme si však ještě jednou to, co jsme si o konkrétním mechanismu potvrzování řekli již minule: protokol TCP používá tzv. kladné potvrzování (positive acknowledgement), což znamená, že potvrzuje pouze správně přijatá data, zatímco na chybně přijatá data nereaguje nijak. Odesilatel proto pozná, že určitá data nebyla přenesena správně, až po vypršení určitého časového limitu. Současně s tím je ale dobré si uvědomit, že také kladná potvrzení jsou sama přenášena pomocí stejně nespolehlivých přenosových služeb síťové vrstvy, jako samotná data. Může se proto stát, že určitá data jsou přenesena bezchybně, ale "ztratí" se jejich kladné potvrzení. Odesilatel však nemá možnost oba tyto případy rozlišit. Vždy musí čekat až do vypršení časového limitu, zda nedostane kladné potvrzení, a pokud ne, musí data vyslat znovu.
Otázkou ovšem je, jak volit příslušný časový limit (timeout)? Bude-li příliš krátký, může docházet k situacím, kdy data budou přenesena bezchybně, ale jejich kladné potvrzení dojde odesilateli příliš pozdě - až po vypršení časového limitu, což odesilatele přinutí znovu vyslat úspěšně přenesená data. V opačném případě - bude-li časový limit příliš dlouhý - bude odesilatel zase zbytečně dlouho čekat, než si bude moci domyslet, že se data nepřenesla správně. V obou případech je výsledkem neefektivní využití přenosových kapacit.
Problém vhodné volby časového limitu je navíc komplikován skutečností, že protokol TCP může být používán v různých sítích, ve kterých se doby přenosu mohou lišit i v několika řádech. Například v rychlé lokální síti by příslušný časový limit měl být výrazně kratší než v rozlehlé síti, která používá relativně velmi pomalé pevné telefonní okruhy. Situace je navíc ještě komplikovanější u vzájemně propojených sítí (internets, s malým "i"), kde jednotlivé části přenosové trasy (route) mají obecně různé přenosové kapacity, a kde se navíc trasa mezi dvěma koncovými účastníky může v průběhu přenosu dynamicky měnit (např. v důsledku zahlcení či výpadku).
TCP neustále měří dobu obrátky (RTT, round trip time) jako dobu od odeslání dat do přijetí kladného potvrzení o jejich úspěšném doručení. Časový limit pak uzpůsobuje průměrné době obrátky, kterou vypočítává jako vážený průměr (weighted average) jednotlivých naměřených dob obrátky.
Z pohledu zabezpečení spolehlivého přenosu tato nejednoznačnost nijak nevadí, ale problém vzniká při výpočtu doby obrátky: má tato být vztažena k okamžiku prvního vyslání, nebo naopak k okamžiku posledního opakovaného vyslání určitých dat? Dá se ukázat, že obě varianty jsou špatné - v případě té první může vážený průměr doby obrátky růst nade všechny meze, zatímco ve druhém případě sice konverguje k určité konečné hodnotě, ale tato je menší, než by správně měla být (praktické implementace této varianty ukazují, že je tato hodnota přibližně poloviční oproti správné, a protokol TCP pak vysílá všechna data právě dvakrát).
Myšlenka, se kterou Karn přišel, je velmi jednoduchá - v případě nejednoznačného potvrzení (tj. v případě opakovaného vyslání již jednou vyslaných dat) vůbec neměřit dobu obrátky, a tudíž i neuzpůsobovat podle ní časový limit. Jinými slovy: pro stanovení časového limitu využívat pouze ty případy, kdy data byla vyslána jen jednou, a je tudíž jasné, jak dobu obrátky měřit.
I toto řešení však ve své čisté podobě není příliš použitelné. Představme si totiž situaci, kdy například vlivem změny trasy či výpadku části přenosových kapacit náhle vzroste zpoždění při přenosu. Potvrzení nestihne přijít včas, a tak jsou data vyslána znovu - v důsledku toho se pak ale neměří doba obrátky, a nijak se nemění ani časový limit. Bude-li nárůst zpoždění trvalý, výše uvedený algoritmus na něj vůbec nezareaguje!
Konkrétní algoritmus, který Phil Karn navrhl, však řeší i tuto situaci (technikou, označovanou jako timer backoff): v okamžiku, kdy začne docházet k opakovanému vysílání dat, přestává tento algoritmus měřit dobu obrátky, a nemění tudíž ani vážený průměr těchto dob. Začne ale zvětšovat časový limit (např. na dvojnásobek po každém opakovaném vyslání dat). Teprve v okamžiku, kdy díky většímu časovému limitu dostane kladné potvrzení včas (tj. jako jednoznačné potvrzení), změří skutečnou dobu obrátky, znovu začne vypočítávat vážený průměr dob obrátky, a tomuto průměru pak uzpůsobí časový limit.