Dzisiaj kolejny element HTTP 2.0, tym razem wymagający zmiany kodu po stronie aplikacji. Tak jak już z wszystkimi opisanymi wcześniej zmianami, ma to na celu zmniejszenie opóźnienia (latency) wynikającego z liczby zapytań.

Doskonale wiemy, że każda strona ma referencje do innych zasobów takich jak CSS czy pliki graficzne. Wcześniej zajęliśmy się już HTTP Multiplexing, który znacząco niweluje problem.

W jednym z poprzednich wpisów pokazałem również jak w HTTP 1.1 programiści radzili sobie z zasobami. Częstym obejściem, było umieszczenie plików graficznych inline. Powodowało to, że jak tylko plik HTML lub CSS został ściągnięty, plik graficzny stawał się od razu dostępny (ponieważ był częścią tego samego pliku).

Z tej techniki tak naprawdę wywodzi się Server Push. Wiemy, że w celu wyświetlenia strony “A”, musimy również wysłać zasób “B”. Dlaczego zatem nie wysłać zasobu B od razu zaraz po A? Inline jest pewną implementacją tego, ale jak wiemy dość kłopotliwą. Server push pozwala z kolei, “wepchnąć” dowolny zasób (nie koniecznie plik graficzny) w strumień danych płynący od serwera do klienta. Oczywiście serwer (np. IIS), nie będzie znał relacji w poszczególnych aplikacjach między zasobami. Wynika z tego, że to nasza rola (ewentualnie framework’a)  jest poinformować o tym klienta.

Służą do tego tzw. “Push Promise”, czyli obietnice klienta odnoście relacji między zasobami. Jeśli projektując system wiemy, że wyświetlając stronę A, zaraz będzie załadowana  biblioteka jQuery,  wtedy wydajemy obietnice. Push promise to prosta metoda, która zwraca listę zależności. Przeglądarka następnie przeczyta taką listę obietnic i stwierdzi czy warto je akceptować. Czasami te zasoby mogą już znajdować się w cache przeglądarki, wtedy należy przerwać taką transmisje. W przeciwnym wypadku przeglądarka zaakceptuje je i w praktyce zostaną one odebrane zaraz po przesłaniu strony – bez zbędnych opóźnień.

W ASP.NET dostępna jest już metoda PushPromise:

public void PushPromise(
	string path,
	string method,
	NameValueCollection headers
)

Drugie przeładowanie jest nieco prostsze w użyciu:

public void PushPromise(
	string path
)

Warto zauważyć, że w taki sposób możemy kontrolować czas życia obiektu. W przypadku inline nie było takiej możliwości – zawsze zasób był przesyłany. Jeśli korzystamy z ServerPush, zasób będący w cache przeglądarki zostanie anulowany i nie przesyłany. Podobnie za pomocą parametru headers (nagłówki), możemy dowolnie aktualizować lub usuwać dany zasób z cache (nagłówek Cache-Control).

Z powyższego opisu wynika jeszcze jeden wniosek – zwracana obietnica zasobu musi nadawać się do cachowania. Przeglądarka ma prawo i będzie wspomniany zasób wykorzystywać w innych podstronach. Tak samo, projektując stronę, nie powinniśmy polegać wyłącznie na Server Push. To jedynie usprawnienie w wydajności, a nie element nowej architektury – wiele przeglądarek wciąż tego nie wspiera.

Server Push to wyłącznie mechanizm uprzedzenia przeglądarki i dostarczania zależności wraz z plikiem głównym. Nie ma to nic wspólnego z Web Sockets i innymi technikami komunikacja dwustronnej.