Přiznám se, že jsem od minulého článku pořád úplně nepochopil ten server push. Ano, je hezké, že klient může serveru říct, které soubory mu nemá posílat, ale přiznám se, že mi pořád není úplně jasná strategie, pořád nějak nedokážu přijít na to, jak může klient už při prvním požadavku na načtení stránky sdělit serveru, které soubory mu nemá posílat.
krok 1) klient požádá o soubor (v tuto chvíli klient neví, které další soubory bude stránka potřebovat),
krok 2) server pošle soubor a k němu mu přibalí dáreček v podobě dalších souborů,
krok 3) klient parsuje soubor a teprve teď může zjistit, které soubory bude potřebovat a zjistit, jestli už jejich verzi nemá ve vyrovnávací paměti,
krok 4) klient zjistí, že některé soubory už ve vyrovnávací paměti a tedy že je není nutné posílat, tak začne odesílat požadavek na zrušení přenosu těchto přibalených souborů.
A teď moje nejasnosti:
- existuje nějaký způsob, jak může klient už při prvním požadavku zjistit, které soubory související s dotazovaným souborem nebude potřebovat? Pokud ano, jaký?
- začne server odesílat dárečkové soubory navíc okamžitě po ukončení přenosu požadovaného souboru? (tj. v okamžiku, kdy klient teprve provádí parsování přijatého souboru)
- co se stane v okamžiku, kdy server nebude respektovat požadavek na ukončení dárečkového souboru?
Server samozřejmě nebude klientovi posílat nějaké náhodné soubory, ale pošle mu ty, které bude potřebovat pro danou stránku.
Takže krok 3 je jinak – klient parsuje soubor a teprve teď by s HTTP/1.1 zjistil, které soubory bude potřebovat. Server to ale ví také, takže mu je poslal už předem.
zjistit, jestli už jejich verzi nemá ve vyrovnávací paměti
K tomuhle ale prohlížeč nepotřebuje stránku rozparsovat – nějaké soubory už mu nabídl server, a to, zda tyto soubory (v aktuální verzi) má v cache zjistí prohlížeč rovnou ze seznamu objektů cache, tu stránku k tomu vůbec nepotřebuje.
existuje nějaký způsob, jak může klient už při prvním požadavku zjistit, které soubory související s dotazovaným souborem nebude potřebovat? Pokud ano, jaký?
Při požadavku to nezjistí. S odpovědí na požadavek mu ale server nějaké soubory nabídne, klient se podívá do cache, a pokud už v ní tuhle verzi souboru má, odmítne tu nabídku serveru.
začne server odesílat dárečkové soubory navíc okamžitě po ukončení přenosu požadovaného souboru
Záleží to na prioritách, které mají ty jednotlivé soubory nastavené. Obvykle ten první soubor (HTML stránka) bude mít vyšší prioritu, takže se bude odesílat, dokud to jde, a teprve pak ty ostatní soubory. Pokud tedy půjde třeba o statickou HTML stránku, odešle se nejprve celá ta stránka a pak se hned začne s odesíláním dalších souborů (není důvod čekat). Může ale nastat i případ, že se ty další soubory začnou odesílat dřív, než se odešle celý ten první soubor – třeba je to generovaná stránka a bude se čekat na odpověď od databáze. Není důvod, aby v tu chvíli server klientovi nic neodesílal, takže začne odesílat některý z dodatečných souborů. Když pak dorazí data z databáze a vygeneruje se další kus té první HTML stránky, pozastaví se odesílání těch ostatních souborů a bude se pokračovat v odesílání té první (prioritnější) HTML stránky.
co se stane v okamžiku, kdy server nebude respektovat požadavek na ukončení dárečkového souboru?
Je to chyba implementace protokolu, klient se zachová úplně stejně, jako kdyby server nerespektoval požadavek na ukončení streamu, o který požádal klient – bude ignorovat pakety ze streamu, který je uzavřený. Pokud by klient bezpečně zjistil, že server odesílá data i po té, co dostal zprávu o resetu streamu (což je něco jiného, než že klient po resetu ještě nějaká data dostal – ta mohla být na cestě už před tím, než klient stream resetoval), mohl by asi serveru ohlásit chybu protokolu a uzavřít spojení.
A co brání serveru, aby k těm přidaným souborům přibalil dáreček úplně navíc? Klient něco takového v cache nemá a že tento dárečen není potřeba, zjistí až po rozparsování stránky.
Jenom si dovolím poznamenat, že v době generování dynamické stránky bude server obtížně posílat odpovědi v době čekání na databázi, protože kód stránky pro něj v daném okamžiku nemusí být přístupný a těžko tedy bude zkoumat její obsah - jedině, že by nastoupila predikce.
He? A proč by to server vůbec dělal? K čemu by něco takového bylo i nějaké hodně pochybné stránce? Dárečkem, co se přenese za rozumný čas, se ani to místo na disku zabrat pořádně nedá.
Proč by server neměl vědět, co má poslat? Vždyť tu stránku generuje např. nějaký php script. Takže na začátku scriptu se naplánuje přenos souborů, které ta stránka potřebuje, pak se může čekat na DB a mezitím se v jiném vlákně přenášejí ty csska a obrázky.
Proč klientovi. To je seznam souborů, které má server poslat klientovi hned aby nemusel čekat až klient _taky_ zjistí že ty soubory potřebuje a řekne si o ně.
Příklad s reálného života HTTP 1.1 :
Napíšu úřadu o formulář 15a. Úřad pošle formulář 15a. Na něm je napsané že potřebuju ještě formulář 25e. Napíšu si o formulář 25e. Na něm je, že potřebuju ...
s HTTP/2 :
Napíšu úřadu o formulář 15a. Úřad mi pošle formulář 15a a do obálky přiloží i 25e a další.
Taky příklad z reálného života: Na daňové přiznání potřebuju formulář, nazvěme ho "FA" a v některých situacích někdo bude potřebovat fiormulář "FB" a někdo jiný v jiné situaci bude potřebovat formulář "FC". Tedy "FA" je potřeba vždy a formuláře "FB" a "FC" je někdy, přičemž někdy jsou potřeba oba současně a někdy je potřeba jenom jeden z nich.
Co na to HTTP/2?
Boze ... jak v matersky. Dokud ta stranka neni na strane serveru kompletni, tak srv nemuze mit ani paru o tom, co vse je jeji soucasti. Tak maximalne muze nekde nekdo prohlasit, ze soucasti je nejaky css, ale jaky tam sou obrazky vubec netusi. A pokud se stylopis generuje taky, tak netusi ani ten.
Takze vysledkem bude zhruba to, ze misto aby srv poslal browseru html stranku, tak ji bude jeste sam parsovat aby zjistil, co k ni ma jeste pribalit ... lol.
Proč parsovat proboha? Vždyť server ví z čeho tu stránku poskládal. Tu stránku na serveru _generuje_ nějaký script. Ten script ví jaké obrázky/styly/whatever ta stránka má obsahovat a podle toho do té stránky při generování vkládá jejich jména. Takže navrch k vložení jména obrázku do stránky i okamžitě začne ten obrázek přenášet ke klientovi.
Jiste, tvle tys nebyl na netu uz nejmin 10 let, ze?
Vis jak vypada typickej soudobej web? Ze se ptam, netusis ... takovej stredne zmrvenej web se sklada ze zdroju z minimalne 5ti ruznych domen a o 1/2 toho co se zobrazi rozhoduje js.
O druhy pulce pak to, jak moc velkej paranoik je user. A v okamziku, kdy useri zjistej, ze jim servery tlacej hromady sragor, ktery stejne videt nechtej, tak budou vsechny browsery at uz z vyroby nebo pomoci pluginu tuhle uzasnou funcionalitu aktivne blokovat.
O tom, ze uz ted je bezny, ze k webu je nalinkovanejch klidne i par MB js/css/... a dalsich hovadin z cehoz se realne pouzije tak 10% ani nemluve.
Jenom si dovolím poznamenat, že v případě statických HTML stránek server nic o obsahu stránky bez parsování vědět nemůže. Pokud budu mít klasické JavaScriptové zobrazovadlo, tak jsem dokonce v situaci, že serveru nemá šanci pomoct ani statistika, a klient nemá šanci odmítnout soubory, které mu server pošle nadbytečně, protože ani sám klient netuší, které to vůbec budou (leda, že by si prováděl "předparsování" skriptu).
Ale co by se mi líbilo, kdyby si ten server předtahal vnořené stránky a soubory z jiných serverů, na které se stahovaná stránka odkazuje, a pak je pushoval klientovi :-)
Technicky v tom nebrání serveru nic, ale byl by to nesmysl, server by pouze spotřebovával prostředky na zbytečnou věc. Bylo by to stejně nesmyslné, jako přidat do HTML stránky nebo skriptu spousty dlouhých komentářů.
Zatím jsem neslyšel o implementaci server push takovým způsobem, že by server zkoumal obsah odpovědi a teprve podle toho navrhoval, které soubory nabídne. Vždy se o tom uvažuje takovým způsobem, že server pro daný požadavek má už sestavený seznam souborů, které k němu má přibalit. Ten seznam je možné připravit ručně, může ho připravit třeba redakční systém (všechny potřebné údaje typicky má k dispozici), nebo třeba Jetty má implementováno to, že sleduje referery a podle nich si sestaví seznam souborů, které prohlížeč typicky požaduje po načtení nějaké adresy (není to dokonalé, ale funguje to úplně nezávisle na odesílaných datech, server jim vůbec nemusí rozumět).