Page 1


Tytuł oryginału: High Performance Browser Networking Tłumaczenie: Andrzej Watrak (wstęp, rozdz. 9 – 18), Lech Lachowski (rozdz. 1 – 8) ISBN: 978-83-246-8894-4 © 2014 Helion S.A. Authorized Polish translation of the English edition of High Performance Browser Networking, ISBN 9781449344764 © 2013 Ilya Grigorik This translation is published and sold by permission of O’Reilly Media, Inc., which owns or controls rights to publish and sell the same. All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from the Publisher. Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu niniejszej publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą kserograficzną, fotograficzną, a także kopiowanie książki na nośniku filmowym, magnetycznym lub innym powoduje naruszenie praw autorskich niniejszej publikacji. Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź towarowymi ich właścicieli. Autor oraz Wydawnictwo HELION dołożyli wszelkich starań, by zawarte w tej książce informacje były kompletne i rzetelne. Nie bierze jednak żadnej odpowiedzialności ani za ich wykorzystanie, ani za związane z tym ewentualne naruszenie praw patentowych lub autorskich. Wydawnictwo HELION nie ponosi również żadnej odpowiedzialności za ewentualne szkody wynikłe z wykorzystania informacji zawartych w książce. Wydawnictwo HELION ul. Kościuszki 1c, 44-100 GLIWICE tel. 32 231 22 19, 32 230 98 63 e-mail: helion@helion.pl WWW: http://helion.pl (księgarnia internetowa, katalog książek) Drogi Czytelniku! Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres http://helion.pl/user/opinie/wydapi Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję. Printed in Poland.

• Kup książkę • Poleć książkę • Oceń książkę

• Księgarnia internetowa • Lubię to! » Nasza społeczność


Spis treļci

Przedmowa ...................................................................................................................11 Wstýp ........................................................................................................................... 13

Czýļë I. Sieci ..................................................................................................... 17 1. Podstawowe informacje na temat opóŚnieħ i przepustowoļci ................................ 19 PrödkoĈè jest cechñ RóĔne skäadniki opóĒnieþ PrödkoĈè Ĉwiatäa i opóĒnienie propagacji OpóĒnienia ostatniego kilometra PrzepustowoĈè w sieciach rdzeniowych PrzepustowoĈè na brzegach sieci Zapewnianie wysokich przepustowoĈci i niskich opóĒnieþ

19 20 22 23 24 25 26

2. Budowanie bloków TCP ..............................................................................................29 Procedura three-way handshake Zapobieganie zatorom i kontrola przeciñĔenia Sterowanie przepäywem Powolny start Zapobieganie zatorom Produkt opóĒnienia i przepustowoĈci Blokowanie typu HOL Optymalizacja TCP Konfiguracja serwera dostrajajñcego Dostrajanie zachowaþ aplikacji Lista porad dotyczñcych wydajnoĈci

30 32 33 34 40 41 43 45 46 47 47

3

Kup książkę

Poleć książkę


3. Budowanie bloków UDP ..............................................................................................49 Usäugi protokoäu zerowego UDP i bramki NAT Limity czasu stanu poäñczenia Techniki przechodzenia przez bramki NAT STUN, TURN oraz ICE Optymalizacje dla protokoäu UDP

50 51 53 53 55 57

4. Protokóĥ TLS .................................................................................................................59 Szyfrowanie, uwierzytelnianie oraz integralnoĈè danych Procedura handshake TLS Rozszerzenie ALPN Rozszerzenie Server Name Indication (SNI) Wznowienie sesji TLS Identyfikatory sesji Bilety sesji ãaþcuch zaufania i urzödy certyfikacji Wycofanie certyfikatu Lista uniewaĔnionych certyfikatów Protokóä OCSP Protokóä TLS rekordu Optymalizacja TLS Koszty obliczeniowe WczeĈniejsze zakoþczenie Buforowanie sesji i bezstanowe wznowienie Rozmiar rekordu TLS Kompresja TLS DäugoĈè äaþcucha certyfikatów Zszywanie protokoäu OCSP Protokóä HSTS Lista porad dotyczñcych wydajnoĈci Testowanie i weryfikacja

60 62 64 66 66 67 68 69 71 71 72 73 74 74 75 77 78 79 80 81 82 82 83

Czýļë II. Wydajnoļë sieci bezprzewodowych ................................................ 85 5. Wprowadzenie do sieci bezprzewodowych .............................................................. 87 Powszechny dostöp Typy sieci bezprzewodowych

4

_

87 88

Spis treļci

Kup książkę

Poleć książkę


Podstawowe czynniki wpäywajñce na wydajnoĈè sieci bezprzewodowych SzerokoĈè pasma Siäa sygnaäu Modulacja Mierzenie wydajnoĈci bezprzewodowej w rzeczywistym Ĉwiecie

89 89 92 94 94

6. Wi-Fi ............................................................................................................................. 97 Od Ethernetu do bezprzewodowej sieci LAN Standardy i cechy Wi-Fi Pomiar i optymalizacja wydajnoĈci Wi-Fi Utrata pakietów w sieciach Wi-Fi Optymalizacja sieci Wi-Fi Wykorzystanie niemierzalnej przepustowoĈci Dostosowanie siö do zmiennej przepustowoĈci Dostosowanie siö do zmiennych opóĒnieþ

97 99 100 102 102 103 103 104

7. Sieci komórkowe ....................................................................................................... 107 Krótka historia sieci G Pierwsze usäugi transmisji danych w sieciach 2G Wspólne projekty 3GPP oraz 3GPP2 Ewolucja technologii 3G Wymagania standardu IMT-Advanced 4G Long Term Evolution (LTE) HSPA+ jako Ĉwiatowy lider w przysposobieniu standardu 4G Budowanie wielogeneracyjnej przyszäoĈci Funkcje i moĔliwoĈci urzñdzeþ Kategorie sprzötu uĔytkownika Protokóä RRC Wymagania dotyczñce zasilania w sieciach 3G, 4G oraz Wi-Fi Automat skoþczony RRC dla standardu LTE Automat skoþczony RRC dla standardów HSPA i HSPA+ (UMTS) Automat skoþczony RRC dla standardu EV-DO (CDMA) NieefektywnoĈè transferów okresowych Docelowa architektura operatora komórkowego Sieè radiowa (RAN) Sieè rdzeniowa PojemnoĈè i opóĒnienie systemów dosyäowych

107 108 109 111 113 114 115 116 118 118 120 122 123 125 127 128 129 130 131 134

Spis treļci

Kup książkę

_

Poleć książkę

5


Przepäyw pakietów w sieci komórkowej Inicjowanie Ĕñdania Przepäyw danych przychodzñcych Sieci heterogeniczne (HetNet) WydajnoĈè sieci 3G, 4G oraz Wi-Fi w rzeczywistym Ĉwiecie

134 135 137 139 141

8. Optymalizacja sieci komórkowych ........................................................................... 143 Oszczödzanie baterii Wyeliminowanie okresowych i nieefektywnych transferów danych Eliminowanie zbödnych poäñczeþ keepalive w aplikacjach Przewidywanie poziomu opóĒnienia sieciowego Uwzglödnianie zmian stanów RRC Oddzielenie interakcji uĔytkownika od komunikacji sieciowej Projektowanie przy uwzglödnieniu zmiennej dostöpnoĈci do interfejsu sieciowego Transmisja seryjna i powrót do stanu bezczynnoĈci Przerzucanie obciñĔenia na sieci Wi-Fi Stosuj najlepsze praktyki dla protokoäu i aplikacji

144 146 148 149 150 150 151 153 154 154

Czýļë III. HTTP ................................................................................................ 157 9. Krótka historia protokoĥu HTTP ................................................................................ 159 HTTP 0.9 — protokóä dla jednego poäñczenia HTTP 1.0 — gwaätowny rozwój i specyfikacja RFC Protokóä HTTP 1.1 — standard internetu HTTP 2.0 — zwiökszenie wydajnoĈci transmisji danych

159 160 162 164

10. Wprowadzenie do wydajnoļci aplikacji WWW ....................................................... 167 Hipertekst, strony i aplikacje WWW Anatomia nowoczesnej aplikacji WWW SzybkoĈè, wydajnoĈè i wraĔenia uĔytkownika Analiza wodospadu zasobów Filary wydajnoĈci — przetwarzanie, wyĈwietlanie, transmisja danych Szersze pasmo nie ma (wiökszego) znaczenia OpóĒnienie sieciowe, wñskie gardäo w wydajnoĈci Syntetyczny i rzeczywisty pomiar wydajnoĈci Optymalizacja przeglñdarki

167 170 171 172 176 177 177 179 182

11. Protokóĥ HTTP 1.X ...................................................................................................... 187 KorzyĈci z podtrzymywania poäñczeþ Kolejkowanie Ĕñdaþ HTTP

6

_

189 192

Spis treļci

Kup książkę

Poleć książkę


UĔycie wielu poäñczeþ TCP Rozdrobnienie domeny Pomiar i kontrola narzutu protokoäu Konkatenacja i kompozycja zasobów Osadzanie zasobów

195 197 199 200 203

12. Protokóĥ HTTP 2.0 ......................................................................................................205 Historia protokoäu i jego zwiñzek ze SPDY Droga do HTTP 2.0 Cele projektowe i techniczne Warstwa ramkowania binarnego Strumienie, komunikaty i ramki Multipleksacja Ĕñdaþ i odpowiedzi Priorytety Ĕñdaþ Jedno poäñczenie na serwer Sterowanie przepäywem Wypychanie zasobów Kompresja nagäówka Skuteczna aktualizacja i wykrywanie protokoäu HTTP 2.0 Krótkie wprowadzenie do ramkowania binarnego Inicjowanie nowego strumienia Przesyäanie danych aplikacyjnych Analiza przepäywu ramek DATA w protokole HTTP 2.0

206 206 208 209 210 211 212 214 214 216 218 220 222 224 224 225

13. Optymalizacja aplikacji ............................................................................................. 227 Zawsze aktualne najlepsze praktyki wydajnoĈciowe Zapamiötywanie zasobów po stronie klienta Przesyäanie skompresowanych danych Eliminacja niepotrzebnych bajtów Ĕñdaþ Równolegäe przetwarzanie Ĕñdaþ i odpowiedzi Optymalizacja protokoäu HTTP 1.x Optymalizacja protokoäu HTTP 2.0 Usuniöcie optymalizacji 1.x Strategie optymalizacyjne w przypadku dwóch protokoäów Translacja protokoäu 1.x na 2.0 i z powrotem Ocena jakoĈci i wydajnoĈci serwera Komunikacja 2.0 z protokoäem TLS i bez niego Serwery obciñĔenia, proxy i aplikacji

229 230 231 232 233 234 235 236 237 239 240 240 241

Spis treļci

Kup książkę

_

Poleć książkę

7


Czýļë IV. Interfejsy API i protokoĥy przeglédarki ........................................ 243 14. Podstawy komunikacji sieciowej przeglédarek .......................................................245 Zarzñdzanie poäñczeniami i ich optymalizacja Bezpieczeþstwo sieciowe i izolacja aplikacji Przechowywanie zasobów i stanu klienta Interfejsy API i protokoäy aplikacyjne

246 248 248 249

15. Protokóĥ XMLHttpRequest ........................................................................................ 251 Krótka historia protokoäu XHR Miödzydomenowe wspóädzielenie zasobów (CORS) Pobieranie danych za pomocñ XHR Wysyäanie danych za pomocñ XHR Monitorowanie postöpu pobierania i wysyäania danych Strumieniowanie danych za pomocñ XHR Powiadamianie i dostarczanie danych w czasie rzeczywistym Odpytywanie w protokole XHR Däugotrwaäe odpytywanie w protokole XHR Przykäady uĔycia i wydajnoĈè protokoäu XHR

252 253 256 257 258 260 262 262 264 266

16. Server-Sent Events (SSE) ...........................................................................................269 Interfejs EventSource API Protokóä strumienia zdarzeþ Zastosowanie i wydajnoĈè protokoäu SSE

269 271 274

17. WebSocket ................................................................................................................. 277 Interfejs WebSocket API Schematy adresów URL w protokoäach WS oraz WSS Odbieranie danych tekstowych i binarnych Wysyäanie danych tekstowych i binarnych Negocjacja subprotokoäu Protokóä WebSocket Warstwa ramkowania binarnego Rozszerzenia protokoäu Negocjacja Upgrade w protokole HTTP Zastosowanie i wydajnoĈè protokoäu WebSocket Strumieniowanie Ĕñdaþ i odpowiedzi Narzut komunikatów WydajnoĈè i kompresja danych Wäasne protokoäy aplikacyjne WdroĔenie protokoäu WebSocket WydajnoĈciowa lista kontrolna 8

