Maison >Opération et maintenance >Nginx >Comment gérer les requêtes à l'aide de Nginx

Comment gérer les requêtes à l'aide de Nginx

(*-*)浩
(*-*)浩original
2019-11-27 15:22:412626parcourir

Comment gérer les requêtes à l'aide de Nginx

Nginx utilise un modèle multi-processus pour fournir des services externes, notamment un processus maître et plusieurs processus de travail. Le processus maître est responsable de la gestion de Nginx lui-même et des autres processus de travail.

Toute la logique de traitement métier réelle se trouve dans le processus de travail. Il existe une fonction dans le processus de travail qui exécute une boucle infinie, traitant en continu les demandes reçues du client et les traitant jusqu'à ce que l'ensemble du service Nginx soit arrêté. (Apprentissage recommandé : nginx utilise ) Dans le

processus de travail, la fonction ngx_worker_process_cycle() est la fonction de traitement de cette boucle infinie.

Dans cette fonction, le flux de traitement simple d'une requête est le suivant :

Le mécanisme fourni par le système d'exploitation (comme epoll, kqueue, etc.) génère des événements associés.

Recevoir et traiter ces événements. Si des données sont reçues, un objet de requête de niveau supérieur est généré.

Traitez l'en-tête et le corps de la requête.

Produit une réponse et la renvoie au client.

Traitement complet de la demande.

Réinitialisez les minuteries et autres événements.

Processus de traitement des demandes

Afin de permettre à tout le monde de mieux comprendre le processus de traitement des demandes dans Nginx, nous prenons la requête HTTP comme exemple pour l'expliquer en détail.

Depuis Nginx, le traitement d'une requête HTTP implique les étapes suivantes.

Initialiser la requête HTTP (lire les données du client et générer un objet de requête HTTP, qui contient toutes les informations de la requête).

Traitement des en-têtes de requêtes.

Traitez le corps de la demande.

Invoquez le gestionnaire associé à cette requête (URL ou emplacement), le cas échéant.

Appelez chaque gestionnaire de phase dans l'ordre pour le traitement.

Ici, nous devons comprendre le concept de gestionnaire de phase. Phase signifie littéralement étape. Les gestionnaires de phases sont donc faciles à comprendre, ce sont des gestionnaires qui contiennent plusieurs étapes de traitement.

Dans chaque étape, il y a plusieurs gestionnaires. Lorsque le traitement atteint une certaine étape, les gestionnaires de cette étape sont appelés à tour de rôle pour traiter la requête HTTP.

Normalement, un gestionnaire de phase traite cette requête et produit un résultat. Habituellement, un gestionnaire de phase est associé à un emplacement défini dans un fichier de configuration.

Un gestionnaire de phase effectue généralement les tâches suivantes :

Obtenir la configuration de l'emplacement.

Produit une réponse appropriée.

Envoyer l'en-tête de réponse.

Envoyer le corps de la réponse.

Lorsque Nginx lit l'en-tête d'une requête HTTP, Nginx recherche d'abord la configuration de l'hôte virtuel associé à la requête. Si la configuration de cet hôte virtuel est trouvée, alors généralement, cette requête HTTP passera par les étapes de traitement suivantes (gestionnaires de phases) :

NGX_HTTP_POST_READ_PHASE : Phase de lecture du contenu de la requête

NGX_HTTP_SERVER_REWRITE_PHASE : Phase de réécriture de l'adresse de la demande du serveur

NGX_HTTP_FIND_CONFIG_PHASE : Phase de recherche de configuration :

NGX_HTTP_REWRITE_PHASE : Phase de réécriture de l'adresse de la demande de localisation

NGX_HTTP_POST_REWRITE_P HASE : Phase de soumission de la réécriture de l'adresse de la demande

NGX_HTTP_POST_REWRITE_P HASE : Phase de soumission de la réécriture de l'adresse de la demande

NGX_HTTP_CONTENT_PHASE : Phase de génération de contenu

NGX_HTTP_LOG_PHASE : Phase de traitement du module de journalisation

Dans la phase de génération de contenu, afin de générer une réponse correcte à une requête, Nginx doit envoyer cette requête Quitter à un gestionnaire de contenu approprié pour le gérer.

Si l'emplacement correspondant à cette requête est explicitement spécifié en tant que gestionnaire de contenu dans le fichier de configuration, alors Nginx peut directement trouver le gestionnaire correspondant en faisant correspondre l'emplacement et transmettre la requête au gestionnaire de contenu pour qu'il la traite. Ces directives de configuration incluent perl, flv, proxy_pass, mp4, etc.

Si l'emplacement correspondant à une requête n'a pas directement de gestionnaire de contenu configuré, alors Nginx essaiera dans l'ordre :

Si un emplacement a random_index configuré, alors sélectionner au hasard Un fichier envoyé au client.

Si une directive d'index est configurée dans un emplacement, alors le fichier spécifié par la directive d'index est envoyé au client.

Si l'autoindexation est configurée dans un emplacement, alors la liste des fichiers sous le chemin du serveur correspondant à l'adresse de la demande sera envoyée au client.

Si gzip_static on est défini sur l'emplacement correspondant à cette requête, alors vérifiez si un fichier .gz correspondant existe, et si c'est le cas, envoyez-le au client (si le client prend en charge gzip).

Si l'URI demandé correspond à un fichier statique, le module statique enverra le contenu du fichier statique au client.

Une fois la phase de génération de contenu terminée, la sortie générée sera transmise au module de filtrage pour traitement.

Le module de filtrage est également lié à l'emplacement. Tous les modules installateurs sont organisés en chaîne. La sortie passera par tous les filtres en séquence jusqu'à ce qu'une valeur de retour du module de filtre indique que le traitement est terminé.

Voici quelques modules de filtrage courants, par exemple :

inclut côté serveur.

Filtrage XSLT.

Mise à l'échelle de l'image, etc.

compression gzip.

Parmi tous les filtres, il existe plusieurs modules de filtrage qui nécessitent une attention particulière. Les instructions sont les suivantes dans l'ordre des appels :

write : écriture de la sortie sur le client, en écrivant en fait sur le socket correspondant à la connexion.

reporter : ce filtre est responsable de la sous-requête, c'est-à-dire de la sous-requête.

copie : copiez certains bufs (fichiers ou mémoire) qui doivent être copiés, puis transmettez-les au filtre corporel restant pour traitement.

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!

Déclaration:
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn