Eine umfassende Analyse der Möglichkeiten von Nginx

Vorwort

Dieser Artikel konzentriert sich nur darauf, was Nginx ohne das Laden von Drittanbietermodulen verarbeiten kann. Da es zu viele Drittanbietermodule gibt, ist es unmöglich, sie alle vorzustellen. Natürlich ist dieser Artikel selbst möglicherweise nicht vollständig. Schließlich ist es nur das, was ich persönlich verwendet und verstanden habe. Bitte verzeihen Sie mir und hinterlassen Sie gerne eine Nachricht zur Kommunikation

Was Nginx kann

1. Reverse-Proxy
2. Lastverteilung
3. HTTP-Server (inkl. dynamischer und statischer Trennung)
4. Proxy weiterleiten

Das Obige ist, was ich darüber weiß, was Nginx tun kann, ohne auf Module von Drittanbietern angewiesen zu sein. Im Folgenden finden Sie eine detaillierte Beschreibung der Ausführung der einzelnen Funktionen.

Reverse-Proxy

Reverse Proxy ist wahrscheinlich die häufigste Funktion von Nginx. Was ist Reverse Proxy? Hier ist, was die Baidu-Enzyklopädie sagt: Reverse Proxy bezieht sich auf die Verwendung eines Proxyservers, um Verbindungsanfragen im Internet anzunehmen, die Anfragen dann an einen Server im internen Netzwerk weiterzuleiten und die vom Server erhaltenen Ergebnisse an den Client zurückzugeben, der die Verbindung im Internet anfordert. Zu diesem Zeitpunkt erscheint der Proxyserver der Außenwelt als Reverse-Proxy-Server. Einfach ausgedrückt kann auf den realen Server nicht direkt vom externen Netzwerk zugegriffen werden, daher wird ein Proxyserver benötigt. Der Proxyserver kann vom externen Netzwerk aus erreicht werden und befindet sich in derselben Netzwerkumgebung wie der reale Server. Natürlich kann es auch derselbe Server mit einem anderen Port sein.

Hier ist ein einfacher Code zur Implementierung eines Reverse-Proxys

Server {
    hören Sie 80;                             
    Servername localhost;                        
    Maximale Client-Body-Größe: 1024 M;

    Standort / {
      Proxy-Passwort http://localhost:8080;
      Proxy_set_header Host $host:$server_port;
    }
  }

Nachdem wir die Konfigurationsdatei gespeichert haben, starten wir Nginx. Wenn wir auf localhost zugreifen, entspricht dies dem Zugriff auf localhost:8080.

Lastenausgleich

Lastenausgleich ist auch eine häufig verwendete Funktion von Nginx. Lastenausgleich bedeutet, die Ausführung auf mehrere Betriebseinheiten wie Webserver, FTP-Server, wichtige Unternehmensanwendungsserver und andere unternehmenskritische Server zu verteilen, um die Arbeitsaufgaben gemeinsam abzuschließen. Einfach ausgedrückt: Wenn zwei oder mehr Server vorhanden sind, werden die Anforderungen nach den Regeln zufällig an die angegebenen Server verteilt, um sie dort zu verarbeiten. Die Konfiguration des Lastenausgleichs erfordert im Allgemeinen gleichzeitig die Konfiguration eines Reverse-Proxys und springt zum Lastenausgleich über den Reverse-Proxy. Nginx unterstützt derzeit 3 ​​integrierte Lastausgleichsstrategien und 2 häufig verwendete Strategien von Drittanbietern.

1. RR (Standard)

Jede Anfrage wird in chronologischer Reihenfolge nacheinander einem anderen Backend-Server zugewiesen. Wenn der Backend-Server ausfällt, kann er automatisch entfernt werden.

Einfache Konfiguration

 Upstream-Test {
    Server localhost:8080;
    Server localhost:8081;
  }
  Server {
    hören 81;                             
    Servername localhost;                        
    Maximale Client-Body-Größe: 1024 M;

    Standort / {
      Proxy-Passwort http://test;
      Proxy_set_header Host $host:$server_port;
    }
  }

Der Kerncode des Lastenausgleichs ist

  Upstream-Test {
    Server localhost:8080;
    Server localhost:8081;
  }

Hier habe ich natürlich zwei Server konfiguriert. Tatsächlich ist es nur einer, aber die Ports sind unterschiedlich und der Server 8081 existiert nicht, das heißt, er kann nicht aufgerufen werden. Wenn wir jedoch http://localhost aufrufen, gibt es kein Problem. Standardmäßig wird zu http://localhost:8080 gesprungen. Dies liegt daran, dass Nginx den Status des Servers automatisch ermittelt. Wenn der Server nicht erreichbar ist (der Server ist ausgefallen), wird nicht zu diesem Server gesprungen. Dadurch wird auch die Situation vermieden, dass ein Server ausfällt und die Nutzung beeinträchtigt wird. Da Nginx standardmäßig die RR-Richtlinie verwendet, benötigen wir keine weiteren Einstellungen.