_

278 279 279 281 282 283 284 286 286 289 290 291 291 292 293 294

Spis treļci

Kup książkę

Poleć książkę


18. Komunikacja WebRTC ............................................................................................... 297 Standardy i rozwój komunikacji WebRTC Usäugi audio i wideo Pozyskiwanie strumienia audio i wideo za pomocñ metody getUserMedia Transmisja sieciowa w czasie rzeczywistym Krótkie wprowadzenie do interfejsu RTCPeerConnection API Nawiñzanie poäñczenia peer-to-peer Sygnalizacja i negocjacja sesji Protokóä Session Description Protocol (SDP) Protokóä Interactive Connectivity Establishment (ICE) Przyrostowe zbieranie danych (Trickle ICE) Przyrostowe zbieranie danych ICE i status poäñczenia Zebranie wszystkich elementów Przesyäanie mediów i danych aplikacyjnych Protokóä Datagram Transport Layer Security Przesyäanie mediów w protokoäach SRTP i SRTCP Przesyäanie danych aplikacyjnych za pomocñ protokoäu SCTP Protokóä DataChannel Konfiguracja i negocjacja poäñczenia Konfiguracja kolejnoĈci i gwarancji dostarczania komunikatów CzöĈciowa gwarancja dostarczania a wielkoĈè pakietu Zastosowanie i wydajnoĈè komunikacji WebRTC Strumieniowanie audio, wideo i danych Architektury poäñczeþ wielostronnych Planowanie infrastruktury i pojemnoĈci WydajnoĈè i kompresja danych WydajnoĈciowa lista kontrolna

298 298 300 302 304 306 307 309 311 314 315 317 321 321 323 326 331 333 335 337 337 338 339 340 342 342

Skorowidz ..................................................................................................................345

Spis treļci

Kup książkę

_

Poleć książkę

9


10

_

Spis treļci

Kup książkę

Poleć książkę


ROZDZIAĤ 12.

Protokóĥ HTTP 2.0

Protokóä HTTP 2.0 sprawia, Ĕe nasza aplikacja jest szybsza, prostsza i bardziej spójna (to rzadkie poäñczenie cech). Dziöki niemu moĔna usunñè z aplikacji wiele tymczasowych korekt protokoäu HTTP 1.1, poniewaĔ teraz zostaäy one wprowadzone w warstwie transportowej. Co wiöcej, nowa wersja otwiera mnóstwo zupeänie nowych moĔliwoĈci optymalizacji aplikacji i poprawy wydajnoĈci! Podstawowym celem protokoäu HTTP 2.0 jest zmniejszenie opóĒnieþ aplikacji poprzez udostöpnienie peänej multipleksacji Ĕñdaþ i odpowiedzi, zminimalizowanie narzutu protokoäu za pomocñ skutecznej kompresji pól nagäówka HTTP, nadawanie Ĕñdaniom priorytetów i wypychanie zasobów. Aby zaimplementowaè te funkcjonalnoĈci, wprowadzono wiele dodatkowych ulepszeþ, takich jak sterowanie przepäywem, obsäuga bäödów i mechanizmy aktualizacji danych. Sñ to najwaĔniejsze funkcjonalnoĈci, które powinien rozumieè i wykorzystywaè w swoich aplikacjach kaĔdy programista stron WWW. Wersja HTTP 2.0 w Ĕaden sposób nie zmienia sposobu wykorzystania protokoäu HTTP przez aplikacjö. Wszystkie podstawowe koncepcje, takie jak metody HTTP, kody stanów, identyfikatory URI i pola nagäówka, wciñĔ istniejñ. Natomiast wersja HTTP 2.0 zmienia sposób formatowania (ramkowania) danych i przesyäania ich miödzy klientem a serwerem. Obie strony zarzñdzajñ procesem komunikacji, a wszystkie jego zawiäoĈci sñ ukryte przed aplikacjñ w nowej warstwie ramkowania. W rezultacie wszystkie istniejñce aplikacje mogñ byè stosowane bez modyfikacji. To sñ dobre wiadomoĈci. Jednak my jesteĈmy zainteresowani nie tylko samym dostarczaniem dziaäajñcej aplikacji. Naszym celem jest osiñgniöcie jak najwyĔszej wydajnoĈci! Protokóä HTTP 2.0 oferuje kilka nowych metod optymalizacji, które wczeĈniej nie byäy moĔliwe, a teraz moĔna zastosowaè je w naszej aplikacji. Naszym zadaniem jest jak najlepiej je wykorzystaè. Przyjrzyjmy siö bliĔej, co jest w Ĉrodku protokoäu. Standard w trakcie tworzenia Obecnie protokóä HTTP 2.0 jest na etapie aktywnego tworzenia. Podstawowe konstrukcje architektury, zasady dziaäania i nowe funkcjonalnoĈci sñ jasno okreĈlone, ale tego samego nie moĔna powiedzieè o konkretnych niskopoziomowych szczegóäach implementacyjnych. Z tego powodu skupimy siö na architekturze protokoäu i jej implementacji, a format przesyäanych danych bödzie omówiony bardzo ogólnie, w stopniu wystarczajñcym do zrozumienia dziaäania protokoäu i wynikajñcych z niego konsekwencji. Aby poznaè najnowszñ specyfikacjö i status standardu protokoäu HTTP 2.0, odwiedĒ stronö IETF pod adresem http://tools.ietf.org/html/draft-ietf-httpbis-http2.

205

Kup książkę

Poleć książkę


Historia protokoĥu i jego zwiézek ze SPDY SPDY jest eksperymentalnym protokoäem opracowanym przez Google, udostöpnionym w poäowie roku 2009. Jego podstawowym celem byäo skrócenie czasu äadowania stron WWW i rozwiñzanie kilku znanych ograniczeþ wydajnoĈciowych protokoäu HTTP 1.1. W szczególnoĈci projekt miaä nakreĈlone nastöpujñce cele: x skrócenie czasu äadowania strony o 50%, x unikniöcie koniecznoĈci zmiany zawartoĈci stron WWW przez ich twórców, x zminimalizowanie zäoĔonoĈci wdroĔenia, unikniöcie zmian w infrastrukturze sieciowej, x opracowanie nowego protokoäu wspólnie ze spoäecznoĈciñ tworzñcñ otwarty kod, x zebranie rzeczywistych danych wydajnoĈciowych w celu zatwierdzenia lub odrzucenia

eksperymentalnego protokoäu. Aby osiñgnñè poprawö czasu äadowania strony o 50%, protokóä SPDY w zaäoĔeniu miaä efektywniej wykorzystywaè poäñczenia TCP przez wprowadzenie nowej warstwy ramkowania binarnego, umoĔliwiajñcej multipleksacjö Ĕñdaþ i odpowiedzi, nadawanie priorytetów i minimalizacjö lub eliminacjö niepotrzebnego opóĒnienia sieciowego (patrz podrozdziaä „OpóĒnienie sieciowe, wñskie gardäo w wydajnoĈci” w rozdziale 10.).

Niedäugo po pierwszej zapowiedzi protokoäu, inĔynierowie Google, Mike Belshe i Roberto Peon, ogäosili swoje pierwsze wyniki, dokumentacjö i kod Ēródäowy eksperymentalnej implementacji nowego protokoäu SPDY: Jak dotñd, przetestowaliĈmy protokóä SPDY jedynie w warunkach laboratoryjnych. Wyniki wyglñdajñ bardzo obiecujñco. Podczas otwierania 25 najpopularniejszych stron WWW poprzez symulowane domowe poäñczenie sieciowe stwierdziliĈmy znacznñ poprawö wydajnoĈci — strony äadowaäy siö o 55% szybciej. — A 2x Faster Web („2 × szybsza sieè”) Chromium Blog

Przeskoczmy szybko kilka lat wprzód, do roku 2012. Nowy, eksperymentalny protokóä jest obsäugiwany przez przeglñdarki Chrome, Firefox, Opera, a wiele duĔych stron (np. Google, Twitter, Facebook) oferuje protokóä SPDY kompatybilnym z nim klientom. Innymi säowy, okazaäo siö, Ĕe protokóä SPDY zaoferowaä ogromne korzyĈci wydajnoĈciowe, a wskutek jego coraz szerszego zastosowania staä siö de facto standardem. W efekcie grupa HTTP Working Group (HTTPWG), wyciñgajñc wnioski z lekcji protokoäu SPDY, opublikowaäa na poczñtku roku 2012 nowy protokóä HTTP 2.0 i wprowadziäa go jako oficjalny standard.

Droga do HTTP 2.0 Protokóä SPDY byä zalñĔkiem protokoäu HTTP 2.0, ale nie jest to wäaĈciwy protokóä HTTP 2.0. Pierwsza specyfikacja protokoäu HTTP 2.0 pojawiäa siö na poczñtku 2012 roku i po burzliwych dyskusjach wewnñtrz grupy HTTPWG specyfikacja SPDY zostaäa przyjöta jako punkt startowy w pracy nad nowym standardem. Od tej pory do oficjalnego standardu protokoäu HTTP 2.0 zostaäo wprowadzonych i bödzie dalej wprowadzanych wiele zmian i ulepszeþ.

206

_

Rozdziaĥ 12. Protokóĥ HTTP 2.0

Kup książkę

Poleć książkę


Jednak zanim wybiegniemy za daleko, warto przejrzeè wstöpnñ propozycjö protokoäu HTTP 2.0, poniewaĔ uwidacznia ona zakres i najwaĔniejsze zaäoĔenia protokoäu: Oczekuje siö, Ĕe protokóä HTTP 2.0 wprowadzi nastöpujñce zmiany: x 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.

x Zostanie rozwiñzany problem blokowania poczñtku kolejki w protokole HTTP. x 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.

x 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.

x Bödzie jasno zdefiniowana interakcja z protokoäem HTTP 1.x, szczególnie w urzñdze-

niach poĈrednich.

x Bödñ jasno okreĈlone miejsca umoĔliwiajñce rozbudowö protokoäu i zasady ich wäa-

Ĉciwego wykorzystania.

Oczekuje siö, Ĕe ostateczna specyfikacja speäni powyĔsze oczekiwania w przypadku istniejñcych wdroĔeþ protokoäu HTTP, dotyczñcych szczególnie przeglñdania internetu (za pomocñ urzñdzeþ stacjonarnych i mobilnych), uĔycia poza przeglñdarkami (HTTP API), udostöpniania stron WWW (w róĔnej skali wielkoĈci) i obsäugi w urzñdzeniach poĈrednich (serwerach proxy, zaporach, odwrotnych serwerach proxy i w sieciach CDN). Analogicznie bieĔñce i przyszäe rozszerzenia protokoäu HTTP/1.x (np. nagäówki, metody, kody stanu, dyrektywy pamiöci podröcznej) bödñ obsäugiwane w nowym protokole. — Statut grupy roboczej HTTPbis HTTP 2.0

Krótko mówiñc, protokóä HTTP 2.0 miaä na celu rozwiñzanie wielu znanych ograniczeþ wydajnoĈciowych poprzednich standardów 1.x, jak równieĔ ich rozwiniöcie, lecz nie zastñpienie. Wykorzystanie protokoäu HTTP w aplikacji pozostaäo takie samo i nie zostaäy wprowadzone Ĕadne zmiany do oferowanych funkcjonalnoĈci ani podstawowych koncepcji, takich jak metody, kody stanów, identyfikatory URI i pola nagäówka. Tego typu zmiany zostaäy jawnie wykluczone. Czy w takim razie oznaczenie „2.0” jest uzasadnione? Powodem zwiökszenia gäównego numeru wersji do 2.0 jest zmiana sposobu wymiany danych miödzy klientem a serwerem. Aby osiñgnñè wytyczone cele wydajnoĈciowe, protokóä HTTP 2.0 wprowadza nowñ warstwö ramkowania binarnego, która nie jest kompatybilna wstecz z poprzedniñ wersjñ 1.x. Stñd numer 2.0. O ile nie implementujesz wäasnego serwera WWW lub nietypowego klienta i nie operujesz na podstawowych gniazdach TCP, to moĔe siö okazaè, Ĕe nawet nie zauwaĔysz Ĕadnej z faktycznych zmian wprowadzonych przez protokóä HTTP 2.0. Caäe nowe niskopoziomowe ramkowanie jest wykonywane za Ciebie przez przeglñdarkö i serwer. Jedynñ róĔnicñ moĔe byè dostöpnoĈè nowych i opcjonalnych funkcjonalnoĈci interfejsu API, na przykäad wypychania zasobów!

Droga do HTTP 2.0

Kup książkę

_

Poleć książkę

