Podsumowanie roku 2013 według Google

SPDY (mod_spdy) i mod_pagespeed

Ostatnio pisałem o nowym rozszerzeniu TCP Fast Open, stworzonym przez Google w ramach inicjatywy Make the Web Faster. Teraz przedstawię dwa kolejne projekty z tego laboratorium, to protokół połączeniowy SPDY i moduł do Apache mod_pagespeed.

TCP Fast Open skraca czas otrzymania pierwszych danych po nawiązaniu sesji TCP, to spory zysk jeżeli ilość pakietów pomnożymy przez np. milion. Nie zmienia to faktu, że przeglądarka używając bezstanowego protokołu HTTP za każdym zapytaniem musi nawiązywać nowe połączenie TCP. Nie prawda? Racja, w HTTP 1.1  jest Keep-Alive. Mało tego, jest też HTTP Pipelining (opisywałem), który pozwala wysyłać wiele zapytań HTTP jednocześnie, bez czekania na odpowiedzi wcześniejszych zapytań.
Jednak HTTP Keep-Alive i HTTP Pipelining są pewnego rodzaju doróbkami do archaicznej architektury protokołu HTTP, na podstawie której buduje się nowoczesny Web. Tak właśnie powstał SPDY (od SPeeDY). Zadaniem protokołu SPDY jest rozbudować HTTP o mechanizm nawiązywania stałych sesji, a nawet pozwala ustalać priorytety dla każdego połączenia. W czym pomoże SPDY i jak można zobaczyć poniżej.





Jeżeli chcesz, aby Twój serwer Apache obsługiwał protokół SPDY wystarczy, że zainstalujesz mod_spdy i skonfigurujesz mod_ssl, ponieważ SPDY działa tylko z https. Należy również otworzyć port tcp/443. Na stronie projektu opisany jest proces instalacji, która jest bardzo prosta, jej poprawność w Debianie sprawdzimy komendą:
apache2ctl -M

Jeżeli chcesz sprawdzić, czy jakiś serwer obsługuje SPDY skorzystaj z spdycheck.org. Natomiast co do obsługi SPDY w przeglądarce, to najlepiej sprawdzić na stronie producenta. Firefox ma dodatek, który na pasku adresu wskazuje, czy obecna strona korzysta ze SPDY.

Drugi moduł mod_pagespeed również ma poprawić prędkość ładowania stron w przeglądarce, ale jego obszarem działania jest zupełnie co innego niż w SPDY. Tu chodzi o optymalizację budowy strony, tzn zdjęć, kodu i wszystkiego co da się poprawić, aby jej przetwarzanie trwało krócej. Np. w ostatniej wersji dodano optymalizację związaną z możliwością rozwijania adresów innych serwerów za pomocą treści otrzymanych przez pierwszy serwer. Zaoszczędza to czas czekania na odpowiedzi serwera DNS. Krótko mówiąc mod_magespeed, to silnik do automatycznego wprowadzania sztuczek w kodzie strony, aby te były szybciej interpretowane przez przeglądarki, ale co ja będę pisał, najlepiej samemu zobaczyć.






Instalacja jest prosta, jej poprawność można sprawdzić w ten sam sposób, jak w mod_spdy. Tu jednak trzeba troszkę poeksperymentować z dostępnymi filtrami.

Zasoby:

SPDY
http://googlecode.blogspot.com/2012/01/making-web-speedier-and-safer-with-spdy.html
http://www.chromium.org/spdy/spdy-whitepaper
http://code.google.com/p/mod-spdy/

mod_pagespeed
http://code.google.com/p/modpagespeed/
http://googledevelopers.blogspot.com/2012/12/new-modpagespeed-cache-advances.html

Tradycyjne podsumowanie roku

Jak zwykle na swoim blogu prezentuję podsumowanie mijającego roku przez Google, na które czekałem z ciekawością. Niestety, w porównaniu do dwóch poprzednich lat ten klip nie zrobił na mnie takiego wrażenia. Może to nowe podejście do Zeitgeist przez Google. Oczywiście pisząc o tym, że moje oczekiwania trochę się zawiodły to konkretnie mam na myśli podkład muzyczny. Natomiast sam cel podsumowania wydarzeń minionego roku jak zwykle ma ukryty cel, chodzi o pokazanie jak te wydarzenia były relacjonowane przez sieć.

Dostępna jest również strona Zeitgeist 2012, na której można sprawdzić co w naszym kraju było najczęściej wyszukiwane w 2012 roku.




W rym roku podsumowania dokonała również fundacja Linuksa.




