Názory k článku
Chrome zapíná všem podporu HTTP/3
-
J ouda (neregistrovaný)
Tak jen budu doufat, že oproti minulému pokusu před pár lety poněkud domluvili congestion control algoritmu aby nebyl tak agresivní.
Si až moc dobře pamatuji že tehdy dvě zařízení s youtubem v celkem malém rozlišení na domácí síti přípojení přes wifi způsobily všemu ostatnímu cca 15% packet loss kterému učinilo přítrž až upd/443 do REJECTu (a pohledem na tcpdump bylo jasné že to posílalo v dávkách které na providerově straně prostě přetekly buffer a, v rozporu se specifikací, se tvrdošíjně vracely po pár sekundách pořád dokola k velkým dávkám) -
Dost se mi nelíbí ten nešvar co se nám tu poslední dobou rozmohl a to nasazování nehotových protokolů. Jak je zmíněno v článku i sám Google používá dvě (nekompatibilní) verze. Koncovému uživateli je to asi jedno, protože "Chrome si to stejně nějak dohodne", ale co chudáci vývojáři, správci a nadšenci.
-
FILIP JIRSÁKStříbrný podporovatelKomu z vývojářů mimo Google to vadí, kterým správcům a nadšencům? Jak konkrétně to kohokoli omezuje?
Naopak je skvělé, že se protokoly před dokončením testují v ostrém provozu, aby se odhalily jejich chyby a nedostatky dřív, než to bude navěky zadrátované ve standardu.
-
FILIP JIRSÁKStříbrný podporovatel
Pokud první spuštění v novém prostředí považujete za testování, pak byste nikdy nic nespustil. Protože před tím, než byste něco na produkci spustil na ostro, byste to musel na produkci otestovat. Ale to se nesmí.
Za skvělý nápad považuju něco otestovat v reálném světě před tím, než se na to nalepí nálepka, že je to finální standard. Jsou totiž dvě možné situace. Buď se to při testování osvědčilo a ta nálepka se nalepí na to samé, co se před tím testovalo. Podle vás se ta testovaná věc nějak zázračně zlepší tím, že ji prohlásíme za standard? Asi těžko. Druhá možnost je, že se v reálném světě ukáže, že navržené řešení má nějaké problémy. Pak je ovšem možné je opravit ještě dřív, než vznikne finální standard, který pak implementují všichni. Podle vás by bylo lepší, kdyby ta testovaná verze měla už nálepku finálního standardu a implementovaly by jí všichni? Takže ty problémy by se místo testování na pár serverech týkaly úplně všech?
Ono je totiž potřeba alespoň malinko vědět, jak funguje testování (že to není jednorázová záležitost, ale s tím, jak se produkt dokončuje, zapojuje se do testování víc a víc subjektů a prostředí, kde se to provozuje, jsou stále kritičtější). Opakování větiček zaslechnutých někde na internetu nestačí.
Jen tak pro pobavení, jaký by tedy byl správný postup podle vás? Současnou verzi HTTP over QUIC prohlásit za finální standard HTTP/3? Nebo jak a kde byste ji chtěl dál testovat, aby se postupně dostala do stavu, kdy může být prohlášena za finální verzi standardu?
-
Nemám nic proti testování.
Nelíbí se mi situace, kdy velký subjekt, který dnes víceméně diktuje co se používá nasadí veřejně nehotovou věc. Vytváří to pak jistý dojem, že je hotová. Chytnou se toho pak ostatní a implementují ji tak jak je v draftu, který se může ještě 10x změnit, ale my pak budeme řešit důsledky těch špatných implementací, jelikož ne všichni nasadí změny a opravy (zvláště v SOHO sféře). -
FILIP JIRSÁKStříbrný podporovatel
Přesně stejným způsobem, jakým teď Google nasazuje HTTP/3, se nasazovalo HTTP/2. Stejně se řeší nové věci v HTML5 nebo CSS. Kdy přesně došlo k vámi popisované situaci?
-
třeba zrovna u HTTP/2 alias SPDY od Googlu, různé implementace, různé verze prohlížečů to různě podporující, různé snahy firem to také nějak umět. Důsledek takovéhoto postupu je třeba nefunkční Server Push, kvůli chybné implenentaci na klientech a serverech.
V HTML5 rodině je zase důsledek neustálého proudu novinek snížení konkurence na straně vykreslovacích enginů, většina nezvládla držet krok.
-
FILIP JIRSÁKStříbrný podporovatel
HTTP/2 je přece dávno standardizované, a když se něco implementuje podle standardu, musí to být v pořádku, ne?
Když si mám vybrat mezi dnešním stavem prohlížečů a stavem, kdy dominoval MSIE6 (což je stav před HTML5), beru dnešní stav. Všema dvaceti.
-
J ouda (neregistrovaný)
...deleted zbytečná reakce na ad hominem argumenty které si laskavě nechte od cesty, na to není nikdo zvědavý...
Možná byste si místo nich mohl taky nastudovat standard, zamyslet se kde primárně může být v reálném provozu zakopaný pes (případně to ověřit na reálných příkladech přípojení) a třeba byste zjistil, že případné ladění nemusí znamenat změnu samotné specifikace, ale v konkrétním ladění parametrů. Client i server side. https://quicwg.org/base-drafts/draft-ietf-quic-recovery.htmlad poslední odstavec - třeba tak jak to dělá Firefox s opt-inem. Čemuž by měl předcházet dostatečně rozsáhlý test v labu na prověření nejen nejčastějších, ale i okrajových use cases, který alespoň v minulosti (viz můj příspěvek na začátku) evidentně minimálně v jednom případě neproběhl a/nebo byl naprosto odfláklý.
Ostatně celou absurdnost situace dokreslují dvě různé implementace.
Edit: A jak byste to řešil Vy zavedení nové technologie, pokud byste nebyl technologický gigant, který má kromě arogance k dispozici i několik miliard (ne)dobrovolných testerů?
10. 10. 2020, 21:00 editováno autorem komentáře
-
FILIP JIRSÁKStříbrný podporovatel
Jenom jste zapomněl napsat, jak si představujete to testování na reálných připojeních bez reálných připojení.
Implementace HTTP/3 v Chrome byla rozsáhle testována v labu, pak to bylo opt-in v prohlížeči, pak to bylo defaultně zapnuté v Chromiu, a teď se to postupně zapíná v Chrome. Vaše přání jsou splněna dříve, než je vyslovíte. Škoda, že jste si nepřečetl alespoň druhou větu zprávičky, pod kterou diskutujete.
-
A opravdu takové testování stačí ? Ono dokud jsme přecházeli z HTTP 1.1 na 2.0, tak asi ok ... protože to byly protokoly které neovlivňovaly nic kolem.
Ale teď tu najednou přecházíme z TCP na UDP ... ptal se někdo operátorů, jak se zachovají jejich síťové prvky, pokud jim bude v budoucnu třeba více jak polovina provozu běhat po UDP? Budou fungovat stávající AntiDDOS ochrany ?
11. 10. 2020, 13:36 editováno autorem komentáře
-
FILIP JIRSÁKStříbrný podporovatel
To je právě ten důvod, proč se to zapíná postupně. Operátoři o tom dopředu samozřejmě mohou vědět, pokud se zajímají. Situaci „je potřeba udělat takovéhle změny, připravte se na to a dejte vědět, až budete připraveni“ známe ze zavádění IPv6. To se takhle zavádí už dvacet let, a jsou stále tací operátoři, kteří to neřeší, protože to údajně nikdo nepoužívá. Takže jediná reálná možnost, jak něco nového zavést, je po otestování to pustit v malém do běžného provozu a postupně přidávat.
Mimochodem, antoDDoS ochrana musí především ustát velký objem příchozích paketů. Sledovat v takové situaci každé jednotlivé TCP/IP spojení mi nepřipadá jako dobrý nápad, jak se s tím vypořádat. Takže bych si tipnul, že antiDDoS ochrana bude pracovat spíš na úrovni IP paketů než na úrovni TCP spojení.
-
Testovat na produkci považujete za skvělý nápad?
To není testování. Je hotová specifikace. Po zkušenostech z provozu se nezmění, nebo trochu změní a následně se standardizuje. Tímto způsobem vznikají standardy. Ostatně i na webu většina technologí nejdříve vznikla, někdo je prosadil a pak se kodifikovaly do standardů. Představa, že se dá standard připravit od "rýsovacího prkna" a z laboratoře, je naivní.
-
- - (neregistrovaný)
@Miroslav Šilhavý
Ono spíš bude záležet/záleží na tom, jak se to nasadí do produkce. Obecně, pokud je to napůl dodělané a jediný důvod k nasazení je nějaké datum v manažerském grafu, je to špatně a pak má tady odpůrce pravdu. Pokud je to řádně připraveno, mnohokráte úspěšně otestováno, není důvod plácat o testování v produkci. Ostatně, rozjet novou feature pouze pro určitý segment, doladit a pak uvolnit úplně je běžná praxe a zde je s tím tedy odpůrce naprosto mimo - pravděpodobně proto, protože nezohledňuje reálný stav implementace zatímco pouze žongluje se slovy "testovat" a "produkce".
10. 10. 2020, 21:18 editováno autorem komentáře
-
@87vdf4vg82
Díváte se na to optikou doktríny plánovaného hospodářství. Samozřejmě, lokálně mají firmy, oddělení a lidé své cíle, které musejí plnit. Nicméně, to je samoregulační proces. Přijdete s něčím moc brzy - a pohoříte. Nu což, nic se nestane, přijde někdo jiný s něčím lepším. A tím "lepším" nemyslím, že se to bude víc líbit technikům-odborníkům. Myslím tím, že lepší je ta technologie, která prokáže svoji životaschopnost. (Stalo se nejednou, že se uchytila technicky méně dokonalá norma, ale životaschopnější).
Nevzrušoval bych se tedy z toho, že začali používat HTTP/3. Prostě se uvidí, jaké to bude mít výsledky. Dokonce si myslím, že to sami stáhnou z provozu, kdyby to způsobovalo víc problémů, než užitku. (A ano, na "chudáky" techniky, kteří se musí mentálně vyrovnat s (ne)řízením toku UDP se hledět nebude - ajťáci jsou dnes něco jako popeláři - všichni je potřebují, ale medaile se za to nedávají).
-
@87vdf4vg82
Nepochopil jsem, jakého stavu byste rád dosáhl. Buďto se musí vše řídit centrálně - tj. někdo rozhoduje o specifikacích, dbá na jakost, testování, ... - podobně, jako je tomu třeba u léčiv. Nebo se to nechá volně, pak si rozhoduje trh a standardy se kodifikují až zpětně. Tedy ve chvíli, kdy technologie ukáže svoji účelnost a někomu stojí za to se standardizaci věnovat. Já jsem zastáncem toho druhého způsobu.
-
- - (neregistrovaný)
@Miroslav Šilhavý
Aha. Tak v tom případě nehledejte v mém textu jednu z verzí, kterou si myslíte Vy, ale přečtete si, co si myslím já.
Hint: nemluvím o tom kam co kdo nasazuje a jestli o tom rohod někdo centrálně. Po třetí a naposledy Vám píši, že se zamýšlím nad testem v produkci a odzkoušením i v produkci - ne, to opravdu nema nic společného s centrálním plánováním. Jedná se spíš, po třetí píši, o stav implementace.Pokud nehodláte můj text aspoň jednou přečíst, bude lepší neodpovídat vůbec. Není to Vaše povinnost, já to unesu a ušetři to čas ...
-
Žádný zázračný protokol nezrychlí načítání špatně udělaných stránek, plné zbytečného obsahu a zejména pak velice datově náročných reklam.
Můj názor na HTTP/2 a HTTP/3 je ten, že vyšší komplexita celého řešení nepřináší adekvátní hodnotu. Prostě je to kanón na vrabce.
Napsat rychlé a přitom bohaté stránky nad primitivní "jedničkou" přitom jde i v dnešní době, dokonce i tak, že povýšení na HTTP/2+ se už na zrychlení nijak neprojeví.
-
FILIP JIRSÁKStříbrný podporovatel
Jenomže protokolem HTTP už se dávno nepřenášejí jenom stránky. Přenáší se jím také aplikace, aplikační komunikace, video… Přenos stránek nejspíš už dávno objemově tvoří menšinu přenosu přes HTTP.
-
Aplikační komunikace si právě vystačí s HTTP/1, a pokud ne, stejně potřebuje Websocket. Vím to, protože v tom dělám. Zpravidla si člověk vystačí s jedním spojením s maximálně dvěma, multiplex je kanón na vrabce. Pokud se používá websocket, stejně to jede formou pipelingu, v případě JSONRPC dokonce i na přeskáčku, bez vynuceného multiplexu. A jako provozovatel serveru __nechcete__ aby vám jeden klient posílal informace moc rychle, protože by vám mohl přetížit server. Když mu dáte jedno spojení s očekávanou latenci, je to často dostatečné aby on nepocítil nějaká omezení a vám to neshodilo server, až jich tam takových přijde 100.
Opravdu skutečná režie na přenos aplikačních dat je nula nula nic. Největší latenci dělá samotný server tím, že zpracování požadavku prostě nějaký čas zabere.
na video jsou jiné protokoly.
Nevím, jestli http/2 a /3 řeší websockety, ale i tak je to kanón na vrabce. A když už bych na aplikační úrovni použil UDP rozhraní přímo (i když teď z hlavy nevím jestli něco takového už v JS existuje nebo ne)
-
Největší latenci dělá samotný server tím, že zpracování požadavku prostě nějaký čas zabere.
Však je taky smutné, jak se dnes často programuje. Činnosti, které mají trvat milisekundy, se zpracovávají dlouhé sekundy. Nicméně, používat protokol za tím účelem, aby brzdil přístup do aplikace (aby ta se z toho neopupínkovala) není dobrá cesta.
-
FILIP JIRSÁKStříbrný podporovatel
Vím to, protože v tom dělám.
To ale po vás nikdo nechtěl, abyste se přiznával k tomu, že nerozumíte technologiím, které používáte.Představte si třeba takový GMail, kde se načítá seznamy e-mailů, seznam úkolů a položky kalendáře. Není důvod, aby se to načítalo sériově za sebou, a co dorazí, to se může rovnou zobrazit. Nebo Facebook – načítají se příspěvky na zdi, jejich obrázky, uživatelé v chatu, odkazy, příběhy. Proč by se to mělo načítat za sebou?
Zpravidla si člověk vystačí s jedním spojením s maximálně dvěma
Dvě je divné číslo. Proč ne tři nebo čtyři? Samozřejmě je nejlepší jedno spojení, přidávání dalších spojení vám nic nepřinese, jenom režii.na video jsou jiné protokoly.
Jenže v praxi funguje nejlépe HTTP. Navíc ve webovém prohlížeči moc velký výběr protokolů nemáte.i když teď z hlavy nevím jestli něco takového už v JS existuje nebo ne
No, hlavně že v tom děláte. JavaScript neumí nic, jenom z něj můžete volat různá API poskytovaná prohlížečem. A prohlížeč samozřejmě neposkytuje API pro síťovou komunikaci na úrovni TCP nebo UDP. Umožňuje jen odeslat HTTP požadavek nebo komunikovat přes WebSocket (povýšením HTTP spojení). Trochu bokem je pak ještě WebRTC. -
FILIP JIRSÁKStříbrný podporovatel
Já mám zase za to, že se slušným chováním se neslučuje ani psát: „vím to, protože v tom dělám,“ když to není pravda. V mém světě je součástí slušného chování i pokora. Pokud si je někdo takhle sebejistý a pak píše jeden nesmysl za druhým, asi potřebuje oplatit stejnou mincí, aby vůbec zaznamenal, že je něco špatně.
-
- - (neregistrovaný)
Tak to asi nevíte, co je šlušné chování. "vím to, protože v tom dělám" je tak akorát hloupý argument, nemá to s pravdou nebo neslušností co dělat.
Píšete o pokoře, ale spíš to vypadá, že jediným důvodem je, že kvůli hloupému argumentu okamžitě potřebuje oplácet údajně stejnou mincí - to není pokora a slušné chování už vůbec ne.
12. 10. 2020, 11:56 editováno autorem komentáře
-
Jako vývojář nejmenovaných velkých e-shopů a několika dalších na assety náročných (například VoD) aplikací vám mohu říci jen jediné: na HTTP/2 bylo pozdě už před deseti lety. Obcházet na frontendu neustále omezení HTTP 1.x je opravdu komplikované a otravné.
12. 10. 2020, 10:36 editováno autorem komentáře
ČLÁNKY DO MAILU