207


Na koniec warto omówiè prognozy rozwoju protokoäu HTTP 2.0. Opracowanie nowej wersji protokoäu realizujñcego caäñ komunikacjö w sieci WWW jest nietrywialnym zadaniem, wymagajñcym wielu starannych przemyĈleþ, eksperymentów i koordynacji prac. Dlatego prognozowanie rozwoju protokoäu HTTP 2.0 jest niebezpiecznym procederem. Protokóä bödzie gotowy wtedy, gdy bödzie gotowy. Oznacza to, Ĕe grupa HTTP-WG robi szybkie postöpy i oficjalnie wyznaczyäa nastöpujñce etapy: x marzec 2012 — ogäoszenie zapotrzebowania na protokóä HTTP 2.0, x wrzesieþ 2012 — pierwsza specyfikacja protokoäu HTTP 2.0, x lipiec 2013 — pierwsza specyfikacja implementacji protokoäu 2.0, x kwiecieþ 2014 — ostatnie prace grupy Working Group nad protokoäem HTTP 2.0, x listopad 2014 — przesäanie do grupy IESG specyfikacji protokoäu HTTP 2.0 jako propo-

zycji nowego standardu.

DuĔa przerwa miödzy rokiem 2012 a 2014 przypadäa na intensywne prace edycyjne i eksperymentalne. W zaleĔnoĈci od postöpów i opinii ze strony administratorów i Ĉrodowiska jako caäoĈci daty mogñ siö zmieniè. Dobra wiadomoĈè jest taka, Ĕe na koniec roku 2013 harmonogram byä dotrzymany!

Wspólna ewolucja protokoĥów HTTP 2.0 i SPDY Grupa pracujñca nad protokoäem HTTP przyjöäa w lecie 2012 roku specyfikacjö protokoäu SPDY v2 jako punkt startowy prac nad standardem HTTP 2.0. Jednak gdy to siö staäo, prace nad protokoäem SPDY nie ustaäy. Wröcz przeciwnie, protokóä SPDY równolegle ewoluowaä: x W 2012 roku zostaäa ogäoszona wersja SPDY v3 ze zaktualizowanym formatem ramko-

wania i pierwszñ implementacjñ sterowania przepäywem.

x Na przeäomie lat 2013 i 2014 zostaäa udostöpniona wersja SPDY v4 ze zaktualizowanym (po-

nownie) formatem ramkowania, usprawnionñ obsäugñ priorytetów, sterowaniem przepäywem i zaimplementowanym wypychaniem zasobów.

Powód kontynuacji rozwoju protokoäu SPDY jest prosty — jest to motor napödowy w eksperymentach z nowymi funkcjonalnoĈciami i propozycjami dla protokoäu HTTP 2.0. To, co dobrze wyglñda na papierze, moĔe nie dziaäaè w praktyce i vice versa. Protokóä SPDY jest drogñ do testów i oceny kaĔdej propozycji przed zawarciem jej w standardzie 2.0. Ten stopniowy proces rozwoju i wspólnej ewolucji protokoäów SPDY i HTTP 2.0 zadaä wiele pracy programistom, ale w praktyce przyniesie równieĔ wiele korzyĈci — bardziej zwartñ i dokäadnie przetestowanñ specyfikacjö, jak równieĔ implementacjö serwera i klienta, które takĔe mogñ równolegle wspólnie ewoluowaè. W rzeczywistoĈci, gdy pojawi siö protokóä HTTP 2.0 z oznaczeniem „gotowy”, bödziemy mieè dokäadnie przetestowane implementacje popularnych serwerów i klientów! W tym momencie protokóä SPDY bödzie mógä przejĈè na emeryturö, a na Ĉrodku sceny pojawi siö protokóä HTTP 2.0.

Cele projektowe i techniczne Protokóä HTTP 1.x zostaä zaprojektowany pod kñtem prostoty implementacji. Protokóä HTTP 0.9 byä jednowierszowñ wersjñ, która zapoczñtkowaäa rozwój sieci WWW. Protokóä HTTP 1.0 usystematyzowaä rozszerzenia wersji 0.9 w nieformalnym standardzie, a wersja 1.1 staäa siö 208 _

Rozdziaĥ 12. Protokóĥ HTTP 2.0

Kup książkę

Poleć książkę


oficjalnym standardem IETF (patrz rozdziaä 9.). W ten sposób protokóä 0.9 – 1.x staä siö tym, czym miaä siö staè — jednym z najbardziej rozpowszechnionych i najszerzej zaimplementowanych protokoäów aplikacyjnych w internecie. Niestety, prostota implementacji szäa w parze z kosztami wydajnoĈci aplikacji, co stanowiäo lukö, którñ wäaĈnie protokóä HTTP 2.0 z zaäoĔenia ma wypeäniè: Enkapsulacja HTTP/2.0 umoĔliwia lepsze wykorzystanie zasobów sieciowych i dziöki kompresji pól nagäówka i jednoczesnemu przesyäaniu wielu komunikatów w ramach tego samego poäñczenia zmniejszenie postrzeganych przez uĔytkowników opóĒnieþ. Protokóä wprowadza równieĔ spontaniczne wypychanie zasobów z serwerów do klientów. — HTTP/2.0 Szkic 4.

Prace nad protokoäem HTTP 2.0 trwajñ, co oznacza, Ĕe szczegóäowe instrukcje, jak kodowaè bity w kaĔdej ramce, jakie bödñ nazwy poszczególnych pól i podobne niskopoziomowe szczegóäy, mogñ siö zmieniè. Jednak mimo tego, Ĕe instrukcje „jak” bödñ siö zmieniaè, podstawowe cele projektowe i techniczne, którym poĈwiöcimy wiökszñ czöĈè naszego omówienia, zostaäy uzgodnione i sñ znane.

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.

Rysunek 12.1. Warstwa ramkowania binarnego w protokole HTTP 2.0

Termin „warstwa” okreĈla nowy mechanizm wprowadzany pomiödzy interfejsem gniazda a interfejsem API wyĔszego poziomu udostöpnianym naszej aplikacji. 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. Cele projektowe i techniczne

Kup książkę

_ 209

Poleć książkę


W rezultacie zarówno klient, jak i serwer, aby mogli siö wzajemnie rozumieè, muszñ stosowaè nowy mechanizm kodowania binarnego. Klient uĔywajñcy protokoäu HTTP 1.x nie zrozumie serwera uĔywajñcego tylko protokoäu 2.0, i odwrotnie. Na szczöĈcie nasza aplikacja pozostanie w bäogiej nieĈwiadomoĈci istnienia tych wszystkich zmian, poniewaĔ to klient i serwer wykonajñ za nas caäe niezbödne ramkowanie. Protokóä HTTPS jest kolejnym doskonaäym przykäadem zastosowania ramkowania binarnego — wszystkie komunikaty HTTP sñ kodowane i dekodowane w sposób niewidoczny dla nas (patrz podrozdziaä „Protokóä TLS rekordu” w rozdziale 4.), dziöki czemu moĔliwa jest bezpieczna komunikacja miödzy klientem a serwerem bez koniecznoĈci wprowadzania jakichkolwiek modyfikacji w aplikacji. Protokóä HTTP 2.0 dziaäa w podobny sposób.

Strumienie, komunikaty i ramki Wprowadzenie nowego mechanizmu ramkowania binarnego zmienia sposób wymiany danych (patrz rysunek 12.2) miödzy klientem a serwerem. Aby opisaè ten proces, musimy wprowadziè kilka nowych terminów charakterystycznych dla protokoäu HTTP 2.0:

Rysunek 12.2. Strumienie, komunikaty i ramki w protokole HTTP 2.0

Strumieþ Dwukierunkowy przepäyw bajtów w ramach nawiñzanego poäñczenia. Komunikat Peäna sekwencja ramek tworzñcych logiczny komunikat. 210

_

Rozdziaĥ 12. Protokóĥ HTTP 2.0

Kup książkę

Poleć książkę


Ramka Najmniejsza jednostka danych w protokole HTTP 2.0, zawierajñca nagäówek identyfikujñcy przynajmniej strumieþ, do którego ramka naleĔy. Caäa komunikacja w protokole HTTP 2.0 odbywa siö w ramach poäñczenia, które moĔe zawieraè dowolnñ liczbö dwukierunkowych strumieni. Z kolei strumienie przesyäajñ komunikaty skäadajñce siö z jednej ramki lub kilku ramek, które mogñ byè wymieszane. Ramki sñ nastöpnie skäadane w komunikaty na podstawie identyfikatora strumienia zawartego w nagäówku. Wszystkie ramki w protokole HTTP 2.0 stosujñ kodowanie binarne, a dane nagäówka sñ kompresowane. PowyĔszy rysunek ilustruje zaleĔnoĈè pomiödzy strumieniami, komunikatami i ramkami, ale bez kodowania podczas przesyäania ich przez äñcze — te szczegóäy sñ opisane w podrozdziale „Krótkie wprowadzenie do ramkowania binarnego”, dalej w tym rozdziale.

W tych kilku zwiözäych zdaniach jest upakowanych mnóstwo informacji. Przejrzyjmy je jeszcze raz. ZnajomoĈè terminologii strumieni, komunikatów i ramek stanowi podstawö zrozumienia protokoäu HTTP 2.0: x Caäa komunikacja odbywa siö w ramach jednego poäñczenia TCP. x Strumieþ jest to wirtualny kanaä wewnñtrz poäñczenia, przenoszñcy komunikaty w obu

kierunkach. KaĔdy strumieþ posiada unikatowy identyfikator (1, 2, … N). x Komunikat jest logicznym komunikatem HTTP, takim jak Ĕñdanie lub odpowiedĒ, skäa-

dajñcym siö z jednej ramki lub wielu ramek.

x Ramka jest najmniejszñ jednostkñ komunikacyjnñ, zawierajñcñ okreĈlone informacje, np.

nagäówek HTTP, dane itp. Krótko mówiñc, protokóä HTTP 2.0 dzieli komunikacjö na poszczególne maäe ramki tworzñce komunikaty w ramach strumieni. Z kolei kilka strumieni moĔe przesyäaè równolegle komunikaty w ramach jednego poäñczenia TCP.

Multipleksacja Ŝédaħ i odpowiedzi Aby klient uĔywajñcy protokoäu HTTP 1.x mógä zwiökszyè wydajnoĈè, wysyäajñc równolegle kilka Ĕñdaþ, musiaä uĔyè kilku poäñczeþ TCP — patrz podrozdziaä „UĔycie wielu poäñczeþ TCP” w rozdziale 11. Takie dziaäanie jest bezpoĈredniñ konsekwencjñ modelu transmisji danych w protokole HTTP 1.x, w którym tylko jedna odpowiedĒ mogäa byè przesyäana w danej chwili (kolejkowanie odpowiedzi) w danym poäñczeniu. Co gorsza, ten sposób powodowaä blokowanie poczñtku kolejki i nieefektywne wykorzystanie poäñczenia TCP. 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. Rysunek 12.3 przedstawia kilka strumieni przesyäanych w ramach jednego poäñczenia. Klient wysyäa do serwera ramkö DATA (strumieþ 5), a w tym czasie serwer wysyäa do klienta przemieszanñ sekwencjö ramek w strumieniach 1 i 3. W rezultacie równolegle przesyäane sñ trzy Ĕñdania i odpowiedzi!

Cele projektowe i techniczne

Kup książkę

_

Poleć książkę

211


Rysunek 12.3. Multipleksacja Ĕñdaþ i odpowiedzi we wspóädzielonym poäñczeniu w protokole HTTP 2.0

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: x mieszanie wielu równolegäych Ĕñdaþ bez ich wzajemnego blokowania, x mieszanie wielu równolegäych odpowiedzi bez ich wzajemnego blokowania, x uĔycie jednego poäñczenia do równolegäego przesyäania wielu Ĕñdaþ i odpowiedzi, x szybsze äadowanie stron dziöki eliminacji niepotrzebnych opóĒnieþ, x usuniöcie z kodu aplikacji niepotrzebnych napraw usterek protokoäu HTTP 1.x, x i wiele innych funkcjonalnoĈci…

