plik

Przepraszam za brak obrazków ale zgodność licencyjna i
liber mocno :D (większości idzie się po prostu domyśleć a
mnie nie chce się kopiować) pozdrawiam PW [teraz tak
myślę, że rysunki jak komuś zależy są w darmowej wersji
angielskiej]

Definicje i historia

Opóźnienia

(ang. latency) Czas, który upływa od momentu wysłania pakietu przez

źródło do momentu odebrania pakietu przez punkt przeznaczenia.
Przepustowość

(ang. bandwidth) Maksymalna przepustowość logicznej lub

fizycznej ścieżki komunikacji.

Opóźnienie propagacji

Czas wymagany na przesłanie komunikatu od nadawcy do

odbiorcy. Jest to funkcja odległości do prędkości, z jaką rozchodzi się sygnał.
Opóźnienie transmisji

Czas wymagany na wypchnięcie wszystkich bitów pakietu

do łącza. Jest to funkcja długości pakietu do szybkości transmisji danych przez
łącze.
Opóźnienie przetwarzania

Czas wymagany na przetworzenie nagłówka pakietu,

sprawdzenie błędów na poziomie bitów oraz określenie miejsca przeznaczenia
pakietu.
Opóźnienie kolejkowania

Czas, jaki pakiet oczekuje w kolejce na przetworzenie.

Sieć ARPANET (ang. Advanced Research Projects Agency Network) była prekursorką
współczesnego internetu i pierwszą na świecie działającą siecią z komutacją pakietów (ang.
packet-switched network). Projekt oficjalnie ruszył w 1969 r., a w roku 1983 protokoły
TCP/IP zastąpiły wcześniejszy NCP (ang. Network Control Program), stając się głównymi
protokołami komunikacyjnymi. Reszta, jak powiadają, jest historią

(ang. Internet Protocol), czyli protokół internetowy, jest tym, co zapewnia

rutowanie i adresowanie pomiędzy hostami. Natomiast

TCP (ang. Transmission

Control Protocol), czyli protokół kontroli transmisji, tworzy abstrakcję niezawodnej
sieci działającej w zawodnym kanale. TCP/IP jest często określane „zestawem
protokołów internetowych” (ang. Internet Protocol Suite), a termin ten został po raz
pierwszy zaproponowany przez Vintona Cerfa i Roberta Kahna w roku 1974 w
artykule pod tytułem A Protocol for Packet Network Intercommunication.
Pierwotny dokument (RFC 675) był wielokrotnie zmieniany i w roku 1981 wersja 4.
specyfikacji TCP/IP została opublikowana nie jako pojedynczy dokument RFC, lecz
jako dwa oddzielne dokumenty: RFC 791 — Internet Protocol, RFC 793 —
Transmission Control Protocol.

Procedura three-way handshake w protokole TCP

Wszystkie połączenia TCP rozpoczynają się od procedury three-way handshake
(patrz rysunek 2.1). Zanim klient lub serwer będą mogły wymienić jakiekolwiek dane
aplikacji, muszą po obu stronach uzgodnić sekwencję liczb pakietu startowego oraz
szereg innych zmiennych charakterystycznych dla danego połączenia. Ze względów
bezpieczeństwa sekwencje liczb są wybierane po każdej ze stron losowo.
Standard HTTP nie określa TCP jako jedynego protokołu transportowego. Gdybyś
chciał, mógłbyś dostarczyć treść HTTP poprzez gniazda datagramowe (UDP — ang.
User Datagram Protocol) lub poprzez inny wybrany przez Ciebie protokół
transportowy. Jednak w praktyce cały ruch HTTP jest w internecie realizowany za
pomocą protokołu TCP ze względu na wiele wspaniałych właściwości, które
zapewnia od ręki.

SYN

(synchronizacja) Klient wybiera losową liczbę x z sekwencji i wysyła pakiet

SYN, który może również zawierać dodatkowe flagi i opcje TCP.

SYN ACK

(potwierdzenie synchronizacji) Serwer zwiększa wartość x o jeden,

wybiera własną losową liczbę y z sekwencji, dołącza swój zestaw flag i opcji, a
następnie rozsyła odpowiedź.

ACK

(zatwierdzenie połączenia) Klient zwiększa obie wartości x oraz y o jeden i

kończy procedurę nawiązywania połączenia, wysyłając ostatni pakiet ACK.

