Nach der Installation von Nginx wird ein entsprechendes Installationsverzeichnis generiert. Gemäß dem vorherigen Installationspfad lautet der Pfad der Nginx-Konfigurationsdatei /opt/nginx/conf, wobei nginx.conf die Hauptkonfiguration ist Datei von Nginx. Hier konzentrieren wir uns auf die Konfigurationsdatei nginx.conf. Die Nginx-Konfigurationsdatei ist hauptsächlich in vier Teile unterteilt: Hauptteil (globale Einstellungen), Server (Hosteinstellungen), Upstream (Lastausgleichsservereinstellungen) und Standort (URL entspricht den Einstellungen für einen bestimmten Standort). Die im Hauptteil festgelegten Anweisungen wirken sich hauptsächlich auf die Angabe des Hosts und des Ports aus Der Standortteil wird verwendet, um den Standort der Webseite abzugleichen. Die Beziehung zwischen den vier: Der Server erbt den Hauptserver, der Standort erbt den Server und der Upstream erbt weder andere Einstellungen noch wird er vererbt. Unter diesen vier Teilen enthält jeder Teil eine Reihe von Anweisungen, darunter hauptsächlich Anweisungen für das Nginx-Hauptmodul, Anweisungen für das Ereignismodul und Anweisungen für das HTTP-Kernmodul Es können andere HTTP-Modulanweisungen verwendet werden, z. B. das Http-SSL-Modul, das statische HttpGzip-Modul und das Http-Additionsmodul usw. Im Folgenden wird anhand eines Nginx-Konfigurationsbeispiels die Bedeutung jeder Anweisung in nginx.conf im Detail vorgestellt. Um ein klareres Verständnis der Struktur von Nginx und der Bedeutung der einzelnen Konfigurationsoptionen zu erhalten, ist die Nginx-Konfigurationsdatei entsprechend den Funktionspunkten in 7 Teile unterteilt und wird einzeln erläutert. Im Folgenden finden Sie eine Einführung in diese 7 Teile. 1. Globale Konfiguration von Nginx
Der folgende Inhalt ist die globale Attributkonfiguration von Nginx. Der Code lautet wie folgt:
[html] Sicht
Klarschrift
- Benutzer niemand niemand;
- pid logs/nginx.pid; events{
-
use epoll; >
worker_connections 65536; }
- Die Bedeutung jeder Konfigurationsoption im obigen Code wird wie folgt erklärt:
- user ist ein Hauptmodulbefehl, der angegeben wird. Der Nginx-Worker-Prozess wird als Benutzer und Benutzergruppe ausgeführt. Standardmäßig wird er vom Niemandskonto ausgeführt.
worker_processes ist eine Hauptmodulanweisung, die die Anzahl der Prozesse angibt, die von Nginx geöffnet werden sollen. Jeder Nginx-Prozess verbraucht durchschnittlich 10 bis 12 MB Speicher. Erfahrungsgemäß reicht es im Allgemeinen aus, einen Prozess anzugeben. Handelt es sich um eine Multicore-CPU, empfiehlt es sich, die gleiche Anzahl an Prozessen anzugeben wie die Anzahl an CPUs. -
error_log ist eine Hauptmodulanweisung, die zum Definieren einer globalen Fehlerprotokolldatei verwendet wird. Zu den Protokollausgabeebenen gehören Debug, Info, Hinweis, Warnung, Fehler und Krit. Unter diesen ist das Debug-Ausgabeprotokoll am detailliertesten, während das Krit-Ausgabeprotokoll am wenigsten detailliert ist.
- pid ist eine Hauptmodulanweisung, mit der der Speicherort der Prozess-ID in der Datei angegeben wird.
- worker_rlimit_nofile wird verwendet, um die maximale Anzahl von Dateideskriptoren anzugeben, die von einem Nginx-Prozess geöffnet werden können. Hier ist sie 65535. Sie müssen den Befehl „ulimit -n 65535“ verwenden, um sie festzulegen. Der Befehl
events dient dazu, den Arbeitsmodus von Nginx und die Obergrenze der Anzahl der Verbindungen festzulegen.
[html] Ansicht
Klarschrift
Ereignisse{
Epoll verwenden;
worker_connections 65536;
}
use ist ein Ereignismodulbefehl, mit dem der Arbeitsmodus von Nginx angegeben wird. Die von Nginx unterstützten Arbeitsmodi sind select, poll, kqueue, epoll, rtsig und /dev/poll. Unter diesen sind Select und Poll Standardarbeitsmodi, kqueue und epoll sind effiziente Arbeitsmodi. Der Unterschied besteht darin, dass epoll auf der Linux-Plattform und kqueue auf dem BSD-System verwendet wird. Für Linux-Systeme ist der Epoll-Arbeitsmodus die erste Wahl.
worker_connections ist auch eine Ereignismodulanweisung, mit der die maximale Anzahl von Verbindungen für jeden Nginx-Prozess definiert wird. Der Standardwert ist 1024. Die maximale Anzahl von Clientverbindungen wird also durch worker_processes und worker_connections bestimmt , Max_client=worker_processes*worker_connections, Wenn max_clients als Reverse-Proxy fungiert, wird es zu: max_clients
= worker_processes * worker_connections/4.
Die maximale Anzahl an Verbindungen eines Prozesses wird durch die maximale Anzahl geöffneter Dateien des Linux-Systemprozesses begrenzt. Die Einstellung von worker_connections kann erst nach Ausführung des Betriebssystembefehls „ulimit -n“ wirksam werden 65536". 2. HTTP-Serverkonfiguration
Als nächstes starten Sie die HTTP-Servereinstellungen.
Der folgende Inhalt ist die Konfiguration der HTTP-Server-bezogenen Attribute von Nginx. Der Code lautet wie folgt:
[html]-Ansicht
Klarschrift
- http{
- include conf/mime.types
- default_type application/octet-stream;
- log_format main '$remote_addr - $remote_user [$time_local] ' $request" $status $bytes_sent '
- '"$http_referer" "$http_user_agent" '
- '"$gzip_ratio"';
- log_format download ' $remote_addr - $remote_user [$time_local] '
- '"$request" $status $bytes_sent '
- '"$http_referer" " $http_user_agent" '
- '"$http_range" "$sent_http_content_range"';
- client_max_body_size 20m;
- client_header_buffer_size 32K; >
Sendfile on; tcp_nodelay on; -
keepalive_timeout 60;
- client_header_timeout 10;
- client_body_timeout 10;
- Im Folgenden finden Sie eine detaillierte Einführung in die Bedeutung der einzelnen Konfigurationsoptionen in diesem Code. include ist eine Hauptmodulanweisung, die das Festlegen von in der Konfigurationsdatei enthaltenen Dateien ermöglicht, wodurch die Komplexität der Hauptkonfigurationsdatei verringert werden kann. Ähnlich der include-Methode in Apache. default_type gehört zur HTTP-Kernmodulanweisung. Hier wird der Standardtyp auf „Binary Stream“ festgelegt, der verwendet wird, wenn der Dateityp nicht definiert ist. Wenn die PHP-Umgebung beispielsweise nicht konfiguriert ist, analysiert Nginx ihn nicht . Zu diesem Zeitpunkt greifen Sie mit einem Browser auf die PHP-Datei zu und es erscheint ein Download-Fenster.
Der folgende Code implementiert die Einstellung des Protokollformats.
- [html] Ansicht
Klarschrift
-
log_format main '$remote_addr - $remote_user [$time_local] '
'"$request " $status $bytes_sent '
'"$http_referer" "$http_user_agent" '
'"$gzip_ratio"';
log_format download '$remote_addr - $remote_user [$time_local] '
- '"$request" $status $bytes_sent ' '"$http_referer" "$http_user_agent" '
-
'"$http_range" "$sent_http_content_range"' >
log_format ist die HttpLog-Modulanweisung von Nginx, mit der das Ausgabeformat von Nginx-Protokollen angegeben wird. mainDer Name dieses Protokollausgabeformats, auf das in der folgenden access_log-Direktive verwiesen werden kann.
client_max_body_size wird verwendet, um die maximale Anzahl von Bytes einer einzelnen Datei festzulegen, die vom Client angefordert werden darf.
client_header_buffer_size wird verwendet, um die Header-Puffergröße aus dem Client-Anfrage-Header anzugeben. Für die meisten Anfragen ist eine Puffergröße von 1 KB ausreichend. Wenn Sie die Nachrichtenheader anpassen oder größere Cookies haben, können Sie die Puffergröße erhöhen. Dies ist auf 32 KB eingestellt.
large_client_header_buffers wird verwendet, um die maximale Anzahl und Größe von Caches für größere Nachrichtenheader in Client-Anfragen anzugeben. „4“ ist die Zahl, „128K“ ist die Größe und die maximale Cache-Menge beträgt 4 128K.
Der sendfile-Parameter wird verwendet, um einen effizienten Dateiübertragungsmodus zu aktivieren. Setzen Sie die Anweisungen tcp_nopush und tcp_nodelay auf „Ein“, um eine Netzwerkblockierung zu verhindern.
keepalive_timeout legt das Timeout fest, damit Clientverbindungen aktiv bleiben. Nach Ablauf dieser Zeit schließt der Server die Verbindung.
client_header_timeout legt das Zeitlimit für das Lesen des Client-Anforderungsheaders fest. Wenn diese Zeit überschritten wird und der Client keine Daten gesendet hat, gibt Nginx den Fehler „Request Time Out (408)“ zurück.
client_body_timeout legt das Zeitlimit für das Lesen des Client-Anforderungstexts fest. Wenn diese Zeit überschritten wird und der Client keine Daten gesendet hat, gibt Nginx den Fehler „Request Time Out (408)“ zurück. Der Standardwert ist 60.
send_timeout gibt den Timeout-Zeitraum für die Beantwortung des Clients an. Dieses Timeout ist auf die Zeit zwischen zwei Verbindungsaktivitäten begrenzt. Wenn diese Zeit ohne Aktivität auf dem Client überschritten wird, schließt Nginx die Verbindung. 3.HttpGzip-Modulkonfiguration
Konfigurieren Sie unten das HttpGzip-Modul von Nginx. Dieses Modul unterstützt die Online-Echtzeitkomprimierung von Ausgabedatenströmen. Um zu überprüfen, ob dieses Modul installiert ist, verwenden Sie den folgenden Befehl:
[html] view
Klarschrift
- [root@localhost conf]# /opt/nginx/sbin/nginx -V
- Nginx-Version: nginx/0.7.65
- Argumente konfigurieren: --with-http_stub_status_module --with-http_gzip_static_module --prefix=/opt/nginx
Sie können die Kompilierungsoptionen bei der Installation von Nginx über den Befehl /opt/nginx/sbin/nginx -V anzeigen. Aus der Ausgabe können wir Sehen Sie, dass wir das HttpGzip-Modul installiert haben.
Im Folgenden sind die relevanten Attributeinstellungen des HttpGzip-Moduls in der Nginx-Konfiguration aufgeführt:
[html]-Ansicht
Klarschrift
- gzip on;
- gzip_min_length 1k; >gzip_buffers 4 16k; gzip_http_version 1.1;
-
gzip_comp_level 2; gzip_types text/plain application/x-javascript text/css application/xml;
-
gzip_vary on; Das GZIP-Modul ein- oder ausschalten bedeutet, die GZIP-Komprimierung einzuschalten und den Ausgabedatenstrom in Echtzeit zu komprimieren.
- gzip_min_length legt die minimale Anzahl von Bytes der Seite fest, die für die Komprimierung zulässig sind. Die Anzahl der Seitenbytes wird aus der Inhaltslänge des Headers ermittelt. Der Standardwert ist 0, wodurch die Seite unabhängig von ihrer Größe komprimiert wird. Es wird empfohlen, die Anzahl der Bytes auf mehr als 1 KB festzulegen. Wenn sie kleiner als 1 KB ist, kann die Anzahl der Bytes immer größer werden.
- gzip_buffers bedeutet, dass 4 Einheiten 16-KB-Speicher als Stream-Cache für das Komprimierungsergebnis verwendet werden. Der Standardwert besteht darin, denselben Speicherplatz wie die ursprüngliche Datengröße zum Speichern des gzip-Komprimierungsergebnisses zu verwenden.
gzip_http_version wird verwendet, um die HTTP-Protokollversion festzulegen und zu identifizieren. Die Standardeinstellung ist 1.1. Derzeit unterstützen die meisten Browser bereits die GZIP-Dekomprimierung, verwenden Sie also einfach die Standardeinstellung. -
gzip_comp_level wird verwendet, um das GZIP-Komprimierungsverhältnis anzugeben. 1 hat das kleinste Komprimierungsverhältnis und die schnellste Verarbeitungsgeschwindigkeit. 9 hat das größte Komprimierungsverhältnis und die schnellste Übertragungsgeschwindigkeit, aber die langsamste Verarbeitung und verbraucht mehr CPU Ressourcen.
gzip_types wird verwendet, um den Komprimierungstyp anzugeben. Unabhängig davon, ob er angegeben ist oder nicht, wird immer der Typ „text/html“ komprimiert.
Die Option gzip_vary ermöglicht es dem Front-End-Cache-Server, GZIP-komprimierte Seiten zwischenzuspeichern, z. B. die Verwendung von Squid zum Zwischenspeichern von Nginx-komprimierten Daten.
4. Lastausgleichskonfiguration Legen Sie die Lastausgleichsserverliste unten fest.
[html]-Ansicht
Klarschrift
- upstream ixdba.net{
- ip_hash;
- Server 192.168.12.133:80;
3-
fail_timeout- =20s; Server 192.168. 12.136:8080; 🎜>upstream ist das HTTP-Upstream-Modul von Nginx. Dieses Modul verwendet einen einfachen Planungsalgorithmus, um einen Lastausgleich von der Client-IP zum Back-End-Server zu erreichen. In den obigen Einstellungen wird der Name eines Load Balancers ixdba.net durch die Upstream-Direktive angegeben. Dieser Name kann beliebig vergeben und später bei Bedarf direkt aufgerufen werden. Das Lastausgleichsmodul von Nginx unterstützt derzeit vier Planungsalgorithmen, die im Folgenden vorgestellt werden. Bei den letzten beiden handelt es sich um Planungsmethoden von Drittanbietern. Abfrage (Standard). Jede Anfrage wird nacheinander in chronologischer Reihenfolge verschiedenen Back-End-Servern zugewiesen. Fällt ein Back-End-Server aus, wird das fehlerhafte System automatisch eliminiert, sodass der Benutzerzugriff nicht beeinträchtigt wird.
Gewicht. Geben Sie die Polling-Gewichtung an. Je größer der Gewichtungswert, desto höher die zugewiesene Zugriffswahrscheinlichkeit. Sie wird hauptsächlich verwendet, wenn die Leistung der einzelnen Backend-Server ungleichmäßig ist. -
ip_hash. Jede Anfrage wird entsprechend dem Hash-Ergebnis der aufgerufenen IP zugewiesen, sodass Besucher von derselben IP immer auf einen Back-End-Server zugreifen, wodurch das Problem der Sitzungsfreigabe dynamischer Webseiten effektiv gelöst wird.
- fair. Ein intelligenterer Lastausgleichsalgorithmus als die beiden oben genannten. Dieser Algorithmus kann einen intelligenten Lastausgleich basierend auf Seitengröße und Ladezeit durchführen, d. h. Anforderungen basierend auf der Antwortzeit des Back-End-Servers zuweisen und diejenigen mit kurzen Antwortzeiten priorisieren. Nginx selbst unterstützt Fair nicht. Wenn Sie diesen Planungsalgorithmus verwenden müssen, müssen Sie das Modul upstream_fair von Nginx herunterladen.
url_hash. Durch die Verteilung von Anforderungen entsprechend dem Hash-Ergebnis der aufgerufenen URL, sodass jede URL an denselben Backend-Server weitergeleitet wird, kann die Effizienz des Backend-Cache-Servers weiter verbessert werden. Nginx selbst unterstützt url_hash nicht. Wenn Sie diesen Planungsalgorithmus verwenden müssen, müssen Sie das Nginx-Hash-Softwarepaket installieren.
Im HTTP-Upstream-Modul können Sie die IP-Adresse und den Port des Backend-Servers über den Serverbefehl angeben und außerdem den Status jedes Backend-Servers in der Lastausgleichsplanung festlegen. Häufig verwendete Zustände sind:
down, was bedeutet, dass der aktuelle Server vorübergehend nicht am Lastausgleich teilnimmt.
Backup, reservierte Backup-Maschine. Die Backup-Maschine wird angefordert, wenn alle anderen Nicht-Backup-Maschinen ausfallen oder ausgelastet sind, sodass diese Maschine den geringsten Druck hat.
max_fails, die Anzahl der zulässigen Anforderungsfehler, der Standardwert ist 1. Wenn die maximale Anzahl von Malen überschritten wird, wird der durch das Modul „proxy_next_upstream“ definierte Fehler zurückgegeben.
fail_timeout, die Zeit zum Anhalten des Dienstes nach max_fails-Fehlern. max_fails kann zusammen mit fail_timeout verwendet werden.
Beachten Sie, dass der Status des Backend-Servers bei der Lastausgleichsplanung nicht Gewichtung und Backup sein kann, wenn der Lastplanungsalgorithmus ip_hash ist.
5.Server-Konfiguration des virtuellen Hosts Im Folgenden wird die Konfiguration des virtuellen Hosts beschrieben. Es wird empfohlen, den Konfigurationsinhalt des virtuellen Hosts in eine andere Datei zu schreiben und ihn dann über die Include-Direktive einzubinden, was die Wartung und Verwaltung erleichtert.
[html] Ansicht
Klarschrift
server{
listen 80;
Servername 192.168.12.188 www.ixdba.net;
index index.html index.htm index.jsp; /www.ixdba.net
charset gb2312;
Das Server-Flag definiert den Start des virtuellen Hosts, mit listen wird der Service-Port des virtuellen Hosts angegeben, mit server_name wird die IP-Adresse oder der Domänenname angegeben und mehrere Domänennamen werden durch Leerzeichen getrennt . Der Index wird verwendet, um die Standard-Homepage-Adresse für den Zugriff festzulegen, und der Root-Befehl wird verwendet, um das Webseiten-Stammverzeichnis des virtuellen Hosts anzugeben. Dieses Verzeichnis kann ein relativer Pfad oder ein absoluter Pfad sein. Charset wird verwendet, um das Standardcodierungsformat von Webseiten festzulegen.
access_log logs/www.ixdba.net.access.log main;
access_log wird verwendet, um den Zugriffsprotokoll-Speicherpfad dieses virtuellen Hosts und den letzten anzugeben main wird verwendet, um das Ausgabeformat von Zugriffsprotokollen anzugeben. 6. URL-Abgleichskonfiguration
Der URL-Adressabgleich ist der flexibelste Teil der Nginx-Konfiguration. Location unterstützt den Abgleich regulärer Ausdrücke und den Abgleich bedingter Beurteilungen. Benutzer können die Standortanweisung verwenden, um die Nginx-Filterung dynamischer und statischer Webseiten zu implementieren.
Die folgenden Einstellungen werden verwendet, um Webseiten-URLs über die Standortanweisung zu analysieren und zu verarbeiten. Alle statischen Dateien mit den Endungen .gif, .jpg, .jpeg, .png, .bmp und .swf werden an nginx übergeben Für die Verarbeitung wird Expires verwendet, um die Ablaufzeit statischer Dateien anzugeben, hier sind es 30 Tage.
[html] Ansicht
Klarschrift
- Standort ~ .*.(gif|jpg|jpeg|png|bmp|swf)$ {
- root /web/wwwroot/www.ixdba.net;
- läuft 30 Tage ab;
- }
Die folgende Einstellung besteht darin, alle Dateien unter Upload und HTML zur Verarbeitung an Nginx zu übergeben. Natürlich sind die Upload- und HTML-Verzeichnisse in /web/wwwroot/www.ixdba enthalten. Netzverzeichnis Mitte.
[html]-Ansicht
Klarschrift
- Standort ~ ^/(upload|html)/ {
- root /web/wwwroot/ www.ixdba.net;
-
läuft 30 Tage ab >In der letzten Einstellung ist der Standort der Filterprozess für dynamische Webseiten unter diesem virtuellen Host, also alle Dateien mit Das Suffix .jsp wird zur Verarbeitung an den 8080-Port des lokalen Computers übergeben.
[html] Ansicht
Klarschrift
location ~ .*.jsp$ {
index index.jsp; > Proxy_Pass http://localhost:8080; - }
7 🎜>- Das StubStatus-Modul kann den Arbeitsstatus von Nginx seit dem letzten Start abrufen. Dieses Modul ist kein Kernmodul und muss beim Kompilieren und Installieren von Nginx manuell angegeben werden, um diese Funktion zu verwenden.
- Der folgende Befehl gibt tatsächlich an, die Funktion zum Erhalten des Nginx-Arbeitsstatus zu aktivieren.
[html]-Ansicht
Klarschrift
- location /NginxStatus {
- stub_status on;
-
access_log logs/NginxStatus .log; zu „ on“, um die Arbeitsstatus-Statistikfunktion von StubStatus zu aktivieren. access_log wird verwendet, um die Zugriffsprotokolldatei des StubStatus-Moduls anzugeben. auth_basic ist ein Authentifizierungsmechanismus von Nginx. auth_basic_user_file wird verwendet, um die Passwortdatei für die Authentifizierung anzugeben. Da die auth_basic-Authentifizierung eine mit Apache kompatible Passwortdatei verwendet, müssen Sie zum Generieren einer Passwortdatei den Befehl htpasswd von Apache verwenden Die folgende Methode zum Generieren einer Passwortdatei:/usr/local/apache/bin/htpasswd -c /opt/nginx/conf/htpasswd webadmin
erhält die folgende Eingabeaufforderung: - Neues Passwort: Nach der Eingabe des Passworts werden Sie vom System erneut aufgefordert, Ihr Passwort einzugeben. Nach der Bestätigung wurde der Benutzer erfolgreich hinzugefügt.
- Um den Betriebsstatus von Nginx zu überprüfen, können Sie http://ip/ NginxStatus eingeben und dann den Benutzernamen und das Passwort eingeben, die Sie gerade erstellt haben, um die folgenden Informationen anzuzeigen: Aktive Verbindungen: 1 Server akzeptiert bearbeitete Anfragen
393411 393411 393799- Lesen: 0 Schreiben: 1 Warten: 0
Aktive Verbindungen geben die Anzahl der derzeit aktiven Verbindungen an und die drei Zahlen in der Die dritte Zeile zeigt Nginx an. Derzeit wurden insgesamt 393.411 Verbindungen verarbeitet, 393.411 Handshakes erfolgreich erstellt und insgesamt 393.799 Anforderungen verarbeitet. Das Lesen in der letzten Zeile gibt die Anzahl der von Nginx gelesenen Client-Header-Informationen an, das Schreiben gibt die Anzahl der von Nginx an den Client zurückgegebenen Header-Informationen an und „Warten“ gibt die Anzahl der residenten Verbindungen an, deren Verarbeitung Nginx abgeschlossen hat und auf die es wartet nächste Anforderungsanweisung.
In der letzten Einstellung wird die Fehlermeldungs-Rückgabeseite des virtuellen Hosts festgelegt. Die Fehlermeldungs-Rückgabeseite verschiedener Fehlermeldungen kann über die error_page-Direktive angepasst werden. Standardmäßig sucht Nginx im HTML-Verzeichnis des Home-Verzeichnisses nach der angegebenen Rückgabeseite. Es ist besonders wichtig zu beachten, dass die Größe der Rückgabeseite für diese Fehlermeldungen 512 KB überschreiten muss, andernfalls wird sie durch die des IE-Browsers ersetzt Standard-Fehlerseite.
[html] Ansicht
Klarschrift
error_page 404 /404.html;
error_page 500 502 503 504 /50x.html;
Den Originaltext finden Sie im Blog „Technology Makes Dreams“, http://ixdba.blog.51cto.com/ 2895551/790611
Das Obige stellt das Parsen von Nginx-Konfigurationsdateien vor, einschließlich Aspekten des Inhalts. Ich hoffe, es wird für Freunde hilfreich sein, die sich für PHP-Tutorials interessieren.