必备知识：
URL:统一资源定位符 对网络中资源的定位地址
URI:是统一资源标识符 对网络资源的标识
SSL:安全套接层
TLS:安全传输层协议 用于在两个通信应用程序之间提供保密性和数据完整性
TLS与SSL在传输层对网络连接进行加密
基本加密算法：
对称加密：密钥只有一个，加密解密为同一个密码，且加解密速度快，典型的对称加密算法有DES、AES等。 加密方和解密方是对称的
非对称加密：密钥成对出现（且根据公钥无法推知私钥，根据私钥也无法推知公钥），加密解密使用不同密钥（公钥加密需要私钥解密，私钥加密需要公钥解密），相对对称加密速度较慢，典型的非对称加密算法有RSA、DSA等。 安全性更高
专业名词：
1.无连接：限制每次连接只处理一个请求 处理完后断开连接
2.无状态：对于事务处理没有记忆能力，服务器不知道客户端是什么状态
HTTP:超文本传输协议
基于TCP的协议 提供简单快速无连接无状态的服务
版本
1.HTTP/1.1
我们目前使用浏览网站的大部分是HTTP/1.1
缺点：
1）一个连接一次只能发送一个请求
2）明文请求
2.SPDY 过渡
通过多路复用、请求优化和 HTTP 头部压缩等功能，来最小化 HTTP/1.1 的各种性能限制所导致的延迟
3.HTTP/2
3.1是二进制的而非文本的
HTTP/2 将一个 TCP 连接分为若干个流 (stream)，每个流中可以传输若干消息 (message)，每个消息由若干最小的二进制帧 (frame) 组成
3.2是完全多路复用而非按顺序和阻塞的
多路复用允许多个请求和响应消息同时发出
3.3压缩头部
大网站优势明显
3.4允许服务器主动推送资源给客户端
服务器会主动推送它认为的客户端会需要缓存的资源
事务
一次HTTP操作称为一个事务
事务的流程：
1.首先客户机与服务器需要建立连接
2.建立连接后，客户机发送一个请求给服务器
3.服务器接到请求后，给予相应的响应信息 包括状态行
4.客户端接收服务器所返回的信息通过终端显示在用户的显示屏上，然后断开连接。
HTTP内容
请求报文
请求行：GET /images/logo.gif HTTP/1.1
请求头： Accept-Language: en UserAgent等
请求实体：
请求方式
GET 向特定的资源发出请求 访问url即可发起get请求 相应速度快 参数拼接在url上 数据大小有限制 容易被爬
POST 向指定资源提交数据进行处理请求 数据被包含在请求体中 数据交互量大
PUT 向指定资源位置上传其最新内容
HEAD 向服务器索要与GET请求相一致的响应，只不过响应体将不会被返回
响应报文：
状态行 包含状态码
响应头
报文实体
状态码
400 请求错误
200 请求已成功
202 服务器已接受未处理
404 请求失败，请求所希望得到的资源未被在服务器上发现
403 服务器拒绝请求的操作
HTTP认证机制
HTTP是无状态协议 而认证需要保存状态，保存状态有3种方式
Cookie
Cookie机制是一种将数据保存在客户端的机制
客户端向服务端 发送请求 客户端返回时会带上一个cookie信息
下次客户端 请求时带上这个cookie就能认证为同一用户
弊端：cookie 中的所有数据在客户端就可以被修改，数据非常容易被伪造，
一些重要的数据就不能存放在 cookie 中
Session
Session机制是一种将数据保存在服务器端的机制
通过session_id来进行，session_id通常是存放在客户端的 cookie
当请求到来时，服务端检查 cookie 中保存的 session_id 并通过这个 session_id 与服务器端的 session data 关联起来，进行数据的保存和修改
session id的值应该是一个既不会重复，又不容易被找到规律以仿造的字符串
session 可以存放在
1）内存
2）cookie本身
3）redis 或 memcached 等缓存中
4）数据库中
Token
Token 是在服务端产生的
前端使用用户名密码向服务端请求认证，服务端认证成功，那么在服务端会返回 Token 给前端
前端可以在每次请求的时候带上 Token 证明自己的合法地位。如果这个 Token 在服务端持久化（比如存入数据库），那它就是一个永久的身份令牌。
Token失效
1.在服务器端保存 Token 状态，用户每次操作都会自动刷新（推迟） Token 的过期时间
2.一旦 Token 过期，就反馈给前端，前端使用 Refresh Token 申请一个全新 Token 继续使用
HTTPS
HTTPS=HTTP+SSL(安全套接层)为HTTP连接提供加密服务
原理阐述
1.如何加密保证连接不会被第三方截取后得到明文
通常C/S会采用对称算法对要传输的数据在发送端进行加密在接收端解密
接着面临的问题是如何保证双方协商对称加密算法的安全
为了保证客户端暴露算法详情
HTTPS采用运行时生成随机数决定对称算法来保证每个客户端的对称密钥都不同
但是密钥和对称算法都需要服务端告诉客户端 如何保证这个过程的安全？
2.服务端使用非对称算法的私钥对这个过程进行加密 所以客户端有公钥 这样就只有服务端能解密 保证了client->server的安全
客户端如何保证这个公钥没有被篡改？ 这里就用到了第三方证书
3.服务端将公钥交由第三方证书的私钥加密 客户端使用第三方的公钥进行解密 若能成功解密 则没有被篡改过
但这里又有安全隐患！因为第三方机构发放证书是一对多的 若恶意中间人使用 他们加密后的证书给客户端 客户端也可以解密 使得客户端请求的正文遭到篡改
客户端如何保证这个证书没有篡改？答案在证书本身
4.证书上写着如何根据证书的内容生成证书编号 且证书编号是经过第三方机构私钥加密了
当客户端拿到证书后，使用第三方机构公钥解密生成真正的证书编号 与客户端生成的编号进行比较
如果客户端计算出来的证书编号与证书中的证书编号相同，则验证通过
第三方机构的公钥如何在客户端的机器中呢？
其实在浏览器和操作系统都会维护一个权威的第三方机构列表（包括它们的公钥）。因为客户端接收到的证书中会写有颁发机构，客户端就根据这个颁发机构的值在本地找相应的公钥。
具体请求过程
[站外图片上传中...(image-9aab70-1523895586455)]
文字解释
最根本：
client有第三方公钥
服务器通过第三方加密 功能上等于 有第三方私钥
这是最根本的保证
网友评论