Detaillierte Erläuterung der Nginx-Antwort- und Anforderungsverarbeitungsmethoden

In diesem Artikel wird detailliert beschrieben, wie der Nginx-Server auf http- und andere Anfragen reagiert und diese verarbeitet. Außerdem wird die Konfigurationsmethode des virtuellen Nginx-Hosts erläutert.

1. Namensbasierter virtueller Nginx-Host
Nginx wählt zunächst aus, welcher virtuelle Host die Anfrage bearbeiten soll.
Beginnen Sie mit einer einfachen Konfiguration (bei der alle 3 virtuellen Hosts auf Port *:80 lauschen):

Code kopieren Codebeispiel:

server {
listen 80;
server_name jbxue.org www.jbxue.org;
...
}

server {
listen 80;
server_name jbxue.net www.jbxue.net;
...
}

server {
listen 80;
server_name jbxue.com www.jbxue .com;
...
}

In dieser Konfiguration überprüft nginx nur den „Host“-Header der Anfrage, um zu bestimmen, von welchem ​​virtuellen Host die Anfrage verarbeitet werden soll. Wenn der Host-Header mit keinem virtuellen Host übereinstimmt oder die Anfrage überhaupt keinen Host-Header enthält, verteilt nginx die Anfrage an den auf diesem Port definierten virtuellen Standardhost. In der obigen Konfiguration ist der erste aufgeführte virtuelle Host der standardmäßige virtuelle Host von Nginx – dies ist das Standardverhalten von Nginx. Darüber hinaus können Sie einen Host explizit als virtuellen Standardhost festlegen, d. h. den Parameter „default_server“ in der „listen“-Direktive festlegen:

Code kopieren Codebeispiel:

server {
listen 80 default_server;
server_name jbxue.net www.jbxue.net;
...
}

Der Parameter „default_server“ ist ab Version 0.8.21 verfügbar. In früheren Versionen sollte stattdessen der Parameter „default“ verwendet werden.
Bitte beachten Sie, dass „default_server“ ein Attribut des Überwachungsports ist, nicht der Hostname. Mehr dazu später.

So verhindern Sie die Verarbeitung von Anfragen mit undefinierten Hostnamen

Wenn der Header „Host“ in der Anfrage nicht erlaubt ist, können Sie den folgenden Host definieren und diese Anfragen verwerfen:

Code kopierenCodebeispiel:

server {
listen 80;
server_name "";
return 444;
}

Hier wird der Hostname auf eine leere Zeichenfolge gesetzt, um Anfragen ohne definierten „Host“-Header zu entsprechen, und es wird ein Nginx-spezifischer, nicht-HTTP-Standard-Rückgabecode 444 zurückgegeben, der dies kann zum Schließen der Verbindung verwendet werden.

Ab Version 0.8.48 ist dies die Standardeinstellung für Hostnamen, daher kann server_name „“ weggelassen werden. Frühere Versionen verwendeten den Hostnamen der Maschine als Standard-Hostnamen.
Virtueller Host basierend auf gemischtem Domänennamen und IP

Eine kompliziertere Konfiguration. In dieser Konfiguration lauschen mehrere virtuelle Hosts auf verschiedene Adressen:

Code kopierenCodebeispiel:

server {
listen 192.168.1.1:80;
server_name jbxue.org www.jbxue.org;
...
}

server {
listen 192.168.1.1:80;
server_name jbxue.net www.jbxue.net;
...
}

server {
listen 192.168.1.2:80;
server_name jbxue.com www.jbxue.com;
...
}

In diesem Bei der Konfiguration testet Nginx zunächst, ob die angeforderte IP-Adresse und der Port mit der Konfiguration der Listen-Anweisung in einem bestimmten Serverkonfigurationsblock übereinstimmen. Anschließend testet nginx weiterhin, ob der Host-Header der Anfrage mit einem bestimmten server_name-Wert in diesem Serverblock übereinstimmt. Wenn der Hostname nicht gefunden wird, übergibt Nginx die Anfrage an den standardmäßigen virtuellen Host. Beispielsweise wird eine von Port 192.168.1.1:80 empfangene Zugriffsanforderung auf www.jbxue.com vom standardmäßigen virtuellen Host verarbeitet, der Port 192.168.1.1:80 überwacht. In diesem Fall handelt es sich um den ersten Server, da es keine Definition gibt ein virtueller Host namens www.jbxue.com.

Der Standardserver ist eine Eigenschaft des Abhörports, daher können verschiedene Abhörports unterschiedliche Standardserver festlegen:

Code kopieren Codebeispiel:

server {
listen 192.168.1.1:80;
server_name jbxue.org www.jbxue.org;
...
}
server {
Listen 192.168.1.1:80 default_server;
Server_name jbxue.net www.jbxue.net;
...
}