Jako podsumowanie roku 2012 polecam również obejrzenie Linux Kernel Report z konferencji LinuxCon Europe 2012, która odbyła się na początku listopada. Można tam usłyszeć o większość nowinek, w które jądro Linux zostało wyposażone w mijającym roku.

TCP Fast Open - wkład Google w szybsze połączenia

W czerwcu 2012 pisałem o nowym rozszerzeniu TCP zwanym Multipath, teraz napisze o nowym mechanizmie, który pozwoli na szybsze ładowanie się stron internetowych na pewno o 5-7%, a w niektórych przypadkach nawet o 30-40%! Już pewnie zastanawiasz się o które mechanizmy chodzi, ale może trochę źle się wyraziłem. Tu nie chodzi tylko o szybkość ładowania się stron internetowych, ale o szybkość nawiązywania wszystkich połączeń w sieci przez protokół TCP/IP.

TCP/IP to duma inżynierii prawie z przed 30-tu lat, gdy protokoły te były projektowane ich twórcy nie mieli pojęcia jak będzie wyglądała sieć dziś. Mimo wszystko zostały opracowane tak dobrze, że mimo iż cała sieć zmienia się całkowicie w przeciągu każdych kolejnych 10 lat, to wciąż działa na tym samym TCP/IP.

Google ma chyba największe i najlepsze "laboratorium" do przeprowadzania optymalizacji połączeń w sieci (klient-serwer). Mało która firma ma tak dużo obciążonych serwerów i do tego własną przeglądarkę. Ten zestaw tworzy wspaniałe laboratorium, w którym Google dostrzegł problem i postanowił pracować nad jego rozwiązaniem. Tak właśnie powstał między innymi TCP Fast Open.

Tam i z powrotem

Jak zapewne wiesz, protokół TCP (RFC 793) jest protokołem stanowym, dlatego musi nawiązać sesję przed przesłaniem danych. To nawiązanie jest zwane 3-way handshake (3WHS). Zanim serwer prześle treści do przeglądarki, klient musi wysłać pakiet SYN, a serwer na niego odpowiedzieć pakietem SYN-ACK. W tym momencie klient może już przesyłać pierwsze dane wraz z potwierdzeniem ACK. Dopiero po odebraniu tego pakietu serwer połączenie uważa się za nawiązane (ESTABLISHED) i przystępuje do wysyłania kodu strony dla klienta. Podróż pakietu od klienta do serwera i z powrotem określana jest mianem round-trip time (RTT), czyli czasem podróży tam i z powrotem.

Zauważ, że serwer HTTP jest bezstanowy, czyli każde żądanie jest dla niego indywidualne. Dlatego często trzeba nawiązywać nowe połączenia TCP, a każde takie nawiązanie zawiera w sobie koszt RTT.

Ile kosztuje RTT?

Wartość RTT jest celem dla mechanizmu TCP Fast Open, im większa ona jest, tym zysk jest większy. Dlatego warto dobrze zrozumieć istotę sprawy. Wyobraź sobie, że chcesz wybrać się do kina. Wcześniej jednak musisz pojechać do kina i zakupić bilet. Po otrzymaniu biletu, musisz wrócić do domu i z powrotem wrócić na film, o wyznaczonej porze. Tak w skrócie można zobrazować nawiązanie sesji TCP. W tym miejscu pominiemy fakt, że pierwszy raz bez sensu musisz jechać do kina tylko po to, aby kupić bilet. Skupmy się na tym, ile czasu tracisz przez to.

W rzeczywistym świeci wziąłbyś ze sobą zegarek i zmierzył czas, w świecie komputerów służy do tego program ping. Jeżeli ping-niesz różne strony, to w wyniku otrzymasz czas RTT. Jeżeli masz wolne łącze podróż pakietom zajmie więcej czasu. Ponadto należy pamiętać, że przeciętne strony wymagają wielu zapytań, często do różnych serwerów i w każdym z nich jest zawarty czas RTT.

Jak już wspomniałem wcześniej Google posiada największe "laboratorium", w którym dokładnie policzono jaki jest rzeczywisty koszt RTT.

Wykres przedstawia wyniki badań przeprowadzone na serwerach Google. Czerwony słupek reprezentuje procentowy koszt nowego trójstopniowego połączenia TCP, zielony to suma pierwszych i kolejnych zapytań w nawiązanych sesjach. Dla różnych usług Google te wartości są inne, ale jak widać w procesie wyszukiwania aż 15% czasu zabiera nawiązanie sesji TCP z serwerem.

