Hypertextový přenosový protokol prošel od svého vzniku dramatickým vývojem a protokol HTTP/2 představuje jeden z nejvýznamnějších skoků v přenosu dat po celosvětové síti. Pokud jste si v posledních letech všimli, že se webové stránky načítají rychleji, je pravděpodobné, že v pozadí funguje protokol HTTP/2.
Tento průvodce popisuje vše, co potřebujete vědět o protokolu HTTP/2 – odjeho základních mechanik a výkonnostních výhod až po praktické kroky nasazení. Ať už jste vývojář, který chce optimalizovat svůj webový server, nebo vás prostě jen zajímá, co dělá moderní webové stránky funkčními, najdete zde užitečné informace.
Rychlá odpověď: Co je HTTP/2 a proč je to důležité
HTTP/2 je zásadní revizí hypertextového přenosového protokolu verze 1.1, kterou standardizovala Internet Engineering Task Force v dokumentu RFC 7540 (květen 2015). Zaměřuje se na snížení latence, zlepšení využití síťových zdrojů a výrazné zrychlení načítání webových stránek – to všepři zachování plné zpětné kompatibility se stávající sémantikou HTTP.
V roce 2026 bude HTTP/2 téměř všudypřítomný. Podle údajů společnosti W3Techs používá HTTP/2 aktivně více než třetina nejlepších webových stránek a většina hlavních sítí CDN (Cloudflare, AWS CloudFront, Fastly) jej ve výchozím nastavení povoluje pro provoz HTTPS. Pokud váš web běží na protokolu HTTPS s moderním webovým serverem, pravděpodobně již využíváte výhod protokolu HTTP/2 bez jakékoli další konfigurace.
Protokol zavádí několik hlavních funkcí, které řeší výkonnostní nedostatky protokolu HTTP 1.1:
- Multiplexování: Více datových proudů současně přes jedno spojení TCP.
- Komprese záhlaví (HPACK): Zavádí kompresi polí záhlaví, která výrazně snižuje množství nadbytečných metadat záhlaví HTTP.
- Binární rámovací vrstva: Zcela obecná rámcová vrstva, která nahrazuje textové příkazy efektivním rámováním binárních zpráv.
- Push serveru: Proaktivní doručování zdrojů předtím, než si je prohlížeč výslovně vyžádá.
- Stanovení priorit proudu: Klientské nápovědy, které serverům říkají, které zdroje jsou nejdůležitější.
Co to znamená v praxi:
- Rychlejší načítání stránek, zejména na webech náročných na zdroje.
- Menší počet připojení TCP potřebných pro jeden původ
- Lepší výkon v mobilních sítích s vysokou latencí
- Zlepšené využití sítě ve všech oblastech
Od HTTP/0.9 k HTTP/2: krátká historie
Protokol HTTP ušel od doby, kdy Tim Berners-Lee v roce 1991 představil HTTP/0.9 jako jednoduchý mechanismus pro načítání dokumentů HTML, dlouhou cestu. V roce 1996 následoval HTTP/1. 0, který přidal hlavičky a stavové kódy, a HTTP/1.1 byl standardizován v RFC 2068 (1997) a později upřesněn v RFC 2616 (1999). Téměř dvě desetiletí sloužil protokol HTTP/1.1 jako základ komunikace mezi klientem a serverem na webu.
Web se však výrazně změnil. Moderní webové stránky se z jednoduchých dokumentů staly komplexními aplikacemi, které načítají desítky svazků JavaScriptu, souborů CSS, obrázků a volání API. Architektura protokolu HTTP/1.1 vytvářela úzká místa i při širokopásmovém připojení a výkonném hardwaru:
- Blokování hlavy linky: Každé spojení TCP mohlo v daném okamžiku zpracovat pouze jeden požadavek, což způsobovalo zbytečný provoz v síti, protože zdroje se řadily do fronty.
- Režijní náklady na připojení: Webové prohlížeče pro stolní počítače a mobilní webové prohlížeče obvykle otevírají 6-8 paralelních spojení TCP na původ, aby toto omezení obešly.
- Nadbytečné hlavičky: Každý požadavek HTTP opakovaně odesílá stejné slovní hlavičky (cookies, user-agent, accept headers).
Společnost Google tyto problémy rozpoznala a v roce 2009 zahájila projekt SPDY. Projekt SPDY byl poprvé implementován v prohlížeči Chrome kolem roku 2010 a přinesl několik inovací:
- Binární rámování namísto textových protokolů
- Multiplexování více požadavků přes jedno připojení
- Komprese záhlaví pro snížení režie
- Stanovení priorit pro kritické zdroje
Pracovní skupina IETF pro HTTP si všimla potenciálu SPDY a v roce 2012 jej přijala jako výchozí bod pro HTTP/2. Po rozsáhlé práci pracovní skupiny ietf http byla v květnu 2015 zveřejněna RFC 7540 (HTTP/2) a RFC 7541 (HPACK).
Přijetí prohlížeče proběhlo rychle:
- Chrome od verze Chrome 51 (květen 2016) vyřadil SPDY ve prospěch HTTP/2.
- Firefox přidal podporu HTTP/2 ve verzi 36 (únor 2015)
- Safari následuje ve verzi 9 (září 2015)
- Microsoft Edge je dodáván s podporou HTTP/2 od svého prvního vydání
- Dokonce i Internet Explorer 11 získal podporu HTTP/2 v systému Windows 8.1 a novějším.
Cíle návrhu a hlavní rozdíly oproti HTTP/1.1
Protokol HTTP/2 zachovává plnou kompatibilitu se sémantikou protokolu HTTP/1.1. Metody jako GET a POST fungují stejně. Stavové kódy zůstávají beze změny. URI a pole hlaviček HTTP se řídí stejnými pravidly. Mění se pouze způsob, jakým se tato data pohybují po vedení – mechanika transportní vrstvy, která určuje skutečnou rychlost načítání.
Cíle návrhu protokolu byly jasné:
| Cíl | Jak toho HTTP/2 dosahuje |
|---|---|
| Snížení latence | Multiplexování eliminuje blokování na úrovni HTTP v čele linky |
| Lepší využití připojení | Všechny požadavky na původce vyřizuje jediné spojení TCP. |
| Odříznutí záhlaví nad hlavou | Komprese HPACK zmenšuje dříve přenesené hodnoty záhlaví |
| Zlepšení výkonu mobilních zařízení | Menší počet spojení a menší hlavičky jsou výhodné pro sítě s vysokou latencí |
Krása tohoto návrhu spočívá ve zpětné kompatibilitě na úrovni aplikace. Váš stávající kód webové aplikace – trasy, obslužné programy, logika odezvy – se nemusí měnit. Pouze klientský a serverový stack musí podporovat HTTP/2, aby se projevily výhody.
To je v ostrém kontrastu s řešením HTTP/1.1, které museli vývojáři implementovat ručně:
- Sdílení domény: Rozložení aktiv do více domén pro otevření více připojení
- Spojování aktiv: Spojování souborů CSS a JavaScript pro snížení počtu požadavků
- Obrázkové sprity: Spojení více obrázků do jednoho souboru
- Vložení: Vkládání CSS a JavaScriptu přímo do HTML
Základní mechanismy protokolu HTTP/2, které tyto hacky nahrazují:
- Binární rámovací vrstva: Zprávy rozdělené do rámců efektivně přenášejí data jako binární protokolové jednotky.
- Multiplexované proudy: Více souběžných výměn probíhá přes stejné připojení.
- Komprese záhlaví HPACK: Dynamické tabulky sledují záhlaví, čímž se eliminuje redundance.
- Push serveru: Servery proaktivně odesílají zdroje, které bude klient potřebovat.
- Stanovení priorit proudu: Klienti signalizují, které zdroje jsou nejdůležitější, pomocí vah závislosti na toku.
Binární rámování, proudy, zprávy a multiplexování
Jádrem protokolu HTTP/2 je binární rámcová vrstva, která představuje zásadní odklon od textového formátu protokolu HTTP/1.1. Každá zpráva HTTP je rozdělena do binárních rámců s konzistentním uspořádáním rámce: 9bajtová hlavička rámce obsahuje délku, typ, příznaky a identifikátory datového toku, za nimiž následují volitelná data užitečného zatížení.
Pochopení hierarchie vyžaduje pochopení tří pojmů:
Streamy jsou nezávislé obousměrné kanály v rámci jednoho připojení. Každý stream má jedinečný 31bitový identifikátor. Klienti iniciují streamy s lichými identifikátory (1, 3, 5…), zatímco servery používají sudé identifikátory (2, 4, 6…) pro streamy iniciované serverem, například push. Neočekávaný identifikátor proudu vyvolá chybu. Nastavení maximálního počtu souběžných streamů řídí, kolik jich může být současně aktivních.
Zprávy představují úplné požadavky nebo odpovědi HTTP. Kompletní blok záhlaví se skládá z jednoho nebo více rámců a odpovědi mohou obsahovat více datových rámců pro tělo. Když se příjemce setká s fragmenty bloku záhlaví, znovu je složí, aby rekonstruoval celou zprávu.
Rámečky jsou nejmenší jednotky na drátu. Mezi běžné typy rámců a chyb patří:
- Rámce DAT: Přenášejí obsah těla žádosti/odpovědi
- Rámeček HEADERS: Obsahuje pole záhlaví HTTP, případně rozdělená do více rámců, tzv. fragmentů bloků záhlaví.
- NASTAVENÍ: Řídicí zprávy připojení pro konfiguraci
- WINDOW_UPDATE: Úpravy okna řízení toku
- PUSH_PROMISE: Oznamuje server push
- RST_STREAM: Ukončí datový tok s chybovým kódem
- GOAWAY: Zahájí postupné vypínání připojení
Kouzlo se děje prostřednictvím multiplexování. Protože rámce z více současně otevřených streamů lze prokládat přes jediné spojení TCP – přičemž oba koncové body prokládají rámce podle potřeby -, není třeba čekat. Přijímač znovu sestavuje rámce podle identifikátoru toku.
Zvažte načtení typické webové stránky, která potřebuje:
- index.html (10 KB)
- styles.css (25 KB)
- app.js (100 KB)
- logo.png (15 KB)
- hero-image.jpg (200 KB)
Při použití protokolu HTTP/1.1 prohlížeč paralelně otevírá několik spojení pro jejich načtení, čímž stále naráží na limity. U HTTP/2 se všech pět zdrojů přenáší současně přes jedno spojení jako více datových proudů. Datové rámce z různých toků se prolínají, přičemž klient i server efektivně spravují celé spojení.
Tím se eliminuje potřeba vícenásobných připojení TCP, snižuje se režie oken řízení toku spojení a výrazně se zlepšuje výkon webu.
Komprese záhlaví pomocí HPACK
HPACK, definovaný v dokumentu RFC 7541 (zveřejněném spolu s protokolem HTTP/2 v květnu 2015), poskytuje kompresi záhlaví speciálně navrženou pro protokol HTTP/2. To je důležité, protože hlavičky HTTP/1.1 byly mnohomluvné a zcela nekomprimované, což způsobovalo zbytečný síťový provoz při každém požadavku.
Vezměme si typické hlavičky požadavku HTTP:
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)...
Accept: text/html,application/xhtml+xml,application/xml;q=0.9...
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Cookie: session=abc123def456; tracking=xyz789...Tyto hlavičky často přesahují 700-800 bajtů na jeden požadavek. V případě souborů cookie mohou dosáhnout až několika kilobajtů. Vynásobte to desítkami požadavků na stránku a ztrácíte značnou šířku pásma – což je obzvlášť nepříjemné v mobilních sítích.
HPACK komprimuje záhlaví třemi mechanismy:
- Statická tabulka: 61 předdefinovaných běžných dvojic pole/hodnota hlavičky (jako :method: GET nebo :status: 200), které se nikdy nemusí přenášet.
- Dynamická tabulka: Tabulka specifická pro připojení, kterou klient a server vytvářejí společně a která uchovává dříve přenesené hodnoty záhlaví pro opakované použití.
- Huffmanovo kódování: Hodnoty řetězců se kódují pomocí předdefinované Huffmanovy tabulky, čímž se zmenší reprezentace textu.
Výsledek je dramatický. Poté, co první požadavek vytvoří společné hlavičky v dynamické tabulce, mohou další požadavky přenášet pouze odkazy na indexy. Hlavičky, které na začátku tvořily kilobajty, se zmenší na desítky bajtů.
HPACK byl speciálně navržen tak, aby se vyhnul bezpečnostním zranitelnostem, jako jsou CRIME a BREACH, které postihovaly dřívější kompresní schémata, například DEFLATE SPDY. Díky použití statických Huffmanových kódů a pečlivé správě tabulek brání HPACK útočníkům v použití analýzy kompresního poměru k získání tajemství ze smíšených dat útočníka a oběti.
Stojí za zmínku, že HPACK pracuje pouze s hlavičkami HTTP. Těla odpovědí stále používají standardní mechanismy kódování obsahu jako gzip nebo Brotli na vrstvě HTTP, zcela odděleně od komprese hlaviček.
Upřednostňování serveru Push a streamu
Protokol HTTP/2 zavádí dvě optimalizační funkce, které mají nahradit řešení protokolu HTTP/1.1: funkci server push pro proaktivní doručování prostředků a priorizaci datových toků pro inteligentní řazení prostředků.
Server Push
Funkce Server push umožňuje webovému serveru odesílat prostředky klientovi dříve, než jsou výslovně vyžádány. Tento mechanismus funguje prostřednictvím rámců PUSH_PROMISE:
- Požadavky klienta /index.html
- Server odpoví pomocí HTML, ale také pošle rámce PUSH_PROMISE, ve kterých oznámí, že pošle /styles.css a /app.js.
- Server odešle tyto prostředky na nových streamech iniciovaných serverem (s identifikátory streamů používajícími sudá čísla podle pravidel pro přiřazování identifikátorů streamů s nižší hodnotou).
- Prohlížeč obdrží zdroje předtím, než při parsování HTML zjistí, že je potřebuje.
Tím se eliminují okružní jízdy. Místo:
- Požadavek HTML → Příjem HTML
- Rozbor HTML, zjištění potřebných CSS → Vyžádání CSS
- Rozbor CSS, zjištění potřebných písem → Vyžádání písem
Push serveru sbalí kroky 2-3 do kroku 1.
V praxi se však ukázalo, že server push je problematický:
- Prohlížeče již mohou mít prostředky uloženy v mezipaměti, což vede k plýtvání prostředky.
- Špatně nakonfigurované servery příliš tlačí na pilu a plýtvají šířkou pásma.
- Mechanismy pro zpracování mezipaměti se nikdy nedočkaly širokého přijetí.
- Mnoho sítí CDN a prohlížečů nyní ve výchozím nastavení omezuje nebo zakazuje službu push.
Klienti mohou funkci push zcela zakázat nastavením SETTINGS_ENABLE_PUSH = 0 v předvolbě připojení. Pokud předmluva připojení klienta okamžitě zakáže push, předmluva připojení serveru se skládá z potvrzení a shody.
Prioritizace toků
Prioritizace datových toků umožňuje klientům signalizovat důležitost prostředků a pomáhá serverům efektivně přidělovat šířku pásma. Tento mechanismus využívá:
- Hmotnosti: Hodnoty od 1-256 označující relativní důležitost
- Závislosti: Proudy mohou záviset na jiných proudech a vytvářet strom závislostí prostřednictvím deklarací závislostí proudů.
Praktický příklad:
- HTML stream (váha 256, bez závislosti) – nejvyšší priorita
- CSS stream (váha 200, závisí na HTML) – vysoká priorita
- Obrázky nad záhybem (hmotnost 100, závisí na CSS)
- Analytics JavaScript (váha 16, závisí na HTML) – nízká priorita
Tím je zajištěno, že kritické zdroje vykreslovací cesty dorazí jako první, což zvyšuje vnímanou rychlost načítání, i když celková doba přenosu zůstává podobná.
Důležitá upozornění:
- Stanovení priorit je doporučující, nikoli povinné
- Implementace serverů se značně liší v tom, jak dodržují priority.
- Zprostředkovatelé (proxy servery, sítě CDN) mohou měnit pořadí rámců.
- Ladění vyžaduje testování s reálným provozem, nikoli předpoklady.
Inzerovaný limit souběžného proudu ovlivňuje, kolik proudů může mít aktivní priority najednou.
Řízení toku, zpracování chyb a bezpečnostní aspekty
Protokol HTTP/2 implementuje vlastní řízení toku a zpracování chyb nad protokolem TCP, čímž řeší scénáře, kdy inteligence aplikační vrstvy překonává výchozí nastavení transportní vrstvy.
Řízení toku
Řízení toku zabraňuje tomu, aby rychlí odesílatelé zahltili pomalé příjemce. Protokol HTTP/2 používá systém založený na kreditech pomocí rámců WINDOW_UPDATE:
- Každý proud má vlastní okno řízení toku přijímače.
- Spojení má také okno řízení toku spojení
- Výchozí velikost okna: 65 535 bajtů (64 KB)
- Odesílatelé nemohou přenášet rámce DATA, které přesahují dostupné okno přijímače.
- Příjemci odesílají rámce WINDOW_UPDATE, aby přidělili více kreditu.
Klíčové vlastnosti:
- Řízení toku je hop-by-hop (platí mezi každým párem odesílatel/příjemce).
- Nelze ji vypnout
- Do okna se započítávají pouze snímky DATA; ostatní povinná data snímků se nezapočítávají.
- Řízení toku proudu i řízení toku spojení fungují nezávisle.
Tím se zabrání monopolizaci zdrojů připojení jediným rychlým tokem, což je důležité zejména v případech, kdy se mezi klienty a původními servery nacházejí proxy servery nebo sítě CDN.
Zpracování chyb
Protokol HTTP/2 poskytuje granulární signalizaci chyb:
- Chyby na úrovni toku: RST_STREAM okamžitě ukončí jeden stream, aniž by ovlivnil ostatní, a nese chybové kódy jako PROTOCOL_ERROR nebo FLOW_CONTROL_ERROR.
- Chyby na úrovni připojení: GOAWAY elegantně ukončí připojení, čímž umožní dokončit požadavky během letu a zároveň zabrání novým požadavkům.
Protokol definuje registr chybových kódů, který obsahuje:
- PROTOCOL_ERROR (0x1): Porušení obecného protokolu
- FLOW_CONTROL_ERROR (0x3): Porušena pravidla řízení toku
- FRAME_SIZE_ERROR (0x6): Překročena velikost rámce SETTINGS_MAX_FRAME_SIZE (Nastavení_maximální_velikosti_rámce)
- INADEQUATE_SECURITY (0xc): Nedostatečná konfigurace zabezpečení transportní vrstvy
Bezpečnostní aspekty
Ačkoli RFC 7540 technicky nevyžaduje šifrování, všechny hlavní webové prohlížeče vyžadují HTTP/2 přes zabezpečení transportní vrstvy (TLS). Tím se TLS 1.2+ stává de facto základním standardem:
- Připojení začíná předáním protokolu TLS včetně protokolu ALPN (Application-Layer Protocol Negotiation).
- Rozšíření ALPN vyjednává identifikátor „h2“ pro HTTP/2
- Servery se musí vyhýbat slabým sadám šifer, které jsou na černé listině specifikace.
- Sady šifer používající RC4 nebo jiné zastaralé algoritmy vyvolávají chyby INADEQUATE_SECURITY.
Ochrana osobních údajů zahrnuje:
- NASTAVENÍ a vzory priorit mohou klientům odebírat otisky prstů.
- Jediné připojení na původ koreluje veškerou aktivitu uživatele s tímto původem.
- Binární protokol zastírá provoz, ale neskrývá ho před pozorovateli sítě
Blokování TCP v čele linky
Protokol HTTP/2 řeší blokování na úrovni HTTP pomocí multiplexování, ale blokování na úrovni TCP zůstává. Při ztrátě paketu TCP se všechny datové toky v daném připojení zastaví, dokud se nedokončí opakované vysílání – dokonce i toky, jejichž data úspěšně dorazila.
Toto omezení motivovalo HTTP/3, který běží přes QUIC (založený na UDP) a poskytuje skutečnou nezávislost na datových tocích. Ztráta paketu ovlivňující jeden tok neblokuje ostatní.
Nasazení a používání protokolu HTTP/2 v praxi
V roce 2026 je povolení protokolu HTTP/2 jednoduché. Většina moderních webových serverů a sítí CDN jej podporuje hned po vybalení z krabice, především přes HTTPS. Mechanismus aktualizace HTTP zvládá vyjednávání transparentně.
Požadavky na straně klienta
Uživatelé nemusí dělat nic zvláštního:
- Všechny moderní webové prohlížeče (Chrome, Firefox, Safari, Edge) podporují HTTP/2 ve výchozím nastavení.
- Mobilní webové prohlížeče (Chrome pro Android, Safari pro iOS) plně podporují
- Kompatibilita s aktuálními verzemi prohlížečů
- HTTP/2 vyjednává automaticky, když je k dispozici
Konfigurace na straně serveru
Server Apache HTTP (2.4.17+):
- Povolte modul mod_http2 (nikoli starší mod_spdy).
- Přidání protokolů h2 http/1.1 do virtuálních hostitelů TLS
- Zkontrolujte, zda verze OpenSSL podporuje ALPN
Nginx (1.9.5+):
server {
listen 443 ssl http2;
ssl_certificate /path/to/cert.pem;
ssl_certificate_key /path/to/key.pem;
# ... rest of configuration
}IIS (Windows Server 2016+):
- HTTP/2 je ve výchozím nastavení povolen pro HTTPS s TLS 1.2+
- Není nutná žádná další konfigurace
Poskytovatelé CDN:
- Cloudflare: HTTP/2 je ve výchozím nastavení povolen ve všech plánech
- AWS CloudFront: Ve výchozím nastavení povoleno pro distribuce HTTPS
- Fastly: Podporováno a povoleno ve výchozím nastavení
Ověřování a řešení problémů
Pomocí tohoto kontrolního seznamu ověřte, že protokol HTTP/2 funguje:
- Browser DevTools: Otevřete kartu Síť, povolte sloupec Protokol, vyhledejte „h2“.
- Příkazový řádek: curl –http2 -I https://example.com zobrazí v odpovědi HTTP/2
- Online nástroje: Testovací služby HTTP/2 ověřují konfiguraci
- Zkontrolujte zprostředkovatele: CDN nebo reverzní proxy musí podporovat HTTP/2, ne jen origin server.
Běžné problémy bránící protokolu HTTP/2:
- Příliš stará verze OpenSSL pro podporu ALPN
- Konfigurace pouze TLS 1.0/1.1
- Slabé sady šifer spouštějící funkci fallback
- Chybně nakonfigurovaný proxy server odebírá podporu HTTP/2
HTTP/2 a další
HTTP/2 zůstává dominantním protokolem pro moderní webovou komunikaci, i když se začíná zavádět HTTP/3 (RFC 9114, publikováno 2022). HTTP/3 řeší blokování TCP head-of-line tím, že běží přes QUIC, ale model jediného připojení TCP protokolu HTTP/2 nadále efektivně slouží většině webového provozu.
Pro většinu webů přináší protokol HTTP/2 podstatné zlepšení výkonu webu s minimálními nároky na konfiguraci. Začněte si vyměňovat rámce přes HTTP/2 ještě dnes a vaši uživatelé – ať už na počítači nebo na mobilu – budou mít rychlejší a efektivnější načítání stránek.
Klíčové poznatky
- HTTP/2 přináší revoluci ve výkonu webu díky multiplexování, které umožňuje více souběžných výměn přes jedno připojení.
- Komprese záhlaví HPACK eliminuje nadbytečný přenos záhlaví, což je výhodné zejména pro mobilní uživatele.
- Server push a upřednostňování datových toků optimalizují poskytování prostředků, ačkoli se implementace liší.
- Řízení toku zabraňuje nedostatku prostředků ve více tocích.
- Nasazení je na moderních serverech jednoduché, vyžaduje především konfiguraci HTTPS.
- Všechny hlavní prohlížeče podporují protokol HTTP/2, takže jeho přijetí je pro koncové uživatele bezproblémové.
Další kroky
Pokud jste na svém webovém serveru ještě neověřili protokol HTTP/2, máte nejvyšší čas. Otevřete vývojářské nástroje prohlížeče, načtěte web a zkontrolujte sloupec Protokol. Pokud místo „h2“ vidíte „http/1.1“, zkontrolujte konfiguraci svého serveru – necháváte na stole významný nárůst výkonu.
Ti, kteří již používají protokol HTTP/2, by měli zvážit sledování metrik připojení HTTP/2 na svém serveru. Porozumění tomu, jak se chová více souběžných streamů v reálném provozu, pomůže identifikovat příležitosti k optimalizaci dříve, než si uživatelé všimnou problémů.