简介
用过Django，flask的对上面的几个单词应该都非常熟悉，但是对于他们之间的关系总是会弄混淆，特别是uwsgi和uWSGI这两个，乍一看这俩不是一回事儿嘛。但是其实他们是属于两个不同的东西。下面我们就几个问题来给他们分辨一下各自的区别。
目录
简介
目录
正文
问题一：CGI、WSGI、ASGI、uwsgi、uWSGI分别是什么？
问题二： CGI、WSGI、ASGI、uwsgi、uWSGI之间的关系是怎么样的？
问题三：CGI、WSGI、ASGI、uwsgi、uWSGI各自做了什么？
问题四：为什么要有这么多协议？
总结
正文
问题一：CGI、WSGI、ASGI、uwsgi、uWSGI分别是什么？
CGL：通用网关接口，是Web 服务器运行时外部程序的规范（一种协议，支持多种语言原生写法）
WSGI：Web服务器网关接口，是为Python语言定义的Web服务器和Web应用程序或框架之间的一种简单而通用的接口（一种协议，专门支持Python）
ASGI：异步网关接口，在WSGI的基础上添加对WebSocket的支持 （一种协议）
uwsgi： uWSGI特有的协议，是从SCGI衍生而来的，但使用二进制字符串长度表示，以及一个包含var块（16位长）大小的4字节头部，和几个通用字节。（一种协议）
uWSGI：一个用 C 写的快速应用服务器，支持上述四种协议（一个软件）
问题二： CGI、WSGI、ASGI、uwsgi、uWSGI之间的关系是怎么样的？
从上一个问题可以看出CGI、WSGI、ASGI、uwsgi这四个属于同一类，都是协议，而uWSGI则是实现了这四种协议的一个软件。
CGI+Python≈WSGI
WSGI+WebSocket≈ASGI
问题三：CGI、WSGI、ASGI、uwsgi、uWSGI各自做了什么？
CGI：
（1）Web 客户端的浏览器将URL的第一部分解码与Web服务器相连。
（2）Web 浏览器将URL的其余部分提供给服务器。
（3）Web 服务器将URL转换成路径和文件名。
（4）Web 服务器发送 HTML 和别的组成请求页面的文件给客户。一旦页面内容传送完，
这个连接自动断开。
（5）在客户端，HTML脚本提示用户做动作或输入。当用户响应后，客户请求Web服务器建立一个新的连接。
（6）Web 服务器把这些信息和别的进程变量传送给由HTML以URL的形式指定CGI程序。
（7）CGI 根据输入作出响应，把响应结果传送给 Web 服务器。
（8）Web 服务器把响应的数据传给客户，完成后关闭连接。 [2]
WSGI：
WSGI区分为两个部分：一为“服务器”或“网关”，另一为“应用程序”或“应用框架”。在处理一个WSGI请求时，服务器会为应用程序提供环境信息及一个回调函数（Callback Function）。当应用程序完成处理请求后，透过前述的回调函数，将结果回传给服务器。
所谓的WSGI中间件同时实现了API的两方，因此可以在WSGI服务器和WSGI应用之间起调解作用：从Web服务器的角度来说，中间件扮演应用程序，而从应用程序的角度来说，中间件扮演服务器。“中间件”组件可以执行以下功能：
-
重写环境变量后，根据目标URL，将请求消息路由到不同的应用对象。
-
允许在一个进程中同时运行多个应用程序或应用框架。
-
负载均衡和远程处理，通过在网络上转发请求和响应消息。
-
进行内容后处理，例如应用XSLT样式表。
ASGI：https://asgi.readthedocs.io/en/latest/introduction.html（小编偷懒直接贴官方文档了）
uwsgi：它是一个二进制协议，可以携带任何类型的数据。一个uwsgi分组的头4个字节描述了这个分组包含的数据类型。
每个uwsgi请求生成一个uwsgi格式的响应。
uwsgi包头
struct uwsgi_packet_header {uint8_t modifier1;uint16_t datasize;uint8_t modifier2;
};uwsgi变量
struct uwsgi_var {uint16_t key_size;uint8_t key[key_size];uint16_t val_size;uint8_t val[val_size];
}问题四：为什么要有这么多协议？
在上一篇推文中（HTTP协议理解），我们有提到在网络中我们是通过URL来定位互联网上的资源的，类似于这种：https://www.ietf.org/rfc/rfc2616.txt。可以请求到相应的资源文件，但是再实际情况中，当我们访问一个网页的时候，大多使用的是下面两种方式：
http:www.xxx.xxx/index.php,http:www.xxx.xxx/index.aspx,http:www.xxx.xxx/index.jsp
https://blog.csdn.net/Sean_TS_Wang/article/details/118719349
很明显的可以看出这两个的不同点，前一个是完完全的网络资源路径，而后一个则一串看不懂的符号（其实是有对应解析规则的）
HTTP协议就是对应第一种请求方式，可以将输入的URL解析到对应的位置，并且返回响应资源
CGI则是对应下面这些请求方式：http:www.xxx.xxx/index.php,http:www.xxx.xxx/index.aspx,http:www.xxx.xxx/index.jsp
这些资源文件会根据CGI协议的规定，转化成我们看到的HTML页面，而不是一行行的代码
这种请求方式又过于原生，很容易就被人看出请求文件路径，而且慢（需要一边计算动态资源，一边加载静态资源），不安全。于是乎就有了下面这种请求方式
https://blog.csdn.net/Sean_TS_Wang/article/details/118719349
这种请求方式更为灵活，不容易被人看出请求的资源，而且也可以根据URL动态的生成响应，但是这也意味着路由不能直接访问到我们想要的资源，于是就需要一定的规则，将URL转化成服务端代码可以识别的请求。这就是我们常说的路由解析
这种规则就从FastCGI协议开始。（又多了一种协议，是小编疏忽，没有加上）
有了FastCGI之后，我们就可以将静态资源和动态请求分开来，也就是我们常说的前后端分离。各种后端的框架也就应运而生。于是又暴露出了一个问题，Python每种框架对Web服务器的支持都不一样，基于这个缺点，WSGI就诞生了。
WSGI将Web服务器和Web应用程式分开，这样开发者就可以随意使用自己喜欢的开发框架，而不需要在意框架对Web服务器是否支持，以及支持的成效如何。常见的Web服务器有：Apache，Nginx，IIS
ASGI则是允许上述请求使用WebSocket进行管道通信
到了uwsgi，则是将HTTP转化成二进制文件，目的是为了加快机器解析速率
总结
总的来说，这几个名词贯穿了请求到响应的整个流程，将原本的请求-响应细分成请求-中间件-中间件-响应的流程，让功能更细化。