Nginx selbst analysiert PHP nicht. Die Anfrage des Terminals für die PHP-Seite wird von Nginx an die vom FastCGI-Prozess überwachte IP-Adresse und den Port übergeben, der schließlich von PHP-FPM verarbeitet wird , werden die Verarbeitungsergebnisse an Nginx zurückgegeben. Tatsächlich ist Nginx ein Reverse-Proxy-Server. Nginx leitet dynamische Anfragen über die Reverse-Proxy-Funktion an das Backend php-fpm weiter und realisiert so die Unterstützung für das PHP-Parsing. Dies ist das Prinzip der Implementierung des dynamischen PHP-Parsings durch Nginx.
Nginx unterstützt keinen direkten Aufruf oder Parsing externer Programme. Alle externen Programme (einschließlich PHP) müssen über die FastCGI-Schnittstelle aufgerufen werden. Die FastCGI-Schnittstelle ist ein Socket unter Linux (dieser Socket kann ein Datei-Socket oder ein IP-Socket sein). Um ein CGI-Programm aufzurufen, wird außerdem ein FastCGI-Wrapper benötigt (ein Wrapper kann als ein Programm verstanden werden, das zum Starten eines anderen Programms verwendet wird). Dieser Wrapper ist an einen festen Socket gebunden, beispielsweise einen Port oder einen Datei-Socket. Wenn Nginx eine CGI-Anfrage an diesen Socket sendet, empfängt der Wrapper die Anfrage über die FastCGI-Schnittstelle und erzeugt dann einen neuen Thread. Dieser Thread ruft den Interpreter oder ein externes Programm auf, um das Skript zu verarbeiten und dann die Rückgabedaten zu lesen Die zurückgegebenen Daten werden über den festen Socket über die FastCGI-Schnittstelle an Nginx weitergeleitet. Schließlich sendet Nginx die zurückgegebenen Daten an den Client.
Das klassische Modell ist das in Nginx verwendete asynchrone Multiprozess-Treibermodell Master-Worker.
Nachdem der übergeordnete Prozess einen Socket erstellt, bindet und abhört, erstellt er über fork mehrere untergeordnete Prozesse. Jeder untergeordnete Prozess erbt den Socket des übergeordneten Prozesses und ruft accpet auf, um mit dem Abhören und Warten auf Netzwerkverbindungen zu beginnen. Zu diesem Zeitpunkt warten mehrere Prozesse gleichzeitig auf das Netzwerkverbindungsereignis. Wenn dieses Ereignis eintritt, werden diese Prozesse gleichzeitig aktiviert, was einen „Schock“ darstellt. Wenn ein Prozess aktiviert wird, muss der Kernel neu geplant werden, damit jeder Prozess gleichzeitig auf dieses Ereignis reagiert. Am Ende kann nur ein Prozess das Ereignis erfolgreich verarbeiten, und andere Prozesse gehen wieder in den Ruhezustand oder können das Ereignis auf andere Weise nicht verarbeiten Ereignis.
Tatsächlich hat der Kernel nach Linux Version 2.6 das „Schock“-Problem der Funktion „accept()“ gelöst. Wenn der Kernel eine Kundenverbindung empfängt, wird nur der erste Prozess in der Warteschlange aktiviert . oder Thread.
Nginx verwendet die Mutex-Sperre „accept_mutex“, um dieses Problem zu lösen. Zu den spezifischen Maßnahmen gehört die Verwendung einer globalen Mutex-Sperre, bevor epoll_wait() ausgeführt wird Erhalten Sie es, wartet es und richtet einen Lastausgleichsalgorithmus ein (wenn das Aufgabenvolumen eines bestimmten Unterprozesses 7/8 des gesamten eingestellten Volumens erreicht, werden keine weiteren Versuche unternommen, Sperren zu beantragen), um das auszugleichen Aufgabenvolumen jedes Prozesses.
Jetzt fassen wir die Verarbeitung von Thundering-Gruppen und Nginx wie folgt zusammen:
Accept wird keine Thundering-Gruppen verursachen, epoll_wait jedoch.
Accept_mutex von Nginx löst nicht das Accept-Panic-Problem, sondern das epoll_wait-Panic-Problem.
Es ist auch falsch zu sagen, dass Nginx das epoll_wait-Panikproblem löst. Es steuert nur, ob der Listening-Socket zu epoll hinzugefügt wird. Der Listening-Socket befindet sich nur im Epoll eines untergeordneten Prozesses. Wenn eine neue Verbindung hergestellt wird, werden andere untergeordnete Prozesse sicherlich nicht aktiviert.
Einfach ausgedrückt darf nur ein Nginx-Worker gleichzeitig das Listening-Handle in seinem eigenen Epoll verwalten. Der Lastausgleich ist ebenfalls sehr einfach. Wenn 7/8 der maximalen Verbindung erreicht sind, versucht der Worker weder, die Akzeptanzsperre zu erhalten, noch verarbeitet er neue Verbindungen, sodass andere Nginx-Worker-Prozesse mehr Möglichkeiten haben, diese zu verarbeiten Listening-Handle. Eine neue Verbindung wird hergestellt. Darüber hinaus erhält der Arbeitsprozess, der die Sperre nicht erhalten hat, aufgrund der Einstellung des Zeitlimits die Sperre häufiger.
Ist das Nginx-Multiprozessmodell wirklich sperrenfrei? Tatsächlich gibt es immer noch einen: ngx_accept_mutex.
nginx ist ein Multiprozessprogramm und Port 80 wird von jedem Worker-Prozess gemeinsam genutzt. Immer wenn eine Verbindung hergestellt wird, konkurrieren zwangsläufig mehrere Worker-Prozesse um die Reaktion.
Wenn der Kernel einen Link akzeptiert, weckt er alle wartenden Prozesse auf, aber tatsächlich kann nur ein Prozess die Verbindung herstellen, und die anderen Prozesse werden ungültig geweckt. Dieses ungültige Wecken wird zweifellos den Overhead erhöhen die Anwendung. Zu diesem Zweck bietet Nginx eine Akzeptanzsperre, um die Tragödie zu vermeiden, dass neun Söhne den Thronfolger übernehmen.
Die Funktion von ngx_accept_mutex besteht darin, den Arbeitsprozessen, die derzeit stark ausgelastet sind
, zu ermöglichen, die Verarbeitung neuer eingehender Anforderungen aktiv aufzugeben, wodurch die allgemeine Aktivierungseffizienz des
Anwendung, wodurch die Gesamtleistung der Anwendung verbessert wird.
proxy_cache
upstream
fastcgi_pass
Standort
Nicht standardmäßiger Statuscode 444 bedeutet, dass die Verbindung geschlossen und kein Antwortheader gesendet wird an den Kunden.
Der Befehl nginx -s reload lädt die geänderte Konfigurationsdatei. Nach Ausgabe des Befehls treten die folgenden Ereignisse auf: 1. Der Masterprozess von Nginx überprüft die Richtigkeit der Konfigurationsdatei. Es wird eine Fehlermeldung zurückgegeben und Nginx verwendet sie weiterhin (da der Worker nicht betroffen ist)
2. Nginx startet einen neuen Worker-Prozess und übernimmt die neue Konfigurationsdatei
3. Nginx weist dem neuen Worker-Prozess neue Anfragen zu
4. Nginx wartet auf die Rückgabe aller Anfragen von den vorherigen Worker-Prozessen und schließt dann die relevanten Worker-Prozesse
5 Führen Sie den obigen Prozess aus, bis alle alten Worker-Prozesse geschlossen sind
Der obige Prozess basiert auf den relevanten offiziellen Dokumenten von Nginx.
Nehmen Sie „proxy_next_upstream“ als Beispiel:
proxy_next_upstream http_504 timeout;
Dieser Befehl hat zwei Funktionen:
Teilen Sie Nginx mit, dass Sie es erneut versuchen müssen, wenn eine Verbindungszeitüberschreitung auftritt und der Upstream 504 zurückgibt.-
Im Allgemeinen schlägt Nginx aufgrund von Fehlern, Zeitüberschreitungen und invalid_header fehl. Wenn Sie andere Verhaltensweisen als Fehler behandeln möchten, müssen Sie Anweisungen wie „proxy_next_upstream“ hinzufügen. Unter anderem liegt ein Fehler vor, wenn http_403 und http_404 nicht erkannt werden.
Besprechen Sie zwei Punkte: die Definition eines Serverausfalls und das Verhalten des Servers nach einem Ausfall.
Serverfehlerdefinition: Die obige Modulfehlerdefinition wird hauptsächlich verwendet, um zu erklären, unter welchen Umständen eine Anfrage fehlschlägt, aber was definiert einen Serverfehler? Nginx verwendet zur Steuerung hauptsächlich zwei Parameter: max_fails und fail_timeout. Einfach ausgedrückt: Wenn eine Anfrage innerhalb von fail_timeout max_fails Mal fehlschlägt, bedeutet dies, dass der Server derzeit ausgefallen ist.
Verhalten nach einem Fehler: Hauptsächlich:
#1 NGX_HTTP_POST_READ_PHASE: Phase des Lesens des Anforderungsinhalts
#2 NGX_HTTP_SERVER_REWRITE_PHASE: Serveranforderungsadresse Umschreibephase
#3 NGX_HTTP_FIND_CONFIG_PHASE: Phase der Konfigurationssuche
#4 NGX_HTTP_REWRITE_PHASE: Phase zum Umschreiben der Standortanforderungsadresse
#5 NGX_HTTP_POST_REWRITE_PHASE: Übermittlungsphase zum Umschreiben der Adresse anfordern
#6 NGX_HTTP_PREACCESS_PHASE: Vorbereitungsphase der Zugriffsberechtigungsprüfung
#7 NGX_HTTP_ACCESS_PHASE: Phase der Zugriffsberechtigungsprüfung
#8 NGX_HTTP_POST_ACCESS_PHASE: Übermittlungsphase der Zugriffsberechtigungsprüfung
#9 NGX_HTTP_TRY_FILES_PHASE: Konfiguration item try_files-Verarbeitungsphase
#10 NGX_HTTP_CONTENT_PHASE: Inhaltsgenerierungsphase
#11 NGX_HTTP_LOG_PHASE: Protokollmodul-Verarbeitungsphase
Nginx-Anfrageverarbeitungsablauf
#1 Wie Bestätigt Nginx, welcher Server die Anfrage bearbeitet?
1. Verwenden Sie IP + Port, um zu bestätigen, dass der Server die IP und den Port überwacht.
2. Bestätigen Sie anhand des Host-Headers in der Anfrage, welcher Server für die Bearbeitung der Anfrage ausgewählt ist.
3. Wenn kein Server übereinstimmt, wird die Anfrage zur Verarbeitung an den Standardserver übertragen.
Im Allgemeinen wird die Reihenfolge in der Konfigurationsdatei angezeigt dient als
Standardserver.
4. Sie können das Flag „default_server“ im Listen-Befehl verwenden, um einen Server als
Standardserver festzulegen.
#2 Wie ordnet Nginx den Server anhand des Host-Headers zu?
Nginx gleicht den Server hauptsächlich durch den Vergleich der server_name- und host-Header im Server ab.
Die Vergleichsreihenfolge ist wie folgt:
1. Der längste passende führende Platzhaltername (z. B. *.zhidao.baidu.com) ;
3. Der längste nachfolgende Platzhaltername (z. B.: zhidao.baidu.*);
#3 HTTP-Anfrage initialisieren, 11 Stufen der http-Anfrage
Befehl
~ Die Wellenlinie zeigt an, dass eine reguläre Übereinstimmung durchgeführt wird, bei der die Groß-/Kleinschreibung beachtet wird.
~* bedeutet die Durchführung eines regulären Abgleichs, ohne Berücksichtigung der Groß- und Kleinschreibung.
^~ ^~ bedeutet, dass die Option übereinstimmt, nur diese Option wird abgeglichen, andere Optionen werden im Allgemeinen nicht zum Abgleichen von Verzeichnissen verwendet.
= führt eine exakte Übereinstimmung gewöhnlicher Zeichen durch.
@ „@“ definiert einen benannten Speicherort, der zur internen Orientierung verwendet wird, z. B. error_page, try_files.
Beispiel:
Anfrage-URI-Beispiel:
/ -> Entspricht Konfiguration A
Der Reverse-Proxy-Mechanismus von Nginx löst domänenübergreifende Front-End-Probleme.
Wie Nginx die Größe hochgeladener Dateien ändert
Erläuterung des dynamischen und statischen Trennungsvorgangs von Nginx
Das obige ist der detaillierte Inhalt vonZusammenfassung und Austausch von Nginx-bezogenen Wissenspunkten. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
