Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00451 008299 10497469 na godz. na dobę w sumie
Wydajne aplikacje internetowe. Przewodnik - książka
Wydajne aplikacje internetowe. Przewodnik - książka
Autor: Liczba stron: 352
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-246-8894-4 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> webmasterstwo >> inne
Porównaj ceny (książka, ebook, audiobook).

Buduj wydajne aplikacje internetowe!

Aplikacje internetowe systematycznie wypierają swoje klasyczne odpowiedniki. Edytory tekstu, programy graficzne czy systemy CRM w wersji online nikogo już nie zaskakują. Coraz bardziej skomplikowane narzędzia dostępne za pośrednictwem przeglądarki internetowej wymagają od deweloperów znakomitej znajomości protokołów HTTP, XHR, WebSocket i nie tylko. Dzięki tej wiedzy są oni w stanie tworzyć wydajne aplikacje, które spełnią oczekiwania użytkowników.

Ta książka to najlepsze źródło informacji poświęcone protokołom internetowym. Przygotowana przez inżyniera Google’a, odpowiedzialnego za wydajność, zawiera szereg cennych informacji, które pozwolą Ci ulepszyć Twoje własne aplikacje. W trakcie lektury dowiesz się, jak osiągnąć optymalną wydajność protokołów TCP, UDP i TLS oraz jak wykorzystać możliwości sieci mobilnych 3G/4G. W kolejnych rozdziałach zaznajomisz się z historią protokołu HTTP, poznasz jego mankamenty oraz sposoby rozwiązywania problemów. Zorientujesz się też w nowościach, jakie ma wprowadzić HTTP w wersji 2.0. W końcu odkryjesz, co mogą Ci zaoferować WebSocket oraz WebRTC, a dodatkowo poznasz skuteczne techniki strumieniowania danych w sieci Internet. Książka ta jest obowiązkową lekturą dla każdego programisty tworzącego aplikacje internetowe!

Dzięki tej książce:

