update
This commit is contained in:
+33
-20
@@ -212,6 +212,7 @@ V této kapitole představíme distribuované systémy. Popíšeme, na čem stoj
|
||||
Počítačový systém se skládá ze služeb, každá implementovaná jako kolekce procesů, které dohromady plní společný úkol. Moderní systémy jsou ale čím dál větší a úkoly, které musí plnit, jsou složitější. To vedlo ke vzniku síťových systémům, ve kterých jsou procesy rozmístěné přes více počítačů a komunikují spolu posíláním zpráv. Výhod je hned několik. Část systému může být umístěna počítači blíž zákazníkovi a snížit tak odezvu. Když jeden proces selže, může být jiný, který plní stejnou službu a může systém udržet v provozu. Konkrétní skupinou jsou distribuované systémy, které mají mnoho procesů rozmístěných přes více počítačů, které aktivně spolupracují a jeví se jako jeden celek.
|
||||
|
||||
|
||||
|
||||
% Počítačový systém se skládá ze služeb, každá je implementována jako kolekce procesů a dohromady plní společný úkol. Systém, ve kterém jsou procesy služeb na různých počítačích propojených v síti, se nazývá \uv{síťový systém}. Zmíníme dva důvody, proč procesy takto rozmístit. Prvním může být záměr \uv{integrace} více existujících systémů. Například se v průběhu života software zjistí, že neposkytuje všechny potřebné služby. Mohou se změnit požadavky nebo se rozšíří uživatelská základna o skupinu, se kterou se původně nepočítalo. Pokud tuto službu poskytuje jiný systém na jiném počítači, můžeme oba systémy spojit. Druhým důvodem může být \uv{expanze}, kdy jeden počítač nesplňuje požadavky na výkon.
|
||||
|
||||
% Síťové systémy můžeme dále rozdělit na \uv{decentralizované} a \uv{distribuované}. Decentralizované jsou většinou ty, které se rozrostly přes více počítačů kvůli integraci. Distribuovaný systém se snaží být dostatečně rozprostřen přes více počítačů tak, aby dokázal plnit svůj úkol. Například aby umožňil snadno přidávat do systému služby, měl dostatečně nízkou odezvu nebo aby bylo možné ho škálovat pro velké množství požadavků.
|
||||
@@ -241,7 +242,7 @@ Co občas může vadit je, že jsou služby \uv{referenčně vázané}. To zname
|
||||
|
||||
\subsubsection{Systémové architektury} \label{sec:system_architecture}
|
||||
|
||||
Pro systémové architektury představíme a využijeme dva vzory: asymetrickou klient-server a symetrickou peer-to-peer.
|
||||
Pro systémové architektury představíme a později využijeme dva modely: asymetrickou klient-server a symetrickou peer-to-peer.
|
||||
|
||||
Asymetrickou architekturou, kde je komponenta buď server, nebo klient, se nazývá \uv{klient-server}. Pouze klienti mohou serverům posílat dotazy a dostávat od nich odpovědi. Vztah je tedy asymetrický. Příkladem jsou webové servery a webové prohlížeče, které fungují jako klienti. Tento model se hodí například pro autoritativní server, který určuje stav hry a pouze jej replikuje klientům. Usnadňuje synchronizaci jednotlivých klientů a zvyšuje efektivitu, protože se účastníci nemusí shodovat, ale pouze přijmout fakt ze serveru.
|
||||
|
||||
@@ -256,13 +257,11 @@ Symetrická architektura, kdy obě strany jsou si rovny, se nazývá \uv{peer-to
|
||||
|
||||
\subsection{Komunikace}
|
||||
|
||||
V síťovém systému není sdílená paměť. Místo toho se pro komunikaci mezi procesy používá posíláním primitivních zpráv pomocí systémových volání. To se snažíme v distribuovaných systémech skrýt za vhodnějším rozhraním. V této podkapitole si představíme různé abstrakce a v podkapitole \ref{sec:NetworkCommunication} ukážeme podrobněji, jak se taková komunikace realizuje.
|
||||
V síťovém systému není sdílená paměť. Místo toho se mezi procesy komunikuje posíláním zpráv pomocí systémových volání. To se snažíme v distribuovaných systémech skrýt za vhodnějším rozhraním. V této podkapitole si představíme různé abstrakce a v podkapitole \ref{sec:NetworkCommunication} ukážeme podrobněji, jak se taková komunikace realizuje.
|
||||
|
||||
Pro schování komunikace a platformy, na které proces běží, se využívá \uv{middleware}. Jedná se o komponentu, která leží mezi aplikací a operačním systémem a poskytuje komunikační služby. Není závislá na žádné konkrétní aplikaci. Příkladem je distribuovaná služba DNS, která podle doménového jména vyhledá síťovou adresu, jako například adrese \texttt{www.seznam.cz} přiřadí síťovou IP adresu \texttt{77.75.77.222}.
|
||||
|
||||
Pro různé účely a situace máme jiné modely komunikace. Například email je typický příklad \uv{persistentní} komunikace. Po odeslání si persistentní middleware zprávu uloží do té doby, dokud ji příjemce nepřijme. To znamená, že proces příjemce nemusí běžět v době, kdy odesílatel odesílá.
|
||||
|
||||
Na druhou stranu máme \uv{transientní} komunikaci, kdy zpráva je uložena jen po dobu, kdy běží proces odesílatele a příjemce. To znamená, že pokud příjemce není dostupný, zprávu nikdy nepřijme. Protokoly v transportní vrstvě jsou transientní.
|
||||
Pro různé účely a situace máme jiné modely komunikace. Například email je typický příklad \uv{persistentní} komunikace. Po odeslání si persistentní middleware zprávu uloží do té doby, dokud ji příjemce nepřijme. To znamená, že proces příjemce nemusí běžět v době, kdy odesílatel odesílá. Na druhou stranu máme \uv{transientní} komunikaci, kdy zpráva je uložena jen po dobu, kdy běží proces odesílatele a příjemce. To znamená, že pokud příjemce není dostupný, zprávu nikdy nepřijme.
|
||||
|
||||
Dále může být komunikace \uv{synchronní} nebo \uv{asynchronní}. Asynchronní znamená, že odesílatel pokračuje v běhu okamžitě po odeslání zprávy. Ta se dočasně uloží v middleware do doby, než se odešle. Na druhou stranu při synchronní komunikaci volající proces zastaví, dokud neobdrží odpověď z cílového procesu. Obecně tedy definujeme tři body, kde může nastat synchronizace (proces odesílatele pokračuje v práci). Zaprvé hned poté, co middleware převzal zprávu a zodpovědnost za její doručení. Zadruhé v moment, kdy byla zpráva doručena druhému procesu. Zatřetí až v moment, kdy druhá strana zpracovala požadavek a dostali jsme odpověď.
|
||||
|
||||
@@ -275,7 +274,10 @@ Prvním přístupem je Remote Procedure Call, který procesu umožňuje zavolat
|
||||
|
||||
Jedná se o intuitivní řešení, ale přináší pár problémů. Dva počítače mají různý adresní prostor, proto je třeba vyřešit, jak bude procedura využívat ukazatele do svého adresního prostoru, nebo jestli tuto vlastnost zakáže.
|
||||
|
||||
Druhým přístupem je posílání zpráv. V tomto přístupu posílají procesy zprávy na logické cíle pomocí systémového jména, nikoliv fyzické adresy. Tento přístup méně schovává fakt, že procesy jsou rozmístěny na více počítačích a abstrakce z fyzických adres na jména pomáhá. Využívá se v architektuře publish-subscribe nebo občas v architektuře orientované na služby.
|
||||
Druhým přístupem je posílání zpráv. V tomto přístupu posílají procesy zprávy na
|
||||
logické cíle pomocí jména v systému, nikoliv fyzické adresy. Tento přístup méně
|
||||
schovává fakt, že procesy jsou rozmístěny na více počítačích. Abstrakce z
|
||||
fyzických adres na jména pomáhá jednoduchosti. Využívá se v architektuře publish-subscribe nebo občas v architektuře orientované na služby.
|
||||
|
||||
Opět je potřeba, aby se dva koncové body shodli na významu bitů jednotlivých zpráv. Většinou jsou v programu zprávy reprezentovány objektem, který je pro síť převeden na n-tici bitů, procesem zvaným \uv{serializace}. V praktické části představíme serializaci podrobněji.
|
||||
|
||||
@@ -291,18 +293,21 @@ Opět je potřeba, aby se dva koncové body shodli na významu bitů jednotlivý
|
||||
|
||||
\subsection{Počítačová Síť} \label{sec:NetworkCommunication}
|
||||
|
||||
Nedílnou součástí distribuovaného systému je síť, přes kterou mohou procesy posílat primitivní zprávy. V této podkapitole se zaměříme na komunikaci mezi dvěma procesy v síti, a to i těch, které nejsou součástí jednoho síťového systému. Počítačová síť je skupina propojených počítačů, které si mezi sebou přenášejí data. Například lokální sítě (LAN) propojují až tisíce počítačů, které jsou geograficky blízko, například v rámci jedné budovy. Rozsáhlé sítě (WAN) propojují miliony různých zařízení po celém světě. Příkladem je síť Internet.
|
||||
V této části popíšeme, jak mezi sebou mohou komunikovat dva procesy, které běží na dvou různých počítačích. Počítačová síť je skupina propojených počítačů, které si mezi sebou přenášejí data. Definujeme několik typů sítí, které se liší velikostí a provedením. Například lokální sítě (LAN) propojují až tisíce počítačů, které jsou geograficky blízko, například v rámci jedné budovy. Rozsáhlé sítě (WAN) propojují miliony různých zařízení po celém světě. Příkladem je rozsáhlá síť Internet.
|
||||
|
||||
Počítačovou síť si lze představit jako graf, ve kterém počítače představují vrcholy a fyzická média mezi nimi jsou hrany. Vrcholy dále dělíme na \uv{koncové body} a \uv{propojovací prvky}. Koncové body jsou počítače, mobilní telefony a jiná zařízení, na kterých běží procesy. Dva procesy na dvou různých počítačích si mezi sebou mohou posílat zprávy. Propojovací prvky jsou přepínače, rozbočovače a opakovače. Ty naopak slouží pouze k směrování zpráv po síti. Využití je propojení skupiny počítačů do sítě přes jedno spojení jako vidíme na obrázku TODO. Propojovací body jsou E a D. Není potřeba připojovat každý počítač s každým.
|
||||
Počítačovou síť si lze představit jako graf, ve kterém počítače představují
|
||||
vrcholy a fyzická média mezi nimi jsou hrany. Vrcholy dále dělíme na \uv{koncové body} a \uv{propojovací prvky}. Díky propojovacím prvkům je možné poslat zprávu přes více vrcholů na cílový počítač. Příkladem takových prvků jsou přepínače, rozbočovače a opakovače. Sítím, které je využívají, se říká \uv{přepínané sítě}. Koncové body jsou například stolní počítače, mobilní telefony a jiná zařízení, na kterých běží komunikující procesy.
|
||||
|
||||
Dva počítače, přímo propojené fyzickým médiem, komunikují posíláním n-tic bytů zvané \uv{rámce}. Variantou jsou \uv{přepínané} sítě, které nemusejí mít mezi všemi dvojicemi počítačů přímé spojení, ale využívají \uv{přepínače}. Proces, kdy doručujeme zprávu na cílový počítač přes vícero přepínačů se nazývá \uv{směrování}. Každý vrchol v takové síti musí mít přiřazenou unikátní \uv{síťovou adresu} a posílali se formátované rámce zvané \uv{pakety}. Ty se skládají z hlavičky, ve které najdeme informace ke směrovaní, a tělu obsahujícím samotnou přenášenou zprávu.
|
||||
Dva počítače, přímo propojené fyzickým médiem, komunikují posíláním n-tic bytů zvané \uv{rámce}. V přepínaných sítích mají rámce konkrétní formát, který pomáhá při hledání cesty v grafu, tzv. \uv{směrování}. Takový formátovaný rámec se nazývá \uv{paket}. Zároveň musí mít každý vrchol v takové síti přiřazenou unikátní \uv{síťovou adresu}. Paket se skládá z hlavičky a těla. V hlavičce najdeme síťovou adresu cílového počítače, pomocí které přepínače hledají pro paket cestu. V těle paketu pak samotná zpráva.
|
||||
|
||||
\subsection{Komunikace v síti}
|
||||
|
||||
V této části představíme jak je realizována komunikace v síti. Aby si dva počítače navzájem rozuměly, musejí se shodnout na významu jednotlivých bitů rámců, které si mezi sebou budou posílat. K takové definici slouží \uv{komunikační protokol}: soubor pravidel pro výměnu informací mezi počítači. Definuje syntaxi, sémantiku a synchronizaci zpráv.
|
||||
V této části představíme jak je implementována komunikace v síti. Aby si dva počítače, které si posílají rámce, navzájem rozuměly, musejí se shodnout na významu jednotlivých bitů rámců. K takové definici slouží \uv{komunikační protokol}: soubor pravidel pro výměnu informací mezi počítači. Definuje syntaxi, sémantiku a synchronizaci zpráv.
|
||||
|
||||
Každý protokol poskytuje komunikační služby. Tyto služby rozdělujeme na dvě skupiny: ty co před komunikací navážou spojení a ty co ne. V prvním případě musejí obě strany přijmout a navázat spojení a potencionálně se domluvit na jeho dalších parametrech. Jakmile jejich komunikace skončí, spojení se ukončí. Příkladem takové služby je telefoní linka. V druhém případě může odeslat zprávu kdykoliv a bez předchozího upozornění druhé strany. Příkladem takové komunikace je posílání emailu.
|
||||
|
||||
Protokoly jsou často organizovány do vrstev, které se liší svou zodpovědností. Každá vrstva poskytuje komunikační službu přes své rozhraní. TODO
|
||||
|
||||
\subsubsection{Rodina protokolů TCP/IP}
|
||||
|
||||
Rodina protokolů pro komunikaci v síti Internet je TCP/IP. Jedná se o více protokolů organizovaných do vrstev, kde každá může používat jen tu pod ní. Vrstvenou architekturu vidíme na obrázku \ref{fig:layer_architecture}. Vrstva $N$ používá rozhraní vrstvy $N-1$. Každá vrstva poskytuje komunikační služby. Počítač A i B tak vidí stejnou službu. Představme si, že rozhraní má dvě funkce: pro čtení a pro zápis. Aplikace do vrstvy $N$ zapíše zprávu, kterou chce, aby si proces využívající stejnou službu, ale na druhém počítači, mohl přečíst. Je potřeba, aby vrstva zapsala zprávu ve formátu, kterému bude rozumnět strana A i strana B. Tento formát je právě protokol, jak vidíme na obrázku \ref{fig:layer_architecture}.
|
||||
@@ -318,9 +323,11 @@ Rodina protokolů pro komunikaci v síti Internet je TCP/IP. Jedná se o více p
|
||||
|
||||
Název se skládá ze dvou důležitých protokolů: IP (Internet Protocol) a TCP (Transmission Control Protocol). IP slouží pro směrování paketů a TCP pro řízení přenosu. IP umožňuje komunikaci libovolných dvou uzlů počítačů v propojených sítích. TCP zajišťuje spolehlivý obousměrný přenos dat mezi procesy na dvou počítačích (ne nutně různých).
|
||||
|
||||
Protokol IP má za úkol doručit paket od odesílatele na příjemce pouze podle IP adresy, která je v hlavičce paketu. IP nenavazuje spojení a nezaručuje doručení. Důvodem je princip \uv{end-to-end}, který říká, že body mezi odesílatelem a příjemcem, jako routery a přepínače, by měli být co nejjednodušší. Spolehlivost musejí zaručit až dva koncové body, například číslováním paketů a sledováním stavu doručení. V případě, že paket chybí, ho musí odesílatel odeslat znova.
|
||||
Protokol IP má za úkol doručit paket od odesílatele na příjemce pouze podle IP adresy, která je v hlavičce paketu. IP nenavazuje spojení a nezaručuje doručení. Důvodem je princip \uv{end-to-end}, který říká, že body mezi odesílatelem a příjemcem, jako routery a přepínače, by měli být co nejjednodušší. Spolehlivost musejí zaručit až dva koncové body, například číslováním paketů a sledováním stavu doručení. Případné ztráty paketu musí odesílatel tento fakt zjistit a ztracené pakety odeslat znovu.
|
||||
|
||||
Router udržuje frontu příchozích paketů, která má fixní velikost. Jakmile objem příchozích paketů překročí kapacitu fronty, router má různé politiky, jak se v takové situaci zachovat. Nejběžnější je politika \uv{tail-drop}, kdy paket zahodí. Proto musejí koncové body hlídat a měřit zahlcení sítě. Měli by hlídat, jak moc paketů se ztrácí a případně snížit frekvenci odesílání. V TCP/IP se o to stará protokol TCP, který si má frontu paketů, které musí odeslat a udržuje si ve frontě okno paketů, které jsou odeslané ale nepotvrzené neboli \uv{in-flight}. Pokud není potvrzeno až příliš paketů, okno zmenší a tím sníží počet paketů, které mohou být najednou v síti.
|
||||
Ztráta paketu nastává, když je některý z přepínačů na cestě mezi odesílatelem a příjemcem, zahlcený. Přepínač si přijaté pakety ukládá do fixně velké fronty, ze které také postupně odebírá a snaží se najít další vhodný uzel, kam každý paket poslat. Pro případ přehlcení fronty má přepínač definovanou politiku. Běžná je politika \uv{tail-drop}, která nově příchozí paket, který se nevejde do fronty, zahodí. V tento moment se paket ztrácí.
|
||||
|
||||
Koncové body si musejí hlídat a měřit zahlcení sítě. V případě, že jsou uzly na cestě zahlcené, měl by odesílatel snížit frekvenci odesílání. V TCP/IP se o to stará protokol TCP. Příjemce pro každý paket, který dostane, musí odeslat acknoledge, kterým oznamuje odesílateli, že paket přijal. Odesílatel si proto drží frontu paketů, které musí odeslat. Zároveň si udržuje okno těchto paketů, které jsou odeslané ale ještě nepotvrzené neboli \uv{in-flight}. Pokud není potvrzeno až příliš paketů, okno zmenší a tím sníží počet paketů, které mohou být najednou v síti.
|
||||
|
||||
Konkrétně architektura TCP/IP je rozdělena do čtyř vrstev: aplikační, transportní, síťová a síťové rozhraní. Každá vrstva obsahuje množinu protokolů a pro každou situaci lze sestavit ideální čtveřice. Vrstvy podrobněji představíme.
|
||||
|
||||
@@ -419,6 +426,8 @@ V protokolu na transportní vrstvě dochází k head-of-line blokování. Pokud
|
||||
|
||||
Nevýhoda pro nás byla, že přenáší proud dat. Jinými slovy, v protokolu není proud rozdělen na jednotlivé bloky se zprávou. Tuto logiku si musíme implementovat sami. Proto jsme v praktické části vytvořili vlastní protokol, který umí v proudu zprávy správně oddělit.
|
||||
|
||||
Pro šifrovánou komunikaci je potřeba použít další protokol, například TLS. Ten opět vyžaduje handshake, protože se strany musejí dohodnout na tajném klíči.
|
||||
|
||||
\subsubsection{UDP}
|
||||
|
||||
Méně spolehlivá alternativa je UDP, neboli User Datagram Protocol. Ten komunikuje posíláním \uv{datagramů}, na rozdíl od proudu bytů, jako je tomu v případě TCP. Znamená to, že to co vrátí jedno systémové volání pro čtení ze soketu je právě jedno volání pro zápis, které udělal odesílatel. Protokol nenavazuje spojení a nezaručuje doručení datagramů.
|
||||
@@ -429,15 +438,15 @@ Je vhodný jako základ pro vlastní transportní protokol. Například protokol
|
||||
|
||||
\subsubsection{QUIC}
|
||||
|
||||
QUIC je spolehlivý protokol transportní vrstvy, který poskytuje multiplexní komunikaci založenou na TLS 1.3, od společnosti Google. Jeho cílem je být efektivnější varianta TCP, která využívá protokol UDP. Znamená to například, že lze snížit množství ahead-of-line blokování, ke kterému dochází z důvodu ztracených paketů. Mezi dvěma koncovými body vytváří spolehlivé spojení.
|
||||
QUIC je spolehlivý protokol transportní vrstvy, který poskytuje multiplexní komunikaci založenou na TLS 1.3. Autorem protokolu je společnost Google. Mezi jeho hlavní výhody patří redukce ahead-of-line blokování. Tento protokol je pro nás důležitý, protože popisuje implementaci spolehlivosti, handshake a dalších věcí nad protokolem UDP. V pozdější kapitole představíme náš protokol, který je protokolem QUIC inspirovaný a dále ho upravuje. Mezi úpravy patří možnost odeslání zpráv nespolehlivě a s různým seřazením. V této části podrobněji popíšeme části protokolu QUIC, které jsou pro náš protokol důležité.
|
||||
|
||||
Na rozdíl od TCP umožňuje otevřít více nezávislých proudů paketů v jednom spojení a modelovat tak částečné uspořádání. TCP má vždy právě jeden proud.
|
||||
Výhoda QUIC oproti TCP je možnost vytvořit více nezávislých proudů dat v jednom navázaném spojení, mezi dvěma koncovými body. TCP má vždy právě jeden proud.
|
||||
|
||||
Mezi dvěma koncovými body se posílají pakety. Ty obsahují rámce, které se rozdělují na ovládací a proudové. Ovládací slouží pro ovládání koncových bodů a úprava navázaného spojení: otevírání a zavírání proudů, změna stavu nebo udržování spojení naživu. Proudové obsahují aplikační data. Stejně jako TCP, i QUIC přenáší data jako proud bytů a oddělení jednotlivých zpráv je nutné implementovat zvlášť.
|
||||
|
||||
\begin{description}
|
||||
\item[{Pakety}] \hfill \\
|
||||
Dvě strany komunikující přes QUIC protokol mezi sebou posílají sekvenční pakety různých typů. Příkladem jsou: \texttt{Initial}, \texttt{0-RTT}, \texttt{Handshake} a \texttt{1-RTT}. Liší se v síle šifrování, které používají, každý typ má svůj číselný prostor a liší se i hlavička. Každý paket má své unikátní pořadové číslo, které se v rozumném čase nesmí použít znova, a to ani při opakovaném poslání stejného paketu z důvodu ztráty. Různé typy paketů mají ale čítač nezávislý. Pakety typu \texttt{Initial} a \texttt{Handshake} mají dlouhou hlavičku a \texttt{0-RTT} a \texttt{1-RTT} mají krátkou hlavičku.
|
||||
Dvě strany komunikující přes QUIC protokol mezi sebou posílají sekvenční Pakety různých typů. Příkladem jsou: \texttt{Initial}, \texttt{0-RTT}, \texttt{Handshake} a \texttt{1-RTT}. Liší se v síle šifrování, které používají, každý typ má svůj číselný prostor a liší se i hlavička. Každý paket má své unikátní pořadové číslo, které se v rozumném čase nesmí použít znova, a to ani při opakovaném poslání stejného paketu z důvodu ztráty. Různé typy paketů mají ale čítač nezávislý. Pakety typu \texttt{Initial} a \texttt{Handshake} mají dlouhou hlavičku a \texttt{0-RTT} a \texttt{1-RTT} mají krátkou hlavičku.
|
||||
|
||||
\item[{Spolehlivost}] \hfill \\
|
||||
Protokol QUIC zajišťuje spolehlivost jednotlivých rámců. Příjemce musí odeslat zpět odesílateli rámec typu \texttt{ACK} se zakódovaným číslem paketu, ve kterém rámce získal. Tento rámec může obsahovat i více paketů zároveň a protokol toho využívá tak, že neposílá \texttt{ACK} tak často.
|
||||
@@ -452,9 +461,16 @@ Mezi dvěma koncovými body se posílají pakety. Ty obsahují rámce, které se
|
||||
|
||||
\end{description}
|
||||
|
||||
Popíšeme, jak v QUIC funguje handshake, který vidíme na obrázku \ref{fig:quic_handshake}. Nejprve začíná strana, která se chce připojit, posláním paketu typu \texttt{Initial} s rámcem CRYPTO s ClientHello. Server odpoví několika rámci: \texttt{Initial} s \texttt{CRYPTO} rámcem se ServerHello společně s ACK rámcem a paketem typu \texttt{Handshake} ve kterém je \texttt{CRYPTO} rámec s potřebnými informacemi pro TLS. Aplikační data jsou v paketu typu \texttt{1-RTT} a \texttt{0-RTT}. Jakmile klient dostane tyto informace, mohou si strany posílat šifrovaná data. Toho QUIC využívá a první odpověď ze serveru už může obsahovat paket \texttt{1-RTT} se \texttt{STREAM} rámci s šifrovanými daty, jak vidíme na obrázku \ref{fig:quic_handshake}. Dále si všimněme, že každý typ paketu má vlastní prostor čísel. QUIC používá UDP a proto posílá datagramy. Do jednoho datagramu spojuje více paketů. Tři pakety ze serveru, které přijdou jako odpověď, se tak mohou odeslat jako jeden datagram.
|
||||
|
||||
Při handshake se dva koncové body mimo jiné domlouvají na svých unikátních číslech. Při Client-Hello se server podívá na Source Connection ID a zapamatuje si ho jako ID připojení druhé strany. Následně vygeneruje své vlastní ID a přiřadí mu instanci relace. Pak se podívá na Destination Connection ID a nastaví si, aby pakety, které mají toto číslo jako Destination Connection ID, se připisovaly nově vytvořené relaci. Toto číslo jako takové nebude používat a v odpovědi jako Source Connection ID bude jeho vlastní vygenerované.
|
||||
Než popíšeme, jak funguje proces handshake pro navázání spojení, popíšeme na čem se dvě strany budou domlouvat. V navázaném spojení má každá strana unikátní ID. Když chce odesílatel poslat paket, musí do jeho hlavičky definovat ID příjemce. Je to z toho důvodu, že koncový bod v QUIC může mít více navázaných spojení pod stejným portem a tímto mezi nimi rozlišuje. V TCP je unikátní identifikátor síťová adresa. Ta se ale může snadno změnit, například když přepneme z mobilních dat na Wi-Fi. V ten moment by v TCP nastal proces time-out, kdy obě strany zjišťují, že už se nevidí a spojení by ukončili. Následně by se původní iniciátor komunikace, nyní s novou IP adresou, pokusil spojení opět navázat. To by znamenalo zopakovat celý proces handshake. V případě QUIC je možné se opakovanému navazování spojení lze vyhnout. Jakmile příjemci dorazí paket na původní ID, ale z nové IP adresy, provede authentizaci a pokud projde, tak si IP adresu druhé strany přenastaví.
|
||||
|
||||
Dostáváme se k šifrování, které QUIC podporuje už v základu. Před tím, než může začít šifrovaná komunikace, musí se obě strany shodnout na tajném klíči, kterým budou zprávy šifrovat. Příkladem protokolu pro šifrovanou komunikaci je TLS. V případě TCP by TLS nebo jiný šifrovací protokol stál ještě nad TCP protokolem. QUIC ale implementuje TLS už v základu, konkrétně verzi 1.3. V původní implementaci by po handshake v TCP bylo potřeba udělat druhý handshake a shodnout se na tajném klíči. V případě QUIC se tajný klíč vytváří už při hlavním
|
||||
|
||||
Pro navázání spojení je nutné se v QUIC shodnout na ID obou stran a tajném klíči procesem zvaný handshake. Diagram vidíme na obrázku \ref{fig:quic_handshake}. V procesu si dvě strany, neboli koncové body, posílají konkrétní ovládací rámce.
|
||||
|
||||
|
||||
Nejprve začíná strana, která se chce připojit, posláním paketu typu \texttt{Initial} s rámcem CRYPTO s ClientHello. Server odpoví několika rámci: \texttt{Initial} s \texttt{CRYPTO} rámcem se ServerHello společně s ACK rámcem a paketem typu \texttt{Handshake} ve kterém je \texttt{CRYPTO} rámec s potřebnými informacemi pro TLS. Aplikační data jsou v paketu typu \texttt{1-RTT} a \texttt{0-RTT}. Jakmile klient dostane tyto informace, mohou si strany posílat šifrovaná data. Toho QUIC využívá a první odpověď ze serveru už může obsahovat paket \texttt{1-RTT} se \texttt{STREAM} rámci s šifrovanými daty, jak vidíme na obrázku \ref{fig:quic_handshake}. Dále si všimněme, že každý typ paketu má vlastní prostor čísel. QUIC používá UDP a proto posílá datagramy. Do jednoho datagramu spojuje více paketů. Tři pakety ze serveru, které přijdou jako odpověď, se tak mohou odeslat jako jeden datagram.
|
||||
|
||||
|
||||
\begin{figure}
|
||||
\begin{center}
|
||||
@@ -466,9 +482,6 @@ Při handshake se dva koncové body mimo jiné domlouvají na svých unikátníc
|
||||
|
||||
Všimněme si speciálního typu paketu \texttt{0-RTT}, který slouží pro poslání aplikačních dat ještě před samotným navázáním spojení, ale pouze se základním šifrováním. Pro tento paket se využívá první Destination Connection ID, které ale vygeneroval iniciátor komunikace. Jedno spojení může mít přiřazeno více ID. Spojení, které si založí druhá strana, si přiřadí jak ID vygenerované touto stranou, tak ID, které zvolil iniciátor. Když přijde později paket \texttt{0-RTT}, bude správně nasměrován na instanci spojení.
|
||||
|
||||
Způsobem, jakým QUIC redukuje nebo dokonce eliminuje head-of-line blocking, je multiplexing. Přes jedno spojení je možné otevřít více paralelních proudů, které se navzájem neovlivňují.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user