提供客户浏览器信息，包括版本号或其他专有数据。
路径信息
该环境变量的值表示紧随CGI程序名之后的其他路径信息。 它经常作为 CGI 程序的参数出现。
请求参数
如果服务器和CGI程序信息的传输方式是GET，则该环境变量的值就是传输的信息。 该信息前面是 CGI 程序名称，两者之间用问号“？”分隔。
远程地址
这个环境变量的值就是发送请求的客户端机器的IP地址，比如之前的192.168.1.67。 该值始终存在。 它是Web客户端需要提供给Web服务器的唯一标记，可以在CGI程序中用来区分不同的Web客户端。
远程主机
该环境变量的值包含发送 CGI 请求的客户端计算机的主机名。 如果不支持你想要查询的内容，则不需要定义这个环境变量。
请求方法
提供如何调用脚本。 对于使用 HTTP/1.0 合约的脚本，只有 GET 和 POST 有意义。
SCRIPT_FILENAME
CGI 脚本的完整路径
SCRIPT_NAME
CGI 脚本的名称
服务器名称
这是您的 Web 服务器的主机名、别名或 IP 地址。
服务器软件
该环境变量的值包含调用CGI程序的HTTP服务器的名称和版本号。 例如里面的值为Apache/2.2.14(Unix)
每当客户请求CGI时，WEB服务器都会请求操作系统生成一个新的CGI类库进程（如php-cgi.exe），一个CGI进程在处理完一个请求后就退出，并在下一个请求到来时重新创建它。 新流程。
事实上，即使在访问很少且没有并发的情况下，这也是可以的。 但是当访问量减少，并发存在的时候，这些方法就不适合了，所以就有了FastCGI
快速CGI
FASTCGI 是 Web 服务器（例如：Nginx）和语言例程（例如：uWsgi）之间的底层通信契约的规范，并且是 CGI 的开放扩展。
CGI的扩展，就像常驻（long-live）CGI一样，不仅废除了CGIfork-and-execute（请求fork一个新进程来处理，处理完后杀死进程）的工作方式，而是使用长寿命的方法可以减少进程消耗并提高性能。
FastCGI首先会fork一个master进程，解析配置文件，初始化执行环境，然后fork多个worker进程（类似Nginx）。 当一个HTTP请求到来时，master进程会将其传递给一个worker进程，然后可以立即接受下一个请求，这样就避免了重复的初始化操作，效率自然就增强了。
但当worker进程不够时，master进程也可以根据配置预先启动几个worker进程并等待； 当空闲工作进程过多时，会关闭一些，这样不仅提高了性能，还节省了系统资源
php-fpm
FastCGI只是一个契约规范，需要各个语言来实现。 PHP-FPM是FastCGI合约的PHP版本的实现。 有了它，就实现了PHP脚本和Web服务器（通常是Nginx）的通信，同时它也是一个PHPSAPI，进而搭建起PHP原语和Web服务器之间的桥梁。
php-fpm的全称是phpfastcgiprocessmanager，即phpfastcgi进程管理器。 与fastcgi静态唤醒cgi相比，fpm可以根据访问压力动态唤醒cgi进程并销毁，动态调整cgi数量，可以有效利用显存。
除此之外，还有其他优点，例如fpm还可以平滑地重新加载php配置； 因为fpm使用Unix-Socket与服务器通信，所以不需要配置cgi端口； fpm有更好的状态输出和slowlog日志，502可以给出更多的错误细节。
PHP-FPM 负责管理一个进程池来处理来自 Web 服务器的 HTTP 动态请求。 在PHP-FPM中，master进程负责与Web服务器通信，接收HTTP请求，然后将请求转发给worker进程处理。 Worker进程主要负责动态执行PHP代码，处理完成后，将处理结果返回给Web服务器，然后Web服务器将结果发送给客户端。这就是PHP-FPM的基本工作原理
WSGI/uwsgi/uWSGI
在Python Web开发中，我们经常使用Uwsgi配合Nginx来部署Web框架，例如Django或flask。 同时我们会说框架和Web服务器必须符合WSGI契约。
那么让我们澄清这些概念。
Web 服务器和 Web 框架
在讲uWSGI和WSGI之前，我们首先要弄清楚Web开发的两大块，Web服务器和Web框架。
Web 服务器是用于接受客户端请求、建立连接和转发响应的程序。 至于转发的内容，会由Web框架来处理，也就是处理那些业务逻辑。 比如查询数据库、生成实时信息等。Nginx是一个Web服务器，而Django或flask是一个Web框架。
那么如何实现uWSGI和WSGI的协作呢？ 任何Web服务器如何与任何框架相匹配？ 这形成了 WSGI 合约。 只要Web服务器和Web框架满足WSGI契约，它们就可以相互协作。 所以WSGI只是一个契约，一个约定。 而不是Python模块、框架等具体功能。
而uWSGI是一个实现WSGI合约的Web服务器。 即用于接受客户端请求并转发响应的程序。 事实上，一个uWSGI Web服务器，再加上Django等Web框架，就已经可以实现网站的功能了。
WSGI
WSGI，（WEBSERVERGATEWAYINTERFACE），Web服务器网段套接字，是Web服务器网段套接字，是Web服务器（如Nginx、uWSGI等）与Web应用程序（如编写的程序）之间通信的规范通过 Flask 框架）。 当前运行在 WSGI 合约上的 Web 框架有 Bottle、Flask、Django
实现了Python Web程序与服务器交互的通用性。 有了这个东西php动态网站开发，web.py或者bottle或者django等Python Web开发框架就可以很方便的部署在不同的Web服务器上，不需要任何特殊的配置（还需要一些小的配置调整）
WSGI合约似乎定义了一个服务器和应用程序前馈规范，即可以有多个服务器实现WSGIserver，也可以有多个实现WSGIapplication的框架，这样你就可以选择服务器和应用程序的任意组合来实现你自己的Web应用。
例如，uWSGI和Gunicorn都是实现WSGIserver契约的服务器，而Django和Flask是实现WSGIapplication契约的Web框架，可以根据项目的实际情况一起使用。
与 Django 一样，Flask 框架也有自己的简单 WSGIserver，通常用于服务器调试。 建议在生产环境中使用其他WSGI服务器。 WSGI服务器有很多选择，包括uWSGI和gunicorn
乌沃斯吉
与WSGI一样，它是一个通信合约
uwsgi合约是uWSGI服务器自己的合约。 它用于定义要传输的信息类型。 每个uwsgipacket的前4个字节是对要传输的信息类型的描述。 与WSGI相比，这是两个不同的东西。
uWSGI（服务器）
它是一个实现了WSGI合约、uwsgi、http等的Web服务器，用于接收后端服务器转发的动态请求，处理后发送给Web应用程序。
无论是apache还是Nginx，它们都不具备解析php等动态语言的功能，而是分配给其他模块。 例如，apache可以说有一个外部php模块。 支持的特别爽，让人感觉apache就像支持php一样。 uwsgi实现了WSGI合约、uwsgi、http等合约。 Nginx中HttpUwsgiModule的作用是与uWSGI服务器进行交互。
uWSGI是一个用C编写的Web服务器，暴露了自己的uwsgi合约。它自带丰富的组件，核心组件包括进程管理、监控、IPC等功能，以及实现应用服务器socket支持多种语言的请求插件以及平台，如WSGI、Rack、LuaWSAPI，网管组件实现负载均衡、代理和推理功能
uWSGI也可以用作中间件。
Nginx+uWGSI
假设我们使用Python的Django框架编写了一个网站，现在我们想要在线运行它，通常需要：
通过 WSGI 合约连接到 uWSGI 服务器的 Django 应用程序。 uWSGI服务器实现WSGI、http和其他合约。 通过uwsgi合约和Nginx服务器，实现http的动态请求、转发和结果。
问题：有了uWGSI，为什么Django还需要Nginx？
一个普通的个人网站，如果访问量不大的话，其实可以由uWSGI和Django组成。 而且一旦访问量太大，客户端请求连接时就需要等待很长时间。 这时候分布式服务器就下来了，我们可以再添加几个Web服务器，这些服务器都可以处理请求。
但是谁来分配客户端的请求连接和Web服务器呢？ Nginx就是这样一个管家，是由它指派的。 这也是Nginx实现的反向代理php动态网站开发，即代理服务器。