Nowa warstwa ramkowania binarnego w protokole HTTP 2.0 rozwiñzuje problem blokowania poczñtku kolejki wystöpujñcy w protokole HTTP 1.1 i eliminuje koniecznoĈè stosowania wielu poäñczeþ do równolegäego przesyäania i przetwarzania Ĕñdaþ i odpowiedzi. Dziöki temu nasze aplikacje mogñ byè szybsze, prostsze i taþsze we wdroĔeniu. Multipleksacja Ĕñdaþ i odpowiedzi umoĔliwia wyeliminowanie wielu napraw usterek protokoäu HTTP 1.x, takich jak konkatenacja plików, kompozycje obrazów i rozdrobnienie domeny (patrz podrozdziaä „Optymalizacja protokoäu HTTP 1.x” w rozdziale 13.). Ponadto dziöki zmniejszeniu liczby wymaganych poäñczeþ TCP w protokole HTTP 2.0 zmniejsza siö równieĔ koszt procesorów i pamiöci zarówno po stronie klienta, jak i serwera.

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: x 0 oznacza strumieþ o najwyĔszym priorytecie, 31

x 2 –1 oznacza strumienie o niĔszych priorytetach.

Dziöki priorytetom klient i serwer mogñ stosowaè róĔne strategie przetwarzania w optymalnej kolejnoĈci poszczególnych strumieni, komunikatów i ramek. Serwer moĔe okreĈlaè priorytet przetwarzanego strumienia i kontrolowaè wykorzystanie zasobów (procesora, pamiöci, pasma), a gdy bödñ dostöpne dane odpowiedzi, okreĈlaè priorytet wysyäania waĔnych ramek do klienta. 212

_

Rozdziaĥ 12. Protokóĥ HTTP 2.0

Kup książkę

Poleć książkę


Priorytety Ŝédaħ przeglédarki i protokóĥ HTTP 2.0 Podczas wyĈwietlania strony przez przeglñdarkö nie wszystkie zasoby majñ taki sam priorytet. Sam dokument HTML ma krytyczne znaczenie podczas tworzenia obiektu DOM. Plik CSS jest wymagany do utworzenia obiektu CSSOM. Tworzenie obiektów DOM i CSSOM moĔe byè blokowane przez zasoby JavaScript (patrz ramka „Obiekty DOM, CSSOM i JavaScript” w rozdziale 10.). Natomiast pozostaäe zasoby, takie jak obrazy, sñ czösto pobierane z niĔszym priorytetem. Aby skróciè czas äadowania strony, wszystkie nowoczesne przeglñdarki nadajñ priorytety Ĕñdaniom na podstawie rodzaju zasobu, jego poäoĔenia na stronie, a nawet priorytetu wyuczonego podczas ostatniego otwarcia. JeĔeli na przykäad podczas poprzedniego otwarcia strona byäa blokowana przez jakiĈ zasób, to w przyszäoĈci moĔe byè mu przypisany wyĔszy priorytet. W protokole HTTP 1.x przeglñdarka miaäa ograniczone moĔliwoĈci ustanawiania priorytetów danych. Protokóä nie obsäugiwaä multipleksacji i nie sposób byäo przekazaè serwerowi priorytetu Ĕñdania. Zamiast tego stosowane byäy jednoczesne poäñczenia, które umoĔliwiaäy ograniczone zrównoleglenie transmisji do szeĈciu Ĕñdaþ na serwer. W rezultacie Ĕñdania czekaäy na dostöpne poäñczenie w kolejce po stronie klienta, co wprowadzaäo niepotrzebne opóĒnienie sieciowe. Teoretycznie kolejkowane Ĕñdaþ HTTP, opisane w rozdziale 11., byäo próbñ czöĈciowego rozwiñzania tego problemu, ale w praktyce nie zostaäo zastosowane. Protokóä HTTP 2.0 naprawia wszystkie te niedoskonaäoĈci. Przeglñdarka moĔe wysyäaè Ĕñdanie kaĔdego zasobu natychmiast po jego wykryciu, okreĈlaè priorytet kaĔdego strumienia i pozwoliè serwerowi na okreĈlenie optymalnej strategii wysäania odpowiedzi. W ten sposób wyeliminowane jest niepotrzebne opóĒnienie zwiñzane z kolejkowaniem Ĕñdaþ i moĔliwe jest osiñgniöcie najefektywniejszego wykorzystania kaĔdego poäñczenia.

Protokóä HTTP 2.0 nie okreĈla Ĕadnego konkretnego algorytmu obsäugi priorytetów, oferuje jedynie mechanizm wymiany priorytetowych danych pomiödzy klientem a serwerem. Zatem priorytety sñ mi, a strategia ich obsäugi moĔe byè róĔna, w zaleĔnoĈci od implementacji protokoäu po stronie klienta i serwera. Klient powinien dostarczaè prawidäowe informacje o priorytetach danych, a serwer powinien dostosowaè ich przetwarzanie i dostarczanie zgodnie ze wskazanymi priorytetami strumieni. Nie masz wpäywu na wiarygodnoĈè priorytetów nadawanych przez klienta, moĔesz jednak mieè wpäyw na serwer. Dlatego starannie wybieraj serwer obsäugujñcy protokóä HTTP 2.0! Dla zobrazowania tego zagadnienia rozwaĔmy nastöpujñce pytania: x Co siö stanie, jeĔeli serwer zlekcewaĔy wszystkie informacje o priorytetach? x Czy wszystkie strumienie o wysokim priorytecie muszñ mieè pierwszeþstwo? x Czy wystñpiñ przypadki, w których strumienie o róĔnych priorytetach bödñ musiaäy byè

wymieszane? JeĔeli serwer zlekcewaĔy informacje o priorytetach, to moĔe w niezamierzony sposób spowolniè dziaäanie aplikacji, na przykäad zablokowaè wyĈwietlanie strony w przeglñdarce, wysyäajñc do niej obrazy, gdy tymczasem strona moĔe oczekiwaè na krytyczne pliki CSS i JavaScript. Z drugiej strony narzucanie ĈciĈle okreĈlonych priorytetów równieĔ moĔe prowadziè do nieoptymalnych scenariuszy, na przykäad ponownego zablokowania poczñtku kolejki, gdy jedno däugotrwaäe Ĕñdanie niepotrzebnie wstrzyma wysyäanie innych zasobów.

Cele projektowe i techniczne

Kup książkę

_

Poleć książkę

213


Ramki o róĔnych priorytetach mogñ i powinny byè mieszane na serwerze. Tam, gdzie to moĔliwe, strumienie o wysokim priorytecie powinny mieè pierwszeþstwo, zarówno w kwestii kolejnoĈci przetwarzania, jak i przydzielania pasma transmisyjnego pomiödzy klientem a serwerem. Niemniej jednak, aby jak najlepiej wykorzystaè poäñczenie, wymagane jest zróĔnicowanie priorytetów.

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. Na podstawie pomiarów w laboratorium dziöki zastosowaniu mniejszej liczby poäñczeþ od klienta stwierdziliĈmy zdecydowane zmniejszenie opóĒnieþ. Caäkowita liczba pakietów przesyäanych za pomocñ protokoäu HTTP 2.0 zostaäa zmniejszona aĔ o 40% w stosunku do poprzednich wersji protokoäu. Obsäuga przez serwer duĔej liczby poäñczeþ równieĔ zaczynaäa stanowiè problem ze skalowalnoĈciñ systemu, a protokóä HTTP 2.0 zmniejszyä to obciñĔenie. — HTTP/2.0 Szkic 2.

Jedno poäñczenie na serwer znacznie zmniejsza wprowadzany przez nie narzut — zarzñdzania wymaga mniejsza liczba gniazd na caäej ĈcieĔce poäñczenia, zajmowana jest mniejsza pamiöè, a poäñczenie ma wiökszñ przepäywnoĈè. Do tego dochodzi wiele innych korzyĈci we wszystkich warstwach stosu: x Spójna obsäuga priorytetów róĔnych strumieni. x Lepsza kompresja danych dziöki zastosowaniu jednego kontekstu kompresji. x Zmniejszenie spiötrzeþ ruchu w sieci dziöki mniejszej liczbie poäñczeþ TCP. x Krótszy okres wolnego startu i szybsza obsäuga spiötrzeþ ruchu i strat pakietów.

W wiökszoĈci przypadków transmisje danych w protokole sñ krótkie i gwaätowne, gdy tymczasem protokóä TCP jest zoptymalizowany pod kñtem däugotrwaäych, intensywnych przesyäów danych. Dziöki wykorzystaniu tego samego poäñczenia przez wszystkie strumienie protokóä HTTP 2.0 moĔe efektywniej wykorzystaè poäñczenie TCP.

PrzejĈcie na protokóä HTTP 2.0 nie tylko powinno zmniejszyè opóĒnienia sieciowe, ale równieĔ zwiökszyè przepäywnoĈè i zmniejszyè koszty utrzymania infrastruktury!

Sterowanie przepĥywem Multipleksacja wielu strumieni w ramach jednego poäñczenia TCP powoduje pojawienie siö rywalizacji o wspóädzielone pasmo transmisyjne. Nadanie strumieniom priorytetów pomaga okreĈliè wzglödnñ kolejnoĈè przesyäania danych, ale same priorytety nie wystarczñ do sterowania podziaäem zasobów miödzy wiele strumieni lub poäñczeþ. Aby rozwiñzaè ten problem, protokóä HTTP 2.0 oferuje prosty mechanizm sterowania przepäywem wewnñtrz strumienia i poäñczenia. 214

_

Rozdziaĥ 12. Protokóĥ HTTP 2.0

Kup książkę

Poleć książkę


Straty pakietów, ĥécza o wysokim opóŚnieniu i wydajnoļë protokoĥu HTTP 2.0 Zaraz, zaraz… WymieniliĈmy zalety stosowania jednego poäñczenia TCP na serwer, ale czy nie powoduje to jakichĈ potencjalnych problemów? Owszem, tak wäaĈnie jest. x WyeliminowaliĈmy blokowanie poczñtku kolejki na poziomie protokoäu HTTP, ale kolejka

wciñĔ jest blokowana na poziomie protokoäu TCP (patrz podrozdziaä „Blokowanie typu HOL” w rozdziale 2.). x Zgodnie z reguäñ iloczynu przepäywnoĈci i opóĒnienia przepäywnoĈè poäñczenia moĔe

byè ograniczona, jeĔeli skalowanie okna TCP bödzie wyäñczone. x JeĔeli zostanie utracony pakiet, rozmiar okna protokoäu TCP zostanie zmniejszony (patrz

podrozdziaä „Zapobieganie zatorom” w rozdziale 2.), wskutek czego zmniejszana jest przepäywnoĈè caäego poäñczenia. KaĔde zjawisko wymienione w powyĔszej liĈcie moĔe mieè niekorzystny wpäyw zarówno na przepäywnoĈè, jak i opóĒnienie poäñczenia w protokole HTTP 2.0. Jednak pomimo tych ograniczeþ eksperymenty dowodzñ, Ĕe zastosowanie pojedynczego poäñczenia jest najlepszym sposobem w strategii wdroĔenia protokoäu HTTP 2.0: Dotychczasowe testy pokazaäy, Ĕe zalety kompresji i priorytetów przewaĔajñ nad niekorzystnym efektem blokowania poczñtku kolejki (szczególnie w przypadku wystöpowania strat pakietów). — HTTP/2.0 Szkic 2.

Podobnie jak w kaĔdym procesie optymalizacyjnym, usuniöcie jednego säabego punktu w wydajnoĈci powoduje pojawienie siö innego. W przypadku protokoäu HTTP 2.0 säabym punktem jest protokóä TCP. Dlatego wäaĈnie przypomnijmy jeszcze raz, Ĕe dobrze dostrojony stos TCP na serwerze ma krytyczny wpäyw na wydajnoĈè protokoäu HTTP 2.0. WciñĔ trwajñ badania majñce na celu usuniöcie powyĔszych ograniczeþ i zwiökszenie wydajnoĈci protokoäu TCP w ogólnoĈci. Powstaäy rozszerzenia TCP Fast Open, Proportional Rate Reduction, powiökszono poczñtkowy rozmiar okna i wprowadzono inne zmiany. Trzeba przyznaè, Ĕe w ten sposób protokóä HTTP 2.0, w odróĔnieniu od poprzednich wersji, nie musi opieraè siö na protokole TCP. Zastosowanie innych protokoäów transportowych, na przykäad UDP, nie jest wykluczone. x Sterowanie przepäywem realizowane jest w poszczególnych odcinkach, a nie w caäym

poäñczeniu. x Sterowanie przepäywem opiera siö na ramkach WINDOW_UPDATE: odbiorca ogäasza, ile bajtów

moĔe odebraè ze strumienia i caäego poäñczenia. x WielkoĈè okna do sterowania przepäywem jest aktualizowana przez ramkö WINDOW_UPDATE

zawierajñcñ identyfikator strumienia i wartoĈè, o którñ okno ma byè powiökszone. x Sterowanie przepäywem ma okreĈlony kierunek. Odbiorca moĔe wybraè dowolnñ wiel-

koĈè okna, wymaganñ dla kaĔdego strumienia i caäego poäñczenia.