Poznaj niuanse pozwalające na zbudowanie szybkiej aplikacji internetowej!

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

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(cid:316)ci Przedmowa ...................................................................................................................11 Wst(cid:253)p ........................................................................................................................... 13 Cz(cid:253)(cid:316)(cid:235) I. Sieci ..................................................................................................... 17 1. Podstawowe informacje na temat opó(cid:346)nie(cid:295) i przepustowo(cid:316)ci ................................ 19 19 20 22 23 24 25 26 Pr(cid:246)dko(cid:264)(cid:232) jest cech(cid:241) Ró(cid:276)ne sk(cid:228)adniki opó(cid:274)nie(cid:254) Pr(cid:246)dko(cid:264)(cid:232) (cid:264)wiat(cid:228)a i opó(cid:274)nienie propagacji Opó(cid:274)nienia ostatniego kilometra Przepustowo(cid:264)(cid:232) w sieciach rdzeniowych Przepustowo(cid:264)(cid:232) na brzegach sieci Zapewnianie wysokich przepustowo(cid:264)ci i niskich opó(cid:274)nie(cid:254) Procedura three-way handshake Zapobieganie zatorom i kontrola przeci(cid:241)(cid:276)enia Sterowanie przep(cid:228)ywem Powolny start Zapobieganie zatorom 2. Budowanie bloków TCP ..............................................................................................29 30 32 33 34 40 41 43 45 46 47 47 Produkt opó(cid:274)nienia i przepustowo(cid:264)ci Blokowanie typu HOL Optymalizacja TCP Konfiguracja serwera dostrajaj(cid:241)cego Dostrajanie zachowa(cid:254) aplikacji Lista porad dotycz(cid:241)cych wydajno(cid:264)ci 3 Kup książkęPoleć książkę Us(cid:228)ugi protoko(cid:228)u zerowego UDP i bramki NAT 3. Budowanie bloków UDP ..............................................................................................49 50 51 53 53 55 57 Limity czasu stanu po(cid:228)(cid:241)czenia Techniki przechodzenia przez bramki NAT STUN, TURN oraz ICE Optymalizacje dla protoko(cid:228)u UDP (cid:227)a(cid:254)cuch zaufania i urz(cid:246)dy certyfikacji Wycofanie certyfikatu Lista uniewa(cid:276)nionych certyfikatów Protokó(cid:228) OCSP Protokó(cid:228) TLS rekordu Optymalizacja TLS Wznowienie sesji TLS Identyfikatory sesji Bilety sesji Rozszerzenie ALPN Rozszerzenie Server Name Indication (SNI) Szyfrowanie, uwierzytelnianie oraz integralno(cid:264)(cid:232) danych Procedura handshake TLS 4. Protokó(cid:293) TLS .................................................................................................................59 60 62 64 66 66 67 68 69 71 71 72 73 74 74 75 77 78 79 80 81 82 82 83 Koszty obliczeniowe Wcze(cid:264)niejsze zako(cid:254)czenie Buforowanie sesji i bezstanowe wznowienie Rozmiar rekordu TLS Kompresja TLS D(cid:228)ugo(cid:264)(cid:232) (cid:228)a(cid:254)cucha certyfikatów Zszywanie protoko(cid:228)u OCSP Protokó(cid:228) HSTS Lista porad dotycz(cid:241)cych wydajno(cid:264)ci Testowanie i weryfikacja Cz(cid:253)(cid:316)(cid:235) II. Wydajno(cid:316)(cid:235) sieci bezprzewodowych ................................................ 85 5. Wprowadzenie do sieci bezprzewodowych ..............................................................87 87 88 Powszechny dost(cid:246)p Typy sieci bezprzewodowych 4 (cid:95) Spis tre(cid:316)ci Kup książkęPoleć książkę Podstawowe czynniki wp(cid:228)ywaj(cid:241)ce na wydajno(cid:264)(cid:232) sieci bezprzewodowych Szeroko(cid:264)(cid:232) pasma Si(cid:228)a sygna(cid:228)u Modulacja Mierzenie wydajno(cid:264)ci bezprzewodowej w rzeczywistym (cid:264)wiecie 89 89 92 94 94 Od Ethernetu do bezprzewodowej sieci LAN Standardy i cechy Wi-Fi Pomiar i optymalizacja wydajno(cid:264)ci Wi-Fi 6. Wi-Fi .............................................................................................................................97 97 99 100 102 102 103 103 104 Wykorzystanie niemierzalnej przepustowo(cid:264)ci Dostosowanie si(cid:246) do zmiennej przepustowo(cid:264)ci Dostosowanie si(cid:246) do zmiennych opó(cid:274)nie(cid:254) Utrata pakietów w sieciach Wi-Fi Optymalizacja sieci Wi-Fi Krótka historia sieci G Pierwsze us(cid:228)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 (cid:264)wiatowy lider w przysposobieniu standardu 4G Budowanie wielogeneracyjnej przysz(cid:228)o(cid:264)ci 7. Sieci komórkowe ....................................................................................................... 107 107 108 109 111 113 114 115 116 118 118 120 122 123 125 127 128 129 130 131 134 Wymagania dotycz(cid:241)ce zasilania w sieciach 3G, 4G oraz Wi-Fi Automat sko(cid:254)czony RRC dla standardu LTE Automat sko(cid:254)czony RRC dla standardów HSPA i HSPA+ (UMTS) Automat sko(cid:254)czony RRC dla standardu EV-DO (CDMA) Nieefektywno(cid:264)(cid:232) transferów okresowych Sie(cid:232) radiowa (RAN) Sie(cid:232) rdzeniowa Pojemno(cid:264)(cid:232) i opó(cid:274)nienie systemów dosy(cid:228)owych Docelowa architektura operatora komórkowego Funkcje i mo(cid:276)liwo(cid:264)ci urz(cid:241)dze(cid:254) Kategorie sprz(cid:246)tu u(cid:276)ytkownika Protokó(cid:228) RRC Spis tre(cid:316)ci (cid:95) 5 Kup książkęPoleć książkę Przep(cid:228)yw pakietów w sieci komórkowej Inicjowanie (cid:276)(cid:241)dania Przep(cid:228)yw danych przychodz(cid:241)cych Sieci heterogeniczne (HetNet) Wydajno(cid:264)(cid:232) sieci 3G, 4G oraz Wi-Fi w rzeczywistym (cid:264)wiecie 134 135 137 139 141 Oszcz(cid:246)dzanie baterii Wyeliminowanie okresowych i nieefektywnych transferów danych 8. Optymalizacja sieci komórkowych ........................................................................... 143 144 146 148 149 150 150 Uwzgl(cid:246)dnianie zmian stanów RRC Oddzielenie interakcji u(cid:276)ytkownika od komunikacji sieciowej Eliminowanie zb(cid:246)dnych po(cid:228)(cid:241)cze(cid:254) keepalive w aplikacjach Przewidywanie poziomu opó(cid:274)nienia sieciowego Projektowanie przy uwzgl(cid:246)dnieniu zmiennej dost(cid:246)pno(cid:264)ci do interfejsu sieciowego Transmisja seryjna i powrót do stanu bezczynno(cid:264)ci Przerzucanie obci(cid:241)(cid:276)enia na sieci Wi-Fi Stosuj najlepsze praktyki dla protoko(cid:228)u i aplikacji 151 153 154 154 Cz(cid:253)(cid:316)(cid:235) III. HTTP ................................................................................................157 9. Krótka historia protoko(cid:293)u HTTP ................................................................................ 159 159 160 162 164 HTTP 0.9 — protokó(cid:228) dla jednego po(cid:228)(cid:241)czenia HTTP 1.0 — gwa(cid:228)towny rozwój i specyfikacja RFC Protokó(cid:228) HTTP 1.1 — standard internetu HTTP 2.0 — zwi(cid:246)kszenie wydajno(cid:264)ci transmisji danych Hipertekst, strony i aplikacje WWW Anatomia nowoczesnej aplikacji WWW Filary wydajno(cid:264)ci — przetwarzanie, wy(cid:264)wietlanie, transmisja danych Szybko(cid:264)(cid:232), wydajno(cid:264)(cid:232) i wra(cid:276)enia u(cid:276)ytkownika Analiza wodospadu zasobów 10. Wprowadzenie do wydajno(cid:316)ci aplikacji WWW ....................................................... 167 167 170 171 172 176 177 177 179 182 Szersze pasmo nie ma (wi(cid:246)kszego) znaczenia Opó(cid:274)nienie sieciowe, w(cid:241)skie gard(cid:228)o w wydajno(cid:264)ci Syntetyczny i rzeczywisty pomiar wydajno(cid:264)ci Optymalizacja przegl(cid:241)darki 11. Protokó(cid:293) HTTP 1.X ...................................................................................................... 187 189 192 Korzy(cid:264)ci z podtrzymywania po(cid:228)(cid:241)cze(cid:254) Kolejkowanie (cid:276)(cid:241)da(cid:254) HTTP 6 (cid:95) Spis tre(cid:316)ci Kup książkęPoleć książkę U(cid:276)ycie wielu po(cid:228)(cid:241)cze(cid:254) TCP Rozdrobnienie domeny Pomiar i kontrola narzutu protoko(cid:228)u Konkatenacja i kompozycja zasobów Osadzanie zasobów 195 197 199 200 203 Historia protoko(cid:228)u i jego zwi(cid:241)zek ze SPDY Droga do HTTP 2.0 Cele projektowe i techniczne 12. Protokó(cid:293) HTTP 2.0 ......................................................................................................205 206 206 208 209 210 211 212 214 214 216 218 220 222 224 224 225 Warstwa ramkowania binarnego Strumienie, komunikaty i ramki Multipleksacja (cid:276)(cid:241)da(cid:254) i odpowiedzi Priorytety (cid:276)(cid:241)da(cid:254) Jedno po(cid:228)(cid:241)czenie na serwer Sterowanie przep(cid:228)ywem Wypychanie zasobów Kompresja nag(cid:228)ówka Skuteczna aktualizacja i wykrywanie protoko(cid:228)u HTTP 2.0 Inicjowanie nowego strumienia Przesy(cid:228)anie danych aplikacyjnych Analiza przep(cid:228)ywu ramek DATA w protokole HTTP 2.0 Krótkie wprowadzenie do ramkowania binarnego Zawsze aktualne najlepsze praktyki wydajno(cid:264)ciowe Zapami(cid:246)tywanie zasobów po stronie klienta Przesy(cid:228)anie skompresowanych danych Eliminacja niepotrzebnych bajtów (cid:276)(cid:241)da(cid:254) Równoleg(cid:228)e przetwarzanie (cid:276)(cid:241)da(cid:254) i odpowiedzi 13. Optymalizacja aplikacji .............................................................................................227 229 230 231 232 233 234 235 236 237 239 240 240 241 Usuni(cid:246)cie optymalizacji 1.x Strategie optymalizacyjne w przypadku dwóch protoko(cid:228)ów Translacja protoko(cid:228)u 1.x na 2.0 i z powrotem Ocena jako(cid:264)ci i wydajno(cid:264)ci serwera Komunikacja 2.0 z protoko(cid:228)em TLS i bez niego Serwery obci(cid:241)(cid:276)enia, proxy i aplikacji Optymalizacja protoko(cid:228)u HTTP 1.x Optymalizacja protoko(cid:228)u HTTP 2.0 Spis tre(cid:316)ci (cid:95) 7 Kup książkęPoleć książkę Cz(cid:253)(cid:316)(cid:235) IV. Interfejsy API i protoko(cid:293)y przegl(cid:233)darki ........................................ 243 14. Podstawy komunikacji sieciowej przegl(cid:233)darek .......................................................245 246 248 248 249 Zarz(cid:241)dzanie po(cid:228)(cid:241)czeniami i ich optymalizacja Bezpiecze(cid:254)stwo sieciowe i izolacja aplikacji Przechowywanie zasobów i stanu klienta Interfejsy API i protoko(cid:228)y aplikacyjne Krótka historia protoko(cid:228)u XHR Mi(cid:246)dzydomenowe wspó(cid:228)dzielenie zasobów (CORS) Pobieranie danych za pomoc(cid:241) XHR Wysy(cid:228)anie danych za pomoc(cid:241) XHR Monitorowanie post(cid:246)pu pobierania i wysy(cid:228)ania danych Strumieniowanie danych za pomoc(cid:241) XHR Powiadamianie i dostarczanie danych w czasie rzeczywistym 15. Protokó(cid:293) XMLHttpRequest ........................................................................................ 251 252 253 256 257 258 260 262 262 264 266 Odpytywanie w protokole XHR D(cid:228)ugotrwa(cid:228)e odpytywanie w protokole XHR Przyk(cid:228)ady u(cid:276)ycia i wydajno(cid:264)(cid:232) protoko(cid:228)u XHR 16. Server-Sent Events (SSE) ...........................................................................................269 269 271 274 Interfejs EventSource API Protokó(cid:228) strumienia zdarze(cid:254) Zastosowanie i wydajno(cid:264)(cid:232) protoko(cid:228)u SSE Interfejs WebSocket API Schematy adresów URL w protoko(cid:228)ach WS oraz WSS Odbieranie danych tekstowych i binarnych Wysy(cid:228)anie danych tekstowych i binarnych Negocjacja subprotoko(cid:228)u 17. WebSocket ................................................................................................................. 277 278 279 279 281 282 283 284 286 286 289 290 291 291 292 293 294 Strumieniowanie (cid:276)(cid:241)da(cid:254) i odpowiedzi Narzut komunikatów Wydajno(cid:264)(cid:232) i kompresja danych W(cid:228)asne protoko(cid:228)y aplikacyjne Wdro(cid:276)enie protoko(cid:228)u WebSocket Wydajno(cid:264)ciowa lista kontrolna Protokó(cid:228) WebSocket Warstwa ramkowania binarnego Rozszerzenia protoko(cid:228)u Negocjacja Upgrade w protokole HTTP Zastosowanie i wydajno(cid:264)(cid:232) protoko(cid:228)u WebSocket 8 (cid:95) Spis tre(cid:316)ci Kup książkęPoleć książkę Pozyskiwanie strumienia audio i wideo za pomoc(cid:241) metody getUserMedia Transmisja sieciowa w czasie rzeczywistym Krótkie wprowadzenie do interfejsu RTCPeerConnection API Nawi(cid:241)zanie po(cid:228)(cid:241)czenia peer-to-peer Standardy i rozwój komunikacji WebRTC Us(cid:228)ugi audio i wideo Sygnalizacja i negocjacja sesji Protokó(cid:228) Session Description Protocol (SDP) Protokó(cid:228) Interactive Connectivity Establishment (ICE) Przyrostowe zbieranie danych (Trickle ICE) Przyrostowe zbieranie danych ICE i status po(cid:228)(cid:241)czenia Zebranie wszystkich elementów 18. Komunikacja WebRTC ...............................................................................................297 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 Konfiguracja i negocjacja po(cid:228)(cid:241)czenia Konfiguracja kolejno(cid:264)ci i gwarancji dostarczania komunikatów Cz(cid:246)(cid:264)ciowa gwarancja dostarczania a wielko(cid:264)(cid:232) pakietu Strumieniowanie audio, wideo i danych Architektury po(cid:228)(cid:241)cze(cid:254) wielostronnych Planowanie infrastruktury i pojemno(cid:264)ci Wydajno(cid:264)(cid:232) i kompresja danych Wydajno(cid:264)ciowa lista kontrolna Protokó(cid:228) Datagram Transport Layer Security Przesy(cid:228)anie mediów w protoko(cid:228)ach SRTP i SRTCP Przesy(cid:228)anie danych aplikacyjnych za pomoc(cid:241) protoko(cid:228)u SCTP Przesy(cid:228)anie mediów i danych aplikacyjnych Protokó(cid:228) DataChannel Zastosowanie i wydajno(cid:264)(cid:232) komunikacji WebRTC Skorowidz ..................................................................................................................345 Spis tre(cid:316)ci (cid:95) 9 Kup książkęPoleć książkę 10 (cid:95) Spis tre(cid:316)ci Kup książkęPoleć książkę ROZDZIA(cid:292) 12. Protokó(cid:293) HTTP 2.0 Protokó(cid:228) HTTP 2.0 sprawia, (cid:276)e nasza aplikacja jest szybsza, prostsza i bardziej spójna (to rzadkie po(cid:228)(cid:241)czenie cech). Dzi(cid:246)ki niemu mo(cid:276)na usun(cid:241)(cid:232) z aplikacji wiele tymczasowych korekt protoko(cid:228)u HTTP 1.1, poniewa(cid:276) teraz zosta(cid:228)y one wprowadzone w warstwie transportowej. Co wi(cid:246)cej, nowa wersja otwiera mnóstwo zupe(cid:228)nie nowych mo(cid:276)liwo(cid:264)ci optymalizacji aplikacji i poprawy wydajno(cid:264)ci! Podstawowym celem protoko(cid:228)u HTTP 2.0 jest zmniejszenie opó(cid:274)nie(cid:254) aplikacji poprzez udost(cid:246)p- nienie pe(cid:228)nej multipleksacji (cid:276)(cid:241)da(cid:254) i odpowiedzi, zminimalizowanie narzutu protoko(cid:228)u za pomoc(cid:241) skutecznej kompresji pól nag(cid:228)ówka HTTP, nadawanie (cid:276)(cid:241)daniom priorytetów i wypychanie zasobów. Aby zaimplementowa(cid:232) te funkcjonalno(cid:264)ci, wprowadzono wiele dodatkowych ulepsze(cid:254), takich jak sterowanie przep(cid:228)ywem, obs(cid:228)uga b(cid:228)(cid:246)dów i mechanizmy aktualizacji danych. S(cid:241) to najwa(cid:276)niejsze funkcjonalno(cid:264)ci, które powinien rozumie(cid:232) i wykorzystywa(cid:232) w swoich aplikacjach ka(cid:276)dy programista stron WWW. Wersja HTTP 2.0 w (cid:276)aden sposób nie zmienia sposobu wykorzystania protoko(cid:228)u HTTP przez aplikacj(cid:246). Wszystkie podstawowe koncepcje, takie jak metody HTTP, kody stanów, identyfi- katory URI i pola nag(cid:228)ówka, wci(cid:241)(cid:276) istniej(cid:241). Natomiast wersja HTTP 2.0 zmienia sposób forma- towania (ramkowania) danych i przesy(cid:228)ania ich mi(cid:246)dzy klientem a serwerem. Obie strony za- rz(cid:241)dzaj(cid:241) procesem komunikacji, a wszystkie jego zawi(cid:228)o(cid:264)ci s(cid:241) ukryte przed aplikacj(cid:241) w nowej warstwie ramkowania. W rezultacie wszystkie istniej(cid:241)ce aplikacje mog(cid:241) by(cid:232) stosowane bez modyfikacji. To s(cid:241) dobre wiadomo(cid:264)ci. Jednak my jeste(cid:264)my zainteresowani nie tylko samym dostarczaniem dzia(cid:228)aj(cid:241)cej aplikacji. Naszym celem jest osi(cid:241)gni(cid:246)cie jak najwy(cid:276)szej wydajno(cid:264)ci! Protokó(cid:228) HTTP 2.0 oferuje kilka nowych metod optymalizacji, które wcze(cid:264)niej nie by(cid:228)y mo(cid:276)liwe, a teraz mo(cid:276)na zastosowa(cid:232) je w naszej aplikacji. Naszym zadaniem jest jak najlepiej je wykorzysta(cid:232). Przyjrzyjmy si(cid:246) bli(cid:276)ej, co jest w (cid:264)rodku protoko(cid:228)u. Standard w trakcie tworzenia Obecnie protokó(cid:228) HTTP 2.0 jest na etapie aktywnego tworzenia. Podstawowe konstrukcje architektury, zasady dzia(cid:228)ania i nowe funkcjonalno(cid:264)ci s(cid:241) jasno okre(cid:264)lone, ale tego samego nie mo(cid:276)na powiedzie(cid:232) o konkretnych niskopoziomowych szczegó(cid:228)ach implementa- cyjnych. Z tego powodu skupimy si(cid:246) na architekturze protoko(cid:228)u i jej implementacji, a format przesy(cid:228)anych danych b(cid:246)dzie omówiony bardzo ogólnie, w stopniu wystarczaj(cid:241)- cym do zrozumienia dzia(cid:228)ania protoko(cid:228)u i wynikaj(cid:241)cych z niego konsekwencji. Aby pozna(cid:232) najnowsz(cid:241) specyfikacj(cid:246) i status standardu protoko(cid:228)u HTTP 2.0, odwied(cid:274) stron(cid:246) IETF pod adresem http://tools.ietf.org/html/draft-ietf-httpbis-http2. 205 Kup książkęPoleć książkę Historia protoko(cid:293)u i jego zwi(cid:233)zek ze SPDY SPDY jest eksperymentalnym protoko(cid:228)em opracowanym przez Google, udost(cid:246)pnionym w po(cid:228)o- wie roku 2009. Jego podstawowym celem by(cid:228)o skrócenie czasu (cid:228)adowania stron WWW i roz- wi(cid:241)zanie kilku znanych ogranicze(cid:254) wydajno(cid:264)ciowych protoko(cid:228)u HTTP 1.1. W szczególno(cid:264)ci projekt mia(cid:228) nakre(cid:264)lone nast(cid:246)puj(cid:241)ce cele: (cid:120) skrócenie czasu (cid:228)adowania strony o 50 , (cid:120) unikni(cid:246)cie konieczno(cid:264)ci zmiany zawarto(cid:264)ci stron WWW przez ich twórców, (cid:120) zminimalizowanie z(cid:228)o(cid:276)ono(cid:264)ci wdro(cid:276)enia, unikni(cid:246)cie zmian w infrastrukturze sieciowej, (cid:120) opracowanie nowego protoko(cid:228)u wspólnie ze spo(cid:228)eczno(cid:264)ci(cid:241) tworz(cid:241)c(cid:241) otwarty kod, (cid:120) zebranie rzeczywistych danych wydajno(cid:264)ciowych w celu zatwierdzenia lub odrzucenia eksperymentalnego protoko(cid:228)u. Aby osi(cid:241)gn(cid:241)(cid:232) popraw(cid:246) czasu (cid:228)adowania strony o 50 , protokó(cid:228) SPDY w za(cid:228)o(cid:276)eniu mia(cid:228) efektywniej wykorzystywa(cid:232) po(cid:228)(cid:241)czenia TCP przez wprowadzenie nowej warstwy ramkowania binarnego, umo(cid:276)liwiaj(cid:241)cej multipleksacj(cid:246) (cid:276)(cid:241)da(cid:254) i odpowiedzi, nadawanie priorytetów i minimalizacj(cid:246) lub eliminacj(cid:246) niepotrzebnego opó(cid:274)nienia sieciowego (patrz podrozdzia(cid:228) „Opó(cid:274)nienie sieciowe, w(cid:241)skie gard(cid:228)o w wydajno(cid:264)ci” w rozdziale 10.). Nied(cid:228)ugo po pierwszej zapowiedzi protoko(cid:228)u, in(cid:276)ynierowie Google, Mike Belshe i Roberto Peon, og(cid:228)osili swoje pierwsze wyniki, dokumentacj(cid:246) i kod (cid:274)ród(cid:228)owy eksperymentalnej implementa- cji nowego protoko(cid:228)u SPDY: Jak dot(cid:241)d, przetestowali(cid:264)my protokó(cid:228) SPDY jedynie w warunkach laboratoryjnych. Wyni- ki wygl(cid:241)daj(cid:241) bardzo obiecuj(cid:241)co. Podczas otwierania 25 najpopularniejszych stron WWW poprzez symulowane domowe po(cid:228)(cid:241)czenie sieciowe stwierdzili(cid:264)my znaczn(cid:241) popraw(cid:246) wydaj- no(cid:264)ci — strony (cid:228)adowa(cid:228)y si(cid:246) o 55 szybciej. — A 2x Faster Web („2 × szybsza sie(cid:232)”) Chromium Blog Przeskoczmy szybko kilka lat wprzód, do roku 2012. Nowy, eksperymentalny protokó(cid:228) jest ob- s(cid:228)ugiwany przez przegl(cid:241)darki Chrome, Firefox, Opera, a wiele du(cid:276)ych stron (np. Google, Twitter, Facebook) oferuje protokó(cid:228) SPDY kompatybilnym z nim klientom. Innymi s(cid:228)owy, okaza(cid:228)o si(cid:246), (cid:276)e protokó(cid:228) SPDY zaoferowa(cid:228) ogromne korzy(cid:264)ci wydajno(cid:264)ciowe, a wskutek jego coraz szerszego zastosowania sta(cid:228) si(cid:246) de facto standardem. W efekcie grupa HTTP Working Group (HTTP- WG), wyci(cid:241)gaj(cid:241)c wnioski z lekcji protoko(cid:228)u SPDY, opublikowa(cid:228)a na pocz(cid:241)tku roku 2012 no- wy protokó(cid:228) HTTP 2.0 i wprowadzi(cid:228)a go jako oficjalny standard. Droga do HTTP 2.0 Protokó(cid:228) SPDY by(cid:228) zal(cid:241)(cid:276)kiem protoko(cid:228)u HTTP 2.0, ale nie jest to w(cid:228)a(cid:264)ciwy protokó(cid:228) HTTP 2.0. Pierwsza specyfikacja protoko(cid:228)u HTTP 2.0 pojawi(cid:228)a si(cid:246) na pocz(cid:241)tku 2012 roku i po burzli- wych dyskusjach wewn(cid:241)trz grupy HTTPWG specyfikacja SPDY zosta(cid:228)a przyj(cid:246)ta jako punkt startowy w pracy nad nowym standardem. Od tej pory do oficjalnego standardu protoko(cid:228)u HTTP 2.0 zosta(cid:228)o wprowadzonych i b(cid:246)dzie dalej wprowadzanych wiele zmian i ulepsze(cid:254). 206 (cid:95) Rozdzia(cid:293) 12. Protokó(cid:293) HTTP 2.0 Kup książkęPoleć książkę Jednak zanim wybiegniemy za daleko, warto przejrze(cid:232) wst(cid:246)pn(cid:241) propozycj(cid:246) protoko(cid:228)u HTTP 2.0, poniewa(cid:276) uwidacznia ona zakres i najwa(cid:276)niejsze za(cid:228)o(cid:276)enia protoko(cid:228)u: Oczekuje si(cid:246), (cid:276)e protokó(cid:228) HTTP 2.0 wprowadzi nast(cid:246)puj(cid:241)ce zmiany: (cid:120) W przypadku wi(cid:246)kszo(cid:264)ci stron w znacz(cid:241)cy i wymierny sposób zostanie zmniejszone opó(cid:274)nienie postrzegane przez u(cid:276)ytkowników w porównaniu z protoko(cid:228)em HTTP 1.1 wykorzystuj(cid:241)cym TCP. (cid:120) Zostanie rozwi(cid:241)zany problem blokowania pocz(cid:241)tku kolejki w protokole HTTP. (cid:120) Do zrównoleglenia obs(cid:228)ugi (cid:276)(cid:241)da(cid:254) nie b(cid:246)dzie wymagane nawi(cid:241)zywanie wielu po(cid:228)(cid:241)cze(cid:254) z serwerem, dzi(cid:246)ki czemu w wi(cid:246)kszym stopniu b(cid:246)dzie wykorzystany protokó(cid:228) TCP, szczególnie pod k(cid:241)tem sterowania spi(cid:246)trzeniami ruchu. (cid:120) Zostanie zachowane dzia(cid:228)anie protoko(cid:228)u HTTP 1.1 zgodnie z istniej(cid:241)c(cid:241) dokumentacj(cid:241), wykorzystuj(cid:241)ce metody HTTP (ale nie tylko), kody stanów, identyfikatory URI i pola nag(cid:228)ówka tam, gdzie b(cid:246)dzie to zasadne. (cid:120) B(cid:246)dzie jasno zdefiniowana interakcja z protoko(cid:228)em HTTP 1.x, szczególnie w urz(cid:241)dze- niach po(cid:264)rednich. (cid:120) B(cid:246)d(cid:241) jasno okre(cid:264)lone miejsca umo(cid:276)liwiaj(cid:241)ce rozbudow(cid:246) protoko(cid:228)u i zasady ich w(cid:228)a- (cid:264)ciwego wykorzystania. Oczekuje si(cid:246), (cid:276)e ostateczna specyfikacja spe(cid:228)ni powy(cid:276)sze oczekiwania w przypadku ist- niej(cid:241)cych wdro(cid:276)e(cid:254) protoko(cid:228)u HTTP, dotycz(cid:241)cych szczególnie przegl(cid:241)dania internetu (za pomoc(cid:241) urz(cid:241)dze(cid:254) stacjonarnych i mobilnych), u(cid:276)ycia poza przegl(cid:241)darkami (HTTP API), udost(cid:246)pniania stron WWW (w ró(cid:276)nej skali wielko(cid:264)ci) i obs(cid:228)ugi w urz(cid:241)dzeniach po(cid:264)red- nich (serwerach proxy, zaporach, odwrotnych serwerach proxy i w sieciach CDN). Analo- gicznie bie(cid:276)(cid:241)ce i przysz(cid:228)e rozszerzenia protoko(cid:228)u HTTP/1.x (np. nag(cid:228)ówki, metody, kody stanu, dyrektywy pami(cid:246)ci podr(cid:246)cznej) b(cid:246)d(cid:241) obs(cid:228)ugiwane w nowym protokole. — Statut grupy roboczej HTTPbis HTTP 2.0 Krótko mówi(cid:241)c, protokó(cid:228) HTTP 2.0 mia(cid:228) na celu rozwi(cid:241)zanie wielu znanych ogranicze(cid:254) wy- dajno(cid:264)ciowych poprzednich standardów 1.x, jak równie(cid:276) ich rozwini(cid:246)cie, lecz nie zast(cid:241)pienie. Wykorzystanie protoko(cid:228)u HTTP w aplikacji pozosta(cid:228)o takie samo i nie zosta(cid:228)y wprowadzone (cid:276)adne zmiany do oferowanych funkcjonalno(cid:264)ci ani podstawowych koncepcji, takich jak me- tody, kody stanów, identyfikatory URI i pola nag(cid:228)ówka. Tego typu zmiany zosta(cid:228)y jawnie wykluczone. Czy w takim razie oznaczenie „2.0” jest uzasadnione? Powodem zwi(cid:246)kszenia g(cid:228)ównego numeru wersji do 2.0 jest zmiana sposobu wymiany danych mi(cid:246)dzy klientem a serwerem. Aby osi(cid:241)gn(cid:241)(cid:232) wytyczone cele wydajno(cid:264)ciowe, protokó(cid:228) HTTP 2.0 wprowadza now(cid:241) warstw(cid:246) ramkowania binarnego, która nie jest kompatybilna wstecz z po- przedni(cid:241) wersj(cid:241) 1.x. St(cid:241)d numer 2.0. O ile nie implementujesz w(cid:228)asnego serwera WWW lub nietypowego klienta i nie operu- jesz na podstawowych gniazdach TCP, to mo(cid:276)e si(cid:246) okaza(cid:232), (cid:276)e nawet nie zauwa(cid:276)ysz (cid:276)adnej z faktycznych zmian wprowadzonych przez protokó(cid:228) HTTP 2.0. Ca(cid:228)e nowe niskopoziomowe ramkowanie jest wykonywane za Ciebie przez przegl(cid:241)dark(cid:246) i serwer. Jedyn(cid:241) ró(cid:276)nic(cid:241) mo(cid:276)e by(cid:232) dost(cid:246)pno(cid:264)(cid:232) nowych i opcjonalnych funkcjonalno(cid:264)ci interfejsu API, na przyk(cid:228)ad wypychania zasobów! Droga do HTTP 2.0 (cid:95) 207 Kup książkęPoleć książkę Na koniec warto omówi(cid:232) prognozy rozwoju protoko(cid:228)u HTTP 2.0. Opracowanie nowej wersji protoko(cid:228)u realizuj(cid:241)cego ca(cid:228)(cid:241) komunikacj(cid:246) w sieci WWW jest nietrywialnym zadaniem, wymaga- j(cid:241)cym wielu starannych przemy(cid:264)le(cid:254), eksperymentów i koordynacji prac. Dlatego prognozowanie rozwoju protoko(cid:228)u HTTP 2.0 jest niebezpiecznym procederem. Protokó(cid:228) b(cid:246)dzie gotowy wte- dy, gdy b(cid:246)dzie gotowy. Oznacza to, (cid:276)e grupa HTTP-WG robi szybkie post(cid:246)py i oficjalnie wy- znaczy(cid:228)a nast(cid:246)puj(cid:241)ce etapy: (cid:120) marzec 2012 — og(cid:228)oszenie zapotrzebowania na protokó(cid:228) HTTP 2.0, (cid:120) wrzesie(cid:254) 2012 — pierwsza specyfikacja protoko(cid:228)u HTTP 2.0, (cid:120) lipiec 2013 — pierwsza specyfikacja implementacji protoko(cid:228)u 2.0, (cid:120) kwiecie(cid:254) 2014 — ostatnie prace grupy Working Group nad protoko(cid:228)em HTTP 2.0, (cid:120) listopad 2014 — przes(cid:228)anie do grupy IESG specyfikacji protoko(cid:228)u HTTP 2.0 jako propo- zycji nowego standardu. Du(cid:276)a przerwa mi(cid:246)dzy rokiem 2012 a 2014 przypad(cid:228)a na intensywne prace edycyjne i ekspery- mentalne. W zale(cid:276)no(cid:264)ci od post(cid:246)pów i opinii ze strony administratorów i (cid:264)rodowiska jako ca(cid:228)o- (cid:264)ci daty mog(cid:241) si(cid:246) zmieni(cid:232). Dobra wiadomo(cid:264)(cid:232) jest taka, (cid:276)e na koniec roku 2013 harmonogram by(cid:228) dotrzymany! Wspólna ewolucja protoko(cid:293)ów HTTP 2.0 i SPDY Grupa pracuj(cid:241)ca nad protoko(cid:228)em HTTP przyj(cid:246)(cid:228)a w lecie 2012 roku specyfikacj(cid:246) protoko(cid:228)u SPDY v2 jako punkt startowy prac nad standardem HTTP 2.0. Jednak gdy to si(cid:246) sta(cid:228)o, prace nad protoko(cid:228)em SPDY nie usta(cid:228)y. Wr(cid:246)cz przeciwnie, protokó(cid:228) SPDY równolegle ewoluowa(cid:228): (cid:120) W 2012 roku zosta(cid:228)a og(cid:228)oszona wersja SPDY v3 ze zaktualizowanym formatem ramko- wania i pierwsz(cid:241) implementacj(cid:241) sterowania przep(cid:228)ywem. (cid:120) Na prze(cid:228)omie lat 2013 i 2014 zosta(cid:228)a udost(cid:246)pniona wersja SPDY v4 ze zaktualizowanym (po- nownie) formatem ramkowania, usprawnion(cid:241) obs(cid:228)ug(cid:241) priorytetów, sterowaniem przep(cid:228)ywem i zaimplementowanym wypychaniem zasobów. Powód kontynuacji rozwoju protoko(cid:228)u SPDY jest prosty — jest to motor nap(cid:246)dowy w ekspery- mentach z nowymi funkcjonalno(cid:264)ciami i propozycjami dla protoko(cid:228)u HTTP 2.0. To, co do- brze wygl(cid:241)da na papierze, mo(cid:276)e nie dzia(cid:228)a(cid:232) w praktyce i vice versa. Protokó(cid:228) SPDY jest drog(cid:241) do testów i oceny ka(cid:276)dej propozycji przed zawarciem jej w standardzie 2.0. Ten stopniowy proces rozwoju i wspólnej ewolucji protoko(cid:228)ów SPDY i HTTP 2.0 zada(cid:228) wiele pracy programistom, ale w praktyce przyniesie równie(cid:276) wiele korzy(cid:264)ci — bardziej zwart(cid:241) i dok(cid:228)adnie przetestowan(cid:241) specyfikacj(cid:246), jak równie(cid:276) implementacj(cid:246) serwera i klienta, które tak(cid:276)e mog(cid:241) równolegle wspólnie ewoluowa(cid:232). W rzeczywisto(cid:264)ci, gdy pojawi si(cid:246) protokó(cid:228) HTTP 2.0 z oznaczeniem „gotowy”, b(cid:246)dziemy mie(cid:232) dok(cid:228)adnie przetestowane implementacje popular- nych serwerów i klientów! W tym momencie protokó(cid:228) SPDY b(cid:246)dzie móg(cid:228) przej(cid:264)(cid:232) na emery- tur(cid:246), a na (cid:264)rodku sceny pojawi si(cid:246) protokó(cid:228) HTTP 2.0. Cele projektowe i techniczne Protokó(cid:228) HTTP 1.x zosta(cid:228) zaprojektowany pod k(cid:241)tem prostoty implementacji. Protokó(cid:228) HTTP 0.9 by(cid:228) jednowierszow(cid:241) wersj(cid:241), która zapocz(cid:241)tkowa(cid:228)a rozwój sieci WWW. Protokó(cid:228) HTTP 1.0 usystematyzowa(cid:228) rozszerzenia wersji 0.9 w nieformalnym standardzie, a wersja 1.1 sta(cid:228)a si(cid:246) 208 (cid:95) Rozdzia(cid:293) 12. Protokó(cid:293) HTTP 2.0 Kup książkęPoleć książkę oficjalnym standardem IETF (patrz rozdzia(cid:228) 9.). W ten sposób protokó(cid:228) 0.9 – 1.x sta(cid:228) si(cid:246) tym, czym mia(cid:228) si(cid:246) sta(cid:232) — jednym z najbardziej rozpowszechnionych i najszerzej zaimplemento- wanych protoko(cid:228)ów aplikacyjnych w internecie. Niestety, prostota implementacji sz(cid:228)a w parze z kosztami wydajno(cid:264)ci aplikacji, co stanowi(cid:228)o luk(cid:246), któr(cid:241) w(cid:228)a(cid:264)nie protokó(cid:228) HTTP 2.0 z za(cid:228)o(cid:276)enia ma wype(cid:228)ni(cid:232): Enkapsulacja HTTP/2.0 umo(cid:276)liwia lepsze wykorzystanie zasobów sieciowych i dzi(cid:246)ki kompresji pól nag(cid:228)ówka i jednoczesnemu przesy(cid:228)aniu wielu komunikatów w ramach tego samego po(cid:228)(cid:241)czenia zmniejszenie postrzeganych przez u(cid:276)ytkowników opó(cid:274)nie(cid:254). Protokó(cid:228) wprowadza równie(cid:276) spontaniczne wypychanie zasobów z serwerów do klientów. — HTTP/2.0 Szkic 4. Prace nad protoko(cid:228)em HTTP 2.0 trwaj(cid:241), co oznacza, (cid:276)e szczegó(cid:228)owe instrukcje, jak kodowa(cid:232) bity w ka(cid:276)dej ramce, jakie b(cid:246)d(cid:241) nazwy poszczególnych pól i podobne niskopoziomowe szczegó(cid:228)y, mog(cid:241) si(cid:246) zmieni(cid:232). Jednak mimo tego, (cid:276)e instrukcje „jak” b(cid:246)d(cid:241) si(cid:246) zmienia(cid:232), podstawowe cele projektowe i techniczne, którym po(cid:264)wi(cid:246)cimy wi(cid:246)ksz(cid:241) cz(cid:246)(cid:264)(cid:232) naszego omówienia, zosta(cid:228)y uzgod- nione i s(cid:241) znane. Warstwa ramkowania binarnego Rdzeniem wszystkich udoskonale(cid:254) wydajno(cid:264)ciowych wprowadzonych w protokole HTTP 2.0 jest nowa warstwa ramkowania binarnego (patrz rysunek 12.1), która okre(cid:264)la sposób enkapsulacji i przesy(cid:228)ania komunikatów mi(cid:246)dzy klientem a serwerem. Rysunek 12.1. Warstwa ramkowania binarnego w protokole HTTP 2.0 Termin „warstwa” okre(cid:264)la nowy mechanizm wprowadzany pomi(cid:246)dzy interfejsem gniazda a in- terfejsem API wy(cid:276)szego poziomu udost(cid:246)pnianym naszej aplikacji. Elementy protoko(cid:228)u HTTP, takie jak s(cid:228)owa kluczowe, metody i nag(cid:228)ówki, pozostaj(cid:241) takie same, ale zmiana polega na sposo- bie ich kodowania podczas transmisji. W odró(cid:276)nieniu od protoko(cid:228)u HTTP 1.x, opartego na zwy- k(cid:228)ym tek(cid:264)cie podzielonym znakami nowego wiersza, w protokole HTTP 2.0 wszystkie przesy- (cid:228)ane dane s(cid:241) podzielone na mniejsze komunikaty i ramki zakodowane w formacie binarnym. Cele projektowe i techniczne (cid:95) 209 Kup książkęPoleć książkę W rezultacie zarówno klient, jak i serwer, aby mogli si(cid:246) wzajemnie rozumie(cid:232), musz(cid:241) stosowa(cid:232) nowy mechanizm kodowania binarnego. Klient u(cid:276)ywaj(cid:241)cy protoko(cid:228)u HTTP 1.x nie zrozumie serwera u(cid:276)ywaj(cid:241)cego tylko protoko(cid:228)u 2.0, i odwrotnie. Na szcz(cid:246)(cid:264)cie nasza aplikacja pozostanie w b(cid:228)ogiej nie(cid:264)wiadomo(cid:264)ci istnienia tych wszystkich zmian, poniewa(cid:276) to klient i serwer wy- konaj(cid:241) za nas ca(cid:228)e niezb(cid:246)dne ramkowanie. Protokó(cid:228) HTTPS jest kolejnym doskona(cid:228)ym przyk(cid:228)adem zastosowania ramkowania binarnego — wszystkie komunikaty HTTP s(cid:241) kodowane i dekodowane w sposób niewidoczny dla nas (patrz podrozdzia(cid:228) „Protokó(cid:228) TLS rekordu” w rozdziale 4.), dzi(cid:246)ki czemu mo(cid:276)liwa jest bezpieczna komunikacja mi(cid:246)dzy klientem a serwerem bez konieczno(cid:264)ci wprowadzania jakichkolwiek modyfikacji w aplikacji. Protokó(cid:228) HTTP 2.0 dzia(cid:228)a w podobny sposób. Strumienie, komunikaty i ramki Wprowadzenie nowego mechanizmu ramkowania binarnego zmienia sposób wymiany danych (patrz rysunek 12.2) mi(cid:246)dzy klientem a serwerem. Aby opisa(cid:232) ten proces, musimy wprowa- dzi(cid:232) kilka nowych terminów charakterystycznych dla protoko(cid:228)u HTTP 2.0: Rysunek 12.2. Strumienie, komunikaty i ramki w protokole HTTP 2.0 Strumie(cid:254) Dwukierunkowy przep(cid:228)yw bajtów w ramach nawi(cid:241)zanego po(cid:228)(cid:241)czenia. Komunikat Pe(cid:228)na sekwencja ramek tworz(cid:241)cych logiczny komunikat. 210 (cid:95) Rozdzia(cid:293) 12. Protokó(cid:293) HTTP 2.0 Kup książkęPoleć książkę Ramka Najmniejsza jednostka danych w protokole HTTP 2.0, zawieraj(cid:241)ca nag(cid:228)ówek identy- fikuj(cid:241)cy przynajmniej strumie(cid:254), do którego ramka nale(cid:276)y. Ca(cid:228)a komunikacja w protokole HTTP 2.0 odbywa si(cid:246) w ramach po(cid:228)(cid:241)czenia, które mo(cid:276)e zawiera(cid:232) dowoln(cid:241) liczb(cid:246) dwukierunkowych strumieni. Z kolei strumienie przesy(cid:228)aj(cid:241) komunikaty sk(cid:228)adaj(cid:241)ce si(cid:246) z jednej ramki lub kilku ramek, które mog(cid:241) by(cid:232) wymieszane. Ramki s(cid:241) nast(cid:246)p- nie sk(cid:228)adane w komunikaty na podstawie identyfikatora strumienia zawartego w nag(cid:228)ówku. Wszystkie ramki w protokole HTTP 2.0 stosuj(cid:241) kodowanie binarne, a dane nag(cid:228)ówka s(cid:241) kompresowane. Powy(cid:276)szy rysunek ilustruje zale(cid:276)no(cid:264)(cid:232) pomi(cid:246)dzy strumieniami, ko- munikatami i ramkami, ale bez kodowania podczas przesy(cid:228)ania ich przez (cid:228)(cid:241)cze — te szczegó(cid:228)y s(cid:241) opisane w podrozdziale „Krótkie wprowadzenie do ramkowania bi- narnego”, dalej w tym rozdziale. W tych kilku zwi(cid:246)z(cid:228)ych zdaniach jest upakowanych mnóstwo informacji. Przejrzyjmy je jesz- cze raz. Znajomo(cid:264)(cid:232) terminologii strumieni, komunikatów i ramek stanowi podstaw(cid:246) zrozu- mienia protoko(cid:228)u HTTP 2.0: (cid:120) Ca(cid:228)a komunikacja odbywa si(cid:246) w ramach jednego po(cid:228)(cid:241)czenia TCP. (cid:120) Strumie(cid:254) jest to wirtualny kana(cid:228) wewn(cid:241)trz po(cid:228)(cid:241)czenia, przenosz(cid:241)cy komunikaty w obu kierunkach. Ka(cid:276)dy strumie(cid:254) posiada unikatowy identyfikator (1, 2, … N). (cid:120) Komunikat jest logicznym komunikatem HTTP, takim jak (cid:276)(cid:241)danie lub odpowied(cid:274), sk(cid:228)a- daj(cid:241)cym si(cid:246) z jednej ramki lub wielu ramek. (cid:120) Ramka jest najmniejsz(cid:241) jednostk(cid:241) komunikacyjn(cid:241), zawieraj(cid:241)c(cid:241) okre(cid:264)lone informacje, np. nag(cid:228)ówek HTTP, dane itp. Krótko mówi(cid:241)c, protokó(cid:228) HTTP 2.0 dzieli komunikacj(cid:246) na poszczególne ma(cid:228)e ramki tworz(cid:241)ce komunikaty w ramach strumieni. Z kolei kilka strumieni mo(cid:276)e przesy(cid:228)a(cid:232) równolegle komu- nikaty w ramach jednego po(cid:228)(cid:241)czenia TCP. Multipleksacja (cid:348)(cid:233)da(cid:295) i odpowiedzi Aby klient u(cid:276)ywaj(cid:241)cy protoko(cid:228)u HTTP 1.x móg(cid:228) zwi(cid:246)kszy(cid:232) wydajno(cid:264)(cid:232), wysy(cid:228)aj(cid:241)c równolegle kilka (cid:276)(cid:241)da(cid:254), musia(cid:228) u(cid:276)y(cid:232) kilku po(cid:228)(cid:241)cze(cid:254) TCP — patrz podrozdzia(cid:228) „U(cid:276)ycie wielu po(cid:228)(cid:241)cze(cid:254) TCP” w rozdziale 11. Takie dzia(cid:228)anie jest bezpo(cid:264)redni(cid:241) konsekwencj(cid:241) modelu transmisji danych w protokole HTTP 1.x, w którym tylko jedna odpowied(cid:274) mog(cid:228)a by(cid:232) przesy(cid:228)ana w danej chwili (kolejkowanie odpowiedzi) w danym po(cid:228)(cid:241)czeniu. Co gorsza, ten sposób powodowa(cid:228) bloko- wanie pocz(cid:241)tku kolejki i nieefektywne wykorzystanie po(cid:228)(cid:241)czenia TCP. Nowa warstwa ramkowania binarnego w protokole HTTP 2.0 usuwa te ograniczenia i umo(cid:276)liwia pe(cid:228)n(cid:241) multipleksacj(cid:246) (cid:276)(cid:241)da(cid:254) i odpowiedzi, dzi(cid:246)ki czemu klient i serwer mog(cid:241) dzieli(cid:232) komuni- katy HTTP na niezale(cid:276)ne ramki (patrz rysunek 12.3), miesza(cid:232) je i ponownie sk(cid:228)ada(cid:232) po dru- giej stronie. Rysunek 12.3 przedstawia kilka strumieni przesy(cid:228)anych w ramach jednego po(cid:228)(cid:241)czenia. Klient wysy(cid:228)a do serwera ramk(cid:246) DATA (strumie(cid:254) 5), a w tym czasie serwer wysy(cid:228)a do klienta przemie- szan(cid:241) sekwencj(cid:246) ramek w strumieniach 1 i 3. W rezultacie równolegle przesy(cid:228)ane s(cid:241) trzy (cid:276)(cid:241)- dania i odpowiedzi! Cele projektowe i techniczne (cid:95) 211 Kup książkęPoleć książkę Rysunek 12.3. Multipleksacja (cid:276)(cid:241)da(cid:254) i odpowiedzi we wspó(cid:228)dzielonym po(cid:228)(cid:241)czeniu w protokole HTTP 2.0 Mo(cid:276)liwo(cid:264)(cid:232) dzielenia komunikatów HTTP na niezale(cid:276)ne ramki, mieszanie ich i sk(cid:228)adanie po dru- giej stronie to najwa(cid:276)niejsze udoskonalenie wprowadzane przez protokó(cid:228) HTTP 2.0. W rze- czywisto(cid:264)ci protokó(cid:228) oferuje wiele pochodnych korzy(cid:264)ci wydajno(cid:264)ciowych w ca(cid:228)ym stosie technologii WWW. Umo(cid:276)liwia mi(cid:246)dzy innymi: (cid:120) mieszanie wielu równoleg(cid:228)ych (cid:276)(cid:241)da(cid:254) bez ich wzajemnego blokowania, (cid:120) mieszanie wielu równoleg(cid:228)ych odpowiedzi bez ich wzajemnego blokowania, (cid:120) u(cid:276)ycie jednego po(cid:228)(cid:241)czenia do równoleg(cid:228)ego przesy(cid:228)ania wielu (cid:276)(cid:241)da(cid:254) i odpowiedzi, (cid:120) szybsze (cid:228)adowanie stron dzi(cid:246)ki eliminacji niepotrzebnych opó(cid:274)nie(cid:254), (cid:120) usuni(cid:246)cie z kodu aplikacji niepotrzebnych napraw usterek protoko(cid:228)u HTTP 1.x, (cid:120) i wiele innych funkcjonalno(cid:264)ci… Nowa warstwa ramkowania binarnego w protokole HTTP 2.0 rozwi(cid:241)zuje problem blokowa- nia pocz(cid:241)tku kolejki wyst(cid:246)puj(cid:241)cy w protokole HTTP 1.1 i eliminuje konieczno(cid:264)(cid:232) stosowania wielu po(cid:228)(cid:241)cze(cid:254) do równoleg(cid:228)ego przesy(cid:228)ania i przetwarzania (cid:276)(cid:241)da(cid:254) i odpowiedzi. Dzi(cid:246)ki te- mu nasze aplikacje mog(cid:241) by(cid:232) szybsze, prostsze i ta(cid:254)sze we wdro(cid:276)eniu. Multipleksacja (cid:276)(cid:241)da(cid:254) i odpowiedzi umo(cid:276)liwia wyeliminowanie wielu napraw usterek protoko(cid:228)u HTTP 1.x, takich jak konkatenacja plików, kompozycje obrazów i roz- drobnienie domeny (patrz podrozdzia(cid:228) „Optymalizacja protoko(cid:228)u HTTP 1.x” w roz- dziale 13.). Ponadto dzi(cid:246)ki zmniejszeniu liczby wymaganych po(cid:228)(cid:241)cze(cid:254) TCP w proto- kole HTTP 2.0 zmniejsza si(cid:246) równie(cid:276) koszt procesorów i pami(cid:246)ci zarówno po stronie klienta, jak i serwera. Priorytety (cid:348)(cid:233)da(cid:295) Po podzieleniu komunikatu HTTP na kilka osobnych ramek ich kolejno(cid:264)(cid:232) przesy(cid:228)ania mo(cid:276)e by(cid:232) zoptymalizowana i w ten sposób mo(cid:276)e by(cid:232) zwi(cid:246)kszona wydajno(cid:264)(cid:232) naszej aplikacji. Aby to osi(cid:241)gn(cid:241)(cid:232), ka(cid:276)demu strumieniowi jest przypisana 31-bitowa warto(cid:264)(cid:232) oznaczaj(cid:241)ca priorytet: (cid:120) 0 oznacza strumie(cid:254) o najwy(cid:276)szym priorytecie, (cid:120) 231–1 oznacza strumienie o ni(cid:276)szych priorytetach. Dzi(cid:246)ki priorytetom klient i serwer mog(cid:241) stosowa(cid:232) ró(cid:276)ne strategie przetwarzania w optymal- nej kolejno(cid:264)ci poszczególnych strumieni, komunikatów i ramek. Serwer mo(cid:276)e okre(cid:264)la(cid:232) prio- rytet przetwarzanego strumienia i kontrolowa(cid:232) wykorzystanie zasobów (procesora, pami(cid:246)ci, pasma), a gdy b(cid:246)d(cid:241) dost(cid:246)pne dane odpowiedzi, okre(cid:264)la(cid:232) priorytet wysy(cid:228)ania wa(cid:276)nych ramek do klienta. 212 (cid:95) Rozdzia(cid:293) 12. Protokó(cid:293) HTTP 2.0 Kup książkęPoleć książkę Priorytety (cid:348)(cid:233)da(cid:295) przegl(cid:233)darki i protokó(cid:293) HTTP 2.0 Podczas wy(cid:264)wietlania strony przez przegl(cid:241)dark(cid:246) nie wszystkie zasoby maj(cid:241) 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(cid:276)e by(cid:232) blokowane przez zasoby JavaScript (patrz ramka „Obiekty DOM, CSSOM i JavaScript” w rozdziale 10.). Natomiast pozosta(cid:228)e zasoby, takie jak obrazy, s(cid:241) cz(cid:246)sto pobierane z ni(cid:276)szym priorytetem. Aby skróci(cid:232) czas (cid:228)adowania strony, wszystkie nowoczesne przegl(cid:241)darki nadaj(cid:241) priorytety (cid:276)(cid:241)da- niom na podstawie rodzaju zasobu, jego po(cid:228)o(cid:276)enia na stronie, a nawet priorytetu wyuczone- go podczas ostatniego otwarcia. Je(cid:276)eli na przyk(cid:228)ad podczas poprzedniego otwarcia strona by(cid:228)a blokowana przez jaki(cid:264) zasób, to w przysz(cid:228)o(cid:264)ci mo(cid:276)e by(cid:232) mu przypisany wy(cid:276)szy priorytet. W protokole HTTP 1.x przegl(cid:241)darka mia(cid:228)a ograniczone mo(cid:276)liwo(cid:264)ci ustanawiania prioryte- tów danych. Protokó(cid:228) nie obs(cid:228)ugiwa(cid:228) multipleksacji i nie sposób by(cid:228)o przekaza(cid:232) serwerowi priorytetu (cid:276)(cid:241)dania. Zamiast tego stosowane by(cid:228)y jednoczesne po(cid:228)(cid:241)czenia, które umo(cid:276)liwia(cid:228)y ograniczone zrównoleglenie transmisji do sze(cid:264)ciu (cid:276)(cid:241)da(cid:254) na serwer. W rezultacie (cid:276)(cid:241)dania czeka(cid:228)y na dost(cid:246)pne po(cid:228)(cid:241)czenie w kolejce po stronie klienta, co wprowadza(cid:228)o niepotrzebne opó(cid:274)nienie sieciowe. Teoretycznie kolejkowane (cid:276)(cid:241)da(cid:254) HTTP, opisane w rozdziale 11., by(cid:228)o prób(cid:241) cz(cid:246)(cid:264)ciowego rozwi(cid:241)zania tego problemu, ale w praktyce nie zosta(cid:228)o zastosowane. Protokó(cid:228) HTTP 2.0 naprawia wszystkie te niedoskona(cid:228)o(cid:264)ci. Przegl(cid:241)darka mo(cid:276)e wysy(cid:228)a(cid:232) (cid:276)(cid:241)- danie ka(cid:276)dego zasobu natychmiast po jego wykryciu, okre(cid:264)la(cid:232) priorytet ka(cid:276)dego strumienia i pozwoli(cid:232) serwerowi na okre(cid:264)lenie optymalnej strategii wys(cid:228)ania odpowiedzi. W ten sposób wyeliminowane jest niepotrzebne opó(cid:274)nienie zwi(cid:241)zane z kolejkowaniem (cid:276)(cid:241)da(cid:254) i mo(cid:276)liwe jest osi(cid:241)gni(cid:246)cie najefektywniejszego wykorzystania ka(cid:276)dego po(cid:228)(cid:241)czenia. Protokó(cid:228) HTTP 2.0 nie okre(cid:264)la (cid:276)adnego konkretnego algorytmu obs(cid:228)ugi priorytetów, oferuje jedy- nie mechanizm wymiany priorytetowych danych pomi(cid:246)dzy klientem a serwerem. Zatem priory- tety s(cid:241) mi, a strategia ich obs(cid:228)ugi mo(cid:276)e by(cid:232) ró(cid:276)na, w zale(cid:276)no(cid:264)ci od implementacji protoko(cid:228)u po stronie klienta i serwera. Klient powinien dostarcza(cid:232) prawid(cid:228)owe informacje o prioryte- tach danych, a serwer powinien dostosowa(cid:232) ich przetwarzanie i dostarczanie zgodnie ze wskazanymi priorytetami strumieni. Nie masz wp(cid:228)ywu na wiarygodno(cid:264)(cid:232) priorytetów nadawanych przez klienta, mo(cid:276)esz jednak mie(cid:232) wp(cid:228)yw na serwer. Dlatego starannie wybieraj serwer obs(cid:228)uguj(cid:241)cy protokó(cid:228) HTTP 2.0! Dla zobrazowania tego zagadnienia rozwa(cid:276)my nast(cid:246)puj(cid:241)ce pytania: (cid:120) Co si(cid:246) stanie, je(cid:276)eli serwer zlekcewa(cid:276)y wszystkie informacje o priorytetach? (cid:120) Czy wszystkie strumienie o wysokim priorytecie musz(cid:241) mie(cid:232) pierwsze(cid:254)stwo? (cid:120) Czy wyst(cid:241)pi(cid:241) przypadki, w których strumienie o ró(cid:276)nych priorytetach b(cid:246)d(cid:241) musia(cid:228)y by(cid:232) wymieszane? Je(cid:276)eli serwer zlekcewa(cid:276)y informacje o priorytetach, to mo(cid:276)e w niezamierzony sposób spowolni(cid:232) dzia(cid:228)anie aplikacji, na przyk(cid:228)ad zablokowa(cid:232) wy(cid:264)wietlanie strony w przegl(cid:241)darce, wysy(cid:228)aj(cid:241)c do niej obrazy, gdy tymczasem strona mo(cid:276)e oczekiwa(cid:232) na krytyczne pliki CSS i JavaScript. Z drugiej strony narzucanie (cid:264)ci(cid:264)le okre(cid:264)lonych priorytetów równie(cid:276) mo(cid:276)e prowadzi(cid:232) do nieoptymal- nych scenariuszy, na przyk(cid:228)ad ponownego zablokowania pocz(cid:241)tku kolejki, gdy jedno d(cid:228)ugo- trwa(cid:228)e (cid:276)(cid:241)danie niepotrzebnie wstrzyma wysy(cid:228)anie innych zasobów. Cele projektowe i techniczne (cid:95) 213 Kup książkęPoleć książkę Ramki o ró(cid:276)nych priorytetach mog(cid:241) i powinny by(cid:232) mieszane na serwerze. Tam, gdzie to mo(cid:276)li- we, strumienie o wysokim priorytecie powinny mie(cid:232) pierwsze(cid:254)stwo, zarówno w kwestii kolejno- (cid:264)ci przetwarzania, jak i przydzielania pasma transmisyjnego pomi(cid:246)dzy klientem a serwerem. Niemniej jednak, aby jak najlepiej wykorzysta(cid:232) po(cid:228)(cid:241)czenie, wymagane jest zró(cid:276)nicowanie priorytetów. Jedno po(cid:293)(cid:233)czenie na serwer Dzi(cid:246)ki nowemu mechanizmowi ramkowania protokó(cid:228) HTTP 2.0 nie potrzebuje wielu po(cid:228)(cid:241)cze(cid:254) TCP, aby równolegle multipleksowa(cid:232) wiele strumieni. Zamiast tego ka(cid:276)dy strumie(cid:254) jest dzielony na wiele ramek, które mog(cid:241) by(cid:232) mieszane i przesy(cid:228)ane z okre(cid:264)lonymi priorytetami. W rezul- tacie wszystkie po(cid:228)(cid:241)czenia s(cid:241) trwa(cid:228)e, a pomi(cid:246)dzy klientem a serwerem jest u(cid:276)ywane tylko jedno po(cid:228)(cid:241)czenie. Na podstawie pomiarów w laboratorium dzi(cid:246)ki zastosowaniu mniejszej liczby po(cid:228)(cid:241)cze(cid:254) od klienta stwierdzili(cid:264)my zdecydowane zmniejszenie opó(cid:274)nie(cid:254). Ca(cid:228)kowita liczba pakietów przesy- (cid:228)anych za pomoc(cid:241) protoko(cid:228)u HTTP 2.0 zosta(cid:228)a zmniejszona a(cid:276) o 40 w stosunku do poprzednich wersji protoko(cid:228)u. Obs(cid:228)uga przez serwer du(cid:276)ej liczby po(cid:228)(cid:241)cze(cid:254) równie(cid:276) zaczyna(cid:228)a stanowi(cid:232) problem ze skalowalno(cid:264)ci(cid:241) systemu, a protokó(cid:228) HTTP 2.0 zmniejszy(cid:228) to obci(cid:241)(cid:276)enie. — HTTP/2.0 Szkic 2. Jedno po(cid:228)(cid:241)czenie na serwer znacznie zmniejsza wprowadzany przez nie narzut — zarz(cid:241)dzania wymaga mniejsza liczba gniazd na ca(cid:228)ej (cid:264)cie(cid:276)ce po(cid:228)(cid:241)czenia, zajmowana jest mniejsza pami(cid:246)(cid:232), a po(cid:228)(cid:241)czenie ma wi(cid:246)ksz(cid:241) przep(cid:228)ywno(cid:264)(cid:232). Do tego dochodzi wiele innych korzy(cid:264)ci we wszystkich warstwach stosu: (cid:120) Spójna obs(cid:228)uga priorytetów ró(cid:276)nych strumieni. (cid:120) Lepsza kompresja danych dzi(cid:246)ki zastosowaniu jednego kontekstu kompresji. (cid:120) Zmniejszenie spi(cid:246)trze(cid:254) ruchu w sieci dzi(cid:246)ki mniejszej liczbie po(cid:228)(cid:241)cze(cid:254) TCP. (cid:120) Krótszy okres wolnego startu i szybsza obs(cid:228)uga spi(cid:246)trze(cid:254) ruchu i strat pakietów. W wi(cid:246)kszo(cid:264)ci przypadków transmisje danych w protokole s(cid:241) krótkie i gwa(cid:228)towne, gdy tymczasem protokó(cid:228) TCP jest zoptymalizowany pod k(cid:241)tem d(cid:228)ugotrwa(cid:228)ych, inten- sywnych przesy(cid:228)ów danych. Dzi(cid:246)ki wykorzystaniu tego samego po(cid:228)(cid:241)czenia przez wszyst- kie strumienie protokó(cid:228) HTTP 2.0 mo(cid:276)e efektywniej wykorzysta(cid:232) po(cid:228)(cid:241)czenie TCP. Przej(cid:264)cie na protokó(cid:228) HTTP 2.0 nie tylko powinno zmniejszy(cid:232) opó(cid:274)nienia sieciowe, ale rów- nie(cid:276) zwi(cid:246)kszy(cid:232) przep(cid:228)ywno(cid:264)(cid:232) i zmniejszy(cid:232) koszty utrzymania infrastruktury! Sterowanie przep(cid:293)ywem Multipleksacja wielu strumieni w ramach jednego po(cid:228)(cid:241)czenia TCP powoduje pojawienie si(cid:246) rywalizacji o wspó(cid:228)dzielone pasmo transmisyjne. Nadanie strumieniom priorytetów pomaga okre(cid:264)li(cid:232) wzgl(cid:246)dn(cid:241) kolejno(cid:264)(cid:232) przesy(cid:228)ania danych, ale same priorytety nie wystarcz(cid:241) do stero- wania podzia(cid:228)em zasobów mi(cid:246)dzy wiele strumieni lub po(cid:228)(cid:241)cze(cid:254). Aby rozwi(cid:241)za(cid:232) ten problem, protokó(cid:228) HTTP 2.0 oferuje prosty mechanizm sterowania przep(cid:228)ywem wewn(cid:241)trz strumienia i po(cid:228)(cid:241)czenia. 214 (cid:95) Rozdzia(cid:293) 12. Protokó(cid:293) HTTP 2.0 Kup książkęPoleć książkę Straty pakietów, (cid:293)(cid:233)cza o wysokim opó(cid:346)nieniu i wydajno(cid:316)(cid:235) protoko(cid:293)u HTTP 2.0 Zaraz, zaraz… Wymienili(cid:264)my zalety stosowania jednego po(cid:228)(cid:241)czenia TCP na serwer, ale czy nie powoduje to jakich(cid:264) potencjalnych problemów? Owszem, tak w(cid:228)a(cid:264)nie jest. (cid:120) Wyeliminowali(cid:264)my blokowanie pocz(cid:241)tku kolejki na poziomie protoko(cid:228)u HTTP, ale kolejka wci(cid:241)(cid:276) jest blokowana na poziomie protoko(cid:228)u TCP (patrz podrozdzia(cid:228) „Blokowanie typu HOL” w rozdziale 2.). (cid:120) Zgodnie z regu(cid:228)(cid:241) iloczynu przep(cid:228)ywno(cid:264)ci i opó(cid:274)nienia przep(cid:228)ywno(cid:264)(cid:232) po(cid:228)(cid:241)czenia mo(cid:276)e by(cid:232) ograniczona, je(cid:276)eli skalowanie okna TCP b(cid:246)dzie wy(cid:228)(cid:241)czone. (cid:120) Je(cid:276)eli zostanie utracony pakiet, rozmiar okna protoko(cid:228)u TCP zostanie zmniejszony (patrz podrozdzia(cid:228) „Zapobieganie zatorom” w rozdziale 2.), wskutek czego zmniejszana jest prze- p(cid:228)ywno(cid:264)(cid:232) ca(cid:228)ego po(cid:228)(cid:241)czenia. Ka(cid:276)de zjawisko wymienione w powy(cid:276)szej li(cid:264)cie mo(cid:276)e mie(cid:232) niekorzystny wp(cid:228)yw zarówno na przep(cid:228)ywno(cid:264)(cid:232), jak i opó(cid:274)nienie po(cid:228)(cid:241)czenia w protokole HTTP 2.0. Jednak pomimo tych ogranicze(cid:254) eksperymenty dowodz(cid:241), (cid:276)e zastosowanie pojedynczego po(cid:228)(cid:241)czenia jest najlepszym sposobem w strategii wdro(cid:276)enia protoko(cid:228)u HTTP 2.0: Dotychczasowe testy pokaza(cid:228)y, (cid:276)e zalety kompresji i priorytetów przewa(cid:276)aj(cid:241) nad nieko- rzystnym efektem blokowania pocz(cid:241)tku kolejki (szczególnie w przypadku wyst(cid:246)powania strat pakietów). — HTTP/2.0 Szkic 2. Podobnie jak w ka(cid:276)dym procesie optymalizacyjnym, usuni(cid:246)cie jednego s(cid:228)abego punktu w wy- dajno(cid:264)ci powoduje pojawienie si(cid:246) innego. W przypadku protoko(cid:228)u HTTP 2.0 s(cid:228)abym punk- tem jest protokó(cid:228) TCP. Dlatego w(cid:228)a(cid:264)nie przypomnijmy jeszcze raz, (cid:276)e dobrze dostrojony stos TCP na serwerze ma krytyczny wp(cid:228)yw na wydajno(cid:264)(cid:232) protoko(cid:228)u HTTP 2.0. Wci(cid:241)(cid:276) trwaj(cid:241) badania maj(cid:241)ce na celu usuni(cid:246)cie powy(cid:276)szych ogranicze(cid:254) i zwi(cid:246)kszenie wydaj- no(cid:264)ci protoko(cid:228)u TCP w ogólno(cid:264)ci. Powsta(cid:228)y rozszerzenia TCP Fast Open, Proportional Rate Reduction, powi(cid:246)kszono pocz(cid:241)tkowy rozmiar okna i wprowadzono inne zmiany. Trzeba przy- zna(cid:232), (cid:276)e w ten sposób protokó(cid:228) HTTP 2.0, w odró(cid:276)nieniu od poprzednich wersji, nie musi opie- ra(cid:232) si(cid:246) na protokole TCP. Zastosowanie innych protoko(cid:228)ów transportowych, na przyk(cid:228)ad UDP, nie jest wykluczone. (cid:120) Sterowanie przep(cid:228)ywem realizowane jest w poszczególnych odcinkach, a nie w ca(cid:228)ym po(cid:228)(cid:241)czeniu. (cid:120) Sterowanie przep(cid:228)ywem opiera si(cid:246) na ramkach WINDOW_UPDATE: odbiorca og(cid:228)asza, ile bajtów mo(cid:276)e odebra(cid:232) ze strumienia i ca(cid:228)ego po(cid:228)(cid:241)czenia. (cid:120) Wielko(cid:264)(cid:232) okna do sterowania przep(cid:228)ywem jest aktualizowana przez ramk(cid:246) WINDOW_UPDATE zawieraj(cid:241)c(cid:241) identyfikator strumienia i warto(cid:264)(cid:232), o któr(cid:241) okno ma by(cid:232) powi(cid:246)kszone. (cid:120) Sterowanie przep(cid:228)ywem ma okre(cid:264)lony kierunek. Odbiorca mo(cid:276)e wybra(cid:232) dowoln(cid:241) wiel- ko(cid:264)(cid:232) okna, wymagan(cid:241) dla ka(cid:276)dego strumienia i ca(cid:228)ego po(cid:228)(cid:241)czenia. (cid:120) Sterowanie przep(cid:228)ywem mo(cid:276)e by(cid:232) wy(cid:228)(cid:241)czone przez odbiorc(cid:246), zarówno dla pojedynczego strumienia, jak i ca(cid:228)ego po(cid:228)(cid:241)czenia. Cele projektowe i techniczne (cid:95) 215 Kup książkęPoleć książkę Po nawi(cid:241)zaniu po(cid:228)(cid:241)czenia w protokole HTTP 2.0 klient i serwer wymieniaj(cid:241) ramki SETTINGS, okre(cid:264)laj(cid:241)ce wielko(cid:264)ci okien do sterowania przep(cid:228)ywem w obu kierunkach. Opcjonalnie ka(cid:276)da strona mo(cid:276)e wy(cid:228)(cid:241)czy(cid:232) sterowanie przep(cid:228)ywem w okre(cid:264)lonym strumieniu lub ca(cid:228)ym po(cid:228)(cid:241)czeniu. Czy powy(cid:276)sza lista nie przypomina Ci sterowania przep(cid:228)ywem w protokole TCP? Na pewno, bo ca(cid:228)y mechanizm jest identyczny — patrz podrozdzia(cid:228) „Sterowanie przep(cid:228)ywem” w rozdziale 2. Jednak samo sterowanie przep(cid:228)ywem w protokole TCP jest niewystarczaj(cid:241)ce, poniewa(cid:276) nie s(cid:241) w nim rozró(cid:276)niane strumienie w ramach po(cid:228)(cid:241)czenia HTTP 2.0. Dlatego zosta(cid:228)o wprowadzone sterowanie przep(cid:228)ywem na poziomie protoko(cid:228)u HTTP 2.0. Standard HTTP 2.0 nie okre(cid:264)la (cid:276)adnego konkretnego algorytmu, zawarto(cid:264)ci ani momentów wy- sy(cid:228)ania ramek WINDOW_UPDATE. Twórca oprogramowania mo(cid:276)e wybra(cid:232) swój w(cid:228)asny algorytm odpowiedni do jego przypadku i zapewniaj(cid:241)cy osi(cid:241)gni(cid:246)cie najwi(cid:246)kszej wydajno(cid:264)ci. Oprócz priorytetów okre(cid:264)laj(cid:241)cych wzgl(cid:246)dn(cid:241) kolejno(cid:264)(cid:232) przesy(cid:228)ania danych sterowanie przep(cid:228)ywem mo(cid:276)e kontrolowa(cid:232) wielko(cid:264)(cid:232) zasobów zajmowanych przez ka(cid:276)dy stru- mie(cid:254) w ramach po(cid:228)(cid:241)czenia HTTP 2.0. Odbiorca mo(cid:276)e zmniejszy(cid:232) rozmiar okna dla okre(cid:264)lonego strumienia i ograniczy(cid:232) pr(cid:246)dko(cid:264)(cid:232) przesy(cid:228)ania danych! Wypychanie zasobów Bardzo u(cid:276)yteczn(cid:241) now(cid:241) funkcjonalno(cid:264)ci(cid:241) protoko(cid:228)u HTTP 2.0 jest mo(cid:276)liwo(cid:264)(cid:232) wysy(cid:228)ania przez serwer wielu odpowiedzi na (cid:276)(cid:241)danie klienta. Oznacza to, (cid:276)e serwer w odpowiedzi na (cid:276)(cid:241)danie klienta mo(cid:276)e wypchn(cid:241)(cid:232) dodatkowe zasoby (patrz rysunek 12.4) bez konieczno(cid:264)ci (cid:276)(cid:241)- dania ich wprost przez klienta! Rysunek 12.4. Serwer inicjuje nowe strumienie (obietnice) do przesy(cid:228)ania zasobów Po nawi(cid:241)zaniu po(cid:228)(cid:241)czenia HTTP 2.0 klient i serwer wymieniaj(cid:241) ramki SETTINGS, któ- re mog(cid:241) ogranicza(cid:232) maksymaln(cid:241) liczb(cid:246) równoleg(cid:228)ych strumieni w obu kierunkach. W rezultacie klient mo(cid:276)e ograniczy(cid:232) liczb(cid:246) wypychanych strumieni lub, ustawiaj(cid:241)c j(cid:241) na zero, ca(cid:228)kowicie wy(cid:228)(cid:241)czy(cid:232) wypychanie zasobów. Dlaczego taki mechanizm jest potrzebny? Typowa aplikacja WWW sk(cid:228)ada si(cid:246) z dziesi(cid:241)tków zasobów, a wszystkie s(cid:241) wykrywane przez klienta w wyniku analizy dokumentu dostarczo- 216 (cid:95) Rozdzia(cid:293) 12. Protokó(cid:293) HTTP 2.0 Kup książkęPoleć książkę nego przez serwer. Dlaczego wi(cid:246)c nie wyeliminowa(cid:232) dodatkowego opó(cid:274)nienia i nie zleci(cid:232) serwerowi wys(cid:228)ania od razu dodatkowych zasobów do klienta? Serwer ju(cid:276) wie, jakich zasobów potrzebuje klient. Na tym polega ich wypychanie. W praktyce, je(cid:276)eli pliki CSS, JavaScript lub inne s(cid:241) osadzone za pomoc(cid:241) identyfikatorów URI (patrz podrozdzia(cid:228) „Osadzanie zasobów” w rozdziale 11.), ma miejsce w(cid:228)a(cid:264)nie wypychanie zasobów! R(cid:246)cznie osadzaj(cid:241)c zasoby w dokumencie, w rzeczywisto(cid:264)ci wypychamy je do klienta bez oczekiwania, a(cid:276) ich za(cid:276)(cid:241)da. Jedyna ró(cid:276)nica wprowadzana przez protokó(cid:228) HTTP 2.0 polega na przesuni(cid:246)ciu tej czynno(cid:264)ci z aplikacji do samego protoko(cid:228)u, co przynosi istotne korzy(cid:264)ci: (cid:120) Wypchni(cid:246)te zasoby mog(cid:241) by(cid:232) zapisane w pami(cid:246)ci podr(cid:246)cznej klienta. (cid:120) Wypchni(cid:246)te zasoby mog(cid:241) by(cid:232) odrzucone przez klienta. (cid:120) Wypchni(cid:246)te zasoby mog(cid:241) by(cid:232) wielokrotnie wykorzystane na ró(cid:276)nych stronach. (cid:120) Wypchni(cid:246)te zasoby mog(cid:241) mie(cid:232) priorytety nadane przez serwer. Wszystkie wypchni(cid:246)te zasoby podlegaj(cid:241) zasadzie tego samego (cid:274)ród(cid:228)a. Dlatego ser- wer nie mo(cid:276)e wypchn(cid:241)(cid:232) do klienta dowolnej tre(cid:264)ci z innego serwera. Serwer musi by(cid:232) upowa(cid:276)niony do wypychania danej tre(cid:264)ci. W rezultacie mechanizm wypychania zasobów eliminuje w wi(cid:246)kszo(cid:264)ci przypadków koniecz- no(cid:264)(cid:232) osadzania zasobów, które jest stosowane w protokole HTTP 1.x. Jedyny uzasadniony przy- padek bezpo(cid:264)redniego osadzania zasobów ma miejsce wówczas, gdy jest wymagany tylko przez jedn(cid:241) stron(cid:246) i nie wprowadza du(cid:276)ego narzutu zwi(cid:241)zanego z kodowaniem (patrz pod- rozdzia(cid:228) „Osadzanie zasobów” w rozdziale 11.). W ka(cid:276)dym innym przypadku Twoja aplika- cja powinna wykorzystywa(cid:232) wypychanie zasobów! Ramka PUSH_PROMISE Wszystkie wypychane strumienie s(cid:241) inicjowane za pomoc(cid:241) ramki PUSH_PROMISE (obietnica wypchni(cid:246)cia zasobu), która sygnalizuje zamiar wypchni(cid:246)cia przez serwer opisanego w niej zasobu oprócz odpowiedzi na oryginalne (cid:276)(cid:241)danie klienta. Ramki PUSH_PROMISE zawieraj(cid:241) tyl- ko nag(cid:228)ówki HTTP obiecywanego zasobu. Klient po otrzymaniu ramki PUSH_PROMISE ma mo(cid:276)liwo(cid:264)(cid:232) odrzucenia strumienia (np. gdy zasób znajduje si(cid:246) ju(cid:276) w pami(cid:246)ci podr(cid:246)cznej), co stanowi istotne udoskonalenie w stosunku do wersji HTTP 1.x. Osadzanie zasobów, b(cid:246)d(cid:241)ce popularn(cid:241) metod(cid:241) „optymalizacji” w protokole HTTP 1.x, jest równoznaczne z ich „wciskaniem” — klient nie mo(cid:276)e ich odrzuci(cid:232), jak rów- nie(cid:276) nie mo(cid:276)e umieszcza(cid:232) ich osobno w pami(cid:246)ci podr(cid:246)cznej. Na koniec kilka ogranicze(cid:254) funkcjonalno(cid:264)ci wypychania zasobów. Po pierwsze, serwer musi stosowa(cid:232) mechanizm (cid:276)(cid:241)danie-odpowied(cid:274) i wypycha(cid:232) zasoby tylko w odpowiedzi na (cid:276)(cid:241)da- nie klienta. Serwer nie mo(cid:276)e sam zainicjowa(cid:232) wypychanego strumienia. Po drugie, ramki PUSH_PROMISE musz(cid:241) zosta(cid:232) wys(cid:228)ane przed wys(cid:228)aniem odpowiedzi, aby unikn(cid:241)(cid:232) efektu wy- (cid:264)cigu, tj. (cid:276)(cid:241)dania przez klienta tych samych zasobów, które serwer zamierza wypchn(cid:241)(cid:232). Implementacja wypychania zasobów w protokole HTTP 2.0 Wypychanie zasobów otwiera wiele nowych mo(cid:276)liwo(cid:264)ci optymalizacji transmisji danych w aplikacjach. W jaki sposób jednak serwer okre(cid:264)la zasoby, które mog(cid:241) lub musz(cid:241) by(cid:232) wys(cid:228)ane? Cele projektowe i techniczne (cid:95) 217 Kup książkęPoleć książkę Podobnie jak w przypadku priorytetów, standard HTTP 2.0 nie okre(cid:264)la (cid:276)adnego konkretnego algorytmu i decyzj(cid:246) pozostawia twórcom oprogramowania. Istnieje zatem wiele mo(cid:276)liwych strategii, z których ka(cid:276)da mo(cid:276)e by(cid:232) dostosowana do danej aplikacji lub serwera: (cid:120)
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Wydajne aplikacje internetowe. Przewodnik
Autor:

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: