Chrome zapíná všem podporu HTTP/3

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.

Komu 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.

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).

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í.

žádný protokol není hotový, dokud není mrtvý

Žá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í.

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.

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.

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

Vazne ma desi, ako si google pretlaci do internetu to co chce len pre to ze moze. A doplacaju na to vsetci ostatni.