Kiedy serwery WWW wysyłają stronę, dlaczego nie wysyłają wszystkich wymaganych CSS, JS i obrazów bez pytania?

Jeśli strona internetowa zawiera pojedynczy plik CSS i obraz, dlaczego przeglądarki i serwery marnują czas na tę tradycyjną, czasochłonną trasę:

1. przeglądarka wysyła początkowe żądanie GET dla strony internetowej i czeka na odpowiedź serwera.
2. przeglądarka wysyła kolejne żądanie GET dla pliku css i czeka na odpowiedź serwera.
3. przeglądarka wysyła kolejne żądanie GET dla pliku obrazu i czeka na odpowiedź serwera.

Kiedy zamiast tego mogliby skorzystać z tej krótkiej, bezpośredniej i oszczędzającej czas trasy?

1. Przeglądarka wysyła żądanie GET dla strony internetowej.
2. Serwer WWW odpowiada za pomocą ( index.html, po których następuje style.css i image.jpg )

Krótka odpowiedź brzmi: „Ponieważ HTTP nie został do tego zaprojektowany”.

Tim Berners-Lee nie zaprojektował wydajnego i rozszerzalnego protokołu sieciowego. Jego jedynym celem projektowym była prostota. (Profesor mojej klasy networkingowej na studiach powiedział, że powinien był zostawić tę pracę profesjonalistom.) Problem, który zarysowujesz, jest tylko jednym z wielu problemów z protokołem HTTP. W oryginalnej formie:

• Nie było wersji protokołu, tylko prośba o zasób
• Nie było nagłówków
• Każde żądanie wymagało nowego połączenia TCP
• Nie było kompresji

Protokół został później zmieniony w celu rozwiązania wielu z tych problemów:

• Żądania zostały wersjonowane, teraz wyglądają GET /foo.html HTTP/1.1
• Nagłówki zostały dodane do meta informacji z żądaniem i odpowiedzią
• Połączenia mogły być ponownie wykorzystane Connection: keep-alive
• Wprowadzono odpowiedzi fragmentaryczne, aby umożliwić ponowne użycie połączeń, nawet jeśli rozmiar dokumentu nie jest znany z góry.
• Dodano kompresję Gzip

W tym momencie HTTP został podjęty tak daleko, jak to możliwe, bez naruszania wstecznej kompatybilności.

Nie jesteś pierwszą osobą, która sugeruje, że strona i wszystkie jej zasoby powinny zostać przekazane klientowi. W rzeczywistości Google zaprojektował protokół, który może to zrobić, zwany SPDY .

Obecnie zarówno Chrome, jak i Firefox mogą używać SPDY zamiast HTTP do serwerów, które go obsługują. Ze strony internetowej SPDY jego główne funkcje w porównaniu do HTTP to:

• SPDY pozwala klientowi i serwerowi kompresować nagłówki żądań i odpowiedzi, co zmniejsza zużycie przepustowości, gdy podobne nagłówki (np. Pliki cookie) są wysyłane w kółko dla wielu żądań.
• SPDY pozwala na wiele jednoczesnych multipleksowanych żądań w ramach jednego połączenia, co pozwala zaoszczędzić na podróżach między klientem a serwerem i zapobiega blokowaniu żądań o wyższym priorytecie przez zasoby o niskim priorytecie.
• SPDY pozwala serwerowi aktywnie przekazywać zasoby do klienta, o którym wie, że będzie potrzebował klienta (np. Pliki JavaScript i CSS), bez czekania na żądanie klienta, umożliwiając serwerowi efektywne wykorzystanie niewykorzystanej przepustowości.

Jeśli chcesz udostępnić swoją witrynę SPDY w przeglądarkach, które ją obsługują, możesz to zrobić. Na przykład Apache ma mod_spdy .

SPDY stał się podstawą dla wersji HTTP 2 z technologią push serwera.

Twoja przeglądarka internetowa nie wie o dodatkowych zasobach, dopóki nie pobierze strony internetowej (HTML) z serwera, która zawiera łącza do tych zasobów.

Być może zastanawiasz się, dlaczego serwer po prostu nie analizuje własnego kodu HTML i nie wysyła wszystkich dodatkowych zasobów do przeglądarki podczas pierwszego żądania strony internetowej? Wynika to z faktu, że zasoby mogą być rozmieszczone na wielu serwerach, a przeglądarka internetowa może nie potrzebować wszystkich tych zasobów, ponieważ niektóre z nich są już buforowane lub mogą ich nie obsługiwać.

