Vlákno názorů k článku HTTP/3: co nám nový protokol přinese a proč to hned tak nebude od Filip Jirsák - Jsem zvědav, zda se s rozšířením IPv6 a...
-
Filip JirsákStříbrný podporovatelJsem 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"?
-
BobTheBuilderStříbrný podporovatel"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.
-
BobTheBuilderStříbrný podporovatel
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. -
Ondřej CaletkaZlatý podporovatelPodle 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.
-
Ondřej CaletkaZlatý podporovatel
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.
-
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.pool.ntp.orgapod. 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.
-
Ondřej CaletkaZlatý podporovatel
Asi jsem se vyjádřil nepřesně. Já samozřejmě vím, že existuje spousta internetových protokolů, které se běžně používají, vím i o tom, že QUIC už celkem dobře funguje několik let. Nesnažím se tvrdit, že je UDP rozbité v nějakém signifikantním množství sítí, může to být třeba pět procent, tedy jedna z dvaceti sítí. Problém je, že i to je výrazně víc než tcp/443, které prostě funguje vždy a všude.
Zatímco HTTP/2 je plně zpětně kompatibilní - každý HTTP/2 server dokáže po stejném spojení obsloužit i klienta, co umí jen HTTP/1, HTTP/3 je úplně nový protokol, využívající úplně nový transportní protokol, který ale několika procentům uživatelů nebude fungovat. Otázka zní, jestli to bude stát provozovatelům webů za to. Já si myslím, že to bude podobné jako s IPv6, tedy velká bída.
Ještě horší to pak bude s případnými dalšími protokoly stavějícími na QUIC. I když budou jednoduché a efektivně pracující s proudy, budou muset stejně mít nějakou záložní variantu pro sítě, kde nic jiného než TCP nefunguje.
-
Nevidím důvod, proč by to nemělo být stejné: weby implementující QUIC samozřejmě fungují i přes HTTP 1 nebo 2, právě proto si nikdo (kromě těch, kdo se o to zajímají) nemusel vůbec všimnout, že QUIC už se v tichosti pár let používá. Proč by to po standardizaci HTTP/3 mělo být jinak?
Otázka zní, jestli to bude stát provozovatelům webů za to. Já si myslím, že to bude podobné jako s IPv6, tedy velká bída.
Jen pro pořádek: velká většina velkých webů už samozřejmě přes IPv6 dostupná je, takže to nebyl dobrý příklad. Tam je problém úplně někde jinde než na straně provozovatelů webů.
Díval jste se na ty statistiky? Už před rokem šlo přes QUIC 35 procent odchozího provozu Google (všech služeb, tj. včetně Youtube). Od té doby podíl Chrome ještě o něco vzrostl a podporu QUIC nabízejí i nové verze Opery, takže dnes to číslo bude ještě větší. To už je hodně silná motivace pro další poskytovatele webových služeb, zejména těch, kteří streamují video. Třeba u Akamai zákazníkům podporu QUIC pro multimediální služby nabízejí od března 2018, od října pak i pro další.
Takže ne, nebavíme se tu o nějakém obskurním protokolu s minimální podporou na obou stranách. Ne že bych z toho měl zrovna radost, ale nemůžu zavírat oči před tím, že QUIC už vstupní bariéru dávno překročil.
využívající úplně nový transportní protokol
Proč to pořád opakujete, když moc dobře víte, že to není pravda? UDP není "úplně nový transportní protokol". UDP je více než 38 let starý transportní protokol.
-
Ondřej CaletkaZlatý podporovatel
>Proč by to po standardizaci HTTP/3 mělo být jinak?
Myslím, že za tím může být strach lákat si do sítě velké množství UDP provozu, což operátoři úplně nemají rádi.
>Jen pro pořádek: velká většina velkých webů už samozřejmě přes IPv6 dostupná je, takže to nebyl dobrý příklad.
Polemizoval bych s tou velkou většinou - z Alexa top 10 má IPv6 5-6 webů, z top 20 pak 7-9 webů. To je tak maximálně mírná většina: http://www.delong.com/ipv6_alexa500.html
Já si naopak myslím, že je to velmi přiléhavá analogie. QUIC, stejně jako IPv6, spousta webů má nasazeno, ale když ho vypnou, nic se nestane a skoro nikdo si toho nevšimne. Takže se QUIC může zařadit po boku IPv6 do kategorie technologií, které nasadíme, až budeme mít všechny ostatní problémy vyřešené a nebudeme mít do čeho píchnout.
Pro hodnocení užitečnosti zavedení QUIC, stejně jako pro hodnocení užitečnosti zavedení IPv6, jsou statistiky objemu provozu irelevantní. Relevantní je pouze metrika určující, o kolik je horší zákaznický zážitek kvůli tomu, že dané technologie nejsou zprovozněny.
>> využívající úplně nový transportní protokol
> Proč to pořád opakujete, když moc dobře víte, že to není pravda? UDP není "úplně nový transportní protokol". UDP je více než 38 let starý transportní protokol.HTTP/3 běží nad úplně novým transportním protokolem QUIC. Využívá jeho unikátní vlastnosti a proto nemůže běžet nad ničím jiným. Teprve QUIC běží nad 38 let starým transportním protokolem UDP. I ten je ale pro webhostery zcela nový, doteď s ním nepracovali a nejspíše dosud neumějí zmírňovat útoky jím vedené. Nebo si to jen myslí a bojí se neznámého. Opět hezká analogie s IPv6, což je pro spoustu lidí taky zcela nový, tentokrát síťový protokol, kterého se bojí.
-
"Proč by to po standardizaci HTTP/3 mělo být jinak?" -- Myslím, že za tím může být strach lákat si do sítě velké množství UDP provozu, což operátoři úplně nemají rádi.
Přečtěte si, prosím, co předchází otázce, kterou jste citoval. Ptal jsem se, proč automaticky předpokládáte, že weby poskytující HTTP/3 budou HTTP/3 only, když je podle mne naopak logické očekávat, že naopak budou obsah poskytovat i přes HTTP/2 a HTTP/1, jako to ostatně už pár let dělají weby nabízející (i) QUIC.
QUIC, stejně jako IPv6, spousta webů má nasazeno, ale když ho vypnou, nic se nestane a skoro nikdo si toho nevšimne.
Kdyby to bylo tak, že si toho nikdo nevšimne, proč by Google nasazoval tolik prostředků do vývoje a nasazení do praxe? Proč by se přidávali ostatní včetně Akamai, tj. jedničky na trhu CDN? Já bych řekl že právě proto, že tam nějaký rozdíl bude - a jak ostatně uvádějí i v těch článcích a prezentacích, je dost velký na to, aby se jim to vyplatilo.
Relevantní je pouze metrika určující, o kolik je horší zákaznický zážitek kvůli tomu, že dané technologie nejsou zprovozněny.
K tomu máte konkrétní čísla i v těch článcích a prezentacích, na které jste dostal odkazy, i v dalších, které si můžete snadno dohledat. Pokud se je ovšem rozhodnete nečíst nebo ignorovat, s tím nic nenadělám.
HTTP/3 běží nad úplně novým transportním protokolem QUIC. ... Teprve QUIC běží nad 38 let starým transportním protokolem UDP.
Takže jen chaos v terminologii.
-
Pokud to implementuje třeba Nginx, pak by to pro provozovatele – podobně jako spdy – mohlo být otázkou jednoho flagu v konfiguráku. Pokud to bude v kvalitě, že to prostě pojede (tzn. fallbacky v prohlížečích pojedou dobře – což ale už dnes testuje Google se svou variantou QUIC), pak věřím, že to budou správci zapínat v nezanedbatelném množství.
Nesouhlasím s předpokladem, že to pomůže tak akorát chudým zákazníkům, kvůli kterým se provozovatelé nepřetrhnou. Kvalita bezdrátového připojení může v praxi různě kolísat, nezávisle na příjmové skupině. Viděl jsem i různé kolísání v bytě, kde se může Wi-Fi rušit se sousedovou.
A pokud bude implementace v prohlížečích (což je asi reálnější předpoklad než IPv6 u dostatečného množství ISP), nevidím, co by postupnému nasazení HTTP/3 bránilo. (Neříkám, že hned půjde 100 % provozu přes HTTP/3, ale desítky procent během pár let jsou reálné.)
Srovnání s IPv6 nesedí ani jinak: Pokud se ke mě všichni dostanou přes IPv4 a prakticky nikdo nemá IPv6-only připojení, co komu přinese IPv6? Bude to rycheljší, bezpečnější, či jinak kvalitnější? Asi ne. Oproti tomu HTTP/3 přichází s jasnou motivací – výkon.