Powolny START
Rozwiązanie polega na tym, by powoli rozpocząć i zwiększać wartości rozmiaru
okna w miarę potwierdzania pakietów — na tym polega mechanizm powolnego
startu! Początkowo wartość startowa cwnd została ustawiona na 1 segment sieci; w
kwietniu 1999 r. dokument RFC 2581 zaktualizował tę wartość do maksymalnie 4
segmentów sieci. Ostatnio wartość ponownie została zwiększona, tym razem do 10
segmentów, zgodnie z dokumentem RFC 6928 z kwietnia 2013 r.
Maksymalna ilość danych przesyłanych dla nowego połączenia TCP stanowi
minimalne wartości rwnd i cwnd. Tym samym serwer może wysyłać nawet cztery
segmenty sieci do klienta, potem jednak musi zatrzymać przesyłanie danych i
czekać na potwierdzenie odbioru. Następnie dla każdego odebranego pakietu ACK
algorytm powolnego startu wskazuje, że serwer może zwiększyć wielkość okna
cwnd o jeden segment — dla każdego pakietu ACK mogą zostać wysłane dwa
pakiety. Ta faza połączenia TCP jest znana powszechnie jako algorytm wzrostu
wykładniczego (patrz rysunek 2.3), kiedy klient i serwer próbują szybko uzgodnić
przepustowość dostępną na ścieżce połączenia sieciowego pomiędzy nimi

HTTP

HTTP 0.9 — protokół dla jednego połączenia (rok 1991)
· Protokół typu klient-serwer, żądanie-odpowiedź.
· Protokół tekstowy, oparty na protokołach TCP/IP.

· Zaprojektowany do przesyłania dokumentów hipertekstowych (HTML).
· Połączenie między klientem a serwerem było zamykane po każdym żądaniu.
HTTP 1.0 — gwałtowny rozwój i specyfikacja RFC tworzenie

(1991 – 1995)

dokumenowanie (1995-1999)
W okresie nieograniczonych eksperymentów powstał pewien zbiór dobrych praktyk i
wspólnych wzorców, a w maju 1996 grupa HTTP Working Group (HTTP-WG) opublikowała
specyfikację

RFC 1945 dokumentującą „powszechne zastosowanie” wielu samoistnych

implementacji protokołu HTTP 1.0. Pamiętajmy, że była to tylko informacyjna specyfikacja.
Protokół HTTP 1.0, jak wiemy, nie jest formalną specyfikacją ani standardem
obowiązującym w internecie!
Nagłówki zarówno żądania, jak i odpowiedzi są zapisane w kodzie ASCII, ale sam obiekt
odpowiedzi może być dowolnego typu — plikiem HTML, zwykłym plikiem tekstowym,
obrazem lub dowolną inną treścią. Wprowadzenie metadanych http (nagłówków)
Protokół HTTP 1.1 — standard tworzenie (opublikowane 1997)
Standard HTTP 1.1 uregulował mnóstwo nieścisłości znalezionych we wcześniejszych
wersjach protokołu i wprowadził kilka ważnych metod optymalizacji wydajności:
podtrzymywanie połączeń

, transmisję danych w blokach, żądania przesłania zakresu

bajtów, dodatkowe mechanizmy zapisywania danych w pamięci podręcznej, kodowanie
przesyłanych danych i kolejkowanie żądań.
HTTP 2.0 — zwiększenie wydajności transmisji danych

RFC 2616

Protokół HTTP 2.0 koncentruje się głównie na zwiększeniu wydajności transmisji danych,
zmniejszeniu opóźnień i uzyskaniu większych przepływności. Dowolna strona WWW lub
aplikacja może być i będzie udostępniana z wykorzystaniem protokołu HTTP 2.0 bez
konieczności modyfikacji. Nie ma potrzeby zmiany kodu aplikacji, aby wykorzystać zalety
protokołu HTTP 2.0.
Dokument hipertekstowy

Dokument hipertekstowy stanowił genezę sieci WWW, był

zwykłym tekstem sformatowanym w podstawowym zakresie i zawierającym odnośniki. W
świetle nowoczesnych standardów nie brzmi to nadzwyczajnie, ale wówczas zostały w ten
sposób wyznaczone założenia, wizja i wielka przydatność sieci WWW.
Strona WWW