Przeglądarka internetowa utrzymuje pamięć podręczną zasobów, więc nie musi pobierać tych samych zasobów w kółko z serwerów, które je hostują. Podczas nawigacji po różnych stronach witryny, z których wszystkie korzystają z tej samej biblioteki jQuery, nie chcesz pobierać tej biblioteki za każdym razem, tylko za pierwszym razem.

Kiedy więc przeglądarka internetowa pobiera stronę internetową z serwera, sprawdza, jakie zasoby połączone NIE ma już w pamięci podręcznej, a następnie wysyła dodatkowe żądania HTTP dla tych zasobów. Całkiem proste, bardzo elastyczne i rozszerzalne.

Przeglądarka internetowa zwykle może jednocześnie wysyłać dwa żądania HTTP. Nie inaczej jest w przypadku AJAX - oba są asynchronicznymi metodami ładowania stron internetowych - asynchroniczne ładowanie plików i asynchroniczne ładowanie treści. Dzięki utrzymywaniu przy życiu możemy wysyłać kilka żądań za pomocą jednego połączenia, a dzięki potokowi możemy wysyłać kilka żądań bez konieczności oczekiwania na odpowiedzi. Obie te techniki są bardzo szybkie, ponieważ większość narzutu zazwyczaj pochodzi z otwierania / zamykania połączeń TCP:

Trochę historii online ...

Strony internetowe powstały jako zwykłe wiadomości e-mail, a systemy komputerowe były konstruowane wokół tej idei, tworząc nieco darmową platformę komunikacyjną; serwery internetowe były wówczas własnością firmy. Później do „specyfikacji e-mail” dodano więcej warstw w postaci dodatkowych typów MIME, takich jak obrazy, style, skrypty itp. W końcu MIME oznacza rozszerzenie wielofunkcyjnej poczty internetowej . Wcześniej czy później mieliśmy praktycznie e-mail multimedialną komunikację, znormalizowane serwery i strony internetowe.

HTTP wymaga, aby dane były przesyłane w kontekście wiadomości podobnych do wiadomości e-mail, chociaż najczęściej nie są to wiadomości e-mail.

W miarę ewolucji takiej technologii musi ona umożliwiać programistom stopniowe wprowadzanie nowych funkcji bez przerywania istniejącego oprogramowania. Na przykład, gdy do specyfikacji zostanie dodany nowy typ MIME - powiedzmy JPEG - jego wdrożenie zajmie trochę czasu. Nie tylko nagle zmuszasz plik JPEG do specyfikacji i zaczynasz wysyłać go do wszystkich przeglądarek internetowych, zezwalasz przeglądarce na żądanie zasobów, które obsługuje, co sprawia, że ​​wszyscy są zadowoleni, a technologia postępuje. Czy czytnik ekranu potrzebuje wszystkich plików JPEG na stronie internetowej? Prawdopodobnie nie. Czy musisz być zmuszony do pobrania wielu plików JavaScript, jeśli Twoje urządzenie nie obsługuje Javascript? Prawdopodobnie nie. Czy Googlebot musi pobrać wszystkie pliki JavaScript, aby poprawnie zaindeksować witrynę? Nie.

Źródło: Opracowałem oparty na zdarzeniach serwer WWW, taki jak Node.js. Nazywa się Rapid Server .

Bibliografia:

• Trwałe połączenie HTTP (utrzymywanie aktywności)
• Potokowanie HTTP
• Połączenia HTTP / 1.1 (RFC 2616)

Dalsza lektura:

• Czy SPDY różni się od multipleksowania HTTP przez utrzymywanie żywych połączeń
• Dlaczego HTTP / 2.0 nie wydaje się interesujący

Ponieważ nie wiedzą, czym są te zasoby. Zasoby wymagane przez stronę internetową są zakodowane w kodzie HTML. Tylko wtedy, gdy analizator składni określi, jakie są te zasoby, użytkownik może zażądać y.

Dodatkowo, gdy te zasoby są znane, należy je podawać indywidualnie, aby można było podawać odpowiednie nagłówki (tj. Typ zawartości), aby klient użytkownika wiedział, jak je obsługiwać.

