Wenn Webserver eine Seite senden, warum senden sie dann nicht alle erforderlichen CSS-, JS- und Bilddateien, ohne dazu aufgefordert zu werden?

45

Wenn eine Webseite eine einzelne CSS-Datei und ein Bild enthält, warum verschwenden Browser und Server Zeit mit dieser herkömmlichen zeitaufwendigen Route:

  1. Der Browser sendet eine erste GET-Anforderung für die Webseite und wartet auf die Antwort des Servers.
  2. Der Browser sendet eine weitere GET-Anforderung für die CSS-Datei und wartet auf die Antwort des Servers.
  3. Der Browser sendet eine weitere GET-Anforderung für die Image-Datei und wartet auf die Antwort des Servers.

Wann könnten sie stattdessen diese kurze, direkte und zeitsparende Route nutzen?

  1. Der Browser sendet eine GET-Anfrage für eine Webseite.
  2. Der Webserver antwortet mit ( index.html gefolgt von style.css und image.jpg )
Ahmed
quelle
2
Eine Anfrage kann natürlich erst gestellt werden, wenn die Webseite abgerufen wurde. Danach werden Anforderungen in der Reihenfolge gestellt, in der der HTML-Code gelesen wird. Dies bedeutet jedoch nicht, dass jeweils nur eine Anfrage gestellt wird. Tatsächlich werden mehrere Anforderungen gestellt, aber manchmal bestehen Abhängigkeiten zwischen den Anforderungen und einige müssen aufgelöst werden, bevor die Seite ordnungsgemäß gezeichnet werden kann. Browser pausieren manchmal, wenn eine Anforderung erfüllt ist, bevor andere Antworten verarbeitet werden. Dadurch wird angezeigt, dass jede Anforderung einzeln verarbeitet wird. Die Realität ist eher auf der Browserseite, da sie in der Regel ressourcenintensiv sind.
Closetnoc
20
Ich bin überrascht, dass niemand Caching erwähnt hat. Wenn ich diese Datei bereits habe, muss sie mir nicht zugeschickt werden.
Corey Ogburn
2
Diese Liste könnte Hunderte von Dingen umfassen. Obwohl es kürzer ist als das eigentliche Senden der Dateien, ist es immer noch nicht die optimale Lösung.
Corey Ogburn
1
Eigentlich habe ich noch nie eine Webseite besucht, die mehr als 100 einzigartige Ressourcen hat ..
Ahmed
2
@AhmedElsoobky: Der Browser weiß nicht, welche Ressourcen als Cache-Ressourcen-Header gesendet werden können, ohne zuerst die Seite selbst abzurufen. Es wäre auch ein Alptraum für Datenschutz und Sicherheit, wenn das Abrufen einer Seite dem Server mitteilt, dass eine andere Seite zwischengespeichert wurde, die möglicherweise von einer anderen Organisation als der ursprünglichen Seite (einer Website mit mehreren Mandanten) gesteuert wird.
Lie Ryan

Antworten:

63

Die kurze Antwort lautet "Weil HTTP nicht dafür entwickelt wurde".

Tim Berners-Lee hat kein effizientes und erweiterbares Netzwerkprotokoll entworfen. Sein einziges Designziel war die Einfachheit. (Der Professor meiner Networking-Klasse am College sagte, er hätte den Beruf den Fachleuten überlassen sollen.) Das Problem, das Sie darlegen, ist nur eines der vielen Probleme mit dem HTTP-Protokoll. In seiner ursprünglichen Form:

  • Es gab keine Protokollversion, nur eine Anforderung für eine Ressource
  • Es gab keine Überschriften
  • Für jede Anforderung ist eine neue TCP-Verbindung erforderlich
  • Es gab keine Kompression

