Optymalizacja parametrów i ±rodowiska pracy protokoªu HTTP

Transkrypt

Politechnika Warszawska
Rok akademicki 2013/2014
Wydziaª Elektroniki i Technik Informacyjnych
Instytut Informatyki
PRACA DYPLOMOWA MAGISTERSKA
Rafaª Paszkiewicz
Optymalizacja parametrów
i ±rodowiska pracy protokoªu HTTP
Opiekun naukowy:
mgr in». Paweª Radziszewski
Ocena . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.........................................
Podpis Przewodnicz¡cego
Komisji Egzaminu Dyplomowego
Kierunek:
Informatyka
Specjalno±¢:
In»ynieria Systemów Informatycznych
Data urodzenia:
17 czerwca 1989 r.
Data rozpocz¦cia studiów:
20 lutego 2012 r.
yciorys
Urodziªem si¦ 17 czerwca 1989 r. w Tarnobrzegu. W latach 2005-2008 ucz¦szczaªem do I Liceum Ogólnoksztaªc¡cego
Collegium Gostomianum
w Sandomierzu. W 2008 r. zdaªem egza-
min maturalny oraz rozpocz¡ªem nauk¦ na Wydziale Elektroniki i Technik Informacyjnych
Politechniki Warszawskiej. W 2012 r. obroniªem z wyró»nieniem prac¦ in»yniersk¡ pt.
chanizmy unikania przeci¡»enia w sieci TCP/IP.
wzi¡ªem udziaª w dwusemestralnym stypendium
Me-
Nast¦pnie w trakcie studiów magisterskich
LLP-Erasmus
na Facultad de Informática,
Universidad Politécnica de Madrid.
.....................................
podpis studenta
Egzamin dyplomowy
Zªo»yª egzamin dyplomowy w dn. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Z wynikiem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ogólny wynik studiów . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dodatkowe wnioski i uwagi Komisji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
...........................................................................................
Tytuª
Optymalizacja parametrów i ±rodowiska pracy protokoªu HTTP
Streszczenie
Dokument opisuje zasad¦ dziaªania protokoªu HTTP oraz mechanizmy usprawniaj¡ce wydajno±¢ jego pracy. Przedstawia kolejne fazy ewolucji tego standardu na przestrzeni lat oraz
przewidywania zwi¡zane z jego dalszym rozwojem i sposobami poprawy wydajno±ci.
Praca dotyczy równie» analizy ±rodowiska dziaªania protokoªu, prezentuje charakterystyk¦
klienta, serwera i strony internetowej, a tak»e zwi¡zane z nimi techniki optymalizacyjne. Ponadto na potrzeby bada« zaimplementowano robota internetowego, który posªu»yª do eksploracji pewnego zbioru witryn oraz konstrukcji statystycznego modelu na ich podstawie.
Finalnie przeanalizowano rezultaty eksperymentu maj¡cego na celu zbadanie wpªywu opisanych technik optymalizacyjnych na wydajno±¢ protokoªu. Zwerykowano skuteczno±¢ tych
metod w ramach pobierania stron internetowych wzorowanych na zbudowanym modelu.
Sªowa kluczowe
HTTP, HTTP-NG, SPDY, optymalizacja protokoªu, robot internetowy, eksploracja sieci
Title
Optimization of parameters and the environment of the HTTP protocol
Abstract
The document describes the HTTP protocol, the principle of its operation and improvements of performance. It presents subsequent evolution phases of the standard over years
and anticipation of the future progress and ways to boost its eciency.
Also analysis of the protocol environment is concerned client-side, server-side and website
characteristics are commented along with corresponding optimization techniques. Moreover,
for the purpose of research, crawler application was implemented and deployed for the network
exploration process and building the statistical model of visited websites.
Finally, the practical experiment is conducted in order to analyze the impact of environment optimization on the protocol performance. The improvements are veried in the context
of fetching articial websites built upon the calculated model.
Keywords
HTTP, HTTP-NG, SPDY, protocol optimization, crawler, network exploration
Spis tre±ci
Wprowadzenie
7
1 Protokóª HTTP
1.1
Historia
1.2
Architektura
1.3
1.4
8
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
1.2.1
Transakcje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
1.2.2
Typy danych
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
1.2.3
Adresowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
1.2.4
Metody dost¦pu
1.2.5
Format komunikatu
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
11
Problemy wydajno±ciowe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
1.3.1
Znaczenie opó¹nienia . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
1.3.2
Wpªyw opó¹nienia na percepcj¦ u»ytkownika
1.3.3
Wpªyw opó¹nienia na transakcje HTTP
. . . . . . . . . . . . . .
13
. . . . . . . . . . . . . . . . .
14
Optymalizacja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
1.4.1
Poª¡czenia równolegªe
. . . . . . . . . . . . . . . . . . . . . . . . . . .
14
1.4.2
Poª¡czenia trwaªe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
1.4.3
Poª¡czenia potokowe . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2 Klient HTTP
17
2.1
Funkcjonalno±¢
2.2
Architektura
2.3
Zasada dziaªania
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
18
19
2.3.1
Pobieranie zasobów . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
2.3.2
Budowa drzewa DOM
. . . . . . . . . . . . . . . . . . . . . . . . . . .
20
2.3.3
Budowa drzewa CSSOM . . . . . . . . . . . . . . . . . . . . . . . . . .
20
2.3.4
Budowa drzewa renderowania . . . . . . . . . . . . . . . . . . . . . . .
21
2.3.5
Rozkªad ramek
2.3.6
Wy±wietlenie strony
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
21
2.4
Analiza dziaªania . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
2.5
Optymalizacja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
2.5.1
Równolegªo±¢ transferu i przetwarzania . . . . . . . . . . . . . . . . . .
23
2.5.2
Priorytetyzacja zasobów . . . . . . . . . . . . . . . . . . . . . . . . . .
23
2.5.3
Skanowanie wyprzedzaj¡ce . . . . . . . . . . . . . . . . . . . . . . . . .
23
2.5.4
Ograniczenie rozmiaru »¡da«
2.5.5
Pami¦¢ podr¦czna DNS
2.5.6
Akcje wyprzedzaj¡ce . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
Parametryzacja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
2.6
. . . . . . . . . . . . . . . . . . . . . . .
23
. . . . . . . . . . . . . . . . . . . . . . . . . .
24
4
3 Serwer HTTP
26
3.1
Funkcjonalno±¢
3.2
Architektura
3.3
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
3.2.1
Podej±cie wieloprzepªywowe . . . . . . . . . . . . . . . . . . . . . . . .
27
3.2.2
Podej±cie zdarzeniowe
Zasada dziaªania
. . . . . . . . . . . . . . . . . . . . . . . . . . .
28
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
3.3.1
Przyj¦cie poª¡czenia
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
3.3.2
Otrzymanie »¡dania
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
3.3.3
Przetworzenie »¡dania
3.3.4
Konstrukcja odpowiedzi
. . . . . . . . . . . . . . . . . . . . . . . . . .
32
3.3.5
. . . . . . . . . . . . . . . . . . . . . . . . . . .
31
Wysªanie odpowiedzi . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
3.4
Komponenty sieci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
3.5
Optymalizacja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
3.5.1
Unikanie przekierowa« . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
3.5.2
Obsªuga pola Expires
34
3.5.3
Konguracja znaczników ETag
3.5.4
Zastosowanie kompresji
3.5.5
Partycjonowanie domeny . . . . . . . . . . . . . . . . . . . . . . . . . .
36
3.5.6
Wykorzystanie infrastruktury CDN . . . . . . . . . . . . . . . . . . . .
37
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
35
. . . . . . . . . . . . . . . . . . . . . . . . . .
35
4 Zasób sieci
38
4.1
Ewolucja zasobu sieci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
4.2
Pomiary zasobów internetowych . . . . . . . . . . . . . . . . . . . . . . . . . .
39
4.2.1
Pomiary Google . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
4.2.2
Pomiary wªasne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
4.2.3
Pomiary Internet Archive
43
4.2.4
Porównanie pomiarów
4.3
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
44
Optymalizacja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
4.3.1
¡czenie zasobów . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
4.3.2
Osadzanie zasobów . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
4.3.3
Uproszczenie arkuszy styli . . . . . . . . . . . . . . . . . . . . . . . . .
47
4.3.4
Miniaturyzacja i zaciemnianie kodu . . . . . . . . . . . . . . . . . . . .
47
4.3.5
Doª¡czanie zasobów w postaci zewn¦trznych plików . . . . . . . . . . .
48
4.3.6
Lokowanie skryptów i arkuszy styli . . . . . . . . . . . . . . . . . . . .
48
4.3.7
Opró»nianie bufora . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
4.3.8
Redukcja liczby elementów DOM . . . . . . . . . . . . . . . . . . . . .
49
4.3.9
Optymalizacja obrazów
49
. . . . . . . . . . . . . . . . . . . . . . . . . .
5 Roboty internetowe
5.1
5.2
50
Algorytmy eksploracji sieci . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
5.1.1
Eksploracja podstawowa . . . . . . . . . . . . . . . . . . . . . . . . . .
52
5.1.2
Eksploracja selektywna . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
5.1.3
Eksploracja ukierunkowana
. . . . . . . . . . . . . . . . . . . . . . . .
53
5.1.4
Eksploracja rozproszona . . . . . . . . . . . . . . . . . . . . . . . . . .
55
Problemy eksploracji sieci
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
5.2.1
Bazowy zbiór adresów
. . . . . . . . . . . . . . . . . . . . . . . . . . .
56
5.2.2
Cykle eksploracji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
5.2.3
Przestrzeganie etykiety . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
5
6 Dokumentacja projektowa
61
6.1
Sªownik poj¦¢ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
6.2
Wymagania funkcjonalne i niefunkcjonalne . . . . . . . . . . . . . . . . . . . .
62
6.3
Przypadki u»ycia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
6.4
Architektura
64
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.4.1
Warstwa danych
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
6.4.2
Warstwa przetwarzania . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
6.4.3
Warstwa komunikacji . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
6.4.4
Warstwa sterowania
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
6.5
Technologia realizacji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
6.6
Instrukcja u»ytkownika . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
7 Eksperymentalna optymalizacja ±rodowiska protokoªu HTTP
7.1
7.2
70
7.1.1
Liczba równolegªych poª¡cze« . . . . . . . . . . . . . . . . . . . . . . .
71
7.1.2
Kompresja gzip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
7.1.3
Infrastruktura CDN
74
7.1.4
Eksternalizacja a osadzanie zasobów
. . . . . . . . . . . . . . . . . . .
75
7.1.5
Konkatenacja zasobów . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
7.1.6
Miniaturyzacja zasobów
. . . . . . . . . . . . . . . . . . . . . . . . . .
77
7.1.7
Pozycjonowanie skryptów
. . . . . . . . . . . . . . . . . . . . . . . . .
78
7.1.8
Mapy obrazów
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Optymalizacja przykªadowych stron
. . . . . . . . . . . . . . . . . . . . . . .
8.2
79
81
7.2.1
Optymalizacja portalu informacyjnego . . . . . . . . . . . . . . . . . .
81
7.2.2
Optymalizacja galerii obrazów . . . . . . . . . . . . . . . . . . . . . . .
83
7.2.3
Optymalizacja wyszukiwarki . . . . . . . . . . . . . . . . . . . . . . . .
85
8 Przyszªo±¢ protokoªu HTTP
8.1
70
Przegl¡d technik optymalizacyjnych . . . . . . . . . . . . . . . . . . . . . . . .
87
HTTP-NG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
88
8.1.1
Modularyzacja
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
88
8.1.2
Ulepszenie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
HTTP/2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
8.2.1
Architektura
90
8.2.2
Warstwa komunikacji . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
8.2.3
Multipleksowanie komunikatów
. . . . . . . . . . . . . . . . . . . . . .
91
8.2.4
Priorytetyzacja komunikatów
. . . . . . . . . . . . . . . . . . . . . . .
92
8.2.5
Pojedyncze poª¡czenie . . . . . . . . . . . . . . . . . . . . . . . . . . .
92
8.2.6
Sterowanie przepªywem
. . . . . . . . . . . . . . . . . . . . . . . . . .
92
8.2.7
Transfer wyprzedzaj¡cy
. . . . . . . . . . . . . . . . . . . . . . . . . .
92
8.2.8
Kompresja nagªówka . . . . . . . . . . . . . . . . . . . . . . . . . . . .
93
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Podsumowanie
94
Tablice
95
Sªownik poj¦¢
99
Zawarto±¢ pªyty CD
100
Bibliograa
101
6
Wprowadzenie
Internet uwa»any jest cz¦sto za jedno z wa»niejszych osi¡gni¦¢ XX wieku. Obecnie stanowi
gwaªtownie rozwijaj¡ce si¦ medium informacyjne, ª¡cz¡ce cechy telewizji, prasy i radia. Pocz¡tkowo nie podejrzewano, »e stanie si¦ gªównym o±rodkiem wymiany informacji, powszechnie
dost¦pnym, popularnym i istotnym dla funkcjonowania spoªecze«stwa.
Globalna sie¢, któr¡ znamy pod obecn¡ postaci¡, jest rezultatem dªugotrwaªego procesu
maj¡cego swe pocz¡tki kilka dekad temu. Wydarzeniem w historii Internetu, które w znacznej
mierze przyczyniªo si¦ do jego sukcesu, jest wprowadzenie protokoªu TCP opowiedzialnego
za niezawodn¡ transmisj¦ danych oraz protokoªu HTTP zapewniaj¡cego jednorodny sposób
dost¦pu do rozproszonych i heterogenicznych zasobów sieci.
Podczas gdy Internet bªyskawicznie rozrósª si¦ na przestrzeni lat, a liczba komputerów
podª¡czonych do sieci zwi¦kszyªa si¦ o kilka rz¦dów wielko±ci, TCP oraz HTTP wci¡» pozostaj¡ wiod¡cymi rozwi¡zaniami w dziedzinie protokoªów transmisji i dost¦pu do danych, a ich
podstawowe zasady funkcjonowania niewiele si¦ zmieniªy.
Jednak wraz ze wzrostem liczby u»ytkowników, zag¦szczeniem w¦zªów sieci oraz ewolucj¡ struktury stron internetowych pojawiªy si¦ problemy wydajno±ciowe. Ich przyczyn¡ jest
ograniczona przepustowo±¢ ª¡czy oraz opó¹nienie transmisji danych. Pierwszy problem zostaª
zªagodzony za po±rednictwem algorytmów unikania przeci¡»enia sieci w warstwie transportowej (TCP), drugi jest adresowany przez mechanizmy poª¡cze« trwaªych, kompresji danych
oraz pami¦ci podr¦cznej w warstwie aplikacji (HTTP).
Dalsze usprawnienia wydajno±ci przeprowadzane s¡ w drodze odpowiedniej konguracji strony klienckiej i serwerowej, a tak»e optymalizuj¡c struktur¦ strony internetowej wraz
z zawarto±ci¡ zasobów zewn¦trznych. Wybór odpowiednich technik optymalizacyjnych zale»y
od charakterystyki witryny oraz jej zasobów i rzutuje na koszty wdro»enia i utrzymania takich rozwi¡za«. Dlatego te» warto przeprowadzi¢ eksperymentaln¡ analiz¦ dziaªania metod
optymalizacyjnych oraz werykacj¦ ich skuteczno±ci w kontek±cie wydajno±ci HTTP.
Innym interesuj¡cym zagadnieniem jest dalszy rozwój protokoªu, który wkrótce mo»e zosta¢ zaktualizowany do kolejnej wersji HTTP/2.0. Jest ona niekompatybilna wstecz, ale ma
szanse wdro»y¢ przeªomowe usprawnienia w kwestii redukcji opó¹nienia. Obecnie mechanizmy
te cz¦±ciowo funkcjonuj¡ w postaci eksperymentalnego protokoªu SPDY dost¦pnego w najnowszych wydaniach przegl¡darek internetowych.
7
Rozdziaª 1
Protokóª HTTP
Protokóª HTTP ewoluowaª przez kilkadziesi¡t lat, by sta¢ si¦ podstawowym kanaªem komunikacji dla najpopularniejszego medium informacji na ±wiecie jakim jest Internet. Kolejne wersje
protokoªu zostaªy zdeniowane w kilku dokumentach RFC (ang.
requests for comments ) i wi¡-
zaªy si¦ ze stopniowym wprowadzaniem ró»nych metod optymalizacji jego wydajno±ci.
1.1
Historia
Pocz¡tki protokoªu HTTP si¦gaj¡ lat osiemdziesi¡tych ubiegªego wieku, kiedy to Tim BernersLee stworzyª program
Enquire
pozwalaj¡cy na poruszanie si¦ pomi¦dzy dokumentami za po-
moc¡ odno±ników znajduj¡cych si¦ w ich tre±ci. Wkrótce dostarczona zostaªa równie» aplikacja
WorldWideWeb
skªadaj¡ca si¦ z edytora i gracznej przegl¡darki.
W 1990 roku pojawiª si¦ pierwszy serwer HTTP, który udost¦pniaª opis projektu WWW.
Na pocz¡tku lat dziewi¦¢dziesi¡tych zarejestrowanych byªo ponad 1500 serwerów, co wpªyn¦ªo
na gwaªtowny rozwój przegl¡darek gracznych:
Erwise, Viola, Netscape, Mosaic
(rys. 1.1).
Rysunek 1.1: Popularna w latach 90. przegl¡darka Mosaic.
Word Wide
Internet Engineering Task Force ) opublikoHypertext Markup Language ). W 1996 wydano
Wkrótce Tim Berners-Lee stan¡ª na czele utworzonego konsorcjum W3C (ang.
Web Consortium ),
natomiast grupa IETF (ang.
waªa ocjalny standard j¦zyka HTML (ang.
specykacj¦ HTTP/1.0 w postaci RFC 1945, a rok pó¹niej wprowadzono obecnie aktualn¡
wersj¦ HTTP/1.1 zawart¡ w dokumentach RFC 2068 i RFC 2616 [16].
8
1.2
Architektura
Protokóª HTTP (ang.
Hypertext Transfer Protocol ) jest protokoªem warstwy aplikacji przezna-
czonym dla rozproszonych i wspóªpracuj¡cych systemów informacyjnych. Bazuje on na warstwie TCP/IP odpowiedzialnej za niezawodn¡ komunikacj¦, jednak»e kanaªy zawodne takie
jak UDP, SSDP równie» mog¡ by¢ obsªugiwane (rys. 1.2). HTTP stanowi równie» podstaw¦
dla wielu rozwi¡za« wy»szego poziomu, np. REST (ang.
Representational State Transfer ) [24].
Rysunek 1.2: Klasykacja protokoªu HTTP w modelu warstwowym [31].
Pierwotnym zastosowaniem protokoªu byªo dostarczanie zasobów u»ytkownikom Internetu, najcz¦±ciej w formie dokumentów hipertekstowych, które tworz¡ sie¢ poª¡cze«. Jako »e
systemy informacyjne w ogólnym przypadku wymagaj¡ szerszej funkcjonalno±ci ni» pobieranie
dokumentu, wymagania dotycz¡ce wysyªania, modykacji oraz wyszukiwania danych równie»
uwzgl¦dniono podczas deniowania architektury protokoªu [49].
1.2.1 Transakcje
Model komunikacji oparty jest o wzorzec klient-serwer i wymian¦ komunikatów na zasadzie
transakcji »¡danie-odpowied¹ (ang.
request-response ),
których sekwencja okre±lana jest mia-
nem sesji. Domy±lnie z protokoªem skojarzony jest port 80.
W najbardziej typowym przypadku transmisji klient otwiera poª¡czenie i wysyªa do serwera »¡danie. Serwer otrzymuje »¡danie, przetwarza je, zwraca dpowied¹ oraz zamyka poª¡czenie (rys. 1.3). W ramach ka»dego komunikatu przesyªane mog¡ by¢ opcjonalne dane.
Rysunek 1.3: Wymiana komunikatów »¡danie-odpowied¹ [31].
9
Transakcyjny charakter komunikacji przekªada si¦ na nast¦puj¡ce cechy protokoªu:
Bezstanowo±¢
Protokóª nie wymaga przechowywania informacji o stanie sesji przez uczest-
ników komunikacji, co wpªywa na wi¦ksz¡ wydajno±¢ oraz niezawodno±¢.
Niezale»no±¢ danych
Protokóª obsªuguje negocjacj¦ reprezentacji oraz transfer danych do-
wolnego typu, pod warunkiem »e klient i serwer s¡ w stanie je obsªu»y¢.
Bezpoª¡czeniowo±¢
Ka»da transakcja lub zbiór logicznie powi¡zanych transakcji w postaci
»¡danie-odpowied¹ wymaga zestawienia nowego poª¡czenia klienta z serwerem.
1.2.2 Typy danych
W celu uªatwienia obsªugi zasobów ró»nego rodzaju protokóª HTTP wykorzystuje znaczniki
przypisywane do ka»dego komunikatu zawieraj¡cego dane (rys. 1.4). Format znakowania opisuje standard MIME (ang.
Multipurpose Internet Mail Extensions ),
który zaprojektowany
zostaª na potrzeby transmisji poczty elektronicznej, ale okazaª si¦ na tyle elastyczny, »e z powodzeniem znalazª zastosowanie w innych usªugach sieciowych [27].
Rysunek 1.4: Dane oznaczone typem MIME [31].
1.2.3 Adresowanie
Uniform Resource IdentiUniform Resource Name ) wskazuj¡cych
zasób jedynie przez nazw¦, niezale»nie od konkretnego poªo»enia, oraz adresów URL (ang. Uniform Resource Locator ) szczegóªowo opisuj¡cych miejsce i sposób dost¦pu do zasobu. Z tego
Ka»dy zasób sieci mo»e by¢ identykowany przez adres URI (ang.
er )
[9]. Jest on nadzbiorem dla adresów URN (ang.
wzgl¦du protokóª HTTP najcz¦±ciej wykorzysuje adresy URL (rys. 1.5).
Rysunek 1.5: Format adresu URL [31].
10
1.2.4 Metody dost¦pu
Ka»dy komunikat »¡dania okre±la metod¦ dost¦pu do zasobu, która determinuje operacj¦
wykonywan¡ przez serwer. Protokóª HTTP dostarcza predeniowany zbiór metod dost¦pu,
który jest implementacyjnie otwarty na rozszerzenia w jego kolejnych wydaniach (tab. 1.1).
Metoda
GET
HEAD
POST
PUT
DELETE
OPTIONS
TRACE
PATCH
Opis
Bezpieczna
Idempotentna
Pobranie zasobu.
Tak
Tak
Pobranie nagªówków z pomini¦ciem zasobu.
Tak
Tak
Przesªanie danych do przetworzenia.
Nie
Nie
Wysªanie i utrwalenie danych.
Nie
Tak
Usuni¦cie wskazanego zasobu.
Nie
Tak
Uzyskanie obsªugiwanych metod dost¦pu.
Tak
Tak
Diagnostyczna transmisja tam i z powrotem.
Tak
Tak
Cz¦±ciowa modykacja zasobu [22].
Nie
Nie
Tablica 1.1: Charakterystyka metod dost¦pu.
Metody GET, HEAD, OPTIONS, TRACE okre±la si¦ mianem bezpiecznych, poniewa»
sªu»¡ do pobierania danych bez zmiany stanu systemu. Natomiast metody POST, PUT oraz
DELETE mog¡ powodowa¢ skutki uboczne. Metody bezpieczne oraz dodatkowo PUT i DELETE maj¡ charakter idempotentny wiele jednakowych »¡da« ma skutek taki jak pojedyncze »¡danie. Wyj¡tkiem jest metoda POST, która z reguªy nie jest idempotentna i z ka»dym
wywoªaniem powoduje zmian¦ stanu systemu. Semantyka i idempotentno±¢ metod nie jest
jednak zale»na od protokoªu lub serwera, a od sposobu obsªugi »¡da« przez aplikacj¦ sieciow¡.
1.2.5 Format komunikatu
Ka»dy komunikat protokoªu HTTP skªada si¦ z nagªówka (ang.
danych (ang.
body ).
header )
oraz opcjonalnych
Format komunikatu zdeniowany jest w nast¦puj¡cy sposób (rys. 1.6):
Rysunek 1.6: Format komunikatu HTTP [31].
Linia inicjuj¡ca
Okre±la wersj¦ protokoªu, dodatkowo w przypadku »¡dania specykuje me-
tod¦ oraz ±cie»k¦ dost¦pu, natomiast dla odpowiedzi wskazuje status wykonanej operacji
skªadaj¡cy si¦ warto±ci liczbowej oraz opisu sªownego (aneks Statusy odpowiedzi).
Nagªówki
Odst¦p
Dane
Linie w formacie
klucz:warto±¢ opisuj¡ce komunikat i nadawc¦ (aneks Nagªówki).
Pusta linia.
Opcjonalne dane, których fragmenty poprzedzane s¡ odpowiadaj¡cymi im rozmiarami.
11
1.3
Problemy wydajno±ciowe
Optymalizacja wydajno±ci protokoªu HTTP jest nieko«cz¡cym si¦ przedsi¦wzi¦ciem, poniewa»
sposób korzystania z Internetu stale ewoluuje przegl¡darki przyspieszaj¡, aplikacje sieciowe
rozrastaj¡ si¦, a prole aktywno±ci u»ytkowników ulegaj¡ zmianom [67]. Mo»na wyszczególni¢
dwa czynniki wpªywaj¡ce na wydajno±¢ protokoªu (rys. 1.7):
Przepustowo±¢
Opó¹nienie
Maksymalna wielko±¢ transferu na ±cie»ce komunikacji w jednostce czasu.
Czas pomi¦dzy wysªaniem a odebraniem pakietu, obejmuje:
•
czas propagacji komunikatu (stosunek odlegªo±ci do pr¦dko±ci propagacji sygnaªu),
•
czas transmisji komunikatu (stosunek rozmiaru pakietu do przepustowo±ci ª¡cza),
•
czas przetwarzania nagªówka komunikatu i sprawdzania jego poprawno±ci,
•
czas oczekiwania na obsªu»enie komunikatu w kolejce po stronie odbiorcy.
Rysunek 1.7: Opó¹nienie a przepustowo±¢ sieci [33].
1.3.1 Znaczenie opó¹nienia
Na wielko±¢ opó¹nienia wpªywa odlegªo±¢ pomi¦dzy nadawc¡ i odbiorc¡, liczba w¦zªów po±rednich oraz nasycenie sieci. Z kolei przepustowo±¢ najcz¦±ciej zale»y od jako±ci usªug ±wiadczonych przez dostawc¦ poª¡czenia internetowego. Dost¦p do ª¡cza o du»ej przepustowo±ci
peªni istotn¡ rol¦ podczas transmisji danych znacznych rozmiarów (ang.
bulk data transfer ),
np. strumieniowania zawarto±ci audio/wideo. Jednak okazuje si¦, »e w przypadku przegl¡dania
stron, które skªadaj¡ si¦ z wielu zasobów, kluczow¡ rol¦ odgrywa opó¹nienie (rys. 1.8).
Wykres przedstawia wpªyw opó¹nienia oraz przepustowo±ci na czas pobierania strony.
W sytuacji zachowania staªego opó¹nienia i zmiany przepustowo±ci w zakresie 1-10 Mb/s
mo»na zauwa»y¢, »e poprawa parametrów z 1 do 2 Mb/s poªowicznie zwi¦ksza wydajno±¢
transferu, podczas gdy wzrost w zakresie 5-10 Mb/s skutkuje zaledwie 5% skróceniem czasu
12
Rysunek 1.8: Wpªyw opó¹nienia i przepustowo±ci sieci na czas ªadowania strony [6].
ªadowania strony. Natomiast w przypadku staªej przepustowo±ci i zmiany opó¹nienia ka»da
redukcja wielko±ci 20 ms przekªada si¦ na liniowe zmniejszenie czasu pobierania dokumentu.
W celu zwi¦kszenia wydajno±ci Internetu w globalnej skali istotne jest ograniczenie opó¹nienia pomi¦dzy klientem a serwerem. Redukcja czasu p¦tli zwrotnej (ang.
time )
RTT round-trip
z 150 do 100 ms mi¦dzy kontynentami w ogólnym przypadku b¦dzie miaªa wi¦kszy
wpªyw na komfort korzystania z sieci ni» zwi¦kszenie przepustowo±ci z 4 do 15 Mb/s. Innym
sposobem jest ograniczenie liczby »¡da« ze strony klienta, których nadmiar wyra¹nie rzutuje
na sumaryczn¡ wielko±¢ opó¹nienia.
1.3.2 Wpªyw opó¹nienia na percepcj¦ u»ytkownika
Nie ulega w¡tpliwo±ci, »e projektuj¡c interaktywne oprogramowanie nale»y mie¢ na uwadze
zdolno±¢ percepcji oraz komfort pracy u»ytkownika (ang.
user experience ),
zwªaszcza w za-
kresie responsywno±ci aplikacji, co okre±laj¡ nast¦puj¡ce progi czasu odpowiedzi (tab. 1.2).
Opó¹nienie
Percepcja u»ytkownika
0-100 ms
Natychmiastowe dziaªanie aplikacji, wysoki komfort pracy.
100-300 ms
Ledwo zauwa»alne opó¹nienie, du»a wygoda pracy.
300-1000 ms
Dostrzegalne niewielkie przestoje, satysfakcjonuj¡cy poziom pracy.
1000+ ms
Wyra¹ne przerwy, utrata koncentracji u»ytkownika.
5000+ ms
Odczuwalne znaczne opó¹nienie, uczucie frustracji.
10000+ ms
Zbyt dªugi czas oczekiwania, porzucenie czynno±ci.
Tablica 1.2: Wpªyw opó¹nienia na percepcj¦ u»ytkownika [64].
Opó¹nienie na poziomie kilkuset milisekund zapewnia pªynno±¢ aplikacji i wygod¦ pracy
u»ytkownika. Konieczno±¢ oczekiwania na odpowied¹ aplikacji rz¦du kilku sekund zaburza
pªynno±¢ interakcji z aplikacj¡ i wzmaga uczucie niecierpliwo±ci u»ytkownika, a przekroczenie
granicy 10 sekund mo»e prowadzi¢ do rezygnacji z wykonywanego zadania. Obrazuje to istot¦
opó¹nienia i konieczno±¢ jego redukcji w celu poprawy wydajno±ci oprogramowania.
13
1.3.3 Wpªyw opó¹nienia na transakcje HTTP
Opó¹nienia sieci s¡ istotnym problemem wydajno±ciowym w kontek±cie pojedynczej transakcji HTTP. Zazwyczaj czas przetwarzania »¡dania przez serwer jest niewielki w porównaniu
do czasu zwi¡zanego z obsªug¡ poª¡czenia i transmisj¡ danych (rys. 1.9).
Rysunek 1.9: Przebieg pojedynczej transakcji [31].
Nawi¡zanie poª¡czenia zgodnie z zasad¡ trójfazowego porozumienia (ang.
shake )
three-way handslow start,
zajmuje caªy okres RTT, po czym protokóª TCP dziaªa wedªug algorytmu
którego celem jest wst¦pne oszacowanie przepustowo±ci sieci poprzez stopniowe zwi¦kszanie
ilo±ci przesyªanych danych [37]. W praktyce cz¦sto zdarza si¦, »e transakcja dobiega ko«ca
i poª¡czenie zamykane jest przed zako«czeniem dziaªania algorytmu, co degraduje stopie«
wykorzystania mechanizmów unikania przeci¡»enia [36]. Opó¹nienia warstwy transportowej
pot¦guj¡ si¦ szczególnie w przypadku sekwencyjnej wymiany komunikatów (rys. 1.10).
Rysunek 1.10: Przebieg sekwencji transakcji [31].
1.4
Optymalizacja
Poprawa aspektów wydajno±ciowych byªa jednym z celów standardu HTTP/1.1, co poskutkowaªo wprowadzeniem licznych udoskonale«, gªównie w zakresie zarz¡dzania poª¡czeniami [28]:
1.4.1 Poª¡czenia równolegªe
Protokóª umo»liwia klientowi zestawianie wielu poª¡cze« w celu realizacji kilku transakcji
HTTP w sposób równolegªy (ang.
parallel connections ).
W rezultacie opó¹nienia poszczegól-
nych transmisji nakªadaj¡ si¦, a dost¦pne pasmo przydzielane jest do nowych poª¡cze«, co
cechuje si¦ wi¦ksz¡ wydajno±ci¡ ni» podej±cie sekwencyjne (rys. 1.11).
14
Rysunek 1.11: Przebieg poª¡cze« równolegªych [31].
Nale»y jednak mie¢ na uwadze, »e tworzenie du»ej liczby poª¡cze« równolegªych skutkuje
rywalizacj¡ o dost¦p do pasma oraz wzrostem zu»ycia zasobów sprz¦towych klienta i serwera. Z tego wzgl¦du przegl¡darki ograniczaj¡ liczb¦ poª¡cze« równolegªych przypadaj¡cych
na serwer w zakresie 2-6, ponadto serwer mo»e w ka»dej chwili zamkn¡¢ poª¡czenia od klienta
zestawiaj¡cego ich zbyt wiele.
1.4.2 Poª¡czenia trwaªe
persistent connections ),
keep-alive znany z HTTP/1.0.
Gªównym ulepszeniem jest wprowadzenie poª¡cze« trwaªych (ang.
które stanowi¡ uzupeªniony i ustandaryzowany mechanizm
W odró»nieniu od pierwotnego podej±cia polegaj¡cego na zamykaniu poª¡czenia po otrzymaniu odpowiedzi na »¡danie, koncepcja ta polega na pozostawianiu otwartego poª¡czenia dla przyszªych transakcji do momentu zamkni¦cia go przez jedn¡ z komunikuj¡cych si¦
stron [51]. W ten sposób wielokrotne wykorzystanie poª¡czenia eliminuje konieczno±¢ ka»dorazowego nawi¡zywania i zamykania obwodu komunikacji, a tak»e pozwala na efektywne dziaªanie algorytmu
slow start
bez konieczno±ci jego powtarzania dla ka»dej transakcji (rys. 1.12).
Rysunek 1.12: Przebieg poª¡czenia trwaªych [31].
W obliczu transmisji
czasu wielko±ci
(N − 1)
N
»¡da«, mechanizm poª¡cze« trwaªych pozwala na oszcz¦dzenie
okresów RTT w porównaniu do pierwotnego podej±cia nawi¡zywania
poª¡czenia dla ka»dej transakcji. W kompozycji z poª¡czeniami równolegªymi jest to istotne
usprawnienie, zwªaszcze »e wy±wietlenie strony internetowej wi¡»e si¦ z pobraniem ±rednio
kilkudziesi¦ciu zasobów zewn¦trznych (rozdz. 4).
15
1.4.3 Poª¡czenia potokowe
Innym udoskonaleniem jest mechanizm potokowego wysyªania komunikatów w obr¦bie poª¡cze« trwaªych (ang.
pipelined connections ).
Stanowi on dalsz¡ optymalizacj¦ protokoªu podczas gdy poª¡czenia trwaªe redukuj¡ narzut otwarcia/zamkni¦cia wirtualnego obwodu pomi¦dzy klientem i serwerem, poª¡czenia potokowe eliminuj¡ czas oczekiwania na mo»liwo±¢
transmisji kolejnego »¡dania, co ma istotne znaczenie w sieciach o du»ym opó¹nieniu [54].
Domy±lnie protokóª HTTP narzuca konwencj¦ wymiany komunikatów w formie »¡danieodpowied¹, z konieczno±ci¡ kolejkowania nowego »¡dania po stronie klienta do momentu otrzymania odpowiedzi na poprzednie zapytanie (ang.
request queuing ).
Koncepcja potokowania
pozwala na wysyªanie wielu »¡da«, a serwer przetwarza je, na bie»¡co kolejkuj¡c i przesyªaj¡c
odpowiedzi do klienta (ang.
response queuing ).
Przeniesienie kolejki komunikatów od klienta
do serwera pozwala skróci¢ czas obsªugi wszystkich »¡da« nawet do 2 okresów RTT (rys. 1.13).
Rysunek 1.13: Przebieg potokowania komunikatów [31].
Istotnym ograniczeniem mechanizmu poª¡cze« potokowych jest konieczno±¢ transmisji odpowiedzi we wªa±ciwej kolejno±ci, gdy» protokóª nie wspiera numerowania i przeplatania komunikatów. Wówczas oczekiwanie na obsªu»enie czasochªonnego »¡dania (ang.
blocking )
head-of-line
skutkuje niedostatecznym wykorzystaniem pasma oraz kosztami buforowania ju»
wygenerowanych odpowiedzi. Równie» obsªuga zerwanych poª¡cze« powoduje problem reemisji sekwencji komunikatów i powtórnego przetwarzania ich po stronie serwera.
Poª¡czenia potokowe nie upowszechniªy si¦ z powodu wymienionych komplikacji. Pomimo
tego, koncepcja potokowania komunikatów jest z powodzeniem stosowana w ±rodowisku, gdzie
klient i serwer s¡ ze sob¡ implementacyjnie sprz¦»one. Przykªadem jest infrastruktura aplikacji
iTunes,
która dzi¦ki zastosowaniu potokowania istotnie zwi¦kszyªa wydajno±¢ protokoªu [32].
Mechanizm komunikacji Wielko±¢ opó¹nienia
Transakcje sekwencyjne
Poª¡czenie trwaªe
Poª¡czenie potokowe
Poª¡czenia równolegªe
Requests ∗ 2 ∗ RT T
(Requests + 1) ∗ RT T
2 ∗ RT T
Latency/Connections
Tablica 1.3: Wielko±¢ opó¹nienia dla ró»nych mechanizmów komunikacji [58].
Podsumowuj¡c, mechanizmy dostarczone przez standard HTTP/1.1 stanowi¡ skuteczn¡
optymalizacj¦ protokoªu i zapewniaj¡ znaczn¡ redukcj¦ opó¹nienia transmisji (tab. 1.3).
16
Rozdziaª 2
Klient HTTP
Strona kliencka (ang.
user agent )
reprezentowana jest przez aplikacj¦ wysyªaj¡c¡ »¡dania
do serwera w postaci komunikatów protokoªu. W ogólno±ci mo»e to by¢ ka»de oprogramowanie
pobieraj¡ce i przetwarzaj¡ce zasoby sieci narz¦dzia linii polece« (curl,
wget ),
roboty inter-
netowe (Googlebot ) oraz przegl¡darki internetowe. Obecnie najpowszechniej u»ywanymi przegl¡darkami s¡: Google Chrome, Internet Explorer, Mozilla Firefox, Safari i Opera (rys. 2.1).
Rysunek 2.1: Popularno±¢ przegl¡darek internetowych [68].
2.1
Funkcjonalno±¢
Podstawowym zadaniem przegl¡darki internetowej (ang.
web browser )
jest pobranie wskaza-
nego zasobu oraz przedstawienie go w sposób czytelny dla u»ytkownika. W trywialnym przypadku transmisji pojedynczego zasobu, proces ten przebiega w nast¦puj¡ce sposób (rys. 2.2):
1. Translacja adresu URL przez usªug¦ DNS.
2. Nawi¡zanie poª¡czenia.
3. Wysªanie »¡dania do serwera.
4. Otrzymanie odpowiedzi serwera.
5. Zamkni¦cie poª¡czenia.
17
Rysunek 2.2: Schemat dziaªania przegl¡darki [31].
2.2
Architektura
Wspóªczesne przegl¡darki s¡ bardzo podobne w kontek±cie architektury. Najcz¦±ciej skªadaj¡
si¦ one z nast¦puj¡cych komponentów o jasno zdeniowanych odpowiedzialno±ciach (rys. 2.3):
Interfejs u»ytkownika
Silnik przegl¡darki
Silnik renderuj¡cy
Warstwa sieciowa
Warstwa graki
Interpreter
Umo»liwia interakcj¦ poprzez przyciski, karty, pasek adresu.
Przekazuje zdarzenia z interfejsu u»ytkownika do silnika renderuj¡cego.
Parsuje, interpretuje i wy±wietla zawarto±¢ »¡danego zasobu.
Obsªuguje transmisj¦ komunikatów HTTP i pobieranie zasobów.
Wy±wietla zasób w postaci gracznej interpretacji.
Parsuje i wykonuje kod JavaScript.
Warstwa danych
Magazyn przechowuj¡cy dane trwaªe.
18
Rysunek 2.3: Gªówne komponenty gracznej przegl¡darki internetowej [35].
Sposób interpretacji i wy±wietlania zasobów zdeniowany jest w specykacjach HTML
i CSS. Przez lata przegl¡darki tylko cz¦±ciowo dostosowywaªy si¦ do ocjalnych wytycznych,
co sprawiaªo wiele trudno±ci twórcom stron internetowych, gªównie w kwestii kompatybilno±ci.
Obecnie sytuacja ulegªa zmianie i przegl¡darki w znacznym stopniu realizuj¡ standardy.
Z drugiej strony, wspóln¡ cech¡ wszystkich przegl¡darek gracznych jest wygl¡d interfejsu
u»ytkownika. Aspekt ten nie zostaª w »aden sposób formalnie wyspecykowany, wywodzi si¦
natomiast z praktyk projektowych sprawdzonych na przestrzeni lat rozwoju przegl¡darek oraz
tendencji wzajemnego imitowania si¦ tych aplikacji.
2.3
Zasada dziaªania
Proces wy±wietlania strony obejmuje parsowanie kodu HTML, ewaluacj¦ arkuszy styli, wykonanie skryptów i renderowanie rezultatu na urz¡dzeniu wyj±ciowym (rys. 2.4):
Rysunek 2.4: Schemat budowania reprezentacji strony internetowej.
2.3.1 Pobieranie zasobów
Przegl¡darka pobiera kod HTML ze wskazanej lokalizacji oraz dostarcza zasoby zewn¦trzne,
co odbywa si¦ w osobnym potoku pobierania. Istotn¡ rol¦ odgrywa mechanizm pami¦ci podr¦cznej, który zapobiega ponownym transferom wcze±niej dostarczonych danych. Otrzymany
strumie« danych traa na wej±cie parsera (rys. 2.5).
19
Rysunek 2.5: Schemat parsowania dokumentu HTML.
2.3.2 Budowa drzewa DOM
Parser odpowiedzialny jest za budow¦ drzewa DOM (ang.
document object model ),
którego
w¦zªy reprezentuj¡ elementy HTML (rys. 2.6). Odniesienia do zasobów zewn¦trznych napotkane przez parser umieszczane s¡ w kolejce pobierania. Obecnie wiele stron internetowych
jest przestarzaªych, dlatego przegl¡darki udost¦pniaj¡ tryb zgodno±ci (ang.
quirks mode ).
Rysunek 2.6: Schemat budowy drzewa DOM.
2.3.3 Budowa drzewa CSSOM
Struktura strony deniowana jest za pomoc¡ kodu HTML, natomiast do specykacji wygl¡du
cascade style sheet ). Arkusz parsowany jest do postaci drzewa CSSOM
CSS object model ), którego w¦zªy reprezentuj¡ reguªy i selektory (rys. 2.7).
sªu»y arkusz CSS (ang.
(ang.
Rysunek 2.7: Schemat budowy drzewa CSSOM.
20
2.3.4 Budowa drzewa renderowania
Rezultatem poª¡czenia obiektów DOM i CSSOM jest drzewo renderowania (ang.
tree ).
rendering
Skªada si¦ ono z ramek opisuj¡cych sposób wy±wietlania elementów (rys. 2.8).
Rysunek 2.8: Schemat budowy drzewa renderowania.
2.3.5 Rozkªad ramek
Model renderowania (ang.
rendering model )
deniuje proces rozkªadania ramek (rys. 2.9),
który przebiega rekurencyjnie od korzenia do li±ci drzewa renderowania i ze wzgl¦dów wydajno±ciowych wykonywany jest jedynie w razie konieczno±ci (ang.
lazy layout ).
Rysunek 2.9: Schemat rozkªadania ramek.
2.3.6 Wy±wietlenie strony
Odrysowanie elementów strony równie» odbywa si¦ w sposób rekurencyjny przechodz¡c po w¦zªach drzewa renderowania. Proces ten mo»e by¢ cz¦±ciowo powtarzany ze wzgl¦du na dynamiczne zmiany zawarto±ci drzew DOM/CSSOM przez kod JavaScript. Za renderowanie
sprz¦towe odpowiada moduª graczny systemu operacyjnego, który realizuje je w nadmiarowej rozdzielczo±ci w celu optymalizacji skalowania widoku (ang.
21
zooming ).
2.4
Analiza dziaªania
Powszechnie wykorzystywanym sposobem analizy wydajno±ci przegl¡darki jest inspekcja kaskadowego widoku pobierania strony internetowej i jej zasobów (ang.
resource waterfall ).
Do jego uzyskania mo»na wykorzysta¢ rozszerzenie przegl¡darki lub serwis internetowy automatyzuj¡cy ten proces. Na potrzeby stworzenia kaskadowego widoku dla witryny
wy±wietlanej w przegl¡darce Firefox 23 posªu»ono si¦ narz¦dziem
WebPageTest.org
mit.edu
(rys. 2.10).
Rysunek 2.10: Kaskadowy widok zasobów.
Otrzymany widok pozwala na analiz¦ struktury dokumentu oraz sposobu dziaªania przegl¡darki. Mo»na zauwa»y¢, »e parsowanie kodu HTML odbywa si¦ w sposób przyrostowy,
umo»liwiaj¡c dynamiczne wykrycie odwoªania do zasobu zewn¦trznego i równolegªe wysªanie »¡dania tego obiektu, co objawia si¦ kaskadowym charakterem widoku. Mo»na zauwa»y¢,
»e klient wi¦kszo±¢ czasu sp¦dza na translacji adresów, zestawianiu poª¡cze« oraz oczekiwaniu na odpowied¹ serwera samo pobieranie danych stanowi uªamek caªkowitego opó¹nienia.
Sposób zarz¡dzania strumieniami TCP przedstawiono za pomoc¡ widoku poª¡cze« (rys. 2.11).
Rysunek 2.11: Widok poª¡cze«.
Sumarycznie, pobranie dokumentu i wszystkich zasobów zewn¦trznych zaj¦ªo 2974 ms,
z czego 2469 ms upªyn¦ªo na operacjach sieciowych (8 translacji adresów i 12 poª¡cze«) co
stanowi a» 83% caªego czasu. Dzi¦ki wykorzystaniu trwaªych i równolegªych strumieni TCP
oraz naªo»eniu opó¹nienia udaªo si¦ pobra¢ wszystkie zasoby w czasie 1015 ms. Transmisja
cechowaªa si¦ oszcz¦dnym zu»yciem przepustowo±ci ª¡cza (poni»ej 5 kB/s), co wskazuje raczej
na opó¹nienie jako gªówny problem w kontek±cie wydajno±ci pobierania stron internetowych.
22
2.5
Optymalizacja
Mimo »e przegl¡darka z perspektywy u»ytkownika jawi si¦ jako prosta aplikacja pobieraj¡ca i wy±wietlaj¡ca strony internetowe, to od strony implementacyjnej jest to rozbudowane
i skomplikowane oprogramowanie. Jak potwierdza nieustanna rywalizacja pomi¦dzy twórcami
przegl¡darek, rozwój tych aplikacji skupia si¦ wokóª optymalnego wykorzystania mechanizmów sieciowych oraz zwi¦kszenia wydajno±ci protokoªu HTTP, do których przyczyniaj¡ si¦
ni»ej opisane usprawnienia.
2.5.1 Równolegªo±¢ transferu i przetwarzania
Wspóªczesne przegl¡darki wykorzystuj¡ równolegªe poª¡czenia trwaªe w celu redukcji czasu
dostarczenia strony internetowej u»ytkownikowi ko«cowemu. Specykacja protokoªu HTTP
zaleca ograniczenie poª¡cze« trwaªych do 2 na serwer, jednak»e w praktyce limit ten cz¦sto
si¦ga 6 poª¡cze«. Warto równie» zrobi¢ u»ytek z mechanizmu poª¡cze« potokowych, który
cz¦sto mo»e zosta¢ aktywowany za po±rednictwem zaawansowanych ustawie« aplikacji. Ponadto z biegem czasu architektura przegl¡darek przeksztaªciªa si¦ z modelu jednoprocesowego
w wieloprocesowy. Pozwala ona na zrównoleglenie przetwarzania, zmniejszenie przywilejów
skryptów, izolacj¦ potencjalnie zªo±liwego kodu oraz zwi¦kszenie stabilno±ci.
2.5.2 Priorytetyzacja zasobów
W trakcie parsowania drzewa DOM napotkane zasoby zewn¦trzne zazwyczaj pobierane s¡
zgodnie z kolejno±ci¡ wyst¦powania w dokumencie, jednak»e przegl¡darka cz¦sto dokonuje
optymalizacji priorytetyzuj¡c je zgodnie z sekwencj¡: arkusze styli, skrypty, pozostaªe zasoby.
Uzasadnione jest to tym, »e arkusze styli nie maj¡ wpªywu na struktur¦ drzewa DOM, zatem
parsowanie dokumentu mo»e by¢ równolegle kontynuowane podczas ich pobierania i ewaluacji.
Natomiast skrypty mog¡ odwoªywa¢ si¦ do informacji zawartych w arkuszach styli, dlatego
te» w celu unikni¦cia bª¦dów wykonania powinny by¢ one dostarczone w nast¦pnej kolejno±ci.
2.5.3 Skanowanie wyprzedzaj¡ce
Ze wzgl¦du na to, »e skrypty mog¡ modykowa¢ struktur¦ drzewa DOM, proces parsowania
dokumentu nie mo»e post¦powa¢ dopóki napotkany skrypt nie zostanie wykonany. Wstrzymanie parsowania sprawia, »e pobieranie dalszych zasobów równie» jest zablokowane, a mechanizm równolegªego transferu pozostaje niewykorzystany. Rozwi¡zaniem tej niedogodno±ci
jest uruchomienie skanera wyprzedzaj¡cego (ang.
lookahead scanner ), który wyszukuje zasoby
do pobrania w dalszej cz¦±ci dokumentu.
2.5.4 Ograniczenie rozmiaru »¡da«
Nagªówki HTTP przesyªane s¡ w postaci nieskompresowanego tekstu na potrzeby zgodno±ci
wstecznej, co cz¦sto stanowi znaczny narzut na rozmiar komunikatu. Dodatkowym obci¡»eniem s¡ ciasteczka przesyªane z serwera do przegl¡darki i pó¹niej doª¡czane do ka»dego »¡dania (rys. 2.12). rednio nagªówki komunikatu HTTP zajmuj¡ 500-800 bajtów, ewentualnie
powi¦kszone o rozmiar ciasteczek rz¦du kilku kilobajtów. Przegl¡darki cz¦sto ograniczaj¡ rozmiar ciasteczek do 4 KB, jednak w przypadku wielu takich obiektów wysªanych przez serwer,
stanowi¡ one powa»ny narzut. Rozwi¡zaniem tego problemu jest dalsze ograniczenie rozmiaru
ciasteczek lub caªkowite ich zablokowanie (kosztem utraty funkcjonalno±ci zachowania stanu
np. zarz¡dzanie sesjami, personalizacja interfejsu, prowadzenie statystyk, etc.) [41].
23
Rysunek 2.12: Schemat dziaªania mechanizmu ciasteczek [31].
2.5.5 Pami¦¢ podr¦czna DNS
Tªumaczenie adresu URL na numer IP za pomoc¡ usªugi DNS zajmuje zwykle 20-120 ms
i do tego czasu przegl¡darka nie mo»e pobra¢ zasobu, którego translacja dotyczy. W celu
zwi¦kszenia wydajno±ci wyniki tego procesu przechowywane s¡ w pami¦ci podr¦cznej na serwerze dostawcy internetowego oraz lokalnie w systemie operacyjnym i przegl¡darce. Zale»nie
od przegl¡darki, wpisy w pami¦ci podr¦cznej uniewa»niane s¡ po okresie 1-30 minut, jednak
korzystnym rozwi¡zaniem jest przedªu»enie tego czasu nawet do 60 minut [4].
2.5.6 Akcje wyprzedzaj¡ce
Nowatorskim rozwi¡zaniem jest mechanizm uczenia si¦ przegl¡darki i przewidywania akcji
u»ytkownika (tab. 2.1). Na podstawie sugestii zawartej w dokumencie HTML, wykrytego
wzorca nawigacji pomi¦dzy stronami lub najechania kursorem na odno±nik mo»na okre±li¢
prawdopodobie«stwo przyszªego wykorzystania danego zasobu [26]. Je±li jest ono znaczne, zapytanie DNS, zestawienie poª¡czenia TCP, transfer danych oraz renderowanie b¦dzie odbywa¢
si¦ z wyprzedzeniem, co mo»e zredukowa¢ czas oczekiwania o kilka okresów RTT.
Sugestia akcji wyprzedzaj¡cej
<link
<link
<link
<link
rel="dns-prefetch" href="abc.com">
rel="subresource" href="script.js">
rel="prefetch" href="image.jpg">
rel="prerender" href="about.html">
Opis
Translacja DNS adresu URL
Pobranie zasobu zaª¡czonego dalej na stronie
Pobranie zasobu na bie»¡cy lub przyszªy u»ytek
Prerenderowanie wskazanej strony
Tablica 2.1: Sugestie akcji wyprzedzaj¡cych.
24
2.6
Parametryzacja
Wspóªczesne przegl¡darki udost¦pniaj¡ wiele mo»liwo±ci konguracyjnych zwi¡zanych z dziaªaniem protokoªu HTTP. Domy±lne warto±ci parametrów protokoªu s¡ optymalne dla wi¦kszo±ci stron internetowych, ich modykacja mo»e jednak poprawi¢ wydajno±¢ w niektórych
przypadkach. Dost¦pne opcje parametryzacji dla ró»nych przegl¡darek przedstawiono poni»ej.
Firefox
Przegl¡darka Firefox udost¦pnia narz¦dzie sªu»¡ce do konguracji zaawansowanych ustawie«
aplikacji pod adresem
about:config.
Wiele zmiennych dotyczy protokoªu HTTP (tab. 2.2).
Nazwa
keep-alive
keep-alive.timeout
max-connections
max-connections-per-server
max-persistent-connections-per-server
pipelining
pipelining.maxrequests
Warto±¢
True
300
Opis
Aktywacja poª¡cze« trwaªych.
Czas bezczynno±ci poª¡cze« trwaªych.
30
Limit poª¡cze«.
15
Limit poª¡cze« na serwer.
6
True
4
Limit poª¡cze« trwaªych na serwer.
Aktywacja poª¡cze« potokowych.
Limit »¡da« poª¡czenia potokowego.
Tablica 2.2: Wybrane parametry przegl¡darki Firefox.
Opera
Przegl¡darka Opera dostarcza narz¦dzie konguracyjne pod adresem
opera:config. Odszuka-
nie parametrów protokoªu HTTP jest trudne, gdy» znajduj¡ si¦ w ró»nych sekcjach (tab. 2.3).
Nazwa
Warto±¢
Enable Pipeling
True
Max Connections Server
Max Connections Total
Max Persistent Connections Server
No Connection Keepalive
8
Limit poª¡cze« na serwer.
20
Caªkowity limit poª¡cze«.
6
False
HTTP Idle Timeout
Opis
(brak)
Limit poª¡cze« trwaªych na serwer.
Dezaktywacja poª¡cze« trwaªych.
Maksymalny czas bezczynno±ci.
Tablica 2.3: Wybrane parametry przegl¡darki Opera.
Google Chrome
Przegl¡darka Google Chrome pozwala na modykacj¦ zaawansowanych ustawie« pod adresem
about:flags,
jednak»e znikoma ich liczba dotyczy protokoªu HTTP (tab. 2.4).
Nazwa
Warto±¢
Opis
HTTP Pipeling
False
Enable SPDY/3
False
Aktywacja protokoªu SPDY.
Tablica 2.4: Wybrane parametry przegl¡darki Google Chrome.
25
Rozdziaª 3
Serwer HTTP
Rol¡ serwera implementuj¡cego protokóª HTTP jest udost¦pnianie zasobów oraz dostarczenie
narz¦dzi administracyjnych umo»liwiaj¡cych dostosowanie i rozszerzanie jego funkcjonalno±ci.
Do obsªugi »¡da« w du»ej mierze wykorzystywany jest system operacyjny, który odpowiada
za obsªug¦ stosu TCP/IP, dost¦p do systemu plików oraz zarz¡dzanie procesami i w¡tkami.
Obecnie do najpopularniejszych serwerów nale»¡:
Apache, Microsoft-IIS, Nginx
Rysunek 3.1: Popularno±¢ serwerów HTTP [53].
3.1
Funkcjonalno±¢
Wymagania stawiane wspóªczesnym serwerom obejmuj¡:
•
wielozadaniowo±¢, wydajne obsªugiwanie wielu »¡da« na raz,
•
zapewnienie bezpiecze«stwa, werykacja u»ytkowników i przywilejów,
•
mechanizm obsªugi bª¦dów,
•
mechanizm negocjacji reprezentacji zasobu z klientem,
•
wsparcie wielu j¦zyków i formatów zasobów,
•
tworzenie wielu serwerów wirtualnych na jednym interfejsie sieciowym.
26
(rys. 3.1).
3.2
Architektura
Zale»nie od architektury serwery HTTP s¡ w stanie obsªu»y¢ od pojedynczego komunikatu
do tysi¡ca równolegªych »¡da« klientów (rys. 3.2).
Rysunek 3.2: Ró»ne sposoby obsªugi operacji wej±cia/wyj±cia przez serwer HTTP [31].
Obecnie wspóªistniej¡ 2 popularne i wysokowydajne architektury serwerów wieloprzepªywowa oraz zdarzeniowa. Oprócz tego pojawiª si¦ zaawansowany wariant ª¡cz¡cy oba te
podej±cia i zapewniaj¡cy du»¡ skalowalno±¢ rozwi¡zania [59].
3.2.1 Podej±cie wieloprzepªywowe
Architektura wieloprzepªywowa bazuje na synchronicznym wykonywaniu operacji wej±ciawyj±cia. Nadchodz¡ce »¡dania przetwarzane s¡ w obr¦bie osobnych przepªywów instrukcji
(w¡tek, proces) tworzonych w razie potrzeby lub z wyprzedzeniem (ang.
worker pool ).
Dzi¦ki
temu nadchodz¡ce komunikaty mog¡ by¢ izolowane i obsªugiwane równolegle [69].
Wieloprocesowo±¢
Wedªug pierwotnej koncepcji do obsªugi poª¡cze« delegowano procesy, co pozwala na ªatw¡
izolacj¦ »¡da«, gdy» nie dziel¡ one wspólnej pami¦ci. Jako »e powoªywanie procesów jest
kosztowne pod wzgl¦dem zu»ywanych zasobów sprz¦towych, rozwi¡zaniem jest tworzenie ich
na pocz¡tku, a nast¦pnie wielokrotne u»ywanie (rys. 3.3).
27
Rysunek 3.3: Schemat wieloprocesowej obsªugi »¡da« [23].
Wielow¡tkowo±¢
Oprócz wieloprocesowego przetwarzania »¡da«, z czasem upowszechniªo si¦ podej±cie wykorzystuj¡ce w¡tki, które stanowi¡ l»ejsz¡ jednostk¦ przepªywu. Gªówn¡ ró»nic¡ jest wspóªdzielenie
przestrzeni adresowej i konieczno±¢ synchronizacji dost¦pu do wspólnych zasobów, jednak przy
mniejszym obci¡»eniu pami¦ciowym.
W praktyce, zastosowanie w¡tków polega na otrzymywaniu nowych poª¡cze« przez dyspozytora, który umieszcza je w kolejce obsªugiwanej przez pul¦ w¡tków (rys. 3.4). W ten sposób
ªatwo mo»na kontrolowa¢ liczb¦ obsªugiwanych poª¡cze« oraz aktywnych w¡tków, co pozwala
na unikni¦cie przeci¡»enia serwera.
Rysunek 3.4: Schemat wielow¡tkowej obsªugi »¡da« [23].
3.2.2 Podej±cie zdarzeniowe
Alternatyw¡ dla synchronicznych, blokuj¡cych operacji wej±cia-wyj±cia jest podej±cie zdarzeniowe (ang.
event-driven ).
Zdarzenia mog¡ by¢ generowane przez ¹ródªa takie jak gniazda
sieciowe, potoki, pliki, których stan wej±cia-wyj±cia jest monitorowany pod k¡tem aktywno±ci
(ang.
multiplexed I/O ).
Pojawiaj¡ce si¦ w ten sposób zdarzenia konsumowane s¡ przez p¦tl¦
zdarze« i sekwencyjnie przekazywane do skojarzonych procedur obsªugi.
28
Wzorzec Reactor
Wzorzec
Reactor
oparty jest o synchroniczn¡ i nieblokuj¡c¡ obsªug¦ operacji wej±cia-wyj±cia.
Idea polega na zarejestrowaniu zasobów i generowanych przez nie zdarze« (np. gniazdo i nowe
poª¡czenie). Do ka»dego zdarzenia kojarzona jest równie» funkcja obsªugi (ang.
callback ) [63].
Gªównym komponentem jest synchroniczny demultiplekser, który w obliczu wyst¡pienia
zdarzenia w kontek±cie zarejestrowanego zasobu powiadamia dyspozytora (ang.
dispatcher )
wywoªuj¡cego w odpowiedzi skojarzon¡ funkcj¦ obsªugi (rys. 3.5).
Rysunek 3.5: Schemat przetwarzania zdarze« [23].
Wzorzec Proactor
Z kolei
Proactor
jest asynchronicznym wariantem wzorca
Reactor.
Gªównym komponentem
jest proaktywny inicjator odpowiedzialny za wyzwolenie operacji wej±cia-wyj±cia oraz zarejestrowanie procedury obsªugi wraz z odpowiednim dyspozytorem, który w ramach obsªugi
zdarzenia wywoªuje podan¡ funkcj¦. Nadzór nad obªug¡ operacji peªni asynchroniczny zarz¡dca, który zazwyczaj stanowi cz¦±¢ systemu operacyjnego [60].
Rozwi¡zanie hybrydowe
Najbardziej skalowalnym rozwi¡zaniem jest poª¡czenie cech architektury wieloprzepªywowej
oraz zdarzeniowej, czego rezultatem jest podej±cie hybrydowe. Przykªadem mo»e by¢ podziaª
logiki serwera na etapy przetwarzania »¡da«, które s¡ przekazywane mi¦dzy nimi za po±rednictwem kolejek (rys. 3.6). Ka»dy etap obsªugiwany jest przez niezale»n¡ pul¦ w¡tków kongurowaln¡ zale»nie od obci¡»enia, co pozwala na efektywne wykorzystanie mocy obliczeniowej [71].
Rysunek 3.6: Schemat wieloetapowego przetwarzania »¡da« [23].
29
3.3
Zasada dziaªania
Do obowi¡zku wi¦kszo±ci serwerów HTTP nale»y wykonywanie dalej opisanych zada« (rys. 3.7).
Rysunek 3.7: Schemat zasady dziaªania serwera HTTP [31].
3.3.1 Przyj¦cie poª¡czenia
Je±li klient zestawiª poª¡czenie trwaªe do serwera, mo»e je wykorzysta¢ do wysªania »¡dania,
w przeciwnym wypadku konieczne jest nawi¡zanie nowego (rys. 3.8). O ile to mo»liwe, serwer
akceptuje poª¡czenie i monitoruje pod k¡tem przysyªanych danych.
Rysunek 3.8: Nawi¡zanie poª¡czenia TCP z serwerem [31].
30
3.3.2 Otrzymanie »¡dania
W momencie pojawienia si¦ danych serwer pobiera je i parsuje do formatu »¡dania (rys. 3.9).
Zale»nie od implementacji, dane buforowane s¡ do momentu otrzymania caªego, logicznego
komunikatu lub przekazywane na bie»¡co do aplikacji sieciowej. Pierwsze rozwi¡zanie ma
znaczenie w kontek±cie wolnego poª¡czenia, drugie natomiast redukuje opó¹nienie.
Rysunek 3.9: Parsowanie danych do formatu »¡dania [31].
3.3.3 Przetworzenie »¡dania
Po odebraniu »¡dania serwer przetwarza je zgodnie z wyspecykowan¡ metod¡ dost¦pu, adresem URL, wytycznymi zawartymi w nagªówku oraz opcjonalnymi danymi, mapuj¡c te informacje na odpowiedni zasób. Obsªuga »¡dania mo»e polega¢ nie tylko na udost¦pnieniu
statycznego zasobu z systemu plików, ale równie» dynamicznie generowanego za po±rednictwem programu po stronie serwera lub funkcji aplikacji sieciowej (rys. 3.10)
Rysunek 3.10: Schemat mapowania adresu URL do zasobu serwera [31].
31
3.3.4 Konstrukcja odpowiedzi
Zasób zidentykowany w poprzednim kroku przesyªany jest przez serwer w postaci komunikatu odpowiedzi, który zawiera kod statusu, nagªówki oraz opcjonalne dane. W przypadku
dostarczania danych, serwer wybiera format najbardziej odpowiadaj¡cy »¡daniu klienta, specykuje typ MIME w polu
Content-Type
oraz rozmiar transferu w polu
Content-Length.
Niekiedy odpowied¹ serwera mo»e by¢ równie» przekierowaniem klienta do innego miejsca,
podanego w polu
Location
(rys. 3.11).
Rysunek 3.11: Przekierowanie klienta do innego serwera [31].
3.3.5 Wysªanie odpowiedzi
Wysyªanie odpowiedzi do poª¡czonego klienta jest symetryczn¡ operacj¡ do pobierania »¡dania. Podobnie transfer mo»e by¢ buforowany do czasu zbudowania caªego komunikatu lub
przekazywany na bie»¡co do klienta. Wa»nym elementem jest ±ledzenie stanu poª¡cze« trwaªych, gdy» mog¡ zosta¢ zamkni¦te przez klienta w ka»dej chwili, jak równie» ustawianie odpowiedniego rozmiaru danych w polu
Content-Length,
poniewa» klient nie b¦dzie w stanie
stwierdzi¢ zako«czenia przesyªania danych.
3.4
Komponenty sieci
Oprócz klientów i serwerów istnieje wiele innych komponentów sieci, najcz¦±ciej peªni¡cych
funkcj¦ w¦zªów po±rednicz¡cych. Mo»na wyró»ni¢ ich nast¦puj¡ce rodzaje:
•
Proxy po±rednik w komunikacji pomi¦dzy w¦zªami, potencjalnie modykuj¡cy komunikaty HTTP, najcz¦±ciej na potrzeby ukrycia to»samo±ci klienta, transformacji danych,
ltrowania anonimowych »¡da« i blokowania niedozwolonej zawarto±ci (rys. 3.12).
•
Pami¦¢ podr¦czna (ang. cache ) w¦zeª po±rednicz¡cy, którego zadaniem jest buforowanie kopii cz¦sto pobieranych zasobów w celu ich udost¦pniania z pomini¦ciem serwera,
co powoduje skrócenie ±cie»ki komunikacji oraz redukcj¦ czasu odpowiedzi (rys. 3.13).
•
Brama (ang. gateway ) warstwa odseparowuj¡ca w¦zªy innej sieci, które wykorzystuj¡
odmienny protokóª aplikacyjny, wymagaj¡cy tªumaczenia komunikatów (rys. 3.14).
•
Tunel (ang. tunnel ) przeka¹nik po±rednicz¡cy pomi¦dzy dwoma w¦zªami sieci w sposób transparentny, najcz¦±ciej wykorzystywany do niemodykuj¡cej transmisji komunikatów innych protokoªów w obr¦bie poª¡cze« HTTP (rys. 3.15).
32
Rysunek 3.12: Schemat dziaªania proxy.
Rysunek 3.13: Schemat dziaªania pami¦ci podr¦cznej.
Rysunek 3.14: Schemat dziaªania bramy.
Rysunek 3.15: Schemat dziaªania tunelu.
33
3.5
Optymalizacja
Na popraw¦ efektywno±ci protokoªu HTTP wpªyw ma nie tylko wybór i sparametryzowanie przegl¡darki, lecz równie» odpowiednie skongurowanie serwera (rys. 3.16). Wska¹nikiem
wydajno±ci tej strony komunikacji jest najcz¦±ciej czas tworzenia i dostarczenia dokumentu
do klienta (ang.
time to rst byte ).
W tym kontek±cie optymalizacja dotyczy gªównie spo-
sobu generowania strony internetowej oraz strategii udost¦pniania zasobów z uwzgl¦dnieniem
pami¦ci podr¦cznej i rozproszonej infrastruktury dostarczania danych.
Rysunek 3.16: Optymalizacja klienta i serwera [42].
3.5.1 Unikanie przekierowa«
Obecnie przekierowania wykorzystywane s¡ najcz¦±ciej do nawigowania mi¦dzy ró»nymi cz¦±ciami strony internetowej, zale»nie od pewnych uwarunkowa« klienta (np. typ przegl¡darki,
rodzaj konta u»ytkownika). Serwer realizuje staªe lub tymczasowe przekierowanie specykuj¡c
kod o warto±ci odpowiednio 301 lub 302 oraz nowy adres zasobu w polu nagªówka
Location:
HTTP/1.1 301 Moved Permanently
Location: http://example.com/contact.html
Content-Type: text/html
Przekierowanie mo»e by¢ równie» zrealizowane na poziomie kodu HTML (znacznik
lub JavaScript (atrybut
location),
<meta>)
jednak preferowan¡ technik¡ jest wykorzystanie statusu
odpowiedzi HTTP, ze wzgl¦du na zapewnienie poprawnego dziaªania nawigacji przegl¡darki.
Negatywny wpªyw przekierowa« polega na wydªu»eniu czasu otrzymania i wy±wietlenia zasobu w przegl¡darce, dlatego te» nale»y ich unika¢ podczas projektowania aplikacji sieciowej.
3.5.2 Obsªuga pola Expires
Wygl¡d i interaktywno±¢ stron internetowych stale si¦ wzbogaca, co skutkuje doª¡czaniem
wi¦kszej liczby skryptów, styli, obrazów i zawarto±ci Flash. Klient odwiedzaj¡cy dan¡ stron¦
po raz pierwszy wykonuje wiele »¡da« HTTP, aby pobra¢ wszystkie zasoby. Aby unikn¡¢ powtórnego pobierania tych komponentów podczas kolejnych wizyt warto umie±ci¢ je w pami¦ci
podr¦cznej za pomoc¡ specykacji daty wa»no±ci zasobu w polu
Expires:
Expires: Thu, 18 Apr 2013 20:00:00 GMT
Serwer HTTP umo»liwia ustawienie daty wa»no±ci wzgl¦dem aktualnego »¡dania odmiennie dla ró»nych typów danych, co automatyzuje proces dodawania pola nagªówka.
34
3.5.3 Konguracja znaczników ETag
Znaczniki ETag (ang.
entity tags )
sªu»¡ do unikalnego identykowania zasobów na potrzeby
walidacji sprawdzania czy obiekt w pami¦ci podr¦cznej klienta wci¡» ma swój niezmieniony
odpowiednik na serwerze. Jest to bardziej elastyczne rozwi¡zanie ni» posªugiwanie si¦ dat¡
ostatniej modykacji zasobu specykowanej w polu
Serwer HTTP przekazuje znacznik w polu
ETag
Last-Modified.
nagªówka odpowiedzi. W momencie wali-
dacji komponentu znajduj¡cego si¦ w pami¦ci podr¦cznej klient odsyªa jego znacznik w polu
If-None-Match.
Je±li znaczniki dla obu stron komunikacji s¡ zgodne, zwrócenie zawarto±ci
zasobu przez serwer mo»e zosta¢ pomini¦te (rys. 3.17).
Rysunek 3.17: Schemat obsªugi znacznika ETag [31].
Problem zwi¡zany ze znacznikami ETag polega na tym, »e cz¦sto s¡ one konstruowane
na bazie atrybutów zapewniaj¡cych im unikalno±¢ w obr¦bie danego serwera (np. metadane
opisuj¡ce plik zasobu lub wersja ustawie« konguracyjnych). Je±li zasoby udost¦pniane s¡
za po±rednictwem klastra serwerów, znacznik uzyskany z jednego w¦zªa nie b¦dzie zgodny
dla tego samego zasobu w innym w¦¹le z grupy.
Wskutek tego zamiast otrzymania zwi¦zªej odpowiedzi
Not Modified
klient musi pobra¢
caª¡ zawarto±¢ zasobu, co powoduje zu»ycie transferu, wzrost opó¹nienia i degradacj¦ wydajno±ci pami¦ci podr¦cznej. Dlatego te» nale»y odpowiednio skongurowa¢ serwer w kontek±cie
generowania znaczników lub caªkowicie wyª¡czy¢ t¦ funkcj¦, polegaj¡c jedynie na walidacji
obiektu za pomoc¡ daty ostatniej modykacji.
3.5.4 Zastosowanie kompresji
W wersji protokoªu HTTP/1.1 klient ma mo»liwo±¢ sygnalizacji wsparcia mechanizmu kompresji za pomoc¡ pola nagªówka
Accept-Encoding:
Accept-Encoding: gzip, deflate
W odpowiedzi na takie »¡danie serwer mo»e skompresowa¢ przesyªane dane za pomoc¡
jednej z metod wspieranych przez klienta i wyspecykowa¢ j¡ w polu
Content-Encoding: gzip
35
Content-Encoding:
Mechanizm gzip b¦d¡cy rozszerzeniem deate jest aktualnie najpopularniejszym sposobem kompresji dla protokoªu HTTP, bowiem pozwala on na zmniejszenie rozmiaru zasobu
w postaci pliku tekstowego nawet o 70%, co przekªada si¦ na ogóln¡ redukcj¦ rozmiaru strony
internetowej (rys. 3.18). Algorytm ten polega na wykryciu jednakowych fragmentów tekstu
i zast¡pieniu ich krótkim identykatorem, dlatego te» z powodzeniem stosowany jest wobec
zawarto±ci HTML, XML, JSON, CSS i JavaScript, które zawieraj¡ powtarzaj¡ce si¦ sªowa
kluczowe, denicje, nazwy i biaªe znaki.
Rysunek 3.18: Redukcja rozmiaru danych za pomoc¡ kompresji [31].
Podczas konguracji serwera HTTP mo»liwe jest wskazanie typów danych podlegaj¡cych
kompresji. Zaleca si¦ stosowanie jej do wszelkiego rodzaju danych tekstowych, w przeciwie«stwie do obrazów i dokumentów PDF, które s¡ pierwotnie kompresowane, a powtórna próba
zmniejszenia ich rozmiaru najcz¦±ciej ma skutek odwrotny do oczekiwanego [20].
3.5.5 Partycjonowanie domeny
Ograniczenie ze specykacji HTTP/1.x dopuszczaj¡ce zestawianie maksymalnie 2 poª¡cze«
do pojedynczego serwera szybko staªo si¦ nieaktualne i zostaªo nieformalnie rozszerzone przez
twórców przegl¡darek do 6 strumieni. Jednak»e dla rozbudowanych aplikacji sieciowych wci¡»
mo»e by¢ to niewystarczaj¡ce, bowiem popularne portale skªadaj¡ si¦ nawet z kilkuset komponentów zewn¦trznych, któr¡ musz¡ zosta¢ sprawnie dostarczone do strony klienckiej.
Taka ilo±¢ zasobów mo»e powodowa¢ znaczne opó¹nienia zwi¡zane z kolejkowaniem »¡da« w przypadku pobierania ich z tego samego serwera. W odpowiedzi na ten problem
stosuje si¦ obej±cie polegaj¡ce na rozdystrybuowaniu zasobów w obr¦bie kilku subdomen
(np.
s1.abc.com, s2.abc.com dla domeny abc.com), poniewa» odmienne adresy URL s¡ inter-
pretowane przez przegl¡darki jako odr¦bne serwery, co powoduje zwi¦kszenie limitu poª¡cze«.
Optymalna liczba partycji, na jak¡ nale»y podzieli¢ domen¦ zale»y od ilo±ci zasobów strony,
dost¦pnej przepustowo±ci sieci oraz opó¹nienia transferu, jednak zazwyczaj nie przekracza
2 subdomen. Rozpraszanie zasobów na wiele partycji jest pracochªonne i uci¡»liwe, ponadto
niewiele serwisów mo»e wydajnie wykorzysta¢ wi¦cej ni» 12 jednoczesnych poª¡cze« TCP.
Stosowanie partycjonowania domen jest cz¦sto nadu»ywane, przyczyniaj¡c si¦ do wzrostu
liczby translacji DNS oraz krótkich poª¡cze« TCP dziaªaj¡cych w trybie
slow start, co w efekcie
prowadzi do zmniejszenia komfortu pracy u»ytkownika. Zwykle znacznie wi¦ksze korzy±ci
mo»na osi¡gn¡¢ poprzez zmniejszenie liczby »¡da« HTTP, eliminuj¡c lub ª¡cz¡c zasoby [31].
36
3.5.6 Wykorzystanie infrastruktury CDN
Niewielka odlegªo±¢ klienta od serwera ma znamienny wpªyw na czas odpowiedzi, zwªaszcza
»e 80-90% wielko±ci opó¹nienia odczuwanego przez u»ytkownika zwi¡zane jest z pobieraniem
danych. Rearan»acja architektury aplikacji sieciowej na potrzeby wydajnego dostarczania zawarto±ci jest kosztownym przedsi¦wzi¦ciem, z tego wzgl¦du lepszym rozwi¡zaniem jest replikacja udost¦pnianych zasobów i rozprowadzenie ich na wiele oddalonych od siebie maszyn.
Sªu»y do tego infrastruktura CDN (ang.
content delivery network ) stanowi¡ca zbiór serwerów
rozproszonych geogracznie i znajduj¡cych si¦ w strategicznych lokalizacjach (rys. 3.19).
Rysunek 3.19: Rozproszenie zasobów w obr¦bie infrastruktury CDN [13].
Korzy±ci pªyn¡ce z wykorzystania systemu CDN wynikaj¡ z jego rozproszonego charakteru:
•
Minimalizacja odlegªo±ci Do obsªugi »¡dania klienta delegowany jest serwer znajduj¡cy si¦ najbli»ej w kontek±cie w¦zªów po±rednich, co redukuje czas odpowiedzi nawet
o 20% oraz powoduje zmniejszenie wariancji opó¹nienia (ang.
jitter ),
która cz¦sto za-
uwa»alna jest podczas strumieniowania zasobów audio/wideo.
•
Decentralizacja serwerów Infrastruktura skªadaj¡ca si¦ z wielu punktów obsªugi »¡da« oferuje wysok¡ odporno±¢ na gwaªtowny wzrost obci¡»enia oraz ataki DoS (ang.
nial of service ),
de-
gdy» w przypadku zakªócenia pracy grupy serwerów, system wci¡»
b¦dzie dost¦pny za po±rednictwem pozostaªych maszyn.
•
Redundancja danych Zwielokrotnienie zasobów w obr¦bie wielu serwerów zapewnia
bezpiecze«stwo i ªagodn¡ degradacj¦ systemu (ang.
fail-safe )
na wypadek uszkodzenia
lub nieprawidªowego funkcjonowania fragmentu sieci Internet. Wªa±ciwo±¢ redundancji
i relokacji zasobów oznacza równie» posiadanie wielu kopii zapasowych, co jest po»¡dan¡
cech¡ w przypadku ryzyka utraty danych.
Najwi¦ksze rmy internetowe posiadaj¡ wªasn¡ sie¢ CDN, jednak dla niewielkich organizacji bardziej opªacalne jest skorzystanie z usªug dostawcy takiej infrastruktury (np. Akamai,
EdgeCast). Najcz¦±ciej wykorzystywana jest ona w celu wydajnego dostarczania zawarto±ci
multimedialnych i niezawodnego dziaªania telewizji internetowej IPTV [55].
37
Rozdziaª 4
Zasób sieci
Zasobem nazywa si¦ dowoln¡ zawarto±¢ znajduj¡c¡ si¦ w sieci, która jest udost¦pniana klientom za po±rednictwem serwera. Najprostszym typem zasobu jest statyczny obiekt znajduj¡cy
si¦ w systemie plików serwera, w ogólno±ci zapisany w ka»dym mo»liwym formacie danych
(np. plik tekstowy, obraz, dokument HTML, zawarto±¢ audio/wideo).
Jednak»e zasoby mog¡ równie» funkcjonowa¢ jako programy, które generuj¡ tre±¢ dynamicznie (rys. 4.1). Tak szeroka interpretacja zasobu umo»liwia udost¦pnianie tymczasowej lub
szybko zmieniaj¡cej si¦ informacji, trudno reprezentowalnej za pomoc¡ statycznych plików
(np. transmisja wideo na »ywo, przebieg kursów akcji, zakupy on-line).
Rysunek 4.1: Statyczne i dynamiczne zasoby sieci [31].
38
4.1
Ewolucja zasobu sieci
Rozwój Internetu na przestrzeni dekad poskutkowaª pojawieniem si¦ ró»nego rodzaju zasobów:
Dokument hipertekstowy
Geneza globalnej sieci zwi¡zana jest z udost¦pnianiem niewiel-
kich dokumentów tekstowych o prostym formatowaniu z osadzonymi odno±nikami do innych obiektów. Obsªug¦ takiego zasobu zapewniaª protokóª HTTP/0.9 na zasadzie nawi¡zania poª¡czenia, realizacji pojedynczego »¡dania i zako«czenia transakcji. Idea ta
przetrwaªa przez lata b¦d¡c podstaw¡ rozwoju projektu WWW oraz protokoªu HTTP.
Strona internetowa
Wkrótce koncepcja dokumentu hipertekstowego zostaªa rozszerzona
do poj¦cia strony internetowej skªadaj¡cej si¦ z wielu zasobów zewn¦trznych (rys. 4.2).
Du»y wpªyw na to zjawisko miaªo pojawienie si¦ technologii HTML/CSS oraz dostarczenia wsparcia dla zasobów multimedialnych. Skutkiem tych innowacji byªa równie»
konieczno±¢ wprowadzenia kolejnej wersji HTTP/1.x wzbogacaj¡cej protokóª o obsªug¦
nagªówków, poª¡cze« trwaªych, pami¦ci podr¦cznej, etc.
Aplikacja sieciowa
Wraz z pojawieniem si¦ ró»nych mechanizmów DHTML (ang.
Dynamic
HTML), zwªaszcza j¦zyka JavaScript oraz technologii AJAX, strony internetowe zacz¦ªy
przeksztaªca¢ si¦ w rozbudowane aplikacje sieciowe wykonuj¡ce kod po stronie klienta,
wykorzystuj¡ce »¡dania asynchroniczne i stanowi¡ce zªo»ony graf zasobów znaczników deniuj¡cych struktur¦, styli okre±laj¡cych wygl¡d oraz skryptów odpowiadaj¡cych
za interakcj¦ z u»ytkownikiem.
Rysunek 4.2: Zasoby zewn¦trzne strony internetowej [31].
4.2
Pomiary zasobów internetowych
Wspóªcze±nie coraz bardziej powszechne staje si¦ analizowanie historii ró»nych zmian technologicznych, przede wszystkim w celu inspekcji zdarze« z przeszªo±ci, ich wpªywu na obecn¡
sytuacj¦ oraz pojawiaj¡ce si¦ trendy. Dlatego te» zdano sobie spraw¦ z kulturowego znaczenia
globalnej sieci i potrzeby archiwizowania zmian w niej zachodz¡cych. Wiele organizacji podj¦ªo
si¦ zadania zbierania i przechowywania informacji dotycz¡cych zasobów Internetu [73].
39
4.2.1 Pomiary Google
Oprócz ekstrakcji zawarto±ci stron internetowych oraz ich indeksowania efektami dziaªania
robota
Googlebot
jest dostarczanie podstawowych pomiarów zwi¡zanych z napotkanymi zaso-
bami. Mierzonymi atrybutami s¡: ilo±¢ oraz typ zasobów zewn¦trznych, rozmiar dokumentu,
skuteczno±¢ mechanizmu kompresji (tab. 4.1). Na wiarygodno±¢ statystyk du»y wpªyw ma
liczba przeanalizowanych stron, która si¦ga kilku miliardów. Do czynników wpªywaj¡cych
na rzetelno±¢ rezultatów mo»na zaliczy¢ nast¦puj¡ce kwestie [61]:
robots.txt.
•
Niektóre strony blokuj¡ dost¦p do plików CSS i JS poprzez wytyczne pliku
•
W kwestii kompresji danych cz¦±¢ witryn prezentuje robotowi odmienne reprezentacje
zasobów ni» zwykªym klientom.
•
Robot bazuje na silniku WebKit, a zasoby mog¡ by¢ serwowane warunkowo w zale»no±ci
od rodziny przegl¡darki.
•
Zbiór analizowanych stron zwi¡zany jest z ich pozycj¡
Atrybut
Warto±¢
PageRank
[11].
Opis
Strony
4.2 × 109
Zasoby
43.9
rednia liczba zewn¦trznych zasobów
¡dania GET
44.6
rednia liczba »¡da« typu GET
Hosty
7.01
rednia liczba unikalnych hostów
Zasoby na host
6.26
rednia liczba zasobów na host
Wielko±¢ transferu
320 KB
rednia liczba przesªanych bajtów
Rozmiar dokumentu
376 KB
redni caªkowity rozmiar strony
Zastosowanie kompresji
66%
Udziaª skompresowanych danych
Obrazy
29.4
rednia liczba obrazów
Rozmiar obrazów
206 KB
redni rozmiar obrazów
Skrypty
7.09
rednia liczba skryptów
Rozmiar skryptów
58.0 KB
redni rozmiar skryptów
¡czenie skryptów
3.75
rednia liczba nadmiarowych »¡da« skryptów
Arkusze styli
3.22
rednia liczba zewn¦trznych arkuszy styli
Rozmiar arkuszy styli
18.7 KB
redni rozmiar arkuszy styli
¡czenie arkuszy styli
2.02
rednia liczba nadmiarowych »¡da« arkuszy styli
Liczba przeanalizowanych stron
Tablica 4.1: Wyniki pomiarów stron internetowych robota Google (2010 r.).
Najwa»niejsze wnioski wynikaj¡ce z zebranych danych:
•
redni rozmiar strony internetowej w 2010 r. wynosi 320 KB.
•
Jedynie 66% kompresowalnych danych jest faktycznie skompresowanych.
•
W przypadku 80% stron co najmniej 10 zasobów pobieranych jest z tego samego serwera.
•
Gdyby wszystkie skrypty oraz arkusze styli znajduj¡ce si¦ na jednym serwerze zostaªy
poª¡czone, zaoszcz¦dzonoby co najmniej 5 »¡da« HTTP.
40
4.2.2 Pomiary wªasne
W celu ewaluacji ocjalnych pomiarów oraz poszerzenia zbioru informacji na temat struktury statystycznego dokumentu HTML, w ramach cz¦±ci projektowej powtórzono badania
we wªasnym zakresie. Wst¦pnie rozwa»ono nast¦puj¡ce warianty ±rodowiska eksperymentu:
•
Przegl¡darka internetowa implementacja wªasnego klienta HTTP na bazie istniej¡cego silnika przegl¡darki, wzbogaconego o mechanizm zbierania statystyk odwiedzonych
stron. Podej±cie wymaga wkªadu znacznej ilo±ci pracy w celu dostarczenia funkcjonalno±ci zach¦caj¡cej u»ytkownika do systematycznego wykorzystywania aplikacji.
•
Rozszerzenie istniej¡cej przegl¡darki dodanie moduªu zbierania statystyk do istniej¡cej przegl¡darki za pomoc¡ mechanizmu wtyczek. Ze wzgl¦dów bezpiecze«stwa rozszerzenia dziaªaj¡ w ±rodowisku o ograniczonych przywilejach (ang.
sandbox ),
co mo»e
powodowa¢ trudno±ci w skªadowaniu i przesyªaniu zebranych charakterystyk.
•
Robot internetowy przeprowadzanie pomiarów przy u»yciu przegl¡darki uzale»nia
powodzenie eksperymentu od wyboru odpowiedniej próby u»ytkowników oraz ich rzetelnej wspóªpracy. Zautomatyzowanie procesu pozyskiwania statystyk pozwala na zredukowanie wpªywu czynnika ludzkiego oraz czasu oczekiwania na rezultaty. Wobec tego zdecydowano si¦ na realizacj¦ robota internetowego symuluj¡cego u»ytkowników (rozdz. 6).
Struktura
html
head
title
meta
link
body
span
div
1.0
1.0
1.0
7.5
6.3
0.9
12.7
49.6
Zasoby
a
img
style
script
object
embed
iframe
56.9
32.1
1.4
15.1
0.1
0.2
2.7
Formatowanie
p
h1
h2
h3
b
i
strong
em
hr
17.6
1.5
4.2
5.7
6.1
2.7
5.9
1.7
0.1
Tabele i listy
table
th
tr
td
li
ul
ol
2.8
0.1
6.9
15.3
13.6
11.9
0.4
HTML 5
header
nav
section
article
aside
figure
canvas
audio
footer
0.5
0.3
0.8
0.9
0.2
0.3
0.5
0.1
0.3
Formularze
form
label
input
select
option
textarea
button
1.5
2.1
8.0
0.6
19.6
0.1
0.6
Tablica 4.2: Wªasne wyniki pomiarów stron (2012 r.).
Projekt wªasnego robota internetowego zostaª oparty na silniku Webkit, przez co aplikacja
w kontek±cie funkcjonowania jako klient HTTP niewiele ró»niªa si¦ od przegl¡darki, pozwalaj¡c odwiedzanym serwisom na wykonanie kodu JavaScript i zaªadowanie zawarto±ci Flash.
Dzi¦ki temu w pomiarach uwzgl¦dnienio asynchronicznie pobierane komponenty oraz dokªadnie okre±lono wielko±¢ transferu. Podobnie jak w przypadku pomiarów Google, mierzonymi
atrybutami s¡: liczba »¡da«, rozmiar strony oraz potencjalne oszcz¦dno±ci przy zastosowaniu
ª¡czenia plików (tab. 4.3). Dodatkowo uwzgl¦dniono czas ªadowania strony, stopie« wykorzystania ciasteczek oraz wyst¦powanie poszczególnych znaczników HTML (tab. 4.2).
41
Sumarycznie robot odwiedziª 200,000 najpopularniejszych serwisów z rankingu
Alexa.org
oraz po 4 losowe podstrony z ka»dego portalu, co ª¡cznie daje 1,000,000 wizyt. Ze wzgl¦du
na liczno±¢ odwiedzanych stron oraz niewielkie zaplecze sprz¦towe ka»dy z adresów odwiedzany
byª jednokrotnie. Takie podej±cie zwi¡zane jest z nast¦puj¡cymi komplikacjami:
•
W przypadku strony o szybkozmiennej zawarto±ci, pomiar dokonany podczas jednorazowej wizyty mo»e nie by¢ reprezentatywny dla danego serwisu.
•
Niektóre strony wymagaj¡ zalogowania w celu uzyskania dost¦pu do podstron i typowej
dla danego portalu zawarto±ci (np.
•
facebook.com ).
Pewne serwisy nie posiadaj¡ strony gªównej, poniewa» s¡ wykorzystywane do udost¦pniania innych zasobów (np.
Atrybut
googleusercontent.com ).
Warto±¢
Opis
Strony
106
Zasoby
53.4
¡dania GET
55.1
Hosty
8.00
Zasoby na host
6.68
rednia liczba zasobów na host
532 KB
Rozmiar dokumentu
612 KB
redni caªkowity rozmiar strony
Obrazy
32.1
Rozmiar obrazów
393 KB
Skrypty
10.7
Rozmiar skryptów
92.7 KB
¡czenie skryptów
6.91
rednia liczba nadmiarowych »¡da« skryptów
Arkusze styli
3.62
23.8 KB
¡czenie arkuszy styli
2.54
rednia liczba nadmiarowych »¡da« arkuszy styli
Ciasteczka
5.74
rednia liczba ciasteczek
Czas oczekiwania
1.79
redni czas ªadowania strony
Bª¦dy
13%
Udziaª odpowiedzi o charakterze bª¦du (4XX, 5XX)
Tablica 4.3: Wªasne wyniki pomiarów stron (2012 r.).
•
Po upªywie 2 lat ±redni rozmiar strony niemal si¦ podwoiª i przekroczyª 0,5 MB.
•
Ilo±¢ zasobów zewn¦trznych wymagaj¡cych osobnego »¡dania GET wynosi okoªo 54.
•
Na ka»d¡ stron¦ przypada prawie 10 nadmiarowych »¡da« w porównaniu do sytuacji,
gdyby skrypty i arkusze styli byªy poª¡czone.
•
Porównuj¡c liczb¦ skryptów zewn¦trznych oraz znaczników
<script> mo»na stwierdzi¢,
»e kod Javascript w 60% przypadków osadzany jest wewn¡trz dokumentu HTML.
•
Na stron¦ przypada okoªo 1 formularz, 3 tabele, 6 ciasteczek i ponad 50 odno±ników.
•
W przybli»eniu co trzecia strona wykonana jest w standardzie HTML5, wynika to z cz¦sto±ci znaczników
•
<nav> i <footer>,
które zazwyczaj wyst¦puj¡ pojedynczo.
redni czas ªadowania strony wyniósª niespeªna 2 s dla ª¡cza o przepustowo±ci 10 Mb/s.
42
4.2.3 Pomiary Internet Archive
Organizacja Internet Archive obejmuje serwis HTTP Archive stanowi¡cy repozytorium informacji zwi¡zanych z wydajno±ci¡, budow¡ i sposobem dziaªania popularnych portali internetowych. Gªównymi przedmiotami pomiarów s¡: rozmiar strony, wykorzystywane technologie,
czas obsªugi »¡da«, bª¦dne odpowiedzi serwera, liczba przekierowa« (tab. 4.4).
Zbiór odwiedzanych adresów obejmuje ponad 300,000 najpopularniejszych serwisów WWW
wedªug zestawienia portalu
Alexa.org.
Badania przeprowadzane s¡ przy pomocy przegl¡darki
Internet Explorer 9, sterowanej za po±rednictwem narz¦dzia
WebPageTest.org. Ka»da ze stron
internetowych odwiedzana jest 3 razy, a ostateczny wynik stanowi mediana tak otrzymanych
rezultatów. Problematyczne kwestie dla tego podej±cia to:
•
Jako±¢ dziaªania serwisu eksploracji sieci rzutuje na ilo±¢ efektywnie pobranych stron.
•
Caªo±¢ witryny mo»e nie by¢ odpowiednio reprezentowana przez jej stron¦ gªówn¡.
•
Zasoby mog¡ by¢ serwowane w zale»no±ci od typu przegl¡darki.
Atrybut
Warto±¢
Opis
Strony
300,000+
¡dania GET
90
Hosty
15
1311 KB
Obrazy
55
Rozmiar obrazów
812 KB
Skrypty
15
Rozmiar skryptów
216 KB
Arkusze styli
5
36 KB
Zasoby Flash
3
Liczba zasobów Flash
Rozmiar zasobów Flash
195 KB
redni rozmiar zasobów w formacie Flash
Biblioteki Google
26%
Udziaª stron wykorzystuj¡cych biblioteki Google
Technologia Flash
36%
Udziaª stron wykorzystuj¡cych technologi¦ Flash
Wªasne czcionki
14%
Udziaª stron wykorzystuj¡cych wªasne czcionki
Obrazy JPEG
45%
Udziaª obrazów w formacie JPEG
Obrazy GIF
27%
Udziaª obrazów w formacie GIF
Obrazy PNG
25%
Udziaª obrazów w formacie PNG
¡dania HTTPS
5%
Udziaª »¡da« typu HTTPS
Bª¦dy
36%
Udziaª odpowiedzi o charakterze bª¦du (4XX, 5XX)
Przekierowania
65%
Udziaª odpowiedzi o charakterze przekierowania
Tablica 4.4: Wyniki pomiarów stron HTTP Archive (2014 r.).
•
W ci¡gu 4 lat ±redni rozmiar strony zwi¦kszyª si¦ czterokrotnie i przekroczyª 1 MB.
•
Co czwarty serwis wykorzystuje biblioteki Google, co trzeci technologi¦ Flash.
•
Obrazy w formacie GIF wci¡» dominuj¡ nad standardem PNG.
•
¡dania skierowane do 36% witryn zako«czyªy si¦ komunikatem bª¦du.
•
Niemal 2/3 odwiedzonych stron wykorzystuje przekierowania.
43
4.2.4 Porównanie pomiarów
W celu caªo±ciowej analizy modelu statystycznej strony internetowej, wyniki zebrane przez Google, Internet Archive oraz podczas wªasnej eksploracji sieci zaprezentowano w pojedynczym
zestawieniu (tab. 4.5). Obejmuje ono wspólne parametry pojawiaj¡ce si¦ u ka»dego z wykonawców pomiarów: liczba badanych stron, odniesienia do innych hostów, wielko±¢ transferu,
ilo±¢ i rozmiar zasobów z wyszczególnieniem obrazów, skryptów i arkuszy styli.
Atrybut
Google
Wªasne
Archive
Opis
Rok
2010
2012
2014
Rok wykonania pomiarów
Strony
4.2 × 106
106
3 × 105
Zasoby
44
53
90
Hosty
7
8
15
320 KB
532 KB
1311 KB
Obrazy
29
32
55
Rozmiar obrazów
206 KB
393 KB
812 KB
Skrypty
7
11
15
Rozmiar skryptów
58 KB
93 KB
216 KB
Arkusze styli
3
4
5
rednia liczba arkuszy styli
19 KB
24 KB
36 KB
Tablica 4.5: Zestawienie pomiarów Google, HTTP Archive oraz wªasnych.
•
Dobór wielko±ci badanej próbki ma du»y wpªyw na rzetelno±¢ pomiarów, dlatego najcz¦±ciej za punkt odniesienia uznaje si¦ kompleksowe rezultaty dostarczone przez Google.
•
W ci¡gu 4 lat liczba zasobów podwoiªa si¦ i osi¡gn¦ªa warto±¢ 90 (rys. 4.3). wiadczy to
o istotnym znaczeniu technik optymalizacyjnych oraz bada« nad now¡ wersj¡ protokoªu
HTTP (rozdz. 8), których nadrz¦dnym celem jest redukcja czasu pobierania zasobów.
Rysunek 4.3: Wzrost liczby zasobów stron internetowych.
44
•
W ci¡gu 4 lat liczba hostów, na których przechowywane s¡ zasoby statystycznej strony
internetowej równie» si¦ podwoiªa i osi¡gn¦ªa warto±¢ 15. Mo»e by¢ to spowodowane
upowszechnieniem si¦ infrastruktury CDN (rozdz. 3) lub agresywno±ci¡ systemów reklam, które zawy»aj¡ rezultaty poprzez umieszczanie tre±ci marketingowych.
•
Od 2010 r. wypadkowy rozmiar strony zwi¦kszyª si¦ 4-krotnie (rys. 4.4). W tym aspekcie
najwi¦ksz¡ rol¦ odgrywa wzrost liczby i rozmiaru zasobów zewn¦trznych, które pobierane s¡ wraz z tre±ci¡ dokumentu, a stanowi¡ 88% przesyªanych bajtów. Najpowszechniejszymi elementami s¡ obrazy, skrypty oraz arkusze styli.
Rysunek 4.4: Wzrost rozmiaru stron internetowych i ich zasobów.
•
Rozmiar i liczba obrazów podwoiªa si¦, pod tym wzgl¦dem stanowi¡ one najwi¦kszy
udziaª o warto±ci 67% w statystycznej charaterystyce zasobów stron internetowych.
•
Rozmiar skryptów równie» podwoiª si¦, ale ich liczba zwi¦kszyªa si¦ mniej gwaªtownie.
Ilo±¢ zasobów zewn¦trznych w postaci czystotekstowej mo»e by¢ bowiem efektywnie
ograniczana przez ª¡czenie tych plików, co skutkuje zmniejszeniem liczby »¡da«.
•
Natomiast rozmiar i liczba arkuszy styli wzrosªa nieznacznie w post¦pie liniowym, prawdopodobnie za spraw¡ tendencji do ujednolicania i minimalizacji wygl¡du stron w celu
zapewnienia czytelno±ci i dogodnej obsªugi, zwªaszcza na urz¡dzeniach przeno±nych.
W zwi¡zku z gwaªtowno±ci¡ i nieuchronno±ci¡ wzrostu rozmiaru i liczby zasobów umieszczanych na stronach internetowych, istotn¡ rol¦ odgrywa rozpoznanie i efektywne zastosowanie
odpowiednich technik pozwalaj¡cych na ograniczenie rozmiaru tych elementów i redukcj¦ ich
liczby w celu zmniejszenia opó¹nienia sieci bez konieczno±ci usuwania funkcjonalno±ci strony.
45
4.3
Optymalizacja
Statystycznie wi¦kszo±¢ czasu sp¦dzonego przez przegl¡dark¦ przypada na pobieranie zasobów zewn¦trznych: obrazów, skryptów, arkuszy styli, zawarto±ci Flash. Zmniejszenie liczby
tych komponentów równowa»ne jest ograniczeniu ilo±ci »¡da« HTTP, co przekªada si¦ na redukcj¦ sumarycznego opó¹nienia. Efekt ten mo»na ªatwo osi¡gn¡¢ przez eliminacj¦ zasobów
i uproszczenie wygl¡du strony, jednak istniej¡ techniki pozwalaj¡ce na popraw¦ wydajno±ci
transferu za po±rednictwem HTTP przy zachowaniu bogatej funkcjonalno±ci i estetycznego
interfejsu serwisu. Zostaªy one spopularyzowane na przestrzeni lat przez spoªeczno±¢ twórców
stron internetowych, nale»y mie¢ jednak na uwadze, »e s¡ to prowizoryczne obej±cia ogranicze«
specykacji, które zostan¡ wyeliminowane w kolejnych wersjach protokoªu [34].
4.3.1 ¡czenie zasobów
Redukcja liczby »¡da« jest najlepsz¡ metod¡ poprawy wydajno±ci, bez wzgl¦du na wykorzystywany protokóª i aplikacj¦. Najprostszym sposobem osi¡gni¦cia tego celu w kontek±cie
protokoªu HTTP jest ª¡czenie wielu zasobów w jeden, obsªugiwany przez pojedyncze »¡danie.
W ten sposób wiele skryptów lub arkuszy styli mo»e by¢ konkatenowane, a obrazy scalane
i wybierane z osobna przez odpowiednie reguªy CSS (rys. 4.5).
Rysunek 4.5: Przykªad scalenia obrazów.
Jednak istnieje kilka istotnych problemów zwi¡zanych ze stosowaniem tej techniki:
•
Agregat mo»e zawiera¢ zasoby niewykorzystane przez stron¦, do której s¡ doª¡czone.
•
Ewaluacja skryptów i arkuszy styli po zako«czeniu pobierania caªego agregatu przyczynia si¦ do opó¹nienia dziaªania aplikacji.
•
Modykacja zawarto±ci zasobu skªadowego powoduje uniewa»nienie caªego agregatu
w pami¦ci podr¦cznej i konieczno±¢ ponownego transferu.
•
Utrata modularno±ci i granularno±ci zasobów z perspektywy pami¦ci podr¦cznej.
•
Wi¦ksze zu»ycie pami¦ci operacyjnej przez przegl¡dark¦ podczas obsªugi scalonych obrazów, niezale»nie od faktycznie wy±wietlanego obszaru.
¡czenie komponentów jest optymalizacj¡ na poziomie aplikacji, która eliminuje niedoskonaªo±ci protokoªu HTTP w postaci narzutu niekompresowanych nagªówków i braku niezawodnego mechanizmu potokowania komunikatów. Z drugiej strony wymaga jednak dodatkowego
przetwarzania zasobów zanim zostan¡ umieszczone na serwerze oraz komplikuje proces ich
buforowania, modykacji i renderowania.
46
4.3.2 Osadzanie zasobów
Wplatanie zasobów w zawarto±¢ dokumentu HTML (ang.
inlining )
jest popularn¡ technik¡
redukuj¡c¡ liczb¦ »¡da« HTTP. Kod JavaScript i CSS mo»e zosta¢ ªatwo wª¡czony za pomoc¡ znaczników
<script>
i
<style>,
natomiast osadzenie zasobów multimedialnych (ob-
razy, audio, pliki PDF) wymaga wyspecykowania typu
dostarczenie danych zakodowanych w
base64:
data jako schematu adresu URL oraz
<img src="data:image/gif;base64,R0lGODlhAQABAI
AAAAAAAAAACH5BAAAAAAALAAAAAABAAEAAAICTAEAOw=="
alt="1x1 transparent GIF pixel" />
Zasoby osadzone w tre±ci dokumentu staj¡ si¦ jego nieodª¡czn¡ cz¦±ci¡ i nie mog¡ by¢
umieszczone w pami¦ci podr¦cznej osobno. Wplatanie tego samego zasobu w zawarto±¢ kilku
stron sprawia, »e jest on pobierany wielokrotnie, a ka»da jego modykacja powoduje uniewa»nienie caªego dokumentu w pami¦ci podr¦cznej. Wobec tego zaleca si¦ osadzanie unikalnych
zasobów o rozmiarze poni»ej 1-2 KB, poniewa» dostarczanie ich w postaci samodzielnych
plików poci¡gaªoby za sob¡ narzut nagªówków HTTP przekraczaj¡cy wªasny rozmiar [65].
4.3.3 Uproszczenie arkuszy styli
Wyra»enia zawarte w arkuszach styli pozwalaj¡ na dynamiczne ustawianie wªa±ciwo±ci za pomoc¡ instrukcji JavaScript, np.:
background-color: expression((new Date()).getHours() % 2 ? "#FFF" : "#333");
Jest to przydatny, ale i kosztowny mechanizm blokowany przez wi¦kszo±¢ przegl¡darek,
poniewa» wyra»enia CSS ewaluowane s¡ nadmiernie cz¦sto podczas zmiany poªo»enia kursora, przewijania strony i skalowania okna przegl¡darki. W celu dynamicznego modykowania
styli zaleca si¦ obsªugiwanie zdarze« z poziomu kodu JavaScript (uchwyty
obiektu
window).
onload
i
resize
4.3.4 Miniaturyzacja i zaciemnianie kodu
Zmniejszenie rozmiaru skryptów i arkuszy styli (ang.
minication ) polega na usuni¦ciu z nich
zb¦dnych elementów (komentarze, biaªe znaki). Alternatywn¡ i mniej powszechn¡ optymalizacj¡ jest zaciemnianie kodu (ang.
obfuscation )
polegaj¡ce na uczynieniu go nieczytelnym
dla czªowieka, co wi¡»e si¦ równie» ze zmniejszeniem rozmiaru (list. 4.1). Obydwie metody
redukuj¡ rozmiar pliku ±rednio o 20%, co skutkuje skróceniem czasu jego pobierania. Proces
zautomatyzowanego zmniejszania rozmiaru nale»y stosowa¢ zarówno do zewn¦trznych, jak
i zagnie»d»onych skryptów oraz arkuszy styli.
Listing 4.1: Zaciemnianie i miniaturyzacja kodu JavaScript.
var
a=" H e l l o
function
World ! " ;
MsgBox ( msg )
{
a l e r t ( msg+"\n"+a ) ;
}
MsgBox ( "OK" ) ;
var
_0xea0d = [ " \ x 4 8 \ x 6 5 \x6C\x6C\ x6F \ x 2 0 \ x 5 7 \ x6F \ x 7 2 \x6C\ x 6 4 \ x 2 1 " ,
" \ x0A " , " \ x4F \x4B " ] ; v a r
a=_0xea0d [ 0 ] ; f u n c t i o n
MsgBox ( _0x951cx3 )
{ a l e r t ( _0x951cx3+_0xea0d [ 1 ] + a ) ; } MsgBox ( _0xea0d [ 2 ] ) ;
47
4.3.5 Doª¡czanie zasobów w postaci zewn¦trznych plików
Jak wcze±niej stwierdzono, zmniejszenie liczby »¡da« HTTP w du»ej mierze przyczynia si¦
do redukcji opó¹nienia. Mo»e to skªania¢ do osadzania zasobów w kodzie HTML, jednak nie
zawsze jest to optymalne rozwi¡zanie, ze wzgl¦du na korzy±ci pªyn¡ce z obsªugi osobnych
plików za po±rednictwem poª¡cze« równolegªych oraz pami¦ci podr¦cznej. I tak wplatanie zawarto±ci zasobów w struktur¦ dokumentu redukuje liczb¦ wykonywanych »¡da«, jednak kosztem wzrostu rozmiaru strony alternatywnym rozwi¡zaniem jest doª¡czanie tych obiektów
jako zewn¦trznych plików, które mog¡ by¢ umieszczone w pami¦ci podr¦cznej przegl¡darki,
co dla kolejnych transferów zmniejsza rozmiar strony bez zwi¦kszania liczby »¡da«.
Kluczowym czynnikiem determinuj¡cym preferowany sposób udost¦pniania zasobów pobocznych jest stopie« ich powtarzalno±ci na przestrzeni dokumentów HTML wchodz¡cych
w skªad strony. Je±li u»ytkownicy serwisu dla ka»dej sesji generuj¡ wiele wy±wietle« podstron, a ka»da z nich wspóªdzieli wspólny zbiór zasobów, wówczas warto udost¦pnia¢ je jako
pliki zewn¦trze. Z kolei w przypadku strony gªównej, która najcz¦±ciej cechuje si¦ pojedynczym wy±wietleniem przez u»ytkowników, zaleca si¦ osadzenie zawarto±ci zasobów w obr¦bie
dokumentu HTML w celu zmniejszenia czasu odpowiedzi.
4.3.6 Lokowanie skryptów i arkuszy styli
<head> pozwala przegl¡darce na stopniowe wy±wietlanie strony w miar¦ pobierania kodu HTML (ang. progressive rendering ). Suk-
Przeniesienie arkuszy styli na szczyt dokumentu do sekcji
cesywnie pojawiaj¡ce si¦ elementy strony sprawiaj¡ wra»enie mniejszego opó¹nienia i dostarczaj¡ informacj¦ na temat przebiegu ªadowania dokumentu, bez konieczno±ci wy±wietlania
pasków post¦pu. Arkusze umieszczone poni»ej szczytu dokumentu blokuj¡ progresywne renderowanie w wielu przegl¡darkach. W ten sposób unikaj¡ one konieczno±ci ponownego odrysowywania strony, gdy jej styl ulegnie zmianie.
Z kolei problem zwi¡zany ze skryptami polega na wstrzymywaniu równolegªych transferów
przez przegl¡dark¦ do momentu pobrania i wykonania danego kodu JavaScript. Powoduje to
równie» nieefektywno±¢ techniki partycjonowania domen dla serwerów udost¦pniaj¡cych zasoby. Aby obsªuga kodu JavaScript nie blokowaªa innych komponentów, zaleca si¦ umieszczanie skryptów na dole dokumentu HTML lub dodanie atrybutu
defer
do znacznika
<script>
w celu opó¹nienia ich ewaluacji przez przegl¡dark¦. Nie jest to jednak mo»liwe w sytuacji,
gdy kod zawiera instrukcj¦
document.write
modykuj¡c¡ struktur¦ drzewa DOM w danym
miejscu lub gdy takie ustawienie powoduje problemy zwi¡zane z zasi¦giem zmiennych skryptu.
4.3.7 Opró»nianie bufora
Dynamiczne wygenerowanie dokumentu HTML przez aplikacj¦ sieciow¡ mo»e by¢ operacj¡
dªugotrwaª¡, np. ze wzgl¦du na dost¦p do bazy danych lub rozbudowan¡ logik¦ przetwarzania.
W tym czasie klient czeka bezczynnie na otrzymanie odpowiedzi. Remedium na ten problem
jest krokowe opró»nianie bufora danych serwera, czyli dostarczanie kodu HTML fragmentami. Wówczas przegl¡darka ma mo»liwo±¢ pªynnego parsowania otrzymywanej zawarto±ci
i pobierania zasobów zewn¦trznych.
Przykªadowo, w j¦zyku PHP do opró»niania bufora sªu»y funkcja
niejszym momentem dla tego wywoªania jest zako«czenie sekcji
flush().
Najdogod-
<head> dokumentu, poniewa»
pozwala to klientowi na rozpocz¦cie pobierania arkuszy styli i skryptów w niej zamieszczonych.
48
4.3.8 Redukcja liczby elementów DOM
Nadmiernie skomplikowane i rozbudowane strony internetowe zazwyczaj cechuj¡ si¦ sporym
rozmiarem kodu HTML oraz powolnym dost¦pem do elementów drzewa DOM z poziomu
skryptów JavaScript. Du»a liczba znaczników HTML mo»e by¢ symptomem nieprawidªowego
zaprojektowania struktury strony, np. poprzez nadu»ywanie tabel i bloków
<div>
do spe-
cykacji ukªadu. Takie obej±cia powinny zosta¢ wyeliminowane i zast¡pione semantycznie
poprawnymi elementami, których rozkªad deniowany jest za pomoc¡ arkuszy styli. Obecnie przyjmuje si¦, »e liczba znaczników nie powinna przekracza¢ granicy 500-700 elementów
dla rozbudowanych serwisów internetowych.
4.3.9 Optymalizacja obrazów
Czas odpowiedzi serwera jest skorelowany z rozmiarem strony internetowej, a do jego wzrostu
najbardziej przyczyniaj¡ si¦ obrazy, poniewa» stanowi¡ one ponad 50% wszystkich zasobów
zewn¦trznych. Szcz¦±liwie, pliki graczne s¡ obiektami podlegaj¡cymi stosunkowo ªatwej i wydajnej optymalizacji, bez wi¦kszej utraty jako±ci i pogorszenia komfortu pracy u»ytkownika.
Rysunek 4.6: Porównanie ró»nych stopni kompresji JPEG.
Usprawnienia te polegaj¡ na wst¦pnym okre±leniu wymaganej rozdzielczo±ci, ostro±ci i przestrzeni barw danego obrazu, których dostosowanie skutkuje ogóln¡ utrat¡ jako±ci (rys. 4.6).
Nast¦pnie obraz podlega technikom nienaruszaj¡cym jako±ci, takim jak kompresja bezstratna
lub eliminacja metadanych. W tych aspektach rekomendowane metody optymalizacji to [66]:
•
dostosowanie rozmiaru palety kolorów do liczby barw wyst¦puj¡cych w obrazie,
•
ª¡czenie zbli»onych kolorów i ograniczenie ich liczby do 256 dla formatu PNG,
•
optymalizacja animowanych plików GIF lub konwersja statycznych do formatu PNG,
•
wspomaganie kompresji poprzez poziome i g¦ste rozªo»enie scalonych obrazów,
•
usuni¦cie metadanych z plików JPEG oraz PNG,
•
unikanie skalowania obrazów w kodzie HTML za pomoc¡ atrybutów znacznika
49
<img>.
Rozdziaª 5
Roboty internetowe
Robot internetowy (ang.
crawler, spider, bot ) jest aplikacj¡ automatyzuj¡c¡ proces pobierania
i analizowania zasobów sieci. Najcz¦±ciej wykorzystywany jest jako element silnika wyszukiwarki sªu»¡cy do budowania odpowiedniej kolekcji dokumentów, które nast¦pnie s¡ indeksowane na potrzeby realizacji zapyta« u»ytkowników. Innymi jego zastosowaniami s¡: archiwizacja stron, wykrywanie narusze« prawa i niebezpiecze«stw w sieci oraz statystyczne pomiary
i monitorowanie ewolucji Internetu [56].
Rysunek 5.1: Graf zasobów sieci Internet.
Konieczno±¢ posªugiwania si¦ robotami internetowymi wynika z topologii globalnej sieci,
która nie stanowi typowo centralnego repozytorium informacji, lecz ma charakter dynamicznie zmieniaj¡cego si¦, cyklicznego grafu zasobów tworzonych przez ró»nych dostawców tre±ci,
najcz¦±ciej konkuruj¡cych ze sob¡ (rys. 5.1). Dlatego te» eksploracja Internetu gªównie sprowadza si¦ do odwiedzania kolejnych stron (wierzchoªków grafu), ekstrakcji zawarto±ci zasobu
oraz pod¡»aniu za znalezionymi odno±nikami (kraw¦dzie grafu) [3].
50
5.1
Algorytmy eksploracji sieci
Obecnie istnieje ponad 1600 sygnatur robotów internetowych, które ró»ni¡ si¦ architektur¡,
wydajno±ci¡ i mo»liwo±ciami wykorzystania [12]. Ich wspóln¡ cech¡ jest zastosowanie w procesie eksploracji sieci potencjalnie ka»dy z nich dziaªa wedªug wªasnego schematu, jednak
w ogólno±ci bazuj¡ one na kolejnych krokach algorytmu podstawowego (rys. 5.2):
Rysunek 5.2: Schemat dziaªania robota internetowego [47].
1. Wybór pocz¡tkowego zbioru adresów (ang.
2. Inicjalizacja kolejki (ang.
seed URLs ).
queue, frontier ).
3. Dopóki kolejka nie jest pusta:
(a) Pobranie adresu z kolejki.
(b) Pobranie zawarto±ci zasobu identykowanego przez adres.
(c) Ekstrakcja odno±ników, dodanie ich do kolejki.
(d) Zapisanie zawarto±ci zasobu do repozytorium.
4. Zako«czenie procesu eksploracji.
51
5.1.1 Eksploracja podstawowa
Jak wspomniano, przyjmuje si¦, »e Internet mo»e by¢ modelowany za pomoc¡ grafu cyklicznego, którego wierzchoªki odpowiadaj¡ poszczególnym stronom. Dlatego te» podstawowy algorytm eksploracji sprowadza si¦ do przej±cia po wszystkich osi¡galnych wierzchoªkach grafu
pocz¡wszy od zadanego, kolejno je koloruj¡c w celu oznaczenia odwiedzonych w¦zªów [17].
Listing 5.1: Algorytm eksploracji podstawowej
def
simple_crawler ( root_urls ,
do cuments ,
edges ) :
p e n d i n g _ u r l s = deque ( r o o t _ u r l s )
while
pending_urls :
u r l = pending_urls . p o p l e f t ( )
document = f e t c h _ r e s o u r c e ( u r l )
documents [ u r l ]
= document
a n c h o r s = p a r s e _ u r l s ( document )
for
anchor
in
anchors :
edges . s e t d e f a u l t ( url ,
if
anchor
not in
l i s t ( ) ) . append ( a n c h o r )
pending_urls
and
anchor
not in
documents :
p e n d i n g _ u r l s . append ( a n c h o r )
simple_crawler w j¦zyku
adresów root_urls oraz dwa kon-
Przykªadow¡ implementacj¦ przedstawiono za pomoc¡ funkcji
Python (list. 5.1). Algorytm otrzymuje na wej±ciu zbiór
tenery asocjacyjne sªownik
documents
przechowuj¡cy odwiedzone adresy i odpowiadaj¡ce
edges zawieraj¡cy
odwiedzone adresy i znalezione w nich odno±niki w postaci par (url, anchors).
Kolejka adresów przeznaczonych do odwiedzenia pending_urls pocz¡tkowo zostaje wypeªniona bazowym zbiorem root_urls, nast¦pnie jest przetwarzana iteracyjnie a» do wy-
im zawarto±ci dokumentów w postaci par
(url, document)
oraz sªownik
czerpania jej zawarto±ci. Zale»nie od sposobu zarz¡dzania kolejk¡ (rys. 5.3) w porz¡dku
rst-in rst-out ) lub LIFO (ang. last-in rst-out ) eksploracja grafu
odpowiednio wszerz (ang.breadth-rst search ) lub wgª¡b (ang. depth-frist search ).
FIFO (ang.
przebiega
Rysunek 5.3: Porz¡dek FIFO oraz LIFO.
pending_urls wyci¡gany jest adres url, a identykowany przez niego zasób document zostaje pobrany przez funkcj¦ pomocnicz¡ fetch_resource
oraz wstawiony do sªownika documents. W dalszym kroku inna funkcja pomocnicza parse_urls
na podstawie tre±ci dokumentu zwraca zawarte w nim odno±niki anchors. Nast¦pnie wstawiane s¡ one do kolejki pending_urls, pod warunkiem, »e si¦ tam nie znajduj¡ lub nie zostaªy
Dla ka»dego przebiegu p¦tli z kolejki
odwiedzone, co koresponduje z kolorowaniem wierzchoªków grafu w celu unikni¦cia zap¦tlenia.
Dodatkowo za pomoc¡ sªownika
edges
ka»dy odno±nik kojarzony jest z adresem
url
do-
kumentu, w którym zostaª odnaleziony, co odpowiada kraw¦dzi grafu. Informacja ta mo»e
zosta¢ wykorzystana poprzez funkcj¦ oceny, która uwzgl¦dniana jest w bardziej zaawansowanych wariantach algorytmu.
52
W implementacji tego algorytmu, nale»y równie» wzi¡¢ pod uwag¦ nast¦puj¡ce aspekty
praktyczne [52]:
•
Serializacja Kolejka adresów do przetworzenia oraz zbiór odwiedzonych adresów odzwierciedlaj¡ stan eksploracji, która mo»e zosta¢ przerwana i wznowiona pod warunkiem
trwaªo±ci wymienionych kontenerów danych.
•
Wydajno±¢ Zastosowanie wielow¡tkowego pobierania zasobów pozwala na wykorzystanie dost¦pnej przepustowo±ci sieci oraz czasu realizacji operacji wej±cia/wyj±cia.
•
Dynamika W odró»nieniu do statycznego modelu grafowego, sie¢ Internet nieustannie podlega modykacjom w kontek±cie zawarto±ci jak i topologii. Rozwi¡zaniem tego
problemu mo»e by¢ odwiedzanie stron podatnych na zmiany z wi¦ksz¡ cz¦stotliwo±ci¡.
5.1.2 Eksploracja selektywna
Znacz¡ca liczba analizowanych zasobów negatywnie wpªywa na skalowalno±¢ eksploracji sieci
oraz koszt utrzymania systemu. W optymalnym przypadku robot powinien w ±ci±le ogranicznym czasie odwiedza¢ podzbiór stron internetowych, istotnych w dziedzinie problemu.
W przypadku podstawowego algorytmu eksploracji sieci, kolejka adresów do odwiedzenia
mo»e by¢ zarz¡dzana wedªug pewnej funkcji oceny, co przekªada si¦ na strategi¦ najpierw
najlepszy (ang.
•
best-rst search )
Zagª¦bienie
[62]. W praktyce funkcja oceny mo»e wykorzystywa¢:
Ograniczenie poziomów zagª¦biania si¦ w hierarchii podstron w celu
maksymalizowania eksploracji wszerz, co zwi¦ksza szanse na dotarcie do interesuj¡cej
informacji, w odró»nieniu od eksploracji wgª¡b okre±lanej mianem
•
lost in the space
[72].
Popularno±¢ Ograniczenie liczby odwiedzanych stron poprzez ranking popularno±ci
strony internetowej, któr¡ mo»na oszacowa¢ poprzez miejsce w wynikach wyszukiwarki,
ilo±¢ odno±ników z innych stron lub wªasn¡ implementacj¦ algorytmu
PageRank
[11].
5.1.3 Eksploracja ukierunkowana
W wielu zastosowaniach realizacja algorytmu caªo±ciowej eksploracji sieci mo»e by¢ nadmiarowa, jako »e obiektem zainteresowania s¡ konkretne dziedziny tematyczne. Wówczas przeznaczeniem robota internetowego jest selektywne odwiedzanie stron nawi¡zuj¡cych do okre±lonych
tematów, a nie wyczerpuj¡ce analizowanie wszystkich zasobów.
Przewidywanie trafno±ci
Podobnie jak w przypadku eksploracji selektywnej, istotne znaczenie dla robota ukierunkowanego tematycznie ma denicja funkcji oceny. W praktyce najcz¦±ciej opiera si¦ ona na technikach kategoryzacji tekstu, np. naiwnym klasykatorze Bayesa trenowanym na odpowiednim
zbiorze dokumentów [15], chocia» istniej¡ inne sposoby okre±lania jako±ci zasobu:
•
Ocena zawarto±ci Oceniany jest dokument, którego trafno±¢ rzutowana jest na wszystkie zawarte w nim odno±niki, opieraj¡c si¦ na zasadzie lokalno±ci tematu [19].
•
Ocena odno±nika
Zamiast szacowania trafno±ci caªego dokumentu oceniany jest
tekst odno±nika, który jest traktowany jako no±nik potencjalnie istotnych informacji
zwi¡zanych z tematem.
53
Grafy kontekstu
Koncepcja grafu kontekstu sªu»y do modelowania topologii sieci w celu okre±lenia odlegªo±ci istotnych zasobów od zadanego. W¦zªami grafu s¡ zasoby sieci, kraw¦dziami natomiast
odno±niki je ª¡cz¡ce. Graf konstruowany jest w taki sposób, »e pocz¡tkowy zasób znajduje
si¦ w warstwie centralnej, a ka»da kolejna warstwa zawiera wszystkie w¦zªy odnosz¡ce si¦
do w¦zªów w warstwie poprzedniej (rys. 5.4).
Rysunek 5.4: Schemat grafu kontekstu [21].
Tak zbudowane grafy wyznaczaj¡ zbiory zasobów w konkretnej odlegªo±ci od zadanego.
Na ich podstawie system uczenia przewiduje warstw¦ odpowiedni¡ dla nowego zasobu, co
przekªada si¦ na liczb¦ odno±ników, które prowadz¡ od niego do istotnych dokumentów.
Uczenie przez wzmacnianie
Algorytm uczenia przez wzmacnianie opisuje zasady wyznaczania optymalnej polityki podejmowania akcji przez agenta na podstawie interakcji z nieznanym ±rodowiskiem, bez udziaªu
nadzorcy. Jedyn¡ informacj¡, na której agent si¦ opiera jest sygnaª wzmocnienia, a jego warto±¢ zale»y od poprawno±ci podj¦tej decyzji (rys. 5.5). W kontek±cie eksploracji sieci, agent
jest nagradzany w przypadku pobierania trafnych dokumentów, a karany po napotkaniu nieistotnych. W ten sposób wzmocnienie mobilizuje agenta do pobierania wªa±ciwych zasobów.
Rysunek 5.5: Schemat uczenia przez wzmacnianie [5].
54
5.1.4 Eksploracja rozproszona
Zbudowanie skalowalnego systemu eksploracji cz¦sto wymaga wieloprocesowego zrównoleglenia przetwarzania i geogracznego rozproszenia robota (rys. 5.6). Pozwala ono na peªne wykorzystanie dost¦pnej przepustowo±ci i mocy obliczeniowej oraz redukcj¦ opó¹nienia poprzez
delegowanie przetwarzania do jednostek znajduj¡cych si¦ w niewielkiej odlegªo±ci od serwerów.
Rysunek 5.6: Schemat dziaªania rozproszonego robota internetowego [47].
Taka infrastruktura stosowana jest w wysokowydajnych systemach eksploracji sieci:
•
Interaktywny system rekomendacji
WebWatcher
asystuje przy przegl¡daniu stron inter-
netowych. Wykorzystuj¡c techniki uczenia maszynowego próbuje przewidzie¢ najwªa±ciwszy odno±nik do odwiedzenia dla zdeniowanego przez u»ytkownika celu [1].
•
Zdolny do adaptacji system
Arachnid
wyszukuje informacje powi¡zane z dostarczonymi
sªowami kluczowymi. Do tego celu wykorzystuje populacj¦ agentów i sieci neuronowych
wybieraj¡cych dokumenty, których trafno±¢ oceniana jest przez u»ytkownika [50].
•
Popularny silnik wyszukiwania
CiteSeer
eksploruje zasoby sieci rozpoznaj¡c publikacje
i artykuªy z dziedziny informatyki. Odnalezione dokumenty s¡ analizowane oraz klasykowane w celu budowy globalnego modelu cytowa« i odniesie« [46].
55
5.2
Problemy eksploracji sieci
Rozmiar danych umieszczonych w Internecie co roku zwi¦ksza si¦ o 30% (rys. 5.7). Do tej
pory pobrano i zaindeksowano 16% wszystkich zasobów [45], a koszt eksploracji caªego Internetu szacuje si¦ na
106
dolarów [18], bior¡c jedynie pod uwag¦ wykorzystanie infrastruktury
sieciowej. Rozmiar globalnej sieci i dynamiczny rozwój jej topologii sprawia, »e zaprojektowanie i implementacja wydajnego, skalowalnego, odpornego na bª¦dy robota internetowego jest
znacznym wyzwaniem i wymaga zmierzenia si¦ z problemami, które zostaªy dalej opisane.
Rysunek 5.7: Wzrost sumarycznego rozmiaru zasobów Internetu [48].
5.2.1 Bazowy zbiór adresów
Robot internetowy rozpoczyna eksploracj¦ sieci od bazowego zbioru adresów (ang.
root set ).
Jako »e nie istnieje pojedynczy dokument po±rednio odnosz¡cy si¦ do wszystkich pozostaªych
(rys. 5.8), zbiór bazowy wypeªniany jest relatywnie niewielk¡ liczb¡ adresów z interesuj¡cej
dziedziny. W praktyce s¡ to adresy popularnych serwisów, nowo utworzonych witryn oraz
niszowych stron, do których rzadko odnosz¡ si¦ inne.
Rysunek 5.8: Problem selekcji bazowego zbioru adresów [31].
56
5.2.2 Cykle eksploracji
Istotnym zagadnieniem jest zdolno±¢ robota do wykrywania cykli, które powoduj¡ odwiedzanie
tych samych stron w p¦tli. Takie zachowanie mo»e spowolni¢ lub zatrzyma¢ proces eksploracji
sieci oraz spowodowa¢ inne skutki uboczne:
•
nadmierne zu»ycie zasobów sprz¦towych i sieciowych (moc obliczeniowa, pami¦¢, operacje wej±cia/wyj±cia, transfer danych),
•
powa»ne obci¡»enie serwera, który mo»e zaniecha¢ udost¦pniania usªugi robotowi lub
innym u»ytkownikom sieci,
•
duplikacja i redundancja danych w przypadku przechowywania pobranych zasobów
dla pó¹niejszego przetwarzania.
Naturalne cykle odno±ników
Najpowszechniejszym przypadkiem cyklu jest zamkni¦ty ªa«cuch odno±ników (rys. 5.9). Wyst¦powanie takich p¦tli jest naturaln¡ konsekwencj¡ reprezentacji Internetu w postaci grafu
cyklicznego, którego wierzchoªki odpowiadaj¡ poszczególnym serwerom podª¡czonym do sieci.
Rysunek 5.9: Cykl w postaci ªa«cucha odno±ników [31].
Niekiedy trudno jest okre±li¢, czy strona zostaªa wcze±niej odwiedzona, gªównie za spraw¡
aliasów adresów URL, które identykuj¡ ten sam zasób w ró»ny sposób (tab. 5.1).
Adres
abc.com/about.html
abc.com/user
abc.com/about.html#bio
abc.com/readme.html
abc.com/
abc.com/index.html
Alias
abc.com:80/about.html
abc.com/%7Fuser
abc.com/about.html#memo
abc.com/README.HTML
abc.com/index.html
209.231.87.45/index.html
Komentarz
Domy±lny port 80
%7F
odpowiada
Oznaczenie fragmentów dokumentu
Serwer ignoruje wielko±¢ liter
Domy±lna strona
Tablica 5.1: Przykªadowe adresy URL oraz ich aliasy.
57
index.html
Adresowanie poprzez numer IP
Generowane cykle odno±ników
W szczególnym przypadku cykle mog¡ by¢ konstruowane dynamicznie przez zªo±liw¡ aplikacj¦ sieciow¡, która generuje dokumenty hipertekstowe. Odwiedzenie osadzonych w dokumencie
odno±ników prowadzi do tego samego serwera, który ponownie tworzy sztuczny zasób, i tak dalej (rys. 5.10). Wykrycie takiego zap¦tlenia stanowi trudno±¢, jako »e generowany kod HTML
oraz zawarte w nim adresy URL mog¡ za ka»dym razem wygl¡da¢ inaczej.
Rysunek 5.10: Cykl w postaci ªa«cucha odno±ników generowanego dynamicznie [31].
Cykle systemu plików
Niefortunne utworzenie dowi¡zania symbolicznego (ang.
symbolic link )
w systemie plików
serwera mo»e spowodowa¢ cykl sprawiaj¡cy wra»enie niesko«czenie gª¦bokiej hierarchii katalogów, która zycznie nie istnieje (rys. 5.11). Odmienne adresowanie sugeruje ró»norodno±¢
zasobów, jednak w rzeczywisto±ci s¡ one to»same, co powoduje zap¦tlenie do czasu rozrostu
adresu do dªugo±ci przekraczaj¡cej mo»liwo±ci przetwarzania robota lub serwera.
Rysunek 5.11: Cykl w postaci dowi¡zania symbolicznego [31].
58
Unikanie cykli
Jak mo»na przypuszcza¢, nie istnieje uniwersalny sposób unikania cykli, które stanowi¡ powa»ne zagro»enie dla poprawnego dziaªania robota internetowego. Jednak w praktyce najcz¦±ciej wykorzystuje si¦ zestaw poni»szych heurystyk, skutecznych dla wi¦kszo±ci przypadków:
•
Normalizacja adresów Transformacja aliasów do adresów w standardowej postaci.
•
Rejestrowanie adresów Trwaªe przechowywanie odwiedzonych adresów w celu unikni¦cia ich ponownego odwiedzenia.
•
Skróty zasobów
Zastosowanie funkcji skrótu do binarnych reprezentacji zasobów
pozwala na wykrycie duplikatów niezale»nie od adresowania.
•
Kwarantanna Ograniczenie odwiedzania odno±ników z okre±lonej strony w przedziale
czasu opó¹nia powrót do hipotetycznego cyklu.
•
Czarna lista Utrzymywanie i aktualizacja listy adresów stanowi¡cych cz¦±¢ wykrytego wcze±niej cyklu jednoznacznie odrzuca zasoby-puªapki.
•
Przechodzenie wszerz Eksploracja grafu sieci metod¡ wszerz pozwala na odwiedzenie wielu innych stron przed powrotem do hipotetycznego cyklu.
•
Ograniczenie dªugo±ci adresu
Odltrowanie adresów o znacznej dªugo±ci w celu
unikni¦cia cykli systemu plików, jednak kosztem pomini¦cia prawidªowych stron.
•
Wykrywanie wzorców Rozpoznawanie powtarzaj¡cych si¦ sekwencji zawartych w adresie zasobu, co jest charakterystyczne dla cykli systemu plików (np.
/res/img/res/).
5.2.3 Przestrzeganie etykiety
Robot internetowy jako klient HTTP powinien przynajmniej przestrzega¢ zasad okre±lonych
w specykacji protokoªu. Jednak bª¦dy implementacyjne lub zªo±liwe zamiary twórcy cz¦sto
powoduj¡ powa»ne problemy innych u»ytkowników sieci Internet:
•
Generowanie nadmiernego ruchu
Roboty pobieraj¡ zasoby sieciowe ze znacznie
wi¦ksz¡ cz¦stotliwo±ci¡ ni» ludzie, co mo»e by¢ przyczyn¡ generowania nadmiernego
ruchu i obci¡»enia serwera, degraduj¡c komfort pracy innych u»ytkowników.
•
Nieprawidªowe adresowanie zasobów Z powodu cykli lub bª¦dów implementacyjnych, robot mo»e odnosi¢ si¦ do dªugich, nieprawidªowych lub przestarzaªych adresów
URL, co skutkuje zanieczyszczeniem plików logowania zdarze« serwera, obni»eniem jego
wydajno±ci i w szczególnym przypadku zatrzymaniem dziaªania.
•
Dost¦p do prywatnych danych Niektóre roboty mog¡ natra¢ na dokumenty zawieraj¡ce prywatne dane i upubliczni¢ je poprzez silniki wyszukiwania lub inne aplikacje,
co nara»a u»ytkowników sieci na straty moralne i nansowe.
•
¡danie zasobów dynamicznych
W znacznej liczbie przypadków roboty nie s¡
w stanie zidentykowa¢ sposobu w jaki serwowany jest zasób sieci, a cz¦sto mo»e wi¡za¢
si¦ to z dynamicznym i kosztownym generowaniem zawarto±ci, co dla du»ej liczby »¡da«
negatywnie wpªywa na wydajno±¢ serwera.
59
Warto zatem pozna¢ kilka dobrych praktyk, które stanowi¡ wytyczne prawidªowego projektowania robotów sieciowych oraz ich wspóªpracy z serwerami [39]:
•
Identykacja robota Wykorzystanie nagªówka User-Agent w celu poinformowania
serwera o nazwie i przeznaczeniu robota.
•
Identykacja maszyny
Wykorzystanie maszyny z aktualnym wpisem DNS w celu
rozpoznania odpowiedzialnej organizacji.
•
Umo»liwienie kontaktu
Wykorzystanie nagªówka
From
w celu ujawnienia adresu
strony internetowej lub poczty elektronicznej twórcy robota.
•
Monitorowanie dziaªania ledzenie wpisów diagnostycznych w celu wykrycia puªapek, bª¦dów oraz nieprawidªowego dziaªania robota.
•
Filtrowanie zasobów Wykorzystanie nagªówka Accept oraz normalizowanie adresów
w celu zignorowania nieistotnych zasobów (obrazy, archiwa, programy).
•
Wykluczanie zasobów
Respektowanie i stosowanie si¦ do reguª wykluczaj¡cych
zasoby z eksploracji, przechowywanych w pliku
•
robots.txt
(rys. 5.12).
Redukcja ruchu Unikanie generowania nadmiernego ruchu sieciowego poprzez ograniczenie cz¦stotliwo±ci i liczby dost¦pów do serwera oraz obsªug¦ »¡da« warunkowych.
•
Obsªuga odpowiedzi Wªa±ciwa interpretacja kodów i statusów odpowiedzi serwera
w celu wykrycia przekierowa« i bª¦dów.
•
Zarz¡dzanie zasobami Monitorowanie zu»ycia pami¦ci operacyjnej, przepustowo±ci
sieci na potrzeby optymalnego skongurowania robota.
•
Odporno±¢ na awarie
Wykorzystanie mechanizmu migawek (ang.
punktów kontrolnych (ang.
snapshot )
lub
checkpoint ) umo»liwia kontynuacj¦ dziaªania w razie awarii.
Rysunek 5.12: Schemat stosowania si¦ do wyklucze« zasobów [40].
60
Rozdziaª 6
Dokumentacja projektowa
Przeznaczeniem projektu jest przygotowanie prostego zr¦bu programistycznego i oskryptowania (ang.
framework )
pozwalaj¡cego na implementacj¦ kongurowalnego robota interne-
towego. Wi¡»e si¦ to z realizacj¡ podstawowych moduªów robota abstrahuj¡c od logiki aplikacyjnej przetwarzania pobieranych dokumentów, jako »e zale»na jest ona od konkretnego
zastosowania programu [29]. Takie podej±cie umo»liwia ponowne wykorzystanie kodu w przyszªo±ci do implementacji robotów, które w zautomatyzowany sposób mog¡ przetwarza¢ zasoby
sieci w kontek±cie ró»norodnych zastosowa« (rys. 6.1).
Rysunek 6.1: Mo»liwo±ci wykorzystania robotów internetowych [14].
Zadaniem implementowanego robota jest kontrolowana eksploracja globalnej sieci w celu
uzyskania statystycznego modelu strony internetowej. Aplikacja ma w zamierzeniu umo»liwia¢ zdeniowanie pocz¡tkowego zbioru adresów z uwzgl¦dnieniem wyklucze« umieszczanych
na czarnej li±cie, okre±lenie liczby odno±ników wybieranych z odwiedzanej strony oraz ograniczenia poziomu zagª¦bienia w hierarchii podstron. Pobierane przez robota dokumenty i ich
zasoby s¡ analizowane i statystycznie u±redniane, w rezultacie daj¡c wgl¡d na charakterystyk¦
typowej strony internetowej.
61
6.1
Sªownik poj¦¢
Bazowy zbiór
Czarna lista
Pocz¡tkowy zbiór adresów URL rozpoczynaj¡cych proces eksploracji.
Zbiór adresów URL niepodlegaj¡cych odwiedzaniu przez robota.
Eksploracja sieci
Algorytm odwiedzania kolejnych adresów URL z uwzgl¦dnieniem pobra-
nia dokumentu, ekstrakcji odno±ników, przetwarzania i utrwalenia zebranych danych.
Kolejka
Baza danych zawieraj¡ca kolejno odwiedzane adresy URL.
Model strony
U±rednione charakterystyki statystycznej strony internetowej (np. w kontek-
±cie liczby i rozmiaru zasobów, struktury HTML, przepªywu komunikatów HTTP).
Nadzorca
Moduª monitoruj¡cy dziaªanie wielu instancji robota internetowego.
U»ytkownik
Osoba korzystaj¡ca z programu.
Robot internetowy
6.2
Program pobieraj¡cy zasoby sieci za po±rednictwem protokoªu HTTP.
Wymagania funkcjonalne i niefunkcjonalne
Wymagania funkcjonalne:
1.
Inicjalizacja eksploracji
zip)
2.
Dostarczenie adresów URL (pliki tekstowe
txt, csv lub
db).
oraz wprowadzenie ich do bazowego zbioru lub czarnej listy (pliki binarne
Porz¡dek eksploracji
Wybór porz¡dku eksploracji sieci (depth-rst,
breadth-rst )
przez wykorzystanie odpowiedniej dyscypliny kolejkowania odno±ników (LIFO, FIFO).
3.
Ograniczenie eksploracji
Okre±lenie liczby ekstraktowanych odno±ników z ka»dej
strony i poziomów zagª¦bienia w hierarchii podstron danej domeny.
4.
Pobieranie zasobów
Pobranie nagªówków HTTP, zawarto±ci odwiedzanych stron
oraz zasobów zewn¦trznych, do których si¦ ona odnosi.
5.
6.
Wykonanie pomiarów Pomiar charakterystyk odwiedzanych stron:
•
liczba »¡da« HTTP,
•
liczba i rozmiar zewn¦trznych zasobów (obrazów, skryptów, styli),
•
liczba hostów przechowuj¡cych zasoby zewn¦trzne,
•
wielko±¢ transferu (z uwzgl¦dnieniem kompresji),
•
rozmiar strony (dokumenty wraz z zasobami zewn¦trznymi),
•
liczba nadmiarowych »¡da« skryptów i arkuszy styli,
•
liczba znaczników HTML ka»dego rodzaju,
•
liczba ciasteczek,
•
status odpowiedzi HTTP,
•
czas ªadowania strony.
Obliczanie statystyk
Obliczenie statystycznego modelu strony poprzez arytme-
tyczne u±rednianie warto±ci wy»ej wymienionych charakterystyk.
62
Wymagania niefunkcjonalne:
1.
Odporno±¢ na bª¦dy
Detekcja przekierowa« i cykli eksploracji, obsªuga bª¦dnego
kodu HTML, odporno±¢ na nieprzewidziane zachowanie serwera oraz sieci.
2.
Przestrzeganie etykiety Ograniczenie tempa wysyªania »¡da« do tego samego serwera, identykacja robota poprzez pola nagªówka HTTP, zastosowanie wyklucze« zapisanych w pliku
3.
robots.txt.
Bezpiecze«stwo Brak negatywnego wpªywu na bezpiecze«stwo i stabilno±¢ systemu
operacyjnego.
4.
Rozproszono±¢
Zdolno±¢ dystrybucji przetwarzania na wiele jednostek obliczenio-
wych, potencjalnie oddalonych od siebie.
5.
Wydajno±¢ Efektywna utylizacja dost¦pnych zasobów komputera, mocy obliczeniowej i przepustowo±ci sieci.
6.
Skalowalno±¢ atwo±¢ zwi¦kszania tempa eksploracji sieci poprzez dodawanie nowych
maszyn i zwi¦kszanie przepustowo±ci sieci.
7.
Rozszerzalno±¢ Modularna architektura pozwalaj¡ca na przyszªe rozszerzenie funkcjonalno±ci w kontek±cie nowych formatów danych lub protokoªów sieciowych.
6.3
Przypadki u»ycia
Rysunek 6.2: Diagram przypadków u»ycia
63
6.4
Architektura
Referencyjna architektura robota internetowego bazuje na kilku komponentach, które niemal
zawsze pojawiaj¡ w ka»dej realizacji takiego oprogramowania (rys. 6.3):
Rysunek 6.3: Referencyjna architektura robotów internetowych [14].
queue, frontier ),
•
kolejka adresów URL do przetworzenia (ang.
•
planista przydziaªu adresu URL do robota internetowego (ang.
•
moduª pobieraj¡cy wskazane zasoby z sieci (ang.
•
parser odno±ników z uzyskanego dokumentu (ang.
•
magazyn trwale przechowuj¡cy zebrane dane (ang.
scheduler ),
downloader ),
URL extractor ),
storage ).
Adaptacja architektury referencyjnej polegaªa na zapewnieniu pewnego stopnia skalowal-
horizontal scalability ). Wi¡zaªo si¦ to z wprowadzeniem moduªu nadzorcy (ang. supervisor ), który
no±ci aplikacji poprzez mo»liwo±¢ dodawania kolejnych instancji przetwarzaj¡cych (ang.
odpowiada za uruchamianie, monitorowanie i prawidªowe ko«czenie pracy robotów wspóªbie»nie dziaªaj¡cych w obr¦bie pojedynczej maszyny. Rozdystrybuowanie procesów nadzorcy
na kilka maszyn pozwala na elastyczne zwi¦kszenie liczby uruchamianych robotów oraz efektywn¡ utylizacj¦ dost¦pnych zasobów sprz¦towych.
Rysunek 6.4: Wªasna architektura robota internetowego.
Dodatkowo dostarczono przezroczyst¡ warstw¦ komunikacyjn¡ pomi¦dzy moduªami, która
remote procedure call ). Idea ta
stub ), które nast¦pnie delegowane
bazuje na koncepcji wywoªywania procedur zdalnych (ang.
polega na wywoªywaniu metod w kontek±cie zal¡»ka (ang.
s¡ do peªnoprawnego obiektu, by¢ mo»e znajduj¡cego si¦ na odlegªej maszynie. Dzi¦ki temu,
ewentualna relokacja procesów lub wewn¦trzna zmiana sposobu komunikacji nie ma wpªywu
na kod logiki aplikacyjnej (rys. 6.4).
64
Pod wzgl¦dem przydziaªu odpowiedzialno±ci poszczególne komponenty robota internetowego mo»na podzieli¢ na warstwy: danych, komunikacji, przetwarzania, sterowania (rys. 6.5).
Rysunek 6.5: Warstwowy podziaª komponentów.
6.4.1 Warstwa danych
W celu zapewnienia trwaªo±ci danych aplikacji zrealizowano persystentny kontener asocja-
PersistenDict. Dostarcza ona podzbiór operacji sªownikowych bazuj¡c na standardowym module DbfilenameShelf, który jest
implementacj¡ uniksowego interfejsu DBM (ang. database manager ) wzbogacon¡ o mo»liwo±¢
przechowywania obiektów Pythona zserializowanych do postaci tekstowej metod¡ pickle.
cyjny typu klucz-warto±¢ reprezentowany przez klas¦
Rysunek 6.6: Diagram klas warstwy danych.
W celu zapewnienia szybko±ci dost¦pu, dane zapisywane s¡ wst¦pnie w pami¦ci operacyjnej, a dopiero po zapeªnieniu przydzielonego bufora skªadowane na dysku. Za pomoc¡ sªow-
PersistentDict zamodelowano kolejk¦ PersitentQueue, zbiór PersistentSet oraz inne
ini
po±rednictwem klasy ConfigReader.
nika
kontenery. Ponadto zapewniono mo»liwo±¢ odczytu plików konguracyjnych w formacie
za
65
6.4.2 Warstwa przetwarzania
Minimalny interfejs, który powinien by¢ realizowany przez implementacj¦ robota interneto-
BaseCrawler uogólniaj¡cej podstawowy alBatchCrawler deniuje metody pobierania zada«
wego zostaª wyspecykowany w klasie bazowej
gorytm eksploracji sieci. Pochodna klasa
z kolejki oraz sprawdzania warunku zako«czenia pracy. Natomiast logika aplikacyjna obejmuj¡ca proces pobierania zasobów z sieci oraz sposób ich przetwarzania zostaªa pozostawiona
do implementacji dalszym klasom pochodnym.
Rysunek 6.7: Diagram klas warstwy przetwarzanie.
Na potrzeby pracy tak¡ klas¡ pochodn¡ jest
StatisticsCrawler,
która reprezentuje ro-
bota zbieraj¡cego dane statystyczne na podstawie odwiedzanych stron internetowych. W tym
przypadku funkcjonalno±¢ pobierania zasobów z sieci delegowano do klasy
QWebPage z biblio-
teki PyQt wykorzystuj¡cej implementacj¦ popularnego silnika Webkit. Udost¦pniane przez ni¡
mechanizmy dost¦pu do sieci, obªugi ciasteczek, zarz¡dzania pami¦ci¡ podr¦czn¡, ªadowania
zawarto±ci Flash i kodu JavaScript zostaªy hermetyzowane w klasie
NetworkManager.
Robot
internetowy wykorzystuje j¡ dodatkowo deniuj¡c funkcje obsªugi zdarze« ªadowania strony,
jako »e silnik przegl¡darki dziaªa asynchronicznie.
Ze wzgl¦du na konieczno±¢ przestrzegania etykiety, wytyczne plików
pretowane s¡ przez narz¡dzie
RobotsParser
HttpReply
obejmuj¡cej klasy
Headers i Html
lxml
za po±rednic-
opakowuj¡ce zawarto±¢ przesyªan¡ przez
serwer HTTP. Dost¦p do warstwy sterowania odbywa si¦ poprzez klas¦
umo»liwia przesyªanie sygnaªów »ycia (ang.
inter-
z biblioteki standardowej. Przetwarzanie po-
branych zasobów i obliczanie statystyk realizowane jest przez bibliotek¦
twem
robots.txt
heartbeats )
Hypervised,
która
do procesu nadzoruj¡cego robota.
Natomiast zapisywanie danych delegowane jest do warstwy danych przez przezroczyste serwery RPC kolejki
i
URLTracker
TaskQueue i ResultQueue, rejestry odwiedzonych adresów AliasTracker
Blacklist.
oraz czarnej listy
66
6.4.3 Warstwa komunikacji
Schemat komunikacji pomi¦dzy komponentami aplikacji zrealizowano zgodnie z koncepcj¡
RPC (ang.
remote procedure call ).
Jej podstaw¡ jest ogólna klasa
RPCServer,
która umo»li-
wia wywoªywanie wªasnej metody poprzez podanie jej nazwy oraz dostarczenie argumentów.
Ze wzgl¦dów bezpiecze«stwa metody przeznaczone do wywoªywania w ten sposób oznaczane
s¡ dekoratorem
@rpc,
co zapobiega modykacji wewn¦trznych struktur serwera.
Klasa w poª¡czeniu ze standardowym moduªem
ThreadingTCPServer
funkcjonuje jako
wielow¡tkowy serwer TCP, który realizuje »¡dania klienta posªuguj¡cego si¦ jego zal¡»kiem
(ang.
stub ).
Taka namiastka ma wszystkie cechy peªnoprawnego obiektu, jednak w rzeczywi-
sto±ci jakakolwiek interakcja przezroczy±cie delegowana jest do serwera. Obiekty przesyªane
mi¦dzy klientem a serwerem serializowane s¡ do postaci tekstowej w klasie
przy u»yciu techniki
PickleSerializer
pickle, dzi¦ki czemu zachowuj¡ semantyk¦ obiektów Pythona i na przy-
kªad umo»liwiaj¡ zdalne zgªoszenie wyj¡tku.
Rysunek 6.8: Diagram klas warstwy komunikacji.
Mechanizm wywoªa« dostarczany przez serwer RPC wykorzystywany jest przez klasy
QueueServer, SetServer i DictServer,
niezb¦dne do komunikacji z persystentnymi konten-
terami warstwy danych. Wielow¡tkowy dost¦p do tych struktur zrealizowano za pomoc¡ klasy
SynchronizedWrapper,
która synchronizuje wywoªania metod wspóªdzielonego zasobu.
67
6.4.4 Warstwa sterowania
Do warstwy sterowania nale»y nadzorca reprezentowany przez klas¦
Hypervisor,
która za-
rz¡dza pul¡ procesów tworz¡c i monitoruj¡c instancje robota internetowego. Jak wcze±niej
wspomniano, podczas eksploracji sieci robot mo»e napotka¢ nieprzewidziane z góry puªapki
oraz problemy w komunikacji z serwerami HTTP, dlatego te» awaryjne zako«czenie jego procesu jest naturalnym zjawiskiem nowa instancja zostanie powoªana przez nadzorc¦, dzi¦ki
czemu aplikacja zachowa stabilno±¢ i odporno±¢ na bª¦dy.
Rysunek 6.9: Diagram klas warstwy sterowania.
Oprócz tego nadzorca funkcjonuje jako serwer RPC odbieraj¡cy sygnaªy »ycia od stworzonych instacji robota, które dzi¦ki rozszerzeniu klasy
Hypervised maj¡ mo»liwo±¢ informowania
o prawidªowym dziaªaniu. Mechanizm ten jest konieczny ze wzgl¦du na mo»liwo±¢ zablokowania operacji wej±cia-wyj±cia podczas dost¦pu do sieci przez nieprawidªowo funkcjonuj¡ce
serwery HTTP. Taka sytuacja mo»e by¢ wykryta jedynie przez brak komunikacji w zadanym czasie ze strony robota. Wówczas jego instancja jest uruchamiana ponownie, a aplikacja
odzyskuje jednostki przetwarzania.
6.5
Technologia realizacji
Program zostaª zaimplementowany w j¦zyku Python (2.7.3) przy u»yciu biblioteki
dostarczaj¡cej implementacj¦ silnika przegl¡darki Webkit oraz narz¦dzia
lxml
PyQt
(4.10)
(3.2) wspoma-
gaj¡cego przetwarzanie struktury dokumentu HTML. Wykorzystane pakiety biblioteki standardowej obejmuj¡ moduªy
json, pickle, shelve, configparser, robotparser, TCPServer.
Wybór j¦zyka programowania umotywowany jest dynamicznym typowaniem, szybko±ci¡
prototypowania, obszerno±ci¡ biblioteki standardowej zawieraj¡cej niemal wszystkie niezb¦dne
narz¦dzia oraz dost¦pno±ci¡ szerokiej gamy bibliotek zewn¦trznych, maj¡cych zastosowanie
w aplikacjach sieciowych, technologiach internetowych i rozwi¡zaniach rozproszonych.
68
6.6
Instrukcja u»ytkownika
Do uruchomienia aplikacji wymagana jest maszyna z dost¦pem do Internetu, dziaªaj¡ca pod kon-
PyQt i lxml.
WebsiteStatistics obejmuje podkatalog src z jednostkami kodu ¹ródªowego *.py oraz podkatalog res zawieraj¡cy kontenery danych *.db, plik konguracji
config.ini i bazowy zbiór miliona adresów URL top-1m.csv.zip z serwisu Alexa.org.
trol¡ systemu Linux, z zainstalowanym interpreterem j¦zyka Python, bibliotek¡
Katalog projektu
Uruchamianie komponentów aplikacji polega na wykonaniu nast¦puj¡cych kroków:
1. Wyeksportowanie ±cie»ki do katalogu zawieraj¡cego kod ¹ródªowy:
> cd src
> export PYTHONPATH=`pwd`
2. Przej±cie do katalogu zawieraj¡cego skrypty uruchomieniowe:
> cd Run
3. Umieszczenie w kolejce okre±lonej liczby adresów URL z serwisu
Alexa.org,
z uwzgl¦d-
nieniem liczby ekstraktowanych odno±ników i poziomów zagª¦bienia dla ka»dego adresu.
Przykªadowo, wybór TOP 10000 stron, dla ka»dej ekstrakcja maksymalnie 12 odno±ników z dozwolonym zagª¦bieniem 2 poziomów podstron:
> ./InsertTasks.py 10000 12 2
4. Uruchomienie serwerów RPC dost¦pu do warstwy danych zbiór odwiedzonych adresów,
kolejka zada« i rezultatów (pomini¦to wykorzystanie czarnej listy i rejestru aliasów):
> ./UrlTracker.py &
> ./TaskQueue &
> ./ResultQueue &
5. Uruchomienie zarz¡dcy instancji robota internetowego:
> ./CrawlerHypervisor.py &
6. Zako«czenie pracy komponentów, które zostaªy powoªane jako procesy tªa poprzez wysªanie do nich sygnaªu
kill
w kolejno±ci odwrotnej do uruchamiania:
> kill `jobs -p | sort -r`
7. Wy±wietlenie zada« pozostaªych w kolejce:
> ./ShowTasks.py | less
8. Wy±wietlenie dotychczas zebranych statystyk:
> ./ShowResults.py | less
9. Wygenerowanie zebranych statystyk stron internetowych w formacie
> ./CreateReport.py
69
csv:
Rozdziaª 7
Eksperymentalna optymalizacja
±rodowiska protokoªu HTTP
W ramach pracy przeprowadzono eksperyment polegaj¡cy na zastosowaniu wybranych technik optymalizacyjnych w izolacji oraz zbiorczo w kontek±cie kilku stron internetowych o ró»nej charakterystyce. Pomiary zebrano w postaci kaskadowego widoku zasobów dostarczanego
przez wtyczk¦ Firebug do przegl¡darki Firefox [30]. Taka reprezentacja rezultatów pozwala
na zademonstrowanie zale»no±ci czasowych kolejnych etapów transmisji (rys. 7.1). Pomini¦to
jednak fazy zapytania DNS oraz zestawiania poª¡czenia ze wzgl¦du na ich zmienne opó¹nienie
polegano natomiast na uprzednio nawi¡zanych poª¡czeniach trwaªych.
Rysunek 7.1: Oznaczenia kaskadowego widoku zasobów.
7.1
Przegl¡d technik optymalizacyjnych
Pierwszy test polega na zbadaniu skuteczno±ci poszczególnych technik optymalizacyjnych powszechnie stosowanych w kontek±cie klienta, serwera lub zasobu. Elementy te stanowi¡ bowiem
ortogonalne cz¦±ci ±rodowiska dziaªania protokoªu HTTP (rys. 7.2).
Rysunek 7.2: rodowisko protokoªu HTTP.
Struktura i rozmiar stron b¦d¡cych przedmiotem testów odpowiada modelowi statystycznemu zbudowanemu na podstawie wªasnej eksploracji sieci. Jednak liczba zasobów zewn¦trznych zostaªa proporcjonalnie zmniejszona, aby zapewni¢ czytelno±¢ generowanych widoków.
70
7.1.1 Liczba równolegªych poª¡cze«
Zgodnie z wytycznymi standardu HTTP/1.1 w przegl¡darkach stosuje si¦ wyª¡cznie poª¡czenia trwaªe, a z powodu braku upowszechnienia mechanizmu potokowania jego obsªuga jest
deaktywowana. Jedynym parametrem konguracyjnym z perspektywy klienta pozostaje wi¦c
liczba poª¡cze« zestawianych jednocze±nie do pojedynczego serwera. Standard zaleca 2 takie
poª¡czenia, jednak w praktyce przegl¡darki wykorzystuj¡ do 6 równolegªych poª¡cze«.
W celu zbadania wpªywu liczby poª¡cze« na wydajno±¢ protokoªu zbudowano stron¦ skªadaj¡c¡ si¦ z kilkunastu zasobów obejmuj¡cych arkusze styli, skrypty i obrazy. W ramach testu
zmierzono czas ªadowania strony wykorzystuj¡c od 1 do 12 równolegªych poª¡cze« (tab. 7.1).
Poª¡czenia
Opó¹nienie
Przyspieszenie
1
10.08 s
Poprawa
2
6.65 s
34.02 %
34.02 %
3
5.91 s
41.37 %
7.35 %
4
5.35 s
46.92 %
5.55 %
5
5.10 s
49.40 %
2.48 %
6
4.86 s
51.79 %
2.39 %
7
4.70 s
53.37 %
1.58 %
8
4.55 s
54.86 %
1.49 %
9
4.52 s
55.16 %
0.30 %
10
4.49 s
55.46 %
0.30 %
11
4.48 s
55.56 %
0.10 %
12
4.45 s
55.85 %
0.29 %
Tablica 7.1: Wpªyw liczby poª¡cze« na redukcj¦ opó¹nienia.
Jak mo»na zauwa»y¢, najwi¦ksza wzgl¦dna poprawa o wielko±ci 34% osi¡gane jest przy
zastosowaniu 2 poª¡cze«, natomiast ustawienie 6 poª¡cze« pozostaje optymaln¡ konguracj¡,
poniewa» zwi¦kszanie liczby powy»ej tego progu nie przynosi wymiernych korzy±ci (rys. 7.3).
Rysunek 7.3: Wpªyw liczby poª¡cze« na redukcj¦ opó¹nienia.
Przykªadowo, ograniczaj¡c liczb¦ poª¡cze« do 1, czas zaªadowania strony wyniósª 10.08 s
(rys. 7.4). Natomiast dopuszczaj¡c mo»liwo±¢ zestawiania do 6 równolegªych poª¡cze«, opó¹nienie zostaªo zredukowane do 4.86 s (rys. 7.5) Dalsze zwi¦kszanie liczby poª¡cze« jest nieopªacalne, poniewa» opó¹nienie ograniczone jest od doªu przez czas wykonywania skryptów
oraz maksimum z czasów transmisji poszczególnych zasobów.
71
Rysunek 7.4: Wykorzystanie 1 poª¡czenia.
Rysunek 7.5: Wykorzystanie 6 równolegªych poª¡cze«.
72
7.1.2 Kompresja gzip
Mechanizm kompresji gzip jest technik¡ optymalizacyjn¡ wdra»an¡ po stronie serwera. Sªu»y
do zredukowania wielko±ci transferu poprzez zast¦powanie powtarzaj¡cych si¦ fragmentów danych krótszymi identykatorami. Z tego wzgl¦du z powodzeniem stosuje si¦ go w kontek±cie
plików tekstowych w przeciwie«stwie do plików gracznych, które s¡ uprzednio kompresowane, a nadmierna optymalizacja mo»e prowadzi¢ nawet do zwi¦kszenia ich rozmiaru.
Rysunek 7.6: Brak kompresji gzip.
W celu zbadania skuteczno±ci kompresji gzip przygotowano stron¦ zawieraj¡c¡ arkusz styli
oraz skrypt o rozmiarach odpowiednio 58 kB i 67 kB, które wraz z dokumentem osi¡gn¦ªy rozmiar 126 kB. Bez stosowania kompresji gzip czas zaªadowania strony wyniósª 2.24 s (rys. 7.6).
Natomiast po aktywowaniu tego mechanizmu dla plików CSS i JS rozmiar pierwotnych zasobów zostaª zmniejszony do 8 kB i 18 kB, a opó¹nienie zredukowano do 1.21 s, co mo»na
interpretowa¢ jako przyspieszenie rz¦du 45%.
Rysunek 7.7: Zastosowanie kompresji gzip.
Zastosowanie kompresji gzip wobec plików tekstowych pozwala na znaczne zwi¦kszenie
wydajno±ci protokoªu HTTP. Mechanizm ten jest ªatwy do aktywowania po stronie serwera,
a przegl¡darki domy±lnie wspieraj¡ jego obsªug¦ bez konieczno±ci dodatkowej konguracji.
73
7.1.3 Infrastruktura CDN
Zastosowanie infrastruktury CDN polega na zwielokrotnieniu i rozdystrybuowaniu zasobów
zewn¦trznych strony na kilka osobnych serwerów rozproszonych geogracznie w celu minimalizacji opó¹nienia podczas ich transmisji. Ze wzgl¦du na kosztowno±¢ tej metody, na potrzeby
bada« wykorzystano zasoby innego portalu ju» rozproszone w obr¦bie takiej infrastruktury.
Rysunek 7.8: Brak infrastruktury CDN.
Dla sprawdzenia skuteczno±ci tej techniki zbudowano stron¦ skªadaj¡c¡ si¦ z 1 arkusza
styli, 5 skryptów i 8 obrazów w sumie wraz z dokumentem zajmuj¡cych 42 kB. Czas transmisji pojedynczych zasobów przed zastosowaniem tej metody optymalizacji wynosiª 200-400 ms,
a do momentu wy±wietlenia strony upªyn¦ªo 1.08 s (rys. 7.8). Natomiast po wdro»eniu infrastruktury pojedyczne »¡dania zasobów trwaªy jedynie 15-30 ms w sumie daj¡c zaledwie
385 ms opó¹nienia (rys. 7.9) i skutkuj¡c popraw¡ wielko±ci 60%.
Rysunek 7.9: Zastosowanie infrastruktury CDN.
Zastosowanie infrastruktury CDN wyra¹nie redukuje opó¹nienie transmisji komunikatów,
deleguj¡c »¡dania do kilku rozproszonych serwerów, które w idealnej sytuacji poªo»one s¡
blisko u»ytkownika (w kontek±cie liczby po±rednich w¦zªów sieci). Taka metoda optymalizacji
jest skuteczna oraz dodatkowo poprzez replikacj¦ i rozproszenie zasobów zewn¦trznych zwi¦ksza stabilno±¢ i skalowalno±¢ witryny. W praktyce rozwi¡zanie wci¡» jest kosztowne, dlatego
te» wdra»aj¡ je popularne serwisy, dla których opó¹nienie oraz pogorszenie interaktywno±ci
mo»e skutkowa¢ utrat¡ licznego grona u»ytkowników.
74
7.1.4 Eksternalizacja a osadzanie zasobów
Osadzanie zasobów polega na wplataniu zawarto±ci zasobów w kod strony, co sprawia »e
nie s¡ one przesyªane w ramach dodatkowych »¡da« protokoªu HTTP. Z kolei eksternalizacja
zasobów to doª¡czanie ich za po±rednictwem zewn¦trznych plików, dzi¦ki czemu transfer mo»e
by¢ optymalizowany za pomoc¡ poª¡cze« równolegªych, kompresji gzip i pami¦ci podr¦cznej.
Rysunek 7.10: Zasoby osadzone w kodzie strony.
W celu porównania tych dwóch schematów doª¡czania zasobów przygotowano stron¦
z 3 skryptami i 1 arkuszem styli. W pierwszym przypadku zostaªy one wplecione w kod
strony, skutkuj¡c transmisj¡ 76 kB danych w czasie 737 ms (rys. 7.10).
Rysunek 7.11: Zasoby zewn¦trzne podczas pierwszego pobrania.
W drugim przypadku zasoby doª¡czono w postaci osobnych plików czas zaªadowania
tak skongurowanej strony wyniósª 853 ms, pomimo wykorzystania równolegªych poª¡cze«
i kompresji gzip (rys. 7.11). Jednak podczas kolejnego pobierania tej samej strony zostaªa
wykorzystana pami¦¢ podr¦czna, co pozwoliªo unikn¡¢ ponownej transmisji zasobów i zredukowaªo opó¹nienie do 655 ms (rys. 7.12).
Rysunek 7.12: Zasoby zewn¦trzne podczas kolejnych pobra«.
Eksternalizacja zasobów jest technik¡ optymalizacyjn¡ stosowan¡ niejawnie, poniewa» zazwyczaj zasoby domy±lnie doª¡czane s¡ w formie plików zewn¦trznych. Dzi¦ki temu usprawnienia protokoªu HTTP/1.1 w postaci poª¡cze« równolegªych, kompresji gzip i pami¦ci podr¦cznej mog¡ zosta¢ naturalnie wykorzystane. Jednak»e w niektórych przypadkach, gdy pewne
zasoby maj¡ niewielki rozmiar i s¡ wykorzystywane jednokrotnie w obr¦bie caªego serwisu,
warto przemy±le¢ ich osadzenie w kodzie strony, aby zminimalizowa¢ narzut na transmisj¦
dodatkowych komunikatów protokoªu.
75
7.1.5 Konkatenacja zasobów
Scalanie zasobów w postaci plików tekstowych dotyczy skryptów i arkuszy styli, które mog¡
zosta¢ poª¡czone w celu zmniejszania liczby »¡da« HTTP i tym samym prowadzi¢ do zredukowania wypadkowego czasu ªadowania strony.
Rysunek 7.13: Zasoby rozª¡czne.
Na potrzeby testu zbudowano witryn¦ zawieraj¡c¡ 7 skryptów zajmuj¡cych wraz z dokumentem 22 kB. Czas transmisji zasobów wynosiª 200-700 ms, przez co ªadowanie strony zaj¦ªo
969 ms (rys. 7.13). Poª¡czenie kilku skryptów w jeden zwi¦kszyªo skuteczno±¢ kompresji gzip
oraz zmniejszyªo liczb¦ dodatkowych »¡da« z 7 do 1 trwaj¡cego 393 ms. Dzi¦ki temu strona
wy±wietliªa si¦ ju» po 633 ms, przynosz¡c w rezultacie przyspieszenie do 35%(rys. 7.14).
Rysunek 7.14: Zasoby scalone.
Przeprowadzona eksploracja sieci we wªasnych zakresie wykazaªa, »e na stron¦ ±rednio
przypada do 9 nadmiarowych »¡da« w kontek±cie skryptów i arkuszy styli (rozdz. 6). Mo»na
by je wyeliminowa¢ scalaj¡c te zasoby, co jest ªatwym i tanim rozwi¡zaniem. Jednak ten sposób optymalizacji nale»y traktowa¢ z umiarem, poniewa» scalenie wielu zasobów danego typu
powoduje, »e mechanizm poª¡cze« równolegªych protokoªu HTTP nie jest w peªni wykorzystywany, a wypadkowy czas ªadowania strony nieoptymalny.
76
7.1.6 Miniaturyzacja zasobów
Miniaturyzacja zasobów dotyczy usuwania biaªych znaków z plików tekstowych oraz kompresji obrazów, pozwalaj¡c na zredukowanie ich rozmiaru zwªaszcza je»eli zasoby te zostaªy
uprzednio scalone.
Rysunek 7.15: Zasoby o pierwotnym rozmiarze.
W ramach testu przygotowano stron¦ zawieraj¡c¡ 2 skrypty o rozmiarze 11 kB i 73 kB,
przez co wypadkowy transfer wyniósª 86 kB. Przed zastosowaniem optymalizacji zaªadowanie
strony zaj¦ªo 1.06 s (rys. 7.15), natomiast po zmniejszeniu rozmiaru zasobów, czas oczekiwania
osi¡gn¡ª 853 ms (rys. 7.16), co przekªada si¦ na przyspieszenie rz¦du 20%.
Rysunek 7.16: Zasoby o zredukowanym rozmiarze.
Miniaturyzacja plików wymaga zastosowania zewn¦trznych narz¦dzi, które automatyzuj¡
proces redukowania rozmiaru zasobu, ale jest to kolejne przyst¦pne rozwi¡zanie pozwalaj¡ce
osi¡gn¡¢ zauwa»aln¡ popraw¦ czasu transmisji za po±rednictwem protokoªu HTTP.
77
7.1.7 Pozycjonowanie skryptów
Skrypty zaª¡czone w strukturze strony blokuj¡ dalsze parsowanie dokumentu przez przegl¡dark¦ a» do momentu ich wykonania. Z tego powodu równie» pobieranie kolejnych zasobów
jest wstrzymywane. W znacznej mierze pogarsza to wydajno±¢ mechanizmu równolegªych poª¡cze« dostarczanego przez protokóª HTTP.
Rysunek 7.17: Skrypty umieszczone na górze strony.
Na potrzeby bada« zrealizowano witryn¦ skªadaj¡c¡ si¦ ze skryptu doª¡czonego na górze
strony oraz 5 obrazów umieszczonych za nim w kodzie HTML, w sumie zajmuj¡cych 8 kB. Czas
wykonania skryptu ustawiono na 250 ms poprzez wywoªanie z jego poziomu funkcji
sleep().
Takie umiejscowienie kodu JavaScript powoduje niemo»no±¢ jednoczesnego pobrania obrazów, dlatego te» caªkowite opó¹nienie wynosi 731 ms (rys. 7.17). W przypadku umieszczenia
skryptu na dole strony, parsowanie dokumentu nie jest blokowane i wszystkie zasoby zostaªy
pobrane równolegle w czasie 485 ms, co stanowi ponad 30% poprawy (rys. 7.18).
Rysunek 7.18: Skrypty umieszczone na dole strony.
Umieszczenie dªugo wykonuj¡cych si¦ skryptów na dole dokumentu HTML mo»e znakomicie przyspieszy¢ czas ªadowania strony. Ta technika jest ªatwa do realizacji i nie wymaga
modykowania »adnych zasobów poza wprowadzeniem drobnych zmian w kodzie strony, najlepiej po scaleniu i zminiaturyzowaniu wybranych fragmentów kodu JavaScript.
78
7.1.8 Mapy obrazów
Zastosowanie map obrazów polega na scaleniu niewielkich plików gracznych (ikon, przycisków, logotypów, etc.) oraz dost¦p do nich poprzez specykowanie wspóªrz¦dnych i rozmiaru
za pomoc¡ arkuszy styli lub znacznika
<map>. Takie podej±cie pozwala na zredukowanie liczby
»¡da« HTTP, które dla niewielkich zasobów stanowi¡ wyra¹ny narzut.
Rysunek 7.19: Brak optymalizacji obrazów.
Na potrzeby testu przygotowano stron¦ zawieraj¡c¡ 5 obrazów GIF o rozmiarze 1.2 kB.
Transmisja takiej strony z obrazami doª¡czonymi jako osobne zasoby zewn¦trzne zaj¦ªa 514 ms,
transfer poszczególnych plików zostaª efektywnie zrównoleglony (rys. 7.19). ¡cz¡c pliki graczne do postaci mapy obrazów o rozmiarze 2.8 kB zredukowano liczb¦ »¡da«, a opó¹nienie
zmniejszono do 424 ms, co przekªada si¦ na 15% wzrostu wydajno±ci (rys. 7.20).
Rysunek 7.20: Zastosowanie mapy obrazów.
W skrajnym przypadku, aby wyeliminowa¢ wszystkie dodatkowe »¡dania, obrazy mog¡
by¢ osadzone w kodzie strony, prowadz¡c do zmniejszenia czasu ªadowania strony do 218 ms
(rys. 7.21). Jednak takie rozwi¡zanie, jak ju» wcze±niej wspomniano, skuteczne jest dla plików
znikomej wielko±ci oraz wykorzystywanych jednokrotnie.
Rysunek 7.21: Obrazy osadzone w kodzie strony.
Opisywana technika optymalizacyjna wymaga selekcji plików gracznych o niewielkim
rozmiarze, które wyst¦puj¡ razem w obr¦bie danej strony. Zastosowanie mapy obrazów lub
zdecydowanie si¦ na ich osadzenie w kodzie strony zale»ne jest od cz¦sto±ci wykorzystywania.
Wdro»enie tego usprawnienia wymaga jednak pewnego nakªadu pracy na obróbk¦ graki.
79
Porównanie
W ramach eksperymentu zwerykowano kilka powszechnych technik optymalizacyjnych protokoªu HTTP w kontek±cie klienta, serwera i zasobu. Ró»ni¡ si¦ one przede wszystkim skuteczno±ci¡, kosztami wdro»enia i utrzymania (tab. 7.2).
Kontekst
Technika
Przed
Po
Przyspieszenie
Koszty
Klient
Liczba poª¡cze«
10.08 s
4.86 s
51.79 %
maªe
Kompresja gzip
2.24 s
1.21 s
45.98 %
maªe
Sie¢ CDN
1080 ms
385 ms
64.35 %
du»e
Eksternalizacja
737 ms
655 ms
11.33 %
maªe
Konkatenacja
969 ms
633 ms
34.67 %
±rednie
±rednie
Serwer
Zasób
Miniaturyzacja
1060 ms
853 ms
19.52 %
Skrypty na dole
731 ms
485 ms
33.65 %
maªe
Mapy obrazów
514 ms
424 ms
17.51 %
±rednie
Osadzanie
514 ms
218 ms
57.59 %
±rednie
Tablica 7.2: Porównanie skuteczno±ci technik optymalizacyjnych.
Z tego wzgl¦du zaleca si¦ wprowadzanie usprawnie« protokoªu w nast¦puj¡cej kolejno±ci:
1.
Liczba poª¡cze« Podstawowym rozwi¡zaniem jest wybór przegl¡darki wspieraj¡cej
mechanizmy HTTP/1.1 oraz konguracja 6 równolegªych poª¡cze« na serwer. W przypadku posiadania wydajnej maszyny mo»na ustawi¢ 8 takich poª¡cze« lub zainstalowa¢
wtyczk¦ optymalizuj¡c¡ prac¦ przegl¡darki (np.
2.
Kompresja gzip
Fasterfox ).
Wyspecykowanie plików tekstowych (HTML, XML, CSS, JS)
w konguracji mechanizmu kompresji gzip po stronie serwera przekªada si¦ na zmniejszenie rozmiaru danych transportowanych przez sie¢, a tak»e zredukowanie czasu oczekiwania na zaªadowanie strony.
3.
Eksternalizacja lub osadzanie zasobów
Selekcja niewielkich zasobów wykorzy-
stywanych jednokrotnie i wplecienie ich w kod strony efektywnie redukuje liczb¦ »¡da«.
Dla pozostaªych zasobów doª¡czanych z zewn¦trz warto odpowiednio skongurowa¢ pola
ETag
4.
lub
Expires
w celu optymalizacji mechanizmu pami¦ci podr¦cznej.
Pozycjonowanie skryptów Umieszczenie skryptów na dole strony pozwala unikn¡¢
blokowania kolejnych zasobów i degradacji mechanizmu równolegªych poª¡cze«.
5.
Scalenie zasobów
Poª¡czenie skryptów i arkuszy styli w pojedyncze zasoby oraz
zastosowanie map obrazów dla wyst¦puj¡cych razem niewielkich plików gracznych prowadzi do ograniczenia wysyªanych »¡da«. Nale»y jednak wzi¡¢ pod uwag¦ korzy±ci, jakie
niesie mechanizm równolegªych poª¡cze« w kontek±cie wielu oddzielnych zasobów.
6.
Miniaturyzacja zasobów
Usuni¦cie biaªych znaków ze skryptów i styli oraz opty-
malna kompresja obrazów lub wykorzystanie techniki indeksowania palety barw pomaga
zmniejszy¢ wielko±¢ transferu i czas transmisji tak przygotowanych zasobów.
7.
Infrastruktura CDN Zwielokrotnienie zasobów w obr¦bie geogracznie rozproszonych serwerów zapewnia znaczn¡ redukcj¦ opó¹nienia transmisji. W przypadku braku
±rodków na pokrycie kosztów wdro»enia i utrzymania dodatkowej infrastruktury warto
wzi¡¢ pod uwag¦ zastosowanie techniki partycjonowania domeny.
80
7.2
Optymalizacja przykªadowych stron
Drugi test polega na skonstruowaniu kilku typowych stron internetowych, okre±leniu scenariuszy ich dziaªania, a nast¦pnie przeprowadzeniu optymalizacji za pomoc¡ wybranych technik.
Pozwoli to na zbadanie skuteczno±ci usprawnie« protokoªu HTTP w warunkach zbli»onych
do rzeczywistych. Ostatecznie zdecydowano si¦ na konstrukcj¦ odpowiedników portalu informacyjnego, galerii obrazów oraz wyszukiwarki sieciowej (tab. 7.3).
Atrybut
Pliki
Portal
Galeria
Wyszukiwarka
Tekst
HTML, XML
Obrazy
JPG, PNG, GIF
•••
••
••
••
••
••
••
•••
•••
•
•••
•
•
•
•
•••
•
•••
Interfejs
CSS, JS
Przetwarzanie
PHP, CGI
Zasoby ogóªem
Obci¡»enie ogóªem
Tablica 7.3: Porównanie charakterystyk wybranych stron internetowych [70].
Wybrane typy stron internetowych ró»ni¡ si¦ pod wzgl¦dem przeznaczenia (intensywno±¢
przetwarzania, nat¦»enie ruchu) oraz struktury (typ, rozmiar, liczba zasobów). Z tego wzgl¦du
nie wszystkie optymalizacje b¦d¡ skuteczne lub opªacalne dla ka»dego z serwisów dlatego
wybór odpowiednich usprawnie« dla poszczególnych stron zostaª dokªadnie przeanalizowany.
7.2.1 Optymalizacja portalu informacyjnego
Bazuj¡c na charakterystyce strony BBC News za reprezentacj¦ portalu informacyjnego przyj¦to dokument zawieraj¡cy du»¡ ilo±¢ danych tekstowych, liczne zdj¦cia oraz nietrywialny
interfejs u»ytkownika (rys. 7.22). Zakªada si¦, »e serwis wykorzystuje zewn¦trzne biblioteki
JavaScript, a obrazy oraz tekst s¡ dynamicznie dostarczane przez redaktorów.
Dlatego te» zasoby nie zawsze mog¡ by¢ odpowiednio zoptymalizowane pod k¡tem wydajno±ci transmisji. Portal cechuje si¦ ponadprzeci¦tnym stopniem przetwarzania po stronie
serwera oraz niemaª¡ liczb¡ u»ytkowników jednocze±nie odwiedzaj¡cych witryn¦.
Rysunek 7.22: Wzorcowy portal informacyjny
81
BBC.co.uk.
Bior¡c pod uwag¦ brak peªnej kontroli nad umieszczanymi zasobami przez dostawców tre±ci, skoncentrowano si¦ na stosowaniu usprawnie« w kontek±cie serwera i pami¦ci podr¦cznej:
•
aktywowanie kompresji gzip dla plików tekstowych,
•
konguracja pól nagªówka
•
eksternalizacja zasobów w celu usprawnienia pami¦ci podr¦cznej,
•
wdro»enie infrastruktury CDN lub wykorzystanie techniki partycjonowania domeny
ETag i Expires,
dla zasobów pochodz¡cych z wªasnych ¹ródeª.
Rysunek 7.23: Brak optymalizacji portalu informacyjnego.
Przed zastosowaniem technik optymalizacyjnych wy±wietlenie portalu wymagaªo przesªania 244 kB danych w czasie 4.98 s (rys. 7.23). Po wdro»eniu i parametryzacji usprawnie«
udaªo si¦ zredukowa¢ wielko±¢ transferu do 111 kB, a opó¹nienie do 1.64 s (rys.7.24).
Przeniesienie wi¦kszo±ci zasobów do sieci CDN pozwoliªo na zmniejszenie czasu transmisji
pojedynczych zasobów z 300-900 ms do 10-90 ms. Przekªada si¦ to na uzyskanie trzykrotnego
przyspieszenia wypadkowego, jednak dolne ograniczenie optymalizacji czasu stanowi¡ zasoby
znajduj¡ce si¦ poza infrastruktur¡ CDN. Z kolei dwukrotna redukcja rozmiaru przesyªanych
danych to zasªuga kompresji gzip zastosowanej w kontek±cie dominuj¡cych plików tekstowych.
Rysunek 7.24: Optymalizacja portalu informacyjnego.
82
7.2.2 Optymalizacja galerii obrazów
Przykªadow¡ galeri¦ obrazów zbudowano wzoruj¡c si¦ na ocjalnej witrynie marki PENTAX
(rys. 7.25). Za typowe cechy takiej strony przyj¦to niewielk¡ ilo±¢ tekstu wyst¦puj¡c¡ jedynie
w postaci tytuªów i opisów fotograi, natomiast du»¡ liczb¦ zasobów zewn¦trznych. Zaliczaj¡
si¦ do nich zdj¦cia, graczne elementy interfejsu u»ytkownika, a tak»e skrypty i arkusze styli
zapewniaj¡ce efektowny wygl¡d serwisu.
W ramach bada« wydajno±ci transmisji HTTP zakªada si¦, »e serwer znajduje si¦ poza
kontrol¡ na zewn¦trznym hostingu. Intensywno±¢ oblicze« po jego stronie jest niewielka, podobnie jak tempo wysyªania »¡da« przez u»ytkowników równocze±nie odwiedzaj¡cych witryn¦.
Rysunek 7.25: Wzorcowa galeria obrazów
PentaxPhotoGallery.com.
Ze wzgl¦du na wykorzystanie zdj¦¢, skryptów i arkuszy styli wªasnego autorstwa, optymalizacja wydajno±ci protokoªu skupia si¦ na redukcji liczby »¡da« i rozmiaru owych zasobów:
•
kompresja obrazów,
•
usuni¦cie metadanych z plików gracznych,
•
miniaturyzacja skryptów i arkuszy styli,
•
scalenie skryptów i arkuszy styli o maªych rozmiarach,
•
umieszczenie skryptów na dole strony.
Wy±wietlenie pierwotnej strony zaj¦ªo 4.8 s, co obejmowaªo pobranie 564 kB danych oraz
wykonanie 24 »¡da« (rys. 7.26). Zastosowanie usprawnie« pozwoliªo na wyra¹ne zwi¦kszenie
responsywno±ci aplikacji oraz komfortu pracy u»ytkownika (rys. 7.27).
Scalenie zasobów poskutkowaªo redukcj¡ liczby »¡da« do 18 komunikatów. Miniaturyzacja plików tekstowych, kompresja plików gracznych oraz pozbycie si¦ zb¦dnych metadanych
przeªo»yªo si¦ z kolei na czterokrotne zmniejszenie wielko±ci transferu do 140 kB. Natomiast
przeniesienie skryptów na dóª strony wyeliminowaªo konieczno±¢ oczekiwania na ich zaªadowanie przed innymi zasobami, dzi¦ki czemu czas ªadowania strony zostaª zredukowany do 1.94 s.
83
Rysunek 7.26: Brak optymalizacji galerii obrazów.
Rysunek 7.27: Optymalizacja galerii obrazów.
84
7.2.3 Optymalizacja wyszukiwarki
Za wzorcowy model wyszukiwarki przyj¦to serwis Yahoo i na jej podstawie zbudowano przykªadow¡ stron¦ na potrzeby testów (rys. 7.28). Witryna tego typu cz¦sto wykorzystywana jest
jako strona gªówna w przegl¡darce, dlatego czas jej zaªadowania musi by¢ jak najmniejszy.
Wyszukiwarki charakteryzuj¡ si¦ prostot¡ wygl¡du i minimalistycznym interfejsem u»ytkownika, dlatego te» liczba obrazów, skryptów i styli wystepuj¡cych w obr¦bie witryny jest
znikoma. Z drugiej strony obci¡»enie serwera oraz liczba u»ytkowników korzystaj¡cych z wyszukiwarki jest najwi¦ksze ze wszystkich analizowanych aplikacji sieciowych. Zakªada si¦, »e
przykªadowy serwis zostaª zoptymalizowany po stronie serwera, natomiast usprawnienia wymaga struktura strony i sposób doª¡czania zasobów zewn¦trznych.
Rysunek 7.28: Wzorcowa wyszukiwarka
Yahoo.com.
W efekcie optymalizacja dotyczy gªównie modykacji zasobów w celu zminimalizowania
liczby »¡da« oraz opó¹nienia, tak aby wyszukiwarka ªadowaªa si¦ jak najszybciej:
•
przygotowanie map obrazów dla wspólnie wystepuj¡cych plików gracznych,
•
osadzenie pojedynczo wystepuj¡cych obrazów w kodzie HTML,
•
miniaturyzacja skryptów i arkuszy styli,
•
osadzenie zawarto±ci skryptów i arkuszy styli w kodzie HTML.
Pocz¡tkowo uruchomienie wyszukiwarki w przegl¡darce obejmowaªo realizacj¦ 16 »¡da«,
które trwaªy w sumie 4.22 s i wymagaªy pobrania 111 kB danych (rys. 7.29). Po uwzgl¦dnieniu
proponowanych usprawnie« wy±wietlenie strony generowaªo 4 »¡dania, wymagaªo oczekiwania
jedynie 1.12 s i przesªania 125 kB (rys. 7.30).
Jak mo»na zauwa»y¢, stworzenie map obrazów, miniaturyzacja zasobów oraz osadzenie
ich w kodzie strony pozwoliªo czterokrotnie zredukowa¢ liczb¦ »¡da«. Odbyªo si¦ to kosztem
skuteczno±ci mechanizmu kompresji gzip oraz pami¦ci podr¦cznej, jako »e wielko±¢ transferu
wzrosªa a» o 20 kB. Istotny jest jednak fakt, »e udaªo si¦ trzykrotnie zmniejszy¢ opó¹nienie
niemal do optymalnej granicy, co jest kluczowym wyznacznikiem zadowolenia i komfortu pracy
tysi¦cy u»ytkowników korzystaj¡cych z wyszukiwarki.
85
Rysunek 7.29: Brak optymalizacji wyszukiwarki.
Rysunek 7.30: Optymalizacja wyszukiwarki.
Porównanie
Oprócz analizy skuteczno±ci technik optymalizacyjnych stosowanych w odosobnieniu, eksperyment przedstawiª równie» sposób kompleksowego wdra»ania tych metod. Za pomoc¡ zbudowanego modelu statystycznego skonstruowano kilka przykªadowych stron powszechnie wyst¦puj¡cych w Internecie (portal informacyjny, galeria obrazów, wyszukiwarka sieciowa) [57].
Nast¦pnie okre±lono charakterystyk¦ i ±rodowisko dziaªania tych serwisów, na ich podstawie wyselekcjonowano odpowiednio uargumentowane techniki optymalizacyjne, które w efekcie przyczyniªy si¦ do poprawy wydajno±ci dziaªania protokoªu (tab. 7.4). Ponownie naskuteczniejszymi okazaªy si¦ metody redukcji rozmiaru transferu i odlegªo±ci geogracznej (kompresja danych, system CDN), w dalszej kolejno±ci byªy to sposoby zmniejszenia liczby »¡da«
(scalanie i osadzanie zasobów w kodzie strony).
Typ strony
Przed
Po
Przyspieszenie
Portal informacyjny
4.98 s
1.64 s
67.07 %
Galeria obrazów
4.80 s
1.94 s
59.58 %
Wyszukiwarka
4.22 s
1.18 s
72.04 %
Tablica 7.4: Porównanie skuteczno±ci optymalizacji przykªadowych stron.
Badania potwierdziªy intuicyjne przypuszczenie, »e usprawnienia wydajno±ci powinny by¢
wdra»anie zale»nie od budowy strony, jej przeznaczenia i charakterystyki wykorzystywanych
zasobów. Zastosowanie nieprawidªowych technik mo»e mie¢ odwrotny skutek do po»¡danego,
dlatego nie nale»y ich wykorzystywa¢ bez dogª¦bnej analizy optymalizowanej strony.
Wszelkie ulepszenia warto równie» wprowadza¢ od pocz¡tku tworzenia witryny, kiedy to
koszt ich wdro»enia jest niewielki. Nie zawsze jednak mo»liwa jest konguracja wszystkich
elementów ±rodowiska protokoªu HTTP przykªadowo ze wzgl¦du na przestarzaªe klienty,
brak dost¦pu do serwera, poleganie na zewn¦trznych bibliotekach JavaScript.
86
Rozdziaª 8
Przyszªo±¢ protokoªu HTTP
W toku ewolucji protokoªu HTTP na przestrzeni lat powstaªo kilka jego wersji:
•
HTTP/0.9
Prototyp o wielu wadach projektowych, sªu»¡cy do pobierania doku-
mentów hipertekstowych. Obsªuguje jedynie metod¦ GET, nie dostarczaj¡c wsparcia
dla nagªówków, numerów wersji i typów danych, szybko zast¡piony przez HTTP/1.0.
•
HTTP/1.0 Powszechnie wdro»ona wersja niweluj¡ca ubytki poprzedniego wydania.
Rozszerzyªa zbiór metod dost¦pu oraz wzbogaciªa funkcjonalno±¢ o obsªug¦ multimediów
i formularzy, co przyczyniªo si¦ do wzrostu popularno±ci projektu WWW [10].
•
HTTP/1.0+ W odpowiedzi na dynamiczny rozwój Internetu wiele przegl¡darek oraz
serwerów wprowadziªo nieocjalne rozszerzenia obsªugi poª¡cze«
keep-alive, wirtualnych
serwerów i w¦zªów po±rednich, które przyj¦ªy si¦ jako standardowe rozwi¡zania.
•
HTTP/1.1
Wydanie to miaªo na celu poprawienie architektury protokoªu, specy-
kacj¦ semantyki metod dost¦pu, optymalizacj¦ wydajno±ci, usuni¦cie wadliwej funkcjonalno±ci i dostarczenie wsparcia dla upowszechniaj¡cych si¦ aplikacji sieciowych [25].
Aktualna wersja HTTP/1.1 wspiera ±ledzenie wersji dokumentów, ró»ne metody wysyªania
danych, obsªug¦ wielu j¦zyków, pami¦¢ podr¦czn¡, zakresowy dost¦p do zasobów. Pomimo
tych udoskonale«, istnieje kilka problemów zwi¡zanych z architektur¡ protokoªu:
•
Zªo»ono±¢ Implementacja skomplikowanych aplikacji HTTP cz¦sto wymaga dodatkowego oprogramowania mechanizmów protokoªu (obsªuga transakcji, poª¡czenia trwaªe,
pami¦¢ podr¦czna).
•
Rozszerzalno±¢
Inkrementalne wzbogacenie funkcjonalno±ci protokoªu jest trudne,
gdy» nie przewidziano takiego mechanizmu. Ka»da modykacja mo»e prowadzi¢ do niekompatybilno±ci oraz dezaktualizacji wielu istniej¡cych aplikacji i systemów.
•
Wydajno±¢
Wiele problemów wydajno±ciowych protokoªu pogª¦bia si¦ z powodu
stopniowego upowszechniania si¦ technologii bezprzewodowych o wysokim opó¹nieniu
i niskiej przepustowo±ci.
•
Sprz¦»enie warstwy transportowej Implementacje HTTP bazuj¡ najcz¦±ciej na stosie TCP/IP, którego wykorzystanie dla systemów wbudowanych i sieci bezprzewodowych
jest suboptymalne. W obliczu rosn¡cego zapotrzebowania na uniwersaln¡ platform¦ komunikacyjn¡, potrzebne jest wsparcie dla innych protokoªów warstwy transportowej [2].
87
8.1
HTTP-NG
W toku rozwoju HTTP jego zastosowania przekroczyªy pierwotne zaªo»enia projektowe, dlatego konieczne byªo zaproponowanie architektury nast¦pnej generacji. W 1997 r. przy udziale
konsorcjum W3C narodziªa si¦ idea HTTP-NG (ang.
HTTP Next Generation ), która wkrótce
potem zostaªa porzucona, jednak wyznaczyªa pewien kierunek dla przyszªo±ci protokoªu.
8.1.1 Modularyzacja
W celu zapewnienia modularyzacji i separacji wspóªzale»nych mechanizmów protokoªu (zarz¡dzanie poª¡czeniami, obsªuga komunikatów, metody dost¦pu), zaproponowano trójwarstwowy
podziaª funkcjonalno±ci (rys. 8.1).
Rysunek 8.1: Izolacja funkcjonalno±ci protokoªu w postaci warstw [34].
Warstwa transportu komunikatów
Warstwa transportu komunikatów (ang.
message transport layer ) dostarcza interfejs pozwala-
j¡cy na wymian¦ wiadomo±ci bez wzgl¦du na obsªugiwany stos sieciowy. Moduª ten odpowiada
za wydajn¡ transmisj¦ komunikatów, dokonuj¡c nast¦puj¡cych optymalizacji:
batch ),
•
redukcja opó¹nie« przez poª¡czenia potokowe i przetwarzanie wsadowe (ang.
•
zapobieganie przestojom transmisji poprzez multipleksowanie strumieni komunikatów,
•
ªatwe wyznaczanie granic komunikatów poprzez wydajny mechanizm segmentacji.
Warstwa wywoªa« zdalnych
Warstwa wywoªa« zdalnych (ang.
remote invocation layer )
dostarcza generyczny mechanizm
typu »¡danie-odpowied¹, pozwalaj¡cy klientowi dokonywa¢ zdalnych operacji na zasobach
po stronie serwera. Moduª ten abstrahuje od implementacji i semantyki poszczególnych operacji, eksponuje jedynie odpowiedni interfejs. Obecnie istnieje wiele kompatybilnych standardów
wywoªa« zdalnych (np. CORBA, DCOM, Java RMI).
Warstwa aplikacji
Warstwa aplikacji (ang.
web application layer ) deniuje semantyk¦ oraz logik¦ protokoªu. Pre-
zentuje ona wspólne usªugi oraz mechanizmy dla ró»norodnych, potencjalnie wspóªistniej¡cych
aplikacji. Jej przeznaczeniem jest dostarczanie funkcjonalno±ci HTTP/1.1 oraz udost¦pnianie
interfejsu dla przyszªych rozszerze« [44].
88
8.1.2 Ulepszenie
Po dokonaniu podziaªu protokoªu HTTP na moduªy, mogªy one by¢ niezale»nie modykowane
w celu zwi¦kszenia ich wydajno±ci i wzbogacenia funcjonalno±ci. Zdecydowano si¦ na optymalizacj¦ ró»nych wªa±ciwo±ci protokoªu przy pomocy nast¦puj¡cych koncepcji:
Obiekty rozproszone
distributed objects ). Podej±cie to zapewnia rozszerzalno±¢ i elastyczno±¢ systemu, jednak cechuje
Architektura HTTP-NG w du»ej mierze oparta jest na idei obiektów rozproszonych (ang.
si¦ stosunkowo du»ym nakªadem implementacyjnym oraz znacznym stopniem zªo»ono±ci [43].
WebMUX
Koncepcja WebMUX deniuje wydajny mechanizm obsªugi komunikatów, które mog¡ by¢
jednocze±nie transportowane poprzez multipleksowane poª¡czenie TCP. Dzi¦ki temu, osobne
strumienie komunikatów transmitowanych z ró»n¡ cz¦stotliwo±ci¡ mog¡ zosta¢ podzielone
i rozprowadzone w obr¦bie jednego lub kilku poª¡cze« (rys. 8.2). Dodatkowo mechanizm ten
redukuje nasycenie sieci za po±rednictwem anonsowania gotowo±ci obsªugi danych przez odbiorc¦, analogicznie do koncepcji sterowania przepªywem w warstwie transportowej.
Rysunek 8.2: Schemat multipleksowania komunikatów [34].
Binary Wire
Specykacja HTTP-NG okre±la typy obiektów oraz dokonuje skojarzenia metod dost¦pu
do ka»dego z nich. Obiekty identykowane s¡ poprzez adresy URI, zatem charakterystyki
i metody dost¦pu mog¡ by¢ zró»nicowane na poziomie zasobów, a nie statycznie w obr¦bie caªego serwera, jak w przypadku HTTP/1.1. Wydajny i rozszerzalny mechanizm
Wire
Binary
deniuje sposób obsªugi zdalnych operacji oraz odpowiada za transport komunikatów
za po±rednictwem stanowego poª¡czenia [38].
Komunikat »¡dania okre±la typ operacji i obiekt docelowy, podczas gdy komunikat odpowiedzi status operacji i numer kontrolny, a ka»dy z nich mo»e by¢ równie» no±nikiem
opcjonalnych danych. Numer kontrolny identykuje odpowiadaj¡ce »¡danie, co umo»liwia
wymian¦ komunikatów w dowolnej kolejno±ci, nie tylko w sekwencji »¡danie-odpowied¹. Ponadto protokóª wprowadza kilka wewn¦trznych wiadomo±ci steruj¡cych wykorzystywanych
do zwi¦kszenia wydajno±ci i niezawodno±ci poª¡czenia.
89
8.2
HTTP/2.0
Pomimo porzucenia koncepcji modularnego protokoªu HTTP-NG, obecnie trwaj¡ prace nad
kolejn¡ wersj¡ HTTP. Staªo si¦ to za spraw¡ projektu SPDY zainicjowanego przez Google
w 2009 r., który miaª na celu zmniejszenie czasu ªadowania stron internetowych poprzez eliminacj¦ wydajno±ciowych ogranicze« protokoªu. W toku pomy±lnego rozwoju idea przerodziªa
si¦ w zapowied¹ ocjalnego standardu HTTP/2.0 [7].
8.2.1 Architektura
Implementacja HTTP cechuje si¦ prostot¡, jednak»e odbywa si¦ to kosztem wydajno±ci, co
jest gªównym obszarem optymalizacji na potrzeby kolejnej wersji protokoªu, takich jak [8]:
•
redukcja opó¹nienia i nasycenia sieci,
•
zachowanie semantyki HTTP/1.1 na poziomie aplikacyjnym,
•
zdeniowanie schematu interakcji z poprzednimi wersjami protokoªu,
•
dostarczenie mechanizmu rozszerze« i wytycznych jego u»ytkowania,
•
minimalizacja zmian istniej¡cej infrastruktury oraz zasobów sieciowych.
W kontek±cie zaªo»e« projektowych proponowanymi usprawnieniami jest multipleksowanie, priorytetyzacja komunikatów, kompresja pól nagªówka, obsªuga bª¦dów, wspomaganie
aktualizacji i mechanizm sterowania przepªywem. Nowa wersja protokoªu nie modykuje semantyki HTTP, natomiast wprowadza niekompatybiln¡ wstecznie warstw¦ komunikacji.
8.2.2 Warstwa komunikacji
Podstaw¡ wszystkich optymalizacji wydajno±ciowych HTTP/2.0 jest warstwa transmisji binarnych ramek (ang.
binary framing layer )
deniuj¡ca sposób w jaki protokóª konstruuje
i przesyªa komunikaty (rys. 8.3).
Rysunek 8.3: Warstwa transmisji binarnych ramek [34].
Warstwa ta operuje pomi¦dzy interfejsem gniazd sieciowych a interfejsem aplikacyjnym
HTTP. W ten sposób semantyka metod dost¦pu i pól nagªówka pozostaje nienaruszona, podczas gdy zmianie ulega kodowanie i enkapsulacja transmitowanych danych. W przeciwie«stwie
90
do HTTP/1.x format komunikacji nie jest czysto tekstowy, lecz oparty o podziaª na komunikaty i ramki kodowane w formie binarnej. Konsekwencj¡ tego rozwi¡zania jest niekompatybilno±¢ z istniej¡cymi wersjami protokoªu i konieczno±¢ negocjacji sposobu transmisji pomi¦dzy
klientem i serwerem. Ponadto specykacja protokoªu wprowadza nast¦puj¡c¡ terminologi¦:
Sesja
Odpowiednik poª¡czenia.
Strumie«
Wirtualny, dwukierunkowy kanaª transportuj¡cy komunikaty.
Komunikat
Ramka
Logiczny komunikat HTTP skªadaj¡cy si¦ z sekwencji ramek.
Najmniejsza jednostka komunikacji przenosz¡ca informacje (nagªówki, dane).
Komunikacja mi¦dzy klientem a serwerem odbywa si¦ w obr¦bie sesji skªadaj¡cej si¦ z dwukierunkowych strumieni. Te z kolei przenosz¡ komunikaty zbudowane z ramek identykowanych numerem strumienia, dzi¦ki czemu mog¡ by¢ przeplatane w dowolnej kolejno±ci (rys. 8.4).
Rysunek 8.4: Terminologia protokoªu HTTP/2.0 [34].
8.2.3 Multipleksowanie komunikatów
W przypadku HTTP/1.x, realizacja równolegªych »¡da« wymaga zestawienia odpowiedniej
liczby poª¡cze« TCP. Warstwa komunikacyjna eliminuje t¦ niedogodno±¢ za pomoc¡ multipleksowania, która polega na podziale komunikatów na ramki, ich transmisji w dowolnej
kolejno±ci oraz rekonstrukcji do pierwotnej formy (rys. 8.5).
Rysunek 8.5: Multipleksowanie komunikatów w obr¦bie sesji [34].
91
Mechanizm multipleksowania jest znacznym usprawnieniem jego celem jest:
•
wydajna utylizacja pojedynczej sesji,
•
nieblokuj¡ce i wspóªbie»ne przeplatanie komunikatów,
•
ograniczenie opó¹nienia i zu»ycia zasobów,
•
eliminacja optymalizacji w kodzie aplikacyjnym.
8.2.4 Priorytetyzacja komunikatów
Jako »e komunikat jest dzielony na niezale»ne ramki, sposób ich przeplatania i dostarczania
w obr¦bie sesji mo»e zosta¢ zoptymalizowany pod k¡tem wydajno±ci aplikacji HTTP. W odpowiedzi dostarczono mechanizm priorytetyzacji, dzi¦ki czemu klient lub serwer ma mo»liwo±¢
stosowania ró»nych strategii przetwarzania strumieni, komunikatów i ramek w po»¡danej kolejno±ci. Priorytetyzacja jest szczególnie przydatna w kontek±cie dziaªania przegl¡darek internetowych, jako »e w procesie renderowania strony zasoby cechuj¡ si¦ ró»nymi priorytetami
zale»nie od ich typu i rozmieszczenia w dokumencie (rozdz. 2).
8.2.5 Pojedyncze poª¡czenie
Obsªuga przez serwer du»ej liczby wspóªbie»nych poª¡cze« stanowi problem w kontek±cie
skalowalno±ci, zwªaszcza »e wi¦kszo±¢ transakcji HTTP ma charakter impulsowy, a wykorzystywany protokóª TCP zoptymalizowany jest pod k¡tem czasochªonnych transferów danych
o du»ych rozmiarach. Jednak dzi¦ki multipleksowaniu wszystkie poª¡czenia HTTP/2.0 s¡
trwaªe i mog¡ by¢ wspóªdzielone przez klienta, co przynosi nast¦puj¡ce korzy±ci:
•
zmniejszenie nasycenia sieci i zu»ycia zasobów,
•
spójna priorytyzacja dla wszystkich strumieni,
•
redukcja opó¹nienia i narzutu operacyjnego,
•
efektywno±¢ algorytmu
slow start.
8.2.6 Sterowanie przepªywem
Multipleksowanie wielu strumieni w obr¦bie sesji wprowadza zjawisko konkurencji o przepustowo±¢ sieci. Idea priorytetyzacji pozwala na determinacj¦ wzgl¦dnego porz¡dku dostarczania
komunikatów, jednak jest niewystarczaj¡ca do kontrolowania przydziaªu zasobów do poszczególnych strumieni i sesji. Z tego wzgl¦du dostarczono mechanizm sterowania przepªywem,
analogiczny do rozwi¡zania znanego z protokoªu TCP, które bazuje na rozgªaszaniu przez
odbiorc¦ rozmiaru okna danych gotowych do otrzymania i przetworzenia.
8.2.7 Transfer wyprzedzaj¡cy
Kolejnym udogodnieniem jest mo»liwo±¢ wysªania kilku odpowiedzi serwera na pojedyncze
»¡danie klienta (ang.
push ), co pozwala na wyprzedzaj¡ce dostarczenie dodatkowych zasobów
(rys. 8.6). W praktyce przyczynia si¦ to do znacznej redukcji opó¹nienia podczas przegl¡dania
stron internetowych, poniewa» »¡dany dokument HTML transmitowany jest wraz z zasobami
zewn¦trznymi w obr¦bie tego samego systemu plików. Symetryczny efekt osi¡galny jest w wersji HTTP/1.1 na poziomie aplikacji poprzez osadzenie zawarto±ci zasobu w dokumencie, przez
co jest bezpo±rednio dostarczany do klienta bez konieczno±ci realizacji dodatkowego »¡dania.
92
Rysunek 8.6: Obiecanie przesªania powi¡zanych zasobów przez serwer [34].
8.2.8 Kompresja nagªówka
Ka»da transakcja wymaga doª¡czenia nagªówka opisuj¡cego przesyªany zasób i jego wªa±ciwo±ci. W wersji HTTP/1.x jest on przesyªany w formacie tekstowym, stanowi¡c narzut rz¦du
kilkuset bajtów. Nowy protokóª zmniejsza to obci¡»enie poprzez kodowowanie metadanych
w postaci przyrostowej. Rozwi¡zanie polega na zapisywaniu przesyªanych nagªówków do tabel
aktualizowanych przez obie strony komunikacji na czas trwania sesji, co eliminuje konieczno±¢
transferu redundatnych informacji w nast¦puj¡cych po sobie komunikatach (rys. 8.7).
Rysunek 8.7: Przyrostowe kodowanie pól nagªówka [34].
Wdro»enie
Przewiduje si¦, »e aktualizacja protokoªu HTTP do wersji 2.0 b¦dzie procesem dªugotrwaªym,
poniewa» wymaga zmian po stronie serwera, klienta oraz powszechnie u»ywanych bibliotek
sieciowych. Szcz¦±liwie, wi¦kszo±¢ nowoczesnych przegl¡darek wykorzystuje mechanizm aktualizacji w tle, który pozwala na szybkie i przezroczyste wdro»enie nowego protokoªu dla szerokiego grona u»ytkowników. Natomiast serwery b¦d¡ prawdopodobnie przez dªu»szy czas
obsªugiwa¢ HTTP w wersjach 1.x i 2.0 w celu zapewnienia kompatybilno±ci wstecznej. Wi¡»e
si¦ to z konieczno±ci¡ wprowadzenia mechanizmu negocjacji sposobu komunikacji mi¦dzy stronami podczas zestawiania poª¡czenia.
93
Podsumowanie
Opisany w pracy protokóª HTTP stanowi podstawowy kanaª komunikacyjny pozwalaj¡cy
na jednolity i ustandaryzowany dost¦p do zasobów Internetu, zgodnie z zaªo»eniami pionierskiego projektu
World Wide Web.
Protokóª funkcjonuje w warstwie aplikacji na zasadzie
wymiany transakcji typu »adanie-odpowied¹, powszechnie stosowany jest w ró»norodnych ±rodowiskach sieciowych pocz¡wszy od szerokopasmowych sieci korporacyjnych, na ª¡czach
radiowych maªej mocy sko«czywszy.
Standard przez dekady ulegaª modykacjom dopasowuj¡c si¦ do zmian zachodz¡cych w topologii oraz rozmiarze globalnej sieci, a tak»e uwzgl¦dniaj¡c ewolucj¦ zasobów internetowych
przeksztaªacaj¡cych si¦ z prostych, statycznych stron do rozbudowanych i interaktywnych
aplikacji. Z tego wzgl¦du stopniowo wprowadzano usprawnienia i optymalizacje protokoªu.
Pierwotne wersje HTTP/0.9-1.0 stanowiªy nieskomplikowany protokóª wymiany dokumentów hipertekstowych. Obsªugiwaªy one »¡dania w sposób niewydajny, tworz¡c osobne poª¡czenia dla ka»dej operacji. Nie wspieraªy równie» hierarchicznych w¦zªów proxy, pami¦ci
podr¦cznej oraz serwerów wirtualnych. Spowodowaªo to konieczno±¢ wprowadzenia kolejnej
wersji HTTP/1.1, która dostarczyªa mechanizm poª¡cze« trwaªych, koncepcj¦ potokowania,
mo»liwo±¢ kompresji zasobów i transmisji fragmentów danych.
Ponadto na przestrzeni lat opracowano sposoby optymalizacji ±rodowiska pracy protokoªu
od strony klienta, serwera, a tak»e samej strony internetowej. Zrozumienie zasady dziaªania
tych technik oraz przemy±lane zastosowanie pozwala na dalsz¡ popraw¦ wydajno±ci HTTP, co
zaprezentowano na podstawie przeprowadzonego eksperymentu. Jego celem byªa werykacja
oraz ocena skuteczno±ci opisanych metod optymalizacyjnych. Analiza opieraªa si¦ na porównaniu widoków kaskady zasobów wygenerowanych przed i po wdro»eniu tych rozwi¡za«.
Punktem wyj±cia dla eksperymentu byª statystyczny model strony internetowej, który zostaª zbudowany za pomoc¡ zaimplementowanej aplikacji robota internetowego. Zrealizowany
program posªu»yª do przeprowadzenia procesu eksploracji sieci, czyli odwiedzenia wyspecykowanego zbioru popularnych witryn oraz obliczenie u±rednionej charakterystyki strony internetowej. Tak skonstruowany model wykorzystano podczas bada« do przygotowania przykªadowych stron, które zostaªy poddane wybranym technikom optymalizacyjnym. Ich efektywno±¢
zobrazowano za pomoc¡ kaskadowego widoku zasobów, specykuj¡cych liczb¦ »¡da«, wielko±¢
transferu oraz zale»no±ci czasowe przesyªanych obiektów.
Dodatkowo zilustrowano alternatywn¡ koncepcj¦ protokoªu, zwi¡zan¡ z zaniechanym projektem HTTP-NG. Zarysowano wizj¦ dalszego rozwoju standardu w kontek±cie nowego usprawnienia o nazwie SPDY, stanowi¡cego baz¦ dla przyszªej wersji HTTP/2.0, która prawdopodobnie zostanie wprowadzona do u»ytku w przeci¡gu kilku nast¦pnych lat.
94
Tablice
Nagªówki
Nagªówek »¡dania
Nazwa pola
Opis
Accept
Akceptowalne typy danych.
Przykªad
text/plain, image/jpg
Accept-Charset
Akceptowalne kodowanie znaków.
utf-8, iso-8859-1
Accept-Encoding
Akceptowalne sposoby kompresji.
gzip, deate, compress
Accept-Language
Akceptowalne j¦zyki.
en-US
Accept-Datetime
Akceptowalny znacznik czasowy zasobu.
Fri, 8 June 2012 12:13:00 GMT
Authorization
Dane uwierzytelniaj¡ce.
Basic QWxhZGuIHc2FtZQ==
Cookie
Ciasteczko wysªane przez serwer.
$Version=1; Skin=new;
From
Adres e-mail klienta.
[email protected]
User-Agent
Opis aplikacji klienckiej.
Mozilla/5.0 (X11; Linux i686)
Host
Identykacja serwera.
www.w3.org
Referer
Adres URL pocz¡tkuj¡cy »¡danie.
http://www.w3.org/about.html
If-Match
Warunek zgodno±ci znacznika ETag.
737060cd8c284d8af7ad3082f209
If-None-Match
Warunek niezgodno±ci znacznika ETag.
737060cd8c284d8af7ad3082f209
If-Modied-Since
Warunek modykacji wzgl¦dem daty.
Fri, 8 June 2012 12:13:00 GMT
If-Unmodied-Since
Warunek staªo±ci wzgl¦dem daty.
Fri, 8 June 2012 12:13:00 GMT
If-Range
Warunek zgodno±ci znacznika ETag (»¡da-
737060cd8c284d8af7ad3082f209
nie fragmentu zasobu).
Nagªówek odpowiedzi
Nazwa pola
Opis
Server
Nazwa i wersja serwera.
Apache/2.4.1 (Unix)
Location
Przekierowanie do innego zasobu.
http://www.w3.org/news.html
Set-Cookie
Denicja ciasteczka.
UserId=John; Max-Age=3600
Refresh
Przekierowanie do innego zasobu.
5; url=http://www.w3.org
Retry-After
Ponowienie »¡dania w okre±lonym czasie.
120
WWW-Authenticate
Schemat autoryzacji dost¦pu.
Basic
95
Przykªad
Nagªówek ogólny
Nazwa pola
Opis
Connection
Preferowany typ poª¡czenia.
keep-alive
Date
Data i czas wysªania komunikatu.
Fri, 8 June 2012 12:13:00 GMT
Pragma
Wytyczne dla uczestników komunikacji.
no-cache
Cache-Control
Wytyczne dla pami¦ci podr¦cznej.
no-cache
Trailer
Pola zawarte na ko«cu komunikatu.
Max-Forwards
Transfer-Encoding
Sposób kodowania transmisji.
chunked
Upgrade
¡danie zmiany wersji protokoªu.
SHTTP/1.3
Via
Lista w¦zªów proxy na ±cie»ce komunikacji.
1.1 example.com (Apache/1.1)
Warning
Potencjalny problem zwi¡zany z danymi.
199 Miscellaneous warning
Nazwa pola
Opis
Allow
Lista obsªugiwanych metod.
GET, HEAD
Expires
Termin wa»no±ci komunikatu.
Fri, 8 June 2012 12:13:00 GMT
Last-Modied
Ostatnia data modykacji zasobu.
Fri, 8 June 2012 12:13:00 GMT
Content-Encoding
Sposób kodowania danych.
gzip
Content-Language
J¦zyk danych.
pl
Content-Length
Rozmiar danych w oktetach.
512
Content-Location
Alternatywna lokalizacja danych.
/index.htm
Content-MD5
Skrót MD5 danych.
Q2hlY2sgSW50ZWdyaXR5IQ==
Content-Disposition
Sugestia obsªugi danych.
attachment; lename=cat.png
Content-Range
Pozycja danych w obr¦bie zasobu.
bytes 21010-47021/47022
Content-Type
Typ MIME danych.
text/html
ETag
Znacznik zasobu.
737060cd8c284d8af7ad3082f209
Link
Zwi¡zek z innymi zasobem.
</feed>; rel=alternate
Nagªówek danych
96
Przykªad
Przykªad
Statusy odpowiedzi
Statusy informacyjne
Znaczenie
Kod Status
100
Continue
Kontynuacja, pro±ba o dalsze wysyªanie zapytania.
101
Switching Protocols
Zmiana protokoªu.
110
Connection Timed Out
Przekroczono limit czasu poª¡czenia.
111
Connection Refused
Serwer odrzuciª poª¡czenie.
Statusy powodzenia
Znaczenie
Kod Status
200
OK
¡danie przetworzono, serwer zwraca zawarto±¢ zasobu.
201
Created
Wysªany dokument zostaª zapisany na serwerze.
202
Accepted
Zapytanie przyj¦te, lecz jeszcze nie przetworzone.
203
Non-Authoritative Information
Zwrócona informacja pochodzi z innego serwera.
204
No Content
Serwer nie zwraca zawarto±ci zasobu.
205
Reset Content
Klient powinien przywróci¢ pierwotny wygl¡d dokumentu.
206
Partial Content
Serwer zwraca cz¦±ciow¡ zawarto±¢ zasobu.
Kod Status
Statusy przekierowania
Znaczenie
300
Multiple Choices
Istnieje wi¦cej ni» jeden sposób obsªu»enia »¡dania.
301
Moved Permanently
Zasób zostaª przeniesiony pod inny adres URL.
302
Found
Zasób zostaª chwilowo przeniesiony pod inny adres URL.
303
See Other
Odpowied¹ znajduje si¦ pod innym adresem URL.
304
Not Modied
Zawarto±¢ nie ulegªa zmianie w kontek±cie warunku klienta.
305
Use Proxy
Zasób jest dost¦pny przez wskazany serwer proxy.
307
Temporary Redirect
Tymczasowe przekierowanie pod inny adres URL.
310
Too Many Redirects
Zbyt wiele przekierowa«.
97
Statusy bª¦dów klienta
Znaczenie
Kod Status
400
Bad Request
Nieprawidªowe »¡danie z powodu bª¦dnej skªadni.
401
Unauthorized
Nieautoryzowany dost¦p, konieczno±¢ uwierzytelnienia.
402
Payment Required
Dost¦p do zasobu wymaga opªaty.
403
Forbidden
Dost¦p do zasobu jest zabroniony.
404
Not Found
Zasób nie zostaª odnaleziony wedªug adresu URL.
405
Method Not Allowed
Wykonano niedozwolon¡ metod¦ dost¦pu do zasobu.
406
Not Acceptable
Typ zasobu nie jest obsªugiwany przez klienta.
407
Proxy Authentication Required
Wymagane uwierzytelnienie do serwera proxy
408
Request Timeout
Przekroczenie limitu czasu oczekiwania na »¡danie klienta.
409
Conict
Wyst¡pienie koniktu z obecnym statusem zasobu.
410
Gone
Zasób nie dost¦pny i nieznany jest nowy adres URL.
411
Length Required
Wymóg wskazania rozmiaru danych przez klienta.
412
Precondition Failed
Warunek wst¦pny nie mo»e by¢ speªniony przez serwer.
413
Request Entity Too Large
Dªugo±¢ »¡dania jest zbyt dªuga z perspektywy serwera.
414
Request-URI Too Long
Dªugo±¢ adresu URL jest zbyt dªugi z perspektywy serwera.
415
Unsupported Media Type
Nieznany sposób »¡dania dla serwera.
416
Requested Range Not Satisable
Niemo»no±¢ zwrócenia wskazanego zakresu bajtów.
417
Expectation Failed
Brak zawarto±ci zasobu oczekiwanej przez klienta.
Kod Status
Statusy bª¦dów serwera
Znaczenie
500
Internal Server Error
Wewn¦trzny bª¡d serwera.
501
Not Implemented
Brak wymaganej funkcjonalno±ci serwera.
502
Bad Gateway
Serwer po±redni nie jest w stanie zrealizowa¢ »¡dania.
503
Service Unavailable
Niedost¦pno±¢ serwera.
504
Gateway Timeout
Przekroczono limit czasu serwera po±redniego.
505
HTTP Version Not Supported
Brak obsªugi wskazanej wersji protokoªu HTTP.
98
Sªownik poj¦¢
WWW
(ang.
World Wide Web )
HTML
(ang.
Hypertext Markup Language )
UDP
(ang.
SSDP
ISP
CSS
(ang.
JSON
protokóª pakietów warstwy transportowej
Domain Name System )
Cascading Style Sheets )
(ang.
system tªumaczenia adresów sieciowych
j¦zyk opisu wygl¡du stron internetowych
Javascript Object Notation )
tekstowy format wymiany danych
(ang.
Extensible Markup Language )
CDN
(ang.
Content Delivery Network )
(ang.
Internet Protocol )
(ang.
Round Trip Ttime )
TCP
(ang.
Transport Control Protocol )
(ang.
j¦zyk reprezentacji ustrukturalizowanych danych
system serwerów wysokiej dost¦pno±ci
protokóª komunikacyjny warstwy sieciowej
RTT
HTTP
standard budowy komunikatu
dostawca usªugi Internetu
XML
IP
protokóª do wykrywania urz¡dze«
Multipurpose Internet Mail Extensions )
Internet Service Provider )
(ang.
hipertekstowy j¦zyk znaczników
Simple Service Discovery Protocol )
(ang.
(ang.
DNS
User Datagram Protocol )
(ang.
MIME
usªuga internetowa dost¦pu do globalnej sieci
czas podró»y pakietów w obie strony
protokóª komunikacyjny warstwy transportowej
Hypertext Transfer Protocol )
protokóª dokumentów hipertekstowych
99
Zawarto±¢ pªyty CD
Zaª¡czona do pracy pªyta CD zawiera nast¦puj¡ce katalogi:
application
cz¦±¢ implementacyjna pracy
src
kod ¹ródªowy aplikacji
res
pliki konguracji i bazy danych
thesis
cz¦±¢ merytoryczna pracy
pdf
dokument w formacie
latex
pdf
dokument w formacie
tex
100
Bibliograa
[1] R. Armstrong, D. Freitag, T. Joachims, and T. Mitchell.
prentice for the World Wide Web.
[2] H. Balakrishnan, S. Seshan, E. Amir, and R. Katz.
Wireless Networks.
Improving TCP/IP Performance over
ACM Press, 1995.
[3] P. Baldi, P. Frasconi, and P. Smyth.
[4] D. Barr.
WebWatcher: A Learning Ap-
Carnegie Mellon University, 1995.
Modeling the Internet and the Web.
Common DNS Operational and Conguration Errors.
[5] A. Barto.
Reinforcement Learning: An Introduction.
[6] M. Belshe.
More Bandwidth Doesn't Matter (Much).
[7] M. Belshe and A. Langley.
Wiley, 2003.
RFC 1912, IETF, 1996.
MIT Press, 1998.
Google, 2010.
SPDY: An Experimental Protocol for a Faster Web.
Google,
2009.
[8] M. Belshe, R. Peon, M. Thomson, and A. Melnikov.
2.0.
Hypertext Transfer Protocol Version
IETF, 2013.
[9] T. Berners-Lee.
Universal Resource Identiers in WWW.
[10] T. Berners-Lee, R. Fielding, and H. Frystyk.
RFC 1630, IETF, 1994.
Hypertext Transfer Protocol HTTP/1.0.
RFC 1945, IETF, 1996.
[11] S. Brin and L. Page.
The Anatomy of a Large-scale Hypertextual Web Search Engine.
Computer Networks and ISDN Systems, 1998.
[12] J. Brun.
List of Spiders and Crawlers.
[13] R. Buyya and A. Vakali.
CrawlTrack, 2013.
Content Delivery Networks.
[14] C. Castillo and R. Baeza-Yates.
http://www.crawltrack.net.
Springer, 2008.
A New Model for Web Crawling.
University of Chile,
2002.
[15] S. Chakrabarti, M. Berg, and B. Dom.
Specic Web Resource Discovery.
[16] D. Connolly.
Focused Crawling: a New Approach to Topic-
ACM Press, 1999.
A Little History of the World Wide Web.
[17] T. Cormen, C. Leiserson, R. Rivest, and C. Stein.
W3C, 2000.
Introduction to Algorithms.
MIT Press,
2001.
[18] N. Craswell, F. Crimmins, D. Hawking, and A. Moat.
in Web Search.
Performance and Cost Tradeos
Australasian Database Conference, 2004.
101
[19] B. Davison.
Topical Locality in the Web.
[20] P. Deutsch.
GZIP File Format Specication Version 4.3.
ACM Press, 2000.
RFC 1952, IETF, 1996.
[21] M. Diligenti, F. Coetzee, S. Lawrence, C. Giles, and M Gori.
Context Graphs.
[22] L. Dusseault and J. Snell.
[23] B. Erb.
Focused Crawling Using
World Wide Web Conference, 2000.
PATCH Method for HTTP.
RFC 5789, IETF, 2010.
Concurrent Programming for Scalable Web Architectures.
[24] R. Fielding.
Ulm University, 2012.
Architectural Styles and the Design of Network-based Software Architectures.
University of California, 2000.
[25] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and T. Berners-Lee.
Hypertext Transfer Protocol HTTP/1.1.
[26] D. Fisher.
Link Prefetching FAQ.
[27] D. Freed and N. Borenstein.
RFC 2616, IETF, 1999.
Mozilla, 2003.
https://developer.mozilla.org.
Multipurpose Internet Mail Extensions (MIME).
RFC 2045-
2049, IETF, 1996.
[28] H. Frystyk, J. Gettys, A. Baird-Smith, E. Prud'hommeaux, H. Wium, and C. Lilley.
Network Performance Eects of HTTP/1.1, CSS1, and PNG.
[29] E. Gamma, R. Helm, R. Johnson, and J. Vlissides.
Object-Oriented Software.
[30] H. Goei.
Design Patterns: Elements of Reusable
Addison-Wesley, 2000.
Debugging JavaScript and CSS Using Firebug.
[31] D. Gourley and B. Totty.
[32] J. Graessley.
W3C, 1997.
HTTP: The Denitive Guide.
Networking Best Practices.
O'Reilly Media, 2002.
Apple, 2012.
[33] I. Grigorik.
Latency: The New Web Performance Bottleneck.
[34] I. Grigorik.
High Performance Browser Networking.
[35] A. Grosskurth and M. Godfrey.
Google, 2012.
A Reference Architecture for Web Browsers.
University
of Waterloo, 2005.
[36] J. Heidemann.
Performance Interactions Between P-HTTP and TCP Implementations.
ACM Press, 1997.
[37] V. Jacobson.
Congestion Avoidance and Control.
Computer Communication Review,
1988.
[38] B. Janssen.
Binary Wire Protocol for HTTP-NG.
[39] M. Koster.
Guidelines for Robot Writers.
[40] M. Koster.
A Standard for Robot Exclusion.
[41] D. Kristol and L. Montulli.
W3C, 1998.
W3C, 1993.
IETF, 1994.
HTTP State Management Mechanism.
RFC 2965, IETF,
2000.
[42] A. Krohn.
Why Is My Page Slow?
GTMetrix, 2011.
102
http://gtmetrix.com.
[43] D. Larner.
Migrating the Web toward Distributed Objects.
[44] D. Larner.
HTTP-NG Web Interfaces.
W3C, 1998.
Accessibility of Information on the Web.
[45] S. Lawrence and C. Giles.
[47] B. Liu.
ACM Press, 2000.
Digital Libraries and Autonomous Citation
[46] S. Lawrence, C. Giles, and K. Bollacker.
Indexing.
Xerox, 1996.
IEEE, 1999.
Web Data Mining.
[48] P. Lyman and H. Varian.
[49] L. Masinter.
Springer, 2007.
How Much Information?
Hyper Text Coee Pot Control Protocol.
RFC 2324, IETF, 1998.
ARACHNID: Adaptive Retrieval Agents Choosing Heuristic Neighborhoods
for Information Discovery. University of California, 1997.
[50] F. Menczer.
[51] J. Mogul.
The Case for Persistent-Connection HTTP.
[52] M. Najork and A. Heydon.
[53] NetCraft.
High-Performance Web Crawling.
Web Server Survey.
[54] M. Nottingham.
2012.
Compaq, 2001.
http://www.netcraft.com.
Making HTTP Pipelining Usable on the Open Web.
[55] E. Nygren, R. Sitamaran, and J. Sun.
Performance Internet Applications.
[56] C. Olston and M. Najork.
[57] T. O'Reilly.
ACM Press, 1995.
IETF, 2011.
The Akamai Network: A Platform for High-
ACM Press, 2010.
Web Crawling.
Now, 2010.
Design Patterns and Business Models for the Next Generation of Software.
[58] V. Padmanabhan and J. Mogul.
Improving HTTP Latency.
ACM Press, 1994.
[59] D. Pariag, T. Brecht, A. Harji, P. Buhr, A. Shukla, and D. Cheriton.
Performance of Web Server Architectures.
Comparing the
ACM Press, 2007.
Proactor: An Object Behavioral Pattern for Demultiplexing and Dispatching Handlers for Asynchronous Events. Washington
[60] I. Pyarali, T. Harrison, D. Schmidt, and T. Jordan.
University, 1997.
[61] S. Ramachandran.
Web metrics: Size and Number of Resources.
[62] S. Russel and P. Norvig.
Google, 2010.
Articial Intelligence: A Modern Approach.
Prentice Hall, 2002.
Reactor: An Object Behavioral Pattern for Concurrent Event Demultiplexing
and Event Handler Dispatching. ACM Press, 1995.
[63] D. Schmidt.
[64] S. Seow.
Designing and Engineering Time.
[65] S. Souders.
High Performance Web Sites.
[66] S. Souders.
Even Faster Web Sites.
[67] S. Spero.
Pearson Education, 2008.
Analysis of HTTP Performance Problems.
103
W3C, 1994.
[68] StatCounter.
Browsers Worldwide Monthly.
[69] R. Stevens, B. Fenner, and A. Rudo.
Sockets Networking API.
2012.
http://www.statcounter.com.
Unix Network Programming, Volume 1: The
Addison-Wesley, 2003.
Mobile Applications Development Technologies Impact on Network Load and
Perceived Performance. Warsaw University of Technology, 2011.
[70] Z. Szl¦k.
[71] M. Welsh, D. Culler, and E. Brewer.
Scalable Internet Services.
[72] J. Wiebe.
SEDA: An Architecture for Well-Conditioned,
ACM Press, 2001.
State Space Search.
Pittsburgh University, 1997.
[73] A. Woodru, P. Aoki, E. Brewer, P. Gauthier, and L. Rowe.
ments from the World Wide Web.
An Investigation of Docu-
104

Optymalizacja parametrów i ±rodowiska pracy protokoªu HTTP

Transkrypt

Podobne dokumenty

„Przegląd Zachodni” nr 3/2005 - wstęp Współczesny człowiek

Java - podstawy j¦zyka W celu uzyskania zaliczenia zaj

Laboratorium Sieci Komputerowych

3 str - KORNELUK

Cennik us ug serwisowych ETI rado szycia

BS Jordanów | USŁUGI W SYSTEMIE ECORPONET

Stanowisko w sprawie finansowania rozwoju obszarów wiejskich w