Stellen Sie einen Varnish-Cache-Proxyserver basierend auf Centos7 bereit

1. Lackübersicht

1. Einführung in Varnish

Varnish ist ein leistungsstarker Open-Source-Reverse-Proxy-Server und HTTP-Beschleuniger, der eine neue Softwarearchitektur verwendet und eng mit aktuellen Hardwaresystemen zusammenarbeitet. Im Vergleich zum herkömmlichen Squid bietet Varnish die Vorteile einer hohen Leistung, hohen Geschwindigkeit und einfacheren Verwaltung. Derzeit versuchen viele große Websites, Squid durch Varnish zu ersetzen. Dies ist der grundlegendste Grund für die rasante Entwicklung von Varnish.

Hauptmerkmale von Varnish:

(1) Cache-Proxy-Speicherort: Es kann entweder der Speicher oder die Festplatte verwendet werden.
(2) Protokollspeicherung: Protokolle werden im Speicher abgelegt;
(3) Unterstützt die Verwendung des virtuellen Speichers;
(4) Es gibt einen präzisen Zeitverwaltungsmechanismus, nämlich die Zeitattributsteuerung des Caches.
(5) State-Engine-Architektur: Unterschiedliche Cache- und Proxy-Daten werden auf unterschiedlichen Engines verarbeitet.
(6) Cache-Verwaltung: Verwenden Sie einen binären Heap, um Cache-Daten zu verwalten und eine rechtzeitige Datenbereinigung sicherzustellen.

2. Vergleich und Ähnlichkeiten zwischen Varnish und Squid

• Bei allen handelt es sich um Open-Source-Software.
• Es ist ein Reverse-Proxy-Server;

Vorteile von Lack

(1) Stabilität: Wenn Varnish und Squid dieselbe Arbeitslast bewältigen, ist die Wahrscheinlichkeit eines Serverausfalls bei Squid höher als bei Varnish, da Squid häufig neu gestartet werden muss.
(2) Schnellere Zugriffsgeschwindigkeit: Alle zwischengespeicherten Daten von Varnish werden direkt aus dem Speicher gelesen, während Squid von der Festplatte liest;
(3) Unterstützt mehr gleichzeitige Verbindungen: Da die TCP-Verbindungs- und Freigabegeschwindigkeit von Varnish viel schneller ist als die von Squid

Nachteile von Lack

(1) Sobald der Varnish-Prozess neu gestartet wird, werden die zwischengespeicherten Daten vollständig aus dem Speicher freigegeben. Zu diesem Zeitpunkt werden alle Anforderungen an den Backend-Server gesendet. Bei hoher Parallelität wird der Backend-Server stark belastet.
(2) Wenn bei Verwendung von Varnish eine einzelne URL-Anforderung über den Lastenausgleich verwendet wird, fällt jede Anforderung auf einen anderen Varnish-Server, sodass alle Anforderungen an den Back-End-Server gesendet werden. Außerdem wird dieselbe Qin-GUI auf mehreren Servern zwischengespeichert, wodurch auch die Cache-Ressourcen von Varnish verschwendet werden und die Leistung beeinträchtigt wird.

Lösungen für die Nachteile von Lacken

Zu Nachteil 1: Bei großem Datenverkehr empfiehlt es sich, den Speichercache-Modus von Varnish zu verwenden, und es müssen mehrere Squid/nginx-Server folgen. Dies dient hauptsächlich dazu, zu verhindern, dass eine große Anzahl von Anforderungen Varnish durchdringt, wenn der vorherige Varnish-Dienst oder -Server neu gestartet wird. Auf diese Weise kann Squid / nginx als Cache der zweiten Ebene fungieren und auch das Problem ausgleichen, dass der Varnish-Cache im Speicher beim Neustart freigegeben wird.
Zum zweiten Nachteil: Sie können URL-Hashing auf dem Load Balancer durchführen, um eine einzelne URL-Anfrage an einen Varnish-Server zu senden.

3. Wie Varnish funktioniert

Wenn der Varnish-Server eine Anfrage von einem Client erhält, prüft er zunächst, ob sich Daten im Cache befinden. Ist dies der Fall, antwortet er direkt dem Client. Ist dies nicht der Fall, fordert er die entsprechende Ressource vom Backend-Server an, speichert sie lokal auf dem Varnish-Server im Cache und antwortet dann dem Client.

