Buforowanie Weba

Porównanie buforów

Po wybraniu kilku odpowiadających nam produktów możemy się skoncentrować na takich cechach jak współczynnik odwołań trafionych czy zastosowane algorytmy odświeżania.

Administrator bufora może sterować pracą algorytmu, definiując różne czasy odświeżania (wydłużając lub skracając czas odświeżania). Jeśli czas odświeżania zostanie wydłużony, bufor będzie rzadziej przeglądać zawartość oryginalnego serwera webowego. Łącze WAN będzie mniej obciążone, ale pobierany z bufora obiekt może się nieraz okazać obiektem przestarzałym. Coś za coś.

Buforowanie Weba

<b>Podstawowe parametry techniczne buforów webowych</b>

Przyjrzyjmy się najpierw współczynnikowi odwołań trafionych. Odwołania takie obsługuje sam bufor, w przeciwieństwie do odwołań chybionych, które skutkują tym, że obiekt musi być pobrany z oryginalnej lokalizacji. Producenci buforów przechwalają się, jakimi to wspaniałymi współczynnikami odwołań trafionych charakteryzują się oferowane przez nich produkty. Jest jednak jedno ale: bufor zainstalowany przez usługodawcę internetowego na obrzeżu sieci udostępnianej klientom (którzy pobierają z Internetu miliony stron WWW z absolutnie różnych serwerów webowych) rzadko może legitymować się współczynnikiem odwołań trafionych przekraczającym poziom 50 proc. Jeśli jednak bufor taki usytuujemy przed firmowym serwerem webowym (liczba obiektów i stron WWW pobieranych przez klientów jest ograniczona do tego serwera), to współczynnik odwołań trafionych może nawet przekroczyć poziom 80 proc.

Obiekty - świeże czy przestarzałe

Buforowanie Weba

Tsunami CPX-1000 (Swell)

Kolejna ważna cecha rozwiązania to funkcje odświeżające zawartość bufora. Ponieważ bufory przechowują informacje zmieniające się z czasem, to muszą stosować mechanizmy określające, które obiekty należy odświeżyć, a które usunąć i wstawić w ich miejsce inne. Zadanie to wykonują algorytmy odświeżania, które automatycznie aktualizują obiekty webowe. Algorytmy pracują w oparciu o parametry i funkcje, takie jak: czas odświeżania, wysłanie żądania pobrania zmodyfikowanego obiektu, określenie przewidywanego czasu życia obiektu i wykonanie zadania aktywnego buforowania.

Buforowanie Weba

DynaCache 30i (InfoLibria)

Algorytm może wysyłać do oryginalnego serwera webowego żądanie „pobierz, jeśli obiekt został zmodyfikowany”. Za każdym razem, gdy przeglądarka klienta chce pobrać obiekt, bufor kontaktuje się z oryginalnym serwerem webowym i sprawdza, czy dany obiekt był modyfikowany. Jeśli nie był, odsyła do przeglądarki obiekt przechowywany w swojej pamięci. Jeśli był, pobiera cały obiekt z pamięci oryginalnego serwera i przekazuje przeglądarce, zapisując jednocześnie w swojej pamięci. Inny algorytm pozwala administratorowi sterować pracą bufora, tak aby bufor sam przewidywał czas życia obiektu, biorąc pod uwagę upływ czasu od momentu, gdy dany obiekt był ostatni raz modyfikowany.

Lokalizacja

Buforowanie Weba

WebCache100 (Lucent)

Gdy wiemy już co nieco o współczynniku odwołań trafionych i o odświeżaniu zasobów, możemy się zastanowić nad tym, gdzie zainstalować bufor. Generalna zasada jest właściwie prosta - obiekty webowe powinny być przechowywane jak najbliżej ich potencjalnych użytkowników.

Buforowanie Weba

IBM Netfinity 5600

Praktyka wskazuje, że w dużych firmach po zainstalowaniu bufora na obrzeżu sieci LAN wykorzystanie łącza WAN spada przeciętnie 20-30 proc. Maleje też wtedy czas odpowiedzi i wzrasta komfort pracy pracowników korzystających często z zasobów Internetu.

Po zainstalowaniu w firmie standardowego bufora proxy należy rekonfigurować wszystkie przeglądarki, tak aby odwoływały się bezpośrednio do bufora. W przypadku zastosowania bufora przezroczystego, kluczową rolę odgrywa przełącznik warstwy 4, komunikujący się zarówno z buforem, jak i z Internetem.

Buforowanie Weba

Cache Engine 590 (Cisco)

Jeśli osoby pracujące w domu wykorzystują technologię dostępu zdalnego, to bufor powinien się znajdować w sieci usługodawcy internetowego, w punkcie określanym mianem POP (Point of Presence - punkt obecności), aby uniknąć niedogodności związanych z powolną pracą publicznych połączeń telefonicznych. Usługodawca internetowy instaluje wtedy u siebie bufor przezroczysty, dlatego przeglądarek nie trzeba rekonfigurować.

Buforowanie Weba

PowerEdge 130-B (Dell)

Bufory proxy cieszą się szczególnym wzięciem w intranetach. Pełnią one tam rolę zapór, chroniąc intranet przed atakami włamywaczy komputerowych. Wszystkie przeglądarki eksploatowane w firmie muszą być wtedy rekonfigurowane, tak aby odwoływały się bezpośrednio do określonego przez administratora bufora.

