『30 天沉淀 90 mins』Day 3 http2.0 探索与 https 入门
http2.0 探索
http1.1 如何优化？
-
通过缓存技术来避免发送 HTTP 请求。客户端收到第一个请求的响应后，可以将其缓存在本地磁盘，下次请求的时候，如果缓存没过期，就直接读取本地缓存的响应数据。如果缓存过期，客户端发送请求的时候带上响应数据的摘要，服务器比对后发现资源没有变化，就发出不带包体的 304 响应，告诉客户端缓存的响应仍然有效。
-
减少 HTTP 请求的次数，有以下的方法：
- 将原本由客户端处理的重定向请求，交给代理服务器处理，这样可以减少重定向请求的次数；
- 将多个小资源合并成一个大资源再传输，能够减少 HTTP 请求次数以及 头部的重复传输，再来减少 TCP 连接数量，进而省去 TCP 握手和慢启动的网络消耗；
- 按需访问资源，只访问当前用户看得到/用得到的资源，当客户往下滑动，再访问接下来的资源，以此达到延迟请求，也就减少了同一时间的 HTTP 请求次数。
- 通过压缩响应资源，降低传输资源的大小，从而提高传输效率，所以应当选择更优秀的压缩算法。
不管怎么优化 HTTP/1.1 协议都是有限的，不然也不会出现 HTTP/2 和 HTTP/3 协议。
http2.0 所做改进
头部压缩
- 头部含很多固定的字段，比如 Cookie、User Agent、Accept 等，这些字段加起来也高达几百字节甚至上千字节，所以有必要压缩；
- 大量的请求和响应的报文里有很多字段值都是重复的，这样会使得大量带宽被这些冗余的数据占用了，所以有必须要避免重复性；
涉及静态表编码、动态表编码，编码方式采用 huffman 编码。
静态表编码
http2.0框架自带一个静态表，有 61 项，对于每一项来说：
Index | Header Name | Header Value
例子：
8 | :status | 200
状态码 200 index 为 8
动态表编码
静态表只包含了 61 种高频出现在头部的字符串，不在静态表范围内的头部字符串就要自行构建动态表，它的 Index 从 62 起步，会在编码解码的时候随时更新。
比如，第一次发送时头部中的「User-Agent 」字段数据有上百个字节，经过 Huffman 编码发送出去后，客户端和服务器双方都会更新自己的动态表，添加一个新的 Index 号 62。那么在下一次发送的时候，就不用重复发这个字段的数据了，只用发 1 个字节的 Index 号就好了，因为双方都可以根据自己的动态表获取到字段的数据。
二进制帧
http2.0 将 http1.1 的文本格式压缩成二进制极大地节省了空间，将报文压缩成了 Headers Frame 和 Data Frame。多个 http 报文的两种 frame 被放在单个 stream 里传输。
帧的结构：
- 前 3 个字节表示帧数据的长度。
- 帧长度后面的 1 个字节是表示帧类型。
- 帧类型后面的一个字节是标志位，可以保存 8 个标志位。于携带简单的控制信息，比如：
- END_HEADERS 表示头数据结束标志，相当于 HTTP/1 里头后的空行（“\r\n”）；
- END_Stream 表示单方向数据发送结束，后续不会再有数据帧。
- PRIORITY 表示流的优先级；
- 帧头的最后 4 个字节是流标识符（Stream ID），但最高位被保留不用，只有 31 位可以使用，因此流标识符的最大值是 2^31，大约是 21 亿。
- 作用是用来标识该 Frame 属于哪个 Stream，接收方可以根据这个信息从乱序的帧里找到相同 Stream ID 的帧，从而有序组装信息。
并发传输
- 1 TCP -> 多 Stream。
- 1 Stream -> 多 http2.0 frame = 多个http报文数据
- 1 TCP -> 多个 http 报文
- HTTP/2 实现了 Stream 并发，多个 Stream 只需复用 1 个 TCP 连接，节约了 TCP 和 TLS 握手时间，以及减少了 TCP 慢启动阶段对流量的影响。不同的 Stream ID 可以并发，即使乱序发送帧也没问题，比如发送 A 请求帧 1 -> B 请求帧 1 -> A 请求帧 2 -> B 请求帧2，但是同一个 Stream 里的帧必须严格有序。
https
在 http 于 tcp 之间加入 SSL/TLS 层
考虑通信交流的场景，不安全的情况无非 3 种：
- 盗听，信息加密解决。
- 篡改，校验机制解决。
- 冒充，身份证数解决。
HTTPS 具体实践
- 混合加密的方式实现信息的机密性，解决了窃听的风险。
- 摘要算法、数字签名的方式来实现完整性，它能够为数据生成独一无二的「指纹」，指纹用于校验数据的完整性，解决了篡改的风险。
- 服务器公钥放入到数字证书中，解决了冒充的风险。
混合加密
HTTPS 采用的是对称加密和非对称加密结合的「混合加密」方式：
- 在通信建立前采用非对称加密的方式交换「会话秘钥」，后续就不再使用非对称加密。
- 非对称加密使用两个密钥：公钥和私钥，公钥可以任意分发而私钥保密，解决了密钥交换问题但速度慢。
- 在通信过程中全部使用对称加密的「会话秘钥」的方式加密明文数据。
- 对称加密只使用一个密钥，运算速度快，密钥必须保密，无法做到安全的密钥交换。
摘要算法+数字签名
- 用摘要算法（哈希函数）来计算出内容的哈希值，连同内容一起传送，接收方受到内容，哈希运算后和哈希值再作对比，但可能哈希值被篡改，因此需要特别加密。
- 利用 『私钥加密、公钥解密』的非对称加密方式可以确认发送方的身份，对哈希值加密，也是数字签名的加密方式。
- 私钥由服务端保管，然后服务端会向客户端颁发对应的公钥。如果客户端收到的信息，能被公钥解密，就说明该消息是由服务器发送的。
数字证书
解决了身份冒充的问题。
数字证书包含服务端的 服务器信息、公钥、数字签名 。