Wählen Sie anhand der Regeln und des Typs der angeforderten Seite aus, ob die Daten zwischengespeichert werden müssen. Sie können anhand des Cache-Contorl im Anforderungsheader und anhand der Markierung des Cookies bestimmen, ob zwischengespeichert werden soll. Diese Funktionen können durch das Schreiben von Konfigurationsdateien implementiert werden.

4. Lackieren Sie einfache Architektur

Varnish ist in Verwaltungsprozess und Kindprozess unterteilt

• Verwaltungsprozess: verwaltet untergeordnete Prozesse, kompiliert VCL-Konfigurationen und wendet sie auf verschiedene Status-Engines an;
• Untergeordneter Prozess: Generiert einen Thread-Pool, der für die Verarbeitung von Benutzeranforderungen und die Rückgabe von Benutzerergebnissen durch Hash-Suche verantwortlich ist.

Gemeinsame Threads, die von untergeordneten Prozessen generiert werden, sind

• Accept-Thread: empfängt neue Verbindungsanfragen und antwortet;
• Arbeitsthread: Sitzung, Verarbeitung von Anforderungsressourcen;
• Ablaufthread: löscht abgelaufene Inhalte im Cache;

5. Hauptkonfigurationsteil von Varnish

• Backend-Konfiguration: Fügen Sie Varnish mindestens einen Reverse-Proxy-Server-Knoten hinzu;
• ACL-Konfiguration: Fügen Sie Varnish Zugriffskontrolllisten hinzu und geben Sie den Zugriff bzw. das Zugriffsverbot durch diese Listen an;
• Prüfkonfiguration: Fügen Sie Varnish Regeln hinzu, um zu erkennen, ob der Backend-Server normal ist, um das Umschalten oder Deaktivieren des entsprechenden Backend-Servers zu erleichtern.
• Directors-Konfiguration: Fügen Sie Varnish einen Lastausgleichsmodus hinzu, um mehrere Backend-Server zu verwalten;
• Konfiguration der Kernunterprogramme: Fügen Sie Varnish Backend-Server-Switching, Anforderungs-Caching, Zugriffskontrolle, Fehlerbehandlung und andere Regeln hinzu.

6. VCL verfügt über integrierte voreingestellte Variablen: Variablen (auch Objekte genannt):

Wie gezeigt

(1) req: Variablen, die verfügbar sind, wenn der Client den Varnish-Server anfordert;
(2) bereq: Der Varnish-Server fordert die auf dem Backend-Server verfügbaren Variablen an;
(3) beresp: Die Variable, die verwendet wird, wenn der Backend-Server auf die Varnish-Serveranforderung antwortet und das Ergebnis zurückgibt;
(4) resp: Die Variable, die vom Varnish-Server verwendet wird, um auf die Client-Anfrage zu antworten;
(5) obj: Cache-Objekt, das den Inhalt der Antwortanforderung im Cache des Backends speichert;
(6) now: gibt den aktuellen Zeitstempel zurück;

Kunde

Clientet.ip: Gibt die IP-Adresse des Clients zurück
Client.port: Ruft die vom Client angeforderte Portnummer ab (in Vatnish 4.0 und höher müssen Sie das std-Modul aufrufen, um sie zu verwenden). Die Syntax lautet import std; std.port(client.ip)
Client.identiy Holen Sie sich den Client-Identifikationscode. Die Software generiert während des Installationsvorgangs eine Seriennummer zur Identifizierung der Identität.

Server

Server.hostname: Server-Hostname
Server.identiy: Den Server-Identifikationscode abrufen
Server.ip: Holen Sie sich die Server-IP-Adresse
Server.prot: Holen Sie sich die Server-IP-Portnummer, Sie müssen das Standardmodul aufrufen

Clientanforderung req (das von der Clientanforderung gesendete Objekt)