Das Protokoll wurde später überarbeitet, um viele dieser Probleme zu lösen:

  • Die Anfragen wurden versioniert, jetzt sehen die Anfragen so aus GET /foo.html HTTP/1.1
  • Header wurden für Metainformationen sowohl mit der Anforderung als auch mit der Antwort hinzugefügt
  • Verbindungen durften mit wiederverwendet werden Connection: keep-alive
  • Es wurden Teilantworten eingeführt, um die Wiederverwendung von Verbindungen zu ermöglichen, auch wenn die Dokumentgröße nicht im Voraus bekannt ist.
  • Gzip-Komprimierung wurde hinzugefügt

Zu diesem Zeitpunkt wurde HTTP so weit wie möglich entfernt, ohne die Abwärtskompatibilität zu beeinträchtigen.

Sie sind nicht die erste Person, die vorschlägt, dass eine Seite und alle zugehörigen Ressourcen an den Client gesendet werden sollen. Tatsächlich hat Google ein Protokoll namens SPDY entwickelt .

Heute können sowohl Chrome als auch Firefox SPDY anstelle von HTTP für Server verwenden, die dies unterstützen. Auf der SPDY-Website stehen im Vergleich zu HTTP folgende Hauptmerkmale zur Verfügung:

  • Mit SPDY können Client und Server Anforderungs- und Antwortheader komprimieren, wodurch die Bandbreitennutzung verringert wird, wenn ähnliche Header (z. B. Cookies) immer wieder für mehrere Anforderungen gesendet werden.
  • SPDY ermöglicht mehrere, gleichzeitig gemultiplexte Anforderungen über eine einzige Verbindung, spart Roundtrips zwischen Client und Server und verhindert, dass Ressourcen mit niedriger Priorität Anforderungen mit höherer Priorität blockieren.
  • Mit SPDY kann der Server Ressourcen, von denen er weiß, dass sie vom Client benötigt werden (z. B. JavaScript- und CSS-Dateien), aktiv auf den Client übertragen, ohne auf deren Anforderung zu warten. Auf diese Weise kann der Server die nicht genutzte Bandbreite effizient nutzen.

Wenn Sie Ihre Website mit SPDY für Browser bereitstellen möchten, die dies unterstützen, können Sie dies tun. Zum Beispiel hat Apache mod_spdy .

SPDY ist die Basis für HTTP Version 2 mit Server-Push-Technologie geworden.

Stephen Ostermiller
quelle
2
Verdammt gute und informierte Antwort! Webbrowser sind von Natur aus seriell und Anfragen können ziemlich schnell gestellt werden. Ein Blick auf eine Protokolldatei zeigt, dass Anfragen nach Ressourcen ziemlich schnell gestellt werden, sobald der HTML-Code analysiert wurde. Es ist was es ist. Kein schlechtes System, nur nicht so code- / ressourceneffizient wie es sein könnte.
Closetnoc
6
SPDY ist nicht der heilige Gral. Es macht einige Dinge gut, bringt aber andere Probleme mit sich. Hier ist ein Artikel, der einige Punkte enthält, die gegen SPDY sprechen.
Jost
3
Ich empfehle jedem, der sich dafür interessiert, die Kritik in @Josts Link zu lesen. Es gibt Ihnen einen Hinweis auf die Komplexität, die es mit sich bringt, herauszufinden, wie man eine sehr häufig implementierte Sache nicht nur inkrementell , sondern auch so viel besser umsetzt, dass jeder anfängt, sie zu nutzen . Man kann sich leicht eine Verbesserung vorstellen, die die Dinge für eine relativ große Teilmenge von Anwendungsfällen etwas besser macht. Die Dinge so zu verbessern, dass jeder anfängt, Ihr neues Protokoll zu verwenden, weil es so viel besser ist, dass sich die Änderungskosten lohnen, ist eine ganz andere Sache und nicht einfach zu tun.
Msouth
11
er hätte die Arbeit den Profis überlassen sollen : Wenn er das getan hätte, hätten sie sechs Jahre gebraucht, um einen Standard zu entwickeln, der an dem Tag, als er herauskam, überholt gewesen wäre, und bald wären ein Dutzend konkurrierender Standards erschienen. Brauchen die Profis außerdem die Erlaubnis von jemandem? Warum haben sie es nicht selbst gemacht?
Shantnu Tiwari
2
Um ehrlich zu sein, es gibt damals keine qualifizierten Fachkräfte. Niemand weiß, wie man ein World Wide Web baut, weil niemand jemals eines gebaut hat. Das Konzept der Hypermedien wurde nicht von Tim erfunden, er hatte zehn Jahre Erfahrung mit verschiedenen lokalen Hypermediensystemen, bevor er den Vorschlag für ein "Informationsmanagement" verfasste, um das Problem des "Informationsverlusts" am CERN zu lösen.
Lie Ryan
14

