Detaillierte Erläuterung zum Einrichten des Ressourcencaches in Nginx

Ich wollte schon immer etwas über Caching lernen. Schließlich spielt der Cache eine große Rolle bei der Front-End-Leistungsoptimierung. Es gibt zwei Cache-Typen: obligatorischen Cache und ausgehandelten Cache. Ich habe viele Artikel über die Unterschiede zwischen ihnen gelesen, aber ich habe sie nie in der Praxis verwendet. Ich kenne nur ihre Bedeutung, weiß aber nicht, wie man sie einstellt. Der Mangel an praktischer Erfahrung führt auch zu einer vagen Erinnerung. Übung ist der beste Lehrmeister! Lassen Sie mich meinen Prozess des Cache-Lernens mithilfe des Nginx-Servers aufzeichnen.

Vorstudie

Zuerst habe ich im Stammverzeichnis von nginx eine neue Datei index.html und index.js erstellt. An diesem Punkt sieht die nginx -Konfigurationsdatei folgendermaßen aus:

Server {
 hören Sie 8080;
 Servername localhost;
 Standort / {
  root /Volumes/meineDatei/nginx_root; 
  Index Index.html Index.htm;
 }
}

Anschließend öffnen wir den Browser und rufen localhost:8080 auf. Öffnen Sie die Konsole und suchen Sie nach zwei Anfragen:

Sie können sehen, dass beim ersten Zugriff die Statuscodes beider Anfragen 200 lauten. Klicken wir auf eine der Anfragen, um die Informationen im Antwortheader anzuzeigen:

Wie Sie sehen, enthält der Antwortheader Etag und Last-Modified -Informationen. Dies ist das vom Verhandlungscache verwendete Feld. Es scheint, dass Nginx standardmäßig den Cache für uns verwendet hat. Anschließend aktualisieren wir die Seite erneut, um dies zu überprüfen, ohne die HTML- und JS-Datei zu ändern. Wenn der Verhandlungscache erreicht wird, sollte der Statuscode 304 Not Modified an uns zurückgeben. Ich habe mehrmals aktualisiert, um den Statuscode der HTTP-Anfrage zu beobachten. Die HTML-Datei gibt jedes Mal 304 zurück. Aber die js-Datei hatte zunächst den Wert 304, wurde später aber zu 200 OK (from memory cache) . Das heißt, jedes Mal, wenn die HTML-Datei auf den Verhandlungscache trifft, trifft die JS-Datei auf den starken Cache (die Priorität des starken Cache ist höher als die des Verhandlungscache). Warum passiert das? Ich habe auf Baidu gesucht:

Warum zeigen einige Caches „200 OK (aus Cache)“ und andere „304 Nicht geändert“ an? Das ist ganz einfach: Prüfen Sie einfach, ob das Entity-Tag entfernt wurde. Wenn es entfernt wird, ist es immer 200 OK (aus dem Cache). Ohne Entfernung werden die beiden abwechselnd angezeigt.

Worin besteht also der Unterschied im Timing der beiden Auslöser? 200 OK (aus Cache) wird durch direktes Klicken auf einen Link oder durch Eingeben einer URL und Drücken der Eingabetaste ausgelöst. 304 Nicht geändert wird ausgelöst, wenn die Seite aktualisiert wird oder wenn ein starker Cache festgelegt ist, die Entity-Tags jedoch nicht entfernt werden.

Im Gegensatz zu meinem Beispiel verstehe ich es so: Die Datei index.html aktualisiert die Seite und trifft auf den Verhandlungscache, wobei 304 zurückgegeben wird, während die js-Datei in der Datei index.html verknüpft ist und daher auf den starken Cache 200 OK (aus dem Cache) trifft. Um meine Idee zu überprüfen, habe ich über die Adressleiste direkt auf die Datei index.js zugegriffen. Geben Sie in die Adressleiste ein: localhost:8080/index.js. Es gibt mir 304 zurück. Schauen wir uns jetzt den Anforderungsheader an:

Sie können sehen, dass Cache-Control zu diesem Zeitpunkt max-age=0 ausgibt; und es überträgt auch die relevanten Parameter des ausgehandelten Caches. Es scheint, dass der Browser beim Aktualisieren Cache-Control:max-age=0 verwendet, um eine Belastung des starken Caches zu vermeiden.

nginx deaktiviert starken Cache