Należy też wspomnieć o buforach zwrotnych, instalowanych tuż przed serwerami webowymi. Dzięki takim buforom serwery te nie muszą już odpowiadać na wszystkie odwołania. Część takich odwołań jest obsługiwanych przez bufor zwrotny, dlatego wydajność serwerów webowych w znaczący sposób wzrasta.

Zarządzanie buforami

Buforowanie Weba

DataReactor 5000 (iMimic)

Tak jak każde urządzenie sieciowe bufor trzeba najpierw zainstalować i następnie mieć narzędzia pozwalające zarządzać nim. Tylko firma Quantex oferuje produkt, który można zainstalować w 15 minut. Oprogramowanie Squid (patrz witryna www.squid-cache.org) jest produktem bezpłatnym, ale użytkownik tego oprogramowania musi dobrze znać system operacyjny Unix, aby przystąpić do jego instalowania. A jakich funkcji zarządzania należy szukać w buforach? Bufor powinien obsługiwać standard MIB II (Management Information Base), wysyłać w razie potrzeby wiadomości e-mail (informując administratora o różnych zdarzeniach) i oferować rozwiązania pozwalające zdalnie kontrolować bufor i zarządzać nim.

Bufor firmy Quantex Microsystems używa graficznego interfejsu użytkownika opartego na języku Java, który zawiera łącza odwołujące się w trybie online do dokumentacji technicznej. Znajduje się w niej indeks tzw. często zadawanych pytań (FAQ), które ułatwiają zadanie konfigurowania i zarządzania produktem.

Kontrowersje wokół stron webowych

Czy buforowanie Weba jest niekorzystne dla Internetu? Debata w tej sprawie rozgorzała wśród społeczności IETF w momencie, gdy wiodący dostawcy rozwiązań buforowania Weba zaproponowali protokół komunikacyjny zaprojektowany dla rozkładania obciążeń i przekierowywania ruchu sieciowego.

Problem polega na tym, że proponowany protokół NECP (Network Element Control Protocol jest technologią ogólnego zastosowania, „obsługującą” bezpieczną i elastyczną komunikację pomiędzy serwerami, przełącznikami i urządzeniami sieciowymi.

NECP jest popierany przez niektóre firmy z branży internetowej: Akmai Technologies, Foundry Networks, Inktomi, Alteon WebSystems, Novell, Radware i Network Apliance. Firmy te przedstawiły projekt tego protokołu na forum IETF z wnioskiem o publikację w formie dokumentu informacyjnego.

NECP stał się przedmiotem kontrowersji, ponieważ niektórzy uczestnicy IETF uważają, że jedno z prawdopodobnych zastosowań NECP – tzw. proxy przechwytujące – narusza podstawowe zasady projektowe Internetu.

Proxy przechwytujące funkcjonuje jako pośrednik pomiędzy użytkownikiem końcowym a serwerem, który ten użytkownik próbuje osiągnąć. Bierze ono na siebie rolę serwera docelowego, dostarczając zawartość lub usługę sieciową szybciej niż serwer docelowy. Jedną z zalet proxy przechwytującego jest to, że nie wymaga żadnego konfigurowania po stronie użytkownika. Jednak z drugiej strony narusza standard IP, odchodząc od natury end-to-end tej techniki komunikacyjnej i powodując problemy współdziałania. Takie proxy zmieniają także komunikację bez wiedzy i aprobaty użytkownika końcowego czy serwera docelowego.

Proxy przechwytujące są używane przez AOL innych usługodawców internetowych do obsługi ruchu od użytkowników uzyskujących dostęp do Internetu przez telefoniczną sieć komutowaną (ok. 25% użytkowników Internetu w USA).

Pomimo tak szerokiego stosowania technika przechwytywania jest ciągle drażliwym tematem na forum IETF. Jeden z prominentnych uczestników debaty zażądał odrzucenia wniosku o publikację NECP właśnie z tego powodu, iż obsługuje on także proxy przechwytujące. W toczącej się debacie „puryści IP” argumentowali, że IETF nie powinno firmować używania proxy przechwytującego, natomiast pragmatycy argumentowali, że standaryzacja powszechnie stosowanej praktyki jest pożyteczna.

NECP jest otwartym protokołem zastępującym kilka różnych (firmowych) rozwiązań stosowanych w urządzeniach buforujących Weba do komunikowania z serwerami i przełącznikami. Specyfikacja ta została utworzona dla aplikacji buforowania i rozkładania obciążeń, jednak może być także stosowana w innych aplikacjach, ponieważ pozwala dowolnemu serwerowi w sieci „rozmawiać” z każdym urządzeniem w sieci.

NECP, nad którym prace rozpoczęto dwa lata temu, ma być implementowany jeszcze w tym roku, między innymi w produktach firm Radware i Network Appliance. Niezależnie od temperatury debaty nad NECP, IETF zamierza opublikować tę specyfikację w formie dokumentu informacyjnego po usunięciu z niego odniesień do proxy przechwytujących i dokonaniu kilku innych drobnych zmian w tekście.

(NW/jm)


TOP 200