Vlákno názorů k článku HTTP/3 nebude postavené na TCP, základem bude QUIC používající UDP od pajac - Fundamentalni problem QUICu je, ktery sebedumyslnejsi implementace nevyresi,...
-
pajac (neregistrovaný)
Fundamentalni problem QUICu je, ktery sebedumyslnejsi implementace nevyresi, ze funguje az na aplikacni vrstve.
Pro vsechna zarizeni, pres ktera jeho data potecou, to budou jen a pouze UDP pakety se vsemi slabostmi a omezenimi tohoto internetoveho protokolu. K tomu neni potreba uz co dodavat.. -
Filip JirsákStříbrný podporovatelOna taky všechna ta zařízení, přes která ta data tečou, nemají dělat nic jiného, než je předat dál. Do obsahu těch paktů jim nic není (navíc je šifrovaný).
-
kraxna (neregistrovaný)
To je asi jako rict, ze fundamentalni problem HTTP 1.1 je to, ze pro vsechny zarizeni na cest jsou to jenom IP pakety se vsemi slabostmi a omezenimi :-)
Data jsou sifrovana, binarni, necitelna jak v H1 (pokud nekdo neni prasatko), H2, tak v QUIC / HTTP3.
Neni v tom zadny rozdil a hlavne tak je to naprosto v poradku.
-
Anonym (neregistrovaný)
Poslechněte si přednášku na BlackHat2016, UDP je vlastně nejlepší volba. Důvod proč aplikační úroveň je rychlost a jednoduchost nasazení. Na síťové vrstvě nasazujeme IPv6 dekádu (za chvíli dvě), plná závislost na mrtě výrobců, kolik jich vlastně existuje a je jakkoliv ochotno podporovat legacy zařízení. Na relační vrstvě jste závislý na operačním systému, a záleží tedy na výrobci operačního systému, jak se mu bude chtít nebo také jestli vůbec ještě existuje. Tak relativně nejjednodušší implementace je na aplikační úrovni. Je to čistě ve vašich rukou. "Blbé" UDP staré 40 let zvládne jakékoliv zařízení. Jak říkají v přednášce, odpor k této implementaci je spíše ze zcela jiného filozofického přístupu. Zcela nové a neotřelé řešení. Teď jen záleží, jak se s tím poperem. Co vidím jako zásadní úskalí je složitější inspekce QUIC. Zvláště, pokud se potřebuji dívat, co se mezi klientem a serverem přenáší.
-
S většinou souhlasím, jen to, že odpor je způsoben jinou filosofií a neotřelým přístupem, mi připadá podobně zavádějící, jako když každý, kdo je obviněn z nekalých praktik, prohlásí "V Čechách se holt neodpouští úspěch." IMHO podvědomý odpor odborné veřejnosti pramení spíš z toho, že přejdeme-li v masovém měřítku na řešení typu QUIC, dáváme tím najevo, že jsme rezignovali na snahu neutěšený stav síťové infrastruktury řešit a místo toho problém obejdeme. To aspoň vadí mně (plus ta neprůhlednost, o které jsem se už zmiňovala o které píšete i vy). Chápu ovšem, že většina lidí potřebuje fungovat v rámci Internetu, který tu máme, ne snít o tom, jaký by mohl (měl) být.
-
kraxna (neregistrovaný)
> dáváme tím najevo, že jsme rezignovali na snahu neutěšený stav síťové infrastruktury řešit a místo toho problém obejdeme
Tady by se hodil nejaky link na clanek o adopci IPv6 :-D
Ale tolik stranou, v podstate souhlasim, ale na druhou stranu rici si, ze nejdulezitejsi / nejpouzivanejsi aplikacni protokol, potrebuje (vyuzije) moznosti specialniho transportniho protokolu, ktery je optimalizovany pro jeho potreby, mi neprijde nic divneho.
-
Pro mne třeba nejzajímavější, co jsem si odnesl z té prezentace, na kterou jsem dával odkaz ve svém prvním příspěvku, bylo zjištění, že po 35 letech práce na TCP a vymýšlení sofistikovanějších algoritmů pro congestion control a loss recovery lze dosáhnout lepšího výsledku, když celou komunikaci schovám do UDP a flow control si udělám (end to end) po svém. (Byť samozřejmě přiznávají, že ve skutečnosti většinou používají techniky známé z TCP.) To není moc povzbudivé a IMHO je to zřetelný signál, že s těmi "chytrými" krabičkami po cestě je něco zásadně v nepořádku.
-
kraxna (neregistrovaný)
Popravde, dovolim si nesouhlasit.
Zasadni problem TCP je to, ze si musi domyslet veci, protoze pracuje na ciste transportni vrstve, tedy bez znalosti aplikacni vrstvy, navic jeho urceni je obecne. QUIC ma obrovskou vyhodu, ze neni obecnym protokolem, ale prave protokolem resicim konkretni ulohu pro konkretni aplikacni vrstvu.
Prijde mi to podobna situace, jako kdyz si nechas udelat kuchyn na miru vs koupis skladacku v IKEA. Ta namiru vyuzije kazdy cm prostoru, ktery je k dispozici, tak, jak ty chces / potrebujes. Skladacka jako obecne reseni to z principu udelat nemuze.
-
Matas (neregistrovaný)
Ano, souhlas, pokud se potrebujete podivat co se prenasi mate problem. A v dnesni dobe je pomerne bezne ze kontroluje obsah prenaseny pres HTTPS, zejmena pokud se bavime o korporatnim prostredi. Co se nepodari zkontrolovat na rozhrani site, musi zvladnout ochrana na endpointu.... (o potrebe kontroly ve vsech vrstvach sem psal jiz vyse).
Osobne chapu pohnutky autoru QUICu, jedna z veci ktere mne na nem vadi je ze implementuje/supluje handshake do vrstvy kde nema co delat a trochu tim dela bordel v OSI modelu. Proc se misto cpani hanshake do aplikacni vrstvy nepokusili pouzit treba DTLS se mi nepodarilo rozumne vycist...