• Req: Die Datenstruktur der gesamten Anfrage
• req.bachend_hint: Gibt den Anforderungs-Backend-Knoten an, z. B. GIF an den Bildserver.
• Req.can_gzip: Ob der Client die GZIP-Übertragungskodierung akzeptiert (normalerweise unterstützen Browser alle Komprimierungsformate)
• req.hash_always_miss: ob Daten aus dem Cache gelesen werden sollen
• req.hash_ignore_busy: Ignoriere ausgelastete Daten-Deadlocks im Cache (z. B. wenn zwei Varnish-Server während der Verarbeitung um eine Ressource konkurrieren und dadurch eine Blockade verursachen. Wenn der Deadlock nicht manuell gestoppt wird, bleibt er bestehen).
• req.http: entspricht dem Header der http-Anfrage
• req.method: Anfragetyp oder Anfragemethode (wie etwa gt, post)
• req.proto: Die von der Client-Anforderung verwendete Version des HTTP-Protokolls
• req.restarts: Die Anzahl der Neustarts. Der standardmäßige Maximalwert ist 4 (wird normalerweise verwendet, um festzustellen, ob auf den Server zugegriffen wurde).
• req.url: angeforderte URL
• req.xid: eindeutige ID. Beim Zugriff durch den Varnish-Server wird X-Varnish zum Header hinzugefügt. Die Zahl dahinter ist die ID von Varnish. Die ersten Daten sind die Identifikations-ID der Anfrage und die zweiten Daten sind die Identifikations-ID des Caches.

Varnish fordert den Backend-Server (bereq) an

• bereq: Datenstruktur der gesamten Backend-Anfrage
• bereq.backend: Konfiguration des angeforderten Backend-Knotens
• bereq.between_bytes_timeout: Die Wartezeit oder das Timeout zwischen jedem vom Backend empfangenen Byte
• bereq.http: entspricht den an das Backend gesendeten HTTP-Headerinformationen
• bereq.method: Der Anforderungstyp oder die Methode, die an das Backend gesendet wird
• bereq.proto: Die HTTP-Protokollversion der an das Backend gesendeten Anfrage
• bereq.retires: Gleiche Anzahl von Wiederholungsversuchen für Anfragen
• bereq.uncacheable: Die Anforderungsdaten werden nicht zwischengespeichert oder die Anforderung wird nicht zwischengespeichert
• bereq.url: Die an die Backend-Anfrage gesendete URL
• bereq.xid: eindeutige ID anfordern

Der Backend-Server gibt Daten an Varnish beresq zurück

• Beresp: Antwortdaten des Backend-Servers
• Beresp.backend.ip: IP-Adresse des Backend-Antwortservers (Verarbeitung der Anforderungsdaten)
• Beresp.backend.name: der Knotenname des Backend-Antwortservers
• Beresp.do_gunzip: Standardmäßig auf „false“ eingestellt, dekomprimieren Sie das Objekt vor dem Zwischenspeichern
• Beresp.grace: Zusätzliche Nachfrist für das Ablaufen des Cache festlegen
• Beresp.http: http-Header in der Antwort
• Beresp.keep: Objekt-Cache mit Aufbewahrungszeit
• Beresp.proto: http-Version der Antwort
• Beresp.reason: Vom Backend-Server zurückgegebene HTTP-Statusinformationen
• Beresp.status: Der vom Backend-Server zurückgegebene Statuscode
• Beresp.storage_hint: Gibt den spezifischen Speicher an, der gespeichert werden soll
• Beresp.ttl: Ändern Sie die verbleibende Zeit des Objektcaches und geben Sie die verbleibende Zeit des einheitlichen Caches an
• Beresp,uncacheable: Daten nicht zwischenspeichern

Lagerung

• Storage.<name>.free_space: Verfügbarer Speicherplatz (Bytes)
• Storage.<name>.used_space: Verbleibende Speicherzeit (Bytes)
• Storage.<name>.happy: Status des Speicherknotens
• deliver sendet Daten an den Client und die zurückgegebenen Daten
• fetch holt Daten vom Backend und speichert sie lokal im Cache.

7. Spezifische Funktionsanweisungen

• Ban(Ausdruck): Löscht den angegebenen Objektcache.
• Call(Subroutine): ruft eine Subroutine auf;
• Hash_data(input): Generiert Hash-Schlüssel basierend auf dem Wert der Eingabe-Subroutine;
• New(): Erstellt ein neues VCL-Objekt, das nur im vcl_init-Subprozess verwendet werden kann.
• Return(): Beenden Sie die aktuelle Subroutine und geben Sie den nächsten Schritt an.
• Rollback(): stellt den HTTP-Header in seinen ursprünglichen Zustand zurück. Diese Funktion ist veraltet. Verwenden Sie stattdessen std.rollback().
• Synthetisch (STRING): Synthesizer, definiert den Seiten- und Statuscode, der an den Client zurückgegeben wird;
• Regsub(str, regex, sub) ersetzt das erste Vorkommen einer Zeichenfolge durch einen regulären Ausdruck;
• Regsuball(str, regex, sub) ersetzt alle Vorkommen einer Zeichenfolge;

