31 - Řízení toku dat (flow-control) a prevence zahlcení (congestion-control) na transportní vrstvě (MP-TCP, QUIC, SCTP, DCCP).
pondělí 21. května 2018
17:24
Cíle transportní vrstvy: 
Garantovat spolehlivé doručení (reliable data transfer)
Řídit tok (flow control) 
Řídit zahlcení (congestion control) 
Doručování v pořadí (in-order delivery) 
Byte-order vs. Message-order
Connection oriented: před komunikací se musí ustanovit spojení (handshake...)
Connection-less: spojení se neustanovuje, když je potřeba něco poslat, tak se pošle
Korekce chyb (řízení toku)
Simulace metod: [link]
Stop-and-wait
Čekám na konkrétní paket. Až mi dojde tak potvrdím a čekám na následující paket
Go-Back-N
Mám okno N paketů. Pokud mi dojde paket z okna, tak ho potvrdím. Pokud potvrdím nejlevější paket okna, tak okno posunu doprava
Lesší než Stop-adn-wait, ale selective repeat je lepší
Selektivní znovu zasílání (selective repeat)
Fast Retransmit
V rámci okna se potvrzuje každý přijatý paket v pořadí zvlášť, přičemž každý následující (kumulativní) ACK obsahuje sekvenční číslo posledně korektně přijatého paket.
Používá se v TCP
Vhodné jen pro relativně spolehlivé linky
Bitová maska
Pomocí bitové masky dává příjemce odesilateli vědět, které pakety z aktivního chyby-kontrolujícího okna dorazily v pořádku a které nikoli
Umí si poradit s více chybami, ale je nutné zasílat bitovou masku, takže režie navíc
NACK
Kromě ACK, kterými potvrzuji došlé zprávy, posílám i NACK, kterémi dávám najevo, které pakety mi nedošly
oproti selektivnímu znovuzasílání nezvětšuje hlavičku
oproti Fast Retransmitu je schopno si poradit s více než jednou chybou v chyby-kontrolujícím okně
SMART
Kombinace Selektivního znovu zasílání s Go-Back-N a Fast Retransmit
Každý ACK obsahuje dvojici: (poslední paket přijatý v pořadí, potvrzený paket), která mu umožňuje zrekonstruovat bitovou mapu bez toho, aniž by ona samotná byla obsažena v hlavičce
Transportní protokoly
Přehled vlastností protokolů
Spolehlivý přenost
Řízení zahlcení
Řízení toku
TCP
Inorder byte stream
slow start + congestion avoidance
3-way handshake nastavující sekvenční čísla
Fast Retransmit
SCTP
Inorder message stream
slow start + congestion avoidance
4-way handshake nastavující sekvenční čísla a bránící před SYN floodem
EWMA,
Fast Retransmit
MPTCP
Inorder byte stream
Má vlastní alg. odlišné od TCP
Stejné jako TCP
Fast Retransmit
QUICK
Inorder byte stream
TCP CUBIC
V nejlepším případě connection-less, jinak connectionoriented
SMART s kumulativním potvrzováním
DCCP
Best-effort delivery
Buď jako TCP nebo vlastní alg.
3-way handshake domlouvající způsob řízení zahlcení
ne
UDP
Best-effort delivery
Neřeší, tlačí pakety na plný plyn
Connection-less
ne
TCP
Použitím TCP mohou aplikace na počítačích propojených do sítě vytvořit mezi sebou spojení, přes které mohou obousměrně přenášet data. Protokol garantuje spolehlivé doručování a doručování ve správném pořadí. TCP také umožňuje rozlišovat a rozdělovat data pro více aplikací (například webový server a emailový server) běžících na stejném počítači.
Řízení toku:
Kumulativní potvrzování - potvrzuju poslední korektně a v pořadí doručenou zprávu. Pomocí speciálních TCP-options umí i selektivní. 
Timeout: pokud vyprší pro daný balík timeout a já jsem nedostal potvrzení, tak posílám znovu
Pokud mi dojde několik ACK na stejný balík, tak se dá předpokládat, že se ty následující někde ztratily a já tedy zasílám před vypršením timeoutu
Řízení zahlcení:
TCP Tahoe: slow start (postupně se dvojnásobně zvyšuje rychlost) do ssthresh (určitá hranice) a pak congestion avoidance (lineární nárust). Až narazí na zahlcení, tak spane na 0 a zase znovu.
TCP Reno: Jako Tahoe, ale nehledá na 0, ale začíná congestion avoidance od poloviny šírky pásma
TCP WestWood: rozlišuje zda nechodí nic nebo zda chodí jen ACK. Pokud nechodí nic, tak na 0, pokud jen ACK, tak na polovinu
TCP Cubic: založené na kubických křivkách. 
Nevýhody TCP:
Head of line bloacking
Nepodporuje multihoming (pokud se změní IP, musí se vytvořit nové spojení)
Velká režie potvrzování (ACK...) - asi 30% internetové komunikace jsou ACK
UDP
Connection-less
Nespolehlivé a neřeší zahlcení nebo doručování v pořadí
Chrlí data ven maximální rychlostí -> pokud mám v síti UDP a TCP toky, tak UDP přiškrtí TCO, protože TCP se snaží zamezit zahlcení a tak při dosažení max. Šířky pásma sníží rychlost. UDP je to ale jedno a tak zaberu tu šířku pásma uvolněné TCP. 
Velmi jednoduchý protokol
DCCP
UDP + congestion control
Tzn. stále je to best effort delivery
Neposkytuje inorder doručování
Obsahuje ECN (explicit congestion notification) bit. Pomocí toho můžeme druhou stranu varovat před zahlcením bez zahazování paketů. 
Pro řízení zahlcení může použít buď to co TCP + autoři implementovali i další algoritmy
SCTP
Po navázání spojení, kterému se v terminologii SCTP říká asociace, po něm lze přenášet řadu navzájem nezávislých proudů (stream). 
V rámci každého proudu dokáže SCTP garantovat doručení všech dat ve správném pořadí. Případný výpadek (a pozdější opakování, čili zdržení) v některém z proudů se však nijak netýká proudů ostatních. Jejich komunikace pokračuje bez přerušení. 
4-way handshake
Místo byte stream pracuje s message stream
Zvyšuje maximální kapacitu spojení na sumu kapacit všech dostupných cest (původní TCP je omezeno na jednu cestu a její kapacitu)
Multihoming - situace, kdy komunikující uzel má několik IP adres. Dostupné adresy si partneři vyměňují při vytvoření asociace a může se jednat o libovolnou směs IPv4 a IPv6 adres. Během komunikace je jedna z nich brána jako primární a na ni jsou odesílána data. Pro opakování však vybírá jinou a pokud má primární adresa častější problémy s dostupností, přejde odesilatel na jinou (je-li k dispozici). SCTP totiž monitoruje všechny cesty a udržuje si přehled o jejich stavu.
Doručení dat v balících (chunks) pomocí proudů eliminuje nechtěné chybějící bloky dat, jako je tomu v případě TCP.
Výběr a sledování cesty - Můžete si vybrat hlavní (primární) adresu a pokud má primární adresa častější problémy s dostupností, přejde odesilatel na jinou (je-li k dispozici).
Ověřovací a potvrzovací mechanismy - SCTP komplikuje některé útoky směřující k nedostupnosti služeb (DoS, třeba SYN flood). Zajišťuje ověření opakujících se a chybějících balíků.
Bez HoL-blocking 
Velká signalizační režie
MP-TCP
Multipath-TCP
TCP + multihoming
Umožňuje vést TCP spojení více cestami zároveň. Spojení se zachová i při změně koncových IP adres. 
Stačí aby MPTCP podporovaly koncové uzly
Tato vlastnost například umožní, aby mobilní zařízení (smartphone, tablet) změnilo svoji IP adresu a přesto navázaná Multipath TCP spojení zůstala v činnosti a mohla pokračovat (například při přechodu zařízení do jiné Wi-Fi sítě nebo při přechodu mezi Wi-Fi providerem a 3G připojením k Internetu od mobilního operátora
Zvyšuje maximální kapacitu spojení na sumu kapacit všech dostupných cest (původní TCP je omezeno na jednu cestu a její kapacitu)
Navíc oproti TCP má vlastní žízení zahlcení
QUIC
Quick UDP Internet Connections
Spolehlivé multiplexing spojení přes UDP
Hlavním cílem je vytvořit alternativu pro aplikace k TCP. Chce řešit nutnost navazovat spojení (první data až po 1,5 RTT)
Umí šifrovat, takže je to možná náhrada za TLS/SSL. Umí efektivněji navázat spojení (vše se nacpe do jedné zprávy) než SSL, takže úspora času. 
Pro FLOW control používá SMART s kumulativním potvrzováním
Pro řízení zahlcení používá TCP Cubic
Má zabudovanou opravu chyb (FEC) - je možné z došlých paketů opravit poškozený paket (něco jako RAID 5 u disků)
Místo sekvenčních čísel se používá entropy hash
V nejlepším případě connection-less, jinak connection-oriented