wsgi 接口规范

wsgi 『 Web Server Gateway Interface 』 是为 python 语言定义的一种在 web 服务器上和 web 应用程序、框架之间定义的一种通用接口。在 wsgi 之后，很多其他语言也出现了类似的接口。官方对其的解释是： the Python Web Server Gateway Interface 。

从用户的角度能更直观了解到问题：

1. 我们输了 url ；
2. 浏览器将 url 组成 http/https 的请求；
3. request 请求是 应用层 数据，经过层层包装来到 数据链路层 ，从网卡发出；
4. 在服务器那头反过来，层层解包，获得我们的 request ，交付给 web 应用；
5. 服务器生成 respond 响应返回，走老路递交给我们的浏览器显示。

在这一系列的过程中，服务器的主要职责是对 『 req —— 比特流 —— res 』 这一变化进行处理；
而 web app 的职责是将 request 请求和 response 响应进行屏幕上的反馈。

问题来了，服务器/客户端怎么将 req/res 和 web app 进行交互？ 通过 wsgi 接口。

在 wsgi 规范下， web 组件被分成三类： client 、 server 、 middleware 。

apps 能处理 request ，这也就引发出中间件这一概念， client 被作为它的上游， server 被作为它的下游。

职责分配：

组件	职能
server	接收请求
client	处理结果
applition	处理请求

asgi 接口规范

随着时间的推移，越来越多的人开始热衷于实时响应， HTML5 中的 websocket 给我们展现了一片新大陆，全双工通信也确实不是 ajax 轮询 和 long poll 可以比拟的。

那么为什么他会解决服务器上消耗资源的问题呢？下面是我找到唯一一段话看懂的答案。

其实我们所用的程序是要经过两层代理的，即HTTP协议在Nginx等服务器的解析下，然后再传送给相应的Handler（PHP等）来处理。
简单地说，我们有一个非常快速的接线员（Nginx），他负责把问题转交给相应的客服（Handler）。
本身接线员基本上速度是足够的，但是每次都卡在客服（Handler）了，老有客服处理速度太慢。，导致客服不够。

asgi 『 Asynchronous Server Gateway Interface 』是为了取代 wsgi 而定义的，它的处理类型包括了 websocket 。一次 http 请求信息就开始源源不断地进行着传递了。实时 django 也得以实现。

asgi 由三个组件组成：协议『 interface server 』、频道『 channel 』、应用 『 consumer 』。频道层沟通协议层和应用层。

职能分配：

组件	职能
interface server	接收请求、分配请求
channel	传递请求、队列系统
consumer	处理请求、返回结果

补一张图，便于理解：