HTTP
- 无状态
- 简单快速
- 基于TCP/IP
- 灵活
- 明文传输
- 默认端口号：80
HTTPS
- 证书加密
- 安全
- SSL/TLS
- = HTTP + SLL/TLS
- 默认端口号：443
加密
SSL
- 对称加密：采用协商的秘钥进行对数据加密
- 非对称加密：实现身份认证和秘钥协商
- 摘要算法： 验证信息的完整性
- 数字签名：身份证验证
对称加密
指的是加密和解密的秘钥都是同一个，是对称的，只要保证了秘钥的安全即可
明文=> 加密数据=> 服务端解密
非对称加密
存在两个秘钥，一个是私钥、一个公钥
私钥和公钥都是可用加密解密，但是公钥加密后只能用私钥解密（国密sm？？？），反过来，私钥加密后，只能通过公钥解密
明文=> 公钥加密=> 服务器接收=> 私钥解密=>明文
混合加密
将对称加密和非对称加密结合起来，就是https加密的流程啦
- 非对称加密，使用的获取交换信息的秘钥
- 开销大
- 加密复杂
- 安全系数高
- 对称加密，主要等客户端、服务端都完成非对称加密后，进行加密信息的传入
- 开销小
- 加密简单
- 只需要同一个秘钥即可
为什么要这样做呢？
- 单独使用对称加密，一旦泄露秘钥则不安全
- 先用非对称加密，加密私钥，形成秘钥在进行通讯，更安全
CA
- 第三方认证机构，可以发放SSL证书
SSL
- 相当于身份证
- 里面包公钥
- 支撑加密方式（SHA256）
流程
第一次，客户端通知服务端，发送对应证书信息、版本、R1
- Client Hello
- 客户端发起
- 浏览器端根据可支持加密方式、CA证书（SSL证书）、加密套件、SSL版本
- 生产一个随机R1
- 2个消息发送给服务端
第二次，服务端接接收到R1、选择可用的证书、版本，生产R2返回到客户端，验证身份证
- Server Hello
- 执行者：客户端
- 确定加密方式、SSL版本、加密版本（这边只是挑选可以求作用的套件）
- 生产一个随机R2
- 结合发送给客户端
- Certifcate
- 执行者：服务端
- 出示自己的证书，表明身份证，来确定是自己不是别人假冒
- 服务端发起给客户端
- Server Key Exchange
- 执行者：服务端
- 将公钥发送给客户端
- 可以发出要求客户端发送自己的证书，保证安全
- 服务端发出个客户端
- Server Hello End（结束）
- 执行者：客户端
- 告诉客户端我都ok了
- 服务端发出客户端
第三次，客户端收到数据，并且拿到pubkey，确认身份证，然后随机生成R3，加密生产预主秘钥，发送给客户端
- Client Exchange Key，Encrypted Handshake Message
- 执行者：客户端
- 客户端生产第三个随机数R3
- 客户端收到了服务端的公钥，会将公钥加密R3=>预主秘钥
- 发送给服务器，报文pubkey指向的及时预主秘钥
- 客户端发出服务端
第四次，服务端收到预主秘钥，通过私钥解析或主要R3，将R123进行加密通讯秘钥
- Encrpyted Handke Message
- 执行者：服务端
- 客户将接收预主秘钥，通过服务端秘钥进行解密，生产R3
- 统一将R1,R2,R3进行生产生产通讯秘钥
- 发送给客户端，我这边搞定了
- 客户端将R123通过算法生产通讯秘钥
- 开始通讯
特点
- 仅在当前通话中有效，离开则失效
摘要算法
又称hash算法，输入任意长度的数据，可以返回一个固定长度的数据
这个摘要算法主要是在第二步，ca证书认证时候用到的
- MD5
- SHA-1
- SHA-256
为什么要是用摘要算法？
首先我们可以加密后得到一个固定长度数据，是与原文完全等价的，其次我们在原文附后他的摘要
let message = 'abc';
let sha2str = SHA2(message)
return message + sha2str;
这样我们可以把数据传输到对方，对方可以将数据的sha2str解密，对比原文，是否相同，避免有人修改明文
message=> 证书信息
-
浏览器需要发送
message
-
将message用sha2编译摘要，并添加到messag后面，形成msgstr
-
将msgstr和从非对称加密后的通讯秘钥进行加密发送
-
服务器接收到数据，将通讯秘钥解密获取到msgstr
-
截取msg进行sha2编译，对比str是否相同
-
相同则接收，ok认证成功是真的证书
这是算法，不是传输协议
- 加密
- 信息进行信息摘要（SHA2、MD5算法），生产密文
- 通过秘钥（数字证书）进行str加密
- 摘要+密文，搭配证书公钥，生产数字签名
- 发送
- 解密
- 收到数据，进行公钥解密生产摘要+密文
- 将信息进行信息摘要，形成密文
- 匹配密文与信息是否相等
数字签名
数字签名可能确定消息缺失有发送方签名并发送的，因为别人假冒不了发送发的签名
-
流程
- 服务器运营人员向CA认证机构提出公开密钥的申请
- CA机构在判断申请身份后，对公钥做数字签名
- 将签名+公钥，绑定一起，这就是公钥证书
- 服务器会CA机构发布的公钥证书发送给客户端，进行非对称加密通讯（Certificate阶段）
- 客户端接收到CA证书后，可以将里面公钥对气签名（Sign）签名验证
- 确定是否真实可信赖
优化
- 使用SLB（服务器负载均衡）
- 使用CDN（内容分发网络）
中间人攻击
因为有中间人攻击，所以加入了CA数字签名
- 客户端发送请求公钥
- 中间人拦截，替代客户端发送
- 中间人收到公钥，并制造一个FAKE公钥
- 每次加密后，都可以用，中间人都是解密拿到数据，然后用真实公钥加密代替发送
- 拿到数据后解密，通过自己的des加密发送给服务端
所以我们要防止被中间人攻击，需要引入CA证书
中间人会去篡改证书吗
可能会获取到证书，修改证书的域名，但是CA机构的撕咬的是本地的，他拿不到。无法创建一个新的签名，签名是需要申请的。
客户端收到篡改的证书， 通过私钥解密证书摘要，同时客户端也要对收到证书内容生产信息摘要，2个Str对比发现存在问题，则断开连接
版本
HTTP1.0
每次请求只能等到返回数据后才能再次请求
短连接
每次与服务器交互必须再次链接
HTTP1.1
每次请求后，会长连接状态keep-alive
一次TCP/IP链接，可以发送多个HTTP请求和接收多个响应，增加了沟通效率
同时客户端，可以不用等上次请求结果，直接再次发送，但是服务器是必须同步按序返回数据。
新增
- 缓存控制，cache-control、IF-No-Match -E-tag、 experise、 maxage等控制花村
- 引入range，控制运行值请求某个部分
- 引入host，实现一台web服务器可以再同一个ip和端口上使用不用的主机名来创建多个虚拟节点
- Put delete update options方法
HTTP2.0
- 多路复用
- 二进制分针
- header压缩
- 服务器推送
多路复用
HTTP/2 复用TCP链接，在一个链接里，客户端和服务端都可以同时发送多个请求，不用按照顺序一一对应，便面了队列阻塞
二进制分帧
帧是HTTP2中最小的信息单温
采用二进制格式，而非1.x版本的文本格式，解析起来更高效
其实就将数据解析成二进制数据
因为在http2中，同域名下的所有通讯都是单连接中完成，该链接中可以承载任何数量的双向数据流
每个数据流都是二进制数据发送，根据帧头部的流表示区别后重新编码装
首部压缩
因为只有一次链接，所以客户端和服务端使用首部表来跟踪和记录之前发送的键值对，对相同数据，不咋进行响应和回复
首部表是在连接中始终存在的，由服务端、客户端共同更新维护
服务器推送
可以让服务器主动推送到客户端
