Kształtowanie ruchu

Kształtowanie ruchu polega na takim zarządzaniu pasmem – przez „regulatory ruchu” – aby mniej ważne aplikacje nie dławiły ciągów komunikacyjnych prowadzących do serwerów webowych.

Można wyróżnić dwa podstawowe typy regulatorów:

1. „zarządca bufora” (znany także jako „drybler bitów”);
2. regulator ruchu pakietów, sterujący tempem sesji TCP/IP.

Typ pierwszy, obsługujący zazwyczaj połączenia Frame Relay, jest umiejscawiany poza ruterem, gdzie tworzy i obsługuje kolejki ruchu zapełniane danymi wysyłanymi przez stacje końcowe. Przydzielanie pasma dla ruchu może opierać się na typie protokołu. Pakiet nie tłumi całkowicie ruchu o niskim priorytecie, zmniejsza tylko dostępność pasma dla takiego ruchu, preferując strumienie transmisyjne aplikacji o wyższym priorytecie.

Regulatory ruchu typu drugiego – umiejscawiane wewnątrz sieci prywatnej, tuż za ruterem – przechwytują potwierdzenia TCP we wchodzących strumieniach danych i decydują o tym, na jaki czas wstrzymać takie potwierdzenie, regulując w ten sposób opóźnienia potwierdzenia odbioru, a tym samym i tempo przesyłania pakietów danych. W tym celu regulator ruchu identyfikuje w pakiecie TCP/IP aplikacyjny typ ruchu i adresy IP, a następnie rozdysponowuje pasmo według określonych reguł. Proces taki działa jak regulator dozujący: ruch dławiony jest przez urządzenie transmitujące, otwierające pasmo dla typów ruchu o wysokim priorytecie. Jedną z korzyści, jakie daje regulator pakietów umiejscowiony po wewnętrznej stronie sieci, jest możliwość zastosowania reguł decyzyjnych do lokalnego ruchu sesji TCP.

Buforowanie Weba

Pomysł polega na umieszczeniu obiektów stron webowych tak blisko użytkowników końcowych, jak to tylko możliwe. Strony WWW pobierane są wtedy z bufora zainstalowanego na obrzeżach sieci LAN, a nie ściągane z serwera, pracującego gdzieś daleko w Internecie.

Istnieją trzy podstawowe rodzaje buforów webowych:

• zwykły bufor proxy,
• bufor przezroczysty,
• zwrotny.

Bufor webowy może współpracować z zaporą. Sam bufor jest pewnego rodzaju filtrem, ograniczającym dostęp do wewnętrznych zasobów intranetu. Ponieważ wszystkie odwołania do stron webowych przechodzą przez serwer buforujący, to może on stanowić dodatkową ochronę przed intruzami, którzy chcieliby uzyskać dostęp do wewnętrznego adresu IP.

Buforowanie wykorzystuje fakt, że grupy użytkowników często potrzebują tej samej informacji z Weba wielokrotnie. Ponieważ większość zawartości jest statyczna, niecelowe jest pobieranie za każdym razem świeżej kopii przez relatywnie powolne połączenia internetowe. Efektywniejsze jest zapamiętanie raz pobranej kopii danych webowych blisko żądającego ich użytkownika, zapewniając w ten sposób krótszy czas reakcji na ponowne żądanie i oszczędzając pasmo.

Użytkownicy wewnętrzni, zlecający pobieranie danych webowych, są kierowani najpierw do bufora. Zlecenie jest ekspediowane przez Internet do serwera webowego jedynie wtedy, gdy bufor nie zawiera żądanej informacji. W takim modelu uzyskuje się lepszy czas reakcji kosztem aktualności informacji.

Rozwiązaniem alternatywnym jest umieszczenie urządzenia buforującego bliżej serwera webowego w roli procesora czołowego (front end processor) przejmującego zlecenia do najczęściej pobieranych z serwera stron. Takie rozwiązanie czasami jest nazywane buforowaniem zwrotnym (reverse caching). Ponieważ często pobierane strony są buforowane, motor buforujący po prostu zawraca taką stronę bezpośrednio do urządzenia zlecającego, zamiast przekazywać zlecenia do serwera webowego. Różnice w implementacji tej techniki sprowadzają się zazwyczaj do sposobu przetwarzania zlecenia pobrania strony – stosuje się przysłanianie adresu IP stacji klienckiej żądającej danych z serwera webowego, prezentując serwerowi jedynie adres IP urządzenia buforującego, lub też przechowuje się adres IP klienta zlecającego i prezentuje go serwerowi webowemu w zleceniu „get”.

