Názory k článku HTTP/3: co nám nový protokol přinese a proč to hned tak nebude

Jsem zvědav, zda se s rozšířením IPv6 a šifrování (hlavně HTTPS) podaří Internet spravit v tom smyslu, že zařízení po cestě nepolezou kam nemají a nebudou tedy (často nechtěně) blokovat protokoly, kterým nerozumí – a zda tedy bude v budoucnosti snazší zavést nový protokol. A nebo zda to uživatelé různých NATů a síťových „antivirů“ nevzdají a při pokusech vlámat se dovnitř komunikace rozbijou na co přijdou, takže budeme čím dál víc směřovat k „Internet-over-HTTP“.

Vendoři stále půjdou cestou nejmenšího odporu.

Potřebujete zavést software. Musíte investovat dolar tak, aby se vrátil a ještě něco vydělal. K tomu potřebujete: 1) levné programátory, 2) co nejméně problémů u zákazníků.

Levný programátor = využije nějakou dostupnou knihovnu, neláme si hlavu nad efektivitou přenosu, často ani nad zabezpečením.
Co nejméně problémů u zákazníků = potřebujete řešení "tady a teď". Může být z dlouhodobého hlediska lepší dodržovat standardy, jenže se taky může stát, že Vaše firma už nebude u toho, protože mezitím zkrachuje.

To je taky důvod, proč se IPv6 uchytává tak moc děsně pomalu. Celkově by světu prospělo, ale těm, kteří by ji museli podporovat a tlačit, se to nevyplatí. Po IPv4 a přes všechny NATY data nějak protlačí (nezabezpečeně, neefektivně), jenže ty náklady s neefektivitou nese někdo jiný.

Podívejte se na nabídku největších internetových operátorů. Objednejte si kabelovku, DSL, nebo i internet od místního providera. V kolika procentech případů dostanete službu, kde bude i IPv6, včetně dodávky fungujícího routeru a instalace typu "plug & forget"?

"Objednejte si kabelovku, DSL, nebo i internet od místního providera."
VDSL routery mají IPv6 snad od samého začátku, zákazníci to už pár let mají zapnuté. UPC má IPv6 standardně cca 2 roky, ale kdo má starší instalaci, tomu to (asi) zůstává postaru.
V obou případech ale máte IPv6 out-of-the-box, pokud si za to nedáte další router - to je ovšem celkem časté, lidi si pokrytí WiFi rozšíří routerem (v režimu router, nikoliv AP), takže sbohem IPv6.
Místní provider bude případ od případu, takový větší, Netbox, má IPv6 přes 6in4, který si musíte nakonfigurovat (když máte router, který to umí). To skutečně není žádná sláva (udělá to jen geek, BFU rozhodně ne).
Ale v tomto směru ti velcí provideři jsou lepší, protože dávají svůj modem/router a když to zapnou, tak to zákazníci mají. Malí ISP ne, tam si router koupí klient, obvykle co nejlevnější, takže smůla.

Tak např. UPC Vám neodroutuje standardní /64 prefix, takže z vlastností IPv6 využijete zase jen zlomeček.
Pokud chcete mít pevnou IPv4 adresu, tak o IPv6 přijdete úplně, neumějí to.

Malí ISP jsou podle mě průšvih. To, že nedodávají koncové zařízení způsobuje spoustu problémů. Mimo jiné nemají segment sítě chráněný, takže zavirované PC ovlivní velký kus sítě. Pokud je to bezdrátem, tak je to o to horší. Následkem toho pak zavádějí různé nesmyslné filtry (nejmenší z toho je blokování portu 25), ale i limity na spojení a tempo nových spojení. O to víc je situace zamotaná a blbě řešitelná - přesně jak na to naráží kolega Jirsák.

