Vlákno názorů k článku HTTP/3 nebude postavené na TCP, základem bude QUIC používající UDP od Cohen - Při vší úctě k IETF mi to nepřijde...
-
Cohen (neregistrovaný)
Při vší úctě k IETF mi to nepřijde jako nejlepší nápad.
V dnešní době panuje masivně trend vše vkládat do HTTPS. Tomu se v podstatě přizpůsobuje každá nová služba, která nechce riskovat problémy s provozem. A spirálou se podle toho chovají správci ve firmách, takže se často stává, že "internet = tcp 80 a 443". Takže potřeba toto celé začít přepisovat na jiné principy, mi přijde minimálně celkem odvážné.
Volba UDP pro účely nového protokolu je jistě velmi výhodná z mnoha důvodů, radost z ní ale nebudou mít firewally, které mají v této oblasti výrazně míň možností hlídat provoz, než v případě TCP.
A v neposlení řadě to bude mít zásadní vliv na globální provoz. Nedávno tu byl článek o BBR a problémech, které by mohl přestavovat z pohledu řízení toku. QUIC může mít ještě mnohem větší dosah a ačkoliv je už určitě z YouTube k dispozici spousta dat z provozu, pochybuji, že to představuje dostatečně různorodou směs použití pro kvalifikovaný odhad všech budoucích rizik.
-
j (neregistrovaný)
Hlavne to ... nemuze fungovat, respektive muze, kdyz to potvrzovani a overovani ze data dorazila, reimplementujes komplet o layer vejs, takze to muze navrhovat leda debil.
UDP ma totiz smysl tam, kde ti ztrata paketu nevadi, a ses ochoten ji vymenit za trochu lepsi latenci, coz neni pripad http. I spousta routeru ti v pripade velky zateze zaccne nejdriv zahazovat udp - jednoduse proto, ze zahozeny tcp se jim obratem vrati v pozadavku na opakovany prenos.
Jinak se cela tahle demence vymejsi predevsim kvuli nesmyslu ala protlacime video pres http.
-
Však o garanci doručení nepřijdete, jen to bude implementovat jiná vrstva. Což sice není hezké, ale: Buď můžeme vymýšlet hezké řešení v podobě „TCP2“ a čekat na jeho implementaci a reálné nasazení v routerech atd., nebo můžeme už dnes použít UDP.
S videem přes HTTP to asi moc nesouvisí. A mimochodem, i u videa záleží, o co přesně jde. Já radši video stáhnu celé.
-
Petr M (neregistrovaný)
Ale PROČ je potřeba nahrazovat fungující a robustní část systému vlastní implementací? PROČ nevyhoví TCP + IPSEC? Tohle neřeší problém, jenom posune limity kapacity o 20% dál a za rok-dva jsme ve stejné žumpě. Zahození paketů na přetížené lince to nezabrání. Jenomže teď pokud mám MTU 1500 a buffer na čtyři pakety, opakuju při zahození max. 6kB, takhle budu hlásit chybu po 10MB a opakovat znova těch 10MB. No dík moc.
Jenom to přinese další bugy v implementacích a v postřezích bezpečnosti se dočteme o CVE na "packet injection" u Chrome...
-
> PROČ nevyhoví TCP + IPSEC?
TCP – výkon
IPSEC – až tak to neznám, ale funguje na jiné vrstvě a řeší ponékud jiný problém. Je to spíše řešení pro VPN než náhrada TLS: https://www.quora.com/In-what-cases-is-TLS-more-useful-than-IPsec-and-vice-versa
> jenom posune limity kapacity o 20% dál a za rok-dva jsme ve stejné žumpě
Nevím, odkud máte ten posun o 20 %, ono to především snižuje latenci u navázání spojení. Kapacitu teoreticky navýšíte jak chcete pomocí dostatečného počtu paralelních linek, latenci tak snadno neobejdete. Rychlost světla je konečná, můžete leda zkracovat dráhu, zpoždění při routování a počet round tripů. O to poslední se snaží právě QUIC.
> Jenomže teď pokud mám MTU 1500 a buffer na čtyři pakety, opakuju při zahození max. 6kB, takhle budu hlásit chybu po 10MB a opakovat znova těch 10MB.
Z čeho odvozujete těch 10 MB?
> Jenom to přinese další bugy v implementacích a v postřezích bezpečnosti se dočteme o CVE na "packet injection" u Chrome...
Bugy to přinést může (jako všechno nové), ale zrovna packet injection by mě s TLS moc netrápilo…
-
Petr M (neregistrovaný)
TCP má jednu krásnou vlastnost, jeho chování při přetížení linky a zahazování paketů. Dokud není potvrzeno doručení dávky, nic se nevysílá.
Kdežto s UDP bez potvrzování bude fikce doručení a prostě se tam UDP pakety s nějakou kadencí sypou. Když začne switch nebo router zahazovat kvůli plné cache, přijímač má timeout třeba 1s a za tu 1s zareaguje, že nic nechodí a pošle žádost o opakování. Mezitím vybleješ 120MB dat do gigové lajny. Při latenci 100ms už opakuješ 130MB - který byly zahozeny. A zase se potká 12 gigových linek na switchi s uplinkem 10G... Nebo ta gigová lajna vleze do 120mbps přípojky. A zase se zahazuje...
Prostě si neumím představit zaručený přenos většího balíku dat bez potvrzování. Linka totiž nemá zaručeno, že data doručí a nedokážu si představit přenos třeba 2048B PKI klíče s MTU 1500 bez garance, že dostanu oba pakety. A já chci obě půlky klíče.
Btw, pokud se ztrácí pakety, problém bude všude. Pokud to jde hladce a máš nějakou cache na straně přijímače, chodí potvrzení nezávisle na datech a potvrzuješ několik paketů zpětně, zbytek se skládá a cachuje podle propustnosti lajny.
Pokud jde o IPSEC, myslím, že by bylo vhodnější. HTTPS zcela nesystémově řeší ověření původu dat a šifrování (dvě nezávislý věci) jedním klíčem různýho typu. pak klíč musí vydávat nějaká CA i v situaci, kdy chci komunikovat v rámci LAN. Pro šifrování komunikace by bylo lepší IPSec s VK webu v DNS. Stáhnu klíč, zašifruju pomocí jejich VK svůj VK, dešifruje jej jenom ten web s pomocí PK a máme šifrovaný tunel. I pro IoT, kde si zařízení vygeneruje svoje klíče a nemusí se autentizovat (je v mé LAN, vím kdo to je).
Autentizace protistrany se teprve dá řešit tím, že ten VK serveru bude podepsaný někým důvěryhodným, ale volitelně. Pro šifrovanou komunikaci bez ověření protistrany stačí HTTP nad TCP nad IPSEC.
-
Ad TCP: je pravda, že dobrá implementace QUIC si tady asi vyžádá nějaké úsilí, ale nemyslím si, že by to nešlo. Ostatně iniciuje to Google, ne nějaká garážovka. A jakmile budou knihovny…
Nebo máte nějaký důvod předpokládat, že se to bude chovat takto hloupě?
Ad IPSEC: Ono to na první pohled vypadá možná jako správná cesta, ale je to komplikovanější. HTTPS pracuje s hostname, což na úrovni IPsec asi nemáte.
-
Karel (neregistrovaný)
QUIC ale packety potvrzuje. V tom funguje stejně jako TCP. Odesilatel, stejně jako příjemce, má paměť jen na X packetů. Dokud nepřijde potvrzení přijetí, tak se další nepošlou. Je to trochu složitější, protože v rámci jednoho spojení může být více streamů. Takže ztracený packet zablokuje jen jeden stream a ostatní (pokud tam nějaké ostatní jsou) mohou přenášet data dál.
Nepleťte si UDP a QUIC. QUIC garantuje doručení ve správném pořadí.
-
Adam KaliszStříbrný podporovatelVtipné je, že snížit latenci by se asi nejvíce "vyplatilo" změnou vlnovodů/ optických vodičů na mikrorourky. Světlo se vzduchem šíří oproti křemennému sklu asi 40-50% rychleji -> právě jste zkrátil latenci na skoro polovinu. Myslím, že na transatlantické kabely by to bylo zajímavé a jistý výzkum v tomto směru je...
Samozřejmě práce na přenosové nebo aplikační vrstvě je taky dobrá, ale ono to nakonec dopadne tak, že monopol Google a pár dalších větších hráčů budou mít technologicky tak trochu svůj internet s IPv6, QUIC a HTTP/3 a BGPSec atp. a ti ostatní (firmy v jiné branži, velkopodniky) pojedou vesele na CGNAT IPv4, TCP, HTTP 1.1 a občas TLS 1.2 max.
Doufám, že internet zůstane technologicky více homogenní, ale realita nejspíše bude jiná.
-
Jestli rychlost je o 50 % vyšší, pak to znamená zkrácení latence na dvě třetiny.
A hlavně, jsou to dvě nezávislé věci. Jestli to můž2te zrychlit lepším médiem, proč ne. Jestli to můžete zrychlit lepším protokolem, taky dobře. Bude-li to úsilí stát za to, klidně vyměňme obojí. Otázkou je snadnost nasazení (např. software se mění lépe než hardware + z pozice Googlu je ten rozdíl ještě větší).
(V přenosových médiích se nevyznám a jen slepě předpokládám, že by šlo o zlepšení bez negativních dopadů…)
-
mik (neregistrovaný)
Toto je omyl aj v samotnom clanku, ze hlavny dovod QUIC, je dlzka nadviazania spojenia.
Hlavny problem HTTP/2 je head-of-line blocking. Pretoze HTTP/2 ma v sebe niekolko paralelnych streamov tak by bolo pekne aby boli nezavisle, co nie su, lebo idu v jednom TCP streame. Cize strata/zdrzanie jedineho paketu sposobi zdrzanie vsetkych streamov. Tento problem pri HTTP/1.1 neexistoval, alebo bol aspon ovela menej viditelny.
Cim nechcem povedat ze pome naspat k HTTP/1.1!!!
Samozrejme, znizit pocet paketov na nadviazanie spojenia je vzdy pekne, ale pretoze user agent by mal nadvazovat HTTP/2 spojenia, ktore su na viacero requestov + mame 0-RTT v TLS1.3 tak prinos znizenia poctu round tripov je marginalny.
-
>> Hlavny problem HTTP/2 je head-of-line blocking. Pretoze HTTP/2 ma v sebe niekolko paralelnych streamov tak by bolo pekne aby boli nezavisle, co nie su, lebo idu v jednom TCP streame. Cize strata/zdrzanie jedineho paketu sposobi zdrzanie vsetkych streamov. Tento problem pri HTTP/1.1 neexistoval, alebo bol aspon ovela menej viditelny.
No a to by nestačilo, aby browser navázal několik spojení? Takový hybrid mezi mezi http/1.1 a http/2... Nemůžu si pomoct, mě vývoj nového protokolu přijde spíš jako obchodně-politický tah.
-
kraxna (neregistrovaný)
Vic spojeni.= vickrat resit cele TLS, handshake, ...
Je to zbytecne, proto je jednodussi pouzit spojeni jedno nad UDP a QUIC uz si to osetri sam.A hlavne, tohle neni zadna novinka boha jeho. 35 % veskereho mobilniho trafficu v USA je pomoci QUIC.
A zadne problemy se nekonaji, naopak. -
Dobrá poznámka.
Co jsem se díval na specifikaci TLS 1.3, vypadá to, že i TLS je na nějaké vynechání paketu připraveno – není-li kompletní record, nebrání to čtení dalších recordů. (Neúplný record by teoreticky šlo číst, ale nezkontrolujeme mu integritu…) Ale nejspíš QUIC musí mít nějaké požadavky ne dělení do recordů, jinak může být problém správně pokračovat…
-
Petr M (neregistrovaný)
V tom případě by to dávalo smysl, ale furt je to další srovnávák rovnáku na ohybák.
Primárně problém vznikl tak, že se místo jednoho html, několika obrázků a stylu začalo přenášet kikilión zbytečností navíc. Přitom co ten web <b>doopravdy</b> potřebuje?
Tracking uživatele obrázkama 1x1px, kvůli kterýmu se navazuje extra spojení a stahuje se soubor? To přece server tak jako tak vidí - stránku, kterou posílá, ví a session ID taky.
Fonty? To jako vážně osobní blog Buhumila Františka Ujetýho s pěti návštěvama ročně, nepočítáme-li autora, musí mít stejný font na Widlích i na Macu? Default systémový písmo nestačí? Pryč s tím, pokud není racionální důvod.
Hi res obrázky, který škáluješ na místě? Co kdyby prostě HTTP server dostal info "mám k dispozici rozlišení X x Y", vyrenderoval stránku a hotovo? Klidně může vygenerovaný prvky s konkrétním rozlišením hodit do lokální cache, pokud chce šetřit výkon.
Skripty pro G, FB, LinkedIn, ... stahovaný automaticky a bez souhlasu autora i tam, kde provoozovatel webu v OOP garantuje soukromí návštěvníka? To přece ani není legální, pryč s tím!
Pak se zjistí, že v reálu se stahuje pět souborů + nějaká reklama. Pokud pro reklamu bude extra stream s nějakým kontejnerem, 6x TCP už tak nebolí. Prostě řešit problémy by měli v rámci stávajícího standardu a až to nejde, hledat teprve jinou cestu.
-
A vážně to nějak ovlivní přenos velkých souborů (např. toho videa), kde se jednou naváže spojení (DNS, TCP, TLS, ...) a pak se přenáší proud obsahující velký objem dat?
Většina těch snah mi přijde namířená spíš na scénáře, kde je velký počet malých souborů a kde se cílí na minimalizaci latence. Ale když si pouštím video, tak je mi celkem jedno, jestli začne hned nebo za dvě vteřiny, protože má třeba dvacet minut nebo dvě hodiny -- a když už se tomu rozhodnu věnovat tolik času, nějaká ta režie na začátku je nepodstatná. A pokud to video za něco stojí, tak si ho stejně spíš stáhnu k sobě na disk, abych nebyl závislý na tom, zda ho někdo na serveru milostivě nechá.
Pokud jde o krátká videa, to budou právě většinou ty spamy, reklamy... Nebo to má být kvůli živým přenosům? Tam ale stejně nějaké latence jsou (komprese videa atd.). A hlavně mi většinou přijde vhodnější asynchronní způsob komunikace -- nevyžaduje, aby autor informace byl připojen ve stejnou dobu jako její příjemce.
-
Pokud zminujete banky, tak si clovek taky musi uvedomit, co se z jeho requestem opravdu deje. Ono totiz TCP vs UDP je analogicky stejne jako globalni transakce vs even sourcing. Globalni transakce vzdy byly problematicke, ale ok, na konci clovek vedel, ze co prislo je vyrizeno a zapsano vsude kde ma. To je pripad TCP, ale spousta nejenom bank prechazi/preslo na event driven architektury, resp. event sourcing, tj. eventualni konzistenci dat. Ma to svoje challenges, ale je to plne non-blocking (z vlastni perspecktivy, blocking tam prinasi protokoly typu http, apod.), takze super, ze se toho zbavime.
-
sasaQ (neregistrovaný)
tak sup zpatky do skoly a nastudovat rozdil mezi transportni a aplikacni vrstvou. aby z quicu nemeli radost middleboxy je zamer. a volba congestion control zavisi na servru a ten se rohoduje podle toho kam data posila. v clanku chybi uvaha o rychlosti adaptace zmen toho, co je v kernelu/user space. a ze se autor nezminil o early data je taky velky spatny.
ČLÁNKY DO MAILU