Serwer Proxy, a serwis w technologii flash
15 grudnia 2008 09:21
Jakub Rosiak
Serwery Proxy stały się ważną częścią infrastruktury sieci komputerowych. Wykorzystywane są do buforowania ruchu Web, nierzadko autoryzują dostęp do zasobów (authorization proxy), filtrują zapytania pod względem treści (content filter web proxy), czy wyposażone w akceleratory SSL (Secure Socket Layer) pozwalają odciążyć serwery aplikacji z potrzeby szyfrowania i deszyfrowania ruchu (reverse proxy).
Idea działania usługi Proxy jest dobrze znana i w ogólności sprowadza się do pośredniczenia w połączeniu pomiędzy komputerem klienta a serwerem danej usługi. Wykorzystując fakt pośredniczenia w komunikacji, serwer proxy dodatkowo buforuje dane przepływające. Umożliwia to udzielanie odpowiedzi na żądania użytkownika, w imieniu serwer zasobu, gdy tylko proxy posiada żądane dane w buforze. W efekcie minimalizowany jest ruch na łączu klient-zasób.
Koncepcja wykorzystania serwerów pośredniczących posiada jeden znaczący minus - nie daje się zastosować do danych dynamicznie zmiennych w czasie (np. strumieni audio, czy video).
Czy to jedyne ograniczenie proxy?
Wyobraźmy sobie sytuację, w której łączymy się z sieci korporacyjnej do serwisu web wykonanego w technologii flash.
Składowe takiego serwisu, a nierzadko całe serwisy, zapisywane są w postaci plików z rozszerzeniem *.swf. Aby uruchomić je z pomocą przeglądarki internetowej należy w kodzie html zamieścić odpowiednie instrukcję, na przykład w index html:
<html>
<object width="550" height="400">
<param name="movie" value="somefilename.swf">
<embed src="somefilename.swf" width="550" height="400">
</embed>
</object>
</html>
Tak stworzona strona działa poprawnie nawet, jeżeli użytkownicy korzystają z pośrednictwa serwera Proxy buforującego. Problem pojawia się w momencie aktualizacji treści strony.
Aby dokonać zmiany w zawartości strony trzeba zmodyfikować plik somefilename.swf. Twórcy serwisów www najczęściej nie zmieniają nazwy pliku przy aktualizacji, a zatem nie modyfikują właściwej strony napisanej w kodzie html. To z kolei pozbawia serwer proxy możliwości uzyskania informacji o właśnie wprowadzonej zmianie.
Jak do tego dochodzi?
Prześledźmy szczegóły połączenia prowadzące do pobrania strony. Komunikacja podzielona jest na dwie niezależne sesje (od klienta do serwera Proxy oraz od serwera Proxy do serwera zasobu), które na poziomie protokołu HTML wyglądają prawie identycznie.
Użytkownik generuje żądanie HTTP GET ze wskazaniem zasobu, który chce pobrać:
REQUEST
GET / HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
Accept-Language: pl
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Host: www.zasób.flash.pl
Connection: Keep-Alive
Serwer odpowiada - treścią strony:
RESPONSE
HTTP/1.1 200 OK
Content-Length: 120
Content-Type: text/html
Content-Location:
www.zasób.flash.pl/index.html
Last-Modified: Fri, 2 Dec 2008 07:05:02 GMT
Accept-Ranges: bytes
ETag: "c31267809725c71:17ab"
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Date: Tue, 02 Dec 2008 18:36:21 GMT
<html>
<object width="550" height="400">
<param name="movie" value="somefilename.swf">
<embed src="somefilename.swf" width="550" height="400">
</embed>
</object>
</html>
W efekcie wymiany komunikatów wyświetlana jest strona internetowa, która zostaje również zapisana w buforze serwera proxy buforującego.
Załóżmy, że właśnie w tej chwili ktoś przeprowadza wcześniej opisaną modyfikację treści strony. Zmieniona zostaje zawartość pliku somefilename.swf. Natomiast plik index.html pozostaje bez zmian. Jeżeli inny użytkownik ponowi zapytanie o zasób otrzyma w odpowiedzi stronę, ale podaną nie z właściwego serwera, lecz z bufora Proxy. Nawet, gdy użytkownik będzie posiadał wiedzę o fakcie zmiany treści strony i użyje klawiszy zapewniających odświeżenie jej zawartości (F5 czy Carl+F5), nie uzyska spodziewanego efektu. Przeterminowane dane z bufora proxy będą nadal traktowane jako aktualne.
Dlaczego tak się dzieje?
Kluczem jest treść zapytania klienta, który chce pobrać stronę domyślną dla danego zasobu. W naszym przypadku jest to index.html, wewnątrz której obsadzona jest właściwa treść pliku *.swf. Ponieważ data ostatniej modyfikacji index.html nie uległa zmianie, to pomimo zmuszenia proxy do ponownego pobrania zawartości strony (wciśnięcie F5 lub Crtl+F5) - poprzez metodę GET warunkową (IMS - if modified since), na zapytanie o zasób przez Proxy serwer do serwera usługi otrzymamy odpowiedź:
HTTP/1.1 304 Not Modified
Date: Tue, 02 Dec 2008 19:13:11 GMT
W efekcie zawartość bufora zostanie uznana za nieprzeterminowaną i jako taka zostanie przesłana użytkownikowi.
Czy istnieje rozwiązanie problemu?
Możliwości jest, co najmniej kilka. Pierwsza odnosi się do twórców serwisów, którzy powinni zawsze przy zmianie zawartości jakichkolwiek składników serwisów umieszczanych w treści strony html, modyfikować również jej zawartość. Innym rozwiązaniem będzie odpowiednie skonfigurowanie serwera proxy tak, aby dany zasób nie był buforowany. Podejście to ma jednak charakter reaktywny i jako takie jest raczej metodą rozwiązania powstałego problemu, a nie sposobem na zapobiegnięcie jego powstaniu.
Możliwe jest też modyfikowanie nagłówków protokołu http z poziomu konkretnej strony www. Przewidując zawczasu, że buforowanie tego zasobu może prowadzić do powstania wyżej opisanego problemu umieszczamy deklarację w sekcji <head> strony www.
<META http-EQUIV="Cache-control" CONTENT="no-cache">
Dyrektywa ta spowoduje, że w nagłówku odpowiedzi na żądanie http request będzie ustawiona odpowiednia składowa klasy cache-control, która zostanie stosownie zinterpretowana przez serwer Proxy. W przypadku opcji no-cache serwer będzie pośredniczył w komunikacji, ale nie będzie buforował danych.
Będąc administratorem serwera zasobu możemy spowodować odpowiednie ustawienia klasy cache-control poprzez modyfikację konfiguracji serwera www (np. apache):
<Directory "/var/www/">
Header Set Cache-Control "max-age=0, no-store"
</Directory>
Możemy taką dyrektywą odnieść się również do konkretnego pliku, lub typu plików:
<Directory "/var/www/">
<FilesMatch "\.html$">
Header Set Cache-Control "max-age=0, no-store"
</FilesMatch>
</Directory>
Opisany powyżej problem nie powstaje w skutek błędnego działania konkretnej technologii. Jest on raczej wypadkową niedopasowania rozwiązań i brakiem przewidywania twórców serwisów internetowych do komplikacji środowiska sieciowego, z jakim mamy do czynienia w obecnych czasach.
odpowiada...
wydrukuj
wyślij do znajomego