To jistě, UPC má naprosto debilní firmware a nejde přepnout do bridge modu, a když mu zapnu stateful, tak to po restartu zase přepne do stateless. O2 zase dá jen /64. Ale v obou případech máte veřejnou adresu, byť efektivně jen jednu síť.
Jenže moje námitka se týká tvrzení:
"Objednejte si kabelovku, DSL, nebo i internet od místního providera. V kolika procentech případů dostanete službu, kde bude i IPv6, včetně dodávky fungujícího routeru a instalace typu "plug & forget"?"
Takže DSL i kabelovka (UPC) vám out-of-the-box fungující IPv6 dá, pro domácí použití naprosto vyhovující - a to je docela dost klientů.
S těmi místními providery souhlas, a zapomněl jste na mobilní operátory, ti taky na IPv6 stále z vysoka.

Podle mě se to nepodaří. Myslím si, že HTTP/3 se kvůli tomu moc prosazovat nebude, protože prostě nebude fungovat všude. HTTP/2 funguje všude tam, kde funguje klasické HTTP/1 s HTTPS a zároveň jde efektivitou až na samou hranici možného v rámci TCP protokolu. Proti tomu ani protokol UDP se dosud nikdy síťově na internetu nepoužíval, jediné použití je hop-by-hop přenos DNS zpráv.

Navíc HTTP/3 přinese proti HTTP/2 zlepšení hlavně lidem s nejméně kvalitní přípojkou, což jsou obvykle ti nejchudší, takže nasazením HTTP/3 jen tak někdo nezbohatne.

Proti tomu ani protokol UDP se dosud nikdy síťově na internetu nepoužíval

DNS? NTP? SIP/RTP? IPsec IKE a případně NAT-T? openvpn? vxlan?

jediné použití je hop-by-hop přenos DNS zpráv

Hop-by-hop jen z hlediska DNS hierarchie (a i to jen částečně), rozhodně ne z hlediska síťové toipologie.

DNS jen na místní resolver, přímé spojení s internetem je potřeba jen pro ten resolver – tohle jsem myslel tím hop-by-hop. NTP, SIP/RTP – stejný příběh jako DNS – koncové stanice komunikují výhradně interně.

IPsec IKE je přesně ten protokol, na kterém se ověřilo, že přidávání nových transportních protokolů na internetu prostě nefunguje. A ano IPsecové, případně OpenVPN VPNky ze spousty korporátních sítí nefungují. Proto taky někteří provozovatelé VPN v čele s Mikrotikem dostali „geniální nápad“ provozovat OpenVPN na tcp/443. VXLAN je datacentrová technologie, tu snad žádná koncová stanice (= tam, kde má běžet HTTP/3) nepoužívá.

Takže ano, koncové stanice v korporátních sítích dosud nepotřebovaly používat síťově (tím myslím nikoli v lokální síti) nic jiného než TCP. Spousta správců koncových sítí přitom nastavuje firewally způsobem „cokoli není (teď) používáno pro jistotu zablokujeme“. Někteří jdou i tak daleko, že blokují například veškeré ICMP.

jen v Praze jsou desítky firem, které blokují vše kromě běžných tcp portů, udp a icmp neprojde. Pokrývají desítky až stovky tisíc zaměstnanců, není to vůbec málo.

Stejně tak bude tomuhle protokolu bránit nemožnost (pro mě super) jeho filtrování, což zase lokální správci nebudou mít rádi.

Osobně mi vadí implementace kompletně v user space, každá aplikace si implementaci ponese s sebou.

My přes UDP dostáváme streamy TV stanic pro další zpracování.

DNS jen na místní resolver

Zdaleka ne vždy, spousta lidí má z různých důvodů 8.8.8.8 a 8.8.4.4. Já mám třeba na některých svých strojích 127.0.0.1 a vlastní caching only nameserver. Navíc ten resolver používá úplně stejný protokol, jako by používala koncová stanice. Není důvod, proč by měl jeden projít a druhý ne.

NTP, SIP/RTP – stejný příběh jako DNS – koncové stanice komunikují výhradně interně.