Ponieważ w twoim przykładzie serwer WWW zawsze wysyła CSS i obrazy, niezależnie od tego, czy klient już je ma, co znacznie marnuje przepustowość (a tym samym spowalnia połączenie , zamiast zmniejszać opóźnienie, co prawdopodobnie było twoim zamiarem). Pamiętaj, że właśnie z tego powodu pliki CSS, JavaScript i pliki graficzne są wysyłane z bardzo długim czasem wygaśnięcia (tak jak wtedy, gdy trzeba je zmienić, wystarczy zmienić nazwę pliku, aby wymusić nową kopię, która będzie ponownie buforowana przez długi czas).

Teraz możesz spróbować obejść problem marnowania przepustowości, mówiąc „ OK, ale klient może wskazać, że ma już niektóre z tych zasobów, więc serwer nie wyśle ​​go ponownie ”. Coś jak:

GET /index.html HTTP/1.1
Host: www.example.com
If-None-Match: "686897696a7c876b7e"
Connection: Keep-Alive

GET /style.css HTTP/1.1
Host: www.example.com
If-None-Match: "70b26618ce2c246c71"

GET /image.png HTTP/1.1
Host: www.example.com
If-None-Match: "16d5b7c2e50e571a46"

A następnie otrzymuj tylko te pliki, które nie uległy zmianie, wysyłane przez jedno połączenie TCP (przy użyciu potokowania HTTP zamiast trwałego połączenia). I zgadnij co? Tak to już działa (możesz także użyć If-Modified-Since zamiast If-None-Match ).

Ale jeśli naprawdę chcesz zmniejszyć opóźnienia, marnując dużo pasma (jak w pierwotnym żądaniu), możesz to zrobić dzisiaj, używając standardowego protokołu HTTP / 1.1 podczas projektowania witryny. Większość ludzi tego nie robi, ponieważ nie uważa, że ​​warto.

Aby to zrobić, nie musisz mieć CSS lub JavaScript w osobnym pliku, możesz dołączyć je do głównego pliku HTML za pomocą tagów <style>i <script>(prawdopodobnie nie musisz nawet robić tego ręcznie, silnik szablonów prawdopodobnie zrobi to automatycznie) . Możesz nawet dołączyć obrazy do pliku HTML za pomocą URI danych , w następujący sposób:

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg==" alt="Red dot" />

Oczywiście kodowanie base64 nieznacznie zwiększa wykorzystanie przepustowości, ale jeśli nie zależy ci na marnowanej przepustowości, nie powinno to stanowić problemu.

Teraz, jeśli naprawdę Ci na tym zależy, możesz nawet sprawić, że twoje skrypty internetowe będą wystarczająco inteligentne, aby uzyskać jak najlepszy efekt z obu światów: na pierwsze żądanie (użytkownik nie ma pliku cookie), wyślij wszystko (CSS, JavaScript, obrazy) osadzone tylko w jednym HTML plik jak opisano powyżej, dodaj link rel = "prefetch" tagi dla zewnętrznych kopii plików i dodaj plik cookie. Jeśli użytkownik ma już cookie (np. On odwiedził wcześniej), a następnie wysłać go po prostu normalnym HTML z <img src="example.jpg">, <link rel="stylesheet" type="text/css" href="style.css">etc.

Tak więc przy pierwszej wizycie przeglądarka zażąda tylko jednego pliku HTML i pobierze i pokaże wszystko. Następnie (w stanie bezczynności) wstępnie ładuje określone zewnętrzne CSS, JS, obrazy. Następnym razem, gdy użytkownik odwiedzi stronę, przeglądarka zażąda i pobierze tylko zmienione zasoby (prawdopodobnie tylko nowy HTML).

Dodatkowe dane obrazów CSS + JS + byłyby wysyłane tylko dwukrotnie, nawet jeśli klikniesz setki razy na stronie. Znacznie lepiej niż setki razy, jak sugeruje proponowane rozwiązanie. I nigdy nie użyłby (nie za pierwszym razem, ani następnym razem) więcej niż jednej podróży w obie strony zwiększającej opóźnienia.

