Detaillierte Erklärung der Funktionsweise von Nginx

So funktioniert Nginx

Nginx besteht aus einem Kern und Modulen.

Nginx selbst erledigt eigentlich sehr wenig Arbeit. Wenn es eine HTTP-Anforderung empfängt, ordnet es die Anforderung einfach einem Standortblock zu, indem es die Konfigurationsdatei nachschlägt. Die verschiedenen an diesem Standort konfigurierten Anweisungen starten verschiedene Module, um die Arbeit abzuschließen. Daher kann das Modul als der eigentliche Arbeiter von Nginx angesehen werden. Normalerweise umfassen die Anweisungen an einem Standort ein Handlermodul und mehrere Filtermodule (natürlich können mehrere Standorte dasselbe Modul wiederverwenden). Das Handlermodul ist für die Verarbeitung von Anfragen und die Generierung von Antwortinhalten verantwortlich, während das Filtermodul die Antwortinhalte verarbeitet.

Von Benutzern nach ihren eigenen Bedürfnissen entwickelte Module sind Drittanbietermodule. Die Unterstützung so vieler Module macht Nginx so leistungsstark.

Nginx-Module sind strukturell in Kernmodule, Basismodule und Drittanbietermodule unterteilt:

• Kernmodule: HTTP-Modul, EVENT-Modul und MAIL-Modul
• Basismodule: HTTP-Zugriffsmodul, HTTP-FastCGI-Modul, HTTP-Proxy-Modul und HTTP-Rewrite-Modul.
• Module von Drittanbietern: HTTP Upstream Request Hash-Modul, Notice-Modul und HTTP Access Key-Modul.
  

Nginx-Module werden anhand ihrer Funktionen in die folgenden drei Kategorien unterteilt:

• Handler (Prozessormodul). Dieser Modultyp verarbeitet Anfragen direkt und führt Vorgänge wie die Ausgabe von Inhalten und die Änderung von Header-Informationen aus. Normalerweise kann es nur ein Handlers-Prozessormodul geben.
• Filter (Filtermodul). Dieser Modultyp ändert hauptsächlich den von anderen Prozessormodulen ausgegebenen Inhalt und gibt ihn schließlich über Nginx aus.
• Proxys (Proxy-Klassenmodul). Dieser Modultyp ist ein Modul wie Nginx's HTTP Upstream. Diese Module interagieren hauptsächlich mit einigen Backend-Diensten wie FastCGI, um Funktionen wie Service-Proxy und Lastausgleich zu implementieren.

Nginx-Prozessmodell

Nginx verwendet standardmäßig den Multiprozess-Arbeitsmodus. Nach dem Start von Nginx werden ein Masterprozess und mehrere Arbeitsprozesse ausgeführt. Der Master fungiert als Interaktionsschnittstelle zwischen der gesamten Prozessgruppe und dem Benutzer. Er überwacht den Prozess und verwaltet den Arbeitsprozess, um Funktionen wie den Neustart von Diensten, reibungslose Upgrades, das Ersetzen von Protokolldateien und das Aktivieren von Konfigurationsdateien in Echtzeit zu implementieren. Worker werden zur Verarbeitung grundlegender Netzwerkereignisse eingesetzt. Worker sind gleichberechtigt und konkurrieren um die Verarbeitung von Client-Anfragen.

Das Prozessmodell von nginx ist in der Abbildung dargestellt:

Erstellen Sie beim Erstellen eines Masterprozesses zuerst den Socket (listenfd), der abgehört werden muss, und forken Sie dann mehrere Workerprozesse vom Masterprozess aus (mit „fork“), sodass jeder Workerprozess den vom Benutzer angeforderten Socket abhören kann. Wenn eine Verbindung zustande kommt, erhalten im Allgemeinen alle Arbeiter eine Benachrichtigung, aber nur ein Prozess kann die Verbindungsanforderung annehmen, und die anderen schlagen fehl. Dies ist das sogenannte Herdenphänomen. nginx stellt ein accept_mutex (Mutex-Sperre) bereit. Mit dieser Sperre wird nur ein Prozess gleichzeitig mit dem Accept verbunden, sodass es kein Herdenpanikproblem gibt.