NTP - zdaleka ne vždy. Mám-li víc počítačů v lokání síti, může mít smysl mít tam i lokální NTP server. Pro jeden nebo dva je to zbytečné. Koneckonců třeba openSUSE defaultně nastavuje 0.opensuse.po­ol.ntp.org apod. Kolik procent uživatelů myslíte, že si to změní? SIP - to jako že má každý svého VoIP providera na jeden hop? To asi těžko...

IPsec IKE je přesně ten protokol, na kterém se ověřilo, že přidávání nových transportních protokolů na internetu prostě nefunguje.

IKE žádný nový transportní nepřidává (a QUIC resp. HTTP/3 ostatně také ne), běží nad UDP (RFC 768 a.k.a. STD 6, datováno 28.8.1980, tj. o rok dříve než RFC 791 a 793). S čím byl často problém, to byly protokoly AH a ESP, kvůli tomu ostatně vzniklo rozšíření NAT-T, které pro veškerou komunikaci používá UDP. Kdyby to bylo s fungováním UDP na Internetu tak špatné, jak se snažíte tvrdit, proč by si někdo dával tu práci?

openvpn přes TCP je fallback právě pro ty případy, kdy je po cestě absurdně nakonfigurovaný firewall. Naštěstí jsou to spíš výjimky a zdaleka jich není tolik, jak se snažíte tvrdit. Ani v případě různých hotspotů v obchodních domech nebo na letištích či připojení v hotelech, s UDP problém nemívám. Vlastně si vzpomínám jen na jeden případ, kdy mi openvpn přes UDP nepřošla a přes TCP ano.

Mimochodem, když se podíváte např. na statistiky tady (přibližně 0:45 - 4:55), zjistíte, že QUIC už se ve skutečnosti v praxi pár let používá, a to v nezanedbatelné míře.

Ja bych to nevidel tak cerne - nevytvaris nejaky novy protokol, ktery musi umet zarizeni. Vytvaris protokol nad UDP. Potrebujes, aby to podporoval server - tech zase tolik neni a prohlizec - tech taky moc neni a mas hotovo. V podstate to velci hraci mohou prosadit "silou".

Mě by hlavně zajímalo jakým způsobem se pak bude sanitizovat trafik, a to hned na obou dvou koncích:
1. denně na nás jde několik UDP flood útoků, které je triviální teď čistit, protože téměř nic nepřipomíná regulérní provoz. Přechodem HTTP na UDP to bude znamenat parsovat komunikace až na aplikační úroveň a tedy nejspíše desetinásobek současného výkonu.
2. aktuálně máme bezpečnostní pojistku, aby ze sítě neodcházeli UDP až na pár výjimek. S přepnutím HTTP na UDP komunikaci tak umožníme opět jakémukoliv počítači v síti stát se aktivním prvkem v botnetu a riskovat například zablokování celé sítě. V dřívější dobách by se to řešilo povolením jen schválených zařízení, ale dnes každý vyžaduje wifi access s internetem ke svému mobilu/tabletu/no­tebooku.

1. Až na aplikační úroveň se kvůli šifrování nedostanete. Bez znalosti klíče relace není možné odlišit legitimní součást QUIC relace jiných UDP zpráv

2. Jaký je rozdíl v botnetu na UDP proti botnetu na TCP?

1. To lze vyřešit problém logováním klíčů, Wireshark je na to připraven. Java mu může data poskytnout skrze http://jsslkeylog.sourceforge.net/ , u Firefoxu a Chrome AFAIR stačilo nastavit nějakou environment variable.

I když to odlišíte, k čemu vám taková informace bude? Stejně to musíte zahodit až na cílovém stroji, žádný síťový prvek po cestě nebude schopen takové drobné nuance rozlišovat, natož pak takové detaily třeba pomocí RTBH filtrovat přímo u providera.