Ihr Webbrowser kennt die zusätzlichen Ressourcen erst, wenn er die Webseite (HTML) vom Server herunterlädt, die die Links zu diesen Ressourcen enthält.

Sie fragen sich vielleicht, warum der Server bei der ersten Anforderung der Webseite nicht einfach sein eigenes HTML analysiert und alle zusätzlichen Ressourcen an den Webbrowser sendet. Dies liegt daran, dass die Ressourcen möglicherweise auf mehrere Server verteilt sind und der Webbrowser möglicherweise nicht alle Ressourcen benötigt, da bereits einige zwischengespeichert sind oder diese möglicherweise nicht unterstützt werden.

Der Webbrowser verwaltet einen Cache mit Ressourcen, sodass nicht immer wieder dieselben Ressourcen von den Servern heruntergeladen werden müssen, auf denen sie gehostet werden. Wenn Sie auf verschiedenen Seiten einer Website navigieren, die alle dieselbe jQuery-Bibliothek verwenden, möchten Sie diese Bibliothek nicht jedes Mal herunterladen, sondern nur beim ersten Mal.

Wenn der Webbrowser eine Webseite vom Server abruft, prüft er, welche verknüpften Ressourcen sich noch NICHT im Cache befinden, und stellt dann zusätzliche HTTP-Anforderungen für diese Ressourcen. Ziemlich einfach, sehr flexibel und erweiterbar.

Ein Webbrowser kann normalerweise zwei HTTP-Anfragen gleichzeitig stellen. Dies ist nicht anders als bei AJAX - beide sind asynchrone Methoden zum Laden von Webseiten - asynchrones Laden von Dateien und asynchrones Laden von Inhalten. Mit Keep-Alive können wir über eine Verbindung mehrere Anfragen stellen, und mit Pipelining können wir mehrere Anfragen stellen, ohne auf Antworten warten zu müssen. Beide Techniken sind sehr schnell, da der größte Overhead normalerweise durch das Öffnen / Schließen von TCP-Verbindungen entsteht:

bleib am Leben

Pipelining

Ein bisschen Webprotokoll ...

Die Webseiten begannen als reine Text-E-Mail, und Computersysteme entwickelten sich aus dieser Idee heraus und bildeten eine etwas freie Kommunikationsplattform. Die Webserver waren zu diesem Zeitpunkt noch proprietär. Später wurden der "E-Mail-Spezifikation" weitere Ebenen in Form von zusätzlichen MIME-Typen wie Bildern, Stilen, Skripten usw. hinzugefügt. Immerhin steht MIME für Multi-Purpose Internet Mail Extension. Früher oder später hatten wir eine im Wesentlichen multimediale E-Mail-Kommunikation, standardisierte Webserver und Webseiten.

HTTP erfordert, dass Daten im Kontext von E-Mail-ähnlichen Nachrichten übertragen werden, obwohl es sich bei den Daten meistens nicht um E-Mails handelt.