Problem ten wcale nie jest nowy, po części rozwiązano go już wcześniej wprowadzając do protokołu HTTP mechanizm zwany Persistent Connection (RFC2616). Dla przykładu w serwerze Apache służy do tego dyrektywa KeepAlive, która jest domyślnie włączona. Również wszystkie przeglądarki implementują ten mechanizm.
Problem z Persistent Connection polega na tym, że o ile po stronie klient zasoby są raczej nie wykorzystywane maksymalnie, to po stronie serwera mechanizm ten zużywa bardzo dużo zasobów. Poza tym jak wynika z badań przeprowadzonych przez Google w 33% sytuacji mechanizm ten nie zdaje egzaminu. Wynika to z tego, jak obecnie złożone są strony internetowe i ze sposobu w jaki deweloperzy starają się przyśpieszyć ich ładowanie. Wiele serwisów korzysta z kilku równoległych połączeń, aby przyśpieszyć generowanie treści. Poza tym co raz popularniejsze urządzenia przenośne nie przechowują długo nieaktywnych połączeń z uwagi na mniejszą ilość zasobwów.
Persistent Connection to nie jedyny mechanizm przyśpieszenia protokołu HTTP, jest jeszcze HTTP Pipelining, o którym również pisałem wcześniej.

Pominąć 3WHS

Obecny standard TCP zezwala na wysyłanie danych wraz z pierwszym pakietem SYN, chociaż nie zezwala na wymianę danych przed zakończenie trójstopniowego połączenia. Dlatego postanowiono wykorzystać ten fakt i dodano do pakietu SYN tzw. prośbę o ciasteczko (cookie request) - przedstawia to schemat poniżej.

Gdy serwer otrzyma wraz z pakietem SYN prośbę o ciasteczko, wygeneruje je na podstawie adresu IP klienta i odeśle wraz z pakietem SYN, ACK. Klucz używany przez serwer do generowania ciasteczek jest zmieniany co jakiś czas ze względów bezpieczeństwa. Klient otrzymane ciasteczko przechowuje podobnie jak odpowiedzi serwera DNS, na przyszły użytek. Po rejestracji nowego klienta wymiana danych przebiega standardowo.

Korzyści zaczynają się wtedy, gdy ten sam klient ponownie wyśle zapytanie do serwera. Najpierw klient sprawdza, czy dysponuje ciasteczkiem dla danego serwera. Jeżeli takie posiada, to dołączy je i dane do pierwszego pakietu SYN. Serwer spostrzegając ciasteczko w pakiecie SYN przystępuje do jego weryfikacji. Są to podobno bardzo szybkie operacje szyfrowania, które mają minimalny wpływ na opóźnienia.

Prawidłowe ciasteczko sprawia, że serwer przekazuje dane z pakietu SYN do aplikacji, której wynik jest przesyłany z powrotem do klienta wraz z pakietem SYN, ACK. W ten sposób, w przypadku kolejnych zapytań, klient otrzymuje kod strony (w innym przypadku dane) w czasie jednego RTT, czyli pinga.

Ponad to serwer może zacząć wysyłać kolejne dane jeszcze przed otrzymania potwierdzenia, czyli ostatniego kroku 3WHS.

Gdyby nie mechanizm ciasteczek, można byłoby od razu przesyłać dane w pierwszym pakiecie SYN. Niestety, wtedy protokół TCP straciłby jedną ze swoich głównych zalet - stałby się niepodatny na fałszowanie adresu IP. Mimo konieczności generowania ciasteczek mechanizm ten nadal przyśpiesz połączenia (np. o 15% dla każdego kolejnego zapytania do google.com).

Implementacja

W każdym moim wpisie przychodzi czas na stwierdzenie, że GNU/Linux jest najlepszy :). W tym tekście ten czas przyszedł właśnie teraz. Przebrneliśmy przez tyle rzeczy tylko po to, abym znów mógł napisać, że Linux jest najlepszy. Właściwie czytanie tego tekstu można by rozpocząć od tego momentu, ale zapomniałem wspomnieć o tym na samym początku.

Tak więc, Linux jest obecnie pierwszym systemem, który będzie wspierał mechanizm TCP Fast Open. Do wersji jądra 3.6 dodano obsługę client-side, natomiast server-side została dodany do zbliżającej się wersji 3.7.

Obecnie TFO jest na poziomie wdrażania i testowania, istnieje propozycja standardu w IETF, co do której są oczekiwania, że w 2013 roku stanie się oficjalnym standardem. Na chwilę obecną trwają jeszcze rozważania nad propozycjami wdrożenia tego mechanizmu w przyszłości do innych systemów operacyjnych, zwłaszcza systemu Windows. Natomiast korzyści TFO będzie przynosił już niedługo, np. dla Google w samej serwerowni.