x Sterowanie przepäywem moĔe byè wyäñczone przez odbiorcö, zarówno dla pojedynczego

strumienia, jak i caäego poäñczenia.

Cele projektowe i techniczne

Kup książkę

_

Poleć książkę

215


Po nawiñzaniu poäñczenia w protokole HTTP 2.0 klient i serwer wymieniajñ ramki SETTINGS, okreĈlajñce wielkoĈci okien do sterowania przepäywem w obu kierunkach. Opcjonalnie kaĔda strona moĔe wyäñczyè sterowanie przepäywem w okreĈlonym strumieniu lub caäym poäñczeniu.

Czy powyĔsza lista nie przypomina Ci sterowania przepäywem w protokole TCP? Na pewno, bo caäy mechanizm jest identyczny — patrz podrozdziaä „Sterowanie przepäywem” w rozdziale 2. Jednak samo sterowanie przepäywem w protokole TCP jest niewystarczajñce, poniewaĔ nie sñ w nim rozróĔniane strumienie w ramach poäñczenia HTTP 2.0. Dlatego zostaäo wprowadzone sterowanie przepäywem na poziomie protokoäu HTTP 2.0. Standard HTTP 2.0 nie okreĈla Ĕadnego konkretnego algorytmu, zawartoĈci ani momentów wysyäania ramek WINDOW_UPDATE. Twórca oprogramowania moĔe wybraè swój wäasny algorytm odpowiedni do jego przypadku i zapewniajñcy osiñgniöcie najwiökszej wydajnoĈci. Oprócz priorytetów okreĈlajñcych wzglödnñ kolejnoĈè przesyäania danych sterowanie przepäywem moĔe kontrolowaè wielkoĈè zasobów zajmowanych przez kaĔdy strumieþ w ramach poäñczenia HTTP 2.0. Odbiorca moĔe zmniejszyè rozmiar okna dla okreĈlonego strumienia i ograniczyè prödkoĈè przesyäania danych!

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!

Rysunek 12.4. Serwer inicjuje nowe strumienie (obietnice) do przesyäania zasobów Po nawiñzaniu poäñczenia HTTP 2.0 klient i serwer wymieniajñ ramki SETTINGS, które mogñ ograniczaè maksymalnñ liczbö równolegäych strumieni w obu kierunkach. W rezultacie klient moĔe ograniczyè liczbö wypychanych strumieni lub, ustawiajñc jñ na zero, caäkowicie wyäñczyè wypychanie zasobów.

Dlaczego taki mechanizm jest potrzebny? Typowa aplikacja WWW skäada siö z dziesiñtków zasobów, a wszystkie sñ wykrywane przez klienta w wyniku analizy dokumentu dostarczo-

216

_

Rozdziaĥ 12. Protokóĥ HTTP 2.0

Kup książkę

Poleć książkę


nego przez serwer. Dlaczego wiöc nie wyeliminowaè dodatkowego opóĒnienia i nie zleciè serwerowi wysäania od razu dodatkowych zasobów do klienta? Serwer juĔ wie, jakich zasobów potrzebuje klient. Na tym polega ich wypychanie. W praktyce, jeĔeli pliki CSS, JavaScript lub inne sñ osadzone za pomocñ identyfikatorów URI (patrz podrozdziaä „Osadzanie zasobów” w rozdziale 11.), ma miejsce wäaĈnie wypychanie zasobów! 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: x Wypchniöte zasoby mogñ byè zapisane w pamiöci podröcznej klienta. x Wypchniöte zasoby mogñ byè odrzucone przez klienta. x Wypchniöte zasoby mogñ byè wielokrotnie wykorzystane na róĔnych stronach. x Wypchniöte zasoby mogñ mieè priorytety nadane przez serwer.

Wszystkie wypchniöte zasoby podlegajñ zasadzie tego samego Ēródäa. Dlatego serwer nie moĔe wypchnñè do klienta dowolnej treĈci z innego serwera. Serwer musi byè upowaĔniony do wypychania danej treĈci.

W rezultacie mechanizm wypychania zasobów eliminuje w wiökszoĈci przypadków koniecznoĈè osadzania zasobów, które jest stosowane w protokole HTTP 1.x. Jedyny uzasadniony przypadek bezpoĈredniego osadzania zasobów ma miejsce wówczas, gdy jest wymagany tylko przez jednñ stronö i nie wprowadza duĔego narzutu zwiñzanego z kodowaniem (patrz podrozdziaä „Osadzanie zasobów” w rozdziale 11.). W kaĔdym innym przypadku Twoja aplikacja powinna wykorzystywaè wypychanie zasobów!

Ramka PUSH_PROMISE Wszystkie wypychane strumienie sñ inicjowane za pomocñ ramki PUSH_PROMISE (obietnica wypchniöcia zasobu), która sygnalizuje zamiar wypchniöcia przez serwer opisanego w niej zasobu oprócz odpowiedzi na oryginalne Ĕñdanie klienta. Ramki PUSH_PROMISE zawierajñ tylko nagäówki HTTP obiecywanego zasobu. Klient po otrzymaniu ramki PUSH_PROMISE ma moĔliwoĈè odrzucenia strumienia (np. gdy zasób znajduje siö juĔ w pamiöci podröcznej), co stanowi istotne udoskonalenie w stosunku do wersji HTTP 1.x. Osadzanie zasobów, bödñce popularnñ metodñ „optymalizacji” w protokole HTTP 1.x, jest równoznaczne z ich „wciskaniem” — klient nie moĔe ich odrzuciè, jak równieĔ nie moĔe umieszczaè ich osobno w pamiöci podröcznej. Na koniec kilka ograniczeþ funkcjonalnoĈci wypychania zasobów. Po pierwsze, serwer musi stosowaè mechanizm Ĕñdanie-odpowiedĒ i wypychaè zasoby tylko w odpowiedzi na Ĕñdanie klienta. Serwer nie moĔe sam zainicjowaè wypychanego strumienia. Po drugie, 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ñè.

Implementacja wypychania zasobów w protokole HTTP 2.0 Wypychanie zasobów otwiera wiele nowych moĔliwoĈci optymalizacji transmisji danych w aplikacjach. W jaki sposób jednak serwer okreĈla zasoby, które mogñ lub muszñ byè wysäane? Cele projektowe i techniczne

Kup książkę

_

Poleć książkę

217


Podobnie jak w przypadku priorytetów, standard HTTP 2.0 nie okreĈla Ĕadnego konkretnego algorytmu i decyzjö pozostawia twórcom oprogramowania. Istnieje zatem wiele moĔliwych strategii, z których kaĔda moĔe byè dostosowana do danej aplikacji lub serwera: x Aplikacja w swoim kodzie moĔe jawnie zainicjowaè wypychanie zasobów. Ten sposób

wymaga Ĉcisäej wspóäpracy z serwerem obsäugujñcym protokóä HTTP 2.0, ale zapewnia programiĈcie peänñ kontrolö nad procesem. x Aplikacja moĔe zasygnalizowaè serwerowi w dodatkowym nagäówku HTTP, które zaso-

by powinny zostaè wypchniöte. W ten sposób aplikacja jest oddzielona od interfejsu API serwera HTTP 2.0. Na przykäad moduä mod_spdy serwera Apache sprawdza nagäówek X-Associated-Content zawierajñcy listö zasobów, które powinny byè wypchniöte.

x Serwer moĔe automatycznie okreĈliè powiñzane ze stronñ zasoby bez udziaäu aplikacji. MoĔe

przeanalizowaè dokument i okreĈliè zasoby do wypchniöcia albo przeanalizowaè odebrany ruch i podjñè odpowiednie decyzje, np. okreĈliè zaleĔnoĈci miödzy zasobami na podstawie nagäówka Referrer, a nastöpnie automatycznie wypchnñè krytyczne zasoby do klienta.

PowyĔsza lista strategii nie jest peäna, ale ilustruje szeroki zakres moĔliwoĈci, od wykorzystania niskopoziomowego interfejsu API po w peäni zautomatyzowanñ implementacjö. MoĔna zapytaè, czy serwer powinien za kaĔdym razem wypychaè te same zasoby, czy moĔna zaimplementowaè lepszñ strategiö. Serwer moĔe byè inteligentny i na podstawie wäasnego modelu dziaäania, ciasteczek lub innego mechanizmu próbowaè okreĈliè, które zasoby znajdujñ siö w pamiöci podröcznej, i podejmowaè odpowiednie czynnoĈci. Krótko mówiñc, wypychanie zasobów otwiera mnóstwo nowych moĔliwoĈci wprowadzania innowacji. Na koniec warto zaznaczyè, Ĕe wypychane zasoby sñ umieszczane bezpoĈrednio w pamiöci podröcznej, tak jak w przypadku Ĕñdania zainicjowanego przez klienta. Po stronie klienta nie ma Ĕadnego interfejsu API ani funkcji zwrotnych JavaScript, które informowaäyby o nadejĈciu wypchniötego zasobu. Caäy mechanizm jest niewidoczny dla aplikacji uruchomionej w przeglñdarce.

Kompresja nagĥówka Wszystkie przesyäane dane HTTP zawierajñ zestaw nagäówków opisujñcych przesyäane zasoby i ich wäaĈciwoĈci. W protokole HTTP 1.x te metadane sñ zawsze przesyäane jako zwykäy tekst i wprowadzajñ dodatkowy narzut na kaĔde Ĕñdanie wielkoĈci 500 – 800 bajtów albo kilku kilobajtów, jeĔeli wymagane sñ ciasteczka HTTP (patrz podrozdziaä „Pomiar i kontrola narzutu protokoäu” w rozdziale 11.). Aby zmniejszyè narzut i poprawiè wydajnoĈè, protokóä HTTP 2.0 kompresuje metadane w nagäówku: x Zamiast ponownego przesyäania tych samych danych w kaĔdym Ĕñdaniu i odpowiedzi pro-

tokóä HTTP 2.0 stosuje „tabele nagäówków” po stronie klienta i serwera do Ĉledzenia i przechowywania wczeĈniej przesäanych par klucz-wartoĈè. x Tabele nagäówków sñ tworzone dla caäego poäñczenia HTTP 2.0 i sñ stopniowo aktuali-

zowane zarówno po stronie klienta, jak i serwera. x KaĔda nowa para klucz-wartoĈè jest albo doäñczana do istniejñcej tabeli, albo zastöpuje

poprzedniñ parö.

218

_

Rozdziaĥ 12. Protokóĥ HTTP 2.0

Kup książkę

Poleć książkę


W rezultacie obie strony poäñczenia HTTP 2.0 znajñ wczeĈniej przesäane nagäówki i ich wartoĈci, co pozwala zakodowaè nowy zestaw nagäówków po prostu jako róĔnicö w stosunku do poprzedniego zestawu (patrz rysunek 12.5).

Rysunek 12.5. Kodowanie róĔnicowe nagäówków HTTP 2.0 Definicje pól nagäówka w protokole HTTP 2.0 pozostaäy niezmienione z kilkoma niewielkimi wyjñtkami — wszystkie klucze sñ pisane maäymi literami, a wiersz Ĕñdania jest podzielony na poszczególne pary klucz-wartoĈè :method, :scheme, :host i :path.

Kompresja w protokoĥach SPDY, CRIME i HTTP 2.0 Pierwsze wersje protokoäu SPDY do kompresji nagäówków HTTP stosowaäy metodö zlib z wäasnym säownikiem, co skutkowaäo zmniejszeniem przesyäanych danych nagäówków o 85 – 88% i znacznym skróceniem czasu äadowania strony: Na wñskim äñczu DSL z prödkoĈciñ transmisji w górö sieci równñ 375 kb/s kompresja danych, w szczególnoĈci nagäówka Ĕñdania, prowadziäa do znacznego skrócenia czasu äadowania niektórych stron (tj. tych, które wysyäaäy duĔñ liczbö Ĕñdaþ zasobów). StwierdziliĈmy skrócenie czasu äadowania strony o 45 – 1142 ms dziöki samej kompresji nagäówków. — SPDY chromium.org

Jednak latem 2012 roku zostaä opublikowany opis ataku „CRIME” wykorzystujñcego luki w algorytmie kompresji TLS i SPDY i umoĔliwiajñcego przejöcie sesji. W rezultacie zrezygnowano z algorytmu kompresji zlib i zastñpiono go nowym, opisanym wczeĈniej algorytmem wykorzystujñcym tabele indeksów, który rozwiñzywaä problem bezpieczeþstwa i w praktyce oferowaä porównywalnñ wydajnoĈè. Peäny opis algorytmu kompresji w protokole HTTP 2.0 znajduje siö pod adresem http://tools.ietf. org/html/draft-ietf-httpbis-header-compression.