2. Gewicht

Gibt die Polling-Wahrscheinlichkeit an. Die Gewichtung ist proportional zur Zugriffsrate und wird verwendet, wenn die Leistung des Backend-Servers ungleichmäßig ist.

Zum Beispiel

  Upstream-Test {
    Server lokaler Host:8080 Gewicht=9;
    Server lokaler Host:8081 Gewicht=1;
  }

Dann greift im Allgemeinen nur 1 von 10 auf 8081 zu und 9 von 10 auf 8080.

3. ip_hash

Bei den beiden oben genannten Methoden gibt es ein Problem, nämlich dass die nächste Anfrage möglicherweise an einen anderen Server verteilt wird. Wenn unser Programm nicht zustandslos ist (Sitzungen werden zum Speichern von Daten verwendet), gibt es zu diesem Zeitpunkt ein großes Problem. Wenn beispielsweise die Anmeldeinformationen in der Sitzung gespeichert werden, müssen Sie sich erneut anmelden, wenn Sie zu einem anderen Server springen. Daher müssen wir oft ip_hash verwenden, wenn ein Kunde nur auf einen Server zugreifen muss. Jede Anfrage von ip_hash wird entsprechend dem Hash-Ergebnis der Zugriffs-IP zugewiesen, sodass jeder Besucher auf einen festen Backend-Server zugreift, wodurch das Sitzungsproblem gelöst werden kann.

  Upstream-Test {
    ip_hash;
    Server localhost:8080;
    Server localhost:8081;
  }

4. fair (Drittanbieter)

Die Anfragen werden basierend auf der Antwortzeit des Backend-Servers verteilt, wobei Anfragen mit kürzeren Antwortzeiten Vorrang erhalten.

  Upstream-Backend { 
    gerecht; 
    Server localhost:8080;
    Server localhost:8081;
  }

5. url_hash (Drittanbieter)

Anfragen werden entsprechend dem Hash-Ergebnis der aufgerufenen URL verteilt, sodass jede URL an denselben Backend-Server weitergeleitet wird. Dies ist effektiver, wenn der Backend-Server zwischengespeichert ist. Fügen Sie im Upstream eine Hash-Anweisung hinzu. Andere Parameter wie Gewicht können nicht in die Server-Anweisung geschrieben werden. hash_method ist der verwendete Hash-Algorithmus.

  Upstream-Backend { 
    Hashwert für $request_uri; 
    Hash-Methode crc32; 
    Server localhost:8080;
    Server localhost:8081;
  }

Die oben genannten fünf Arten des Lastausgleichs eignen sich für unterschiedliche Situationen, sodass Sie je nach tatsächlicher Situation den zu verwendenden Strategiemodus auswählen können. Für die Verwendung von fair und url_hash ist jedoch die Installation von Drittanbietermodulen erforderlich. Da in diesem Artikel hauptsächlich die Funktionen von Nginx vorgestellt werden, wird in diesem Artikel nicht auf die Installation von Drittanbietermodulen für Nginx eingegangen.

HTTP-Server

Nginx selbst ist auch ein statischer Ressourcenserver. Wenn nur statische Ressourcen vorhanden sind, können Sie Nginx als Server verwenden. Gleichzeitig ist es auch sehr beliebt, statische und dynamische Ressourcen zu trennen, was durch Nginx erreicht werden kann. Sehen wir uns zunächst Nginx als statischen Ressourcenserver an.

  Server {
    hören Sie 80;                             
    Servername localhost;                        
    Maximale Client-Body-Größe: 1024 M;
    Standort / {
        Wurzel e:wwwroot;
        Index Index.html;
      }
  }

Wenn Sie auf diese Weise http://localhost aufrufen, greifen Sie standardmäßig auf index.html im Verzeichnis wwwroot von Laufwerk E zu. Wenn eine Website nur eine statische Seite ist, können Sie sie auf diese Weise bereitstellen.

Trennung von statischer und dynamischer

Die dynamische und statische Trennung besteht darin, die dynamischen Webseiten in der dynamischen Website dazu zu bringen, die unveränderlichen Ressourcen nach bestimmten Regeln von den sich häufig ändernden Ressourcen zu unterscheiden. Nachdem die dynamischen und statischen Ressourcen getrennt wurden, können wir sie entsprechend den Eigenschaften der statischen Ressourcen zwischenspeichern. Dies ist die Kernidee der statischen Verarbeitung von Websites

