Pár slov z naší překladatelské kanceláře: většinou se každý snaží překládat nejnovější materiály a publikace a my nejsme výjimkou. Ale terminály nejsou něco, co se aktualizuje jednou týdně. Proto jsme pro vás přeložili článek Antoina Beauprého, který vyšel na jaře 2018: navzdory svému značnému „stáří“ na moderní standardy podle našeho názoru materiál vůbec neztratil na aktuálnosti. Navíc se původně jednalo o sérii dvou článků, ale rozhodli jsme se je spojit do jednoho velkého příspěvku.
Terminály mají v historii počítačů zvláštní místo, ale v posledních desetiletích byly nuceny přežívat vedle příkazového řádku, protože grafická rozhraní se stávají všudypřítomnými. nahradili své vlastní , které byly zase modifikací systémů založených na děrných štítcích a páčkových spínačích. Moderní distribuce přicházejí s řadou emulátorů terminálů všech tvarů a barev. A zatímco mnozí jsou spokojeni se standardním terminálem poskytovaným jejich pracovním prostředím, někteří hrdě používají vyloženě exotický software ke spuštění svého oblíbeného shellu nebo textového editoru. Ale, jak uvidíme z tohoto článku, ne všechny terminály byly vytvořeny na stejném obrázku: velmi se liší ve funkčnosti, velikosti a výkonu.
Některé terminály mají přímo překvapivé bezpečnostní díry a většina z nich má úplně jinou sadu funkcí, od podpory rozhraní s kartami až po skriptování. I když my , tento článek je aktualizací předchozího materiálu, který čtenářům pomůže určit, který terminál použít v roce 2018. První polovina článku porovnává funkce a druhá polovina hodnotí výkon.
Zde jsou terminály, které jsem zkontroloval:
Nemusí se jednat o nejnovější verze, protože jsem byl v době psaní tohoto článku omezen na stabilní sestavení, která jsem mohl zavést na Debianu 9 nebo Fedoře 27. Jedinou výjimkou je Alacritty. Je to potomek GPU-akcelerovaných terminálů a je napsán v neobvyklém a novém jazyce pro tento úkol – Rust. Ze své recenze jsem vyloučil webové terminály (včetně těch na ), protože předběžné testy ukázaly jejich extrémně špatný výkon.
Podpora Unicode
Své testy jsem začal s podporou Unicode. Prvním testem terminálů bylo zobrazení řetězce Unicode z : „é, Δ, И, ק, م, ๗, あ, 叶, 葉 a 말.“ Tento jednoduchý test ukazuje, zda může terminál správně fungovat po celém světě. Terminál xterm nezobrazuje arabské znaky ve výchozí konfiguraci:
Standardně xterm používá klasický "pevný" font, který dle , má „podstatné pokrytí Unicode od roku 1997“. V tomto písmu se děje něco, co způsobuje, že se znak jeví jako prázdný rámeček, a znak se konečně začne správně zobrazovat pouze tehdy, když se písmo textu zvětší na 20+ bodů. Tato „oprava“ však přeruší zobrazení dalších znaků Unicode:
Tyto snímky obrazovky byly pořízeny ve Fedoře 27, protože poskytovala lepší výsledky než Debian 9, kde některé starší verze terminálů (konkrétně mlterm) neuměly správně pracovat s fonty. Naštěstí to bylo opraveno v pozdějších verzích.
Nyní si všimněte, jak je řádek zobrazen v xterm. Ukazuje se, že symbol Mem a následující semitský viz skripty stylu RTL (), takže technicky by se měly zobrazovat zprava doleva. Webové prohlížeče, jako je Firefox 57, zpracují výše uvedený řádek správně. Jednodušší verzí RTL textu je slovo ""v hebrejštině (). říká následující:
„Mnoho počítačových programů nedokáže správně zobrazit obousměrný text. Například hebrejské jméno „Sarah“ se skládá ze znaků sin (ש) (které se objevují vpravo), potom resh (ר) a nakonec on (ה) (které by se měly objevit vlevo).“
Mnoho terminálů v tomto testu neprojde: Alacritty, terminály Gnome a XFCE odvozené od VTE, urxvt, st a xterm zobrazují „Sara“ v opačném pořadí, jako bychom jméno napsali jako „Aras“.
Dalším problémem obousměrných textů je, že je třeba je nějak zarovnat, zvláště pokud jde o míchání textů RTL a LTR. Skripty RTL by se měly spouštět z pravé strany okna terminálu, ale co by se mělo stát u terminálů, které mají výchozí angličtinu LTR? Většina z nich nemá žádné speciální mechanismy a zarovnává veškerý text doleva (včetně v Konsole). Výjimkou jsou pterm a mlterm, které dodržují standardy a zarovnávají takové čáry doprava.
Ochrana vložení
Další kritickou funkcí, kterou jsem identifikoval, je ochrana proti vložení. Ačkoli je všeobecně známo, že kouzla jako:
$ curl http://example.com/ | shjsou příkazy push spouštění kódu, málokdo ví, že skryté příkazy se mohou při kopírování a vkládání z webového prohlížeče vplížit do konzole, a to i po pečlivé kontrole. skvěle ukazuje, jak neškodně vypadá příkaz:
git clone git: //git.kernel.org/pub/scm/utils/kup/kup.gitse při vložení z Hornova webu do terminálu změní na takovou nepříjemnost:
git clone /dev/null;
clear;
echo -n "Hello ";
whoami|tr -d 'n';
echo -e '!nThat was a bad idea. Don'"'"'t copy code from websites you don'"'"'t trust!
Here'"'"'s the first line of your /etc/passwd: ';
head -n1 /etc/passwd
git clone git://git.kernel.org/pub/scm/utils/kup/kup.gitJak to funguje? V bloku je obsažen škodlivý kód , který se pomocí CSS přesune mimo zobrazení uživatele.
je jasně navržena k neutralizaci takových útoků. V tomto režimu terminály uzavřou vložený text do páru speciálních escape sekvencí, aby sdělily shellu o původu textu. To říká shellu, že může ignorovat speciální znaky, které může obsahovat vložený text. Všechny terminály zpět na úctyhodný xterm tuto funkci podporují, ale vkládání v režimu hranatých závorek vyžaduje podporu ze shellu nebo aplikace běžící na terminálu. Například pomocí softwaru (stejný Bash), potřebuje soubor ~/.inputrc:
set enable-bracketed-paste onBohužel i Hornův testovací web ukazuje, jak tuto ochranu obejít přes samotné formátování textu a předčasně skončit s aplikací Bracketed módu. Funguje to proto, že některé terminály správně nefiltrují sekvence escape před přidáním svých vlastních. Například v mém se mi nikdy nepodařilo úspěšně dokončit testy Konsole ani se správnou konfigurací .inputrc soubor. To znamená, že můžete snadno poškodit konfiguraci systému kvůli nepodporované aplikaci nebo nesprávně nakonfigurovanému shellu. To je zvláště nebezpečné při přihlašování na vzdálené servery, kde je pečlivá konfigurační práce méně běžná, zvláště pokud máte mnoho takových vzdálených počítačů.
Dobrým řešením tohoto problému je plugin pro potvrzení vložení pro terminál urxvt, který jednoduše požádá o povolení vložit jakýkoli text, který obsahuje nové řádky. Nenašel jsem bezpečnější možnost pro textový útok popsaný Hornem.
Karty a profily
Populární funkcí je nyní podpora pro rozhraní s kartami, které budeme definovat jako jedno terminálové okno obsahující několik dalších terminálů. Tato funkce se u různých terminálů liší, a přestože tradiční terminály xterm karty vůbec nepodporují, modernější inkarnace terminálů, jako je terminál Xfce, terminál GNOME a Konsole, tuto funkci mají. Urxvt také podporuje karty, ale pouze pokud používáte plugin. Ale pokud jde o samotnou podporu karet, Terminator je nesporným lídrem: nejenže podporuje karty, ale může také uspořádat terminály v libovolném pořadí (viz obrázek níže).
Další funkcí Terminatoru je možnost „seskupit“ tyto karty dohromady a odesílat stejné úhozy na více terminálů současně, což poskytuje hrubý nástroj pro provádění hromadných operací na více serverech současně. Podobná funkce je implementována také v Konsole. Chcete-li použít tuto funkci v jiných terminálech, musíte použít software třetích stran, jako je např , nebo .
Karty fungují obzvláště dobře, když jsou spárovány s profily: například můžete mít jednu kartu pro e-mail, druhou pro chat a tak dále. To je dobře podporováno terminály Konsole a GNOME. Oba umožňují každé kartě automaticky spustit svůj vlastní profil. Terminátor také podporuje profily, ale nenašel jsem způsob, jak automaticky spustit určité programy, když otevřete konkrétní kartu. Jiné terminály pojem „profil“ vůbec nemají.
Volánky
Poslední věcí, kterou se budu v první části tohoto článku zabývat, je vzhled terminálů. Například GNOME, Xfce a urxvt podporují průhlednost, ale nedávno přestaly podporovat obrázky na pozadí, což některé uživatele přimělo přejít na terminál . Osobně jsem s ním spokojený a je jednoduchý Zdroje, který nastavuje základní sadu barev pozadí pro urxvt. Problémy však mohou způsobovat i nestandardní barevné motivy. Například, s aplikacemi и , protože již používají své vlastní barvy.
nepodporovaly barvy a nové byly často omezeny na 256barevnou paletu. Pro pokročilé uživatele, kteří upravují své terminály, mohou být výzvy shellu nebo stavové řádky složitým způsobem nepříjemným omezením. sleduje, které terminály mají podporu "True Color". Moje testy potvrzují, že terminály st, Alacritty a VTE dokonale podporují True Color. Ostatní terminály si v tomto ohledu příliš nevedou a v podstatě ani nezobrazují 256 barev. Níže můžete vidět rozdíl mezi podporou True Color v terminálech GNOME, st a xterm, které to dělají dobře se svou 256 barevnou paletou, a urxvt, který nejenže v testu neprojde, ale dokonce místo nich zobrazuje některé blikající znaky.
Některé terminály také analyzují text na vzory adres URL, aby bylo možné kliknout na odkazy. To platí pro všechny terminály odvozené od VTE, zatímco urxvt vyžaduje speciální plugin, který by transformoval adresy URL kliknutím nebo pomocí klávesové zkratky. Jiné terminály Zobrazované URL jsem testoval jinými způsoby.
A konečně novým trendem v terminálech je volitelnost rolovací vyrovnávací paměti. Například st nemá vyrovnávací paměť pro posuv; předpokládá se, že uživatel bude používat terminálový multiplexer jako tmux a .
Alacritty také postrádá backscroll buffery, ale jeho podporu díky „rozsáhlé zpětné vazbě“ na toto téma od uživatelů. Kromě těchto upstartů každý terminál, který jsem testoval a našel jsem, podporuje zpětné posouvání.
Mezisoučet
V druhé části materiálu (v originále to byly dva různé články - cca. pruh) porovnáme výkon, využití paměti a latenci. Už teď ale vidíme, že některé z dotyčných terminálů mají vážné nedostatky. Například uživatelé, kteří pravidelně pracují se skripty RTL, mohou chtít zvážit mlterm a pterm, protože zvládají podobné úkoly lépe než ostatní. Konsole si také vedla dobře. Uživatelé, kteří nepracují s RTL skripty, mohou zvolit něco jiného.
Pokud jde o ochranu před vkládáním škodlivého kódu, urxvt vyniká speciální implementací ochrany proti tomuto typu útoku, která se mi zdá rozhodně výhodná. Pro ty, kteří hledají nějaké zvonky a píšťalky, stojí za to se podívat na Konsole. Nakonec stojí za zmínku, že VTE je vynikající základna pro terminály, která zaručuje podporu barev, rozpoznávání URL a tak dále. Na první pohled může výchozí terminál dodávaný s vaším oblíbeným prostředím splňovat všechny požadavky, ale nechme tuto otázku otevřenou, dokud výkon nepochopíme.
Pokračujeme v rozhovoru
Obecně se výkon terminálů sám o sobě může zdát jako přitažený za vlasy problém, ale jak se ukazuje, některé z nich vykazují překvapivě vysokou latenci pro software tak zásadního typu. Dále se také podíváme na to, co se tradičně nazývá „rychlost“ (ve skutečnosti se jedná o rychlost rolování) a spotřebu paměti terminálu (s upozorněním, že to dnes není tak důležité jako před desítkami let).
Zpoždění
Po důkladném prostudování výkonu terminálu jsem došel k závěru, že nejdůležitějším parametrem je v tomto ohledu latence (ping). Ve svém článku Pavel Fatin se podíval na latenci různých textových editorů a naznačil, že terminály v tomto ohledu mohou být pomalejší než nejrychlejší textové editory. Byla to tato nápověda, která mě nakonec přivedla k tomu, že jsem provedl vlastní testy a napsal tento článek.
Ale co je latence a proč je tak důležitá? Fatin to ve svém článku definoval jako „prodlevu mezi stisknutím klávesy a příslušnou aktualizací obrazovky“ a citoval , kde se uvádí: „Zpoždění vizuální zpětné vazby na obrazovce počítače má důležitý dopad na chování a spokojenost písaře.“
Fatin vysvětluje, že tento ping má hlubší důsledky než pouhé uspokojení: „Psaní se zpomaluje, objevuje se více chyb a zvyšuje se napětí očí a svalů.“ Jinými slovy, velké zpoždění může vést k překlepům a také nižší kvalitě kódu, protože vede k dodatečné kognitivní zátěži mozku. Ale co je horší je, že ping "zvyšuje namáhání očí a svalů", což se zdá naznačovat napříště (Zřejmě má autor na mysli problémy se svaly očí, zad, paží a samozřejmě se zrakem - cca. pruh) kvůli opakovanému stresu.
Některé z těchto účinků jsou známy již dlouhou dobu a výsledky , publikovaný již v roce 1976 v časopise Ergonomics, uvedl, že zpoždění 100 milisekund "výrazně snižuje rychlost psaní." Nedávno byla představena uživatelská příručka GNOME za 10 milisekund, a pokud půjdete dále, pak ukazuje, že 1 milisekunda je ideální.
Fatin prováděl své testy na textových editorech; vytvořil přenosný nástroj tzv , který jsem použil k testování pingu v terminálových emulátorech. Mějte na paměti, že test byl proveden v simulačním režimu: ve skutečnosti musíme vzít v úvahu jak vstupní (klávesnice, USB řadič atd.), tak výstupní (vyrovnávací paměť grafické karty, monitor) latenci. Podle Fatina je to v typických konfiguracích asi 20 ms. Pokud máte herní vybavení, můžete tohoto čísla dosáhnout za pouhé 3 milisekundy. Vzhledem k tomu, že již máme takto rychlý hardware, aplikace nemusí přidávat vlastní latenci. Fatinovým cílem je dosáhnout latence aplikace na 1 milisekundu, nebo dokonce dosáhnout vytáčení bez jako v .
Zde jsou výsledky mých měření a také některé Fatinovy výsledky, abych ukázal, že můj experiment souhlasí s jeho testy:
První, co mě zarazilo, byla lepší doba odezvy starších programů jako xterm a mlterm. S nejhorší latencí registru (2,4 ms) si vedly lépe než nejrychlejší moderní terminál (10,6 ms pro st). Žádný moderní terminál neklesne pod práh 10 milisekund. Konkrétně Alacritty nesplňuje požadavek „nejrychlejší dostupný emulátor terminálu“, ačkoli jeho skóre se od první revize v roce 2017 zlepšilo. Ostatně autoři projektu a pracují na vylepšení displeje. Je třeba také poznamenat, že Vim využívající GTK3 je řádově pomalejší než jeho protějšek GTK2. Z toho můžeme usoudit, že GTK3 vytváří další latenci, a to se odráží ve všech ostatních terminálech, které jej používají (Terminátor, Xfce4 Terminal a GNOME Terminal).
Rozdíly však nemusí být okem patrné. Jak vysvětluje Fatin, "nemusíte si být vědomi zpoždění, aby to na vás mělo vliv." Fatin také varuje před směrodatnou odchylkou: „jakékoli poruchy latence (jitter) vytvářejí další stres kvůli své nepředvídatelnosti.
Výše uvedený graf je převzat z čistého Debianu 9 (roztáhnout). . Toto prostředí poskytuje nejlepší výsledky v testech latence. Jak se ukázalo, GNOME vytváří další ping o 20 ms pro všechna měření. Možným vysvětlením je přítomnost programů se synchronním zpracováním vstupních událostí. Fatin uvádí příklad pro takový případ , který přidává zpoždění tím, že zpracovává všechny vstupní události synchronně. Ve výchozím nastavení je GNOME také vybaveno správcem oken , což vytváří další vrstvu vyrovnávací paměti, která ovlivňuje ping a přidává nejméně 8 milisekund latence.
Rychlost rolování
Dalším testem je tradiční test „rychlosti“ nebo „šířky pásma“, který měří, jak rychle může terminál posouvat stránku při zobrazení velkého množství textu na obrazovce. Mechanika testu se liší; původním testem bylo jednoduše vygenerovat stejný textový řetězec pomocí příkazu seq. Mezi další testy patří test Thomase E. Dickeyho (správce xterm), který opakovaně . V další recenzi výkonu terminálu používá řetězec náhodných bajtů zakódovaný v base32, který je odeslán do terminálu pomocí cat. Luu považuje takový test za „tak zbytečný benchmark, jak si lze představit“ a místo toho navrhuje použít terminální odezvu jako primární metriku. Dickey také označuje svůj test za zavádějící. Oba autoři však uznávají, že problémem může být šířka pásma terminálového okna. Luu zjistil, že Emacs Eshell zamrzá při zobrazování velkých souborů a Dickey optimalizoval terminál, aby se zbavil vizuální pomalosti xtrermu. Tento test má tedy stále určité výhody, ale protože se proces vykreslování terminál od terminálu velmi liší, může být také použit jako testovací komponenta pro testování jiných parametrů.
Zde vidíme, že rxvt a st táhnou před konkurencí, následované mnohem novějším Alacritty, který je navržen se zaměřením na výkon. Další jsou Xfce (rodina VTE) a Konsole, které jsou téměř dvakrát rychlejší. Poslední je xterm, který je pětkrát pomalejší než rxvt. Během testu se xterm také hodně vlnil, takže procházející text bylo špatně vidět, i když šlo o stejný řádek. Konsole byla rychlá, ale občas to bylo složité: displej čas od času zamrzal, zobrazoval částečný text nebo jej nezobrazoval vůbec. Ostatní terminály zobrazovaly řetězce jasně, včetně st, Alacritty a rxvt.
Dickey vysvětluje, že rozdíly ve výkonu jsou způsobeny konstrukcí scroll bufferů v různých terminálech. Zejména obviňuje rxvt a další terminály z „nedodržování obecných pravidel“:
„Na rozdíl od xterm se rxvt nepokusil zobrazit všechny aktualizace. Pokud zaostává, odmítne některé aktualizace, aby je dohnal. To mělo větší dopad na zdánlivou rychlost rolování než na organizaci vnitřní paměti. Jednou nevýhodou bylo, že animace ASCII byla poněkud nepřesná."
K nápravě této vnímané xterm pomalosti Dickey navrhuje použít zdroj , což umožňuje xtermu zahodit některé aktualizace obrazovky, aby držel krok s tokem. Moje testy potvrzují, že fastScroll zlepšuje výkon a přináší xterm na stejnou úroveň jako rxvt. Toto je však poněkud drsná berlička, jak sám Dickey vysvětluje: "někdy se zdá, že xterm - jako konsole - se zastaví, protože čeká na novou sadu aktualizací obrazovky poté, co byly některé odstraněny." V tomto duchu se zdá, že ostatní terminály našly nejlepší kompromis mezi rychlostí a integritou displeje.
Spotřeba zdrojů
Bez ohledu na to, zda má smysl považovat rychlost rolování za metriku výkonu, tento test nám umožňuje simulovat zatížení terminálů, což nám zase umožňuje měřit další parametry, jako je využití paměti nebo disku. Metriky byly získány provedením specifikovaného testu následující pod monitorováním procesu Pythonu. Sbíral data z měřidel pro ru_maxrss, částka ru_oublock и ru_inblock a jednoduchý časovač.
V tomto testu je ST na prvním místě s nejnižší průměrnou spotřebou paměti 8 MB, což není překvapivé vzhledem k tomu, že hlavní myšlenkou designu je jednoduchost. mlterm, xterm a rxvt spotřebují o něco více - asi 12 MB. Dalším pozoruhodným výsledkem je Alacritty, který ke spuštění vyžaduje 30 MB. Pak jsou tu terminály rodiny VTE s čísly od 40 do 60 MB, což je poměrně hodně. Tuto spotřebu lze vysvětlit tím, že tyto terminály používají knihovny vyšší úrovně, například GTK. Konsole je na posledním místě s ohromnou spotřebou paměti 65 MB během testů, i když to lze ospravedlnit velmi širokou škálou funkcí.
Ve srovnání s předchozími výsledky získanými před deseti lety začaly všechny programy spotřebovávat znatelně více paměti. Xterm dříve vyžadoval 4 MB, ale nyní vyžaduje 15 MB jen při spuštění. K podobnému nárůstu spotřeby dochází u rxvt, který nyní vyžaduje 16 MB po vybalení z krabice. Xfce Terminal zabírá 34 MB, což je třikrát více než dříve, ale GNOME Terminal vyžaduje pouze 20 MB. Všechny předchozí testy byly samozřejmě prováděny na 32bitové architektuře. Na LCA 2012 Rusty Russell , že existuje mnoho jemnějších důvodů, které by mohly vysvětlit zvýšení spotřeby paměti. Nicméně nyní žijeme v době, kdy máme gigabajty paměti, takže si nějak poradíme.
Nemohu se však ubránit dojmu, že přidělovat více paměti něčemu tak zásadnímu, jako je terminál, je plýtvání prostředky. Tyto programy by měly být nejmenší z nejmenších, měly by být schopny běžet na jakékoli „krabice“, dokonce i na krabici od bot, pokud někdy dojdeme do bodu, kdy je bude třeba vybavit systémy Linux (a víte, že to tak bude ). Ale s těmito čísly se využití paměti stane v budoucnu problémem v jakémkoli prostředí s více terminály, kromě několika nejlehčích a nejvíce omezených schopností. Aby se to kompenzovalo, terminály GNOME, Konsole, urxvt, Terminator a Xfce Terminal mají režim démona, který vám umožňuje ovládat více terminálů prostřednictvím jednoho procesu a omezovat jejich spotřebu paměti.
Během svých testů jsem došel k dalšímu nečekanému výsledku ohledně čtení a zápisu na disk: Čekal jsem, že zde neuvidím vůbec nic, ale ukázalo se, že některé terminály zapisují na disk nejobjemnější data. Knihovna VTE tedy ve skutečnosti uchovává na disku posuvnou vyrovnávací paměť (tato funkce a to se stále děje). Ale na rozdíl od starších implementací jsou nyní alespoň tato data šifrována pomocí AES256 GCM (). Nabízí se ale rozumná otázka: co je na knihovně VTE tak zvláštního, že vyžaduje tak nestandardní přístup k implementaci...
Závěr
V první části článku jsme zjistili, že terminály založené na VTE mají dobrou sadu funkcí, ale nyní vidíme, že to přináší určité náklady na výkon. Paměť nyní není problém, protože všechny terminály VTE lze ovládat pomocí procesu Daemon, což omezuje jejich chuť k jídlu. Starší systémy, které mají fyzická omezení týkající se množství paměti RAM a vyrovnávacích pamětí jádra, však mohou stále potřebovat starší verze terminálů, protože spotřebovávají podstatně méně prostředků. Ačkoli si terminály VTE vedly dobře v testech propustnosti (rolování), jejich latence zobrazení je nad prahovou hodnotou nastavenou v uživatelské příručce GNOME. Vývojáři VTE by s tím pravděpodobně měli počítat. Pokud vezmeme v úvahu, že i pro začínající uživatele Linuxu je setkání s terminálem nevyhnutelné, mohou jej učinit uživatelsky přívětivějším. Pro zkušené geeky může přechod z výchozího terminálu dokonce znamenat menší únavu očí a možnost vyhnout se budoucím pracovním úrazům a nemocem kvůli dlouhým pracovním sezením. Bohužel pouze starý xterm a mlterm nás přivádějí k magické hranici pingu 10 milisekund, což je pro mnohé nepřijatelné.
Benchmarková měření také ukázala, že kvůli vývoji linuxových grafických prostředí museli vývojáři přistoupit na řadu kompromisů. Někteří uživatelé se možná budou chtít podívat na běžné správce oken, protože poskytují výrazné snížení počtu pingů. Bohužel nebylo možné měřit latenci pro Wayland: program Typometer, který jsem použil, byl vytvořen pro to, čemu má Wayland zabránit: špehování jiných oken. Doufám, že Wayland compositing funguje lépe než X.org, a také doufám, že v budoucnu někdo najde způsob, jak měřit latenci v tomto prostředí.
Zdroj: www.habr.com