Inną istotną różnicą jest sposób obsługi procesu HTTP w odniesieniu do seryjnego odbioru. Zlecenie pobrania przychodzące z przeglądarki wyzwala pomiędzy przeglądarką a serwerem cały szereg rund wymiany danych. Dzieje się tak, bo każda strona webowa składa się z wielu obiektów – za każdym razem, kiedy użytkownik zleca sprowadzenie strony z Weba, dla każdego obiektu na stronie jest ustanawiana sesja TCP, a po niej następuje zlecenie get HTTP. Protokół HTTP 1.1 ma ulepszony system uzyskiwania obiektów przez zastosowanie pewnej formy techniki pipeline, przekazującej obiekty w grupach. Jednak trzeba mieć na uwadze fakt, że w bardzo dużej liczbie ośrodków webowych nadal używa się protokółu HTTP 1.0.

Dostęp do buforowanych stron webowych zmniejsza czas reakcji i jest jedną z korzyści zastosowania tej techniki. Jednak produkty stosujące tę technikę muszą też zadbać o aktualność (świeżość) buforowanych danych. Część elementów na stronie webowej może szybko tracić aktualność (na przykład notowania giełdowe). Jest to powód, dla którego motor buforujący musi kontaktować się z oryginalnym serwerem w celu określenia, czy poszczególne obiekty strony webowej nie uległy zmianie od czasu ostatniego pobrania do bufora. Problemem jest tu jednak pewne opóźnienie przy kontroli świeżości. Wielkość takiego opóźnienia zależy od czynników środowiskowych, takich jak aktualne warunki panujące w Internecie lub obciążenia serwera docelowego.

Bufory przechowując informacje zmieniające się w czasie muszą więc mieć mechanizmy pozwalające określać, które obiekty należy odświeżyć, a które usunąć i wstawić w ich miejsce inne. Dzieje się to zgodnie z algorytmami odświeżania, automatycznie aktualizującymi obiekty webowe. Algorytmy wykorzystują 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.

W intrasieciach popularne są bufory proxy. Pełnią one tam często 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ęść odwołań jest obsługiwana przez bufor zwrotny, dlatego wydajność serwerów webowych w znaczący sposób wzrasta.

Rozkładanie obciążeń

Przyspieszanie/wstrzymywanie - kierowanie ruchem w ośrodku webowym.

Kształtowanie ruchu i buforowanie pomagają w uzyskaniu lepszej kontroli nad dostępnym pasmem i w redukcji opóźnień, nie mniej ważną rzeczą jest także zapewnienie odpowiedniego poziomu dyspozycyjności serwera webowego. Jest to problem, do rozwiązania którego stosuje się techniki rozkładania obciążeń. Popularność ośrodka webowego może zostać zdeprecjonowana małymi możliwościami przetwarzania pojedynczego serwera webowego. Rozkładanie obciążeń rozdziela ruch pomiędzy serwery webowe zawierające identyczną lub pokrywającą się zawartość. Podejście to redukuje lub eliminuje przeciążenia serwera – najczęstszy powód kiepskich czasów reakcji ośrodka webowego.

Rozdzielacze obciążeń, w swojej najprostszej formie, są regulatorami ruchu HTTP, FTP i innych, kierowanego do serwera webowego. Rozdzielacze obciążeń przechwytują ruch webowy, zanim osiągnie on właściwe serwery webowe, i określają, który serwer w puli jest najlepiej przystosowany do zapewnienia optymalnej wydajności i najszybszego czasu reakcji na zlecenie użytkownika.

Rozdzielacze obciążeń śledzą też serwery webowe w celu określenia, które z nich są najmniej obciążone, aby przydzielić im obsługę nadchodzących transakcji. Mogą się opierać na relatywnie prostych pomiarach czasu reakcji metodą komendy ping lub pomiarach czasu uzyskania z serwera odpowiedzi na zlecenia przekazywane za pośrednictwem sesji Telnet lub HTTP.

Ujemną stroną rozdzielaczy obciążeń, stosujących protokół PING do sprawdzania stanu serwerów, jest to, że obsługa HTTP na serwerze może być zawieszona, podczas gdy sieciowe połączenie serwerowe może być nadal aktywne i odpowiadać na ping. Prowadzi to do sytuacji, w której rozdzielacz obciążeń jest „przekonany”, iż serwer może obsługiwać zlecenia HTTP.