Mit der Weiterentwicklung dieser Technologie müssen Entwickler in die Lage versetzt werden, schrittweise neue Funktionen zu integrieren, ohne vorhandene Software zu beschädigen. Wenn beispielsweise der Spezifikation ein neuer MIME-Typ hinzugefügt wird - sagen wir JPEG -, dauert es einige Zeit, bis Webserver und Webbrowser dies implementieren. Sie zwingen JPEG nicht plötzlich in die Spezifikation und beginnen, es an alle Webbrowser zu senden. Sie ermöglichen dem Webbrowser, die unterstützten Ressourcen anzufordern, wodurch alle zufrieden sind und die Technologie voranschreitet. Benötigt ein Bildschirmleser alle JPEGs auf einer Webseite? Wahrscheinlich nicht. Sollten Sie gezwungen sein, eine Reihe von Javascript-Dateien herunterzuladen, wenn Ihr Gerät kein Javascript unterstützt? Wahrscheinlich nicht. Muss der Googlebot alle Ihre Javascript-Dateien herunterladen, um Ihre Website ordnungsgemäß zu indizieren? Nee.

Quelle: Ich habe einen ereignisbasierten Webserver wie Node.js entwickelt. Es heißt Rapid Server .

Verweise:

Weitere Lektüre:

Perry
quelle
Nun, eigentlich können wir uns um all diese Nebenprobleme kümmern (Dinge wie Cache, Content-Type-Header usw.). Es gibt Workarounds , um diese Probleme zu lösen. Und wie ich in den Kommentaren zu dem obigen Beitrag vorgeschlagen habe, können wir so etwas wie diesen Header verwenden> Cached-Resources: image.jpg; style.css; um das Caching-Problem zu lösen .. (Wenn Sie Zeit haben, dann können Sie einen Blick auf die Kommentare oben werfen ..)
Ahmed
Ja, diese Idee war mir schon früher in den Sinn gekommen, aber es ist einfach zu viel Aufwand für HTTP und löst nicht die Tatsache, dass Ressourcen auf mehrere Server verteilt sein können. Darüber hinaus glaube ich nicht, dass Ihre vorgeschlagene zeitsparende Methode tatsächlich Zeit spart, da Daten unabhängig davon, wie Sie sie betrachten, als Stream gesendet werden. Bei Keep-Alive werden 100 gleichzeitige HTTP-Anforderungen im Wesentlichen zu einer Anforderung. Die von Ihnen vorgeschlagene Technologie und Fähigkeit scheint in gewisser Weise bereits vorhanden zu sein. Siehe en.wikipedia.org/wiki/HTTP_persistent_connection
perry
@perry: Was halten Sie von der Idee einer Alternative zum https://Senden großer öffentlich verteilter Dateien, die authentifiziert, aber nicht vertraulich behandelt werden müssen: Fügen Sie in die URL einen Hash bestimmter Teile des Headers einer legitimen Antwort ein, was wiederum der Fall sein könnte Enthalten Sie entweder eine Signatur oder einen Hash der Datennutzdaten, und lassen Sie die empfangenen Daten vom Browser anhand des Headers validieren? Ein solches Design würde nicht nur einige SSL-Handshake-Schritte einsparen, sondern vor allem das Zwischenspeichern von Proxys ermöglichen. Rufen Sie die URL über einen SSL-Link ab, und die Daten können von überall eingespeist werden.
Supercat
11

Weil sie nicht wissen, was diese Ressourcen sind. Die Assets, die für eine Webseite erforderlich sind, sind im HTML-Code enthalten. Erst wenn ein Parser feststellt, um welche Assets es sich handelt, kann er vom Benutzeragenten angefordert werden.

Sobald diese Assets bekannt sind, müssen sie einzeln bereitgestellt werden, damit die richtigen Header (dh der Inhaltstyp) bereitgestellt werden können, damit der Benutzeragent weiß, wie er damit umgeht.

