30 | 时代之风（上）：HTTP/2特性概览
- 头部压缩
- http/1里面可以用头字段
Content-Encoding指定body的编码方式，比如使用gzip压缩来节约带宽，但报文的header部分却没有优化手段。 - 在header里字段多，并且很多字段值都是重复的，重复传递相同的内容会大量消耗带宽。
- http/2使用“HPACK”算法对头部字段压缩，在客户端和服务端建立“字典”，用索引号表示重复的字符串。
- 二进制格式
- http/1是ASCII 码的纯文本形式的报文。
- http/2以二进制格式为基础，把“header+body”的消息打散为多个小片的二进制帧，用"HEADERS"帧存放头数据，“DATA”帧存放实体数据。
- 多路复用
- http/2定义了“流”的概念，它是二进制帧的双向传输序列，同一个消息往返的帧会分配一个唯一的流ID。在一个TCP连接上，用“流”同时发送多个“碎片化”消息，这就是多路复用。即多个往返通道都复用一个tcp连接来处理。
- 多个请求/响应之间没有了顺序关系，不需要排队等待，也就不会出现http的“队头阻塞”问题，提高了连接的利用率。
4. 服务器推送
不再是请求-应答的工作模式，服务器可以新建“流”主动向客户端发送消息，比如浏览器刚请求html的时候，就提前把可能用到的css、js等资源发送给客户端，减少等待的延迟。
31 | 时代之风（下）：HTTP/2内核剖析
- HTTP/2 废除了起始行，统一使用头字段，在两端维护字段“Key-Value”的索引表，使用“HPACK”算法压缩头部；
- HTTP/2 把报文切分为多种类型的二进制帧，报头里最重要的字段是流标识符，标记帧属于哪个流；
- 流是 HTTP/2 虚拟的概念，是帧的双向传输序列，相当于 HTTP/1 里的一次“请求 - 应答”；
- 在一个 HTTP/2 连接上可以并发多个流，也就是多个“请求 - 响应”报文，这就是“多路复用”。
32 | 未来之路：HTTP/3展望
- TCP存在队头阻塞。
- QUIC协议选择了UDP。真正解决了队头阻塞问题，
- QUIC 的基本数据传输单位是包和帧，一个包由多个帧组成，包面向的是“连接”，帧面向的是“流
- QUIC 使用不透明的“连接 ID”来标记通信的两个端点，支持“连接迁移”。
- HTTP/3 没有指定默认端口号，需要用 HTTP/2 的扩展帧“Alt-Svc”来发现。
33 | 我应该迁移到HTTP/2吗？
http/2缺点
- 当TCP重新连接的时候，要再次“握手”，经历“慢启动”，而且之前连接里积累的 HPACK 字典也都消失了，必须重头开始计算，导致带宽浪费和时延。
- HTTP/2 对一个域名只开一个连接，所以一旦这个连接出问题，那么整个网站的体验也就变差了。
精灵图（Spriting）、资源内联（inlining）、域名分片（Sharding）这些手段为什么会对 HTTP/2 的性能优化造成反效果呢？
- 使用精灵图，文件就变大了，大文件会延迟客户端的执行，且相比分开请求会更慢，当更新了少量的资源，都需要重新下载。http/2有头部压缩和多路复用，传输小文件的成本很低。
- 资源内联，是将一个资源作为另一个资源的一部分，使二者作为一个整体的资源来请求。http/1使用内联资源主要是为了减少请求的次数，但是内联资源没办法独立的缓存，这就破坏了http/2的多路复用和优先级策略。比如图片是固定的，html是动态的，如果不内联，能更好地发挥缓存的优势。
- 域名分片是为了解决http/1突破浏览器对同一个域名的连接数限制，但是在http/2中使用多路复用技术，一个tcp连接里可以有多次请求，域名分片对于http/2会增加连接成本，HPACK字典、慢启动等多个不利因素，所以应该少用。
