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

45

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 )
Ahmed
źródło
2
Żądanie nie może zostać złożone, dopóki strona internetowa nie zostanie oczywiście pobrana. Następnie żądania są składane w kolejności odczytywania kodu HTML. Nie oznacza to jednak, że jednorazowo wysyłana jest tylko jedna prośba. W rzeczywistości powstaje kilka żądań, ale czasami istnieją zależności między nimi, a niektóre muszą zostać rozwiązane, zanim strona będzie mogła zostać poprawnie pomalowana. Przeglądarki czasami zatrzymują się, gdy żądanie jest spełnione, zanim pojawią się, aby obsłużyć inne odpowiedzi, sprawiając wrażenie, że każde żądanie jest obsługiwane pojedynczo. Rzeczywistość jest bardziej po stronie przeglądarki, ponieważ zwykle wymagają one dużych zasobów.
closetnoc
20
Dziwię się, że nikt nie wspomniał o buforowaniu. Jeśli mam już ten plik, nie potrzebuję go przesyłać.
Corey Ogburn
2
Ta lista może mieć setki rzeczy. Chociaż jest krótszy niż faktyczne wysyłanie plików, nadal jest dość daleki od optymalnego rozwiązania.
Corey Ogburn
1
W rzeczywistości nigdy nie odwiedziłem strony internetowej, która ma ponad 100 unikalnych zasobów.
Ahmed
2
@AhmedElsoobky: przeglądarka nie wie, jakie zasoby można wysłać jako nagłówek zasobów buforowanych bez uprzedniego pobrania samej strony. Byłby to również koszmar prywatności i bezpieczeństwa, jeśli pobranie strony mówi serwerowi, że mam inną stronę w pamięci podręcznej, która jest prawdopodobnie kontrolowana przez inną organizację niż strona oryginalna (strona wielu dzierżawców).
Lie Ryan

Odpowiedzi:

63

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.

Stephen Ostermiller
źródło
2
Dang dobra i świadoma odpowiedź! Przeglądarki internetowe są z natury szeregowe i żądania mogą być wysyłane dość szybko. Jedno spojrzenie na plik dziennika pokaże, że żądania dotyczące zasobów są wysyłane dość szybko po przeanalizowaniu kodu HTML. Jest jak jest. Niezły system, po prostu nie tak wydajny jak na kod / zasoby.
closetnoc
6
Dla przypomnienia, SPDY nie jest świętym Graalem. Robi to dobrze, ale wprowadza inne problemy. Oto jeden artykuł zawierający kilka punktów mówiących przeciw SPDY.
Jost
3
Gorąco polecam wszystkim zainteresowanym przeczytanie krytyki w linku @Jost. Daje to wskazówkę dotyczącą złożoności, która polega na zastanawianiu się, jak zrobić bardzo często wdrażaną rzecz, nie tylko stopniowo, ale o wiele lepiej, aby wszyscy zaczęli z niej korzystać . Łatwo jest wymyślić ulepszenie, które sprawia, że ​​sytuacja jest nieco lepsza w przypadku stosunkowo dużego zestawu przypadków użycia. Ulepszenie w taki sposób, aby wszyscy zaczęli korzystać z nowego protokołu, ponieważ jest o tyle lepszy, że warto go zmienić, to zupełnie inna sprawa i nie jest łatwa do zrobienia.
msouth
11
powinien pozostawić tę pracę profesjonalistom : gdyby to zrobił, zajęłoby sześć lat opracowanie standardu, który byłby nieaktualny w dniu jego opublikowania, a wkrótce pojawiłoby się tuzin konkurencyjnych standardów. Poza tym, czy profesjonaliści potrzebowali od kogoś zgody? Dlaczego nie zrobili tego sami?
Shantnu Tiwari
2
Szczerze mówiąc, nie było wtedy wykwalifikowanych specjalistów. Nikt nie wie, jak zbudować sieć WWW, ponieważ nikt nigdy jej nie zbudował. Koncepcja hipermediów nie została wymyślona przez Tima, miał on doświadczenie z różnymi lokalnymi systemami hipermedialnymi dziesięć lat przed napisaniem propozycji „zarządzania informacją” w celu rozwiązania problemu „utraty informacji” w CERN.
Lie Ryan
14

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:

utrzymać przy życiu

rurociągi

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:

Dalsza lektura:

wino z gruszek
źródło
Cóż, w rzeczywistości możemy zająć się tymi wszystkimi problemami ubocznymi (takimi jak: pamięć podręczna, nagłówek Content-Type .. itd.). Istnieją obejścia pozwalające rozwiązać te problemy. I jak zasugerowałem w komentarzach do powyższego postu, możemy użyć czegoś takiego jak ten nagłówek> Zasoby buforowane: image.jpg; style.css; rozwiązać problem buforowania .. (Jeśli masz czas, możesz spojrzeć na powyższe komentarze ..)
Ahmed,
Tak, ten pomysł przyszedł mi do głowy, ale jest to po prostu zbyt duży narzut dla HTTP i nie rozwiązuje faktu, że zasoby mogą być rozłożone na wiele serwerów. Co więcej, nie sądzę, aby proponowana metoda oszczędzania czasu faktycznie oszczędzała czas, ponieważ dane będą wysyłane jako strumień, bez względu na to, jak na to spojrzysz, a przy utrzymaniu przy życiu 100 równoczesnych żądań HTTP w zasadzie staje się 1 żądaniem. Wydaje się, że proponowana technologia i możliwości już istnieją. Zobacz en.wikipedia.org/wiki/HTTP_persistent_connection
perry
@perry: Co byś pomyślał o pomyśle alternatywnym do https://wysyłania dużych publicznie rozpowszechnianych plików, które wymagają uwierzytelnienia, ale nie są poufne: dołącz do adresu URL skrót niektórych części nagłówka uzasadnionej odpowiedzi, który z kolei może dołączyć podpis lub skrót danych i czy przeglądarki sprawdzają poprawność otrzymanych danych względem nagłówka? Taki projekt nie tylko pozwoliłby zaoszczędzić niektóre kroki uzgadniania SSL, ale co ważniejsze, pozwoliłby buforować serwery proxy. Uzyskaj adres URL za pomocą łącza SSL, a dane mogą być podawane z dowolnego miejsca.
supercat
11

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

John Conde
źródło
2
Zwłaszcza, jeśli używasz czegoś takiego jak wymagana.js. Przeglądarka pyta tylko o to, czego potrzebuje. Wyobraź sobie, że musisz ładować wszystko naraz ...
Aran Mulholland
2
To jest poprawna odpowiedź i jedna, której wydaje się brakować większości komentujących - aby serwer mógł proaktywnie wysyłać zasoby, musi wiedzieć, co to jest, co oznacza, że serwer musiałby parsować HTML.
1
Ale pytanie dotyczy tego, dlaczego serwer WWW nie wysyła zasobów, a nie dlaczego klient nie może ich o to poprosić w tym samym czasie. Bardzo łatwo jest wyobrazić sobie świat, w którym serwery mają pakiet powiązanych zasobów, które wszystkie są wysyłane razem, i które nie wymagają analizowania kodu HTML w celu zbudowania pakietu.
David Meister
@DavidMeister Ponieważ serwer nie zawsze wie, czego chce klient - przeglądarka internetowa dla wyszukiwarki może nie dbać o CSS / JS i istnieje wiele innych zasobów połączonych w dokumencie poza nimi - nie trzeba wysyłać całego Kanał RSS znajduje się w pakiecie do przeglądarki internetowej (większość treści jest już prawdopodobnie w formacie HTML), podczas gdy czytnik kanałów może po prostu przeanalizować <head>element szukający alternatywnych linków RSS, aby znaleźć właśnie to - klient może wysłać listę czym jest zainteresowany, ale potem musi wiedzieć, co jest dostępne i wróciliśmy na początek
Zhaph - Ben Duguid
@ Zhaph-BenDuguid Mówię o alternatywnym świecie, aby podkreślić, że odpowiedź ma tyle samo wspólnego z tym, jak działa protokół, jak wszystko inne. Ponadto serwer może wysyłać wszystkie dane jednocześnie, nawet jeśli nie jest to konieczne. Zasadniczo wymieniasz problemy związane z opóźnieniem w stosunku do wykorzystania przepustowości.
David Meister
8

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.

Matija Nalis
źródło
3
Myślę, że to poprawna odpowiedź.
el.pescado,
7

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

MaBu
źródło
3

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.

The Spooniest
źródło
Jeśli zamierzamy opracować nowy protokół lub naprawić już istniejący, możemy rozwiązać wszystkie te problemy w taki czy inny sposób! A serwer WWW parsuje pliki tylko raz, a następnie może je klasyfikować w zależności od zdefiniowanych reguł, dzięki czemu może ustalić priorytety, które pliki najpierw wysłać ... itd., A serwer WWW nie musi wiedzieć, co mam zrobić z tymi plikami, po prostu trzeba wiedzieć, co wysłać, kiedy to zrobić i w zależności od tego, jakie reguły .. (boty i pająki internetowe nie stanowią problemu, zachowanie będzie się z nimi różnić - mają unikalne nagłówki klienta użytkownika) ..)
Ahmed,
@AhmedElsobky: To, o czym mówisz, brzmi bardziej jak konkretna implementacja niż protokół sieciowy. Ale tak naprawdę musi wiedzieć, co zamierzasz zrobić z plikami, zanim będzie mógł określić, co wysłać: w przeciwnym razie nieuchronnie wyśle ​​pliki, których wielu użytkowników nie chce. Nie można ufać ciągom użytkownika-agenta, więc nie można ich używać do określania zamiarów użytkownika.
The Spooniest