Listen 192.168.2:80 default_serverver ; Servername jbxue.com www.jbxue.com;
...
}

Zweitens eine einfache PHP-Site-Konfiguration
Auf einer typischen, einfachen PHP-Site, wie Nginx den Speicherort für die Verarbeitung einer Anfrage auswählt:

Code kopieren Codebeispiel:

server {
listen 80;
server_name jbxue.org www.jbxue.org;
root /data/www;

location / {
index index.html index.php;
}

location ~* .(gif|jpg|png)$ {
läuft 30 Tage ab ;
}

location ~ .php$ {
fastcgi_pass localhost:9000;
fastcgi_param SCRIPT_FILENAME
                    $document_root$fastcgi_script_name;                                                                                                          🎜>}


Zuerst verwendet Nginx den Präfixabgleich, um den genauesten Standort zu finden. In diesem Schritt ignoriert Nginx die Reihenfolge, in der der Standort in der Konfigurationsdatei angezeigt wird.

In der obigen Konfiguration ist „/“ der einzige Präfix-Übereinstimmungsort, und da er mit jeder Anfrage übereinstimmen kann, wird er als letzte Wahl verwendet. Nginx gleicht dann weiterhin die Positionen der regulären Ausdrücke in der Reihenfolge in der Konfiguration ab und stoppt die Suche, nachdem der erste reguläre Ausdruck gefunden wurde.

Der übereinstimmende Standort wird verwendet. Wenn es keinen Ort gibt, der mit dem regulären Ausdruck übereinstimmt, wird der Ort mit der gerade gefundenen genauesten Präfixübereinstimmung verwendet.

Bitte beachten Sie, dass alle Standortvergleichstests nur den URI-Teil der Anfrage verwenden, nicht den Parameterteil. Dies liegt daran, dass es viele Möglichkeiten gibt, Parameter zu schreiben, wie zum Beispiel:

/index.php?user=john&page=1

/index.php?page=1&user=john
In Außerdem kann jeder eine beliebige Zeichenfolge zur Anforderungszeichenfolge hinzufügen:
/index.php?page=1&something+else&user=john
Sehen wir uns an, wie die Anforderung mit der obigen Konfiguration verarbeitet wird: Request "/logo. gif“ entspricht zuerst dem Speicherort „/“ und dann dem regulären Ausdruck „.(gif|jpg|png)$“. Daher wird es von diesem verarbeitet. Gemäß dem Befehl „root /data/www“ ordnet nginx die Anfrage der Datei „/data/www/logo.gif“ zu und sendet diese Datei an den Client.

Die Anfrage „/index.php“ stimmt auch mit dem ersten Ort „/“ überein und stimmt dann mit dem regulären Ausdruck „.(php)$“ überein. Daher wird er von diesem verarbeitet und dann an den FastCGI-Server gesendet, der bei localhost:9000 lauscht Der FastCGI-Parameter SCRIPT_FILENAME wird auf „/data/www/index.php“ gesetzt und der FastCGI-Server führt diese Datei aus. Die Variable $document_root entspricht dem durch die Root-Direktive festgelegten Wert und dem Wert der Variablen $fastcgi_script_name ist die angeforderte URL „/index.php“. >
Die Anfrage „/about.html“ kann nur mit dem Speicherort „/“ übereinstimmen, daher wird sie entsprechend dem „root /“ verarbeitet. data/www“-Direktive ordnet Nginx die Anfrage der Datei „/data/“ zu. www/about.html“ und sendet diese Datei an den Client

Die Verarbeitung der Anfrage „/“ erfolgt weiter kompliziert. Es kann nur mit dem Speicherort „/“ übereinstimmen, daher wird dieser Speicherort für die Verarbeitung verwendet.

Dann verwendet der Indexbefehl seine Parameter und den Dateipfad, der aus dem Befehl „root /data/www“ besteht, um zu erkennen, ob die entsprechende Datei existiert.

Wenn die Datei /data/www/index.html nicht existiert und /data/www/index.php existiert, führt dieser Befehl eine interne Umleitung nach „/index.php“ durch dann sucht nginx erneut nach einem Standort, der mit „/index.php“ übereinstimmt, als ob diese Anfrage vom Client stammt

Wie bereits gesehen, wird diese umgeleitete Anfrage letztendlich vom FastCGI-Server verarbeitet.

Das Obige enthält eine ausführliche Erläuterung der Methode von Nginx zur Beantwortung und Verarbeitung von Anfragen, einschließlich relevanter Aspekte. Ich hoffe, dass es für Freunde hilfreich ist, die sich für PHP-Tutorials interessieren.