Upstream-Test{ 
    Server localhost:8080; 
    Server localhost:8081; 
  }  

  Server { 
    hören Sie 80; 
    Servername localhost; 

    Standort / { 
      Wurzel e:wwwroot; 
      Index Index.html; 
    } 

    # Alle statischen Anfragen werden von nginx verarbeitet und im HTML-Verzeichnis gespeichert 
    Standort ~ .(gif|jpg|jpeg|png|bmp|swf|css|js)$ { 
      Wurzel e:wwwroot; 
    } 

    # Alle dynamischen Anfragen werden zur Verarbeitung an Tomcat weitergeleitet. Ort ~ .(jsp|do)$ { 
      Proxy-Passwort http://test; 
    } 

    Fehlerseite 500 502 503 504 /50x.html; 
    Standort = /50x.html { 
      Wurzel e:wwwroot; 
    } 
  }

Auf diese Weise können wir HTML, Bilder, CSS und JS im wwwroot-Verzeichnis ablegen, und Tomcat ist nur für die Verarbeitung von JSP und Anfragen verantwortlich. Wenn unser Suffix beispielsweise gif ist, ruft Nginx standardmäßig die dynamische Bilddatei der aktuellen Anfrage von wwwroot ab und gibt sie zurück. Natürlich befindet sich die statische Datei hier auf demselben Server wie Nginx. Wir können auch einen anderen Server verwenden und ihn dann über Reverse-Proxy und Lastenausgleich konfigurieren. Solange wir den grundlegendsten Prozess verstehen, werden viele Konfigurationen sehr einfach sein. Darüber hinaus folgt auf die Lokalisierung tatsächlich ein regulärer Ausdruck, sodass es sehr flexibel ist.

Weiterleitungsproxy

Ein Forward-Proxy ist ein Server, der sich zwischen dem Client und dem Ursprungsserver befindet. Um Inhalte vom Ursprungsserver abzurufen, sendet der Client eine Anfrage an den Proxy und gibt das Ziel (Ursprungsserver) an. Der Proxy leitet die Anfrage dann an den Ursprungsserver weiter und gibt die abgerufenen Inhalte an den Client zurück. Der Client kann den Forwardproxy verwenden. Wenn Sie Ihren Server als Proxyserver verwenden müssen, können Sie Nginx verwenden, um einen Forward-Proxy zu implementieren. Allerdings gibt es derzeit ein Problem mit Nginx, nämlich, dass es HTTPS nicht unterstützt. Obwohl ich Baidu durchsucht habe, um einen HTTPS-Forward-Proxy zu konfigurieren, habe ich festgestellt, dass es immer noch nicht als Proxy verwendet werden kann. Natürlich kann es sein, dass meine Konfiguration falsch ist, daher hoffe ich auch, dass Kameraden, die die richtige Methode kennen, eine Nachricht hinterlassen können, um es zu erklären.

Resolver 114.114.114.114 8.8.8.8;
  Server {

    Resolver_Timeout 5 s;

    hören 81;

    Zugriffsprotokoll e:wwwrootproxy.access.log;
    Fehlerprotokoll e:wwwrootproxy.error.log;

    Standort / {
      Proxy-Passwort http://$Host$Anforderungs-URI;
    }
  }

Resolver ist der DNS-Server, der den Forward-Proxy konfiguriert, und Listen ist der Port des Forward-Proxys. Nach der Konfiguration können Sie die Server-IP+Portnummer für den Proxy im IE oder anderen Proxy-Plugins verwenden.

Schlussworte

Nginx unterstützt Hotstart, was bedeutet, dass wir nach der Änderung der Konfigurationsdatei die Konfiguration wirksam machen können, ohne Nginx herunterzufahren. Natürlich weiß ich nicht, wie viele Leute das wissen. Jedenfalls wusste ich es am Anfang nicht, was dazu führte, dass der Nginx-Thread oft beendet und dann erneut gestartet wurde. . . Der Befehl für Nginx zum erneuten Lesen der Konfiguration lautet

nginx -s reload

Unter Windows ist

nginx.exe -s reload

Zusammenfassen

Oben habe ich Ihnen erklärt, was Nginx kann. Ich hoffe, es wird Ihnen helfen. Wenn Sie Fragen haben, hinterlassen Sie mir bitte eine Nachricht und ich werde Ihnen rechtzeitig antworten. Ich möchte auch allen für ihre Unterstützung der Website 123WORDPRESS.COM danken!