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

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

uWSGI 与 python web framework（eg: django） 通信现在基本基于 wsgi 那么uWSGI 的自有协议 uwsgi 是用在 uWSGI 与 nginx 这种反代（或者前端服务器）之间的通信嘛？如果是的话可不可以理解 uwsgi 的作用类似于 fastcgi 呢？如果不是那么 uwsgi 协议到底用在哪里呢？

添加评论 

分享

按投票排序 按时间排序

2 个回答

1赞同 反对，不会显示你的姓名

fleuria 刀剑的时代已经远去，接下来的战斗要拿起枪

1 人赞同

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

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

编辑于 2016-06-05  添加评论  感谢 

分享

  收藏  •  没有帮助  •  举报  •  作者保留权利

15赞同 反对，不会显示你的姓名

灵剑 Python程序员

15 人赞同

你理解的没错，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很像。