Buforowanie Weba
- NetWorld,
- 01.06.2000
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ś.
<b>Podstawowe parametry techniczne buforów webowych</b>
Obiekty - świeże czy przestarzałe
Tsunami CPX-1000 (Swell)
DynaCache 30i (InfoLibria)
Lokalizacja
WebCache100 (Lucent)
IBM Netfinity 5600
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.
Cache Engine 590 (Cisco)
PowerEdge 130-B (Dell)
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
DataReactor 5000 (iMimic)
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.
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)