关于 nginx+uWSGI+django 架构 数据传输的问题

[lanqing]

最近在看这几个概念有点混淆,有几个问题想请教一下

1. nginx+uWSGI+django 解析 http 协议是在哪个上面解析的?
2. nginx+uWSGI 通信的协议(或者说规范)是什么?
3. uWSGI+django 通信的规范是什么?
4. 网上说 uWSGI 实现了 http 协议,是否 uWSGI+django 的架构上,uWSGI 负责 http 的解析
5. 只有 django 的话,是不是内部也实现了一个简单的 类似 nginx+uWSGI 的东西
6. flask 框架依赖于 werkzeug ,这个东西是不是跟 uWSGI 一个层次的东西

希望不吝赐教啊!

[wlzd]

我也想知道，求大佬们普及

[Rand01ph]

客户端发送 HTTP 协议到 Nginx，然后 Nginx 发送 uwsgi 协议到 uWSGI，然后 uWSGI 调用 Django/flask 的 WSGI application

[Rand01ph]

只有 django 的话，是不存在 uWSGI 这一层，直接接受 HTTP 协议，然后调用 Django 的 WSGI application

[est]

1. nginx 粗解析，比如头，uWSGI 细解析，比如 URL。
2. 是 uwsgi （ uWSGI 是程序 uwsgi 是协议）
3. 是 WSGI。uWSGI 直接调用 libpython.so 其他的都是代码接口。明白了吧
4. uwsgi 协议是 http 的一个超集。可以看成一个 RPC。但是同时 uWSGI 作者精力太旺盛实现了 http http/1.1 https 静态文件输出 cache 服务 key-value 服务 crontab 服务等。可以代替 nginx 直接监听 80 端口。可以代替 supervisor 监控进程。所以 uWSGI 也重新实现了全套 http 解析服务。
5. runserver 实现了。但是只是开发用。
6. 是基于 WSGI 的一些助手工具中间件。

[Zzdex]

插楼问一句 uwsgi 和 gunicorn 那个更好

[xpresslink]

nginx+uWSGI+django 解析 http 协议是在哪个上面解析的?
http 是个文本协议，django 来解析的。

nginx+uWSGI 通信的协议(或者说规范)是什么?
uwsgi 是一种线路协议而不是通信协议，在此常用于在 uWSGI 服务器与其他网络服务器的数据通信。uwsgi 协议是一个 uWSGI 服务器自有的协议，它用于定义传输信息的类型。

uWSGI+django 通信的规范是什么?
WSGI 协议。这东西是一个 Gateway，也就是网关。网关的作用就是在协议之间进行转换。

网上说 uWSGI 实现了 http 协议,是否 uWSGI+django 的架构上,uWSGI 负责 http 的解析
不是。

只有 django 的话,是不是内部也实现了一个简单的 类似 nginx+uWSGI 的东西
Django 所提供的是一个开发服务器，这个开发服务器，没有经过安全测试，而且使用的是 Python 自带的 simple HTTPServer 创建的，在安全性和效率上都是不行的。虽然不要 nginx 和 uWSGI 也可以跑，只不过 django runsever 原生为单线程，当第一个请求没有完成时，第二个请求辉阻塞，知道第一个请求完成，第二个请求才会执行。nginx 是线 web 服务器主要起到了调度，转发，处理静态文件等作用。uWSGI 是 nginx 和 app 之间的桥梁，起到多进程并发，转换协议接口等作用。

flask 框架依赖于 werkzeug ,这个东西是不是跟 uWSGI 一个层次的东西
不是。werkzeug 既不是一个 web 服务器，也不是一个 web 框架，而是是一个 WSGI 工具包，它可以作为一个 Web 框架的底层库，因为它封装好了很多 Web 框架的东西，例如 Request，Response 等等。

[est]

@Zzdex 功能强大来说 uwsgi 好一万倍。

配置难度来说其实一样。如果你只看国内 csdn 级别文章肯定都推荐 gunicorn

要自己去修改一些底层逻辑，gunicorn 更简单。uWSGI 的 C 代码全世界估计只有作者会改。3 层 for 循环嵌套。

[javlib]

@est 我当时选择 gunicorn 的原因是 gunicorn 支持用.py 作为配置文件，可以根据 cpu 核数配置 gunicorn 的 process 数量。

[xpresslink]

@Zzdex
各有优势
Gun 是纯 python 实现的，容易配置和 hack，配合 gevent 时处理部分阻塞请求的性能高。
uW 是 C 实现的，大量非阻塞短请求优势明显，但是配置麻烦一些。
总体上 uW 略占优。

[lanqing]

@xpresslink django 的 runserver 是多线程的

[lanqing]

@est 请问,werkzeug 是不是类似于封装了很多 http 请求的东西,然后用它根据 WSGI 规范能写一个 uWSGI 和 django 通信,根据 uwsgi 规范我可以写一个 uWSGI 与 nginx 通信

[est]

@javlib uWSGI 也能做到 py 文件配置。甚至可以通过 py 指令动态配置。

还可以在配置文件里计算。比如根据 CPU 核心数量的一半配置 process 数量。想不到吧！

[est]

@lanqing WSGI 只是一个 python 代码接口。werkzeug 在这个接口之上封装了很多工具。

WSGI 之下是 uWSGI 真正监听端口跑起来

一般不推荐写 uwsgi 协议。太蛋痛了。

[xpresslink]

@lanqing runserver 确实默认是多线程启动的。写的时候没有太注意，其实是想说 django 应用是单线程的阻塞的，而且 python 有 GIL，也是伪多线程。

[est]

@xpresslink 不懂就不要瞎说。py 的多线程就是 native os thread。跑 http 是会释放 GIL 的。

[xpresslink]

@est IO 操作会释放 GIL，这个基本上学过 py 都知道，我说的伪多线程是指有 GIL 的存在不能利用多核。一个 WEB 框架里不光只有 IO 操作吧，总会有正反序列化之类的吃 CPU 操作的任务。

[est]

@xpresslink 谁告诉你不能利用多核就是伪多线程了？那么多 C++ 写的游戏，都只吃单个 CPU，他们都是单线程的？

[xpresslink]

@est 好吧，你说服我了，Python 的多线程确实是操作系统真多线程。那我改成说是伪平行总可以了吧。

你即使把鸡叫小姐也改变不了婊子的性质啊（逃）

[est]

@xpresslink 比赛说脏话了？ @livid

[xpresslink]

@est 我可真心没说你，只是借喻一下。