Existují algoritmy z TCP různých aby odpovídaly vzrůstajícím připojení šířku pásma: ve skutečnosti první historicky algoritmy používané by být schopen zvýšit míru rychle dost nasytit sítě link 100 Mbit / s Typický průtok lokálních sítí v 2000s.
Mezi nejznámější patří různé algoritmy TCP:
Mělo by být zřejmé, že algoritmus TCP nikdy nezná optimální rychlost pro spojení: navíc je obtížné odhadnout. IP , které přenáší TCP, nezaručuje, že cesta bude v průběhu času stabilní v síti, což znemožňuje předpovědět rychlost použití. Rychlost je navíc podmíněna dalšími faktory, jako je existence souběžných streamů na části cesty (například můžete mít několik současných stahování na serverech s různými úrovněmi výkonu).
Takto se TCP pokusí odhadnout nejlepší propustnost, která se má použít, a to se vždy pokusí zvýšit propustnost, dokud nedojde ke ztrátě paketů, protože síť nemůže zpracovat celou propustnost. Počítačové sítě jsou skutečně navrženy tak, aby byly co nejjednodušší a je to jediná možnost, kterou musí síť varovat uživatele, že je nasycená.
Algoritmy TCP se vyznačují formou pomalého startu a způsobem, jakým využívají dostupnou šířku pásma. Někdy mluvíme o agresivitě protokolu.
Než začneme, terminologie:
Všechny níže uvedené algoritmy jsou založeny na těchto technikách nebo jejich částech. Základním principem zamezení přetížení je reagovat snížením rychlosti připojení. Protokoly měří důležitost problému sledováním různých jevů, jako je například zvýšení doby odezvy nebo duplikace zpráv typu ACK, které znamenají například ztrátu paketu. Pokud protokol nereaguje na přetížení, počet opakovaných přenosů se může i nadále zvyšovat, a tak zhoršovat přetížení. To je důvod, proč řídicí algoritmus snižuje tok v případě přetížení.
Různé algoritmy uvedené níže musí být implementovány v každém zařízení, které si přeje jej použít. Neexistuje žádný centrální systém zamezení přetížení, každý prvek sítě musí přizpůsobit svůj přenosový tok.
Při navazování spojení neznáme spojení mezi námi a příjemcem, takže budeme postupně zvyšovat počet odesílaných paketů. Cílem je proto najít dostupnou šířku pásma a využít všechny dostupné zdroje. Poté použijeme přenosové okno (swnd), které představuje počet paketů, které mají být odeslány bez čekání na potvrzení. Toto okno poroste, jakmile obdržíme potvrzení za odeslané pakety (každý ACK zvýší toto okno o 1, jinými slovy, po každém RTT se velikost okna zdvojnásobí, pokud nedojde k přetížení).
Kromě určitého limitu hodnoty cwnd (práh pomalého spuštění, ssthresh) přejde TCP do režimu vyhýbání se přetížení. Odtamtud se hodnota cwnd zvyšuje lineárně, a proto mnohem pomaleji než při pomalém startu: cwnd se zvyšuje o jeden MSS (= jeden paket) u každého RTT. V tomto provozním režimu algoritmus detekuje ztrátu paketu co nejrychleji: pokud obdržíme ACK stejného paketu třikrát, nečekáme, až zareaguje konec časového limitu. V reakci na tuto ztrátu snížíme hodnotu ssthresh i cwnd (případně se vrátíme do režimu Slow Start). K rychlému odeslání ztracených paketů se používá technika Fast Retransmit.
Jak již bylo vysvětleno dříve, projdeme tímto algoritmem v případě detekce ztráty segmentu (segmentů), když jsme v režimu „Zabránění přetížení“. Duplikát ACK je vysvětlen způsobem zpracování segmentů při příjmu. Ve skutečnosti, pokud obdržíme segment TCP, který není v očekávaném pořadí, musíme poslat ACK s hodnotou rovnou očekávanému číslu segmentu. Pokud dojde ke ztrátě segmentu, příjemce odešle pouze ACK s číslem ztraceného segmentu. Můžeme tedy tuto ztrátu kompenzovat rychle (po obecně duplikovaných 3 ACK), aniž bychom čekali na časový limit.
Namísto návratu do režimu pomalého spuštění při duplikování ACK (a po přechodu do režimu rychlého opětovného přenosu), odešleme znovu ztracený segment a počkáme na ACK pro celé okno přenášené dříve, než se vrátíme do režimu zamezení přetížení. Pokud dosáhneme časového limitu, přejdeme zpět do režimu pomalého spuštění. Díky této technice se vyhneme příliš prudkému snížení průtoku.
Algoritmy, které byly (nebo nebyly) použity, ale nyní jsou zastaralé.
První implementací algoritmu pro zabránění přetížení TCP je TCP Tahoe. Poprvé se objevil v systému BSD4.3. Je to nejjednodušší a nejméně efektivní (všechny typy problémů dohromady). Tato verze používá systém pomalého startu s počáteční hodnotou cwnd 1 a maximální hodnotou cwnd ssthresh (s výchozí hodnotou 65535). Při prvním pomalém startu přijdeme ke ztrátě paketů, v tomto případě bude aktuální hodnota cwnd naší novou ssthresh, pak nastavíme hodnotu cwnd na 1.
Jakmile je dosaženo ssthresh, vstoupíte do Vyvarování se zahlcení. Odtamtud se hodnota cwnd zvyšuje lineárně, a proto pomaleji než v režimu Slow Start. Když obdržíme stejný ACK třikrát, dojde k přetížení, nečekáme na časový limit před opětovným odesláním ztraceného paketu (rychlý opakovaný přenos). Neexistuje žádná rychlá obnova, předáme hodnotu ssthresh polovině aktuální cwnd, cwnd přejde na 1 MSS a vrátíme se na Slow Start. Příklad chování tohoto algoritmu je znázorněn na obrázku.
Rozdíl oproti Tahoe spočívá v tom, že využívá funkci Fast Recovery. Jakmile příjem tří duplikovaných ACK snížíme hodnotu cwnd na polovinu, nastavíme prahovou hodnotu ssthresh na velikost cwnd, provedeme rychlý opakovaný přenos a přejdeme na rychlé zotavení. Pokud máme časový limit, vracíme se zpět k pomalému startu jako u Tahoe s oknem přetížení na 1 MSS.
Reno proto umožňuje nevracet se zpět do pomalého startu (a s hodnotou 1), jakmile dojde k přetížení. Průtoky jsou proto stabilnější.
Tento algoritmus se nazývá „NewReno“, protože se jedná pouze o nepatrnou (ale významnou) úpravu algoritmu Reno. Úprava skutečně probíhá na úrovni fáze rychlého zotavení: v tomto režimu zůstaneme, dokud neobdržíme ACK všech ztracených paketů. Dojde-li ke ztrátě několika segmentů stejného odeslaného „shluku“, po přijetí částečného potvrzení se další ztracený segment odešle zpět, aniž by došlo k opuštění režimu rychlého zotavení, na rozdíl od Reno, které tento režim opouští co nejdříve. neduplikovaný ACK.
Spíše než čekat na ztrátu paketů, Vegas bere v úvahu dobu odezvy příjemce (RTT), aby odvodil poměr, ve kterém bude odesílat pakety. V závislosti na době odezvy jsme schopni předpokládat stav vyrovnávacích pamětí zprostředkujících směrovačů. Vegas pro to upravuje několik dosud viděných algoritmů (pomalý start, zamezení zahlcení, rychlý opakovaný přenos).
Díky této technice má Vegas lepší rychlosti a menší ztráty paketů než Reno. Tento algoritmus dosahuje spravedlivého sdílení zdrojů. Podobně s Vegas je relativně málo ztrát, protože v ustáleném stavu se propustnost velmi podobá kapacitě odkazu \ cite {VEGAS}.
Vzhledem k tomu, že se Vegas dokáže rychleji přizpůsobit změnám v dostupnosti spojení, výkon se snižuje při použití s jinými protokoly, které nezohledňují stav spojení * před * ztrátou paketů.
Jedna nevýhoda však vyžaduje úpravu zásobníku TCP pro odesílatele i příjemce.
Westwood je přepisem New Reno na straně vysílače, aby měl lepší správu LFN (Long Fat Network). Mění hodnoty ssthresh a cwnd na základě odhadů o dostupné šířce pásma. První verze se špatnými odhady byla opravena později, odtud název Westwood +. Podobně jako ve Vegas jsou tyto odhady založeny na době odezvy přijímače (RTT), ale tyto odhady se používají odlišně.
Má mechanismus pro zjišťování, že nedochází k přetížení (Persistent Non Congestion Detection, PNCD), což mu umožňuje rychle využít dostupnou šířku pásma. Westwood upravuje Slow Start (stává se méně agresivním) přidáním fáze: „Agile Probing“, která umožňuje (s odhady prostřednictvím RTT) mít fázi zvyšování cwnd \ cite {UCLA} téměř exponenciální, pak stabilizovat, zvýšit, poté stabilizovat atd.
Algoritmus hodně získává na efektivitě, ale ztrácíme na spravedlnosti, protože v případě ztráty paketů se nepřizpůsobí náhle vydělením jeho cwnd dvěma. Díky tomu je také vhodný pro bezdrátové sítě, které mají náhodné ztráty (a nemusí to být nutně kvůli přetížení).
Algoritmy pro pomalý start a zamezení zahlcení jsou stejné jako pro TCP Reno. Selektivní ACK TCP umožňuje během ztráty říci, že pakety byly přijaty až do pořadového čísla N, ale také určit odesílateli, že byly přijaty některé z následujících paketů. Odesílatel již nemusí znovu odesílat segmenty, které již byly přijaty. SACK je možnost, která obchoduje po připojení. Tato možnost umožňuje získat malý výkon při ztrátě segmentů, ale je nutné mít obě části (odesílatele i příjemce), které ji implementují.
V běžných operačních systémech jsou široce používány dva algoritmy pro zabránění přetížení: CUBIC (Linux) a CTCP (Microsoft Windows). Než se podíváme na jejich rozdíly, podíváme se na algoritmus, od kterého se CUBIC dědí, BIC. Cílem těchto algoritmů je udržet propustnost co nejblíže dostupné šířce pásma.
Předchozí algoritmy nejsou vhodné pro rychlé sítě s velkou šířkou pásma (několik gigabitů za sekundu). Část šířky pásma nechávají nevyužitou. BIC udržuje dobrou propustnost a dobrou spravedlnost iu jiných algoritmů pro předcházení přetížení TCP.
Poněkud zjednodušená verze algoritmu by mohla být: když dojde ke ztrátě, BIC sníží cwnd o určitý koeficient. Před redukcí si ponecháme v paměti hodnotu cwnd, která bude naším maximem (Wmax), a nová hodnota bude naší minimální hodnotou (Wmin). Z těchto dvou hodnot najdeme mezilehlou hodnotu, pro kterou nemáme žádné ztráty (dichotomické vyhledávání).
Algoritmus je opatrný, aby příliš nezvyšoval cwnd, takže pokud během našeho hledání provedeme příliš velké skoky (definované určitou prahovou hodnotou), upřednostníme cwnd logaritmicky. Jakmile je rozdíl zmenšen, můžeme se vrátit k dichotomickému vyhledávání, dokud se nedostaneme k Wmax. Odtamtud hledáme nové maximum s lineárním růstem: hledáme, zda existuje blízké maximum. Pokud po určité době nedojde ke ztrátě, řekneme si, že maximum je mnohem dále a opět exponenciálně zvětšíme velikost okna.
BIC poskytuje dobrou spravedlnost, je stabilní při zachování vysoké propustnosti a umožňuje dobré škálování. Přes své kvality zůstává během své vzestupné fáze příliš agresivní. Ale především to způsobuje nerovnost s toky, které mají dlouhé RTT.
Tento algoritmus byl použit v Linuxu, protože dáváme přednost jeho komplikovanější variantě: CUBIC.
CUBIC má plynulejší uplink než BIC, díky čemuž je „přátelštější“ k jiným verzím TCP. CUBIC je jednodušší, protože má pouze jeden algoritmus pro jeho vzestupnou fázi a nepoužívá potvrzení ke zvětšení velikosti okna, raději mluvíme o přetížení. Díky tomu je CUBIC efektivnější v nízkorychlostních sítích nebo s krátkou RTT.
Jednou z velkých zvláštností CTCP je, že udržuje dvě okna přetížení. První je okno, které se lineárně zvyšuje, ale v případě ztráty přes určitý koeficient klesá. Druhé okno je spojeno s dobou odezvy příjemce. Proto kombinujeme metody související se ztrátou paketů (jako je TCP Reno) a preventivní adaptací na přetížení (jako je TCP Vegas), proto název „Compound“.
Skutečně použitá velikost okna je součtem těchto dvou oken. Pokud je RTT nízká, pak se okno založené na zpoždění rychle zvýší. Pokud dojde ke ztrátě segmentu, pak se okno založené na ztrátě paketů rychle zmenší, aby kompenzovalo zvýšení okna založeného na zpoždění. S tímto systémem se pokusíme udržet konstantní hodnotu okna efektivního vyzařování, blízkou odhadované hodnotě.
Účelem tohoto protokolu je udržovat dobrý výkon v sítích s vysokou rychlostí as velkým RTT.
Tato různá kritéria jsou:
Není lepší mluvit o lepší verzi TCP: existují verze vhodné pro velmi vysoké rychlosti sítí, existují verze vhodné pro nízké rychlosti, existují verze vhodné pro sítě, které způsobují mnoho chyb.
Nakonec pozorujeme, že všechny algoritmy TCP jsou navzájem kompatibilní (protože nedochází k žádné změně segmentu TCP, ale pouze ke změně jejich rychlosti příjezdu). Například Windows Vista používá složený TCP, zatímco linuxová jádra používají CUBIC TCP od verze 2.6.19.