8. Schritte zur Verarbeitung von Varnish-Anfragen

Wie gezeigt

Schritte zur Verarbeitung von Varnish-Anfragen

Empfangsstatus (vcl_recv). Das heißt, der Eintrittsstatus der Anforderungsverarbeitung. Gemäß den VCL-Regeln wird bestimmt, ob die Anforderung durchgelassen (vcl_pass) oder weitergeleitet (vcl_pipe) werden oder in die Suche (lokale Abfrage) eintreten soll.
Nachschlagestatus. Nach dem Eintritt in diesen Status werden die Daten in der Hash-Tabelle gesucht. Wenn sie gefunden werden, treten sie in den Trefferstatus (vcl_hit) ein, andernfalls treten sie in den Fehlschlagstatus (vcl_miss) ein.
Status „Bestanden“ (vcl_pass). In diesem Status wird die Backend-Anforderung direkt eingegeben, dh der Abrufstatus (vcl_fetch)
Status abrufen (vcl_fetch). Im Abrufzustand wird die Anforderung vom Backend abgerufen, die Anforderung gesendet, die Daten abgerufen und die Daten gemäß den Einstellungen lokal gespeichert.
Lieferstatus (vcl_deliver). Senden Sie die erfassten Daten an den Client und schließen Sie die Anfrage ab.
Rohrstatus. Stellen Sie eine direkte Verbindung zwischen dem Client und dem Server her, um Daten vom Backend-Server abzurufen

Die Subroutine vcl_recv: startet die Verarbeitung der Anforderung über die Rückgabe (Aktion);
vcl_pipe-Subroutine: Pipe-Modus-Verarbeitung, die hauptsächlich verwendet wird, um den Backend-Antwortinhalt direkt abzurufen und an den Client zurückzugeben. Der Antwortinhalt kann definiert und an den Client zurückgegeben werden.
vcl_pass-Subroutine: Verarbeitung im Pass-Modus, der dem Hash-Cache-Modus ähnelt, jedoch ohne Cache-Verarbeitung.
vcl_hit-Subroutine: Wird im Hash-Cache-Modus aufgerufen, wenn ein Hash-Cache vorhanden ist, wird für die Cache-Verarbeitung verwendet und kann den Cache verlassen oder ändern.
vcl_miss-Subroutine: Wird im Hash-Cache-Modus aufgerufen, wenn kein Hash-Cache vorhanden ist. Sie wird verwendet, um zu entscheiden, ob das Backend aufgerufen werden soll, um den Antwortinhalt abzurufen. Sie kann in den Pass-Modus geändert werden.
vcl_hash-Subroutine: Hash-Cache-Modus, generiert Hash-Werte als Cache-Lookup-Schlüsselnamen, um Cache-Inhalte zu extrahieren, wird hauptsächlich für die Verarbeitung von Cache-Hash-Schlüsselwerten verwendet, hash_data (Zeichenfolge) kann verwendet werden, um die Schlüsselwert-Zusammensetzungsstruktur anzugeben, und über IP oder Cookie können auf derselben Seite unterschiedliche Cache-Schlüsselwerte generiert werden.
vcl_purge-Subroutine: Bereinigungsmodus, löscht und ruft auf, wenn der entsprechende Cache gefunden wird, und wird verwendet, um die Methode zum Löschen des Caches und zum Melden anzufordern
vcl_deliver-Subroutine: Client-Übermittlungssubroutine, die nach der vcl_backend_response-Subroutine (Nicht-Pipe-Modus) oder nach der vcl_hit-Subroutine aufgerufen wird und zum Anhängen von Antwortheaderinformationen, Cookies usw. verwendet werden kann.
Unterroutine vcl_backend_fetch: Wird vor dem Senden einer Backend-Anforderung aufgerufen und kann verwendet werden, um die Anforderungsadresse oder andere Informationen zu ändern oder die Anforderung abzubrechen.
vcl_backend_response-Subroutine: Wird aufgerufen, nachdem das Backend geantwortet hat. Kann verwendet werden, um die Cache-Zeit und Cache-bezogene Informationen zu ändern.
vcl_backend_error-Subroutine: Fehleraufruf der Backend-Verarbeitung, Verarbeitung abnormaler Seitenanzeigeeffekte. Sie können den Inhalt der Fehlerantwort anpassen oder die Umleitung von beresp.status und beresp.http.Location usw. ändern.
vcl_synth-Unterroutine: Antwortinhalt anpassen. Es kann über synthetic() und den Rückgabewert synth aufgerufen werden. Hier können Sie den Inhalt der Ausnahmeanzeige anpassen und auch die Umleitung von resp.status und resp.http.Location ändern.
vcl_init-Subroutine: Wird zuerst aufgerufen, wenn vcl geladen wird. Sie wird zum Initialisieren von VMODs verwendet. Diese Subroutine nimmt nicht an der Anforderungsverarbeitung teil und wird nur einmal aufgerufen, wenn vcl geladen wird.
vcl_fini-Subroutine: Wird aufgerufen, wenn die aktuelle Vcl-Konfiguration deinstalliert wird, um VMODs zu bereinigen. Diese Subroutine nimmt nicht an der Anforderungsverarbeitung teil und wird nur aufgerufen, nachdem Vcl normal verworfen wurde.

