uWSGI 服务器的 uwsgi 协议究竟用在何处？

单纯协议层面个人感觉用处不大，相比 gunicorn 而言 uwsgi 用自定义协议替代 http 协议做反向代理，理论上 uwsgi 的二进制协议比 http 文本协议的 payload 开销小，但是增加了一层复杂性，间接的一个影响是 uwsgi 的文档会比 gunicorn 差很多，但性能没有显著差异。

反向代理相对于内嵌 fastcgi 的好处在于容易扩展后端实例，用 fastcgi 到需要扩展的时候，依然需要在前头再过一层反向代理。

你理解的没错，WSGI是一种编程接口，而uwsgi是一种传输协议，从作用上来讲，的确跟fastcgi是最接近的。跟fastcgi的区别在于它是面向多并发的。我们知道fastcgi是CGI的替代品，它的工作方式仍然跟CGI是类似的，当一个请求进入的时候，通过socket发送请求的环境变量，然后发送POST数据（相当于CGI的stdin），然后等待程序输出（相当于CGI的stdout），等输出结束后，再发送下一个请求。这就导致fastcgi最大的并发量被限制为fastcgi后端的数量，显然这样的服务器模式对于并发量很大、单个请求耗时比较长的服务是不合适的，因此很多时候我们不愿意使用fastcgi部属而是使用反向代理的方式配置。

但是跟反向代理比起来，fastcgi显然也是有好处的，最重要的好处在于解析HTTP协议的部分被offload到了前端服务器一级，后端服务器不再解析HTTP协议，这样就减轻了后端的压力，由于前端是nginx这样用C/C++高性能实现的服务器，比起在后端的Python当中使用脚本语言解析HTTP协议，效率要高不少。

uwsgi想要继承fastcgi的这种好处，它通过将消息分片的方式，可以在一个socket上并发传输多个请求，这样就解决了一个连接上一次只能传输一个请求的问题。熟悉HTTP2.0的话会发现这个分片机制跟HTTP2.0很像。