John Conde
quelle
2
Vor allem, wenn Sie etwas wie require.js verwenden. Der Browser fragt nur, was er benötigt. Stellen Sie sich vor, Sie müssen alles auf einmal laden ...
Aran Mulholland
2
Dies ist die richtige Antwort und eine, die den meisten Kommentatoren zu fehlen scheint. Damit der Server die Ressourcen proaktiv sendet, muss er wissen, um welche es sich handelt. Dies bedeutet, dass der Server den HTML-Code analysieren muss.
1
Aber die Frage stellt , warum der Web - Server sendet nicht über die Ressourcen, nicht , warum der Kunde kann für sie zur gleichen Zeit nicht fragen. Es ist sehr einfach, sich eine Welt vorzustellen, in der Server über ein Paket verwandter Assets verfügen, die alle zusammen gesendet werden und für deren Erstellung kein HTML-Parsing erforderlich ist.
David Meister
@DavidMeister Da der Server nicht immer weiß, was der Client will - ein Webcrawler für eine Suchmaschine kümmert sich möglicherweise nicht um CSS / JS, und es gibt viele andere Ressourcen, die in einem Dokument verknüpft sind - muss nicht der gesamte Code gesendet werden RSS-Feeds werden im Paket an einen Webbrowser gesendet (der größte Teil des Inhalts befindet sich wahrscheinlich bereits im HTML-Code), während ein Feed-Reader möglicherweise das <head>Element analysiert, das nach alternativen RSS-Links sucht, um genau das zu finden. Der Client kann eine Liste von senden was es interessiert, aber dann muss es wissen, was verfügbar ist und wir sind wieder am Anfang
Zhaph - Ben Duguid
@ Zhaph-BenDuguid Ich spreche von einer alternativen Welt, um hervorzuheben, dass die Antwort genauso viel damit zu tun hat, wie das Protokoll funktioniert, wie alles andere. Außerdem kann es für einen Server durchaus schneller sein, alle Daten auf einmal zu senden, selbst wenn dies nicht erforderlich ist. Sie tauschen im Wesentlichen Latenzprobleme gegen die Bandbreitennutzung aus.
David Meister
8

Denn in Ihrem Beispiel würde der Webserver immer CSS und Bilder senden, unabhängig davon, ob der Client bereits über diese verfügt. Dadurch würde Bandbreite stark verschwendet (und die Verbindung wird langsamer anstatt schneller, da die Latenz verringert wird, was vermutlich Ihre Absicht war). Beachten Sie, dass CSS-, JavaScript- und Bilddateien in der Regel aus genau diesem Grund mit sehr langen Ablaufzeiten gesendet werden (wenn Sie sie ändern müssen, ändern Sie einfach den Dateinamen, um eine neue Kopie zu erzwingen, die erneut für lange Zeit zwischengespeichert wird).

Jetzt können Sie versuchen, diese Bandbreitenverschwendung zu umgehen, indem Sie " OK " sagen. Der Client kann jedoch angeben, dass einige dieser Ressourcen bereits vorhanden sind, sodass der Server sie nicht erneut sendet. " So etwas wie:

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"

Und dann werden nur die Dateien, die sich nicht geändert haben, über eine TCP-Verbindung gesendet (mithilfe von HTTP-Pipelining über eine dauerhafte Verbindung). Und rate was? So funktioniert es bereits (Sie können auch If-Modified-Since anstelle von If-None-Match verwenden ).


Wenn Sie jedoch die Latenz reduzieren möchten, indem Sie viel Bandbreite verschwenden (wie in Ihrer ursprünglichen Anfrage), können Sie dies heute mit Standard-HTTP / 1.1 bei der Gestaltung Ihrer Website tun. Der Grund, warum die meisten Leute es nicht tun, ist, dass sie es nicht für wert halten.

Um dies zu tun, müssen Sie kein CSS oder JavaScript in einer separaten Datei haben. Sie können diese in die Haupt-HTML-Datei einbinden, indem Sie <style>und <script>-Tags verwenden (Sie müssen es wahrscheinlich nicht einmal manuell tun, Ihre Template-Engine kann es wahrscheinlich automatisch tun). . Sie können sogar Bilder in die HTML-Datei einbinden , indem Sie den Daten-URI wie folgt verwenden:

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