Mal sehen, was passiert, nachdem wir versucht haben, das starke Caching in nginx zu deaktivieren. Ändern Sie die Nginx -Konfigurationsdatei:

Server {
 hören Sie 8080;
 Servername localhost;
 Standort / {
  root /Volumes/meineDatei/nginx_root; 
  Index Index.html Index.htm;
  add_header Cache-Steuerung kein Cache;
  # öffentlich kann von jedem Objekt zwischengespeichert werden, privat kann nur von einzelnen Benutzern zwischengespeichert werden und kann nicht von Proxyservern zwischengespeichert werden add_header Cache-Control privat;
 }
}

Nachdem wir die Nginx -Konfigurationsdatei geändert haben, starten wir den Nginx -Server neu. Besuchen Sie jetzt localhost:8080

Wie Sie sehen, weisen sowohl die HTML-Datei als auch die JS-Datei zu diesem Zeitpunkt den Fehler 304 auf und treffen beide auf den Verhandlungscache.

Cache-Steuerung: kein Speichern

Deaktivieren Sie das gesamte Caching (das bedeutet, dass die Antwort nicht zwischengespeichert wird). Ein Cache verhält sich normalerweise wie ein Proxyserver ohne Cache, indem er eine No-Store-Antwort an den Client weiterleitet und dann das Objekt löscht.

Cache-Steuerung: kein Cache

Erzwingen Sie, dass der Client Anfragen direkt an den Server sendet, d. h. jede Anfrage muss an den Server gesendet werden. Der Server empfängt die Anforderung und ermittelt dann, ob sich die Ressource geändert hat. Wenn ja, gibt er den neuen Inhalt zurück. Andernfalls gibt er 304 zurück, was bedeutet, dass sich die Ressource nicht geändert hat. Dies kann leicht irreführend sein und die Leute zu der Annahme verleiten, dass die Antwort nicht zwischengespeichert wird. Tatsächlich wird Cache-Control: no-cache zwischengespeichert, aber jedes Mal, wenn die Antwortdaten dem Client (Browser) bereitgestellt werden, muss der Cache die Gültigkeit der zwischengespeicherten Antwort vom Server auswerten.

Tatsächlich bedeutet das Setzen von Cache-Control auf „no-store“ tatsächlich, dass nicht zwischengespeichert wird. Ändern Sie dann die Nginx- Datei und setzen Sie Cache-Control auf „no-store“, um zu sehen, was passiert. Aktualisieren Sie an dieser Stelle Ihren Browser erneut.

Es ist ersichtlich, dass nach der Änderung der Nginx -Konfigurationsdatei mit Ausnahme des ersten Mals, als 304 angezeigt wurde (der Browser hat diesmal nur die No-Store-Information erhalten und der Anforderungsheader enthielt noch Cache-bezogene Informationen), die verbleibenden paar Aktualisierungen der Seite alle 200 zurückgaben. Weder der starke Cache noch der Verhandlungscache werden getroffen. Werfen wir einen Blick auf die HTTP-Header-Informationen der Datei index.js .

Ich habe hier nicht das gesamte Bild erfasst. Tatsächlich enthält der Antwortheader auch Cache-Control: no-store . Es ist ersichtlich, dass mit der Unterstützung von Cache-Control: no-store der Browser beim Anfordern von Ressourcen die Cache-bezogenen Parameter nicht mitbringt, selbst wenn der Dienst die Verhandlungscache-Parameter im Antwortheader zurückgibt. Daher gibt es jetzt keinen Cache und weder der starke Cache noch der Verhandlungscache werden getroffen. Die Ressourcen jeder HTTP-Anforderung werden vom Server zurückgegeben.

Abschluss

Diese Erkundung ist nun beendet. Tatsächlich ist es nur eine Aufzeichnung meiner Lernerfahrungen. Nachdem ich es einmal geübt habe, habe ich ein klareres Verständnis und eine bessere Wahrnehmung von Cache. Es stimmt, dass Übung den Meister macht. Später möchte ich einen Artikel darüber schreiben, wie man mit nginx Front-End-Ressourcen bereitstellt und zugehörige Caches konfiguriert, nachdem das Front-End mit Frameworks wie React.js oder Vue.js gepackt wurde. Ich werde dann sehen, ob es Sinn macht, ihn aufzuzeichnen.

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, er wird für jedermanns Studium hilfreich sein. Ich hoffe auch, dass jeder 123WORDPRESS.COM unterstützen wird.