Je to vlastně celé takové symbolické. Tím, že se middleboxy naučily strkat prsty i do transportních protokolů byl způsoben současný stav, kdy je každý nový protokol třeba vymyslet tak, aby navenek předstíral nějaký starý známý transportní protokol. Na to vývojáři middleboxů zřejmě zareagují strkáním prstů i do aplikačních dat, ve kterých se skrývá nový transportní protokol. Takhle to nejspíš budeme iterovat donekonečna a ze čtyřvrstvého TCP/IP nám časem vznikne dvacetivrstvé, kde budou vrstvy L4a až L4t ;)

Aha, vypadá to, že jsem ten komentář vytrhl z kontextu. Sorry.

Z našeho provozu registrujeme kupodivu jen větší UDP floody. Na TCP možná něco chodí, ale nic, čeho bychom si všimli mimo normální trafik. Pokud je mi známo, tak TCP floody se běžně řeší limitováním rate syn packetů per IP a zaříznutím čehokoliv, co není v conntrack tabulce. Což je docela CPU/RAM náročné, ale dnešní běžný serverový hw by snad mohl ustát i pár Gbps syn flood. A to je v podstatě způsob, jakým bych přistoupil k filtrování floodu z QUICu. Analyzováním TLS hlavičky, jestli se jedná o již započaté spojení a omezil vytváření nových per IP. Nicméně oproti vyparsování TCP portu a flagů, abych se dostal k informacím o flow, budu muset parsovat QUIC a TLS hlavičky, abych dostal tu samou informaci. Hardware to zvládne, ale pomaleji.

Myslím, že tohoto není třeba se až tak bát. TCP filtrujete na firewallech hlavně kvůli tomu, aby vám nevyčerpalo prostředky v TCP/IP stacku v jádře. Proti tomu UDP datagram projde velmi rychle přímo do aplikace, aniž by za sebou zanechával jakékoli stopy - pokud tedy pro UDP vypnete conntrack. Samotná aplikace pak nepochybně velmi rychle a levně* vyhodnotí, které datagramy patří k existujícím spojením a ty ostatní ihned zahodí.

Proto si myslím, že žádný předsunutý inteligentní firewall analyzující obsahy UDP zpráv není nutný.

*) přinejmenším stejně rychle a levně, jako by to dělal předsunutý firewall

pekny clanok

QUIC se mi libi; protoze uz i ted jde videt, ze je YT/Google o dost sviznejsi, nez treba Facebook (a vsechny jine stranky), ktere bezi na TCP.

Trosku kuriozitka ale je, ze Apache se stale nenaucilo HTTP/2 spolecne s preforkem (a tudiz i treba s mod_php) a my uz tu budeme za chvili mit HTTP/3 :-)

Kuriozita je spíš to, že stále existuje mpm_prefork a mod_php.

Mpm_prefork je není ani tak pre-fork, jako spíš pre-historie. Je s podivem, že ho Apache vůbec ještě zachovává. Podle mě popularita Apache upadá právě i díky tomu, že udržuje morálně zastaralé technologie. Nginx získává popularitu právě proto, že razí jednu "best practice" cestu a nedovoluje, aby to admin vyprasil.

Je mnoho důvodů, proč používat mpm_worker + php_fpm a není prakticky žádný důvod pro používání mpm_prefork + mod_php.

Prave ja jsem nikdy s Apache a preforkem (az na to h2) problem nemel, zatimco z FCGI PHP ano.
Apache mimo jine i diky tomu, ze existuje dlouho ma k dispozici hromadu modulu, ktere dokazou mnoho, zatimco nginx mimo jine i kvuli sve jednoduchosti nejake moduly strada.
FPM spolecne s nginx jsem zkousel, a stale teda nechapu jak, ale podarilo se mi, ze se php kod spoustel pred uspesnym overenim pres Digest auth, coz byla obrovska bezpecnostni trhlina.
FPM s Apache byl oproti modulu trosku narocnejsi, coz by pro RPi Zero mohlo pri vyssi navstevnosti (nebo utoku) cinit problemy.
Ale abych pouze nekrivdil, tak Nginx se vyborne osvedcil jako reverzni proxy :)

