Résumé et partage des points de connaissances liés à Nginx

Nginx lui-même n'analysera pas PHP. La demande du terminal pour la page PHP sera transmise par Nginx à l'adresse IP et au port surveillés par le processus FastCGI, qui seront traités par php-fpm en tant que serveur d'analyse dynamique. , les résultats du traitement seront renvoyés à nginx. En fait, Nginx est un serveur proxy inverse. Nginx transmet les requêtes dynamiques au backend php-fpm via la fonction de proxy inverse, réalisant ainsi la prise en charge de l'analyse PHP. C'est le principe de Nginx implémentant l'analyse dynamique PHP.

Nginx ne prend pas en charge l'appel direct ou l'analyse de programmes externes. Tous les programmes externes (y compris PHP) doivent être appelés via l'interface FastCGI. L'interface FastCGI est une socket sous Linux (cette socket peut être une socket file ou une socket ip). Pour appeler un programme CGI, un wrapper FastCGI est également nécessaire (un wrapper peut être compris comme un programme utilisé pour démarrer un autre programme. Ce wrapper est lié à un socket fixe, tel qu'un port ou un socket de fichier). Lorsque Nginx envoie une requête CGI à ce socket, le wrapper reçoit la requête via l'interface FastCGI, puis génère un nouveau thread. Ce thread appelle l'interpréteur ou le programme externe pour traiter le script et lire les données de retour. les données renvoyées sont transmises à Nginx via le socket fixe via l'interface FastCGI ; enfin, Nginx envoie les données renvoyées au client.

Le modèle classique est le modèle de pilote asynchrone multi-processus Master-Worker utilisé dans Nginx.

Une fois que le processus parent a créé un socket, s'est lié et a écouté, il crée plusieurs processus enfants via fork. Chaque processus enfant hérite du socket du processus parent et appelle accpet pour commencer à écouter et à attendre les connexions réseau. À l'heure actuelle, plusieurs processus attendent en même temps l'événement de connexion réseau. Lorsque cet événement se produit, ces processus sont réveillés en même temps, ce qui constitue un « choc ». Lorsqu'un processus est réveillé, le noyau doit être reprogrammé afin que chaque processus réponde à cet événement en même temps. En fin de compte, un seul processus peut gérer avec succès l'événement, et les autres processus se mettent en veille ou ne parviennent pas à gérer l'événement. événement.

En fait, après la version Linux 2.6, le noyau a résolu le problème de "choc" de la fonction accept(). Lorsque le noyau reçoit une connexion client, il ne réveillera que le premier processus en attente. file d'attente ou fil de discussion.

Nginx utilise le verrouillage mutex accept_mutexmutex pour résoudre ce problème. Les mesures spécifiques incluent l'utilisation du verrouillage mutex global. Chaque processus enfant demande le verrouillage avant epoll_wait(). obtenez-le, il attendra et mettra en place un algorithme d'équilibrage de charge (lorsque le volume de tâches d'un certain sous-processus atteint 7/8 du volume total défini, plus aucune tentative ne sera faite pour demander des verrous) pour équilibrer le. volume de tâches de chaque processus.

Maintenant, nous résumons le traitement des groupes tonnerre et Nginx comme suit :

• accept ne provoquera pas de groupes tonnerre, mais epoll_wait le fera.

• accept_mutex de Nginx ne résout pas le problème de panique d'acceptation, mais résout le problème de panique d'epoll_wait.

• Il est également faux de dire que Nginx résout le problème de panique d'epoll_wait. Il contrôle uniquement s'il faut ajouter le socket d'écoute à epoll. Le socket d'écoute se trouve uniquement dans l'epoll d'un processus enfant. Lorsqu'une nouvelle connexion arrive, les autres processus enfants ne se réveilleront certainement pas.

Pour faire simple, un seul travailleur nginx est autorisé à gérer le handle d'écoute dans son propre epoll en même temps. Son équilibrage de charge est également très simple. Lorsque 7/8 de la connexion maximale sont atteints, le travailleur n'essaiera pas d'obtenir le verrou d'acceptation et ne traitera pas non plus de nouvelles connexions, de sorte que les autres processus de travail nginx auront plus de possibilités de traiter le. handle d’écoute. Une nouvelle connexion est établie. De plus, en raison du paramétrage du délai d'attente, le processus de travail qui n'a pas obtenu le verrou l'obtiendra plus fréquemment.

Le modèle multi-processus nginx est-il vraiment sans verrouillage ? En fait, il y en a encore un : ngx_accept_mutex.

nginx est un programme multi-processus, et le port 80 est partagé par chaque processus de travail. Chaque fois qu'une connexion est établie, plusieurs processus de travail sont tenus de rivaliser pour répondre. C'est ce qu'on appelle le phénomène du troupeau tonitruant.

Lorsque le noyau accepte un lien, il réveillera tous les processus en attente, mais en fait un seul processus pourra obtenir la connexion, et les autres processus seront réveillés de manière invalide. Ce réveil invalide augmentera sans aucun doute la surcharge de. la demande. À cette fin, nginx fournit un verrou d'acceptation pour éviter la tragédie de neuf fils prenant la relève de l'héritier présomptif.

La fonction de ngx_accept_mutex est de permettre aux processus de travail qui sont actuellement fortement chargés

d'abandonner activement le traitement des nouvelles demandes entrantes, améliorant ainsi l'efficacité globale du réveil du

application, améliorant ainsi les performances globales de l'application.

proxy_cache

upstream

fastcgi_pass

location

Le code d'état non standard 444 signifie fermer la connexion et ne pas envoyer d'en-tête de réponse au client.

La commande nginx -s reload charge le fichier de configuration modifié. Une fois la commande émise, les événements suivants se produisent

1 Le processus maître de Nginx vérifie l'exactitude du fichier de configuration. un message d'erreur est renvoyé et nginx continue de l'utiliser. Le fichier de configuration d'origine fonctionne (car le travailleur n'est pas affecté)

2. Nginx démarre un nouveau processus de travail et adopte le nouveau fichier de configuration

<.>3. Nginx alloue de nouvelles demandes au nouveau processus de travail

4 Nginx attend que toutes les demandes des processus de travail précédents soient renvoyées, puis ferme les processus de travail concernés

5. le processus ci-dessus jusqu'à ce que tous les anciens processus de travail soient fermés

Le processus ci-dessus est basé sur les documents officiels pertinents de nginx.

Prenons proxy_next_upstream comme exemple. La configuration générale est la suivante :

proxy_next_upstream http_504 timeout;

Cette commande a deux fonctions :

1. Dites à nginx que si un délai d'attente de connexion se produit et que l'amont renvoie 504, vous devez réessayer en amont

2. Dites à nginx que http 504, le délai d'attente de connexion est un échec de demande

En général, nginx échoue par défaut pour erreur, timeout, invalid_header Si vous souhaitez traiter d'autres comportements comme des échecs, vous devez ajouter des instructions telles que proxy_next_upstream. Parmi eux, si http_403 et http_404 ne sont pas reconnus, c'est un échec.

Discutez de deux points, la définition de la panne du serveur et le comportement du serveur après une panne.

• Définition de panne de serveur : La définition de panne de module ci-dessus est principalement utilisée pour expliquer dans quelles circonstances une requête échoue, mais qu'est-ce qui définit une panne de serveur ? nginx utilise principalement deux paramètres pour contrôler : max_fails et fail_timeout. En termes simples, si une requête échoue max_fails fois dans fail_timeout, cela signifie que le serveur est actuellement en panne.

• Comportement après échec : Principalement :

• Pendant la période fail_timeout, le serveur ne sera pas sélectionné

Après le délai fail_timeout, le serveur sera marqué comme normal et la logique existante sera répétée.
Ngxin divise le traitement des requêtes clients en 11 étapes

#1 NGX_HTTP_POST_READ_PHASE : Lecture de l'étape du contenu de la requête

#2 NGX_HTTP_SERVER_REWRITE_PHASE : Adresse de la requête du serveur phase de réécriture

#3 NGX_HTTP_FIND_CONFIG_PHASE : Phase de recherche de configuration

#4 NGX_HTTP_REWRITE_PHASE : Phase de réécriture d'adresse de demande de localisation

#5 NGX_HTTP_POST_REWRITE_PHASE : Phase de soumission de réécriture d'adresse de demande

#6 NGX_HTTP_PREACCESS_PHASE : Phase de préparation de la vérification des autorisations d'accès

#7 NGX_HTTP_ACCESS_PHASE : Phase de vérification des autorisations d'accès

#8 NGX_HTTP_POST_ACCESS_PHASE : Phase de soumission de la vérification des autorisations d'accès

#9 NGX_HTTP_TRY_FILES_PHASE : Configuration phase de traitement des fichiers try_files

#10 NGX_HTTP_CONTENT_PHASE : Phase de génération de contenu

#11 NGX_HTTP_LOG_PHASE : Phase de traitement du module de journal

Flux de traitement des requêtes Nginx

#1 Comment Nginx confirme-t-il quel serveur gère la requête ?

1. Utilisez ip + port pour confirmer que le serveur écoute l'adresse IP et le port.

2. Confirmez quel serveur est sélectionné pour traiter la demande en fonction de l'en-tête d'hôte dans la demande.

3. Si aucun serveur ne correspond, la demande sera transférée au serveur par défaut pour traitement

De manière générale, sans aucun paramètre, l'ordre dans le fichier de configuration apparaîtra Le premier serveur. sert de

serveur par défaut.

4. Vous pouvez utiliser l'indicateur default_server sur la commande Listen pour définir un serveur comme

serveur par défaut.

#2 Comment Nginx fait-il correspondre le serveur en fonction de l'en-tête de l'hôte ?

Nginx correspond principalement au serveur en comparant les en-têtes server_name et host dans le serveur.

L'ordre de comparaison est le suivant :

1. Nom exact

2. Le nom générique correspondant le plus long (tel que : *.zhidao.baidu.com) ;

3. Le nom générique de fin le plus long (tel que : zhidao.baidu.*)

#3 Initialiser la requête http, 11 étapes de la requête http

Correspondance d'emplacement commande

~ La ligne ondulée indique qu'une correspondance régulière est effectuée, qui est sensible à la casse.

~* signifie effectuer une correspondance régulière, insensible à la casse.

^~ ^~ signifie une correspondance de caractères ordinaire. Si l'option correspond, seule cette option sera mise en correspondance, et les autres options ne le seront pas. Elle est généralement utilisée pour faire correspondre les répertoires.

= effectue une correspondance exacte des caractères ordinaires.

@ "@" définit un emplacement nommé, utilisé pour l'orientation interne, tel que error_page, try_files.

Exemple :

Exemple d'URI de requête :

• / -> Conforme à la configuration A

• /documents/document.html -> Conforme à la configuration B

• /images/1 .gif -> Conforme à la configuration C

• /documents/1.jpg -> Conforme à la configuration D

Recommandations associées :

Le mécanisme de proxy inverse de Nginx résout les problèmes inter-domaines front-end

Comment Nginx modifie la taille des fichiers téléchargés

Explication de l'opération de séparation dynamique et statique Nginx

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!