Teraz, jeśli to brzmi jak zbyt dużo pracy, a nie chcesz korzystać z innego protokołu, takiego jak SPDY , istnieją już moduły, takie jak mod_pagespeed dla Apache, które mogą automatycznie wykonać dla ciebie część tej pracy (scalenie wielu plików CSS / JS w jednym, automatycznie wstawiając mały CSS i minimalizując je, twórz małe zastępcze wstawiane obrazy podczas oczekiwania na załadowanie oryginałów, leniwe ładowanie obrazów itp.) bez konieczności modyfikowania pojedynczego wiersza strony.

HTTP2 jest oparty na SPDY i robi dokładnie to, co sugerujesz:

Na wysokim poziomie HTTP / 2:

• jest binarny, a nie tekstowy
• jest w pełni zmultipleksowany, a nie uporządkowany i blokowany
• może zatem użyć jednego połączenia do równoległości
• używa kompresji nagłówka w celu zmniejszenia obciążenia
• pozwala serwerom proaktywnie „wypychać” odpowiedzi do pamięci podręcznej klienta

Więcej jest dostępnych na HTTP 2 Faq

Ponieważ nie zakłada się, że te rzeczy są rzeczywiście wymagane .

Protokół nie definiuje żadnej specjalnej obsługi dla określonego typu pliku lub klienta użytkownika. Nie zna różnicy między, powiedzmy, plikiem HTML a obrazem PNG. Aby wykonać to, o co prosisz, serwer sieci Web musiałby zidentyfikować typ pliku, przeanalizować go, aby dowiedzieć się, do jakich innych plików się odwołuje, a następnie ustalić, które inne pliki są rzeczywiście potrzebne, biorąc pod uwagę to, co zamierzasz zrobić plik . Są z tym trzy duże problemy.

Pierwszy problem polega na tym, że nie ma standardowego, niezawodnego sposobu identyfikowania typów plików po stronie serwera . HTTP zarządza za pomocą mechanizmu Content-Type, ale to nie pomaga serwerowi, który musi sam to rozgryźć (częściowo po to, aby wiedział, co wprowadzić w Content-Type). Rozszerzenia nazw plików są szeroko obsługiwane, ale delikatne i łatwe do oszukania, czasem w złośliwych celach. Metadane systemu plików są mniej delikatne, ale większość systemów nie obsługuje ich zbyt dobrze, więc serwery nawet nie przeszkadzają. Wykrywanie zawartości (jak fileto robią niektóre przeglądarki i polecenie Unix ) może być niezawodne, jeśli chcesz uczynić go drogim, ale silne wykrywanie jest zbyt drogie, aby było praktyczne po stronie serwera, a tanie wykrywanie nie jest wystarczająco solidne.

Drugi problem polega na tym, że parsowanie pliku jest kosztowne z punktu widzenia obliczeń . To wiąże się nieco z pierwszym, ponieważ trzeba by przeanalizować plik na kilka różnych potencjalnych sposobów, jeśli chcesz silnie wąchać zawartość, ale ma to również zastosowanie po zidentyfikowaniu typu pliku, ponieważ potrzebujesz dowiedzieć się, jakie są odniesienia. Nie jest to takie złe, gdy robisz tylko kilka plików jednocześnie, tak jak robi to przeglądarka, ale serwer sieciowy musi obsłużyć setki lub tysiące żądań jednocześnie. To się sumuje, a jeśli posunie się za daleko, może faktycznie spowolnić bardziej niż wiele żądań. Jeśli kiedykolwiek odwiedziłeś link z Slashdot lub podobnych stron, a okazało się, że serwer jest agresywnie powolny z powodu dużego użycia, zobaczyłeś tę zasadę w działaniu.

Trzeci problem polega na tym, że serwer nie może wiedzieć, co zamierzasz zrobić z plikiem . Przeglądarka może wymagać odwołania do plików w kodzie HTML, ale może nie, w zależności od dokładnego kontekstu, w którym plik jest wykonywany. Byłoby to dość skomplikowane, ale w sieci jest coś więcej niż tylko przeglądarki: między pająkami, agregatorami kanałów i mashupami stronowymi istnieje wiele rodzajów programów klienckich, w których pliki HTML nie są potrzebne: zależy tylko na samym HTML. Wysłanie tych innych plików do takich programów klienckich zmarnowałoby tylko przepustowość.

Najważniejsze jest to, że ustalenie tych zależności po stronie serwera jest większym problemem niż jest warte . Zamiast tego pozwalają klientowi dowiedzieć się, czego potrzebuje.