Ji°φ Peterka: Co je Φφm ... v poΦφtaΦov²ch sφtφch (59):

Protokol TCP - III.

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

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

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.