标签：with 基于 组成 nginx 两种 密码 形式 文件中 获取
django-admin startproject 项目名称
python manage.py startapp 应用 app 名
项目文件夹下的组成部分:
manage.py 是项目运行的入口，指定配置文件路径。
与项目同名的目录，包含项目的配置文件。
_init.py 是一个空文件，作用是这个目录可以被当作包使用。
settings.py 是项目的整体配置文件。
urls.py 是项目的 URL 配置文件。
wsgi.py 是项目与 WSGI 兼容的 Web 服务器。
M:Model，模型，和数据库进行交互
V:View，视图，负责产生 Html 页面
C:Controller，控制器，接收请求，进行处理，与 M 和 V 进行交互，返回应答。
1、 用户点击注按钮，将要注册的信息发送给网站服务器。
2、 Controller 控制器接收到用户的注册信息，Controller 会告诉 Model 层将用户的注册信息保 存到数据库
3、 Model 层将用户的注册信息保存到数据库
4、 数据保存之后将保存的结果返回给 Model 模型，
5、 Model 层将保存的结果返回给 Controller 控制器。
6、 Controller 控制器收到保存的结果之后，或告诉 View 视图，view 视图产生一个 html 页面。 7、 View 将产生的 Html 页面的内容给了 Controller 控制器。
8、 Controller 将 Html 页面的内容返回给浏览器。
9、 浏览器接受到服务器 Controller 返回的 Html 页面进行解析展示。
M:Model，模型，和 MVC 中的 M 功能相同，和数据库进行交互。
V:view，视图，和 MVC 中的 C 功能相同，接收请求，进行处理，与 M 和 T 进行交互，返回应答。 T:Template，模板，和 MVC 中的 V 功能相同，产生 Html 页面
详细介绍可参考博客：https://www.cnblogs.com/caijunchao/p/13054310.html
Django 在中间件中预置了六个方法，这六个方法的区别在于不同的阶段执行，对输入或输出进行干预，方法如:
1.初始化:无需任何参数，服务器响应第一个请求的时候调用一次，用于确定是否启用当前中间件。
2.处理请求前:在每个请求上调用，返回 None 或 HttpResponse 对象。
3.处理视图前:在每个请求上调用，返回 None 或 HttpResponse 对象。
4.处理模板响应前:在每个请求上调用，返回实现了 render 方法的响应对象。
5.处理响应后:所有响应返回浏览器之前被调用，在每个请求上调用，返回 HttpResponse 对象。
6.异常处理:当视图抛出异常时调用，在每个请求上调用，返回一个 HttpResponse 对象。
1.uWSGI 是一个 Web 服务器，它实现了 WSGI 协议、uwsgi、http 等协议。Nginx 中 HttpUwsgiModule 的作用是与 uWSGI 服务器进行交换。WSGI 是一种 Web 服务器网关接口。它是一 个 Web 服务器(如 nginx，uWSGI 等服务器)与 web 应用(如用 Flask 框架写的程序)通信的一种 规范。
要注意 WSGI / uwsgi / uWSGI 这三个概念的区分。
WSGI 是一种通信协议。
uwsgi 是一种线路协议而不是通信协议，在此常用于在 uWSGI 服务器与其他网络服务器的数据通信。 uWSGI 是实现了 uwsgi 和 WSGI 两种协议的 Web 服务器。
2. nginx 是一个开源的高性能的 HTTP 服务器和反向代理:
1.作为 web 服务器，它处理静态文件和索引文件效果非常高;
2.它的设计非常注重效率，最大支持 5 万个并发连接，但只占用很少的内存空间;
3.稳定性高，配置简洁;
4.强大的反向代理和负载均衡功能，平衡集群中各个服务器的负载压力应用。
首先浏览器发起 http 请求到 nginx 服务器，Nginx 根据接收到请求包，进行 url 分析，判断访问的 资源类型，如果是静态资源，直接读取静态资源返回给浏览器，如果请求的是动态资源就转交给 uwsgi 服务器，uwsgi 服务器根据自身的 uwsgi 和 WSGI 协议，找到对应的 Django 框架，Django 框架下的 应用进行逻辑处理后，将返回值发送到 uwsgi 服务器，然后 uwsgi 服务器再返回给 nginx，最后 nginx 将返回值返回给浏览器进行渲染显示给用户。
1.设计表时，尽量少使用外键，因为外键约束会影响插入和删除性能;
2.使用缓存，减少对数据库的访问;
3.在 orm 框架下设置表时，能用 varchar 确定字段长度时，就别用 text;
4.可以给搜索频率高的字段属性，在定义时创建索引;
5.Django orm 框架下的 Querysets 本来就有缓存的;
6.如果一个页面需要多次连接数据库，最好一次性取出所有需要的数据，减少对数据库的查询次数;
7.若页面只需要数据库里某一个两个字段时，可以用 QuerySet.values();
8.在模板标签里使用 with 标签可以缓存 Qset 的查询结果。
对一个后端开发程序员来说，提升性能指标主要有两个一个是并发数，另一个是响应时间网站性能 的优化
一般包括 web 前端性能优化，应用服务器性能优化，存储服务器优化。
1.减少 http 请求，减少数据库的访问量，比如使用雪碧图。
2.对 html，css，javascript 文件进行压缩，减少网络的通信量。
1.合理的使用redis缓存技术，对一些常用到的动态数据，比如首页做一个缓存，或者某些常用的数据做
个缓存，设置一定得过期时间，这样减少了对数据库的压力，提升网站性能。
2.使用 celery 消息队列，将耗时的操作扔到队列里，让 worker 去监听队列里的任务，实现异步操
作，比如发邮件，发短信。
3.代码上的优化，补充:nginx 部署项目也是项目优化，可以配置合适的配置参数，提升 效率，增加并发量。
4.硬件上面的优化，比如增加内存，采用固态硬盘增加读写等。
5.搭建服务器集群，将并发访问请求，分散到多台服务器上处理。
6.构建数据库读写分离
将验证码保存到数据库或 session，设置过期时间为 1 分钟，然后页面设置一个倒计时(一般是前端 js 实现 这个计时)的展示，一分钟过后再次点击获取新的信息。
REST:Representational State Transfer 的缩写，翻译:“具象状态传输”。一般解释为“表现层状态转换”。
REST 是设计风格而不是标准。是指客户端和服务器的交互形式。我们需要关注的重点是如何设计 REST 风格的网络接口。
REST 的特点:
1.具象的。一般指表现层，要表现的对象就是资源。比如，客户端访问服务器，获取的数据就是资 源。比如文字、图片、音视频等。
2.表现:资源的表现形式。txt 格式、html 格式、json 格式、jpg 格式等。浏览器通过 URL 确定资 源的位置，但是需要在 HTTP 请求头中，用 Accept 和 Content-Type 字段指定，这两个字段是对资源 表现的描述。
3.状态转换:客户端和服务器交互的过程。在这个过程中，一定会有数据和状态的转化，这种转化 叫做状态转换。其中，GET 表示获取资源，POST 表示新建资源，PUT 表示更新资源，DELETE 表示删 除资源。HTTP 协议中最常用的就是这四种操作方式。
RESTful 架构:
1.每个 URL 代表一种资源;
2.客户端和服务器之间，传递这种资源的某种表现层;
3.客户端通过四个 http 动词，对服务器资源进行操作，实现表现层状态转换。
简单来说就是: 你访问了信任网站 A，然后 A 会用保存你的个人信息并返回给你的浏览器一个 cookie，然后呢，在 cookie 的过期时间之内，你去访问了恶意网站 B，它给你返回一些恶意请求代码， 要求你去访问网站 A，而你的浏览器在收到这个恶意请求之后，在你不知情的情况下，会带上保存在本 地浏览器的 cookie 信息去访问网站 A，然后网站 A 误以为是用户本身的操作，导致来自恶意网站 C 的 攻击代码会被执:发邮件，发消息，修改你的密码，购物，转账，偷窥你的个人信息，导致私人信息泄 漏和账户财产安全收到威胁。
如何解决:
1. 去掉项目的CSRF验证
2. 前端表单中增加csrf信息
3. 指定请求去掉CSRF校验
4. 为所有请求添加csrf校验数据（推荐）
runserver 方法是调试 Django 时经常用到的运行方式，它使用 Django 自带的 WSGI Server 运 行，主要在测试和开发中使用，并且 runserver 开启的方式也是单进程 。
在单元测试方面，Django 继承 python 的 unittest.TestCase 实现了自己的 django.test.TestCase，编写测试用例通常从这里开始。测试代码通常位于 app 的 tests.py 文件中(也 可以在 models.py 中编写，一般不建议)。在 Django 生成的 depotapp 中，已经包含了这个文件， 并且其中包含了一个测试.
情景:用户发起 request，并等待 response 返回。在本些 views 中，可能需要执行一段耗时的程 序，那么用户就会等待很长时间，造成不好的用户体验，比如发送邮件、手机验证码等。
使用 celery 后，情况就不一样了。解决:将耗时的程序放到 celery 中执行。
将多个耗时的任务添加到队列 queue 中，也就是用 redis 实现 broker 中间人，然后用多个 worker 去监听队列 里的任务去执行。
web 开发中，部署方式大致类似。简单来说，使用 Nginx 主要是为了实现分流、转发、负载均衡， 以及分担服务器的压力。Nginx 部署简单，内存消耗少，成本低。Nginx 既可以做正向代理，也可以 做反向代理。
正向代理:请求经过代理服务器从局域网发出，然后到达互联网上的服务器。
特点:服务端并不知道真正的客户端是谁。
反向代理:请求从互联网发出，先进入代理服务器，再转发给局域网内的服务器。
特点:客户端并不知道真正的服务端是谁。
区别:正向代理的对象是客户端。反向代理的对象是服务端。
Django 自带了一个健壮的缓存系统来保存动态页面这样避免对于每次请求都重新计算。方便起见， Django 提供了不同级别的缓存粒度:可以缓存特定视图的输出、可以仅仅缓存那些很难生产出来的部分、或者可以缓存整个网站 Django 也能很好的配合那些“下游”缓存， 比如 Squid 和基于浏览器 的缓存。这里有一些缓存不必要直接去控制但是可以提供线索， (via HTTPheaders)关于网站哪些部分 需要缓存和如何缓存。
设置缓存:
缓存系统需要一些设置才能使用。 也就是说，你必须告诉他你要把数据缓存在哪里,是数据库中， 文件系统或者直接在内存中。 这个决定很重要，因为它会影响你的缓存性能，是的，一些缓存类型要比其他的缓存类型更快速。
你的缓存配置是通过 setting 文件的 CACHES 配置来实现的。
参考博客：https://www.cnblogs.com/caijunchao/p/13056002.html
两大特性
1）惰性执行
创建查询集不会访问数据库，直到调用数据时，才会访问数据库，调用数据的情况包括迭代、序列化、与if合用，例如，当执行如下语句时，并未进行数据库查询，只是创建了一个查询集qs
2）缓存
使用同一个查询集，第一次使用时会发生数据库的查询，然后Django会把结果缓存下来，再次使用这个查询集时会使用缓存的数据，减少了数据库的查询次数。
情况一：如下是两个查询集，无法重用缓存，每次查询都会与数据库进行一次交互，增加了数据库的负载。
情况二：经过存储后，可以重用查询集，第二次使用缓存中的数据。
1、Cookie 数据存放在客户的浏览器上，session 数据放在服务器上。
2、Cookie 不是很安全，别人可以分析存放在本地的 cookie 并进行 cookie 欺骗，考虑到安全应 当使用 Session。
3、Session 会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能，考虑到 减轻服务器性能方面，应当使用 Cookie。
4、单个 Cookie 保存的数据不能超过 4K，很多浏览器都限制一个站点最多保存 20 个 Cookie。
5、Session 采用的是在服务器端保持状态的方案，而 Cookie 采用的是在客户端保持状态的方案。但是禁用 Cookie 就不能得到 Session。因为 Session 是用 Session ID 来确定当前对话所对应的服务器 Session，而 Session ID 是通过 Cookie 来传递的，禁用 Cookie 相当于失去了 SessionID，也 就得不到 Session。
1、 启用中间件
2、post 请求
3、验证码
4、表单中添加 csrf_token 标签
python manage.py makemigrations
python manage.py migrate
标签：with 基于 组成 nginx 两种 密码 形式 文件中 获取
原文地址：https://www.cnblogs.com/caijunchao/p/13205217.html