Zasoby:
"TCP Fast Open", CoNEXT 2011
"TCP Fast Open: expediting web services", lwn.net
"Let's make TCP faster", The Official Google Code blog

"Main development phase of Linux 3.7 completed", h-online.com
"How Google Wants to Make TCP Faster", readwrite.com

Internet Draft "TCP Fast Open", tools.ietf.org

Podsumowanie roku przez Google

Już coroczny przegląd statystyk wyszukiwania i tego co się wydarzyło w mijającym roku 2011.

Więcej na www.googlezeitgeist.com

Jest też podsumowanie tego co oglądano najczęściej na YouTube.

Lista najczęściej oglądanych dostępna na:

http://googleblog.blogspot.com/2011/12/what-were-we-watching-this-year-lets.html

Czy Google Chrome szpieguje swoich użytkowników?

Google Chrome od początku zaskakiwał pozytywnie użytkowników i zdobywała ich uznanie. Nie potrzebował na to tyle czasu, co inne przeglądarki. Jej dynamiczny rozwój jest fundowany przez jedną z największych informatycznych firm jaką jest Google. Być może dlatego Chrome jest oskarżany, czy podejrzewany o szpiegowanie swoich użytkowników.

Wielu internautów twierdzi, że Chrome jest naszpikowany szpiegowskim kodem i jeżeli już, to lepiej używać Chromium. Chromium to pierwotny projekt Chrome zawierający tylko kod open source. Uważa się, że Google dodaje do niego tajne technologie, aby szpiegować użytkowników.

Oczywiście tak nie jest. Zwróć uwagę na to, iż Google obecnie jest najinnowacyjniejszą firmą informatyczną. Niemal co miesiąc wprowadza nowe produkty, które maja ułatwić wyszukiwanie, czy samo używanie sieci. Do tworzenia i rozwijania najlepszych rozwiązań potrzebne są dane statystyczne, na podstawie których podejmuje się decyzje dotyczące kierunku rozwoju. Poza tym, mówi się, że Google zbiera o nas dane itp. a pomija się np. fakt, że zakładając sobie darmowe konto pocztowe, czy jakąś inna usługę (poza Google) trzeba podać takie dane jak data urodzenia i tym podobne. Potwierdzamy zgodę na przetwarzanie w celach handlowych i wszystko przebiega bez afery, podczas gdy Google zbiera dane do analizy rozwiązań jest oskarżane o szpiegostwo.

Co do rozwiązań Google, które utrzymuje w tajemnicy, to nie ma co się dziwić. Przecież jakąś tajemnice muszą mieć, dotyczącą swoich technologii. Warto zwrócić uwagę na to, że wiele z tych technologi trafia do świata open source. Mało która firma tak go wzbogaca jak Google.

W przypadku Google najważniejsze jest to, aby zrozumieć sposób w jaki oni zarabiają. Firma ta słynie z tego, że prowadzi innowacyjny system reklam, który jest najmniej uciążliwy dla użytkownika, a mimo to osiągają duże dochody. Jednym zdaniem udało im się połączyć rozwój wyszukiwania z korzyściami finansowymi. Problem w tym, że sposób ten jest tak sprytny, że nie wszyscy go rozumieją. W przypadku korzystania z samej wyszukiwarki sposób w jaki Google na tym zarabia jest bardzo ukryty, ale z kolei w serwisie youtube.com jest to bardziej widoczne. Google np. sprytnie minimalizuje ilość reklam na rzecz ich trafności, przy takich samych, a nawet większych zyskach. Do tego jednak potrzebne są pewne informacje zbierane podczas wyszukiwania.

Chromium w porównaniu do Google Chrome to projekt zawierający tylko HTML i inne podstawowe technologie, najprościej mówiąc jest to część techniczna niezbędna do przeglądania sieci. Natomiast Chrome jest wyposażony w szereg dodatków sprawiających, że korzystanie z przeglądarki i sieci jest jeszcze prostsze.

Google, jak mało która firma informuje użytkowników jak działają jej usługi. Dobrym przykładem jest ten film.


Więcej informacji można znaleźć w poniższych miejscach:
http://en.wikipedia.org/wiki/Google_Chrome#Usage_tracking
http://blog.chromium.org/2010/06/in-open-for-rlz.html
http://www.google.com/chrome/intl/pl/privacy.html