Detaillierte Erläuterung des Browser-Negotiation-Cache-Prozesses basierend auf nginx

Dieser Artikel stellt hauptsächlich den detaillierten Prozess zum Einrichten des Browser-Negotiation-Cache basierend auf nginx vor. Der Beispielcode in diesem Artikel ist sehr detailliert und hat einen gewissen Referenzwert für jedermanns Studium oder Arbeit. Freunde in Not können darauf zurückgreifen.

Der Unterschied zwischen starkem Caching und ausgehandeltem Caching

Starkes Caching: Der Browser verhandelt nicht mit dem Server und greift direkt auf den Browser-Cache zu

Ausgehandeltes Caching: Der Browser bestätigt zunächst die Gültigkeit der Ressource beim Server, bevor er entscheidet, ob er die Ressource aus dem Cache holt oder erneut abruft.

Funktionsweise des Verhandlungscache

Nun gibt es ein Geschäftsszenario wie dieses: Die statischen Ressourcen im Backend werden von Zeit zu Zeit aktualisiert, und da der Browser standardmäßig einen starken Cache verwendet, werden veraltete Ressourcen standardmäßig aus dem Browser-Cache abgerufen.

Jetzt möchten wir, dass der Browser bei jedem Abrufen der Ressource beim Backend bestätigt, ob die Ressource aktualisiert wird. Daher müssen wir den Browser so einstellen, dass er den ausgehandelten Cache verwendet.

Wie bestimmt das Backend, ob die Ressource aktualisiert wurde? Zu diesem Zeitpunkt werden die beiden Antwortheader Etag und Last-Modified verwendet.

Jedes Mal, wenn eine Anforderung für eine statische Ressource eingeht, übergibt das Backend den Zeitpunkt der letzten Änderung der Ressource (Last-Modified) und den basierend auf dem Ressourceninhalt berechneten ETag an das Frontend im Antwortheader.

Nach dem Erhalt der Antwort speichert das Front-End diese beiden Elemente im Cache und fügt den Inhalt dieser beiden Elemente dann bei der nächsten Anforderung derselben Ressource in die Anforderungsheader „If-Modified-Since“ und „If-None-Match“ ein.

Nach dem Empfang dieser beiden Elemente vergleicht der Server sie mit dem aktuell von der Ressource generierten Etag und Last-Modified. Wenn die beiden übereinstimmen, bedeutet dies, dass die Ressource nicht aktualisiert wurde, und der Server gibt eine leere 304-Antwort zurück. Andernfalls bedeutet dies, dass die Ressource aktualisiert wurde, und der Server gibt den vollständigen Ressourceninhalt zurück.

erreichen

Wie lässt sich also ein so komplexer Prozess implementieren? Eigentlich ist es ganz einfach. Verwenden Sie einfach nginx als Server für statische Ressourcen und fügen Sie dem Antwortheader Cache-Control: no-cache hinzu.

Lassen Sie es uns Schritt für Schritt umsetzen

1. Verwenden Sie nginx als statischen Ressourcenserver

Ordnen Sie in der Nginx-Konfiguration Anfragen für statische Ressourcen dem Datenträgerpfad der Ressource zu.

http {
  Server {
  hören Sie 80;
  ...
  Standort /Bild/ {
    Alias ​​D:/luozixi/tcp_test/Bild/;
    # Alias ​​ist ein neu definierter Pfad# Wenn Sie beispielsweise auf 127.0.0.1/picture/1_new.gif zugreifen, wird der Zugriff auf D:/luozixi/tcp_test/picture/1_new.gif abgebildet.
    # Die Webanwendung erhält überhaupt keine Anfragen und alle Anfragen für Bilder werden von nginx verarbeitet. # Alias ​​ist ein Ersatz, Root ist eine Verkettung mit Autoindex.
    # Besuchen Sie 127.0.0.1/picture/, Sie erhalten die Verzeichnisindex-Schnittstelle}
  }
}

2. Nginx-Konfiguration neu laden

nginx -s neu laden

3. Wenn zu diesem Zeitpunkt statische Ressourcen angefordert werden, fügt nginx dem Antwortheader automatisch Etag und Last-Modified hinzu

4. Dann habe ich jedoch festgestellt, dass der Browser bei der nächsten Anforderung dieser Ressource die Anforderung nicht an das Backend sendet, wenn Cache-Contrl: no-cache nicht konfiguriert ist, sondern die Ressource direkt aus dem Cache bezieht

5. Konfiguration in nginx

Standort /Bild/ { 
  add_header Cache-Steuerung kein Cache;
  Alias ​​D:/luozixi/tcp_test/Bild/; 
}

6. Nach dem Leeren des Browser-Cache erhält die erste Anfrage eine normale 200-Antwort, und der Antwortheader enthält bereits Cache-Control: no-cache, was darauf hinweist, dass der ausgehandelte Cache verwendet wird.

7. Nachdem Sie die Anforderung erneut initiiert haben, werden Sie feststellen, dass der Anforderungsheader zwei Elemente enthält: If-Modified-Since und If-None-Match

8. Nach dem Empfang dieser beiden Elemente vergleicht der Server (nginx) sie mit dem aktuell von der Ressource generierten Etag und Last-Modified. Wenn die beiden übereinstimmen, bedeutet dies, dass die Ressource nicht aktualisiert wurde, und der Server gibt eine leere 304-Antwort zurück. Andernfalls bedeutet dies, dass die Ressource aktualisiert wurde, und der Server gibt den vollständigen Ressourceninhalt zurück.

Darüber hinaus überprüft der Server If-Modified-Since nur durch einen einfachen Zeichenfolgenvergleich. Selbst wenn Last-Modified der Ressource vor If-Modified-Since liegt, betrachtet der Server die Ressource dennoch als aktualisiert.

9. Nach Erhalt der 304-Antwort ruft der Browser die Ressource aus dem Browser-Cache ab. Die Geschwindigkeit ist also sehr schnell

Der Unterschied zwischen No-Cache und No-Store

no-cache bedeutet, dass abgelaufene Ressourcen nicht zwischengespeichert werden. Der Cache verarbeitet die Ressource nach einer gültigen Verarbeitungsbestätigung vom Server.

Und „kein Store“ bedeutet „kein Caching“.

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.