Cele projektowe i techniczne

Kup książkę

_

Poleć książkę

219


W powyĔszym przykäadzie drugie Ĕñdanie wymaga przesäania jedynie nagäówka path, który róĔni siö od poprzedniego Ĕñdania. Wszystkie pozostaäe nagäówki sñ pobierane z poprzedniego zestawu. W ten sposób protokóä HTTP 2.0 zapobiega wielokrotnemu przesyäaniu tych samych danych, co znacznie zmniejsza narzut wprowadzany przez kaĔde Ĕñdanie. Powszechnie stosowane pary klucz-wartoĈè (np. user-agent, accept itp.), które rzadko zmieniajñ siö w trakcie trwania poäñczenia, wystarczy przesäaè tylko raz. W praktyce, jeĔeli w kolejnych Ĕñdaniach nagäówki nie zmieniajñ siö (np. Ĕñdane sñ te same zasoby), narzut nagäówków jest równy zero bajtów. Wszystkie nagäówki sñ automatycznie pobierane z poprzedniego Ĕñdania!

Skuteczna aktualizacja i wykrywanie protokoĥu HTTP 2.0 Przeäñczenie na protokóä HTTP 2.0 nie odbywa siö w ciñgu jednej nocy. Trzeba zaktualizowaè miliony serwerów, które bödñ stosowaè ramkowanie binarne, a miliardy klientów bödñ aktualizowaè swoje przeglñdarki i biblioteki sieciowe. Dobra wiadomoĈè jest taka, Ĕe wiökszoĈè nowoczesnych przeglñdarek zawiera skuteczny mechanizm aktualizacji, który umoĔliwia szybkie wykorzystanie protokoäu HTTP 2.0 przy minimalnej interwencji wiökszoĈci uĔytkowników. Mimo tego jednak niektórzy uĔytkownicy mogñ trwaè przy starszych przeglñdarkach, ale serwery i urzñdzenia poĈrednie muszñ zostaè zaktualizowane do protokoäu HTTP 2.0, co sprawia, Ĕe caäy proces bödzie däuĔszy i wymagajñcy duĔego nakäadu pracy i Ĉrodków. Protokóä HTTP 1.x bödzie jeszcze stosowany przez jakieĈ dziesiöè lat, wiöc wiökszoĈè serwerów i klientów bödzie musiaäa obsäugiwaè oba standardy — 1.x i 2.0. W rezultacie klient, który obsäuguje protokóä HTTP 2.0, bödzie musiaä wykryè podczas nawiñzywania poäñczenia, czy serwer i wszystkie urzñdzenia poĈrednie równieĔ obsäugujñ ten protokóä. Trzeba rozwaĔyè trzy przypadki: x inicjowanie nowego poäñczenia HTTPS za pomocñ protokoäu TLS negocjacji ALPN, x inicjowanie nowego poäñczenia HTTP z wczeĈniejszym powiadomieniem, x inicjowanie nowego poäñczenia HTTP bez wczeĈniejszego powiadomienia.

Do wykrywania i negocjowania protokoäu HTTP 2.0, bödñcego czöĈciñ zwykäego poäñczenia HTTPS, jest stosowana negocjacja ALPN (ang. Application Layer Protocol Negotiation, negocjacja protokoäu warstwy aplikacyjnej) — patrz podrozdziaäy „Procedura handshake TLS” i „Rozszerzenie ALPN” w rozdziale 4. Zmniejszenie opóĒnienia sieciowego jest krytycznym celem protokoäu HTTP 2.0 i dlatego podczas nawiñzywania poäñczenia HTTPS jest zawsze stosowana negocjacja ALPN. Nawiñzanie poäñczenia HTTP 2.0 w zwykäym nieszyfrowanym kanale wymaga nieco wiöcej pracy. PoniewaĔ zarówno protokoäy HTTP 1.0, jak i HTTP 2.0 dziaäajñ na tym samym porcie (80), wiöc z powodu braku jakiejkolwiek dodatkowej informacji o obsäudze protokoäu HTTP 2.0 przez serwer klient musi zastosowaè mechanizm HTTP Upgrade do wynegocjowania odpowiedniego protokoäu: GET /strona HTTP/1.1 Host: serwer.przyklad.com Connection: Upgrade, HTTP2-Settings Upgrade: HTTP/2.0 HTTP2-Settings: (dane SETTINGS)

220

_

Rozdziaĥ 12. Protokóĥ HTTP 2.0

Kup książkę

Poleć książkę


HTTP/1.1 200 OK Content-length: 243 Content-type: text/html (... Odpowiedě HTTP 1.1 ...)

(lub) HTTP/1.1 101 Switching Protocols Connection: Upgrade Upgrade: HTTP/2.0 (...Odpowiedě HTTP 2.0 ...)

— inicjujñce Ĕñdanie HTTP 1.1 z nagäówkiem aktualizacji do protokoäu HTTP 2.0. — kodowanie Base64 danych HTTP/2.0 SETTINGS. — serwer odmawia aktualizacji i zwraca odpowiedĒ za pomocñ protokoäu HTTP 1.1. — serwer akceptuje aktualizacjö i przeäñcza siö na nowe ramkowanie. W ten sposób w powyĔszej procedurze aktualizacji (Upgrade) serwer nieobsäugujñcy protokoäu HTTP 2.0 moĔe natychmiast po odebraniu Ĕñdania zwróciè odpowiedĒ HTTP 1.1. Ewentualnie moĔe potwierdziè aktualizacjö, zwracajñc odpowiedĒ 101 Switching Protocols w formacie HTTP 1.1, a nastöpnie natychmiast przeäñczyè siö na protokóä HTTP 2.0 i zwróciè odpowiedĒ, uĔywajñc nowego ramkowania binarnego. W obu przypadkach wprowadzana jest dodatkowa wymiana komunikatów. Aby klient i serwer mogli potwierdziè, Ĕe Ĉwiadomie wybierajñ komunikacjö HTTP 2.0, obaj muszñ równieĔ wysäaè „nagäówek poäñczenia”, bödñcy ĈciĈle okreĈlonñ przez standard sekwencjñ bajtów. Ta wymiana säuĔy jako mechanizm zapobiegajñcy „falstartowi” w przypadku klientów, serwerów i urzñdzeþ poĈrednich, które niekiedy akceptujñ aktualizacjö, nie rozumiejñc nowego protokoäu. Taka wymiana nie wprowadza dodatkowych wymian komunikatów, jedynie kilka dodatkowych bajtów na poczñtku poäñczenia.

WdroŜenie protokoĥu HTTP 2.0 z protokoĥem TLS i negocjacjé ALPN Informacja o tym, Ĕe serwer obsäuguje protokóä HTTP 2.0, nie gwarantuje, Ĕe za chwilö zostanie nawiñzane niezawodne poäñczenie. Mówiñc proĈciej, protokóä HTTP 2.0 musi byè obsäugiwany na caäej ĈcieĔce i jeĔeli któreĈ z urzñdzeþ poĈrednich nie speäni tego warunku, poäñczenie moĔe nie dojĈè do skutku. Dlatego mimo Ĕe protokóä HTTP 2.0 nie wymaga zastosowania protokoäu TLS, w praktyce jest to najlepsza metoda wdroĔenia w przypadku duĔej liczby urzñdzeþ poĈrednich (patrz ramka „Serwery proxy, urzñdzenia poĈredniczñce, TLS i nowe protokoäy w sieci WWW” w rozdziale 4.). Aby uzyskaè najlepsze efekty, kaĔde wdroĔenie powinno zaczynaè siö od protokoäu TLS z negocjacjñ ALPN, jako uzupeänienie zwykäej procedury HTTP Upgrade.

Cele projektowe i techniczne

Kup książkę

_

Poleć książkę

221


Na koniec, jeĔeli klient zechce, moĔe zapamiötaè lub pobraè informacjö o obsäudze protokoäu HTTP 2.0 przez serwer innymi sposobami, np. z rekordu DNS, w wyniku röcznej konfiguracji itp., i nie opieraè siö na procedurze Upgrade. Posiadajñc tö wiedzö, moĔe zadecydowaè juĔ na samym poczñtku o wysäaniu przez niezaszyfrowany kanaä ramek HTTP 2.0 i liczyè, Ĕe siö uda nawiñzaè poäñczenie. W najgorszym przypadku poäñczenie nie zostanie nawiñzane i klient bödzie musiaä wróciè do procedury Upgrade lub przeäñczyè siö na tunel TLS z negocjacjñ ALPN.

Krótkie wprowadzenie do ramkowania binarnego NajwaĔniejszym ze wszystkich udoskonaleþ protokoäu HTTP 2.0 jest wprowadzenie nowej warstwy binarnego ramkowania z prefiksami däugoĈci. W porównaniu ze zwykäym tekstem rozdzielanym znakami nowego wiersza ramkowanie binarne oferuje bardziej zwartñ reprezentacjö danych, które równieĔ moĔna äatwiej i skuteczniej przetwarzaè w kodzie. 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.

Rysunek 12.6. Jednolity 8-bajtowy nagäówek ramki 16

x 16-bitowy prefiks DïugoĂÊ informuje, Ĕe jedna ramka moĔe zawieraè 2 –1 bajtów danych,

tj. okoäo 64 kB, wyäñczajñc 8-bajtowy nagäówek. x 8-bitowe pole Typ okreĈla sposób interpretacji pozostaäej czöĈci ramki. x 8-bitowe pole Flagi zawiera flagi komunikatów wäaĈciwe ramce danego typu. x 1 bit jest zarezerwowany i zawsze ustawiony na 0. x 31-bitowy identyfikator jednoznacznie okreĈlajñcy strumieþ HTTP 2.0.

Niektórzy uĔytkownicy wolñ do przeglñdania ruchu HTTP 2.0 uĔywaè swojego ulubionego programu wyĈwietlajñcego dane w formacie heksagonalnym. Oprócz tego dostöpne sñ wtyczki do programu Wireshark i podobne narzödzia prezentujñce dane w bardziej zrozumiaäej dla czäowieka formie. Na przykäad w przeglñdarce Google Chrome po wpisaniu chrome://internals#spdy moĔna obejrzeè wymieniane pakiety wyĈwietlone w formacie szesnastkowym.

Znajñc nagäówek ramki HTTP 2.0, moĔemy teraz napisaè prosty program analizujñcy dowolny strumieþ bajtów HTTP 2.0 i identyfikowaè na podstawie pierwszych oĈmiu bajtów kaĔdej ramki jej typ, raportowaè informacje o flagach lub däugoĈciach. Ponadto, poniewaĔ kaĔda ramka zawiera prefiks z däugoĈciñ, analizator moĔe od razu szybko i skutecznie przeskakiwaè na poczñtek nastöpnej ramki, co stanowi duĔe usprawnienie w stosunku do protokoäu HTTP 1.1.

222

_

Rozdziaĥ 12. Protokóĥ HTTP 2.0

Kup książkę

Poleć książkę


Gdy znany jest typ ramki, pozostaäa jej czöĈè moĔe byè przeanalizowana przez program. Standard protokoäu HTTP 2.0 definiuje nastöpujñce typy ramek: DATA

UĔywana do przesyäania treĈci komunikatów HTTP.

HEADERS

UĔywana do przekazywania dodatkowych pól nagäówka w strumieniu.

PRIORITY

UĔywana do przypisywania lub zmieniania priorytetów wskazywanego zasobu.

RST_STREAM

UĔywana do sygnalizowania nietypowego zakoþczenia strumienia.

SETTINGS

UĔywana do sygnalizowania danych konfiguracyjnych dotyczñcych sposobu komunikacji dwóch urzñdzeþ po obu stronach poäñczenia.

PUSH_PROMISE

UĔywana do sygnalizowania obietnicy utworzenia strumienia i dostarczenia wskazanego zasobu.

PING

UĔywana do pomiaru czasu opóĒnienia i przeprowadzenia testu „ĔywotnoĈci” poäñczenia.

GOAWAY

UĔywana do informowania drugiej strony, aby przerwaäa tworzenie strumienia w bieĔñcym poäñczeniu.

WINDOW_UPDATE

UĔywana do implementacji sterowania przepäywem w strumieniu lub caäym poäñczeniu.

CONTINUATION

UĔywana do kontynuacji sekwencji fragmentów bloku nagäówka. Ramka GOAWAY umoĔliwia serwerowi wskazanie klientowi identyfikatora ostatnio przetwarzanego strumienia, dziöki czemu eliminowana jest seria Ĕñdaþ, a przeglñdarka moĔe inteligentnie wysäaè Ĕñdanie jeszcze raz lub przerwaè przetwarzanie bieĔñcych Ĕñdaþ. Jest to waĔna i potrzebna funkcjonalnoĈè umoĔliwiajñca realizacjö bezpiecznej multipleksacji!