Právě většina těch Apache modulů je toxických, jsou to ohejbáky, mnohdy velmi obsoletní (např. peklo jménem "htaccess"). FPM funguje spolehlivě i s Apache / mpm_worker. Naopak forkování je náročnější operace, mělo by to být méně výkonné, než worker. Jediné, co mě napadá je, jestli jste neměl nastavený FPM na pm.dynamic, nebo neměl příliš velký static pool.

Nginx opravdu nemusí vždy stačit, ale Apache bych určitě přepnul do mpm_worker + PHP FPM.

PS: někdy se jako perverzní proxy hodí naopak Apache, protože Nginx nemá podporu NTLM autentikace, resp. jen v placené verzi. (Tak, a teď se v tom vyznejte, co se k čemu hodí, že? :)))

na tradiční multihostingu je apache s mpm_prefork a mod_php nutnost.

když na jednom serveru máte pár tisíc hostingů, které mají jdenotky návštěv denně, tak je nesmysl aby pro každý hosting běžel samostatný worker, minimálně kvůli paměti.

a přechod napříkad na nginx je naprosto nemožný. není možné zákazníkům sebrat htaccess. nginx žádnou podobnou variantu nenabízí, takže by bylo nutné editovat přího konfiguraci vhostu a vstup od zákazníka by se musel složitě parsovat, jestli se náhodou nesnaží o něco, k čemu nemá přístup.

Pro každý hosting nemusí běžet nezávislý worker, vůbec ne. Princip je prakticky stejný, jak o u preforku, jen nedochází právě k náročné operaci fork(). Nevýhodou preforku je i to, že každý fork musí nutně natahovat i mod_php a tedy žere paměť. U worker naopak obslouží statické soubory a jen na volání PHP zavolá FPM. FPM pak požadavky agreguje, takže je potřeba daleko méně paměti, než u preforku.

