2024-07-12
한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina
[Introduction]: Nginx provides a variety of application layer reverse proxy support, including proxy_pass, uwsgi_pass, fastcgi_pass and scgi_pass. Among them, the proxy_pass instruction can accept a URL parameter to implement reverse proxy for HTTP/HTTPS protocol; uwsgi_pass is used to proxy to uWSGI application server; fastcgi_pass is used to proxy to FastCGI server; and scgi_pass is used to proxy to SCGI (Simple Common Gateway Interface) application. These instructions enable Nginx to flexibly handle different types of backend services and applications. This article focuses on scgi_pass.
SCGI(Simple Common Gateway Interface) proxy isNginxOne of the important reverse proxy methods supported.SCGIIt is a simplified versionCGI(Common Gateway Interface) protocol, which aims to provide a more efficient way to connectWebServers and applications.CGIcompared to,SCGIBy using persistent connections and a simplified protocol format, the overhead of each request is significantly reduced.
SCGIThe protocol defines a standardized way toWebThe server sends request information to the application and receives responses. It uses a simple text format to transmit the request header information, followed by the request body (if any). This design makesSCGIIt is easy to implement and provides good performance.
existWebIn the application architecture,SCGIActed asWebServer (such asNginx) and back-end applications.NginxReceived from the clientHTTPWhen a request is made, it can convert these requests intoSCGIformat, and then throughSCGIThe protocol is sent to the backend application server.
This approach is particularly suitable for those natively supportedSCGIProtocol programming languages and frameworks, such asPythonSomeWebFramework (e.g.Flup)orRubySome application servers (such asUnicorn).by usingSCGI, these applications can avoidHTTPThe overhead of parsing is directly processed fromWebserver requests, thereby improving overall performance.
In practical applications,SCGIThe usage scenarios include but are not limited to:
high performanceWebApplication: For applications that need to handle a large number of concurrent requests,SCGICan provide more than traditionalCGIBetter performance.
Long-running processes: Some applications that need to maintain state or run for a long time can useSCGIandWebThe server maintains a persistent connection.
Language-specific optimizations: Some programming languages or frameworks may useSCGIbetter performance or simpler implementation.
ByNginxUse inscgi_passcommand, administrators can easilyHTTPRequest forwarded to supportSCGIThis not only simplifies the configuration process, but also provides optimizationWebThe performance of the application provides flexibility.
SCGI(Simple Common Gateway Interface) protocol is a simplifiedCGIprotocol, specifically designed forWebCommunication between the server and the application. It has the following notable features:
Simplicity:SCGIThe protocol uses a simple text format to transmit request header information, which makes the implementation and debugging of the protocol relatively easy. The design philosophy of the protocol is to keep it simple while providing sufficient functionality.
Persistent connection: Compared with traditionalCGIdifferent,SCGISupports persistent connections. This means that aSCGIThe server can handle multiple requests without creating a new process or thread for each request. This greatly reduces the overhead of system resources and improves overall performance.
Low overhead: Due toSCGIThe protocol is designed to be simple and incurs very little overhead in request processing.SCGIEspecially suitable for handling high concurrencyWebApplication scenarios.
flexibility:SCGIThe protocol allows the transmission of arbitrary header information, which provides great flexibility for developers. Developers can customize the header information as needed to meet the requirements of specific applications.
Language independence:SCGIThe protocol is designed to be language agnostic. This means it can be implemented in any programming language, allowing developers to choose the language that best suits their project needs.SCGIserver.
AlthoughSCGIandHTTPAll are used forWebCommunication protocols, but they have significant differences in design purposes and usage scenarios:
Target users:HTTPThe protocol is mainly used by clients (such as browsers) andWebCommunication between servers, andSCGIThe agreement focuses onWebCommunication between the server and the backend application.
Protocol complexity:HTTPThe protocol is relatively complex and contains a lot of header information and methods to support variousWebInteraction scene. In contrast,SCGIThe protocol is much simpler and contains only the necessary information to pass requests and responses.
Performance considerations:WebUsed between the server and the applicationSCGIRather thanHTTPThe overhead of protocol parsing can be reduced becauseSCGIThe format is simpler and more direct. This may bring significant performance improvements in high-concurrency scenarios.
Connection Management:HTTP/1.1Introduced the concept of persistent connections, but inWebUsed between the server and the applicationHTTPAdditional connection management may still be required.SCGINative support for persistent connections simplifies this process.
scenes to be used:HTTPIt is the basic protocol of the Internet and is applicable to variousWebCommunication scenario.SCGIIt is mainly used forWebInternal communication between servers and backend applications, especially in scenarios that require high-performance processing.
SCGIandFastCGIBothCGIAn improved version ofWebThe performance of the application. They have some similarities, but also some key differences:
Protocol complexity:SCGIProtocol RatioFastCGIsimpler.SCGIUse a simple text format to transmit header information, whileFastCGIUse binary format. This makesSCGIEasier to implement and debug, but may be inferior in some casesFastCGIperformance.
Multiplexing:FastCGISupports multiplexing of multiple requests on a single connection.SCGIUsually each connection only handles one request. This means that in some high-concurrency scenarios,FastCGIMight perform better.
Record Type:FastCGIDefines several record types (such asSTDIN、STDOUT、STDERRetc.), allowing for more fine-grained control.SCGIA simpler approach is taken, focusing mainly on the transmission of requests and responses.
Language support: Due toFastCGIHaving been around longer, its support in various programming languages and frameworks may be more widespread. However,SCGIThe simplicity of makes its implementation in some languages potentially more straightforward.
Performance: In most cases,SCGIandFastCGIThe performance difference between the two protocols is not significant. The choice of which protocol to use usually depends on the specific application requirements, development language support, and personal preference.
existNginxIn configuration,scgi_passThe command is used to pass the request toSCGIThe key directive of the server. It definesNginxTo which the request should be forwardedSCGIA server or group of servers.
scgi_passThe basic syntax of the command is as follows:
scgi_pass address;
in,addressIt can be in the following forms:
For example:scgi_pass localhost:9000;
in this case,NginxThe request will be forwarded to the client running on the local host and listening on port 9000SCGIserver.
For example:scgi_pass unix:/tmp/scgi.socket;
here,NginxWill be specifiedUnixDomain sockets andSCGIServer communication. This method is usually usedSCGIServer andNginxRunning on the same machine can provide better performance.
For example:scgi_pass scgi_backend;
In this usage,scgi_backendis aNginxA predefined group of upstream servers in the configuration file. This allows you to implement advanced features such as load balancing and failover.
scgi_passInstructions are usuallylocationUsed in blocks to process specificURLPath. For example:
location /scgi/ {
scgi_pass localhost:9000;
include scgi_params;
}
In this example, all/scgi/All requests starting with 9000 will be forwarded to the local server running on port 9000.SCGIserver.
include scgi_params;The statement contains a predefined configuration file, which sets a series ofSCGIParameters. These parameters defineNginxHow toHTTPRequest information converted toSCGIask.
It is worth noting thatscgi_passInstructions can be used with otherNginxDirectives can be combined to achieve more complex configurations. For example, you can useifConditional statements to select differentSCGIserver:
location / {
if ($request_method = POST) {
scgi_pass localhost:9001;
}
scgi_pass localhost:9000;
include scgi_params;
}
In this example,POSTRequests are forwarded to port 9001, while all other requests are forwarded to port 9000.
scgi_passandproxy_passThese are all commonly used reverse proxy instructions, which forward requests to the backend server.
in,scgi_passDedicated to supportSCGIprotocol for back-end server communication.SCGIIt is a simplifiedCGIProtocol, designed forWebEfficient communication between servers and applications. In contrast,proxy_passis a more general directive that can be used to proxy various protocols, includingHTTP、HTTPS、FastCGIwait.
In usescgi_passhour,NginxWill receiveHTTPThe request is converted toSCGIformat, and then sent to the backendSCGIserver. In this process,NginxIt will handle the protocol conversion to ensure that the backend server can correctly understand and process the request.proxy_passIt is usually used to forward the request to the backend server intact without performing protocol conversion.
Another important difference is in the configuration method.scgi_passUsually requires cooperationscgi_paramCommands are used to setSCGIParameters required by the protocol. For example:
location /app/ {
scgi_pass localhost:9000;
include scgi_params;
scgi_param SCRIPT_FILENAME /path/to/app$fastcgi_script_name;
}
In this example,include scgi_paramsIntroduced predefinedSCGIParameters, andscgi_paramDirectives are used to set additional parameters.
In contrast,proxy_passConfiguration is usually more straightforward:
location /api/ {
proxy_pass http://backend_server;
}
In terms of performance,scgi_passandproxy_passEach has its own advantages. For special design useSCGIApplication of the protocol,scgi_passMay provide better performance because it avoidsHTTPThe protocol overhead. However,proxy_passIts versatility makes it more flexible and can adapt to various back-end servers and protocols.
Security is also an aspect that needs to be considered.scgi_passDedicated toSCGIprotocol, which may provide better security in some cases because it limits how it communicates with the backend server.proxy_passDue to its general nature, additional configuration may be required to ensure security, especially when handling sensitive data.
In actual application, choose to usescgi_passstillproxy_passThis depends mainly on the characteristics and requirements of the backend application. If the backend application is specifically designed to useSCGIagreement, thenscgi_passMight be a better choice. If the backend is a standardWebServer or application not supported or requiredSCGI,Soproxy_passMight be more appropriate.
scgi_passThe instruction isNginxUsed for processingSCGI(Simple Common Gateway Interface) is the core instruction of the request. Its working principle involves multiple steps, from receiving the client request to returning the processed response to the client.
First, whenNginxReceived from a clientHTTPWhen a request is received, it will decide how to handle the request based on the rules in the configuration file.scgi_passThe location block of the directive,NginxIt will startSCGIProcessing flow.
existSCGIIn the processing flow,NginxFirst, we will establishSCGIThe connection to the server. This connection can beTCPSocket orUnixdomain socket, depending onscgi_passThe address specified in the directive. If an upstream server group is used,NginxA specific server is also selected based on the configured load balancing algorithm.
After the connection is established,NginxWillHTTPThe request is converted toSCGIformat. This process involves creatingSCGIRequest header and request body.SCGIThe request header contains a series of key-value pairs that provide metadata about the request, such as the request method, path, query string, clientIPaddress, etc. Most of this information comes from the originalHTTPrequest headers, but may also includescgi_paramAdditional parameters set by the command.
SCGIThe format of the request header is specific: it starts with a number indicating the length of the entire header, followed by a colon, then a series of null-terminated key-value pairs, and finally ends with a comma. For example, a simplifiedSCGIThe request header might look like this:
70:CONTENT_LENGTH27SCGI1REQUEST_METHODGETquery_string,
In this example, "70" indicates the total length of the header, followed by three key-value pairs:CONTENT_LENGTH、SCGIandREQUEST_METHOD。
After sending the request header,NginxThe request body (if any) is sent.GETRequests usually have no request body, but forPOSTorPUTA request body may contain form data or other types of content.
SCGIAfter receiving the request, the server processes it and generates a response. The response is sent back over the same connection.Nginx。SCGIThe response format is relatively simple. It consists of a response header and a response body, separated by a blank line.
NginxreceivedSCGIAfter receiving the server's response, it will be converted back toHTTPresponse format. This process includes parsingSCGIResponse headers, set the appropriateHTTPThe response header is then passed to the client unchanged.
in the whole process,NginxIt is also responsible for managing the lifecycle of the connection. This includes handling connection timeouts, managing connection pools (if enabledkeepalive), handle network errors, etc. If an error occurs during processing,NginxAn appropriate error response will be returned to the client based on the configuration.
in addition,scgi_passThe work process is non-blocking. This meansNginxCan handle multipleSCGIrequests without creating a new process or thread for each request.NginxAble to efficiently handle large numbers of concurrent connections.
existNginxMedium Configurationscgi_passThe basic example is relatively simple. This configuration will allowNginxForwards requests for a specific path toSCGIServer. Here is a basic configuration example:
First, openNginxThe main configuration file, usually located at/etc/nginx/nginx.confor/usr/local/nginx/conf/nginx.confIn this file, we need tohttpAdd or modify within a blockserverpiece.
existserverInside the block, we will add alocationDirectives to define which requests should be forwarded toSCGIFor example, if we want to send all/scgi/The request starting with is forwarded to the server running on local port 9000.SCGIServer, the following configuration can be used:
http {
server {
listen 80；
server_name example.com；
location /scgi/ {
scgi_pass localhost:9000；
include scgi_params；
}
}
}
In this configuration,listen 80Instructions tellNginxListening on port 80 (standardHTTPport).server_nameDirectives define the domain names that this server block should respond to.
location /scgi/The block defines all/scgi/At the beginningURLThe request should be processed. Inside this block, we usescgi_passInstructions to specifySCGIThe server's address and port. In this example,SCGIThe server runs on the same machine (localhost) port 9000.
include scgi_params；The statement contains a predefined configuration file, which sets a series ofSCGIParameters. These parameters defineNginxHow toHTTPRequest information converted toSCGIRequest. Typically, this file is located at/etc/nginx/scgi_paramsor/usr/local/nginx/conf/scgi_params。
If yourSCGIThe server requires additional parameters, which can be usedscgi_paramFor example, if you need to setSCRIPT_FILENAMEParameters can be configured like this:
location /scgi/ {
scgi_pass localhost:9000；
include scgi_params；
scgi_param SCRIPT_FILENAME /path/to/your/scripts$fastcgi_script_name；
}
here,SCRIPT_FILENAMEThe argument is set to the actual path to the script.$fastcgi_script_nameIs aNginxVariable representing the requested script name.
If yourSCGIServer UsageUnixDomain sockets instead ofTCPPorts can be configured like this:
location /scgi/ {
scgi_pass unix:/tmp/scgi.socket；
include scgi_params；
}
In this example,NginxWill be located at/tmp/scgi.socketofUnixDomain sockets andSCGIServer communication.
After the configuration is complete, you need to reload or restartNginxTo make the changes take effect, you can use the following command:
sudo nginx -s reload
or
sudo systemctl restart nginx
This basic configuration usesscgi_passThis provides a good starting point. Depending on your specific needs, you may need to do more tuning and optimization. For example, you may need to configure buffering, timeouts, or set up upstream server groups for load balancing. These configuration options are discussed in detail in subsequent chapters.
existNginxThe upstream module allows us to define a set of servers that can be used for load balancing and failover.scgi_passWhen used in conjunction with directives, upstream modules can be greatly enhancedSCGIFlexibility and reliability of agents.
The basic syntax of the upstream module is as follows:
upstream backend_name {
server address1;
server address2;
# 更多服务器...
}
In this configuration,backend_nameis the name you specify for this group of servers.scgi_passEachserverThe directive defines the address of a backend server, which can beIPAddress plus port number, orUnixThe domain socket path.
For example, we can define ascgi_serversUpstream group:
upstream scgi_servers {
server 127.0.0.1:9000;
server 127.0.0.1:9001;
server unix:/tmp/scgi.socket;
}
After defining the upstream, we canscgi_passUse it in the directive:
location /app/ {
scgi_pass scgi_servers;
include scgi_params;
}
so,NginxThe request will be distributed toscgi_serversThe servers in the group.
The upstream module provides a variety of load balancing algorithms, which can be configured by adding parameters after the server directive:
Round Robin (default): Dispatches requests to each server in sequence.
Weighted round-robin: You can assign a weight to each server, and the server with a higher weight will receive more requests. For example:
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;
}
The upstream module also provides server health checking and failover functionality. For example, we can usemax_failsandfail_timeoutParameters to configure fault detection:
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;
}
In this configuration, if a server fails three times in a row within 30 seconds,NginxIt will be marked as unavailable and no further requests will be sent to it for the next 30 seconds.
In addition, we can also usebackupParameters to specify a backup server, which will be used only when all primary servers are unavailable:
upstream scgi_servers {
server 127.0.0.1:9000;
server 127.0.0.1:9001;
server 127.0.0.1:9002 backup;
}
By using the upstream module properly, we can build a highly available and high-performanceSCGIProxy cluster. This can not only improve the overall performance of the application, but also enhance the reliability and fault tolerance of the system. In actual applications, we should choose appropriate load balancing strategies and failover mechanisms according to specific needs and scenarios to obtain the best system performance.
In configurationNginxofscgi_passWhen specifying a command, we have two main options for specifyingSCGIServer address:UnixDomain sockets andTCPSocket. These two methods have their own advantages and disadvantages, and the choice depends on the specific application scenario and requirements.
UnixDomain sockets are a type of inter-process communication (IPC) mechanism that allows processes on the same machine to communicate efficiently.NginxIn configuration,UnixThe address of a domain socket is usually expressed as a file path. For example:
scgi_pass unix:/tmp/scgi.socket；
useUnixThe main advantage of domain sockets is their performance. Since the communication occurs on the same machine, there is no need to go through the network protocol stack.UnixDomain sockets are usually faster thanTCPSockets are faster. They avoidTCP/IPThe overhead brought by the protocol, such as data packet encapsulation and decapsulation, network congestion control, etc.UnixDomain sockets are particularly suitable forNginxandSCGIThe server is running on the same machine.
Another useUnixThe advantage of domain sockets is security. Since communication is limited to the local machine, it is inherently immune to attacks from the network. In addition, file system permissions can be used to control access to the socket file, providing an additional layer of security.
However,UnixDomain sockets have limitations. Most notably, they can only be used to communicate between processes on the same machine.NginxandSCGIThe server needs to run on a different machine, so it cannot be usedUnixDomain socket.
In contrast,TCPSocket UsageIPThe server address and port number are specified. For example:
scgi_pass 127.0.0.1:9000；
TCPThe main advantage of sockets is flexibility. They allowNginxandSCGIThe servers run on different machines, which is necessary for distributed systems or applications that need to scale out.TCPSockets, we can easily implement load balancing and distribute requests to multipleSCGIserver.
Another advantage is thatTCPSockets make it easier to monitor and debug at the network level. Using standard network tools, we can easily check the communication status and diagnose problems.
However,TCPThe main disadvantage of sockets is that their performance is slightly lower thanUnixDomain sockets. Even when communicating on the same machine, data needs to go through the entire network protocol stack, which will bring some additional overhead. In addition, usingTCPSockets may require additional security considerations, such as setting up firewall rules, usingSSL/TLSEncryption, etc.
When choosing to useUnixDomain sockets orTCPWhen using sockets, the following factors need to be considered:
Performance requirements: If you are looking for the highest performance, andNginxandSCGIIf the server is on the same machine, selectUnixDomain socket.
Deployment architecture: IfNginxandSCGIIf the server needs to run on different machines or load balancing is required, you must useTCPSocket.
Security requirements: If security is the primary concern and cross-machine communication is not required,UnixDomain sockets might be a better choice.
Scalability: If you anticipate that you may need toSCGIThe server is expanded to multiple machines usingTCPSockets would be easier to architect.
Debugging and monitoring needs: If you need to use standard network tools for monitoring and debugging,TCPSockets might be more appropriate.
In conclusion,UnixDomain sockets andTCPSockets are valid choices. The choice should be made based on the specific application needs, performance requirements, and deployment environment. In many cases, especially when high performance is required andNginxandSCGIWhen the servers coexist on the same machine,UnixDomain sockets may be a better choice. However, if greater flexibility or distributed deployment is required,TCPSockets are an indispensable option.
This chapter will discuss in detailscgi_passThere are three key high-level configuration aspects of : timeout settings, buffer configuration, and connection pool management.
The timeout setting is to ensureNginxandSCGIThe key to reliable communication between servers. Proper timeout configuration prevents requests from hanging indefinitely if they encounter problems, while also providing enough processing time for slow connections.
NginxProvides multiplescgi_passRelated timeout instructions:
first of allscgi_connect_timeout, which definesNginxandSCGIThe maximum waiting time for the server to establish a connection. If a connection cannot be established within the specified time,NginxAn error will be returned. For example:
scgi_connect_timeout 60s；
This configuration sets the connection timeout to 60 seconds.
Secondly,scgi_read_timeoutSpecifiedNginxfromSCGIThe timeout for the server to read the response.SCGIIf the server does not transmit any data during this period, the connection will be closed. For example:
scgi_read_timeout 60s；
at last,scgi_send_timeoutalready setupNginxTowardsSCGIThe server sends the request timeout. IfSCGIThe server does not receive any data and the connection will be closed. For example:
scgi_send_timeout 60s；
These timeout settings should be adjusted based on the needs of your application. For most applications, the default values are sufficient. However, for some long-running requests, you may need to increase these timeout values.
Buffer configuration is important for optimizationNginxandSCGIData transmission between servers is crucial. Reasonable buffer settings can improve response speed and reduce resource consumption.
scgi_buffer_sizeCommands used to set and readSCGIThe size of the buffer for the first part of the server's response. This usually contains a small response header. For example:
scgi_buffer_size 4k；
scgi_buffersThe command defines theSCGIThe number and size of the buffers in the server response. For example:
scgi_buffers 8 4k；
This configuration creates eight buffers of 4k in size.
If the response does not fit completely into memory, you can usescgi_max_temp_file_sizeDirective to limit the maximum size of temporary files:
scgi_max_temp_file_size 1024m；
This limits the maximum size of temporary files to 1024MB.
For large responses, you can usescgi_busy_buffers_sizeDirective to limit the size of the buffer available in the busy state:
scgi_busy_buffers_size 8k；
These buffer settings should be tuned based on your application characteristics and server resources to achieve optimal performance.
Connection pool management is optimizedNginxandSCGIAnother important aspect of communication between servers. By reusing connections, the overhead of establishing new connections can be significantly reduced, improving overall performance.
scgi_keepaliveDirectives are used to configure upstreamSCGIThe maximum number of idle connections that the server can keep. For example:
scgi_keepalive 10；
This configuration allows each worker process to maintain a maximum of 10 idle keep-alive connections.
can usescgi_http_versionInstructions to specifyNginxUsed withSCGIServer communicationHTTPProtocol Version:
scgi_http_version 1.1；
useHTTP/1.1Persistent connections can be enabled, which is essential to keep the connection pool efficient.
In addition, you can usescgi_next_upstreamDirectives to control under what circumstances the request should be passed to the next server:
scgi_next_upstream error timeout invalid_header http_500；
This configuration specifies what to do if an error occurs, a timeout occurs, an invalid header is received, or aHTTP In case of a 500 error, the request should be passed to the next server.
To be written
This article discusses in detailNginxmiddlescgi_passApplication of the directive, with a particular focus onPythonApplication configuration and deployment. We first introducedSCGIThe characteristics and advantages of the protocol, and then explained in depthscgi_passThe basic syntax and advanced configuration options of the command. Through actual examples, it shows how toPython FlupFramework Configurationscgi_pass, including basic settings, load balancing, connection pools and buffer management.
I have devoted myself to the research of technology for more than 30 years. I am proficient in various languages such as Java, Linux, JavaScript, PHP, CSS, etc. I have made many contributions in the field of open source. I have established a developer documentation site to share some problems in technology development for everyone to read.