Natürlich erhöht die Base64-Codierung die Bandbreitennutzung geringfügig, aber wenn Sie sich nicht für verschwendete Bandbreite interessieren, sollte dies kein Problem sein.

Wenn es Sie wirklich interessiert, können Sie Ihre Web-Skripte sogar so intelligent gestalten, dass Sie das Beste aus beiden Welten herausholen: Senden Sie auf erste Anfrage (Benutzer hat kein Cookie) alles (CSS, JavaScript, Bilder), das in einem einzigen HTML-Code eingebettet ist Datei wie oben beschrieben, fügen Sie einen Link rel = "Prefetch" -Tags für externe Kopien der Dateien hinzu und fügen Sie ein Cookie hinzu. Hat der Benutzer bereits ein Cookie (zB das er schon einmal besucht hat), dann schicke ihm einfach ein normales HTML mit <img src="example.jpg">, <link rel="stylesheet" type="text/css" href="style.css">etc.

Beim ersten Besuch des Browsers wird also nur eine einzige HTML-Datei angefordert und alles abgerufen und angezeigt. Dann würde es (im Leerlauf) angegebenes externes CSS, JS, Images vorladen. Beim nächsten Besuch des Benutzers würde der Browser nur geänderte Ressourcen anfordern und abrufen (wahrscheinlich nur neues HTML).

Die zusätzlichen CSS + JS + -Bilddaten werden immer nur zweimal gesendet, selbst wenn Sie hunderte Male auf der Website geklickt haben. Viel besser als hunderte Male, wie von Ihrer vorgeschlagenen Lösung vorgeschlagen. Und es würde niemals (weder beim ersten noch beim nächsten Mal) mehr als eine latenzerhöhende Hin- und Rückfahrt verwenden.

Wenn das nach zu viel Arbeit klingt und Sie nicht mit einem anderen Protokoll wie SPDY arbeiten möchten , gibt es bereits Module wie mod_pagespeed für Apache, die einen Teil dieser Arbeit automatisch für Sie erledigen können (Zusammenführen mehrerer CSS / JS-Dateien) Sie können kleine CSS-Dateien automatisch in eine Zeile einfügen und diese verkleinern, kleine Bilder mit Platzhaltern in die Zeile einfügen, während Sie darauf warten, dass Originale geladen werden, Bilder verzögert geladen werden usw.), ohne dass Sie eine einzelne Zeile Ihrer Webseite ändern müssen.

Matija Nalis
quelle
3
Ich denke das ist die richtige Antwort.
el.pescado
7

HTTP2 basiert auf SPDY und macht genau das, was Sie vorschlagen:

Auf hoher Ebene ist HTTP / 2:

  • ist binär statt textuell
  • wird voll gemultiplext, statt geordnet und blockiert
  • kann daher eine Verbindung für Parallelität verwenden
  • Verwendet die Header-Komprimierung, um den Overhead zu reduzieren
  • Ermöglicht Servern, Antworten proaktiv in Client-Caches zu „pushen“

Weitere Informationen finden Sie unter HTTP 2 - Häufig gestellte Fragen

MaBu
quelle
3

Weil es nicht voraussetzt, dass diese Dinge tatsächlich benötigt werden .

Das Protokoll definiert keine spezielle Behandlung für einen bestimmten Dateityp oder Benutzeragenten. Der Unterschied zwischen beispielsweise einer HTML-Datei und einem PNG-Bild ist nicht bekannt. Um zu tun, was Sie verlangen, müsste der Webserver den Dateityp identifizieren, ihn analysieren, um herauszufinden, auf welche anderen Dateien er verweist, und dann bestimmen, welche anderen Dateien tatsächlich benötigt werden, je nachdem, was Sie vorhaben die Datei . Hier gibt es drei große Probleme.