Bardziej efektywne rozwiązanie opiera się na zainstalowanym na serwerze agencie gromadzącym statystyki i przesyłającym je do rozdzielaczy obciążeń. Agent zapewnia bardziej szczegółowe informacje niż ta, która może być uzyskana z prostych zleceń ping. Ujemną strona tego rozwiązania jest fakt, że agent, pracujący na serwerze, konsumuje czas CPU.

Każdy algorytm zarządzający ruchem webowym musi uwzględniać konieczność wykrywania uszkodzonych serwerów. Jednak pojęcie „serwer niedostępny” jest względne. O ile identyfikacja „martwego” serwera nie nastręcza trudności, o tyle problemem jest wykrycie serwera, na którym stos TCP/IP jest czynny, ale załamało się oprogramowanie serwera webowego.

Regulatory ruchu, motory buforujące i rozdzielacze obciążeń mogą samodzielnie zapewnić wydatne skrócenie czasu odpowiedzi ośrodka webowego. Jednak istotna poprawa wydajności zależy często od zastosowania wszystkich tego rodzaju urządzeń.

I tak na przykład motor buforujący, umiejscowiony przed rozdzielaczem obciążeń, może zredukować liczbę zleceń trafiających bezpośrednio do serwerów, buforując najczęściej używane strony lub elementy stron webowych. Również stosowanie regulatorów ruchu pakietów może zapewnić ruchowi o strategicznym znaczeniu zawsze „zielone światło”, a rozdzielacz obciążeń może przejąć taki ruch i skierować go do serwera najlepiej przystosowanego do obsługi takich zleceń. Motory buforujące umiejscowione bezpośrednio za rozdzielaczami obciążeń pozwolą z kolei na rozładowanie powtarzalnych zleceń ściągania stron z serwera, uwalniając go dla innych zleceń, np. zamówień i bardzo ważnych transakcji.

Inne metody przyspieszania Weba

Dążenie do obniżki kosztów utrzymania ośrodków webowych stwarza, między innymi, potrzebę szybszej obsługi większej liczby klientów przy mniejszym zapotrzebowaniu na pasmo sieci i mniejszej liczbie serwerów. Stosuje się tu zazwyczaj metody przybliżania zawartości i proxy odciążające.

Szybkość działania ośrodka webowego może być trudna do jednoznacznego określenia. Użytkownik zazwyczaj nie bierze pod uwagę rozmiaru transmitowanych obiektów, liczby innych użytkowników korzystających jednocześnie z ośrodka i wielu innych czynników – dla niego istotny jest czas oczekiwania na wypełnienie ekranu przeglądarki wszystkimi lub co najmniej istotnymi elementami strony.

Komponenty ośrodka webowego, które mogą spowodować opóźnienia, są liczne. Trzy główne to:

• serwer,
• sieć,
• klient.

W ośrodkach webowych typu e-commerce zarządzający ośrodkiem największą kontrolę ma nad serwerem, a najmniejszą nad klientem. Zakres kontroli nad siecią jest zmienny.

Szybkość a skala ośrodka

W sytuacji, gdy ośrodek ma coraz więcej użytkowników, jego serwery w pewnym momencie zostają przeciążone i wolniej reaguje na zlecenia. Dodanie nowych serwerów i zastosowanie rozwiązań z dziedziny rozdzielania obciążeń i klastrowania pozwala na przeskalowanie ośrodka, a jego wydajność może wrócić do normy.

Wydajność można też poprawić stosując szybsze dyski i lepsze ustawienia dostępu do sieci. Do tego celu można użyć specjalistycznych kart poprawiających wydajność serwera lub interfejsu sieciowego – istotą takich rozwiązań jest uwolnienie jednostki centralnej CPU serwera webowego od przetwarzania związanego z obsługą protokołów sieciowych, pozwalając jej skupić się na generowaniu i serwowaniu stron WWW.

Kolejną ważną sposobnością do przyspieszenia działania ośrodka po stronie serwera jest przyjrzenie się oprogramowaniu webowemu serwera – wydajność dostępnych serwerów webowych może znacznie różnić się między sobą. Istnieją też specjalizowane urządzenia (appliance) wyposażone w zoptymalizowany, zagnieżdżony system operacyjny i optymalizowany osprzęt serwerowy.

Przybliżanie zawartości