Grupa robocza pracująca nad protokołem HTTP i pierwsi dostawcy

przeglądarek rozszerzyli definicję hipertekstu o obsługę dodatkowych mediów, takich jak
obrazy i dźwięk, jak również dodali wiele innych elementów wzbogacających wygląd strony.
Nadeszła era stron WWW, umożliwiających wyświetlanie bogatych treści i zawierających
różne typy mediów. Wizualnie strony wyglądały pięknie, ale w większości przypadków nie
były interaktywne, niewiele różniły się od zadrukowanej kartki.

Aplikacja WWW

Wprowadzenie języka JavaScript i późniejsza rewolucja wywołana

dynamicznym protokołem HTML (DHTML) i technologią AJAX było kolejnym wstrząsem,
który przekształcił prostą stronę WWW w interaktywną aplikację, reagującą na czynności
użytkownika bezpośrednio w przeglądarce. Została przetarta droga do powstania
pierwszych w pełni funkcjonalnych aplikacji WWW, takich jak Outlook Web Access
(prekursor protokołu XMLHTTP w przeglądarce IE5), otwierających nową erę
skomplikowanych zależności między skryptami, stylami i znacznikami.
Podwórkowa definicja

PLT (ang. page load time) czas, po którym kółeczko w przeglądarce

przestaje się kręcić.

Techniczna definicja

: PLT (ang. page load time): czas wystąpienia zdarzenia onload

