FastCGI is actually a variation of CGI.
1、Understanding the CGI mechanism
The original purpose of a web server was merely to answer requests from clients by
serving files located on a storage device. The client sends a request to download a file
and the server processes the request and sends the appropriate response: 200 OK if
the file can be served normally, 404 if the file was not found, and other variants.
This mechanism has been in use since the beginning of the World Wide Web and it
still is. However, as stated before, static websites are being progressively abandoned
at the expense of dynamic ones that contain scripts that are processed by applications
such as PHP and Python among others. The web serving mechanism thus evolved
into the following:
When a client attempts to visit a dynamic page, the web server receives the request
and forwards it to a third-party application. The application processes the script
independently and returns the produced response to the web server, which then
forwards the response back to the client.
In order for the web server to communicate with that application, the CGI protocol
was invented in the early 1990s.
2、Common Gateway Interface (CGI)
As stated in RFC 3875 (CGI protocol v1.1), designed by the Internet Society (ISOC):
The Common Gateway Interface (CGI) allows an HTTP server and a CGI script to
share responsibility for responding to client requests. […] The server is responsible
for managing connection, data transfer, transport, and network issues related to the
client request, whereas the CGI script handles the application issues such as data
access and document processing.
CGI is the protocol that describes the way information is exchanged between the web
server (Nginx) and the gateway application (PHP, Python, and so on). In practice,
when the web server receives a request that should be forwarded to the gateway
application, it simply executes the command corresponding to the desired application,
for example, /usr/bin/php. Details about the client request (such as the User Agent
and other request information) are passed either as command-line arguments or in
environment variables, while actual data from POST or PUT requests is transmitted
via the standard input. The invoked application then writes the processed document
contents to the standard output, which is recaptured by the web server.
While this technology seems simple and efficient enough at first sight, it comes with
a few major drawbacks, which are discussed as follows:
• A unique process is spawned for each request. Memory and other context
information are lost from one request to another.
• Starting up a process can be resource-consuming for the system. Massive
amounts of simultaneous requests (each spawning a process) could quickly
clutter a server.
• Designing an architecture where the web server and the gateway application
would be located on different computers seems difficult, if not impossible.
3、Fast Common Gateway Interface (FastCGI)
The issues mentioned in the Common Gateway Interface (CGI) section render the
CGI protocol relatively inefficient for servers that are subject to heavy load. The
will to find solutions led Open Market in the mid-90s to develop an evolution of
CGI: FastCGI. It has become a major standard over the past fifteen years and most
web servers now offer the functionality, even proprietary server software such as
Microsoft IIS.
Although the purpose remains the same, FastCGI offers significant improvements
over CGI with the establishment of the following principles:
• Instead of spawning a new process for each request, FastCGI employs
persistent processes that come with the ability to handle multiple requests.
• The web server and the gateway application communicate with the use
of sockets such as TCP or POSIX Local IPC sockets. Consequently, both
processes may be on two different computers on a network.
• The web server forwards the client request to the gateway and receives the
response within a single connection. Additional requests may also follow
without needing to create additional connections. Note that on most web
servers, including Nginx and Apache, the implementation of FastCGI does
not (or at least not fully) support multiplexing(多路复用).
• Since FastCGI is a socket-based protocol, it can be implemented on any
platform with any programming language.
Throughout this chapter, we will be setting up PHP and Python via FastCGI.
Additionally, you will find the mechanism to be relatively similar in the case of
other applications, such as Perl or Ruby on Rails.
Designing a FastCGI-powered architecture is actually not as complex as one might
imagine. As long as you have the web server and the processing application running,
the only difficulty that remains is to establish the connection between both parties.
The first step in that perspective is to configure the way Nginx will communicate
with the FastCGI application. FastCGI compatibility with Nginx is introduced by
the FastCGI module. This section details the directives that are made available by
the module.
4、uWSGI and SCGI
Before reading the rest of the chapter, you should know that Nginx offers two other
CGI-derived module implementations:
• The uWSGI module allows Nginx to communicate with applications through
the uwsgi protocol, itself derived from Web Server Gateway Interface
(WSGI). The most commonly used (if not the unique) server implementing
the uwsgi protocol is the unoriginally named uWSGI server. Its latest
documentation can be found at http://uwsgi-docs.readthedocs.org.
This module will prove useful to Python adepts(能手;专家) seeing as the uWSGI project
was designed mainly for Python applications.
• SCGI, which stands for Simple Common Gateway Interface, is a variant of the
CGI protocol, much like FastCGI. Younger than FastCGI since its specification
was first published in 2006, SCGI was designed to be easier to implement and
as its name suggests: simple. It is not related to a particular programming
language. SCGI interfaces and modules can be found in a variety of software
projects such as Apache, IIS, Java, Cherokee, and a lot more.
There are no major differences in the way Nginx handles the FastCGI, uwsgi and SCGI
protocols: each of these have their respective module, containing similarly named
directives. The following table lists a couple of directives from the FastCGI module,
which are detailed in following sections, and their uWSGI and SCGI equivalents:
Directive names and syntaxes are identical. In addition, the Nginx development
team has been maintaining all three modules in parallel. New directives or directive
updates are always applied to all of them. As such, the following sections will be
documenting Nginx's implementation of the FastCGI protocol, but they also apply to
uWSGI and SCGI.
5、Upstream blocks
With the FastCGI module, and as you will discover in the next chapter with the Proxy
module too, Nginx forwards requests to backend servers. It communicates with
processes using either FastCGI or simply by behaving like a regular HTTP client.
Either way, the backend server (a FastCGI application, another web server, and so on)
may be hosted on a different server in the case of load-balanced architectures:
The general issue with applications (such as PHP) is that they are quite
resource-consuming, especially in terms of CPU. Therefore, you may find
yourself forced to balance the load across multiple servers, resulting in the
following architecture:
In this case, Nginx is connected to multiple backend servers. To establish such a
configuration, a new module comes into play: the upstream module.
5.1、Module syntax
The upstream module allows you to declare named upstream blocks that define
lists of servers:
upstream phpfpm {
server 192.168.0.50:9000;
server 192.168.0.51:9000;
server 192.168.0.52:9000;
}
When defining the FastCGI configuration, connect to the upstream block:
server {
server_name website.com;
location ~* \.php$ {
fastcgi_pass phpfpm;
[…]
}
}
In this case, requests eligible to FastCGI will be forwarded to one of the backend
servers defined in the upstream block.
A question you might ask is, how does Nginx decide which backend server is to be
employed for each request? And the answer is simple: the default method of the
Upstream module is round robin. However, this method is not necessarily the best.
Two requests from the same visitor might be processed by two different servers,
and that could be a problem for many reasons (for example, when PHP sessions are
stored on the backend server and are not replicated across the other servers).
To ensure that requests from a same visitor always get processed by the same backend
server, you may enable the ip_hash option when declaring the upstream block:
upstream phpfpm {
ip_hash;
server 192.168.0.50:9000;
server 192.168.0.51:9000;
server 192.168.0.52:9000;
}
This will distribute requests based on the visitors IP address employing a regular
round robin algorithm.However, be aware that client IP addresses are sometimes
subject to change for various reasons such as dynamic IP refresh, proxy switching,
Tor. Consequently, the ip_hash mechanism cannot fully guarantee that clients will
always be involved to the same upstream server. Alternatively, you may force Nginx
to select the backend server that currently has the last amount of active connections,
through the use of the least_conn directive.
5.2、Server directive
The server directive that you place within upstream blocks accepts several
parameters that influence the backend selection by Nginx:
• weight=n: This lets you indicate a numeric value that will affect the
weight of the backend server. If you create an upstream block with
two backend servers, and set the weight of the first one to 2, it will
be selected twice more often:
upstream php {
server 192.168.0.1:9000 weight=2;
server 192.168.0.2:9000;
}
• max_fails=n: This defines the number of communication failures
that should occur (in the time frame specified with the fail_timeout
parameter below) before Nginx considers the server inoperative.
• fail_timeout=n: This defines the time frame within which the maximum
failure count applies. If Nginx fails to communicate with the backend
server max_fails times over fail_timeout seconds, the server is
considered inoperative.
• down: If you mark a backend server as down, the server is no longer used.
This only applies when the ip_hash directive is enabled.
• backup: If you mark a backend server as backup, Nginx will not make
use of the server until all other servers (servers not marked as backup)
are down or inoperative.
These parameters are all optional and can be used altogether:
upstream phpbackend {
server localhost:9000 weight=5;
server 192.168.0.1 max_fails=5 fail_timeout=60s;
server unix:/tmp/backend backup;
}
相关推荐
#### Introduction The book titled "Lighttpd" by Andre Bogus is a comprehensive guide designed to provide readers with an in-depth understanding of the Lighttpd web server. This guide is particularly ...
Introduction to Distributed System Design 297 Table of Contents 297 Audience and Pre-Requisites 298 The Basics 298 So How Is It Done? 301 Remote Procedure Calls 305 Some Distributed Design ...
win7修复本地系统工具
《自动化专业英语》04-Automatic-Detection-Block(自动检测模块).ppt
《计算机专业英语》chapter12-Intelligent-Transportation.ppt
内容概要:本文详细介绍了基于西门子S7-1200博图平台的3轴伺服螺丝机程序。该程序使用SCL语言编写,结合KTP700组态和TIA V14及以上版本,实现了对X、Y、Z三个轴的精密控制。文章首先概述了程序的整体架构,强调了其在自动化控制领域的高参考价值。接着深入探讨了关键代码片段,如轴初始化、运动控制以及主程序的设计思路。此外,还展示了如何通过KTP700组态实现人机交互,并分享了一些实用的操作技巧和技术细节,如状态机设计、HMI交互、异常处理等。 适用人群:从事自动化控制系统开发的技术人员,尤其是对西门子PLC编程感兴趣的工程师。 使用场景及目标:适用于希望深入了解西门子S7-1200博图平台及其SCL语言编程特点的学习者;旨在帮助读者掌握3轴伺服系统的具体实现方法,提高实际项目中的编程能力。 其他说明:文中提供的代码示例和设计理念不仅有助于理解和学习,还能直接应用于类似的实际工程项目中。
内容概要:本文详细探讨了五种非线性滤波器(卡尔曼滤波(KF)、扩展卡尔曼滤波(EKF)、无迹卡尔曼滤波(UKF)、粒子滤波(PF)和变维卡尔曼滤波(VDKF))在水下长基线定位(LBL)系统中的应用。通过对每种滤波器的具体实现进行MATLAB代码展示,分析了它们在不同条件下的优缺点。例如,KF适用于线性系统但在非线性环境中失效;EKF通过雅可比矩阵线性化处理非线性问题,但在剧烈机动时表现不佳;UKF利用sigma点处理非线性,精度较高但计算量大;PF采用蒙特卡罗方法,鲁棒性强但计算耗时;VDKF能够动态调整状态维度,适合信标数量变化的场景。 适合人群:从事水下机器人(AUV)导航研究的技术人员、研究生以及对非线性滤波感兴趣的科研工作者。 使用场景及目标:①理解各种非线性滤波器的工作原理及其在水下定位中的具体应用;②评估不同滤波器在特定条件下的性能,以便为实际项目选择合适的滤波器;③掌握MATLAB实现非线性滤波器的方法和技术。 其他说明:文中提供了详细的MATLAB代码片段,帮助读者更好地理解和实现这些滤波器。此外,还讨论了数值稳定性问题和一些实用技巧,如Cholesky分解失败的处理方法。
VMware-workstation-full-14.1.3-9474260
DeepSeek系列-提示词工程和落地场景.pdf
javaSE阶段面试题
《综合布线施工技术》第5章-综合布线工程测试.ppt
安川机器人NX100使用说明书.pdf
内容概要:本文详细介绍了将M7120型平面磨床的传统继电器控制系统升级为基于西门子S7-1200 PLC的自动化控制系统的过程。主要内容涵盖IO分配、梯形图设计和组态画面实现。通过合理的IO分配,确保了系统的可靠性和可维护性;梯形图设计实现了主控制逻辑、砂轮升降控制和报警逻辑等功能;组态画面则提供了友好的人机交互界面,便于操作和监控。此次改造显著提高了设备的自动化水平、运行效率和可靠性,降低了维护成本。 适合人群:从事工业自动化领域的工程师和技术人员,尤其是熟悉PLC编程和控制系统设计的专业人士。 使用场景及目标:适用于需要进行老旧设备升级改造的企业,旨在提高生产设备的自动化水平和可靠性,降低故障率和维护成本。具体应用场景包括但不限于金属加工行业中的平面磨床等设备的控制系统改造。 其他说明:文中还分享了一些实际调试中的经验和技巧,如急停逻辑的设计、信号抖动的处理方法等,有助于读者在类似项目中借鉴和应用。
chromedriver-linux64-136.0.7103.48.zip
IMG_20250421_180507.jpg
《网络营销策划实务》项目一-网络营销策划认知.ppt
Lianantech_Security-Vulnerabil_1744433229
MybatisCodeHelperNew2019.1-2023.1-3.4.1
【深度学习部署】基于Docker的BERT模型训练与API服务部署:实现代码复用与模型共享
摘 要 传统办法管理信息首先需要花费的时间比较多,其次数据出错率比较高,而且对错误的数据进行更改也比较困难,最后,检索数据费事费力。因此,在计算机上安装火车票订票系统软件来发挥其高效地信息处理的作用,可以规范信息管理流程,让管理工作可以系统化和程序化,同时,火车票订票系统的有效运用可以帮助管理人员准确快速地处理信息。 火车票订票系统在对开发工具的选择上也很慎重,为了便于开发实现,选择的开发工具为Eclipse,选择的数据库工具为Mysql。以此搭建开发环境实现火车票订票系统的功能。其中管理员管理用户,新闻公告。 火车票订票系统是一款运用软件开发技术设计实现的应用系统,在信息处理上可以达到快速的目的,不管是针对数据添加,数据维护和统计,以及数据查询等处理要求,火车票订票系统都可以轻松应对。 关键词:火车票订票系统;SpringBoot框架,系统分析,数据库设计