标签：CGI Web WSGI ASGI Nginx 服务器 uWSGI
CGI、WSGI、uWSGI、ASGI概念和Django项目部署架构的关系
CGI（Common Gateway Interface）通用网关接口
顾名思义，CGI（Common Gateway Interface）通用网关接口，它是一个协议，是外部应用程序（CGI 程序）与Web服务器之间的接口标准，该协议定义了 Web 服务器调用外部应用程序的时候需要输入的参数以及给Web服务器的返回结果。
通俗地讲，它规定一个程序应当如何与Web服务器程序进行通信，让这个程序可以跑在Web服务器上。
起源： 最早的Web服务器只是简单地响应浏览器发来的http请求，并将存储在服务器上的html文件返回给浏览器，也就是静态的HTML。这个场景下的服务器一般被称为 HTTP 服务器，常见的有Apache的httpd和Nginx。
时代进步，技术也在发展，网站开始越来越复杂，所以出现动态技术。但是服务器并不能直接运行 php、asp这样的文件。既然自己做不了，那就外包给别人吧，前提是要与第三方协商好一个约定：我给你什么，然后你给我什么，也就是我把请求参数发送给你，然后我接收你的处理结果给客户端。
这个约定就是 Common Gateway Interface，简称 CGI。这个协议可以用 VB、C、PHP、Python 来实现。CGI只是接口协议，根本不是什么语言。
发展：引入了CGI，客户端请求能够触发Web服务器去运行另一个外部程序，客户端所发送的请求数据也会传给这个外部程序，该程序运行结束后会将生成的 HTML 和其他数据通过Web服务器再返回给客户端（即动态请求，比如基于 PHP、Python、Java 实现的应用）。利用 CGI 可以针对用户请求，动态返回给客户端各种各样动态变化的信息。
工作原理：Web服务器与CGI程序的交互
Web 服务器将根据CGI程序的类型决定数据向CGI程序传送的方式，一般是通过标准输入/输出流和环境变量来与 CGI 程序间传递数据。如下图所示：
环境变量是由操作系统提供的，它们定义了程序的执行环境，应用程序可以存取它们。 Web服务器和CGI接口又另设置了一些环境变量，用来向 CGI 程序传递一些重要的参数。
常用 CGI 环境变量：
| 变量名 | 描述 |
|---|---|
| CONTENT_TYPE | 这个环境变量的值指示所传递来的信息的MIME类型。目前，环境变量CONTENT_TYPE一般都是：application/x-www-form-urlencoded,他表示数据来自于HTML表单。 |
| CONTENT_LENGTH | 如果服务器与CGI程序信息的传递方式是POST，这个环境变量即使从标准输入STDIN中可以读到的有效数据的字节数。这个环境变量在读取所输入的数据时必须使用。 |
| HTTP_COOKIE | 客户机内的 COOKIE 内容。 |
| HTTP_USER_AGENT | 提供包含了版本数或其他专有数据的客户浏览器信息。 |
| PATH_INFO | 这个环境变量的值表示紧接在CGI程序名之后的其他路径信息。它常常作为CGI程序的参数出现。 |
| QUERY_STRING | 如果服务器与CGI程序信息的传递方式是GET，这个环境变量的值即使所传递的信息。这个信息就跟在CGI程序名的后面，两者中间用一个问号’?’分隔。 |
| REMOTE_ADDR | 这个环境变量的值是发送请求的客户机的IP地址，例如上面的192.168.1.67。这个值总是存在的。而且它是Web客户机需要提供给Web服务器的唯一标识，可以在CGI程序中用它来区分不同的Web客户机。 |
| REMOTE_HOST | 这个环境变量的值包含发送CGI请求的客户机的主机名。如果不支持你想查询，则无需定义此环境变量。 |
| REQUEST_METHOD | 提供脚本被调用的方法。对于使用 HTTP/1.0 协议的脚本，仅 GET 和 POST 有意义。 |
| SCRIPT_FILENAME | CGI脚本的完整路径 |
| SCRIPT_NAME | CGI脚本的的名称 |
| SERVER_NAME | 这是你的 WEB 服务器的主机名、别名或IP地址。 |
| SERVER_SOFTWARE | 这个环境变量的值包含了调用CGI程序的HTTP服务器的名称和版本号。例如，上面的值为Apache/2.2.14(Unix) |
每当客户端请求CGI的时候，Web服务器就向操作系统请求生成一个新的CGI解释器进程（如 php-cgi.exe），CGI的一个进程处理完一个请求后退出，下一个请求来时再创建新进程。
当然，这样在访问量很少、没有并发的情况还行。但是当访问量增大，并发存在，这种方式就不适合了，于是就有了FastCGI
FastCGI
FastCGI是Web服务器（例如Nginx）和语言解释器（例如 uWsgi）两者底层的通信协议的规范，是对CGI的拓展。它像是一个常驻（long-live）型的CGI ，废除了 CGI fork-and-execute（来一个请求 fork 一个新进程处理，处理完再把进程 kill 掉）的工作方式，转而使用一种较长生存期的方法，减少进程消耗，提升了性能。
FastCGI 会先 fork 一个 master 进程，解析配置文件，初始化执行环境，然后再 fork 多个 worker 进程（与 Nginx 有点像），当 HTTP 请求过来时，master 进程将其会传递给一个 worker 进程，然后立即可以接受下一个请求，这样就避免了重复的初始化操作，效率自然也就提高了。当 worker 进程不够用时，master 进程还可以根据配置预先启动几个 worker 进程等着；当空闲 worker 进程太多时，也会关掉一些，这样不仅提高了性能，还节约了系统资源。
但是，FastCGI仍然只是一个协议规范，需要每种编程语言去实现。
例如PHP-FPM 就是 PHP 版本的 FastCGI 协议实现，有了它，就是实现 PHP 脚本与 Web 服务器（通常是 Nginx）之间的通信，同时它也是一个 PHP SAPI，从而构建起 PHP 解释器与 Web 服务器之间的桥梁。这里就不展开讲了，下面的才是重头戏。
WSGI / uwsgi / uWSGI
在 Python Web 开发中，我们经常使用 Uwsgi 配合 Nginx 部署一个 Web 框架，如 Django 或 flask。同时我们又会说，框架和 Web 服务器之间要符合 WSGI 协议。
那就来厘清一下这几个概念。
Web 服务器和 Web框架
讲 uWSGI 和 WSGI和uWSGI 之前，先要弄清楚Web开发的两大块Web服务器和Web框架。
Web服务器即用来接受客户端请求，建立连接，转发响应的程序。至于转发的内容是什么，交由Web框架来处理，即处理这些业务逻辑。如查询数据库、生成实时信息等。Nginx就是一个Web服务器，Django或flask就是Web框架。
WSGI
WSGI，（WEB SERVER GATEWAY INTERFACE），Web服务器网关接口，是一种Web服务器网关接口，它是一个Web服务器（如Nginx，uWSGI等服务器）与Web应用（如Flask框架写的程序）通信的一种规范。当前运行在WSGI协议之上的Web框架有Bottle，Flask，Django
实现了Python Web程序与服务器之间交互的通用性。有了这个东西，web.py或者bottle或者django等等的Python Web开发框架，就可以轻松地部署在不同的Web server上了，不需要做任何特殊配置（也需要一些小小的配置调整）
WSGI协议其实是定义了一种server与application解耦的规范，即可以有多个实现WSGI server的服务器，也可以有多个实现WSGI application的框架，那么就可以选择任意的server和application组合实现自己的Web应用。
例如 uWSGI和 Gunicorn都是实现了WSGI server协议的服务器，Django，Flask是实现了WSGI application协议的Web框架，可以根据项目实际情况搭配使用。
像Django，Flask框架都有自己实现的简单的WSGI server，一般用于服务器调试，生产环境下建议用其他WSGI server，WSGI服务器的选择很多，包括uWSGI和gunicorn
uWSGI
同WSGI一样是一种通信协议
它是实现了WSGI协议的一个Web服务器。即用来接受客户端请求，转发给响应的程序。实际上，一个uWSGI的Web服务器，再加上Django这样的Web框架，就已经可以实现网站的功能了
uWSGI (服务器)
它是一个Web服务器，它实现了WSGI协议、uwsgi、http等协议。用于接收前端服务器转发的动态请求并处理后发给 Web 应用程序。
因为apache也好，Nginx也罢，它们自己都没有解析动态语言如php的功能，而是分派给其他模块来做，比如apache就可以说内置了php模块，支持的非常爽，让人感觉好像apache就支持php一样。uwsgi实现了WSGI协议、uwsgi、http等协议。Nginx中HttpUwsgiModule的作用是与uWSGI服务器进行交换。
uWSGI是使用C编写的，显示了自有的uwsgi协议的Web服务器。它自带丰富的组件，其中核心组件包含进程管理、监控、IPC等功能，实现应用服务器接口的请求插件支持多种语言和平台，比如WSGI、Rack、Lua WSAPI，网管组件实现了负载均衡、代理和理由功能
uWSGI也可以当做中间件。
- 如果是Nginx+uWSGI+App，那uWSGI就是一个中间件
- 如果是uWSGI+App，那它就是服务器
Nginx+uWGSI
假设我们使用 Python 的 Django 框架写了一个网站，现在要将它挂在网上运行，我们一般需要：
- Nginx 做为代理服务器：负责静态资源发送（js、css、图片等）、动态请求转发以及结果的回复。
- uWSGI 做为后端服务器：负责接收 Nginx 转发的请求并处理后发给 Django 应用以及接收 Django 应用返回信息转发给 Nginx。
- Django 应用收到请求后处理数据并渲染相应的返回页面给 uWSGI 服务器。
一个Django应用，通过WSGI协议连接uWSGI服务器，uWSGI服务器实现WSGI、http等协议，通过uwsgi协议和Nginx服务器实现http的动态请求和转发以及结果
问题：有 uWGSI 了，Django 为什么还需要 Nginx？
一个普通的个人网站，访问量不大的话，当然可以由 uWSGI 和 Django 构成。但是一旦访问量过大，客户端请求连接就要进行长时间的等待。这个时候就出来了分布式服务器，我们可以多来几台 Web 服务器，都能处理请求。
但是谁来分配客户端的请求连接和 Web 服务器呢？Nginx 就是这样一个管家的存在，由它来分配。这也就是由 Nginx 实现反向代理，即代理服务器。
Nginx 是一个 HTTP 和反向代理服务器
- 正向代理：正向的就是由浏览器主动的向代理服务器发出请求，经代理服务器做出处理后再转给目标服务器
- 反向代理：反向的就是不管浏览器同不同意，请求都会经过代理服务器处理再发给目标服务器
使用Nginx作为反向代理服务器的好处：
- 安全
不管什么请求都要经过代理服务器，可以避免外部程序直接攻击Web服务器
- 负载均衡
根据请求情况和服务器负载情况，将请求分配给不同的Web服务器，保证服务器性能
- 提高Web服务器的IO性能
请求从客户端传到Web服务器是需要时间的，传递多长时间就会让这个进程阻塞多长时间，而通过反向代理，就可以由反向代理完整接受该请求，然后再传给Web服务器，从而保证服务器性能，而且有的一些简单的事情（比如静态文件）可以直接由反向代理处理，不经过Web服务器
总结
- WSGI是一种通信协议
- uwsgi是一种通信协议，常用于在uWSGI服务器与其他网络服务器的数据通信
- uWSGI是实现了uwsgi和WSGI两种协议的Web服务器
ASGI
异步网关协议接口，一个介于网络协议服务和Python应用之间的标准接口，能够处理多种通用的协议类型，包括HTTP，HTTP2和WebSocket。
然而目前的常用的WSGI主要是针对HTTP风格的请求响应模型做的设计，并且越来越多的不遵循这种模式的协议逐渐成为Web编程的标准之一，例如WebSocket。
ASGI尝试保持在一个简单的应用接口的前提下，提供允许数据能够在任意的时候、被任意应用进程发送和接受的抽象。并且同样描述了一个新的，兼容HTTP请求响应以及WebSocket数据帧的序列格式。允许这些协议能通过网络或本地socket进行传输，以及让不同的协议被分配到不同的进程中。
WSGI和ASGI的区别
WSGI是基于HTTP协议模式的，不支持WebSocket，而ASGI的诞生则是为了解决Python常用的WSGI不支持当前Web开发中的一些新的协议标准。同时，ASGI对于WSGI原有的模式的支持和WebSocket的扩展，即ASGI是WSGI的扩展。
Django框架的服务器架构
Django框架的服务器架构一般是 Nginx + uWSGI + Django，那么问题来了
有 uWGSI 了，Django 为什么还需要 Nginx？
前面提到的Django框架自带的uwsgi模块：
wsgiref模块：
这个模块监听8000端口，把Http请求，根据WSGI协议，转换application函数中的environ参数，然后调用application函数。 wsgiref会把application函数提供的响应头设置转换为HTTP协议的响应头，把application的返回（return）作为响应体，根据HTTP协议，生成响应，返回给浏览器。
但是它结构太简单，最后也就是只适合用于测试和学习的简单WSGI服务器模块。
Django 本身提供了runserver，为什么不能用来部署？而是使用nginx+uWSGI部署？
- runserver 方法是调试Django 时经常用到的运行方式，它使用Django 自带的WSGI Server 运行，主要在测试和开发中使用，并且runserver 开启的方式也是单进程。
- uWSGI 是一个Web 服务器，它实现了WSGI 协议（web服务网关接口）、uwsgi（线路协议）、http 等协议。
- 注意uwsgi 是一种通信协议，而uWSGI 是实现uwsgi 协议和WSGI 协议的Web 服务器。uWSGI 具有超快的性能、低内存占用和多app 管理等优点，并且搭配着Nginx 就是一个生产环境了，能够将用户访问请求与应用app 隔离开，实现真正的部署。相比来讲，支持的并发量更高，方便管理多进程，发挥多核的优势，提升性能。
为什么要使用Nginx 来做负载均衡？
Nginx能做什么：
安全（Nginx 作为专业服务器，暴露在公网相对比较安全）能更好地处理静态资源（一些http request header）Nginx也可以缓存一些动态内容Nginx可以更好地配合CDN可以进行多台机器的负载均衡
当然，如果访问量不大，其实也没必要加个Nginx，uWSGI足以胜任。
Nginx 和uWISG 服务器之间如何配合工作的？
（1）首先浏览器发起http 请求到nginx 服务器
（2）Nginx 根据接收到请求包，进行url 分析，判断访问的资源类型，如果是静态资源，直接读取静态资源返回给浏览器
（3）如果请求的是动态资源就转交给uwsgi服务器，uwsgi 服务器根据自身的uwsgi 和WSGI 协议，找到对应的Django 框架。
（4）Django 框架下的应用进行逻辑处理后，将返回值发送到uwsgi 服务器，然后uwsgi 服务器再返回给nginx。
（5）最后nginx将返回值返回给浏览器进行渲染显示给用户。
标签：CGI,Web,WSGI,ASGI,Nginx,服务器,uWSGI 来源： https://www.cnblogs.com/starkzz/p/16530847.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。