ćcisäa implementacja powyĔszej terminologii ramek dotyczy w wiökszoĈci programistów tworzñcych oprogramowanie serwerów i klientów, którzy muszñ troszczyè siö o skäadniö kaĔdego przepäywu, obsäugö bäödów, przerywanie poäñczeþ i wiele innych szczegóäów. Dobra wiadomoĈè jest taka, Ĕe wszystkie te zagadnienia sñ wyczerpujñco opisane w oficjalnym standardzie. JeĔeli Ciö one interesujñ, zapoznaj siö z najnowszym szkicem specyfikacji.

Pola o staĥej i zmiennej dĥugoļci w protokole HTTP 2.0 Protokóä HTTP 2.0 wykorzystuje wyäñcznie pola o staäej däugoĈci. Narzut wprowadzany przez ramkö jest niewielki (8 bajtów nagäówka w ramce danych). Gdyby stosowane byäo kodowanie danych o zmiennej däugoĈci, wówczas oszczödnoĈci z tego tytuäu nie kompensowaäyby wiökszego stopnia skomplikowania programu analizujñcego, jak równieĔ nie miaäyby wiökszego wpäywu na wykorzystanie pasma i opóĒnienie podczas wymiany danych. Gdyby kodowanie danych o zmiennej däugoĈci zmniejszyäo narzut o 50%, to w przypadku pakietu sieciowego o däugoĈci 1400 bajtów, przesyäanego äñczem o przepäywnoĈci 1 Mb/s, umoĔliwiäoby zaoszczödzenie 4 bajtów (0,3%) i zmniejszenie opóĒnienia kaĔdej ramki o zaledwie 100 nanosekund.

Krótkie wprowadzenie do ramkowania binarnego

Kup książkę

_

Poleć książkę

223


Nawet jeĔeli warstwa ramkowania jest ukryta przed naszñ aplikacjñ, warto zrobiè krok dalej i przyjrzeè siö dwóm najczöĈciej spotykanym procedurom — inicjowania nowego strumienia i wymiany danych aplikacyjnych. Kierujñc siö intuicjñ i zgadujñc, w jaki sposób Ĕñdanie lub odpowiedĒ sñ täumaczone na poszczególne ramki, moĔemy odpowiedzieè na wiele pytaþ dotyczñcych wydajnoĈci protokoäu HTTP 2.0.

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: x 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Ĉè. x Serwer inicjuje wypychany strumieþ, wysyäajñc ramkö PUSH_PROMISE, która jest praktycz-

nie identyczna z ramkñ HEADERS, z tym jednym wyjñtkiem, Ĕe zawiera dodatkowy „identyfikator obiecanego strumienia”, a nie jego priorytet.

Rysunek 12.7. Ramka HEADERS z opcjonalnym priorytetem

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. PoniewaĔ metadane i dane aplikacyjne sñ dostarczane osobno, oznacza to, Ĕe zarówno klient, jak i serwer mogñ nadawaè im róĔne priorytety, na przykäad „ruch sterujñcy” moĔe byè przesyäany z wyĔszym priorytetem, a sterowanie przepäywem moĔe dotyczyè tylko ramek typu DATA.

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. 224 _

Rozdziaĥ 12. Protokóĥ HTTP 2.0

Kup książkę

Poleć książkę


Rysunek 12.8. Ramka typu DATA

Dane nie sñ dodatkowo kodowane ani kompresowane. Na aplikacjö lub serwer spada wybór mechanizmu kodowania, np. uĔycia formatu zwykäego tekstu, kompresji gzip, kompresji obrazów lub wideo. Nic wiöcej nie moĔna powiedzieè na temat ramki DATA! Caäa ramka skäada siö z jednolitego 8-bajtowego nagäówka i nastöpujñcych po nim danych HTTP. Z technicznego punktu widzenia pole DïugoĂÊ w ramce DATA umoĔliwia przesäanie do 216–1 (65 535) bajtów danych. Jednak aby zmniejszyè blokowanie poczñtku kolejki, standard HTTP 2.0 wymaga, aby däugoĈè ramki nie przekroczyäa 214–1 (16 383). Komunikaty, które przekraczajñ ten limit, muszñ byè podzielone na kilka ramek DATA.

Analiza przepĥywu ramek DATA w protokole HTTP 2.0 WyposaĔeni w podstawowe informacje na temat róĔnych typów ramek moĔemy ponownie przyjrzeè siö diagramowi (patrz rysunek 12.9), który widzieliĈmy wczeĈniej w podrozdziale „Multipleksacja Ĕñdaþ i odpowiedzi”, i przeanalizowaè przepäyw danych.

Rysunek 12.9. Multipleksacja Ĕñdaþ i odpowiedzi we wspóädzielonym poäñczeniu HTTP 2.0 x Sñ trzy aktywne strumienie o numerach 1, 3 i 5. x Wszystkie strumienie majñ nieparzyste identyfikatory, poniewaĔ zostaäy zainicjowane

przez klienta. x W tej wymianie danych nie sñ stosowane strumienie zainicjowane przez serwer. x Serwer wysyäa kilka ramek DATA w strumieniu nr 1 säuĔñcym do przesyäania odpowiedzi

aplikacji na Ĕñdanie klienta. Oznacza to równieĔ, Ĕe wczeĈniej zostaäa przesäana ramka HEADERS. x Serwer wymieszaä ramki HEADERS i DATA ze strumienia 3 z ramkami DATA ze strumienia 1 —

multipleksacja odpowiedzi w akcji! x Klient przesyäa ramkö DATA w strumieniu 5, co oznacza, Ĕe wczeĈniej zostaäa przesäana

ramka HEADERS.

Krótkie wprowadzenie do ramkowania binarnego

Kup książkę

_

Poleć książkę

225


Krótko mówiñc, przedstawione wyĔej poäñczenie multipleksuje trzy równolegäe strumienie na róĔnych etapach przetwarzania. KolejnoĈè ramek okreĈla serwer; nie musimy siö troszczyè o typ i zawartoĈè ramek w kaĔdym strumieniu. Strumieþ 1 moĔe przesyäaè wiele danych lub sygnaä wideo, ale nie bödzie blokowaä innych strumieni wewnñtrz wspóädzielonego poäñczenia!

226

_

Rozdziaĥ 12. Protokóĥ HTTP 2.0

Kup książkę

Poleć książkę


Skorowidz

1G, 108 2G, 108 3G, 108, 109–113 3GPP, 109, 111, 112 3GPP2, 110, 112 4G, 108, 113–118, 134

B

A ACK, 31 adres IP, 132 AIMD, 41 algorytm addytywnego zwiökszania i multiplikatywnego zmniejszania, 41 MAC, 61 Nagle’a, 147 proporcjonalnej redukcji prödkoĈci dla poäñczeþ TCP, 41, 46 ALOHAnet, 97 ALPN, 64–66 aplikacje strumieniowe, 152 WWW, 168, 170–172 architektura poäñczeþ wielostronnych, 339, 340 sieci LTE, 129–133 ARO, 145 ArrayBuffer, 256 atak prowadzñcy do wyczerpania zasobów, 197 automat skoþczony RRC dla standardów HSPA i HSPA+, 125–127 dla standardu EV-DO (CDMA), 127 dla standardu LTE, 123–125

BDP, 41–43 bezczynnoĈè, 123, 126, 127 bezpieczeþstwo w przeglñdarce internetowej, 248 bezstanowe wznowienie, 68, 77, 78 biblioteka SimpleWebRTC, 320 bilet sesji, 68 Blob, 256, 257, 280 blok, 328 blokowanie HOL w protokole TCP, 43–45 poczñtku kolejki, 194 brama sygnalizacyjna, 309 bramka NAT, 51–55 PGW, 132 SGW, 133 bufferbloat, 21 buforowanie sesji, 68, 77, 78

C CDMA, 111 CDN, 23, 77 certyfikat gäównego urzödu certyfikacji, 70 poĈredni, 70 strony, 70 certyfikaty wycofanie, 71, 72 ciasteczka, 233 ciñgäy odbiór, 124 congestion collapse, 32

345

Kup książkę

Poleć książkę


content delivery network, 23 CORS, 253–256 CRL, 71–72 cwnd, 35, 40, 42 czas äadowania strony, 168 reakcji aplikacji www, 171 czöstotliwoĈci, 89–92

D DataChannel, 331–337 datagram, 49, 50 dekodowanie danych binarnych za pomocñ JavaScript, 280 däugi przerywany odbiór, 124 DNS, 49 Document, 256 dokument hipertekstowy, 168 DoS, 197 dostrajanie okna TCP, 34, 46 drganie, 44 DRX, 125 DTLS, 60, 321–323

E EDGE, 109 emulacja protokoäu WebSocket, 278 EPC, 131–133 Ethernet, 97–99

F FIFO, 192

G generacje sieci komórkowych, 108 Gmail, 203 Google Chrome, 247 Google PageSpeed Optimization Libraries, 238 Google Search, 185 GPRS, 109 GSM, 108, 109

346 _

H HetNet, 139–141 HSPA, 112 HSPA+, 115–117 HSTS, 82 HTTP, 159–166 HTTP 0.9, 159, 160 HTTP 1.0, 160–162 HTTP 1.1, 162–164, 187–204 pomiar i kontrola narzutu protokoäu, 199, 200 podtrzymywanie poäñczeþ, 189–192 HTTP 2.0, 164–166, 205–226 HTTPS, 62

I IANA, 52 ICE, 57, 311–313, 315–316 identyfikatory sesji, 67 IMT-Advanced, 113 inicjowanie sesji WebRTC, 317–320 Ĕñdania, 135, 136 integralnoĈè danych, 60 interfejs API, 249, 250 DataChannel API, 305, 332 EventSource API, 269–271 RTCPeerConnection API, 304–306 WebSocket API, 278, 279 Internet Protocol Suite, 29 IP, 29, 52 a UDP, 50 ISDN User Part, 307 ISUP, 307

J Jingle, 307 JSON, 256

K kanaä losowego dostöpu, 97 kategorie sprzötu uĔytkownika, 118–120

Skorowidz

Kup książkę

Poleć książkę


klucz publiczny, 64 symetryczny, 64 szyfrujñcy, 64 kodek Opus, 302 VP8, 302 kodowanie base64, 204 kolejkowanie na poziomie aplikacji, 201 Ĕñdaþ HTTP, 192–195 komenda ss, 47 traceroute, 24 tracert, 24 komponent MME, 133 kompozycja, 200, 201 kompresja danych, 231, 232 nagäówka w protokole HTTP 2.0, 218–220 TLS, 79, 80 komunikacja 2.0 z protokoäem TLS i bez niego, 240 sieciowa przeglñdarek, 245–250 WebRTC, 297–343 komunikat, 284, 328 DATA_CHANNEL_OPEN, 334 w protokole HTTP 2.0, 210, 211 konkatenacja, 200, 201 kontrola przeciñĔenia, 32–40 przepäywu, 33 koszt obliczeniowy, 74 krótki przerywany odbiór, 124

L LAN, 88 lista uniewaĔnionych certyfikatów, 71, 72 LTE, 114, 117, 129–133 LTE-Advanced, 114, 117 luki transmisyjne, 42

Ĥ äaþcuch certyfikatów, 80, 81 zaufania, 69–71

M MAC, 61 MAN, 88 maskowanie danych, 285 MediaStream, 297 metoda getUserMedia(), 301 metody optymalizacji aplikacji, 229–234 miödzydomenowe wspóädzielenie zasobów, 253–256 modulacja, 94 monitorowanie postöpu pobierania i wysyäania danych za pomocñ XHR, 258–260 multipleksacja Ĕñdaþ i odpowiedzi we wspóädzielonym poäñczeniu w protokole HTTP 2.0, 212, 225 multipleksowanie ramek w protokole WebSocket, 285–287 z podziaäem däugoĈci fali, 24

N nagäówki WebSocket, 287 narzut komunikatów w WebSocket, 291 NAT, 52–54 Navigation Timing, 180 nawiñzanie poäñczenia peer-to-peer, 306–320 negocjacja subprotokoäu w WebSocket, 282, 283 Upgrade w protokole HTTP, 286–289 niebuforowane pobranie pierwotne, 77 NPN, 66

O obiekt MediaStream, 300 OCSP, 72, 81, 82 odbieranie danych tekstowych i binarnych za pomocñ WebSocket, 279, 280 oddychanie komórek, 93 odpytywanie w protokole XHR, 262–264 däugotrwaäe odpytywanie, 264, 265 odröbna negocjacja kanaäu, 334 okno odbioru rwnd, 33 okno przeciñĔenia cwnd, 35, 40

