moved protocols into separate section
This commit is contained in:
Martin Slachta
+69
-99
@@ -201,33 +201,54 @@ V poslední kapitole představíme měření, které jsme provedli a jejich výs
|
||||
% - 3. Představit asynchroní posílání zpráv
|
||||
|
||||
|
||||
\section{Počítačová síť} \label{sec:NetworkCommunication}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
\newpage
|
||||
|
||||
\section{Distribuované systémy}
|
||||
|
||||
V této kapitole představíme distribuované systémy. Nejprve si zadefinujeme, co distribuovaný systém je. Podíváme se, čím jsou specifické a jaké vlastnosti mohou mít. Následně se podíváme hlouběji jak takové systémy fungují. Distribuované systémy jsou často složité, proto představíme různé architektonické vzory, které i později při implementaci vlastního distribuovaného systému využijeme.
|
||||
|
||||
Začneme pojmem, co je vlastně počítačový systém. Ten 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ů, 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 na počítači blíž uživateli pro snížení odezvy. 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.
|
||||
|
||||
Příkladem distribuovaného systému je World Wide Web, zkráceně WWW. Jedná se o informační systém, který umožňuje prohlížet, ukládat a odkazovat dokumenty umístěné na internetu. Dokumenty mohou být například webové stránky, obrázky nebo videa a jsou uloženy na webových serverech. Odkazy na ně jsou ve formátu URL. Distribuovanost systému umožňuje snadné rozšíření, protože každý může snadno přidat svůj server se svými dokumenty, které se tak stanou dostupné v systému. To zároveň rozloží zátěž přes více počítačů a systém tak zvládá miliardy požadavků denně. Zároveň se celý systém jeví jako jeden celek, který z URL adresy vyhledá server a vrátí dokument.
|
||||
|
||||
\subsection{Počítačová síť} \label{sec:NetworkCommunication}
|
||||
|
||||
Distribované systémy stojí na počítačových sítích. Ty umožňují komunikaci mezi dvěma procesy 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}. 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.
|
||||
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. Tyto prvky mají za úkol třídit poslané zprávy a doručit je správnému koncovému bodu. Fungují tak podobně jako třídící centra pošty. Sítím, které využívají tyto prvky, se říká \uv{přepínané sítě}. Stejně jako u pošty, musejí mít koncové body přiřazenou unikátní \uv{síťovou adresu}. 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}. 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}. Skládá se z hlavičky, kde jsou informace ke směrování, a těla, kde je samotná zpráva. Každý vrchol v takové síti má přiřazenou unikátní \uv{síťovou adresu}. Cílovou adresu najdeme právě v hlavičce paketu.
|
||||
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, neboli \uv{směrování}. Takový formátovaný rámec se nazývá \uv{paket}. Skládá se z hlavičky, kde jsou informace ke směrování, jako síťovou adresu, a těla, kde je samotná zpráva.
|
||||
|
||||
\subsection{Komunikace}
|
||||
\subsubsection{Komunikace}
|
||||
|
||||
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.
|
||||
% az tady říkáme, že síťový systém nemá sdílenou pamět???
|
||||
V této části popíšeme, jak samotná komunikace posíláním zpráv funguje. Představíme, jaké nástroje a vzory používáme. Konkrétně nás bude zajímat, jak můžeme komunikaci co nejvíce skrýt. Dále zmíníme vlastnosti, které může komunikace mít.
|
||||
|
||||
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}.
|
||||
Ke skrytí komunikace v distribuovaných systémech používáme komponenty, kterým se říká \uv{middleware}. Ty 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.
|
||||
Komunikace může mít různé vlasnosti. 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ěď.
|
||||
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 momenty, kdy 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ěď.
|
||||
|
||||
% TODO: Přidat referenčně vázanost?
|
||||
|
||||
\subsubsection{Modely pro komunikaci}
|
||||
|
||||
Pro každý účel musíme vhodně zvolit konfiguraci perzistence a synchronizace. Představíme dva modely komunikace, které posílání zpráv skrývají a jsou implementovány jako middleware: Message Oriented Middleware (MOM) a Remote Procedure Call (RPC).
|
||||
Představíme dva konkrétní způsoby, jakými se na komunikaci dívat. Nejedná se o konkrétní implementace, ale pouze modely, které můžeme při vývoji middleware použít. Zároveň si řekneme, jaké vlastnosti výsledná komunikace může mít.
|
||||
|
||||
Prvním přístupem je Remote Procedure Call, který procesu umožňuje zavolat lokální proceduru s implementací na jiném počítači. Když proces A zavolá proceduru na počítači B, A se pozastaví a začne se vykonávat na B. Jakmile se dokončí, pošle se výsledek zpět na A, které poté pokračuje. Tento model je synchronní a transientní. Cílem je, aby volání vypadalo jako by implementace byla lokální a skrýt tak komunikaci mezi počítači.
|
||||
Prvním přístupem je Remote Procedure Call, který procesu umožňuje zavolat lokální proceduru s implementací na jiném počítači. Tím kompletně skrývá, že objekt, který jsme zavolali, je na jiném počítači. Když proces A zavolá proceduru na počítači B, proces A se pozastaví a začne se vykonávat nový proces na počítači B. Ten spouští zavolanou metodu. Jakmile metoda vrátí, pošle se výsledek zpět na počítač s procesem A, který poté i s výsledkem pokračuje. Tento model je synchronní a transientní. Cílem je, aby volání vypadalo jako by implementace byla lokální a skrýt tak komunikaci mezi počítači.
|
||||
|
||||
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.
|
||||
|
||||
% TODO: Možná pomaleji zmínit logické cíle
|
||||
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
|
||||
@@ -240,35 +261,12 @@ Opět je potřeba, aby se dva koncové body shodli na významu bitů jednotlivý
|
||||
% - Systémovým voláním zprávu odešle
|
||||
% - Procesy se musejí dohodnout na významu bitů
|
||||
|
||||
% Druhým přístupem je posílání zpráv. V tomto přístupu aplikace posílají zprávy na čistě logický cíl. Např. identifikovaný typem zprávy. Aplikace pak může projevit zájem o různé typy zpráv a middleware se postará o to, že tyto zprávy aplikace dostane. Přístupu se říká \uv{publish-subscribe}.
|
||||
\subsection{Architektury systémů}
|
||||
|
||||
% TODO: Divně zmiňuji příklady
|
||||
V praktické části představujeme náš ukázkový síťový systém, který umožňuje hru pro více hráčů. V návrhu jsme využívali známé vzory, které představíme. Návrh systému rozdělíme na dvě části: softwarovou a systémovou architekturu. V softwarové architektuře řešíme komponenty a konektory mezi nimi. Druhá část architektury, která řeší role jednotlivých služeb, se nazývá \uv{systémová architektura}. Mezi příklady patří peer-to-peer nebo klient-server.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
\newpage
|
||||
|
||||
\section{Distribuované systémy}
|
||||
|
||||
V této kapitole představíme distribuované systémy. Popíšeme, na čem stojí a jaké jsou cíle, pokud se takový systém rozhodneme implementovat. Ukážeme softwarové a systémové architektury v distribovaných systémech. Poté podrobněji rozebereme komunikaci v síti.
|
||||
|
||||
|
||||
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ů, 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ů.
|
||||
|
||||
Příkladem distribuovaného systému je World Wide Web, zkráceně WWW. Jedná se o informační systém, který umožňuje prohlížet, ukládat a odkazovat dokumenty umístěné na internetu. Dokumenty mohou být například webové stránky, obrázky nebo videa a jsou uloženy na webových serverech. Odkazy na ně jsou ve formátu URL. Distribuovanost systému umožňuje snadné rozšíření, protože každý může snadno přidat svůj server se svými dokumenty, které se tak stanou dostupné v systému. To zároveň rozloží zátěž přes více počítačů a systém tak zvládá miliardy požadavků denně. Zároveň se celý systém jeví jako jeden celek, který z URL adresy vyhledá server a vrátí dokument.
|
||||
|
||||
\subsection{Architektury}
|
||||
|
||||
V praktické části jsme navrhli síťový systém. V návrhu jsme využívali známé vzory, které představíme. Návrh systému rozdělíme na dvě části: softwarovou a systémovou architekturu. V softwarové architektuře řešíme komponenty a konektory mezi nimi. Druhá část architektury, která řeší role jednotlivých služeb, se nazývá \uv{systémová architektura}. Mezi příklady patří peer-to-peer nebo klient-server.
|
||||
|
||||
Pro ilustraci rozdílu představíme známý příklad třívrstvé softwarové architektury: databázová, výpočetní a frontendová vrstva. Systémová architektura definuje, že databáze jako služba pro výpočetní vrstvu má roli serveru. Naopak služba pro replikaci ve skupině databázových serverů využívající model peer-to-peer má roli jak serveru, tak klienta. Typy si rozebereme podrobněji v této kapitole.
|
||||
Pro ilustraci rozdílu představíme známý příklad třívrstvé softwarové architektury: databázová, výpočetní a frontendová vrstva. Systémová architektura poté definuje, že databáze jako služba pro výpočetní vrstvu má roli serveru. Naopak služba pro replikaci ve skupině databázových serverů využívající model peer-to-peer má roli jak serveru, tak klienta. Typy si rozebereme podrobněji v této kapitole.
|
||||
|
||||
\subsubsection{Softwarová architektura}
|
||||
|
||||
@@ -290,9 +288,9 @@ Tento princip lze využít u systémů pro hry více hráčů pro komunikační
|
||||
|
||||
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.
|
||||
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řijmou pravdu ze serveru.
|
||||
|
||||
Symetrická architektura, kdy obě strany jsou si rovny, se nazývá \uv{peer-to-peer}. Znamená to, že obě strany mohou posílat požadavky a zprávy na druhou stranu. Využívá se například při replikaci, kdy máme několik replik, které jsou si rovny. Pouze řešíme, která vlastní jaký zdroj tak, aby nedošlo ke konfliktu dvou replik při psaní konkrétního záznamu. Libovolná replika má ale možnost odeslat svůj stav jiné, protože jsou si rovny. Tento model je vhodný například pro horizontální škálování stavových serverů, které si rozdělují část stejné služby. Například vícero serverů může zpracovávat různé části herního světa a předávají si mezi sebou entity, které mají na starost.
|
||||
Symetrická architektura, kdy obě strany jsou si rovny, se nazývá \uv{peer-to-peer}. Znamená to, že obě strany mohou posílat požadavky a zprávy na druhou stranu. Tento přístup je užitečný, pokud dva procesy mají stejnou roli a jedná se tedy pouze o repliku té stejné služby. To je potřeba, pokud je zátěž na systém až moc velká a jeden počítač ji nezvládne. Například můžeme mít více počítačů na kterých běží herní server stejné instance hry. Herní svět můžeme rozdělit na zóny a každý proces dostane svou zónu. Žádná zona není nadřazená jiné, proto spolu mohou procesy komunikovat modelem peer-to-peer a předávat si tak události, které v zónách nastali. Například sousední zóny může zajímat, že se hráč blíží k okraji a za chvíli přejde do jiné zóny. Následně může původní zóna hráče \uv{předat} druhému procesu.
|
||||
|
||||
|
||||
|
||||
@@ -300,10 +298,11 @@ Symetrická architektura, kdy obě strany jsou si rovny, se nazývá \uv{peer-to
|
||||
|
||||
|
||||
|
||||
\newpage{}
|
||||
\section{Protokoly}
|
||||
|
||||
\subsection{Protokoly}
|
||||
|
||||
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.
|
||||
% Weird
|
||||
V této části podrobně popíšeme, jak se komunikace realizuje. Aby si dva počítače rozumněli, musejí se shodnout na významu jednotlivých bytů rámců, které si posílají. To definuje \uv{komunikační protokol}: soubor pravidel pro výměnu informací mezi počítači. Představíme několik už existujících protokolů a jejich vlasnosti. V praktické části jsme vypracovali vlastní protokol optimalizovaný pro distribuované systémy her více hráčů.
|
||||
|
||||
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.
|
||||
|
||||
@@ -315,41 +314,18 @@ Každý protokol poskytuje komunikační služby. Tyto služby rozdělujeme na d
|
||||
\label{fig:layer_architecture}
|
||||
\end{figure}
|
||||
|
||||
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í. Příklad vidíme na obrázku \ref{fig:layer_architecture}. Vidíme dvě vrstvy. Každá vrstva definuje nějakou komunikační službu a má své specifické rozhraní. Toto rozhraní využívá implementace služby nad ní.
|
||||
|
||||
\subsubsection{Rodina protokolů TCP/IP}
|
||||
\subsection{Rodina protokolů TCP/IP}
|
||||
|
||||
Rodina protokolů pro komunikaci v síti Internet se nazývá TCP/IP. Jedná se o více protokolů organizovaných do vrstev. 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}.
|
||||
Rodina protokolů pro komunikaci v síti Internet se nazývá TCP/IP. Jedná se o více komunikačních protokolů, organizovaných do vrstev. Tuto architekturu vidíme na obrázku \ref{fig:layer_architecture}. Každá vrstva má svůj konkrétní význam a jinou zodpovědnost. Tuto zodpovědnost pak plní služba, která v dané vrstvě je. V jedné službě vidíme dva koncové body na dvou počítačích. Oba poskytují rozhraní pro svou instanci. To, že jsou instance fyzicky oddělené je skryté právě za komunikační službu. Vrstva $N$ zapisuje a čte z vrsvy $N-1$ a neřeší, jak si dva koncové body v $N-1$ zapsané informace předají, aby je druhá strana mohla číst. Způsob, jakým si koncové body ve vrstvě předávají informace, je právě protokol.
|
||||
|
||||
Rodina protokolů se řídí principem \uv{end-to-end}, který říká, že body mezi odesílatelem a příjemcem, jako směrovače a přepínače, by měli být co nejjednodušší. Spolehlivost a navázání spojení musejí implementovat až dva koncové body. Případné ztráty paketu musí odesílatel zjistit a ztracené pakety odeslat znovu.
|
||||
|
||||
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\cite{computer_networks}. 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í.
|
||||
|
||||
Název rodiny protokolů se skládá ze dvou důležitých protokolů: IP (Internet Protocol) a TCP (Transmission Control Protocol). IP umožňuje komunikaci libovolných dvou uzlů počítačů v propojených sítích. Definuje formát adresy koncových bodů a směrování. Protokol nenavazuje spojení ani nezaručuje doručení. TCP zajišťuje spolehlivý obousměrný přenos dat mezi procesy na dvou počítačích (ne nutně různých).
|
||||
|
||||
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 směrovače 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 zjistit a ztracené pakety odeslat znovu.
|
||||
|
||||
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.
|
||||
|
||||
\begin{description}
|
||||
\item[{Aplikační}] \hfill \\
|
||||
Nejvyšší je \uv{aplikační} vrstva, ve které jsou aplikace. Příkladem protokolů jsou FTP, SMTP, HTTP nebo gRPC. Tato vrstva je rozbalena až na koncovém bodu, protože neobsahuje žádné podstatné informace pro směrování.
|
||||
|
||||
\item[{Transportní}] \hfill \\
|
||||
Druhá vrstva je \uv{transportní}. Tato vrstva, stejně jako aplikační, je rozbalena až na koncových bodech, jak vidíme na obrázku \ref{fig:tcpip}. Proto se jim někdy říká end-to-end protokoly. Není totiž důležitá pro směrování paketů. Stará se o to, jaké pakety přišli, v jakém pořadí a jestli nejsou poškozené. Příkladem protokolů jsou TCP, UDP nebo QUIC.
|
||||
|
||||
\item[{Síťová}] \hfill \\
|
||||
Pro adresaci slouží síťová vrstva. Ta směruje a předává jednotlivé datagramy. Příkladem protokolů jsou IP, ARP, RARP nebo IPSEC. Je nutné, aby stejně jako vrstva síťového rozhraní, byla implementována ve všech vrcholech na cestě mezi dvěma počítači, které chtějí komunikovat přes internet.
|
||||
|
||||
\item[{Síťové rozhraní}] \hfill \\
|
||||
Nejnižší vrstva, která se stará o přenos přes fyzické médium. Pro různé média bude vyžadovat různé protokoly. Příkladem jsou Ethernet, Token ring a další.
|
||||
\end{description}
|
||||
|
||||
Na obrázku \ref{fig:tcpip} vidíme, jak mezi sebou jednotlivé vrstvy komunikují. Aplikace na počítači $A$ zapíše do transportní vrstvy, kterou počítač $D$ ze stejné vrsvy přečte. Vrstva zná pouze vrstvu pod sebou. Plnou čarou vidíme datový tok zprávy, jak putuje přes jednotlivé vrstvy. Šrafovaná čára reprezentuje abstrahovaný datový tok tak, jak ho vidí vrstva. Počítače B a C jsou propojovací body. Všimněme si, že se nepoužívají transportní nebo aplikační vrstvy, pouze si rozbalí IP paket a zjistí, kam mají pakety posílat dál. Vrstva síťového rozhraní pracuje s různými médii, jak také vidíme na obrázku.
|
||||
|
||||
% Spolehlivost zaručuje tak, že příjemce pro každý přijatý paket odešle potvrzující zprávu, že paket přijal. To protokol implementuje na koncových bodech frontou paketů, které bod potřebuje odeslat. Zároveň si udržuje okno těch, které jsou odeslané, ale ještě nepotvrzené. Pokud není potvrzeno až příliš mnoho paketů, tak rozsah okna zmenší.
|
||||
|
||||
\begin{figure}
|
||||
\begin{center}
|
||||
@@ -359,10 +335,28 @@ Na obrázku \ref{fig:tcpip} vidíme, jak mezi sebou jednotlivé vrstvy komunikuj
|
||||
\label{fig:tcpip}
|
||||
\end{figure}
|
||||
|
||||
Popíšeme vrstvy, ze kterých se rodina TCP/IP skládá. Konkrétně jsou čtyři: aplikační, transportní, síťová a síťové rozhraní. Každá vrstva obsahuje množinu protokolů a pro různé situace můžeme protokoly ve vrstvách kombinovat. Na obrázku \ref{fig:tcpip} vidíme, jak mezi sebou jednotlivé vrstvy komunikují. Aplikace na počítači $A$ zapíše do transportní vrstvy, kterou počítač $D$ ze stejné vrsvy přečte. Vrstva zná pouze vrstvu pod sebou. Plnou čarou vidíme datový tok zprávy, jak putuje přes jednotlivé vrstvy. Šrafovaná čára reprezentuje protokol. Počítače B a C jsou propojovací body. Všimněme si, že se nepoužívají transportní nebo aplikační vrstvy, pouze si rozbalí IP paket a zjistí, kam mají pakety posílat dál. Vrstva síťového rozhraní pracuje s různými médii, jak také vidíme na obrázku.
|
||||
|
||||
\begin{description}
|
||||
\item[{Aplikační}] \hfill \\
|
||||
Nejvyšší je \uv{aplikační} vrstva, ve které jsou protokoly přímo pro aplikace. Příkladem protokolů jsou FTP pro přenos souborů, SMTP pro emailovou komunikaci, HTTP pro přenos hypertextových dokumentů nebo gRPC pro implementaci RPC. Tato vrstva je rozbalena až na koncovém bodu, protože neobsahuje žádné podstatné informace pro směrování. To je vidět i na obrázku \ref{fig:tcpip}.
|
||||
|
||||
\item[{Transportní}] \hfill \\
|
||||
Druhá vrstva je \uv{transportní}. Tato vrstva, stejně jako aplikační, je rozbalena až na koncových bodech. Stará se o to, jaké pakety přišli, v jakém pořadí a jestli nejsou poškozené. Příkladem protokolů jsou TCP, UDP nebo QUIC.
|
||||
|
||||
\item[{Síťová}] \hfill \\
|
||||
Pro adresaci slouží síťová vrstva. Ta směruje a předává jednotlivé datagramy. Příkladem protokolů jsou IP, ARP, RARP nebo IPSEC. Je nutné, aby stejně jako vrstva síťového rozhraní, byla implementována ve všech vrcholech na cestě mezi dvěma počítači, které chtějí komunikovat přes internet.
|
||||
|
||||
\item[{Síťové rozhraní}] \hfill \\
|
||||
Nejnižší vrstva, která se stará o přenos přes fyzické médium. Pro různé fyzické média existují různé protokoly. Příkladem jsou Ethernet, Token ring a další.
|
||||
\end{description}
|
||||
|
||||
|
||||
|
||||
|
||||
\subsection{Protokoly v aplikační vrstvě}
|
||||
|
||||
Nejvyšší v rodině protokolů TCP/IP je aplikační vrstva s protokoly jako HTTP, gRPC nebo SMTP. Aplikačním protokolům, které nejsou specifické pro konkrétní aplikaci, se říká middleware. Mezi takové řadíme právě HTTP a gRPC, které jsou pro obecné posílání zpráv a usnadňují aplikacím komunikaci.
|
||||
Nejvyšší v rodině protokolů TCP/IP je aplikační vrstva s protokoly jako HTTP, gRPC nebo SMTP. Aplikačním protokolům, které nejsou specifické pro konkrétní aplikaci, se říká middleware. Mezi takové řadíme právě HTTP a gRPC, které jsou pro obecné posílání zpráv a poskytují jednoduché rozhraní pro aplikace.
|
||||
|
||||
\subsubsection{HTTP}
|
||||
|
||||
@@ -441,25 +435,7 @@ Je vhodný jako základ pro vlastní transportní protokol. Například protokol
|
||||
|
||||
\subsubsection{QUIC}
|
||||
|
||||
QUIC je spolehlivý protokol transportní vrstvy od společnosti Google, který poskytuje multiplexní šifrovanou komunikaci založenou na TLS 1.3. Multiplexní komunikace znamená, že v jednom navázaném spojení můžeme vytvořit více proudů bytů, ať už jednosměrných nebo obousměrných. To značně redukuje problém ahead-of-line blokování. TCP má vždy právě jeden obousměrný proud. Tento protokol je pro nás důležitý, protože popisuje implementaci spolehlivosti, handshake a dalších vlastností nad protokolem UDP. V pozdější kapitole představíme náš protokol, který je protokolem QUIC inspirovaný a dále ho upravuje. Mezi naše ú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é.
|
||||
|
||||
|
||||
% \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.
|
||||
|
||||
% \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.
|
||||
|
||||
% \item[{Šifrování}] \hfill \\
|
||||
% QUIC už podporuje šifrování přes TLS 1.3 přímo v transportní vrstvě. To znamená dvě výhody: protokol autentizuje klienta, který nám posílá zprávy a tajný klíč lze domluvit už při navazování spojení. TCP naváže spojení pomocí handshake a následně pokračuje další handshake pro TLS. QUIC je v tomto ohledu schopný navázat spojení rychleji.
|
||||
|
||||
% \item[{Unikátní identifikátory koncových bodů}] \hfill \\
|
||||
% Protokol UDP směřuje datagramy do portů a identifikovat klienty umožňuje pomocí zdrojové IP adresy. Protokol QUIC přidává další vrstvu směrování pomocí \uv{unikátních identifikátorů koncových bodů}. Před začátkem komunikace se oba koncové body domluví na svých identifikátorech a odesílatel do hlavičky paketu zapíše identifikátor cílového spojení. Toto číslo je náhodně vygenerované a s délkou až 62 bitů. Díky šifrování nemůže potenciální útočník toto číslo podvrhnout a vydávat se za někoho jiného, protože kvůli neznalosti klíče by nebyl schopný správně zašifrovat zprávu.
|
||||
% Výhoda je, že klient může změnit IP adresu, např. z důvodu přepnutí z Wi-Fi na mobilní data, není třeba spojení znova navazovat. V případě TCP se často stává, že spojení musí vypršet, a pak znova navázat.
|
||||
|
||||
|
||||
% \end{description}
|
||||
QUIC\cite{quic} je spolehlivý protokol transportní vrstvy od společnosti Google, který poskytuje multiplexní šifrovanou komunikaci založenou na TLS 1.3. Multiplexní komunikace znamená, že v jednom navázaném spojení můžeme vytvořit více proudů bytů, ať už jednosměrných nebo obousměrných. To značně redukuje problém ahead-of-line blokování. TCP má vždy právě jeden obousměrný proud. Tento protokol je pro nás důležitý, protože popisuje implementaci spolehlivosti, handshake a dalších vlastností nad protokolem UDP. V pozdější kapitole představíme náš protokol, který je protokolem QUIC inspirovaný a dále ho upravuje. Mezi naše ú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é.
|
||||
|
||||
Koncové body komunikují posíláním paketů. Pakety obsahují rámce, které dělíme na ovládací a proudové. Ovládací slouží pro ovládání koncových bodů a vlastností 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ášť.
|
||||
|
||||
@@ -485,11 +461,6 @@ Nejprve popíšeme domluvu na unikátních ID. Iniciátor si vygeneruje svoje ID
|
||||
|
||||
Všimněme si teď různých typů paketů, jako: Initial, Handshake, 0-RTT a 1-RTT. Liší se především v síle šifrovaní. Pakety typu Initial a 0-RTT se používají, když ještě není domluvený tajný klíč a jsou snadněji dešifrovatelné. Handshake a 1-RTT používají plné šifrování. Význam Initial je zřejmý a 0-RTT se používá pro rychlé sdělení informací druhé straně ještě před navázáním spojení. Není vhodné ale do takového paketu ukládat tajné informace, které nechceme, aby četla třetí strana. Zároveň QUIC umožňuje poslat více paketů v jednom datagramu. Proto v diagramu vidíme, že iniciátor posílá paket Initial i 0-RTT najednou.
|
||||
|
||||
% První paket je typu \bold{Initial} a obsahuje rámec \bold{CRYPTO} s parametrem \uv{Client Hello} neboli CH.
|
||||
|
||||
% 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}
|
||||
\includegraphics[width=0.5\textwidth]{graphics/quic_handshake.pdf}
|
||||
@@ -498,7 +469,6 @@ Všimněme si teď různých typů paketů, jako: Initial, Handshake, 0-RTT a 1-
|
||||
\label{fig:quic_handshake}
|
||||
\end{figure}
|
||||
|
||||
% 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í.
|
||||
|
||||
|
||||
|
||||
@@ -788,7 +758,7 @@ Abychom oddělili to, jak replikátor funguje, vytvořili jsme pro něj na stran
|
||||
|
||||
\subsubsection{Interpolace}
|
||||
|
||||
Když jsme začali systém měřit, zjistili jsme, že vysoká frekvence replikace až příliš zatěžuje síť. Graf s průměry pro počet hráčů vidíme na grafu. Snížili jsme proto frekvenci na 20Hz. To snížilo zátěž na třetinu. Problém ale najednou byl neplynulost hry. Klient sice vykresloval s frekvencí 60Hz, ale méně časté aktualizace způsobili neplynulý pohyb. Řešení je na klientovi interpolovat spojité proměnné, jako pozice nebo rotace. Do klienta replikátoru jsme přidali komponentu \uv{interpolátor}. Ta si ukládá historii konkrétních hodnot a jejich časovou známkou do bufferu. Hodnota, kterou nastaví, je pak interpolovaná z bufferu fixní čas zpět.
|
||||
Když jsme začali systém měřit, zjistili jsme, že vysoká frekvence replikace až příliš zatěžuje síť. Graf s průměry pro počet hráčů vidíme na grafu. Snížili jsme proto frekvenci na 20Hz. To snížilo zátěž na třetinu. Problém ale najednou byl neplynulost hry. Klient sice vykresloval s frekvencí 60Hz, ale méně časté aktualizace způsobili neplynulý pohyb. Řešení je na klientovi interpolovat spojité proměnné, jako pozice nebo rotace. Do klienta replikátoru jsme přidali komponentu \uv{interpolátor}. Ta si ukládá historii konkrétních hodnot a jejich časovou známkou do bufferu. Hodnota, kterou nastaví, je pak interpolovaná z bufferu fixní čas zpět\cite{interpolation}.
|
||||
|
||||
\subsubsection{Rollback}
|
||||
|
||||
@@ -1280,7 +1250,7 @@ Vytvořili jsme si vlastní herní engine, který umožňuje vytvářet hry pro
|
||||
|
||||
Na konci jsme definovali, jaké metriky chceme měřit a jaké chceme optimalizovat. Představili jsme nástroje a možnosti měření, které jsme využili. Naše metriky se netýkali jen komunikace v síti, ale i výkonu jednolivých programů. Například jsme naměřili, že v případě stovek hráčů začala být problém serializace a obecně sestavení smysluplných zpráv, nikoliv samotné odesílání. Implementovali a popsali jsme naše řešení. Zároveň jsme dokázali, že implementované optimalizace jsou vhodné nejen pro model klient-server ale i peer-to-peer.
|
||||
|
||||
Do budoucna by bylo dobré dokončit další vlastnosti QUICr protokolu, jako například sekvenční číslo zprávy. Bylo by nutné se zamyslet, do jaké hloubky by pořadí zpráv měl řešit QUICr. Aplikace sama nejlépe ví, jestli musí čekat na předchozí zprávu nebo ne, jako v našem případě snapshoty ze serveru. Možnost je definovat předchůdce pro kompletní odstranění ahead-of-line blokování. Protokol také neimplementuje dynamické změny datového toku. Ten je nutné snížit, když je síť zatížená.
|
||||
Do budoucna by bylo dobré dokončit další vlastnosti QUICr protokolu, jako například sekvenční číslo zprávy. Bylo by nutné se zamyslet, do jaké hloubky by pořadí zpráv měl řešit QUICr. Aplikace sama nejlépe ví, jestli musí čekat na předchozí zprávu nebo ne, jako v našem případě snapshoty ze serveru. Možnost je definovat předchůdce pro kompletní odstranění ahead-of-line blokování. Protokol také neimplementuje dynamické změny datového toku. Ten je nutné snížit, když je síť zatížená.\cite{quic}
|
||||
\end{kiconclusions}
|
||||
|
||||
\begin{kiconclusions}[english]
|
||||
|
||||
Reference in New Issue
Block a user