Przyspieszanie/wstrzymywanie...

Sieci stwarzają poważne wyzwania dla systemów dostarczania stron – z jednej strony są to problemy ruchu i trasowania, a z drugiej potrzeba takiego projektowania, aby ośrodek był jak najbliżej wszystkich użytkowników.

Jednym z rozwiązań jest ustawienie szeregu serwerów rozproszonych geograficznie i zastosowanie urządzeń globalnego równoważenia obciążeń do trasowania zleceń użytkowników do najbliższego ośrodka. Można też zastosować rozwiązanie CDN (Content Delivery Network), specjalizowanej sieci „przesuwającej” zawartość ośrodka bliżej użytkowników przez umieszczenie dużych, statycznych obiektów stron, takich jak obrazy i pliki PDF, w buforach znajdujących się bliżej użytkownika.

W tak wydzielonej (logicznie) sieci gros zawartości stron dostarczane jest użytkownikowi szybciej i jest mniej zależne od problemów związanych z ruchem, pojawiających się na całej drodze przesyłu. Na ogół jednak usługi CDN nie są tanie i wymagają zmodyfikowania przyspieszanych stron w celu połączenia buforowanych obiektów na stronach. Opracowana specjalnie w tym celu specyfikacja ESI (Edge Side Includes) pozwala na usprawnienie procesu tworzenia dynamicznie składanych i dostarczanych przez CDN zawartości.

Do zmniejszenia objętości dostarczanej zawartości może być używana kompresja, a mniejsza objętość przesyłanych danych generalnie zmniejsza czas ich przesyłania. Obrazy i inne formaty binarne tradycyjnie tworzą zasadniczą „masę objętościową” stron webowych. W celu zmniejszenia objętości plików graficznych stron webowych stosuje się przede wszystkim redukcję kolorów w obrazach GIF lub adiustację plików JPEG.

Do przesyłania ekstremalnie dużych plików graficznych można stosować zaawansowane metody formatowania obrazów (np. MrSid czy DjVU).

Wraz ze wzrostem złożoności dokumentów HTML oraz powszechnym używaniem JavaScript kompresja stron, polegająca na redukcji spacji składniowo i treściowo neutralnych (white space) w dokumentach HTML czy JavaScript, może w istotny sposób zmniejszyć rozmiary plików. Ponadto przeglądarki obsługujące HTTP 1.1 umożliwiają także kodowanie GZIP, które kompresuje pliki przed dostarczaniem ich do odbiorcy. Serwery webowe (na przykład IIS Microsoftu) obsługują zazwyczaj tę opcję. Należy jednak zwrócić uwagę na fakt, że chociaż dostarczanie mniejszej liczby bitów poprawia generalnie przepustowość ośrodka, to jednak trzeba uwzględnić czas kompresji/dekompresji dostarczanych obiektów. Mocno skompresowane pliki mogą zmniejszać zapotrzebowanie na pasmo transmisyjne, ale niekoniecznie musi to spowodować szybsze pojawienie się strony na ekranie użytkownika.

Najczęściej stosowany przez użytkowników Weba schemat postępowania: „kliknij–czekaj–przeglądaj–kliknij”, pozwala na wykorzystanie czasu braku aktywności użytkownika, zajętego „studiowaniem” zawartości na przeglądarce, do sprowadzania obiektów jego przewidywanego, kolejnego zlecenia. Niemały wpływ na czas reakcji ma ustawienie konfiguracyjne systemu użytkownika. Z powodu złych ustawień systemowych po stronie klienckiej, zbyt wielkiej liczby aplikacji na nim pracujących, fragmentacji dysku lub powolnej przeglądarki strony webowe mogą otwierać się powoli.

Proxy odciążające

Bezprzewodowe techniki dostępu do Internetu i urządzenia typu PDA wymagają nowych rozwiązań przyspieszania dostarczania zawartości. Rozwiązania te uzupełniają istniejące już produkty i usługi zwiększania wydajności, takie jak przełączniki do rozkładania obciążeń, urządzenia buforujące i sieci dystrybucji zawartości (CDN).

Rozwiązania te funkcjonują jako proxy odciążające (PEP – Performance Enhancing Proxies), przejmujące zlecenie wysyłane z przeglądarek użytkowników do poszczególnych serwerów webowych i wykonujące niektóre zadania, takie jak np. pobieranie i konwertowanie obrazów kolorowych na format czarno-biały dla użytkowników PDA. Niektóre, współpracując z serwerem webowym, operują na wszystkich danych przekazywanych pomiędzy przeglądarką użytkownika i serwerem webowym.