Skorowidz

Kup książkę

_

Poleć książkę

347


opóĒnienia, 19–24 dla pojedynczego Ĕñdania HTTP, 149 kolejkowania, 21, 291 päaszczyzny sterowania, 136 päaszczyzny uĔytkownika, 136 propagacji, 21 przetwarzania, 21 rutowania internetowego, 136 sieci rdzeniowej, 136 sieciowe, 177 sygnaäu w próĔni i w Ĉwiatäowodzie, 22 transmisji, 21 zmniejszanie, 27 optymalizacja aplikacji, 227–242 dokumentu, 183 äadowania zasobów w przeglñdarce, 234 protokoäu HTTP 1.x, 234 protokoäu HTTP 2.0, 235–237 przeglñdarki, 182 sieci komórkowych, 143–155 sieci Wi-Fi, 100–102 spekulatywna, 183 TCP, 45–48 TLS, 74–82 UDP, 57 w przypadku dwóch protokoäów HTTP 1.x, jak i HTTP 2.0, 237, 238 wydajnoĈci interfejsu uĔytkownika, 175 wydajnoĈci sieci, 19 osadzanie zasobów, 203 oszczödzanie baterii, 144 a aktualizacje w tle, 148

P PageSpeed, 238 pakiet, 49 PAN, 88 peer-to-peer, 306–320 PLT, 168 pobieranie danych za pomocñ XHR, 256, 257 pliku poprzez istniejñce poäñczenie TCP, 39 pliku poprzez nowe poäñczenie TCP, 38 pojemnoĈè kanaäu, 89 poäñczenie peer-to-peer, 306–320 348 _

pomiar wydajnoĈci, 179–182 powolny start, 34–40 prödkoĈè Ĉwiatäa, 22 priorytety Ĕñdaþ a protokóä HTTP 2.0, 212–214 problem säyszalnoĈci, 93 procedura handshake TLS, 62–64 produkt opóĒnienia i przepustowoĈci, 41–43 protokóä ALOHAnet, 97 DataChannel, 331–337 DTLS, 60, 321–323 HSTS, 82 HTTP, 159–166 HTTP 1.1, 187–204 HTTP 2.0, 205–226 ICE, 57, 311–313, 315–316 IP, 29, 52 a UDP, 50 NPN, 66 OCSP, 72, 81, 82 RRC, 120–122 a optymalizacja sieci komórkowych, 150 SCTP, 326–330 SDP, 309–311 Server-Sent Events, 249, 250, 269–276 Session Description Protocol, 309–311 SLS, 60 SPDY, 206, 208, 219 SRTCP, 323–326 SRTP, 323–326 SSL, 59 strumienia zdarzeþ, 271–274 STUN, 55–57 TCP, 29–48 TLS, 59–84 TURN, 56, 57 UDP, 49–58 WebSocket, 249, 250, 277–295 XMLHttpRequest, 249–267 zerowy, PatrzUDP proxy, 61 PRR, 41 przeglñdarka internetowa, 245–250 przepäyw danych przychodzñcych, 137, 138 pakietów w sieci komórkowej, 134–138

Skorowidz

Kup książkę

Poleć książkę


przepustowoĈè, 19, 25, 26 sieci bezprzewodowej, 95 przesyäanie danych aplikacyjnych za pomocñ protokoäu SCTP, 326–330 mediów w protokoäach SRTP i SRTCP, 323–326 przetwarzanie informacji w przeglñdarce, 169 przypisane zasoby radiowe, 124 PSOL, 238 pula poäñczeþ, 247

R ramka, 284 HEADERS, 224 PUSH_PROMISE, 217 typu DATA, 225 w protokole HTTP 2.0, 211, 223 ramkowanie binarne, 209, 222–225 RAN, 130, 131 restartowanie powolnego startu, 37, 38, 46 röcznie okreĈlone certyfikaty, 70 RFC 1323, 34 2246, 60 2616, 199 791, 29 793, 29 rozdöcie bufora, 21 rozdrobnienie domeny, 197–199 rozdzielanie obciñĔenia i obsäugi poäñczeþ TLS, 242 rozmiar rekordu TLS, 78, 79 rozszerzenie ALPN, 64–66 SNI, 66 TCP Fast Open, 47 TFO, 31 WMM, 100 RRC, 120–122 a optymalizacja sieci komórkowych, 150 RTCDataChannel, 297 RTCPeerConnection, 297 RUM, 180 rwnd, 33, 42

S SCTP, 326–330 SDP, 309–311 Server-Sent Events, 249, 250, 269–276 serwer HTTP 2.0, 240 Session Initiation Protocol, 307 Shannon Claude E., 89 sieè ARPANET, 32 bezprzewodowa, informacje ogólne, 87–95 heterogeniczna, 139–141 komórkowa, 107–142 lokalna LAN, 88 miejska MAN, 88 osobista PAN, 88 rdzeniowa, 131–133 rozlegäa WAN, 88 Wi-Fi, 97–105 siäa sygnaäu, 92, 93 SIP, 307 skojarzenie, 327 slow-start, 34–40 SNI, 66 SPDY, 206, 208, 219 SRTCP, 323–326 SRTP, 323–326 SSE, PatrzServer-Sent Events SSL, 59, 60 SSR, 37, 38 ssthresh, 40 stan DCH, 126 FACH, 126 poäñczenia RRC, 123 standardy sieci komórkowych opracowane przez grupy projektowe 3GPP i 3GPP2, 110 Wi-Fi, 99 sterowanie przepäywem, 33, 34 przepäywem w protokole HTTP 2.0, 214–216 stos protokoäów WebRTC, 304 sieciowy przeglñdarki, 247 Skorowidz

Kup książkę

_ 349

Poleć książkę


strona WWW, 168 strumieniowanie audio, wideo i danych w WebRTC, 338, 339 danych za pomocñ XHR, 260–262 SSE za pomocñ protokoäu TLS, 275 ze zmiennñ przepäywnoĈciñ, 104 Ĕñdaþ i odpowiedzi w WebSocket, 290, 291 strumieþ, 327 w protokole HTTP 2.0, 210 STUN, 55–57 superwözeä, 340 sygnaä, 92, 93 SYN, 31 SYN ACK, 31 szczytowa wydajnoĈè widmowa, 108 szerokopasmowoĈè, 113 szerokoĈè pasma, 89–92 szyfrowanie, 60

Ļ Ĉwiatäowód, 24

T TCP, 29–48 uĔycie wielu poäñczeþ TCP, 195–197 TCP Fast Open, 31 TCP/IP, 29, 30 testy syntetyczne, 179 Text, 256 three-way handshake, 30–32 TLS, 59–84 TLS handshake, 62–64 Traceroute, 24 translacja protokoäu 1.x na 2.0 i z powrotem, 239, 240 transmisja seryjna, 153 sieciowa w czasie rzeczywistym, 302–306 Trickle ICE, 314 TURN, 56, 57 typy sieci bezprzewodowych, 88

350

_

U UDP, 49–58 optymalizacja, 57 UMTS, 109, 111 urzñd certyfikacji, 70 usäugi WebRTC do przetwarzania sygnaäu audio i wideo, 299 UTF-8, 273 utrata pakietów, 45 w sieciach Wi-Fi, 102 uwierzytelnianie, 60, 69–71

W WAN, 88 warstwa ramkowania binarnego w protokole HTTP 2.0, 209 w WebSocket, 284, 285 wczeĈniejsze zakoþczenia poäñczeþ klienta, 75–77 wdroĔenie protokoäu WebSocket, 293, 294 web performance optimization, 19 WebP, 232 WebPageTest, 172 WebRTC, 297–343 WebSocket, 249, 250, 277–295 Wi-Fi, 97–105 Wi-Fi Alliance, 97 wodospad zasobów, 172–176 WPO, 19 wstöpne nawiñzywanie poäñczeþ TCP, 183 pobieranie i ustalanie priorytetów zasobów, 183 rozwiñzywanie nazw DNS, 183 wyĈwietlenie strony, 183 wycofanie certyfikatu, 71, 72 wydajnoĈè sieci 3G, 4G, 141, 142 sieci bezprzewodowej, 95 sieci Wi-Fi, 100–102, 141, 142 wypychanie zasobów w protokole HTTP 2.0, 216–218

Skorowidz

Kup książkę

Poleć książkę


wysyäanie danych tekstowych i binarnych za pomocñ WebSocket, 281, 282 danych za pomocñ XHR, 257, 258 wznowienie sesji TLS, 66–68

X XHR, Patrzprotokóä XMLHttpRequest XMLHttpRequest, 249, 250, 251–267

Z

zapobieganie zatorom, 40, 41 zarezerwowane zakresy adresów IP, 52 zarzñdzanie gniazdami komunikacyjnymi, 246 zasilanie w sieciach 3G, 4G oraz Wi-Fi, 122 zdarzenia postöpu realizacji Ĕñdania XHR, 259 zmniejszanie opóĒnieþ, 27

ř Ēródäo, 247, 253

zakresy czöstotliwoĈci, 89–92 zapamiötywanie zasobów po stronie klienta, 230, 231 zapaĈè przeciñĔeniowa, 32, 34

Skorowidz

Kup książkę

_

Poleć książkę

351


O autorze Ilya Grigorik jest inĔynierem wydajnoĈciowym i doradcñ programistów w Google, gdzie pracuje nad przyspieszeniem sieci WWW, tworzñc i stosujñc najlepsze praktyki wydajnoĈciowe w firmie Google i nie tylko.

Kolofon Ptak na okäadce to bäotniak maskareþski (Circus macrosceles). Pierwotnie zostaä odkryty na Komorach i Madagaskarze. Jednak z powodu wielu zagroĔeþ, w tym utraty i degradacji siedlisk, jego populacja siö zmniejsza. Jest on okazem rzadszym, niĔ pierwotnie sñdzono. Wystöpuje doĈè rzadko na szerokim obszarze, a caäkowita populacja jest szacowana na 250 – 500 dorosäych osobników. Bäotniak jest zwiñzany z wilgotnymi obszarami Madagaskaru, a jego ulubionymi rejonami polowaþ sñ przede wszystkim bogate w roĈlinnoĈè sñsiedztwa jezior, bagna, podmokäe obszary przybrzeĔne i pola ryĔowe. Bäotniak poluje na maäe bezkrögowce i owady, a takĔe maäe ptaki, wöĔe, jaszczurki, gryzonie i kurczöta. Jego apetyt na kurczöta (stanowiñce tylko 1% zdobyczy) jest powodem töpienia tego gatunku przez lokalnñ ludnoĈè. W porze suchej — pod koniec sierpnia i we wrzeĈniu — bäotniak zaczyna okres godowy. Zanim rozpocznie siö pora deszczowa, koþczy siö okres wylögania (ok. 32 – 34 dni) i pierzenia pisklñt (42 – 45 dni). Jednak wspóäczynnik reprodukcji bäotniaka pozostaje wciñĔ niski, Ĉrednio 0,9 mäodego osobnika na parö przystöpujñcñ do lögu, a sukces gniazdowy wynosi trzy czwarte. Tak niski sukces gniazdowy — spowodowany czöĈciowo wybieraniem jaj i niszczeniem gniazd przez lokalnñ ludnoĈè — moĔe równieĔ byè zwiñzany z systematycznym i powszechnym zwyczajem wypalania obszarów trawiastych i bagien na potrzeby tworzenia nowych pastwisk i eksploatacji terenów, co czösto koliduje z sezonem lögowym tego gatunku. Jego populacja zmniejsza siö wraz z nasileniem konfliktu. Bäotniak potrzebuje spokojnej i dziewiczej sawanny, a w wielu obszarach Madagaskaru nasila siö dziaäalnoĈè czäowieka zwiñzana z zagospodarowywaniem nowych terenów. Akcje majñce na celu ochronö bäotniaka obejmujñ prowadzenie badaþ potwierdzajñcych wielkoĈè jego caäkowitej populacji, analizö dynamiki jej rozwoju, uzyskanie dokäadniejszych informacji na temat sukcesu gniazdowego, ograniczenie wypalania najwaĔniejszych obszarów, szczególnie w okresie lögowym bäotniaka, oraz okreĈlanie obszarów chronionych w kluczowych miejscach zakäadania przez niego gniazd. Rysunek na okäadce pochodzi z atlasu Histoire Naturelle. Ornithologie i zostaä wykonany przez Roberta Bénarda.

Kup książkę

Poleć książkę


Wydajne aplikacje internetowe. Przewodnik  
Read more
Read more
Similar to
Popular now
Just for you