2. Varnish installieren

Link zum Herunterladen des Varnish-Pakets: https://pan.baidu.com/s/1OfnyR-5xFuxMUYJTnhQesA Extraktionscode: m9q4

Zusätzlich zu einem Varnish-Server können Sie zwei weitere Webserver eröffnen, um Webseiten bereitzustellen.

[root@localhost ~]# yum -y installiere autoconf automake libedit-devel libtool ncurses-devel pcre-devel pkgconfig python-docutils python-sphinx
[root@localhost ~]# tar zxf varnish-4.0.3.tar.gz 
[root@localhost ~]# cd varnish-4.0.3/
[root@localhost varnish-4.0.3]# ./configure && make && make install
[root@localhost varnish-4.0.3]# cp etc/example.vcl /usr/local/var/varnish/
//Kopieren Sie die Varnish-Hauptkonfigurationsdatei [root@localhost /]# vim /usr/local/var/varish/example.vcl 
//Bearbeiten Sie die Varnish-Masterkonfiguration, um die ursprüngliche Änderung vcl 4.0 anzuzeigen.
Importdirektoren;
std importieren;
Backend-Standard {
  .host = "127.0.0.1";
  .port = "80";
}
Probe backend_healthcheck {
    .url="/";
    .Intervall = 5s;
    .Zeitüberschreitung = 1s;
    .Fenster = 5;
    .Schwellenwert = 3;
}
Backend web1 {
    .host = "192.168.148.132";
    .port = "80";
    .probe = backend_healthcheck;
}
Backend Web2 {
    .host = "192.168.148.133";
    .port = "80";
    .probe = backend_healthcheck;
}
ACL-Plünderer {
    "127.0.0.1";
    "lokaler Host";
    "192.168.148.0/24";
    !"192.168.148.133";
}
unter vcl_init {
    neuer Webcluster = Direktoren.round_robin();
    web_cluster.add_backend(web1);
    web_cluster.add_backend(web2);
}
//Lösche alle Originale und füge das folgende Sub vcl_recv { hinzu.
    setze req.backend_hint = web_cluster.backend();
    wenn (req.method == "PURGE") {
        wenn (!client.ip ~ purgers) {
            return (synth(405, "Nicht zulässig."));
    }
    zurückgeben (bereinigen);
}
wenn (req.method != "GET" &&
    req.method != "HEAD" &&
    Anforderungsmethode != "PUT" &&
    Anforderungsmethode != "POST" &&
    Anforderungsmethode != "TRACE" &&
    req.method != "OPTIONEN" &&
    req.method != "PATCH" &&
    req.method != "LÖSCHEN") {
        Rücklauf (Rohr);
    }
wenn (req.method != "GET" und req.method != "HEAD") {
    Rückpass);
}
wenn (req.url ~ "\.(php|asp|aspx|jsp|do|ashx|shtml)($|\?)") {
    Rückpass);
}
wenn (req.http.Accept-Encoding) {
    if (req.url ~ "\.(bmp|png|gif|jpg|jpeg|ico|gz|tgz|bz2|tbz|zip|rar|mp3|mp4|ogg|swf|flv)$") {
    req.http.Accept-Encoding aufheben;
} elseif (req.http.Accept-Encoding ~ "gzip") {
        setze req.http.Accept-Encoding = "gzip";
    } elseif (req.http.Accept-Encoding ~ "deflate") {
        setze req.http.Accept-Encoding = "deflate";
    } anders {
    req.http.Accept-Encoding aufheben;
    }
   }