Tj. s výkonem je to přesně naopak, než píšete. Mrkněte např. na PLESK panel, kde je běžné obsluhovat tisíce webů, je tam reverzní nginx pro statické soubory (+ možnost editovat konfiguraci uživatele) + možnost apache (ale není nutné ji využívat). PHP je řešení přes FPM, mod_php je nedoporučován. (Zde: https://support.plesk.com/hc/en-us/articles/213371169-High-CPU-and-memory-usage-by-website)

Htaccess je výkonnostní past. V 99 % případů slouží k přesměrování požadavku do nějakého frameworku - tj. POKUD EXISTUJE statický soubor POTOM servírujeme statický soubor. ELSE předáváme vše do index.php.

Ostatní direktivy v htaccess jsou různé ohejbáky na zastaralé systémy. Např. zamezení autoindexu (které je dnes už ale standardem), řešení kódování (které už opět řeší spolehlivě aplikace), zákaz přístupu do adresáře (což se stejně má řešit tím, že je mimo document root) atd. Když se nad tím vším zamyslíte, zjistíte, že ve skutečnosti htaccess není potřeba, ale že se jedná jen o dlouholetý (a špatný) zvyk.

celkem dost se mi nelibi, ze je implementace protokolu v userspace. To zase bude znamenat milion knihoven, vzajemne nekompatibilnich a to ani mezi dvema verzema stejne knihovny...
Lepsi by byla podpora primo v kernelu.

Problem vsech techle protokolu je i v tom, ze neni mnohdy jeste zcela funkcni podpora pro http/2 u reverznich proxy. Treba haproxy umi alpn/h2 na frontendu, ale backend nic. A ted by chteli pouzit udp? ...

Ještě pár let a webařům dojde, že na metadata (co se má stahovat, případně malá data) a data (vlastní stahování) se hodí jiné protokoly. Na metadata je potřeba mít zejména zajištěnou integritu, pořadí zpráv či šifrování, u dat je důležitá rychlost, latence a efektivita využívání zdrojů. Když sem tam něco vypadne, nevadí to (obrázky, videa, audio).

Doposud se řešilo, jak přenášet větší data přes TCP, teď se bude různě hackovat, jak přenášet malá data spolehlivě přes UDP.

HTTP/1 - my uzavřeme spojení po každém požadavku... WTF?

HTTP/1.1 má ve výchozím stavu keep alive. Navíc díky chunked protokolu nebo content-length lze provádět pipelineování, tedy kdy lze požádat o víc věcí současně.

Já samozřejmě oceňuju snahu najít lepší řešení než základní HTTP/1, na druhou stranu je třeba být maličko realistický. V době PWA aplikací, single page aplikací jsou často statická a dynamická část aplikace oddělena. Statická část se stahuje jen jednou a dynamická část, tam zpravidla http/2+ moc nepomůže. Tam má programátor v rukou veškerou komunikaci a může optimalizovat dle své fantasie. Třeba veškerá data posílat websocketem.

To že dnes ještě fungují stránky, které se sestavují na serveru a prohlížeč je jen tupě zobrazí, přičemž pro další činnost je potřeba přejít na další stránku, to už je jen dožívající stará technologie. Mnohem víc se mi líbí cesta, kdy se výsledný tvar webové stránky sestavuje až v prohlížeči ze statických a dynamických částí. Kde použití HTTP/2+ je zbytečně OP a zavádí jen ještě větší elektrárnu

To že dnes ještě fungují stránky, které se sestavují na serveru a prohlížeč je jen tupě zobrazí, přičemž pro další činnost je potřeba přejít na další stránku, to už je jen dožívající stará technologie. Mnohem víc se mi líbí cesta, kdy se výsledný tvar webové stránky sestavuje až v prohlížeči ze statických a dynamických částí.

Od toho jsme ještě hodně daleko. Mimo, vyhledávače ještě nejsou zcela připraveny na takovéto aplikace (weby). Google některé dynamické weby zaindexovat dokáže, ale např. Seznam si ani neškrtne.

Ještě dlouhou dobu budou s námi stránky renderované naser veru, dynamické budou spíš formuláře a komponenty, které nenesou obsahovou hodnotu. Proto je potřeba jak HTTP/2, tak i QUIC-HTTP/3.

Mě překvapuje ten přínos versus cena. 3% u běžného AJAX traffic je prakticky zanedbatelné, není-li aplikace napsána vysloveně špatně. 18% o youtube videa, budiž, ale i přesto úvodní buffering trvá vteřinu a 180ms je stěží něco, co uživatel bude vnímat. Bude-li to víc, tak stejně zážitek z videa bude tak mizerný, že mírné zrychlení na začátku to nezachrání.

Na druhé straně, energetická efektivita, je-li třetinová (třikrát dražší), tak je to hodně velká daň jak pro klienta, tak pro server. Záleží samozřejmě, jak moc padne na transport v poměru na aplikační server (neřeším věci jako php, které se stejně s každým requestem zkompilují a zahodí, ale server běžící hodiny až roky), nicméně i v microservices je to hodně o komunikaci.

A nevěřím, že by UDP implementace byla tak "odfláknutá", aby šla třikrát zlepšit, ten protokol je už tak dost jednoduchý. Čekal bych, že to bude spíš naopak, neboť role kernelu je zde zcela osekaná a zvláště při statických datech si server při trošce optimalizace nemusí prakticky nic uchovávat pro případný resend...

Autor kecá. HTTP/1.1 umí pipelining, kde je sice limitem FIFO vyřizování požadavků, ale spojení se zavírat nemusí a klient/server to ani nedělá. Článek je plný citací čehosi, autor by tomu měl v první řadě rozumět, zejména když je šéfredaktor (viz https://en.wikipedia.org/wiki/HTTP_pipelining)