Django 底层原理
快捷键
方向键
方向键本键如果活动选项是选项按钮或文件则为移动焦点；
方向键 + Win键(简称Win键)使窗口全屏、最小化、靠左半边、靠右半边(部分版本不支持)；
方向键+Shift键将连续的文字或文件选中
方向键(左右)+Ctrl键 在英文单词或中文词语间跳跃
方向键(上下)+Ctrl键 在段落开头间跳跃
按Home(定位到行首)然后按Shift+End(行尾)或者 然后按Shift+↓ (下一行这个位置)
或者 按End(定位到行尾)然后按Shift+Home
ctrl
Ctrl+b 粗体 Bold
Ctrl+e 居中对齐 Encenter
Ctrl+f 查找 Find
Ctrl+h 替换 Huan
Ctrl+k 超级链接 King Link
win
Win键+E打开Windows资源管理器Explorer【即我的电脑、计算机】
Win键+R：运行
Win键+Shift+S：Windows 自带截图
win键+PrtScSysRq键 快速截屏
HTTP
超文本传输协议(英文：HyperText Transfer Protocol，缩写：HTTP)是一种用于分布式、协作式和超媒体信息系统的应用层协议。HTTP是万维网WEB的数据通信的基础。
现今广泛使用的一个版本——HTTP 1.1(已更新至2.0)
HTTP工作原理
HTTP协议定义Web客户端如何从Web服务器请求Web页面，以及服务器如何把Web页面传送给客户端。
HTTP协议采用了请求/响应模型。
客户端向服务器发送一个请求报文，请求报文包含请求的方法、URL、协议版本、请求头部和请求数据。服务器以一个状态行作为响应，响应的内容包括协议的版本、成功或者错误代码、服务器信息、响应头部和响应数据。
响应报文：比如"HTTP/1.1 200 OK"
以下是 HTTP 请求/响应的步骤：
客户端连接到Web服务器
一个HTTP客户端，通常是浏览器，与Web服务器的HTTP端口(默认为80)建立一个TCP套接字连接。例如，http://www.luffycity.com。
发送HTTP请求
通过TCP套接字，客户端向Web服务器发送一个文本的请求报文，一个请求报文由请求行、请求头部、空行和请求数据4部分组成。
服务器接受请求并返回HTTP响应
Web服务器解析请求，定位请求资源。服务器将资源复本写到TCP套接字，由客户端读取。一个响应由状态行、响应头部、空行和响应数据4部分组成。
释放连接TCP连接
若connection 模式为 close(无连接)，则服务器主动关闭TCP连接，客户端被动关闭连接，释放TCP连接;若 connection 模式为 keepalive(短连接)，则该连接会保持一段时间，在该时间内可以继续接收请求;
客户端浏览器解析HTML内容
客户端浏览器首先解析状态行，查看表明请求是否成功的状态代码。然后解析每一个响应头，响应头告知以下为若干字节的HTML文档和文档的字符集。客户端浏览器读取响应数据HTML，根据HTML的语法对其进行格式化，并在浏览器窗口中显示。
例如：在浏览器地址栏键入URL，按下回车之后会经历以下流程：
浏览器向 DNS 服务器请求解析该 URL 中的域名所对应的 IP 地址;
域名(英语：Domain Name)，又称网域，是由一串用点分隔的名字组成的Internet上某一台计算机或计算机组的名称，用于在数据传输时对计算机的定位标识(有时也指地理位置)。
由于IP地址具有不方便记忆并且不能显示地址组织的名称和性质等缺点，人们设计出了域名，并通过域名服务器(DNS，Domain Name System)来将域名和IP地址相互映射，使人更方便地访问互联网，而不用去记住能够被机器直接读取的IP地址数串。
解析出 IP 地址后，根据该 IP 地址和默认端口 80，和服务器建立TCP连接;
浏览器发出读取文件(URL 中域名后面部分对应的路径(文件))的HTTP 请求，该请求报文作为 TCP 三次握手中第三次握手(由客户端发送)时的报文数据发送给服务器;
服务器对浏览器请求作出响应，并把对应的 html 文本发送给浏览器;
释放 TCP连接;
浏览器将该 html 文本渲染并显示内容;
HTTP特点：
基于 请求-响应 的模式
HTTP协议规定，请求从客户端发出，最后服务器端响应该请求并返回。换句话说，肯定是先从客户端开始建立通信的，服务器端在没有接收到请求之前不会发送响应
无状态保存
概念：
HTTP是一种不保存状态,即无状态(stateless)协议，即HTTP协议自身不对请求和响应之间的通信状态进行保存。
只要连接中断，就撤销当前所有信息，即每次开始时都是个完全空白的状态
目的：
为了更快地处理大量事务,确保协议的可伸缩性,而特意把HTTP协议设计成如此简单的。
弊端：
信息的不存储，对于必须要存储某些信息的网站来说，意味着：
我输入一个网页并回车，一个套接字返回我要访问的html，然后他就走了，然后当我要进行登陆操作时，又来了一个套接字接待我，给我返回登陆的网页，然后他也走了。我在输入完信息后回车进行登陆，又一个套接字过来拿着我的请求中的信息去数据库里进行比对，检验完后，它就走了，临走前返回我一个登陆成功，这时，如果我要进行基于用户的操作时，一个新的套接字过来说，你还没登陆啊，怎么能进行这个操作，我....
基于上述情况，cookie由此诞生。
无连接
概念：
无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。
目的：
采用这种方式可以节省传输时间，并且可以提高并发性能，不能和每个用户建立长久的连接，请求一次响应一次，服务端和客户端就中断了。
优势：
适用于重浏览型网页，腾出线程来接待新用户，防止占用套接字不发请求的用户。
短连接：
概念：
HTTP/1.1 版本之后，采用的是短连接的方式：即套接字响应完后，不会马上关闭，而是等待几秒钟的时间(程序员可以自行设定)，如果客户端在这段时间内没有响应的话，才会断开。
目的
这样做的主要目的还是为了节省时间，因为重新创建套接字也是需要时间的，目前默认3s左右。对于一个连续操作的客户端来说，如果他在短时间内点击了html中的很多选项，这样每次服务器都需要创建一个套接字来接待他，仅创建套接字的时间就足以拖垮效率。
而对于一个操作间隔很长的客户端来说，无连接很明显是个足够优秀的选择
短连接等待时间
网站根据自己网站用户的行为来分析统计出一个最优的等待时间。
优势：
适用于强操作性网页，可以防止单个用户短时间就占用多个套接字(因为无连接的方式，套接字响应完请求就自行关闭了，所以新的请求就要重新建立套接字)。
因此，无连接、短连接没有绝对的优劣，主要还是看客户端需求。
HTTP请求方法
get 拿数据
post 发数据
报文格式
请求报文
响应报文
通过GET方式提交数据时，请求数据(页面提交的信息)会放在原路径后，并与原路径组成一个新的路径部分，因此get方式提交时路径部分不止有路径，且后面的请求数据部分一定为空。
这种形式还会出现一个问题就是：
客户端第一次访问服务器时，通常是以域名的形式访问的，之后就通过点击超链接或敲回车自动转载网页的形式访问服务器的其他页面。
上述后者是以URL{域名(或ip)+路径}的形式访问服务器的，这就意味着，页面在访问服务器时，域名+路径会直接显示在浏览器网址栏，即用户的请求数据会以明文形式显示在网址栏，这对于用户的个人数据等信息来说是不能接受的。
GET方式以?分割路径和请求数据，请求数据中的参数之间以&相连，如EditBook?name=test1&id=123456.(请求头里面那个content-type做的这种参数形式，后面讲) POST方法是把页面提交的数据放在HTTP包的请求数据中。
GET提交的数据大小有限制(因为浏览器对URL的长度有限制)，而POST方法提交的数据没有限制.
GET与POST请求在服务端获取请求数据方式不同，就是我们自己在服务端取请求数据的时候的方式不同了，这句废话昂。
HTTP状态码
所有HTTP响应的第一行都是状态行，依次是当前HTTP版本号，3位数字组成的状态代码，以及描述状态的短语，彼此由空格分隔。比如"HTTP/1.1 200 OK"
状态代码的第一个数字代表当前响应的类型：
1xx消息——请求已被服务器接收，继续处理
2xx成功——请求已成功被服务器接收、理解、并接受(没问题)
3xx重定向——需要后续操作才能完成这一请求
4xx请求错误——请求含有词法错误或者无法被执行(客户端请求出现问题)
5xx服务器错误——服务器在处理某个正确请求时发生错误(服务器出现问题)
URL
超文本传输协议(HTTP)的统一资源定位符将从因特网获取信息的五个基本元素包括在一个简单的地址中(即一个完整的网页)：
传送协议(http/https(http基础上进行加密，提升安全性))。
层级URL标记符号(为[//],固定不变)
访问资源需要的凭证信息(可省略)
服务器。(通常为域名，有时为IP地址)
端口号。(以数字方式表示，若为HTTP的默认值“:80”可省略)
路径。(以“/”字符区别路径中的每一个目录名称，第一个/前就是域名(或IP)
查询。(GET模式的窗体参数，以“?”字符为起点，每个参数以“&”隔开，再以“=”分开参数名称与数据，通常以UTF8的URL编码，避开字符冲突的问题)
片段。以“#”字符为起点
以http://www.luffycity.com:80/news/index.html?id=250&page=1 为例,
其中：
http，是协议；
www.luffycity.com，是服务器；
80，是服务器上的默认网络端口号，默认不显示；
/news/index.html，是路径(URI：直接定位到对应的资源)；
?id=250&page=1，是查询。
大多数网页浏览器不要求用户输入网页中“http://”的部分，因为绝大多数网页内容是超文本传输协议文件。同样，“80”是超文本传输协议文件的常用端口号，因此一般也不必写明。一般来说用户只要键入统一资源定位符的一部分(www.luffycity.com:80/news/index.html?id=250&page=1)就可以了。
由于超文本传输协议允许服务器将浏览器重定向到另一个网页地址，因此许多服务器允许用户省略网页地址中的部分，比如 www。从技术上来说这样省略后的网页地址实际上是一个不同的网页地址，浏览器本身无法决定这个新地址是否通，服务器必须完成重定向的任务。
浏览器对页面进行渲染时，需要html文件中通过各种方式引用的所有素材以及网页的图标，并且这个过程是以异步的形式向服务器发送请求的(遇到第一个需要的素材，就给服务器发请求说我要，然后html中的代码继续往下走)
rb形式发送文件数据时，发送的只有文档里的内容，文件的外壳跟名字都没有被发送
函数版web框架
from threading import Thread
import socket
server = socket.socket()
server.bind(('127.0.0.1',8001))
server.listen()
def html():
with open('home.html', 'rb') as f:
to_client_data = f.read()
return to_client_data
def css():
with open('home.css', 'rb') as f:
to_client_data = f.read()
return to_client_data
def js():
with open('home.js', 'rb') as f:
to_client_data = f.read()
return to_client_data
def jpg():
with open('1.jpg', 'rb') as f:
to_client_data = f.read()
return to_client_data
def ico():
with open('xx1.ico', 'rb') as f:
to_client_data = f.read()
return to_client_data
url_patterns = [
('/',html),
('/home.css',css),
('/home.js',js),
('/1.jpg',jpg),
('/favicon.ico',ico),
]
while 1:
conn,addr = server.accept()
from_client_msg = conn.recv(1024).decode('utf-8')
# print(from_client_msg)
# print(from_client_msg.decode('utf-8'))
request_path = from_client_msg.split(' ')[1]
# 拿到用户的访问路径
print(request_path)
conn.send(b'HTTP/1.1 200 ok\r\n\r\n')
for i in url_patterns:
if i[0] == request_path:
# 进行信息比对，你要访问的路径在我的url-func关系中，就调用对应的函数给他返回对应页面。
to_client_data = i[1]()
conn.send(to_client_data)
conn.close()
server.close()
并发版web框架
from threading import Thread
import socket
server = socket.socket()
server.bind(('127.0.0.1',8001))
server.listen()
def html(conn):
with open('home.html', 'rb') as f:
to_client_data = f.read()
conn.send(to_client_data)
conn.close()
# return to_client_data
def css(conn):
with open('home.css', 'rb') as f:
to_client_data = f.read()
conn.send(to_client_data)
conn.close()
def js(conn):
with open('home.js', 'rb') as f:
to_client_data = f.read()
conn.send(to_client_data)
conn.close()
def jpg(conn):
with open('1.jpg', 'rb') as f:
to_client_data = f.read()
conn.send(to_client_data)
conn.close()
def ico(conn):
with open('xx1.ico', 'rb') as f:
to_client_data = f.read()
conn.send(to_client_data)
conn.close()
url_patterns = [
('/',html),
('/home.css',css),
('/home.js',js),
('/1.jpg',jpg),
('/favicon.ico',ico),
]
while 1:
conn,addr = server.accept()
from_client_msg = conn.recv(1024).decode('utf-8')
request_path = from_client_msg.split(' ')[1]
print(request_path)
conn.send(b'HTTP/1.1 200 ok\r\n\r\n')
for i in url_patterns:
if i[0] == request_path:
target_thread = Thread(target=i[1],args=(conn,))
# to_client_data = i[1]()
target_thread.start()
server.close()
# 注意：这里不能跟函数web框架一样在循环外关闭套接字、服务器
# 因为我的代码里只有一个变量名。通俗点形容：当一个客户来访问服务器，我就创建一个线程给他个名字叫：conn，并让她去服务这个客户，他俩离开后，如果又来一个用户，我就再创建一个线程，并且把之前那个线程的名字给拿走给这个新的线程，但是这样并不影响之前的线程服务用户，他俩玩他俩的。
# 但当其中一个线程先运行完后，他就会执行循环外的conn.close()，这时如果正好创建了一个线程，把名字也给了，但是还没来得及去服务，他就被辞职了，这时没人服务用户了，程序就出错了！而且，在辞职完conn后，还要关门停止营业，这就不是我预期的效果了。
动态页面版web框架
动态页面的意思是：同一个url，我每次打开时都不同于之前。而非，带闪图、动态等重复变化的页面。
from threading import Thread
import socket
import time
server = socket.socket()
server.bind(('127.0.0.1',8001))
server.listen()
def html(conn):
current_time = time.time()
# import pymysql
with open('home.html', 'r',encoding='utf-8') as f:
to_client_data = f.read()
to_client_data = to_client_data.replace('%xxoo%',str(current_time))
conn.send(to_client_data.encode('utf-8'))
conn.close()
# return to_client_data
def css(conn):
with open('home.css', 'rb') as f:
to_client_data = f.read()
conn.send(to_client_data)
conn.close()
def js(conn):
with open('home.js', 'rb') as f:
to_client_data = f.read()
conn.send(to_client_data)
conn.close()
def jpg(conn):
with open('1.jpg', 'rb') as f:
to_client_data = f.read()
conn.send(to_client_data)
conn.close()
def ico(conn):
with open('xx1.ico', 'rb') as f:
to_client_data = f.read()
conn.send(to_client_data)
conn.close()
url_patterns = [
('/',html),
('/home.css',css),
('/home.js',js),
('/1.jpg',jpg),
('/favicon.ico',ico),
]
while 1:
conn,addr = server.accept()
from_client_msg = conn.recv(1024).decode('utf-8')
request_path = from_client_msg.split(' ')[1]
print(request_path)
conn.send(b'HTTP/1.1 200 ok\r\n\r\n')
for i in url_patterns:
if i[0] == request_path:
target_thread = Thread(target=i[1],args=(conn,))
# to_client_data = i[1]()
target_thread.start()
server.close()
wsgiref版web框架
wsgiref模块是对socket的封装，其内部的environ是对http信息进行了切割，并整理成一个字典，想要用户的什么数据，只要知道这个数据对应的键名就可以直接拿到了，而什么数据对应什么键都是其内部定义好了的，所以用起来很方便。
Django中也有可以实现wsgiref模块功能的元素，也是通过某些功能直接将http信息做好了切割，保存，通过指定方式去拿指定信息就可以了。
from wsgiref.simple_server import make_server
url_patterns = [('/index',index),]
def index():
with open('html', 'rb') as f:
to_client_data = f.read()
return to_client_data
def application(environ, start_response):
"""
:param environ: 封装了所有的http协议相关信息--一个字典{'path_info':'/'}
:param start_response:
:return:
"""
request_path = environ['PATH_INFO']
# 通过固定键名'PATH_INFO'直接拿到用户的请求路径
for i in url_patterns:
if i[0] == request_path:
ret = i[1]()
start_response('200 OK', [('k1','v1'),])
# print(environ)
# print(environ['PATH_INFO'])
return [ret]
httpd = make_server('127.0.0.1', 8080, application)
httpd.serve_forever()
B/S概念
随着Internet和WWW的流行，以往的主机/终端和C/S都无法满足当前的全球网络开放、互连、信息随处可见和信息共享的新要求，于是就出现了B/S架构，即浏览器/服务器结构。它是C/S架构的一种改进，可以说属于三层C/S架构。主要是利用了不断成熟的WWW浏览器技术，用通用浏览器就实现了原来需要复杂专用软件才能实现的强大功能，并节约了开发成本，是一种全新的软件系统构造技术。
结构：
第一层是浏览器，即客户端，只有简单的输入输出功能，处理极少部分的事务逻辑。由于客户不需要安装客户端，只要有浏览器就能上网浏览，所以它面向的是大范围的用户，所以界面设计得比较简单，通用。
第二层是WEB服务器，扮演着信息传送的角色。当用户想要访问数据库时，就会首先向WEB服务器发送请求，WEB服务器统一请求后会向数据库服务器发送访问数据库的请求，这个请求是以 SQL 语句实现的。
第三层是数据库服务器，他扮演着重要的角色，因为它存放着大量的数据。当数据库服务器收到了WEB服务器的请求后，会对 SQL 语句进行处理，并将返回的结果发送给WEB服务器，接下来，WEB服务器将收到的数据结果转换为HTML文本形式发送给浏览器，也就是我们打开浏览器看到的界面。
原理
B/S架构采取浏览器请求，服务器响应的工作模式。
用户可以通过浏览器去访问Internet上由Web服务器产生的文本、数据、图片、动画、视频点播和声音等信息；
而每一个Web服务器又可以通过各种方式与数据库服务器连接，大量的数据实际存放在数据库服务器中；
从Web服务器上下载程序到本地来执行，在下载过程中若遇到与数据库有关的指令，由Web服务器交给数据库服务器来解释执行，并返回给Web服务器，Web服务器又返回给用户。在这种结构中，将许许多多的网连接到一块，形成一个巨大的网，即全球网。而各个企业可以在此结构的基础上建立自己的Internet。
在 B/S 模式中，用户是通过浏览器针对许多分布于网络上的服务器进行请求访问的，浏览器的请求通过服务器进行处理，并将处理结果以及相应的信息返回给浏览器，其他的数据加工、请求全部都是由Web Server完成的。通过该框架结构以及植入于操作系统内部的浏览器，该结构已经成为了当今软件应用的主流结构模式。
B/S优缺点
B/S架构最大的优点是总体拥有成本低、维护方便、 分布性强、开发简单，可以不用安装任何专门的软件就能 实现在任何地方进行操作，客户端零维护，系统的扩展非常容易，只要有一台能上网的电脑就能使用。
最大的缺点就是通信开销大、系统和数据的安全性较难保障。
C/S与B/S
在响应速度，用户界面，数据安全等方面，C/S强于B/S，但是在业务扩展和适用 www 条件下，B/S明显胜过C/S。可以这么说，B/S的强项就是C/S的弱项，反之亦然。它们各有优缺点，相互无法取代。
C/S结构与B/S结构两种模式各自拥有其特色优势，在不同的系统环境与操作平台下，选择较为接近或交叉进 行混合模式的使用，可以保证数据的敏感性、安全性和稳定发展，还可以加强对数据库的修改与新增记录的操作。 对客户端程序进行保护，提高资源数据的交互性能，实现系统维护成本较低、维护方式较简便、布局更合理、网络数据使用效率较高的目的，采用C/S与B/S混合模式才是最佳方案。
C/S与B/S不同点
C/S
B/S
硬件环境
专用网络
广域网
安全要求
面向相对固定的用户群信息安全的控制能力强
面向不可知的用户群对安全的控制能力相对较弱
程序架构
更加注重流程系统运行速度可较少考虑
对安全以及访问速度都要多重的考虑，是发展趋势
软件重用
差
好
系统维护
升级难
开销小，方便升级
处理问题
集中
分散
用户接口
与操作系统关系密切
跨平台，与浏览器相关
信息流
交互性低
交互密集
