Hlavní navigace

Vlákno názorů ke zprávičce Chrome / Chromium 103 přináší API Local Font Access od Filip Jirsák - HTTP/2 PUSH se zavrhlo, že to prý prohlížeče...

  • Aktualita je stará, nové názory již nelze přidávat.
  • 23. 6. 2022 9:19

    Filip Jirsák

    HTTP/2 PUSH se zavrhlo, že to prý prohlížeče neumí používat. Tak se vymyslí HTTP status 103, který se má použít k tomu samému, jako PUSH, akorát je to podstatně omezenější. Zdá se, že tady jde vývoj také po spirále, akorát s každou otáčkou je to horší a horší.

  • 23. 6. 2022 21:49

    L.

    Ano, to je zdroj dokazující, že nemáš pravdu. Díky ;-)

    Abych to rozebral:

    1) HTTP PUSH nebyl zavržen proto, že by ho prohlížeče "neuměly používat". Oni to uměly. Neuměly ho používat servery / uživatelé. (Část "Motivation" krom posledního odstavce.)

    2) Druhým argumentem bylo, že jeho implementace v prohlížeči je poměrně komplikovaná a nákladní na údržbu, což je u nepoužívané featury docela nepříjemné. (Poslední odstavec části "Motivation")

    3) V tom postu autor doporučuje jako lepší řešení používat <link rel="preload" />.Tedy přesně to, co dělají ty Early hints a o čem ty tvrdíš, že je to horší. (Část "Alternative implementation suggestion for web developers")

  • 24. 6. 2022 0:22

    Filip Jirsák

    Chrome HTTP PUSH neumí používat, údajně z důvodu, že je to implementačně náročné a nákladné na údržbu. Chrome je prohlížeč. Jestli by to servery používaly správně nebylo možné zjistit, protože to Chrome zařízl dřív, než by mohly vzniknout implementace v serverových aplikacích. Ono totiž nemá smysl implementovat to dřív, než to podporují prohlížeče. Pak se to začne používat experimentálně v malých instalacích – a pak už to Chrome zařízl.

    <link rel="preload" /> je horší řešení, protože funguje jenom pro HTML; čeká se do doby, než se příslušná část rozparsuje; server musí modifikovat HTML, když to chce použít; lze to použít pouze na začátku stránky; nelze poslat další informace, na základě kterých by se prohlížeč rozhodl, zda zdroj potřebuje; nelze jednotlivé požadavky prioritizovat. Early hints řeší první tři body, ale neřeší zbytek. Hlavní problém je v tom, že řízení přenosu se ze serveru přenáší na klienta, který ale vůbec netuší, která data má server k dispozici a může je posílat. Takže server čeká na data z databáze a mohl by mezi tím začít posílat styly, ale prohlížeč rozhodne, že je lepší nestahovat nic, počkat si na HTML a teprve pak začít posílat styly. Pak server dostane data z databáze a mohl by začít posílat HTML, ale prohlížeč se rozhodne, že místo toho raději bude stahovat obrázek, který se stejně bude moci zobrazit až po té, co dorazí to HTML.

  • 24. 6. 2022 7:47

    L.

    Píšeš hrozný bláboly. Stává se ti to často?

    V době, kdy se HTTP PUSH zavrhl ho Chrome používat uměl. Neuměly ho používat servery. Ve standardu byl pět let. Třeba Nginx ho uměl od začátku 2018, Chrome zhruba stejně dlouho. Tedy dva a půl roku to lidi mohli používal. Nepoužívali.

    Zbytek je takový zmatek, že se v tom nedá pořádně vyznat, co vlastně tvrdíš. Každopádně:

    1) Early hints se dají používat i mimo HTML, stačí, aby klient uměl interpretovat <link /> z té 103 odpovědi. Ten ale klidně může vést třeba na JSON a hlavní odpověď serveru po hintech bude taky JSON.

    2) Ty early hints se posílají právě proto, aby klient věděl, jaká data bude potřebovat a mohl si je stáhnout předem. V drtivé většině případů jsou to statické soubory, které má server k dispozici jaksi pořád, ale i kdyby nebyly, tak prohlížeč prostě pošle request a až to bude, tak to bude.

    3) Zdá se mi to, nebo opravdu netušíš, že jak klient tak server umí vyřizovat požadavky paralelně? Protože jinak nevím, jak si vykládat "místo toho [HTML] raději bude stahovat obrázek".

  • 24. 6. 2022 10:03

    Filip Jirsák

    Jako bláboly vám to připadá proto, že netušíte nic o těch technologiích.

    HTTP PUSH není určen pro server servírující statický obsah nebo proxy, ale aplikační server. Ten totiž doopravdy ví, co bude prohlížeč v následující chvíli potřebovat. Nginx to v drtivé většině případů vědět nemůže, protože vidí jenom data, která mu poslal aplikační server, ale neví, co bude dál. Takže nginx se tu budoucí potřebu dozví až těsně před tím, než se to dozví prohlížeč (kdyby nginx analyzoval procházející komunikaci).

    Na to, aby se to začalo reálně na internetu používat, by bylo potřeba, aby se to naučily redakční systémy, JAMstack generátory apod. Ty zase potřebují, aby to uměl jejich middleware – Express, Netlify/Vercel apod. A ty zase většinou potřebují, aby to uměl proxy server, který reálně komunikuje s prohlížečem. Takže to, že to uměl nginx, bylo v pořádku. Ale neznamenalo to, že se to začne objevovat na internetu. Znamenalo to, že se to může implementovat do druhé vrstvy softwaru, a až to bude v ní, začne se to implementovat do třetí vrstvy – a teprve pak se to může začít implementovat do koncových aplikací a nasazovat na internetu. A tohle prostě nějakou dobu trvá – kdyby se stejně kriticky přistupovalo k HTTP/2, musela by se dávno zaříznout i podpora HTTP/2 (a tam přitom k tomu, aby to bylo vidět na internetu, stačilo implementovat jen jednu vrstvu, tedy nginx a podobné).

    Ad 1) Ano, psal jsem, že tohle nešlo použít, když se preload informace předávaly v HTML elementu link, s Early hints už to jde.

    Ad 2) Ano, a přesně k tomu samému se dalo použít i HTTP PUSH. Jenže HTTP PUSH se dalo použít třeba také v případě, že redakčnímu systému konečně přišla odpověď z databáze, jaké články se mají zobrazit, a on tak mohl prohlížeči nabídnout obrázky k článkům, které bude potřebovat. To s Early hints nejde, protože ty se posílají na začátku přenosu.

    Ad 3) Na rozdíl od vás tuším, že tohle celé přednačítání se dělá proto, že linka mezi prohlížečem a serverem není nekonečně tlustá. Takže když server tlačí linkou HTML maximální rychlostí, nemůže vedle toho ještě posílat obrázek, ani když klient i server chtějí.

    Tohle je úplně stejný princip, jako když QoS na lince (omezování šířky pásma) děláte až za úzkým místem. Ano, jde to, často je lepší, než když QoS nemáte vůbec a máte problematický provoz. Ale pořád je daleko lepší ten provoz řídit před tím úzkým hrdlem. Protože tam víte, co všechno se snažíte tím úzkým hrdlem procpat a můžete to seřadit tak, aby byl výsledek co nejlepší.

    A tohle je přesně to, co může dělat webový server ale ne prohlížeč. Protože server ví, že teď ještě nemá data z databáze pro HTML, tak mezi tím může posílat CSS. Pak data z DB dorazí, tak pozastaví zasílání CSS a maximální rychlostí odešle HTML. Prohlížeč tyhle informace nemá, neví, že teď bude server čekat na nějaký zdroj a teď už data má a může začít posílat HTML, které je důležitější než CSS nebo obrázek.