Das erste Problem besteht darin, dass es keine standardmäßige, zuverlässige Methode zum Identifizieren von Dateitypen auf der Serverseite gibt . HTTP verwaltet sich über den Content-Type-Mechanismus, aber das hilft dem Server nicht, der dies selbst herausfinden muss (teilweise damit er weiß, was er in den Content-Type einfügt). Dateinamenerweiterungen werden weitgehend unterstützt, sind jedoch zerbrechlich und leicht zu täuschen, manchmal aus böswilligen Gründen. Dateisystem-Metadaten sind weniger anfällig, aber die meisten Systeme unterstützen sie nicht sehr gut, sodass sich die Server nicht einmal darum kümmern. Content-Sniffing (wie es einige Browser und der Unix- fileBefehl versuchen) kann robust sein, wenn Sie bereit sind, es teuer zu machen, aber robustes Sniffing ist zu teuer, um auf der Serverseite praktikabel zu sein, und billiges Sniffing ist nicht robust genug.

Das zweite Problem ist, dass das Parsen einer Datei rechnerisch teuer ist . Dies ist insofern etwas mit dem ersten verknüpft, als Sie die Datei auf verschiedene Arten analysieren müssten, wenn Sie den Inhalt zuverlässig durchsuchen möchten. Dies gilt jedoch auch, nachdem Sie den Dateityp identifiziert haben, da Sie ihn benötigen um herauszufinden, was die Referenzen sind. Dies ist nicht so schlimm, wenn Sie nur ein paar Dateien gleichzeitig bearbeiten, wie es der Browser tut, aber ein Webserver muss Hunderte oder Tausende von Anfragen gleichzeitig bearbeiten. Das summiert sich und wenn es zu weit geht, kann es die Dinge tatsächlich mehr verlangsamen, als dies bei mehreren Anfragen der Fall wäre. Wenn Sie jemals einen Link von Slashdot oder ähnlichen Websites aus besucht haben, um festzustellen, dass der Server aufgrund der hohen Auslastung quälend langsam ist, haben Sie dieses Prinzip in Aktion gesehen.

Das dritte Problem besteht darin, dass der Server nicht weiß, was Sie mit der Datei tun möchten . Ein Browser benötigt möglicherweise die Dateien, auf die im HTML verwiesen wird, jedoch möglicherweise nicht, abhängig vom genauen Kontext, in dem die Datei ausgeführt wird. Das wäre komplex genug, aber das Web bietet mehr als nur Browser: Zwischen Spinnen, Feed-Aggregatoren und Seiten-Scraping-Mashups gibt es viele Arten von Benutzeragenten, bei denen die Dateien nicht im HTML-Code referenziert werden müssen : Sie Kümmere dich nur um den HTML-Code. Das Senden dieser anderen Dateien an solche Benutzeragenten würde nur Bandbreite verschwenden.

Das Fazit ist, dass das Herausfinden dieser Abhängigkeiten auf der Serverseite mehr Mühe bereitet, als es wert ist . Stattdessen lassen sie den Kunden herausfinden, was er benötigt.

Der Löffeligste
quelle
Wenn wir ein neues Protokoll entwickeln oder ein bereits vorhandenes beheben wollen, können wir uns auf die eine oder andere Weise um all diese Probleme kümmern! Und der Webserver analysiert Dateien nur einmal und kann sie dann in Abhängigkeit von definierten Regeln klassifizieren, so dass er priorisieren kann, welche Dateien zuerst gesendet werden sollen. Etc und der Webserver muss nicht wissen, was ich tun soll Mit diesen Dateien muss es nur wissen, was zu senden ist, wann und abhängig von welchen Regeln. ..)
Ahmed
@AhmedElsobky: Was Sie meinen, klingt eher nach einer bestimmten Implementierung als nach einem Netzwerkprotokoll. Aber es muss wirklich wissen, was Sie mit den Dateien tun möchten, bevor es bestimmen kann, was gesendet werden soll. Andernfalls werden zwangsläufig Dateien gesendet, die viele Benutzer nicht möchten. Sie können User-Agent-Zeichenfolgen nicht vertrauen, daher können Sie sie nicht verwenden, um die Absicht des Benutzers zu bestimmen.
The Spooniest