Django处理顺序
wsgi
socket请求处理控制器（django框架本身）
控制用户输入，url匹配，通过映射列表将一个请求发送到一个合适的视图views
向模型和模板发送（或获取）数据模型绑定
数据库存取数据模板引擎
用于将内容与展现分离，描述了数据如何展现（如网页模板）模式渲染
将模板和数据整合，形成最终网页控制器（django框架本身）
返回用户展示
MVC与MTV
MVC即模型－视图－控制器模式，就是为那些需要为同样的数据提供多个视图的应用程序而设计的。它很好地实现了数据层与表示层的分离，特别适用于开发与用户图形界面有关的应用程序。控制器用来处理用户命令以及程序事件；模型维护数据并提供数据访问方法；视图用于数据的显示。
MTV即模型 - 模版 - 视图模式，其标准名称是有争议的。在MVC的解释中，视图描述了展现给用户的数据，是指所看到的数据，而不是如何看见它。在python中视图是指对某一特定URL的回调函数，因为回调函数描述了所要展现的数据。模版用于将内容与展现分离。在Django中，视图描述了要展现的数据，而视图一般转交给模版。模版描述了数据如何展现。控制器则是指django框架本身，通过URL配置，系统将一个请求发送到一个合适的视图。
uwsgi与nginx
nginx 接收到浏览器发送过来的http请求，将包进行解析，分析url：
如果是静态文件请求就直接访问用户给nginx配置的静态文件目录，直接返回用户请求的静态文件；
如果不是静态文件，而是一个动态的请求，那么nginx就将请求转发给uwsgi，uwsgi接收到请求之后将包进行处理，处理成wsgi可以接受的格式，并发给wsgi，wsgi根据请求调用应用程序的某个文件，某个文件的某个函数，最后处理完将返回值再次交给wsgi，wsgi将返回值进行打包，打包成uwsgi能够接收的格式，uwsgi接收wsgi 发送的请求，并转发给nginx,nginx最终将返回值返回给浏览器。
第一级的nginx并不是必须的，uwsgi完全可以完成整个的和浏览器交互的流程，但是要考虑到某些情况：
- 安全问题，程序不能直接被浏览器访问到，而是通过nginx，nginx只开放某个接口，uwsgi本身是内网接口，这样运维人员在nginx上加上安全性的限制，可以达到保护程序的作用。
- 负载均衡问题，一个uwsgi很可能不够用，即使开了多个work也是不行，毕竟一台机器的cpu和内存都是有限的，有了nginx做代理，一个nginx可以代理多台uwsgi完成uwsgi的负载均衡。
- 静态文件问题，用django或是uwsgi这种东西来负责静态文件的处理是很浪费的行为，而且他们本身对文件的处理也不如nginx好，所以整个静态文件的处理都直接由nginx完成，静态文件的访问完全不去经过uwsgi以及其后面的东西。
Django中间件
自己理解是类似于Scrapy中间件，在请求和响应的过程中做一些另外的操作，比如拦截、识别、代理等功能操作。
Django的CSRF防护
CSRF, Cross Site Request Forgery, 跨站点伪造请求。举例来讲，某个恶意的网站上有一个指向你的网站的链接，如果某个用户已经登录到你的网站上了，那么当这个用户点击这个恶意网站上的那个链接时，就会向你的网站发来一个请求，你的网站会以为这个请求是用户自己发来的，其实呢，这个请求是那个恶意网站伪造的。
Django 提供的 CSRF 防护机制
Django 第一次响应来自某个客户端的请求时，会在服务器端随机生成一个 token，把这个 token 放在 cookie 里。然后每次 POST 请求都会带上这个 token，这样就能避免被 CSRF 攻击。
Django的CSS防护
- 对单一变量进行转义过滤。可以使用escape过滤器，无需转义时使用safe过滤器
- 利用django的HTML自动转义，无需autoescape标签，django中的HTML文档会自动转义。