if (req.url ~ "\.(css|js|html|htm|bmp|png|gif|jpg|jpeg|ico|gz|tgz|bz2|tbz|zip|rar|mp3|mp4|ogg|swf|flv)($|\?)") {
    req.http.cookie nicht gesetzt;
    Rückgabe (Hash);
}
wenn (req.restarts == 0) {
    wenn (req.http.X-Forwarded-For) {
        setze req.http.X-Forwarded-For = req.http.X-Forwarded-For + ", " + client.ip;
    } anders {
    setze req.http.X-Forwarded-For = client.ip;
    }
}
Rückgabe (Hash);
}
sub vcl_hash {
    hash_data(erforderliche URL);
    wenn (req.http.host) {
    hash_data(req.http.host);
    } anders {
        hash_data(server.ip);
    }
    zurückgeben (nachschlagen);
}
unter vcl_hit {
    wenn (req.method == "PURGE") {
        return (synth(200, "Gelöscht."));
    }
    zurückgeben (liefern);
}
unter vcl_miss {
  wenn (req.method == "PURGE") {
        return (synth(404, "Gelöscht."));
    }
    zurückgeben (holen);
}
unter vcl_deliver {
    if (Objekttreffer > 0) {
        setze resp.http.CXK = "HIT-aus-Lack";
        setze resp.http.X-Cache-Hits = obj.hits;
    } anders {
    setze resp.http.X-Cache = "MISS";
    }
    nicht gesetzt bzw. http.X-Powered-By;
    nicht gesetzt bzw. http.Server;
    nicht gesetzt bzw. http.X-Drupal-Cache;
    nicht gesetzt bzw. http.Via;
    nicht gesetzt bzw. http.Link;
    nicht gesetzt bzw. http.X-Varnish;
    setze resp.http.xx_restarts_count = req.restarts;
    setze resp.http.xx_Age = resp.http.Age;
    setze resp.http.hit_count = obj.hits;
        nicht gesetzt bzw. http.Alter;
            zurückgeben (liefern);
            }

sub vcl_purge {
    return (Synth (200, "Erfolg"));
}
sub vcl_backend_error {
    wenn (beresp.status == 500 ||
        beresp.status == 501 ||
        beresp.status == 502 ||
        beresp.status == 503 ||
        beresp.status == 504) {
        Rückkehr (Wiederholen);
    }
}
sub vcl_fini {
    zurück (ok);
}
[root@localhost /]# varnishd -f /usr/local/var/varnish/example.vcl -s malloc,200M -a 0.0.0.0:80
//Starten Sie den Dienst

Die erste Webseite

[root@localhost ~]# yum -y installiere httpd
[root@localhost ~]# echo aaa > /var/www/html/index.html
[root@localhost ~]# systemctl stoppe Firewall
[root@localhost ~]# systemctl start httpd

Kanal 2

[root@localhost ~]# yum -y installiere httpd
[root@localhost ~]# echo bbb > /var/www/html/index.html
[root@localhost ~]# systemctl stoppe Firewall
[root@localhost ~]# systemctl start httpd

Wenn Sie Varnishd wie folgt neu starten:

[root@localhost /]# netstat -anpt | grep 80
[root@localhost /]# killall -9 varnishd
[root@localhost /]# varnishd -f /usr/local/var/varnish/example.vcl -s malloc,200M -a 0.0.0.0:80

Der Clientzugriff erfolgt wie folgt:

Aktualisieren

[root@localhost /]# curl -X "PURGE" 192.168.148.130
// Cache leeren 

Erläuterung der Varnish-Konfigurationsdatei