wywoływanego przez przeglądarkę po zakończeniu ładowania dokumentu i wszystkich
zawartych w nim zasobów (skryptów JavaScript, obrazów itp.).
projekt HTTP Archive (http://httparchive.org). Śledzi on rozwój sieci, przeglądając okresowo
najpopularniejsze strony (ponad 300 000 stron z serwisu Alexa Top 1M), rejestruje i
agreguje wyniki analizy ilości zastosowanych zasobów, typów treści, nagłówków i innych
metadanych każdej strony.
Wodospad zasobów jest skutecznym narzędziem umożliwiającym wykrycie zastosowanej
metody optymalizacji lub jej braku w dowolnej stronie bądź aplikacji. Opisany wyżej proces
analizy i optymalizacji wodospadu zasobów jest często nazywany

analizą i optymalizacją

wydajności interfejsu użytkownika

(ang. front-end performance).

Prawdziwym wąskim gardłem jest opóźnienie sieciowe pomiędzy klientem a
serwerem.

Ogólnie mówiąc,

testy syntetyczne oznaczają dowolny proces wykonany za pomocą

kontrolowanego środowiska. Jednak testy syntetyczne są niewystarczające do określenia
wszystkich czynników pogarszających wydajność. Problem polega w szczególności na tym,
że zebrane wyniki nie są reprezentatywne dla szerokiego spektrum różnorodnych
czynników, które w rzeczywistym świecie wpływają na ostateczną wydajność aplikacji u
końcowych użytkowników. Czynniki powodujące powstanie takiej luki to między innymi:

Scenariusze wyboru i korzystania ze stron — odtworzenie rzeczywistej nawigacji

użytkownika jest trudne.

Pamięć podręczna przeglądarki — wydajność może zmieniać się w szerokim zakresie w

zależności od stanu pamięci podręcznej przeglądarki u użytkownika.

Urządzenia pośrednie — wydajność może się zmieniać w zależności od pośrednich

serwerów proxy i pamięci podręcznej.

Różnorodność sprzętu — szerokie spektrum wydajności procesorów, procesorów

graficznych i pamięci.

Różnorodność przeglądarek — szerokie spektrum wersji, starych i nowych.

Połączenie — nieustannie zmieniające się pasmo i opóźnienie rzeczywistych połączeń.

Kombinacja wyżej wymienionych i podobnych czynników oznacza, że oprócz syntetycznych
testów musimy uzupełnić naszą strategię pomiaru wydajności o

rzeczywiste pomiary (ang.

real-user measurement, RUM),

W3C Web Performance Working Group wprowadziło interfejsy pomiarowe:

Navigation Timing API – główna strona

User Timing API

Resource Timing API – zasoby pobierane przez stronę

Połączone interfejsy Navigation, Resource oraz User Timing tworzą zestaw wszystkich
niezbędnych narzędzi do przygotowania i przeprowadzenia rzeczywistych pomiarów
wydajności każdej aplikacji WWW.

Optymalizacja przeglądarki

Optymalizacja dokumentu

Stos sieciowy jest zintegrowany z procesami przetwarzania

dokumentu, stylów CSS i wykonywania skryptów JavaScript, tak aby możliwe było
zidentyfikowanie i nadanie priorytetów krytycznym zasobom sieciowym, odpowiednio
wczesne wysłanie żądań i udostępnienie interaktywnej strony najszybciej, jak to możliwe.
Często odbywa się to przez przypisanie priorytetów zasobom, przez wyprzedzającą analizę
dokumentu i inne techniki.

Optymalizacja spekulatywna

W miarę upływu czasu przeglądarka może się uczyć

charakterystyki nawigacji użytkownika i przeprowadzać spekulatywną optymalizację oraz
przewidywać prawdopodobne czynności użytkownika, np. zawczasu rozwiązywać nazwy
DNS, zestawiać połączenia do serwerów itp.
Wstępne pobieranie i ustalanie priorytetów zasobów

Procesy analizy dokumentu, stylów

CSS i wykonywania skryptów JavaScript mogą przekazywać do stosu sieciowego
dodatkową informację o względnych priorytetach nadanych każdemu zasobowi. Zasobom
niezbędnym do pierwszego wyświetlenia strony nadawany jest wysoki priorytet, natomiast
żądania o niskim priorytecie mogą być tymczasowo umieszczone dalej w kolejce.
Wstępne rozwiązywanie nazw DNS

Nazwy serwerów, które prawdopodobnie zostaną

użyte, są zawczasu rozwiązywane w celu uniknięcia opóźnienia związanego z odpytaniem
serwera DNS w przyszłym żądaniu HTTP. Wstępne rozwiązywanie nazw może być
wykonywane na podstawie zapamiętanej historii nawigacji bądź w wyniku wykonania
określonej czynności użytkownika, takiej jak umieszczenie kursora myszy nad odnośnikiem,
lub na podstawie innych sygnałów wysyłanych przez stronę.
Wstępne nawiązywanie połączeń TCP

Po rozwiązaniu nazw za pomocą serwera DNS

przeglądarka może zawczasu nawiązać połączenie TCP, przewidując wysłanie żądania
HTTP. Jeżeli przewidywanie będzie trafne, zostanie dzięki temu wyeliminowane opóźnienie
sieciowe dotyczące nawiązania połączenia TCP.
Wstępne wyświetlenie strony

Niektóre przeglądarki potrafią przewidzieć, jaka strona

zostanie otwarta w następnej kolejności, wstępnie ją całą wyświetlić w ukrytej zakładce i
natychmiast się na nią przełączyć, gdy użytkownik rozpocznie nawigację.
Co powinniśmy robić aby zoptymalizować czas ładowania strony:

Wykrywanie krytycznych zasobów w dokumencie, takich jak style CSS i skrypty JavaScript,

powinno odbywać się jak najszybciej.

Style CSS powinny być przesyłane możliwie jak najwcześniej, aby nie blokować

wyświetlania strony i wykonywania skryptów JavaScript.

Pobieranie mniej krytycznych skryptów JavaScript powinno zostać odłożone na później, aby

nie blokować tworzenia obiektów DOM i CSSOM.

Dokument HTML jest analizowany stopniowo przez przeglądarkę, dlatego w celu osiągnięcia

najwyższej wydajności powinien być wysyłany do przeglądarki etapami.

Oprócz tego, że można zoptymalizować strukturę strony, w samym dokumencie można
zawrzeć dodatkowe wskazówki dotyczące optymalizacji, które przeglądarka może wykonać
za nas:

określonego serwera

zasobu umieszczonego w dalszej części strony

przyszłej nawigacji

przez użytkownika określonej strony i wstępne jej wyświetlenie
HTTP 1.1 wprowadził wiele udoskonaleń i funkcjonalności mających krytyczny wpływ na
wydajność, z których te najbardziej znane to między innymi:

trwałe połączenia umożliwiające ich wielokrotne użycie,

dzielenie danych na porcje umożliwiające strumieniowanie,

kolejkowanie żądań umożliwiające ich równoległe przetwarzanie,

operacje na bajtach umożliwiające wysyłanie żądań określonego zakresu danych,

ulepszony i ściślej określony mechanizm przechowywania danych w pamięci podręcznej

Zalecenia

Zmniejsz liczbę zapytań do serwerów DNS Każde rozwiązanie nazwy hosta wymaga

przesłania komunikatu przez sieć w obie strony, co wprowadza opóźnienie, a podczas
odpytywania wstrzymywane jest wykonywanie żądania.

Zmniejsz liczbę żądań HTTP Nie ma szybszego żądania od tego, które nie zostało

wykonane. Usuwaj niepotrzebne zasoby ze swoich stron.

Stosuj rozproszoną sieć serwerów (Content Delivery Network) Umiejscowienie danych

geograficznie bliżej klienta może znacząco zmniejszyć opóźnienie sieciowe każdego
połączenia TCP i zwiększyć prędkość transmisji.

Dodaj nagłówek Expires i skonfiguruj ETag Potrzebne zasoby powinny być umieszczane w

pamięci podręcznej, aby zapobiec wielokrotnemu żądaniu tych samych bajtów danych przez
każdą stronę. Nagłówek Expires może być użyty do określenia czasu przechowywania
obiektu w pamięci podręcznej, dzięki czemu obiekt może być z niej odczytany, a żądanie
HTTP całkowicie pominięte. Nagłówki ETag i Last-Modified oferują skuteczny mechanizm
odnawiania terminu ważności danych — za pomocą odcisku lub znacznika czasowego
ostatniej aktualizacji.

Kompresuj zasoby Wszystkie zasoby tekstowe przesyłane między klientem a serwerem

powinny być skompresowane metodą gzip. Wielkość pliku jest wtedy zmniejszana średnio o
60 – 80%. Zatem jest to jedna z prostszych i najbardziej wydajnych metod
optymalizacyjnych, jakie można zastosować (wymaga tylko ustawienia flagi konfiguracyjnej
na serwerze).

Unikaj przekierowań HTTP Przekierowania HTTP mogą być bardzo kosztowne, szczególnie

gdy klient jest kierowany do serwera o innej nazwie, co skutkuje dodatkowym odpytaniem
serwera DNS, opóźnieniem połączenia TCP itd.

Każde połączenie TCP rozpoczyna się od wymiany trzech pakietów, co wprowadza
pełne opóźnienie w obie strony pomiędzy klientem a serwerem.

Korzyści z podtrzymywania połączeń
Kolejkowanie żądań http

W praktyce z powodu braku multipleksacji kolejkowanie żądań HTTP powoduje wiele
subtelnych i nieudokumentowanych konsekwencji dla serwerów, urządzeń pośrednich i
klientów, na przykład:

Pojedyncza opóźniona odpowiedź blokuje wszystkie następne żądania.

W trakcie równoległego przetwarzania żądań serwery muszą przechowywać odpowiedzi w

buforach, co może prowadzić do wyczerpania zasobów. Co się na przykład stanie, jeżeli
odpowiedź będzie bardzo duża? Odkryty zostanie słaby punkt serwera, podatny na ataki!

Nieudana odpowiedź może spowodować przerwanie połączenia TCP, co zmusi klienta do

ponownego zażądania wszystkich następnych zasobów, i powtórne przetwarzanie.

Wykrycie kompatybilności kolejkowania żądań jest nietrywialnym zadaniem, szczególnie gdy

istnieją urządzenia pośrednie.

Niektóre urządzenia pośrednie nie obsługują kolejkowania żądań i mogą przerywać

połączenie, a inne mogą serializować wszystkie żądania.
Użycie wielu połączeń TCP

Maksymalne zwielokrotnienie żądań przy braku kolejkowania jest równe liczbie otwartych
połączeń. Ponadto wielkość okna TCP jest w rzeczywistości przemnożona przez liczbę
otwartych połączeń, co umożliwia klientowi obejście skonfigurowanego ograniczenia liczby
pakietów podczas wolnego startu transmisji TCP. Jak na razie, rozwiązanie wydaje się
dobre! Rozważmy jednak kilka kosztów tej metody:

dodatkowe wykorzystanie zasobów przez gniazda po stronie klienta, serwera i wszystkich

urządzeń pośrednich, dodatkowe bufory pamięci i obciążenie procesora;

rywalizację równoległych strumieni TCP o współdzielone pasmo łączy;

znacznie bardziej skomplikowaną implementację obsługi zestawu gniazd;

ograniczone możliwości równoległego przetwarzania danych przez aplikację, nawet przy

równoległych strumieniach TCP.

Rozdrobnienie domeny
W takim razie dlaczego ograniczać się do tego samego serwera? Zamiast wysyłać zasoby z
tego samego źródła (np. www.przyklad.com), możemy je ręcznie „rozdrobnić” między wiele
poddomen {dom1,domn}.przyklad.com. Ponieważ nazwy serwerów będą różne, więc
pośrednio zwiększymy liczbę połączeń na serwer i osiągniemy wyższy poziom
zrównoleglenia. Im większe rozdrobnienie, tym wyższe zrównoleglenie!
Oczywiście nic nie ma za darmo i rozdrobnienie domen (ang. domain sharding) nie jest tu
wyjątkiem. Każda nowa nazwa serwera wymaga osobnego odpytania serwera DNS, co
powoduje zajęcie kolejnych zasobów po obu stronach dodatkowego połączenia, a co
najgorsze, wymaga od twórcy strony ręcznego określenia, jak i gdzie mają być rozdzielone
zasoby.
Pomiar i kontrola narzutu protokołu
Protokół HTTP 0.9 zaczynał od prostego, jednowierszowego żądania dokumentu
hipertekstowego, które wprowadzało minimalny narzut. Wersja 1.0 rozszerzyła protokół
HTTP i wprowadziła pojęcie nagłówków żądań i odpowiedzi, umożliwiających obu stronom
wymianę dodatkowych metadanych. I wreszcie protokół HTTP 1.1 ustanowił standard tego
formatu — nagłówki mogą być łatwo rozszerzane przez serwer lub klienta i są zawsze
przesyłane jako zwykły tekst, aby były kompatybilne z poprzednimi wersjami protokołu
HTTP.

Konkatenacja i kompozycja zasobów

Konkatenacja

(ang. concatenation) Wiele plików JavaScript i CSS jest łączonych w

jednym żądaniu.
Kompozycja (

and. spriting) Z wielu obrazów jest komponowany jeden złożony obraz.

Pliki JavaScript i CSS można bezpiecznie połączyć bez wpływu na zachowanie i
wykonywanie kodu, o ile zostanie niezmieniona kolejność ich wykonywania.
Podobnie kilka obrazów może być połączonych w „kompozycję”, a style CSS mogą
być użyte do wybrania i umieszczenia części kompozycji w odpowiednim miejscu w
oknie przeglądarki. Korzyści z zastosowania powyższych technik są dwojakie:
Mniejszy narzut protokołu

Dzięki połączeniu plików w jeden zasób eliminowany jest

narzut protokołu wprowadzany przez każdy plik. Narzut ten, jak widzieliśmy
wcześniej, może łatwo skutkować przesyłaniem dodatkowych kilobajtów
nieskompresowanych danych.
Kolejkowanie na poziomie aplikacji

Ostateczny efekt zastosowania obu

powyższych technik, rozumiany jako prędkość przesyłania danych, jest taki sam jak
w przypadku kolejkowania HTTP: dane z wielu odpowiedzi są przesyłane jedne po
drugich, eliminując dzięki temu dodatkowe opóźnienie. W ten sposób po prostu
przesunęliśmy algorytm kolejkowania o jeden poziom wyżej, do naszej aplikacji.

Osadzanie zasobów
Osadzanie zasobów

(ang. resource inlining) jest inną popularną metodą optymalizacyjną

umożliwiającą zmniejszenie liczby wysyłanych żądań poprzez osadzenie zasobów w
dokumencie. Kody JavaScript i CSS mogą być umieszczone bezpośrednio na stronie w
odpowiednich blokach HTML, a inne zasoby, takie jak obrazy, a nawet pliki dźwiękowe lub
PDF, mogą być osadzone w schemacie danych URI

Oczekuje się, że protokół HTTP 2.0 wprowadzi następujące zmiany:

W przypadku większości stron w znaczący i wymierny sposób zostanie zmniejszone

opóźnienie postrzegane przez użytkowników w porównaniu z protokołem HTTP 1.1
wykorzystującym TCP.

Zostanie rozwiązany problem blokowania początku kolejki w protokole HTTP.

Do zrównoleglenia obsługi żądań nie będzie wymagane nawiązywanie wielu połączeń z

serwerem, dzięki czemu w większym stopniu będzie wykorzystany protokół TCP,
szczególnie pod kątem sterowania spiętrzeniami ruchu.

Zostanie zachowane działanie protokołu HTTP 1.1 zgodnie z istniejącą dokumentacją,

wykorzystujące metody HTTP (ale nie tylko), kody stanów, identyfikatory URI i pola
nagłówka tam, gdzie będzie to zasadne.

Będzie jasno zdefiniowana interakcja z protokołem HTTP 1.x, szczególnie w urządzeniach

pośrednich.

Będą jasno określone miejsca umożliwiające rozbudowę protokołu i zasady ich właściwego

wykorzystania.
Warstwa ramkowania binarnego

Rdzeniem wszystkich udoskonaleń wydajnościowych

wprowadzonych w protokole HTTP 2.0 jest nowa warstwa ramkowania binarnego (patrz
rysunek 12.1), która określa sposób enkapsulacji i przesyłania komunikatów między klientem
a serwerem.

Elementy protokołu HTTP, takie jak słowa kluczowe, metody i nagłówki, pozostają takie
same, ale zmiana polega na sposobie ich kodowania podczas transmisji. W odróżnieniu od
protokołu HTTP 1.x, opartego na zwykłym tekście podzielonym znakami nowego wiersza, w
protokole HTTP 2.0 wszystkie przesyłane dane są podzielone na mniejsze komunikaty i
ramki zakodowane w formacie binarnym.
Klient używający protokołu HTTP 1.x nie zrozumie serwera używającego tylko protokołu 2.0,
i odwrotnie.

Strumienie, komunikaty ramki
Ramka

najmniejsza jednostka danych w http 2.0, zawierająca nagłówek identyfikujący

przynajmniej strumień, do którego ramka należy.

Cała komunikacja odbywa się w ramach jednego połączenia TCP.

Multipleksacja żądań i odpowiedzi

Nowa warstwa ramkowania binarnego w protokole HTTP 2.0 usuwa te ograniczenia i
umożliwia pełną multipleksację żądań i odpowiedzi, dzięki czemu klient i serwer
mogą dzielić komunikaty HTTP na niezależne ramki (patrz rysunek 12.3), mieszać je
i ponownie składać po drugiej stronie.
Możliwość dzielenia komunikatów HTTP na niezależne ramki, mieszanie ich i
składanie po drugiej stronie to najważniejsze udoskonalenie wprowadzane przez
protokół HTTP 2.0. W rzeczywistości protokół oferuje wiele pochodnych korzyści
wydajnościowych w całym stosie technologii WWW. Umożliwia między innymi:

mieszanie wielu równoległych żądań bez ich wzajemnego blokowania,

mieszanie wielu równoległych odpowiedzi bez ich wzajemnego blokowania,

użycie jednego połączenia do równoległego przesyłania wielu żądań i odpowiedzi,

szybsze ładowanie stron dzięki eliminacji niepotrzebnych opóźnień,

usunięcie z kodu aplikacji niepotrzebnych napraw usterek protokołu HTTP 1.x,

Priorytety żądań

Po podzieleniu komunikatu HTTP na kilka osobnych ramek ich

kolejność przesyłania może być zoptymalizowana i w ten sposób może być
zwiększona wydajność naszej aplikacji. Aby to osiągnąć, każdemu strumieniowi jest
przypisana 31-bitowa wartość oznaczająca priorytet (0 najważniejsze, ostatni
najmniej ważny)
Jedno połączenie na serwer

Dzięki nowemu mechanizmowi ramkowania protokół

HTTP 2.0 nie potrzebuje wielu połączeń TCP, aby równolegle multipleksować wiele
strumieni. Zamiast tego każdy strumień jest dzielony na wiele ramek, które mogą być
mieszane i przesyłane z określonymi priorytetami. W rezultacie wszystkie połączenia
są trwałe, a pomiędzy klientem a serwerem jest używane tylko jedno połączenie.
Wypychanie zasobów

Bardzo użyteczną nową funkcjonalnością protokołu HTTP

2.0 jest możliwość wysyłania przez serwer wielu odpowiedzi na żądanie klienta.
Oznacza to, że serwer w odpowiedzi na żądanie klienta może wypchnąć dodatkowe
zasoby (patrz rysunek 12.4) bez konieczności żądania ich wprost przez klienta!
Ręcznie osadzając zasoby w dokumencie, w rzeczywistości wypychamy je do klienta
bez oczekiwania, aż ich zażąda. Jedyna różnica wprowadzana przez protokół HTTP

2.0 polega na przesunięciu tej czynności z aplikacji do samego protokołu, co
przynosi istotne korzyści:

Wypchnięte zasoby mogą być zapisane w pamięci podręcznej klienta.

Wypchnięte zasoby mogą być odrzucone przez klienta.

Wypchnięte zasoby mogą być wielokrotnie wykorzystane na różnych stronach.

Wypchnięte zasoby mogą mieć priorytety nadane przez serwer.

Serwer musi stosować mechanizm żądanie-odpowiedź i wypychać zasoby tylko w
odpowiedzi na żądanie klienta. Serwer nie może sam zainicjować wypychanego
strumienia. Ramki PUSH_PROMISE muszą zostać wysłane przed wysłaniem
odpowiedzi, aby uniknąć efektu wyścigu, tj. żądania przez klienta tych samych
zasobów, które serwer zamierza wypchnąć.

Kompresja nagłówka
Aby zmniejszyć narzut i poprawić wydajność, protokół HTTP 2.0 kompresuje
metadane w nagłówku:

Zamiast ponownego przesyłania tych samych danych w każdym żądaniu i

odpowiedzi protokół HTTP 2.0 stosuje „tabele nagłówków” po stronie klienta i
serwera do śledzenia i przechowywania wcześniej przesłanych par klucz-wartość.

Tabele nagłówków są tworzone dla całego połączenia HTTP 2.0 i są stopniowo

aktualizowane zarówno po stronie klienta, jak i serwera.

Każda nowa para klucz-wartość jest albo dołączana do istniejącej tabeli, albo

zastępuje poprzednią parę.



Krótkie wprowadzenie do ramkowania binarnego
Po nawiązaniu połączenia HTTP 2.0 klient i serwer komunikują się między sobą,
wymieniając ramki będące najmniejszą jednostką danych w protokole. Wszystkie
ramki mają taki sam 8-bajtowy nagłówek (patrz rysunek 12.6), zawierający długość
ramki, jej typ, pole z flagami i 31-bitowy identyfikator strumienia.


Inicjowanie nowego strumienia

Zanim zostaną przesłane jakiekolwiek dane

aplikacyjne, musi zostać utworzony nowy strumień i muszą być przesłane
odpowiednie metadane, takie jak priorytet strumienia i nagłówki HTTP. W protokole
HTTP 2.0 nowe strumienie mogą być zainicjowane zarówno przez klienta, jak i
serwer, a więc należy rozważyć dwa przypadki:

Klient inicjuje nowe żądanie, wysyłając ramkę HEADERS (patrz rysunek 12.7),

zawierającą jednolity nagłówek z identyfikatorem strumienia, opcjonalnym
31-bitowym priorytetem, a w polu danych zestaw nagłówków HTTP z parami
klucz-wartość.

Serwer inicjuje wypychany strumień, wysyłając ramkę PUSH_PROMISE, która jest

praktycznie identyczna z ramką HEADERS, z tym jednym wyjątkiem, że zawiera
dodatkowy „identyfikator obiecanego strumienia”, a nie jego priorytet.
Ramki obu typów są używane do przesyłania jedynie metadanych opisujących każdy
nowy strumień, a właściwe dane są dostarczane osobno w ramkach typu DATA.
Ponadto, ponieważ obie strony mogą inicjować nowe strumienie, ich numeracja jest
rozdzielona: strumienie inicjowane przez klienta mają parzyste identyfikatory, a
inicjowane przez serwer — nieparzyste. Taki podział eliminuje kolizje w numeracji
strumieni. Każda strona ma własny licznik zwiększany podczas inicjowania nowego
strumienia.
Przesyłanie danych

aplikacyjnych Po utworzeniu nowego strumienia i przesłaniu

nagłówków HTTP do przesłania danych aplikacyjnych (jeżeli takie istnieją) są
stosowane ramki DATA (patrz rysunek 12.8). Dane są dzielone na wiele ramek, z
których ostatnia ma w nagłówku ustawioną flagę END_STREAM, oznaczającą
koniec komunikatu.