Aktivieren Sie zuerst die Option accept_mutex. Nur der Prozess, der accept_mutex erhält, fügt das Accept-Ereignis hinzu. nginx verwendet eine Variable namens ngx_accept_disabled, um zu steuern, ob um die accept_mutex-Sperre konkurriert werden soll. ngx_accept_disabled = die Gesamtzahl der Verbindungen eines einzelnen nginx-Prozesses / 8 – die Anzahl der inaktiven Verbindungen. Wenn ngx_accept_disabled größer als 0 ist, wird kein Versuch unternommen, die accept_mutex-Sperre zu erhalten. Je größer der Wert von ngx_accept_disable, desto mehr Möglichkeiten gibt es aufzugeben und desto größer sind somit die Chancen für andere Prozesse, die Sperre zu erhalten. Wenn Sie dies nicht akzeptieren, wird die Anzahl der Verbindungen für jeden Arbeitsprozess kontrolliert und die Verbindungspools anderer Prozesse werden genutzt. Auf diese Weise kontrolliert nginx das Gleichgewicht der Verbindungen zwischen mehreren Prozessen.

Jeder Arbeitsprozess verfügt über einen unabhängigen Verbindungspool und die Größe des Verbindungspools beträgt worker_connections. Der Verbindungspool speichert hier eigentlich keine echten Verbindungen, sondern ist lediglich ein Array von ngx_connection_t-Strukturen in der Größe von worker_connections. Darüber hinaus speichert nginx alle inaktiven ngx_connection_t über eine verknüpfte Liste free_connections. Jedes Mal, wenn eine Verbindung hergestellt wird, wird eine aus der verknüpften Liste freier Verbindungen abgerufen und nach der Verwendung wieder in die verknüpfte Liste freier Verbindungen eingefügt. Die maximale Anzahl an Verbindungen, die ein Nginx herstellen kann, sollte worker_connections * worker_processes betragen. Natürlich geht es hier um die maximale Anzahl von Verbindungen. Bei HTTP-Anfragen an lokale Ressourcen beträgt die maximale Anzahl gleichzeitiger Verbindungen, die unterstützt werden kann, Worker_Connections * Worker_Processes. Wenn HTTP als Reverse-Proxy verwendet wird, sollte die maximale Anzahl gleichzeitiger Verbindungen Worker_Connections * Worker_Processes/2 betragen. Denn als Reverse-Proxy-Server wird bei jeder gleichzeitigen Verbindung eine Verbindung mit dem Client und eine Verbindung mit dem Backend-Dienst hergestellt, wodurch zwei Verbindungen belegt werden.

Nginx verarbeitet HTTP-Anfragen

Bei der HTTP-Anfrage handelt es sich um ein typisches Netzwerkprotokoll vom Typ „Anforderung/Antwort“. HTTP ist ein Dateiprotokoll. Wenn wir also die Anforderungszeile und den Anforderungsheader analysieren und die Antwortzeile und den Antwortheader ausgeben, verarbeiten wir diese häufig Zeile für Zeile. Normalerweise wird nach dem Herstellen einer Verbindung eine Datenzeile gelesen, um die in der Anforderungszeile enthaltenen Informationen zu Methode, URI und HTTP-Version zu analysieren. Verarbeiten Sie dann den Anforderungsheader zeilenweise, bestimmen Sie anhand der Anforderungsmethode und der Anforderungsheaderinformationen, ob ein Anforderungstext vorhanden ist und wie lang der Anforderungstext ist, und lesen Sie dann den Anforderungstext. Nach Erhalt der Anfrage verarbeiten wir die Anfrage, um die auszugebenden Daten zu generieren, und generieren dann die Antwortzeile, den Antwortheader und den Antworttext. Nachdem die Antwort an den Client gesendet wurde, wird eine vollständige Anfrage verarbeitet.

Ablaufdiagramm der Verarbeitung:

Oben finden Sie eine ausführliche Erklärung zur Funktionsweise von Nginx. Weitere Informationen zur Funktionsweise von Nginx finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!