vcl 4.0;
Importdirektoren;
std importieren;
# Standard-Backend-Definition. Legen Sie diese so fest, dass sie auf Ihren Inhaltsserver verweist.
Probe backend_healthcheck {
    .url="/"; #Greifen Sie auf den Stammpfad des Backend-Servers zu.Interval = 5s; #Anforderungszeitintervall.Timeout = 1s; #Anforderungs-Timeout.Window = 5; #Geben Sie die Anzahl der Abfragen auf 5 Mal an.Threshold = 3; #Wenn es 3 Fehler gibt, bedeutet dies, dass der Backend-Server nicht normal ist}
backend web1 { #definieren Sie den Backend-Server.host = "192.168.1.7"; #IP oder Domänenname des Hosts (also des Backend-Hosts), der umgeleitet werden soll.port = "80"; #geben Sie die Portnummer des Backend-Servers an.probe = backend_healthcheck; #Healthcheck ruft den durch backend_healthcheck definierten Inhalt auf}
Backend Web2 {
    .host = "192.168.1.8";
    .port = "80";
    .probe = backend_healthcheck;
}
acl purgers { #Zugriffskontrollliste "127.0.0.1" definieren;
    "lokaler Host";
    "192.168.1.0/24";
    !"192.168.1.8";
}
sub vcl_init { #Rufen Sie vcl_init auf, um die Subroutine zu initialisieren und die Backend-Hostgruppe, d. h. die Direktoren, zu erstellen.
    new web_cluster = directors.round_robin(); #Verwenden Sie das neue Schlüsselwort, um ein Director-Objekt zu erstellen und verwenden Sie den Round_Robin-Algorithmus web_cluster.add_backend(web1); #Fügen Sie einen Back-End-Serverknoten hinzu web_cluster.add_backend(web2);
}
unter vcl_recv {
    set req.backend_hint = web_cluster.backend(); #Geben Sie den Backend-Knoten der Anforderung an web_cluster definierter Backend-Knoten if (req.method == "PURGE") { #Beurteilen Sie, ob der Anforderungsheader des Clients PURGE ist
        if (!client.ip ~ purgers) { #Wenn ja, prüfen Sie, ob die IP-Adresse des Clients in der ACL-Zugriffskontrollliste steht.
            return (synth(405, "Nicht zulässig.")); #Wenn nicht, gib einen 405-Statuscode an den Client zurück und gib die definierte Seite zurück.
    }
    return (purge); #Wenn es durch ACL definiert ist, wird es durch Purge behandelt.
}
wenn (req.method != "GET" &&
    req.method != "HEAD" &&
    Anforderungsmethode != "PUT" &&
    Anforderungsmethode != "POST" &&
    Anforderungsmethode != "TRACE" &&
    req.method != "OPTIONEN" &&
    req.method != "PATCH" &&
    req.method != "DELETE") { #Beurteilen Sie den Anforderungstyp des Clients return (Pipe);
    }
wenn (req.method != "GET" und req.method != "HEAD") {
    return (pass); #Wenn es nicht GET oder HEAD ist, übergeben Sie es.
}
wenn (req.url ~ "\.(php|asp|aspx|jsp|do|ashx|shtml)($|\?)") {
    return (pass); #Wenn der Client auf eine Datei mit der Endung .php zugreift, übergeben Sie sie zur Verarbeitung an „pass“.
}
wenn (req.http.Accept-Encoding) {
    if (req.url ~ "\.(bmp|png|gif|jpg|jpeg|ico|gz|tgz|bz2|tbz|zip|rar|mp3|mp4|ogg|swf|flv)$") {
    unset req.http.Accept-Encoding; #Stornieren Sie den vom Client empfangenen Komprimierungstyp} elseif (req.http.Accept-Encoding ~ "gzip") {
        set req.http.Accept-Encoding = "gzip"; #Wenn ein Gzip-Typ vorhanden ist, markieren Sie den Gzip-Typ.
    } elseif (req.http.Accept-Encoding ~ "deflate") {
        setze req.http.Accept-Encoding = "deflate";
    } anders {
    unset req.http.Accept-Encoding; #Andere undefinierte Seiten heben auch den vom Client empfangenen Komprimierungstyp auf.
    }
   }
if (req.url ~ "\.(css|js|html|htm|bmp|png|gif|jpg|jpeg|ico|gz|tgz|bz2|tbz|zip|rar|mp3|mp4|ogg|swf|flv)($|\?)") {
    unset req.http.cookie; #Den Cookie-Wert des Clients abbrechen.
    return (Hash); #Leitet die Anforderung an die Hash-Subroutine weiter, d. h. überprüft den lokalen Cache.
}
if (req.restarts == 0) { #Beurteilen Sie, ob es sich um die erste Anfrage vom Client handelt. if (req.http.X-Forwarded-For) { #Wenn es die erste Anfrage ist, legen Sie die IP-Adresse des Clients fest.
        setze req.http.X-Forwarded-For = req.http.X-Forwarded-For + ", " + client.ip;
    } anders {
    setze req.http.X-Forwarded-For = client.ip;
    }
}
Rückgabe (Hash);
}
sub vcl_hash {
    hash_data(req.url); #Zeigen Sie die vom Client angeforderte Seite an und führen Sie ein Hashing durch
    wenn (req.http.host) {
        hash_data(req.http.host); #Host des Clients festlegen} else {
        hash_data(server.ip); #Server-IP festlegen
    }
    zurückgeben (nachschlagen);
}
unter vcl_hit {
    if (req.method == "PURGE") { #Wenn es HIT ist und der Client-Anforderungstyp PURGE ist, geben Sie den Statuscode 200 zurück und geben Sie die entsprechende Seite zurück.
        return (synth(200, "Gelöscht."));
    }
    zurückgeben (liefern);
}
unter vcl_miss {
  wenn (req.method == "PURGE") {
        return (synth(404, "Gelöscht.")); #Wenn es ein Fehler ist, gib 404 zurück
    }
    zurückgeben (holen);
}
unter vcl_deliver {
    if (Objekttreffer > 0) {
        set resp.http.CXK = "HIT-from-varnish"; #HTTP-Header festlegen X-Cache = Hit
        set resp.http.X-Cache-Hits = obj.hits; #Gibt die Anzahl der Befehle zurück} else {
    setze resp.http.X-Cache = "MISS";
    }
    unset resp.http.X-Powered-By; #Anzeige der Webversion abbrechenunset resp.http.Server; #Anzeige des Varnish-Dienstes abbrechenunset resp.http.X-Drupal-Cache; #Anzeige des zwischengespeicherten Frameworks abbrechenunset resp.http.Via; #Anzeige der Dateiinhaltsquelle abbrechenunset resp.http.Link; #Anzeige der HTML-Hyperlinkadresse abbrechenunset resp.http.X-Varnish; #Anzeige der Varnish-ID abbrechen
    set resp.http.xx_restarts_count = req.restarts; #Anzahl der Client-Anfragen festlegen set resp.http.xx_Age = resp.http.Age; #Länge der zwischengespeicherten Dateien anzeigen #set resp.http.hit_count = obj.hits; #Anzahl der Cache-Treffer anzeigen #unset resp.http.Age;
    zurückgeben (liefern);
}
unter vcl_pass {
    return (fetch); #Die vom Backend-Server zurückgegebenen Daten lokal zwischenspeichern}
unter vcl_backend_response {
    setze beresp.grace = 5m; #zusätzliche Nachfrist zwischenspeichernwenn (beresp.status == 499 || beresp.status == 404 || beresp.status == 502) {
        setze beresp.uncacheable = true; #Wenn der Backend-Server mit einem Statuscode von 449 usw. antwortet, nicht zwischenspeichern}
    wenn (bereq.url ~ "\.(php|jsp)(\?|$)") {
        setze beresp.uncacheable = true; #Wenn es eine PHP-Seite ist, wird sie nicht zwischengespeichert} else {
        wenn (bereq.url ~ "\.(css|js|html|htm|bmp|png|gif|jpg|jpeg|ico)($|\?)") {
        setze beresp.ttl = 15m; #Wenn es mit dem oben genannten endet, zwischenspeichere es für 15 Minuten unset beresp.http.Set-Cookie;
        } elseif (bereq.url ~ "\.(gz|tgz|bz2|tbz|zip|rar|mp3|mp4|ogg|swf|flv)($|\?)") {
            setze beresp.ttl = 30m; #Cache für 30 Minuten, setze beresp.http.Set-Cookie zurück;
        } anders {
            setze beresp.ttl = 10m; #Lebensdauer 10 Minuten, nicht gesetzt beresp.http.Set-Cookie;
        }
    }
    zurückgeben (liefern);
}
sub vcl_purge {
    return (Synth (200, "Erfolg"));
}
sub vcl_backend_error {
    wenn (beresp.status == 500 ||
        beresp.status == 501 ||
        beresp.status == 502 ||
        beresp.status == 503 ||
        beresp.status == 504) {
        return (Wiederholen); #Wenn der Statuscode einer der oben genannten ist, erneut anfordern}
}
sub vcl_fini {
    zurück (ok);
}

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.