Rozwiązania i technologie typu PEP są różnorodne. Ich cechą wspólną jest skupianie się na jednym lub kilku z czterech aspektów: optymalizacji danych pod kątem różnorodnych urządzeń wyświetlających; kompresji danych; wykorzystywania „okresów ciszy” pomiędzy transmisjami bieżących stron na przesyłanie obiektów następnych stron do bufora przeglądarki; oraz optymalizacji komunikacji HTTP i TCP.

Techniki stosowane w PEP to między innymi: analiza wzorców zachowań użytkowników odwiedzających ośrodek webowy i wypracowanie na tej podstawie metody wykorzystywania „okresów ciszy” w transmisji danych (np. gdy użytkownik przegląda stronę) na przesyłanie do bufora przeglądarki elementów, takich jak pliki tekstowe czy graficzne, z kolejnych, najbardziej prawdopodobnych do wybrania stron. Gdy użytkownik zdecyduje się kliknąć na wytypowanym według wzorca zachowań linku, to wiele z elementów tej strony jest już dostępnych w buforze przeglądarki, a użytkownik odnosi wrażenie szybszej transmisji.

Następnym sposobem jest optymalizacja i kompresja zawartości. Szereg urządzeń mobilnych z dostępem do Internetu, takich jak PDA, dysponuje jedynie czarno-białym ekranem. W tej sytuacji PEP, po pobraniu pliku obrazu z serwera webowego, wykonuje jego konwersję na obraz czarno-biały. Zmniejsza się w ten sposób rozmiar pliku przesyłanego do przeglądarki urządzenia mobilnego, co ma niebagatelne znaczenie w stosunkowo powolnych połączeniach dial-up czy bezprzewodowych (wiele rozwiązań wykorzystuje też wbudowane w przeglądarki możliwości dekompresji, tak więc użytkownik końcowy nie musi instalować specjalnego oprogramowania do tego celu).

Spotyka się też połączenie redukcji zawartości z kompresją i buforowaniem. Redukcja treści zmniejsza objętość danych, jaka musi być przesłana do przeglądarki użytkownika. Osiąga się to metodą analizy wzorców obrazów strony webowej. Można w ten sposób osiągnąć zmniejszenie rozmiarów plików graficznych do jednej czwartej oryginału. Dodatkowo elementy strony webowej są kompresowane przed wysłaniem do użytkownika. Połączenie redukcji zawartości z jej kompresją oznacza znacznie mniejszą liczbę danych do przesłania – strona może więc pojawić się znacznie szybciej na ekranie użytkownika.

Kolejnym podejściem jest połączenie metod przyśpieszania z mechanizmami inteligentnego zarządzania ruchem. Zarządzanie ma na celu zredukowanie ruchu TCP/HTTP pomiędzy serwerem a użytkownikiem. Metoda sprowadza się do redukcji liczby zleceń, które serwer musi obsłużyć w celu dostarczenia danej strony webowej. Osiąga się to ustalając stałe połączenie z serwerem webowym i dopuszczając użytkowników, chcących uzyskać dostęp do strony webowej, do współdzielenia tego połączenia. Podejście to eliminuje pewne wbudowane niedogodności połączeń TCP realizowanych w ramach protokołu HTTP. Właśnie w HTTP, gdy użytkownik chce uzyskać dostęp do strony webowej, sesja TCP musi być ustanawiana dla każdego elementu strony webowej. Typowa strona webowa zawiera od kilkunastu do kilkudziesięciu różnych obiektów (tekst, grafika, linki, i inne). Każdy taki obiekt wymaga otwarcia sesji TCP, która jest zamykana po odebraniu obiektu. Serwer webowy musi wykonywać to samo zadanie wielokrotnie – dla każdej osoby, która dostaje się do tej samej strony. Zdjęcie tych zadań z serwera webowego przez jednorazowe ustanowienie połączenia eliminuje czas potrzebny na ustanawianie i zamykanie kilkudziesięciu sesji na jedną stronę.

Większość tego typu rozwiązań akceleracyjnych funkcjonuje na serwerze i nie wymaga żadnych zmian po stronie klienckiej. Niemniej spotyka się rozwiązania wymagające sprowadzania niewielkich fragmentów oprogramowania na poziom klienta.

Zobacz także

• Akceleratory ośrodków webowych