2024-07-12
한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina
[Introduction] : Nginx fournit une variété de prises en charge de proxy inverse de couche application, notamment proxy_pass, uwsgi_pass, fastcgi_pass et scgi_pass, etc. Parmi eux, la directive proxy_pass peut accepter un paramètre URL pour implémenter un proxy inverse pour le protocole HTTP/HTTPS ; uwsgi_pass est utilisé pour proxy vers le serveur d'applications uWSGI ; fastcgi_pass est utilisé pour proxy vers le serveur FastCGI ; à l'application SCGI (Simple Common Gateway Interface). Ces directives permettent à Nginx de gérer de manière flexible différents types de services et d'applications backend. L'objet de cet article est scgi_pass.
SCGI(Simple Common Gateway Interface) proxy estNginx L’une des méthodes de proxy inverse importantes prises en charge. dans,SCGIest une version simplifiéeCGI(Common Gateway Interface), conçu pour fournir un moyen plus efficace de se connecterla toile Serveurs et applications.avec du traditionnelCGIpar rapport à,SCGIEn utilisant des connexions persistantes et un format de protocole simplifié, la surcharge par requête est considérablement réduite.
SCGILe protocole définit une manière standardisée dela toile Transmettez les informations de la demande et recevez des réponses entre le serveur et l'application. Il utilise un format de texte simple pour transmettre les informations d'en-tête de la demande, suivies du corps de la demande (le cas échéant).Cette conception faitSCGIIl est à la fois facile à mettre en œuvre et offre de bonnes performances.
existerla toileDans l'architecture des applications,SCGIA agi commela toileserveur (tel queNginx ) et les applications back-end.quandNginxreçu du clientHTTPSur demande, il peut convertir ces demandes enSCGIformater puis passerSCGILe protocole est envoyé au serveur d'applications back-end.
Cette approche est particulièrement adaptée à ceux qui supportent nativementSCGILangages et frameworks de programmation de protocoles tels quePythonune partie dela toilecadres (par ex.Flup)ouRubisCertains serveurs d'applications (tels queLicorne ).en utilisantSCGI, ces applications peuvent éviterHTTPLa surcharge de l'analyse, directement traitée à partir dela toilerequêtes au serveur, améliorant ainsi les performances globales.
Dans les applications pratiques,SCGILes scénarios d'utilisation incluent, sans s'y limiter :
haute performancela toileApplication : pour les applications qui doivent gérer un grand nombre de requêtes simultanées,SCGIPeut fournir mieux que le traditionnelCGIMeilleure performance.
Processus de longue durée : certaines applications qui doivent conserver leur état ou qui s'exécutent depuis longtemps peuventSCGIetla toileLe serveur maintient une connexion persistante.
Optimisations spécifiques au langage : certains langages ou frameworks de programmation peuvent utiliserSCGImontrer de meilleures performances ou une mise en œuvre plus simple.
par dansNginxutilisé dansscgi_passcommande, les administrateurs peuvent facilement placerHTTPTransmettre la demande au supportSCGI serveur d'applications back-end.Cela simplifie non seulement le processus de configuration, mais offre également des opportunités d'optimisation.la toileLes performances des applications offrent de la flexibilité.
SCGI(Simple Common Gateway Interface) est un protocole simplifiéCGIprotocole, spécialement conçu pourla toile Communication entre le serveur et l'application. Il présente les caractéristiques principales suivantes :
Simplicité:SCGI Le protocole utilise un format de texte simple pour transmettre les informations d'en-tête de requête, ce qui rend la mise en œuvre et le débogage du protocole relativement faciles. La philosophie de conception du protocole est de rester simple tout en offrant des fonctionnalités suffisantes.
Connexions persistantes : versus traditionnellesCGIdifférent,SCGI Prend en charge les connexions persistantes.cela signifie unSCGI Le serveur peut gérer plusieurs requêtes sans créer de nouveau processus ou thread pour chaque requête. Cela réduit considérablement la surcharge des ressources système et améliore les performances globales.
Faible surcharge : grâce àSCGI La conception du protocole est simple et crée peu de surcharge supplémentaire lors du traitement des requêtes.Cela faitSCGIParticulièrement adapté à la gestion d’une concurrence élevéela toileScénarios d'application.
la flexibilité:SCGI Le protocole permet la transmission d'informations d'en-tête arbitraires, ce qui offre aux développeurs une grande flexibilité. Les développeurs peuvent personnaliser les informations d'en-tête selon leurs besoins pour répondre aux exigences d'applications spécifiques.
Indépendance linguistique :SCGI La conception du protocole est indépendante du langage de programmation.Cela signifie qu'il peut être implémenté dans n'importe quel langage de programmation, permettant aux développeurs de choisir le langage qui correspond le mieux aux besoins de leur projet.SCGIserveur.
Bien queSCGIetHTTPsont utilisés pourla toileProtocoles de communication, mais ils présentent des différences significatives dans les objectifs de conception et les scénarios d'utilisation :
Utilisateurs cibles :HTTPLe protocole est principalement utilisé par les clients (tels que les navigateurs) etla toilecommunication entre les serveurs, tandis queSCGIL'accord se concentre surla toileCommunication entre le serveur et les applications backend.
Complexité du protocole :HTTPLe protocole est relativement complexe et contient une grande quantité d'informations d'en-tête et de méthodes pour prendre en charge diversesla toile scène interactive. En revanche,SCGILe protocole est plus simple et contient uniquement les informations nécessaires pour transmettre les demandes et les réponses.
Considérations sur les performances : dansla toileUtilisé entre le serveur et l'applicationSCGIau lieu deHTTPLa surcharge de l'analyse du protocole peut être réduite carSCGI Le format est plus simple et plus direct. Cela peut apporter des améliorations significatives des performances dans les scénarios à forte concurrence.
Gestion des connexions :HTTP/1.1Le concept de connexions persistantes a été introduit, mais dansla toileUtilisé entre le serveur et l'applicationHTTPUne gestion de connexion supplémentaire peut encore être nécessaire.SCGILa prise en charge intégrée des connexions persistantes simplifie ce processus.
scènes à utiliser :HTTPIl s'agit du protocole de base d'Internet et il est applicable à diversla toilescénario de communication.SCGIest principalement utilisé pourla toileCommunication interne entre les serveurs et les applications back-end, en particulier dans les scénarios où un traitement hautes performances est requis.
SCGIetCGI rapideTousCGIUne version améliorée dela toile Performances des applications. Ils présentent certaines similitudes, mais aussi quelques différences clés :
Complexité du protocole :SCGItaux d'accordCGI rapideplus simple.SCGIUtilise un format de texte simple pour transmettre les informations d'en-tête, tandis queCGI rapide Utilisez le format binaire.Cela faitSCGIPlus facile à implémenter et à déboguer, mais peut être légèrement inférieur àCGI rapideperformance.
Multiplexage :CGI rapidePrend en charge la gestion de plusieurs requêtes sur une seule connexion (multiplexage), tandis queSCGI Généralement, une seule requête est traitée par connexion. Cela signifie que dans certains scénarios à forte concurrence,CGI rapidePourrait mieux fonctionner.
Type d'enregistrement :CGI rapidePlusieurs types d'enregistrements sont définis (par ex.STDIN、Sortie standard、STDERRetc.), permettant un contrôle plus fin.SCGIUne approche plus simple est adoptée, se concentrant principalement sur la transmission des demandes et des réponses.
Prise en charge linguistique : en raison deCGI rapide Plus il existe depuis longtemps, plus sa prise en charge est susceptible d'être répandue dans divers langages et frameworks de programmation. Cependant,SCGISa simplicité rend sa mise en œuvre dans certains langages potentiellement plus simple.
Performances : dans la plupart des cas,SCGIetCGI rapide La différence de performances n'est pas significative. Le choix du protocole à utiliser dépend souvent des besoins spécifiques de l'application, de la prise en charge du langage de développement et des préférences personnelles.
existerNginxConfiguration,scgi_passLa directive est utilisée pour transmettre la requête àSCGI Directives clés pour le serveur.il définitNginxà qui la demande doit être transmiseSCGIServeur ou groupe de serveurs.
scgi_passLa syntaxe de base de la commande est la suivante :
scgi_pass address;
dans,addressIl peut se présenter sous les formes suivantes :
Par exemple:scgi_pass localhost:9000;
dans ce cas,NginxLa demande sera transmise au serveur exécuté sur l'hôte local et écoutant sur le port 9000.SCGIserveur.
Par exemple:scgi_pass unix:/tmp/scgi.socket;
ici,Nginxpassera le spécifiéUnixsocket de domaine avecSCGI Communication serveur.Cette méthode est habituellement utiliséeSCGIserveur avecNginxL'exécution sur la même machine peut offrir de meilleures performances.
Par exemple:scgi_pass scgi_backend;
Dans cet usage,scgi_backendest un dansNginx Un groupe de serveurs en amont prédéfini dans le fichier de configuration. Cela vous permet d'implémenter des fonctionnalités avancées telles que l'équilibrage de charge et le basculement.
scgi_passLes instructions sont généralement danslocationutilisé dans les blocs pour gérer desURL chemin. Par exemple:
location /scgi/ {
scgi_pass localhost:9000;
include scgi_params;
}
Dans cet exemple, tout/scgi/Les demandes au début seront transmises au port local 9000.SCGIserveur.
include scgi_params;L'instruction contient un fichier de configuration prédéfini, qui définit une série deSCGI paramètre.Ces paramètres définissentNginxcommentHTTPLes informations de la demande sont converties enSCGIdemander.
Il est à noter quescgi_passLes directives peuvent être combinées avec d'autresNginx Les directives sont utilisées en combinaison pour réaliser des configurations plus complexes.Par exemple, vous pouvez utiliserifInstructions conditionnelles pour sélectionner différentes options en fonction de différentes conditionsSCGIserveur:
location / {
if ($request_method = POST) {
scgi_pass localhost:9001;
}
scgi_pass localhost:9000;
include scgi_params;
}
Dans cet exemple,POSTEELes demandes sont transmises au port 9001, tandis que toutes les autres demandes sont transmises au port 9000.
scgi_passetproxy_passCe sont toutes des instructions de proxy inverse couramment utilisées et elles transmettent toutes les requêtes au serveur backend.
dans,scgi_passConçu pour être utilisé avec un supportSCGIProtocole pour la communication du serveur backend.SCGIest un simplifiéCGIprotocole, conçu pourla toile Communication efficace entre les serveurs et les applications. En revanche,proxy_passest une directive plus générale qui peut être utilisée pour proxy une variété de protocoles, y comprisHTTP、HTTPS、CGI rapideattendez.
Utiliséscgi_passheure,NginxrecevraHTTPLa demande est convertie enSCGIformat puis envoyé au backendSCGI serveur. Au cours de ce processus,Nginx Gérera la conversion du protocole pour garantir que le serveur back-end peut comprendre et traiter correctement la demande.etproxy_passIl est généralement utilisé pour transmettre la requête au serveur backend intacte sans conversion de protocole.
Une autre différence importante réside dans la façon dont il est configuré.scgi_passNécessite généralement de la coopérationscgi_paramdirective à utiliser pour définirSCGI Paramètres requis par le protocole. Par exemple:
location /app/ {
scgi_pass localhost:9000;
include scgi_params;
scgi_param SCRIPT_FILENAME /path/to/app$fastcgi_script_name;
}
Dans cet exemple,include scgi_paramsintroduit prédéfiniSCGIparamètres, tandis quescgi_paramLes directives sont utilisées pour définir des paramètres supplémentaires.
En revanche,proxy_passLa configuration est généralement plus simple et directe :
location /api/ {
proxy_pass http://backend_server;
}
En termes de performances,scgi_passetproxy_pass Chacun a ses propres avantages.Pour une utilisation spécialement conçueSCGIapplication du protocole,scgi_passpeut fournir de meilleures performances car cela éviteHTTP surcharge de protocole. Cependant,proxy_passSa polyvalence le rend plus flexible et peut s'adapter à différents serveurs et protocoles backend.
La sécurité est également un aspect à considérer.parce quescgi_passdédié àSCGI protocole, qui peut offrir une meilleure sécurité dans certains cas car il limite la façon dont il communique avec le serveur backend.etproxy_passEn raison de sa polyvalence, une configuration supplémentaire peut être nécessaire pour assurer la sécurité, notamment lors de la manipulation de données sensibles.
Dans les applications pratiques, choisissez d'utiliserscgi_passtoujoursproxy_pass Cela dépend principalement des caractéristiques et des exigences de l'application backend.Si l'application backend est spécifiquement conçue pour utiliserSCGIaccord, alorsscgi_pass Cela pourrait être un meilleur choix.Si le backend est un standardla toileServeur ou application, non pris en charge ou requisSCGI,Doncproxy_passpeut-être plus approprié.
scgi_passL'instruction estNginxutilisé dans le traitementSCGI (Simple Common Gateway Interface) instructions de base demandées. Son fonctionnement implique plusieurs étapes, depuis la réception d'une demande client jusqu'au renvoi d'une réponse traitée au client.
Tout d'abord, quandNginxReçu d'un clientHTTP Lorsqu'une demande est effectuée, il décidera comment traiter la demande en fonction des règles du fichier de configuration.Si la demande correspond, utilisezscgi_passle bloc de localisation de l'instruction,Nginxva commencerSCGIflux de traitement.
existerSCGIPendant le processus de traitement,NginxDans un premier temps, nous créerons leSCGI Connexion au serveur.Cette connexion peut êtreTCPprise ouUnixSocket de domaine, selonscgi_pass L'adresse spécifiée dans l'instruction. Si un groupe de serveurs en amont est utilisé,NginxUn serveur spécifique est également sélectionné en fonction de l'algorithme d'équilibrage de charge configuré.
Une fois la connexion établie,NginxvolontéHTTPLa demande est convertie enSCGI Format.Ce processus comprend la créationSCGIEn-tête et corps de la requête.SCGIL'en-tête de la requête contient une série de paires clé-valeur qui fournissent des métadonnées sur la requête, telles que la méthode de requête, le chemin, la chaîne de requête, le client.Propriété intellectuelle Adresse etcLa plupart de ces informations proviennent de l'originalHTTPen-têtes de requête, mais peut également inclurescgi_paramParamètres supplémentaires définis par la commande.
SCGI Le format de l'en-tête de la requête est spécifique : il commence par un nombre indiquant la longueur de l'en-tête entier, suivi de deux points, puis d'une série de paires clé-valeur terminées par un caractère nul, et enfin terminée par une virgule.Par exemple, une version simplifiéeSCGIL'en-tête de la requête pourrait ressembler à ceci :
70:CONTENT_LENGTH27SCGI1REQUEST_METHODGETquery_string,
Dans cet exemple, « 70 » représente la longueur totale de l'en-tête, suivie de trois paires clé-valeur :CONTENT_LENGTH、SCGIetREQUEST_METHOD。
Après avoir envoyé l'en-tête de la requête,Nginx Le corps de la demande est envoyé (le cas échéant).pourOBTENIRLes requêtes n'ont généralement pas de corps de requête, mais pourPOSTEEouMETTRERequête, le corps de la requête peut contenir des données de formulaire ou d’autres types de contenu.
SCGI Une fois que le serveur reçoit la demande, il traite la demande et génère une réponse.La réponse est renvoyée via la même connexionNginx。SCGILe format de la réponse est relativement simple. Il comprend des en-têtes et un corps de réponse, séparés par une ligne vide.
NginxreçuSCGIAprès la réponse du serveur, il est reconverti enHTTP Format de réponse.Ce processus comprend l'analyseSCGIEn-têtes de réponse, définis de manière appropriéeHTTPen-têtes de réponse, puis transmettez le corps de la réponse intact au client.
dans tout le processus,Nginx Également responsable de la gestion du cycle de vie de la connexion.Cela inclut la gestion des délais d'attente de connexion, la gestion du pool de connexions (si activékeepalive ), gérer les erreurs réseau, etc. Si une erreur survient lors du traitement,NginxUne réponse d'erreur appropriée sera renvoyée au client en fonction de la configuration.
en outre,scgi_pass Le processus de travail est non bloquant.cela signifieNginxPeut traiter plusieursSCGI requêtes sans créer de nouveau processus ou thread pour chaque requête.Cette conception faitNginxCapacité à gérer efficacement un grand nombre de connexions simultanées.
existerNginxConfiguration moyennescgi_pass L’exemple de base de est relativement simple.Cette configuration permettraNginxTransférer les demandes pour un chemin spécifique versSCGI serveur. Voici un exemple de configuration de base :
Tout d'abord, ouvrezNginxLe fichier de configuration principal, généralement situé dans/etc/nginx/nginx.confou/usr/local/nginx/conf/nginx.conf .Dans ce fichier, nous devonshttpAjouter ou modifier dans un blocservermorceau.
existerserverbloc, nous ajouterons unlocationdirective pour définir à quelles demandes doivent être transmisesSCGI serveur.Par exemple, si nous voulons ajouter tous/scgi/La requête du début est transmise au serveur exécuté sur le port local 9000.SCGIServeur, vous pouvez utiliser la configuration suivante :
http {
server {
listen 80；
server_name example.com；
location /scgi/ {
scgi_pass localhost:9000；
include scgi_params；
}
}
}
Dans cette configuration,listen 80les instructions disentNginxÉcoutez sur le port 80 (standardHTTPport).server_nameLa directive définit le nom de domaine auquel ce bloc serveur doit répondre.
location /scgi/le bloc définit tout/scgi/débutURL Les demandes doivent toutes être traitées.À l'intérieur de ce bloc, nous utilisonsscgi_passcommande à spécifierSCGI L'adresse et le port du serveur. Dans cet exemple,SCGILe serveur s'exécute sur la même machine (localhost) du port 9000.
include scgi_params；L'instruction contient un fichier de configuration prédéfini, qui définit une série deSCGI paramètre.Ces paramètres définissentNginxcommentHTTPLes informations de la demande sont converties enSCGI demander.Généralement, ce fichier se trouve/etc/nginx/scgi_paramsou/usr/local/nginx/conf/scgi_params。
Si tonSCGILe serveur nécessite des paramètres supplémentaires, qui peuvent être utilisésscgi_param commande à définir.Par exemple, si vous devez définirSCRIPT_FILENAMELes paramètres peuvent être configurés comme ceci :
location /scgi/ {
scgi_pass localhost:9000；
include scgi_params；
scgi_param SCRIPT_FILENAME /path/to/your/scripts$fastcgi_script_name；
}
ici,SCRIPT_FILENAMELe paramètre est défini sur le chemin réel du script.$fastcgi_script_nameEst unNginxVariable représentant le nom du script demandé.
Si tonSCGIUtilisation du serveurUnixsocket de domaine à la placeTCPLe port peut être configuré comme ceci :
location /scgi/ {
scgi_pass unix:/tmp/scgi.socket；
include scgi_params；
}
Dans cet exemple,Nginxsera localisé via/tmp/scgi.socketdeUnixsocket de domaine avecSCGICommunication serveur.
Une fois la configuration terminée, vous devez recharger ou redémarrerNginx pour que les modifications prennent effet. Les commandes suivantes peuvent être utilisées :
sudo nginx -s reload
ou
sudo systemctl restart nginx
Cette configuration de base consiste à utiliserscgi_pass Fournit un bon point de départ. En fonction de vos besoins spécifiques, des ajustements et des optimisations supplémentaires peuvent être nécessaires. Par exemple, vous devrez peut-être configurer la mise en mémoire tampon, les délais d'attente ou configurer des groupes de serveurs en amont pour l'équilibrage de charge. Ces options de configuration sont abordées en détail dans les chapitres suivants.
existerNginx , le module amont nous permet de définir un ensemble de serveurs pouvant être utilisés pour l'équilibrage de charge et le basculement.quand avecscgi_passLe module en amont peut être considérablement amélioré lorsqu'il est utilisé conjointement avec des directivesSCGIFlexibilité et fiabilité des agents.
La syntaxe de base du module amont est la suivante :
upstream backend_name {
server address1;
server address2;
# 更多服务器...
}
Dans cette configuration,backend_nameest le nom que vous avez spécifié pour ce groupe de serveurs, qui pourra être utilisé ultérieurementscgi_pass cité dans la directive.chaqueserverLa directive définit l'adresse d'un serveur backend, qui peut êtrePropriété intellectuelleAdresse et numéro de port, qui peuvent également êtreUnixChemin du socket de domaine.
Par exemple, nous pouvons définir un fichier appeléscgi_serversgroupe en amont :
upstream scgi_servers {
server 127.0.0.1:9000;
server 127.0.0.1:9001;
server unix:/tmp/scgi.socket;
}
Après avoir défini en amont, on peutscgi_passUtilisez-le dans la directive :
location /app/ {
scgi_pass scgi_servers;
include scgi_params;
}
donc,NginxLa demande sera distribuée àscgi_serversserveurs du groupe.
Le module en amont fournit une variété d'algorithmes d'équilibrage de charge, qui peuvent être configurés en ajoutant des paramètres après la directive du serveur :
Round-robin (par défaut) : distribuez les requêtes à chaque serveur de manière séquentielle.
Interrogation pondérée : vous pouvez spécifier un poids pour chaque serveur. Les serveurs avec des poids plus élevés reçoivent plus de requêtes. Par exemple:
upstream scgi_servers {
server 127.0.0.1:9000 weight=3;
server 127.0.0.1:9001 weight=1;
}
least_conninstruction:upstream scgi_servers {
least_conn;
server 127.0.0.1:9000;
server 127.0.0.1:9001;
}
ip_hashinstruction:upstream scgi_servers {
ip_hash;
server 127.0.0.1:9000;
server 127.0.0.1:9001;
}
Le module en amont fournit également des fonctions de vérification de l’état du serveur et de basculement.Par exemple, nous pouvons utilisermax_failsetfail_timeoutParamètres pour configurer la détection de défauts :
upstream scgi_servers {
server 127.0.0.1:9000 max_fails=3 fail_timeout=30s;
server 127.0.0.1:9001 max_fails=3 fail_timeout=30s;
}
Dans cette configuration, si un serveur tombe en panne trois fois de suite en 30 secondes,NginxIl sera marqué comme indisponible et aucune autre demande ne lui sera envoyée pendant les 30 prochaines secondes.
De plus, nous pouvons utiliserbackupParamètres pour spécifier un serveur de sauvegarde, qui sera utilisé uniquement lorsque tous les serveurs principaux sont indisponibles :
upstream scgi_servers {
server 127.0.0.1:9000;
server 127.0.0.1:9001;
server 127.0.0.1:9002 backup;
}
En utilisant correctement le module en amont, nous pouvons construire un système hautement disponible et performant.SCGI Cluster d'agents. Cela améliore non seulement les performances globales de l'application, mais améliore également la fiabilité et la tolérance aux pannes du système. Dans les applications pratiques, nous devons choisir des stratégies d'équilibrage de charge et des mécanismes de basculement appropriés en fonction de besoins et de scénarios spécifiques pour obtenir les meilleures performances du système.
En configurationNginxdescgi_passdirective, nous avons deux options principales pour spécifierSCGIAdresse du serveur:Unixsocket de domaine etTCP prise. Les deux méthodes ont leurs propres avantages et inconvénients, et la méthode à choisir dépend des scénarios d'application et des besoins spécifiques.
UnixLes sockets de domaine sont un type de communication inter-processus (CIB ) mécanisme qui permet aux processus sur la même machine de communiquer efficacement.existerNginxConfiguration,Unix L'adresse d'un socket de domaine est généralement représentée sous la forme d'un chemin de fichier. Par exemple:
scgi_pass unix:/tmp/scgi.socket；
utiliserUnix Le principal avantage des sockets de domaine réside dans leurs performances.Puisque la communication s'effectue sur la même machine et n'a pas besoin de passer par la pile de protocoles réseau, doncUnixLes sockets de domaine sont généralement plus petites queTCP Les prises sont plus rapides.ils évitentTCP/IP La surcharge causée par le protocole, telle que l'encapsulation et la décapsulation des paquets de données, le contrôle de la congestion du réseau, etc.Cela faitUnixLes sockets de domaine sont particulièrement adaptés pourNginxetSCGILe serveur fonctionne sur la même machine.
Un autre utiliseUnix L’avantage des sockets de domaine est la sécurité. La communication étant limitée à la machine locale, elle est naturellement immunisée contre les attaques provenant du réseau. De plus, les autorisations du système de fichiers peuvent être utilisées pour contrôler l'accès aux fichiers socket, offrant ainsi une couche de sécurité supplémentaire.
Cependant,Unix Les sockets de domaine ont également leurs limites. Bien évidemment, ils ne peuvent être utilisés que pour la communication inter-processus sur la même machine.siNginxetSCGILe serveur doit fonctionner sur une autre machine, il ne peut donc pas être utiliséUnixsocket de domaine.
En revanche,TCPUtilisation du socketPropriété intellectuelle adresse et numéro de port pour spécifier l’adresse du serveur. Par exemple:
scgi_pass 127.0.0.1:9000；
TCP Le principal avantage des sockets est la flexibilité.elles permettentNginxetSCGI Les serveurs s'exécutent sur différentes machines, ce qui est nécessaire pour les systèmes distribués ou les applications nécessitant une évolutivité horizontale.utiliserTCPsockets, nous pouvons facilement implémenter l'équilibrage de charge, en distribuant les requêtes à plusieursSCGIserveur.
Un autre avantage est queTCP Les sockets facilitent la surveillance et le débogage au niveau du réseau. À l’aide d’outils réseau standard, nous pouvons facilement vérifier l’état de la communication et diagnostiquer les problèmes.
Cependant,TCPLe principal inconvénient des sockets est que les performances sont légèrement inférieures à cellesUnix socket de domaine. Même si elles communiquent sur la même machine, les données doivent passer par la pile complète de protocoles réseau, ce qui entraînera une surcharge supplémentaire.De plus, utilisezTCPLes sockets peuvent nécessiter des considérations de sécurité supplémentaires, telles que la définition de règles de pare-feu, l'utilisation deSSL/TLSCryptage, etc.
Lorsque vous choisissez d'utiliserUnixSockets de domaine toujoursTCPLors de l'utilisation de sockets, les facteurs suivants doivent être pris en compte :
Exigences de performance : si vous recherchez les performances les plus élevées etNginxetSCGILe serveur est sur la même machine et doit être sélectionnéUnixsocket de domaine.
Architecture de déploiement : siNginxetSCGISi le serveur doit fonctionner sur différentes machines ou doit réaliser un équilibrage de charge, vous devez utiliserTCPprise.
Exigences de sécurité : si la sécurité est la principale préoccupation et que la communication entre machines n'est pas requise,UnixLes sockets de domaine peuvent être un meilleur choix.
Évolutivité : s'il est prévu que vous devrez peut-êtreSCGIPour faire évoluer un serveur sur plusieurs machines, utilisezTCPLes sockets seront plus faciles à régler le schéma.
Besoins de débogage et de surveillance : si vous devez utiliser des outils réseau standard pour la surveillance et le débogage,TCPLes prises peuvent être plus adaptées.
En bref,Unixsocket de domaine etTCP Les prises sont tous des choix valables. Votre choix doit être basé sur les besoins spécifiques de votre application, vos exigences de performances et votre environnement de déploiement.Dans de nombreux cas, surtout lorsque l'on recherche des performances élevées et queNginxetSCGILorsque des serveurs cohabitent sur la même machine,Unix Les sockets de domaine peuvent être un meilleur choix. Mais si une plus grande flexibilité ou un déploiement distribué est requis,TCPLes prises sont une option indispensable.
Ce chapitre discutera en détailscgi_passTrois aspects clés de la configuration avancée : les paramètres de délai d'attente, la configuration du tampon et la gestion du pool de connexions.
Le paramètre de délai d'attente est de garantirNginxetSCGI Clé de la fiabilité de la communication entre les serveurs. Une configuration appropriée du délai d'attente peut empêcher les requêtes de se bloquer indéfiniment si un problème survient, tout en fournissant également un temps de traitement suffisant pour les connexions lentes.
NginxFournit plusieursscgi_passInstructions de délai d'attente associées :
tout d'abordscgi_connect_timeout, qui définitNginxetSCGI Le temps d'attente maximum nécessaire au serveur pour établir une connexion. Si la connexion ne peut pas être établie dans le délai imparti,Nginx renverra une erreur. Par exemple:
scgi_connect_timeout 60s；
Cette configuration définit le délai d'expiration de la connexion à 60 secondes.
Deuxièmement,scgi_read_timeoutdésignéNginxdepuisSCGI Délai d'expiration du serveur pour lire les réponses.siSCGI Le serveur n'a transmis aucune donnée pendant ce temps et la connexion sera fermée. Par exemple:
scgi_read_timeout 60s；
enfin,scgi_send_timeoutdéjà configuréNginxVersSCGI Le délai d'expiration pendant lequel le serveur envoie des requêtes.Si dans le délai spécifiéSCGI Le serveur n'a reçu aucune donnée et la connexion sera fermée. Par exemple:
scgi_send_timeout 60s；
Ces paramètres de délai d'attente doivent être ajustés en fonction des besoins de l'application réelle. Pour la plupart des applications, les valeurs par défaut sont suffisantes. Mais pour certaines requêtes de longue durée, il peut être nécessaire d'augmenter ces valeurs de délai d'attente.
Configuration du tampon pour l'optimisationNginxetSCGI Le transfert de données entre les serveurs est essentiel. Des paramètres de tampon raisonnables peuvent améliorer la vitesse de réponse et réduire la consommation de ressources.
scgi_buffer_sizeInstructions pour la mise en lectureSCGI La taille du tampon pour la première partie de la réponse du serveur. Celui-ci contient généralement un petit en-tête de réponse. Par exemple:
scgi_buffer_size 4k；
scgi_buffersDes instructions sont définies pour la lectureSCGI Le nombre et la taille des tampons pour les réponses du serveur. Par exemple:
scgi_buffers 8 4k；
Cette configuration crée 8 tampons de taille 4k.
Si la réponse ne rentre pas entièrement en mémoire, vous pouvez utiliserscgi_max_temp_file_sizeDirective pour limiter la taille maximale des fichiers temporaires :
scgi_max_temp_file_size 1024m；
Cela limite la taille maximale des fichiers temporaires à 1 024 Mo.
Pour les réponses volumineuses, vous pouvez utiliserscgi_busy_buffers_sizeDirective pour limiter la taille du buffer disponible en état occupé :
scgi_busy_buffers_size 8k；
Ces paramètres de tampon doivent être ajustés en fonction des caractéristiques de votre application et des ressources du serveur pour des performances optimales.
La gestion du pool de connexions est optimiséeNginxetSCGI Un autre aspect important de la communication entre serveurs. En réutilisant les connexions, les frais liés à l'établissement de nouvelles connexions peuvent être considérablement réduits et les performances globales améliorées.
scgi_keepaliveDirective de configuration en amontSCGI Nombre maximum de connexions inactives que le serveur peut maintenir actives. Par exemple:
scgi_keepalive 10；
Cette configuration permet à chaque processus de travail de maintenir jusqu'à 10 connexions persistantes inactives.
peut utiliserscgi_http_versioncommande à spécifierNginxutilisé avecSCGIcommunications serveurHTTPVersion du protocole :
scgi_http_version 1.1；
utiliserHTTP/1.1Des connexions de longue durée peuvent être activées, ce qui est essentiel au maintien de l'efficacité du pool de connexions.
De plus, on peut utiliserscgi_next_upstreamDirectives pour contrôler dans quelles circonstances les requêtes doivent être transmises au serveur suivant :
scgi_next_upstream error timeout invalid_header http_500；
Cette configuration spécifie quoi faire lorsqu'une erreur se produit, un délai d'attente se produit, un en-tête non valide est reçu ouHTTP Sur une erreur 500, la requête doit être transmise au serveur suivant.
A écrire
Cet article traite en détailNginxmilieuscgi_passapplication des instructions, avec un accent particulier surPython Configuration et déploiement d'applications.Nous avons d'abord introduitSCGILes caractéristiques et les avantages du protocole ont ensuite été expliqués en profondeur.scgi_pass Syntaxe de base et options de configuration avancées pour les directives.A travers des cas pratiques, montrez commentFlux de PythonConfiguration du cadrescgi_pass, y compris les paramètres de base, l'équilibrage de charge, le regroupement de connexions et la gestion des tampons.
Il se consacre à la recherche technologique depuis plus de 30 ans et maîtrise divers langages tels que java, linux, javascript, php, css, etc. Il a apporté de nombreuses contributions dans le domaine de l'open source. station de documentation pour les développeurs pour partager certains problèmes de développement technologique pour référence future.
