Včera jsem psal o HTTP/3.
Máte s tím někdo zkušenosti? Co si o této technologii myslíte?
Díky za názory. Sbírám data k dalšímu článku na toto téma.
Včera jsem psal o HTTP/3.
Máte s tím někdo zkušenosti? Co si o této technologii myslíte?
Díky za názory. Sbírám data k dalšímu článku na toto téma.
Nevim, CF to zatim jisti a podpora ze strany browseru tak nic moc. Tu novou sablonu mas pomalou docela :(
Používáme to zatím u mobilních aplikacích, kde je strana klienta a serveru pod kontrolou, výrazně se zlepšuje odolnost spojení při špatném signálu nebo pomalejší síti. Daleko levnější je i servová strana při řešení load balancingu, mohli jsme vynechat drahé f5 kvůli stavovému tcp a používat levnější řešení přímo na aplikační úrovni a sezení řešit přes klasicky ODS.
Stejně tak jsme http/3 začali experimentálně používat při komunikaci mezi servery, k tomu mám poměrně velké množství zkušeností, ale je to asi za potřebami zdejšího fóra. Zatím to hodnotím pozitivně.
Samotné nasazení na weby zatím není na pořadu dne u žádného klienta, jen testujeme interně, velice se hodí možnost řídit datový tok ze strany serveru a posílat obsah v pořadí, v kterém víme, že bude potřeba. Velké zlepšení je v případě stránek s velkým množstvím malých souborů (typicky galerie nebo video služby), ale to už bylo s http/2. Chvilku bude trvat než se stabilizuje klientská část, zatím v implementacích jsou velké mezery a nerovnosti, složitě se řeší debuging a problémy. Negativním efektem je složité ovlivnění šířky pásma na straně serveru (QoS), i malé množství klientů dokáže u horšího hostingu saturovat zdroje a omezit službu, při velkých službách se zase daleko lépe řeší rozložení zátěže.
@Oleg je rychlejší než ta před tím právě..
@Tomaš můžeš se podělit o zkušenosti? Docela mě to chytlo a chystám se na další článek. Info bych uvítal.
Souhlasím s Olegem. Je hezké, že řešíš HTTP/3, ale jiné aspekty webu ti to zpomalují víc než je teoretický přínos HTTP/3.
Nebudu si konvertovat všechny obrázky na webu, jen proto, že to říká nějaká online služba.
Tohle není o mém blogu, tak se prosím držte tématu.
A co potřebuješ vědět?Původně odeslal Wladass
Http/3 dává vývojářům silnou sadu technik a nástrojů, jak mohou komunikaci přesunout na novou úroveň (kratší RTT při zachování RTD, nižší režii, šifrování a datovou integritu hlaviček, libovolnou velikost payloadu, konfiguratovatelné timeouty a znovu poslání paketu atd.), ale zároveň to bere jistoty, které http nad tcp poskytuje (stabilní load balancing, routing podle hlaviček, stabilní trasu u established spojení - routery jsou stavové, snadný debuging, ověřenou a rozšířenou implementaci, predikovatelné chování).
Http/3 jde ruku v ruce s ipv6, multihoming, dynamické trasování a podporou více cílů. Výrazně se s tím zjednodušuje komunikace při změně sítí (dá se plynule bez výpadku přecházet např. mezi wifi a lte tam a zpět klidně každou minutu). Dává ale velkou zodpovědnost na stranu aplikací, tady vzniká nejvíce problémů a chvilku bude trvat než vzniknou ověřené znovupoužitelné implementace a je to za mě největší bolístka. Na straně aplikací se tím mění pattern request-response a najednou klientská a servová část aplikace navzájem oboustranně spolupracují, aby přichystaly obsah pro zobrazení a zpracování. Tím se ale výrazně zvyšují nároky na straně klienta, na to pozor, mám problém nacházet schopné vývojáře na backend, u frontendu to je katastrofa.
Velké zkušenosti s tím mám na straně serverů a backend aplikací, kdy jsme u HA služeb (99,997 % dostupnost) mohli vyhodit drahé routery a celý problém vysoké dostupnosti aplikací a balancingu mohli založit na bezstavovém udp a eventual consistency databázích (něco jako mongodb, cassandra nebo celá rodina databází nad rocksdb). Tady vidím obrovskou výhodu, doteď jsme sice dělali event-driven koncové aplikace, event-driven zpracování dat a požadavků, ale měli stavové tcp balancery, který celý ten systém ponižovali a tvořily úzké hrdlo ve špičkách (viz. např. věčné výpadky iVysílání od ČT, to je celé způsobené i nerovnoměrným rozložením zatížení na tcp balancerech, kdy při inicalizaci spojení ještě není jasné jak dlouho bude trvat a pak dochází k potkání se spousty dlouhých spojení na jednom serveru/routeru/síti, přepojení na jinou trasu a znovuvytvoření spojení trvá spousty sekund a to způsobuje nepříjemné lagy při přehrávání nebo právě ucpání celé infrastruktury neustálým přepojování hodně klientů).
http/3 má ale i stinné stránky, blbě se řeší bezpečnost, doteď páteřní routery byly schopni spousty závadného provozu sami filtrovat (jsou stavové a mají dostatek informací o komunikaci z hlaviček), ale s http/3 jim ty informace chybí, takže je nutné provoz pouštět na backend, tam ho zpracovat a pokud je závadný, dát vědět routerů a pro příště ho zablokovat. To s sebou ale nese zvýšené náklady na backend a zvyšuje reakční dobu a odvrácení útoků, už to nelze tak snadno řešit a je potřeba s tím při návrhu počítat. Vhodné technologie k tomu teprve vznikají a útoků je zatím také pomálu.
Díky za zajímavý komentář. Je vidět, že je to za základě zkušeností.
Díky Tome. Dal bych bezvýznamnou rep, ale z mobilu nejde.
Dostat tu směrodatnou odpověď je skoro zázrak.
No ono jsou dve hlavni urovne teto problematiky:
1) Jak pise TomasX - usnadnuje to spoustu veci, ale zarovnen ma svoje problemy. Opravdu efektivne resi TCP head-of-line-blocking.
2) Mel by teoreticky byt rychlejsi pro komunikaci server-klient HTTP over QUIC, ale je to jen teorie, sice to ma nejake pozitivni vysledky a predpokladam, ze to bude mit velky dopad na rychlost nacitani pro uzivatele, ale musime se pockat masivni podporu a implementaci.
Takze, v jake rovine resit HTTP/3? Jeho dopad na rychlost prenosu nebo bezpecnost a efektivitu?
Momentalni podpora viz: https://caniuse.com/#feat=http3
Cloudflare to ted poskytuje experimentalne, muzes si to zaplnout, ale k cemu, pro experimentovani s Chrome Canary, Edge dev? U Cloudflare se ted vyplati spise Argo tunel, je lepsi nez H3oQ, fakt megalne lepsi.
Zkus u hostingu zjistit zda pouzivaji TLS 1.3, Wedos napriklad ne.
