mod

极客时间专栏/透视HTTP协议/飞翔篇/30 | 时代之风（上）：HTTP|2特性概览.md

@@ -0,0 +1,132 @@
+<audio id="audio" title="30 | 时代之风（上）：HTTP/2特性概览" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/eb/d5/ebc13babfb4a88680afcf18dde166fd5.mp3"></audio>
+
+在[第14讲](https://time.geekbang.org/column/article/103746)里，我们看到HTTP有两个主要的缺点：安全不足和性能不高。
+
+刚结束的“安全篇”里的HTTPS，通过引入SSL/TLS在安全上达到了“极致”，但在性能提升方面却是乏善可陈，只优化了握手加密的环节，对于整体的数据传输没有提出更好的改进方案，还只能依赖于“长连接”这种“落后”的技术（参见[第17讲](https://time.geekbang.org/column/article/104949)）。
+
+所以，在HTTPS逐渐成熟之后，HTTP就向着性能方面开始“发力”，走出了另一条进化的道路。
+
+在[第1讲](https://time.geekbang.org/column/article/97837)的HTTP历史中你也看到了，“秦失其鹿，天下共逐之”，Google率先发明了SPDY协议，并应用于自家的浏览器Chrome，打响了HTTP性能优化的“第一枪”。
+
+随后互联网标准化组织IETF以SPDY为基础，综合其他多方的意见，终于推出了HTTP/1的继任者，也就是今天的主角“HTTP/2”，在性能方面有了一个大的飞跃。
+
+## 为什么不是HTTP/2.0
+
+你一定很想知道，为什么HTTP/2不像之前的“1.0”“1.1”那样叫“2.0”呢？
+
+这个也是很多初次接触HTTP/2的人问的最多的一个问题，对此HTTP/2工作组特别给出了解释。
+
+他们认为以前的“1.0”“1.1”造成了很多的混乱和误解，让人在实际的使用中难以区分差异，所以就决定HTTP协议不再使用小版本号（minor version），只使用大版本号（major version），从今往后HTTP协议不会出现HTTP/2.0、2.1，只会有“HTTP/2”“HTTP/3”……
+
+这样就可以明确无误地辨别出协议版本的“跃进程度”，让协议在一段较长的时期内保持稳定，每当发布新版本的HTTP协议都会有本质的不同，绝不会有“零敲碎打”的小改良。
+
+## 兼容HTTP/1
+
+由于HTTPS已经在安全方面做的非常好了，所以HTTP/2的唯一目标就是改进性能。
+
+但它不仅背负着众多的期待，同时还背负着HTTP/1庞大的历史包袱，所以协议的修改必须小心谨慎，兼容性是首要考虑的目标，否则就会破坏互联网上无数现有的资产，这方面TLS已经有了先例（为了兼容TLS1.2不得不进行“伪装”）。
+
+那么，HTTP/2是怎么做的呢？
+
+因为必须要保持功能上的兼容，所以HTTP/2把HTTP分解成了“语义”和“语法”两个部分，“语义”层不做改动，与HTTP/1完全一致（即RFC7231）。比如请求方法、URI、状态码、头字段等概念都保留不变，这样就消除了再学习的成本，基于HTTP的上层应用也不需要做任何修改，可以无缝转换到HTTP/2。
+
+特别要说的是，与HTTPS不同，HTTP/2没有在URI里引入新的协议名，仍然用“http”表示明文协议，用“https”表示加密协议。
+
+这是一个非常了不起的决定，可以让浏览器或者服务器去自动升级或降级协议，免去了选择的麻烦，让用户在上网的时候都意识不到协议的切换，实现平滑过渡。
+
+在“语义”保持稳定之后，HTTP/2在“语法”层做了“天翻地覆”的改造，完全变更了HTTP报文的传输格式。
+
+## 头部压缩
+
+首先，HTTP/2对报文的头部做了一个“大手术”。
+
+通过“进阶篇”的学习你应该知道，HTTP/1里可以用头字段“Content-Encoding”指定Body的编码方式，比如用gzip压缩来节约带宽，但报文的另一个组成部分——Header却被无视了，没有针对它的优化手段。
+
+由于报文Header一般会携带“User Agent”“Cookie”“Accept”“Server”等许多固定的头字段，多达几百字节甚至上千字节，但Body却经常只有几十字节（比如GET请求、204/301/304响应），成了不折不扣的“大头儿子”。更要命的是，成千上万的请求响应报文里有很多字段值都是重复的，非常浪费，“长尾效应”导致大量带宽消耗在了这些冗余度极高的数据上。
+
+所以，HTTP/2把“**头部压缩**”作为性能改进的一个重点，优化的方式你也肯定能想到，还是“压缩”。
+
+不过HTTP/2并没有使用传统的压缩算法，而是开发了专门的“**HPACK**”算法，在客户端和服务器两端建立“字典”，用索引号表示重复的字符串，还釆用哈夫曼编码来压缩整数和字符串，可以达到50%~90%的高压缩率。
+
+## 二进制格式
+
+你可能已经很习惯于HTTP/1里纯文本形式的报文了，它的优点是“一目了然”，用最简单的工具就可以开发调试，非常方便。
+
+但HTTP/2在这方面没有“妥协”，决定改变延续了十多年的现状，不再使用肉眼可见的ASCII码，而是向下层的TCP/IP协议“靠拢”，全面采用二进制格式。
+
+这样虽然对人不友好，但却大大方便了计算机的解析。原来使用纯文本的时候容易出现多义性，比如大小写、空白字符、回车换行、多字少字等等，程序在处理时必须用复杂的状态机，效率低，还麻烦。
+
+而二进制里只有“0”和“1”，可以严格规定字段大小、顺序、标志位等格式，“对就是对，错就是错”，解析起来没有歧义，实现简单，而且体积小、速度快，做到“内部提效”。
+
+以二进制格式为基础，HTTP/2就开始了“大刀阔斧”的改革。
+
+它把TCP协议的部分特性挪到了应用层，把原来的“Header+Body”的消息“打散”为数个小片的**二进制“帧”**（Frame），用“HEADERS”帧存放头数据、“DATA”帧存放实体数据。
+
+这种做法有点像是“Chunked”分块编码的方式（参见[第16讲](https://time.geekbang.org/column/article/104456)），也是“化整为零”的思路，但HTTP/2数据分帧后“Header+Body”的报文结构就完全消失了，协议看到的只是一个个的“碎片”。
+
+<img src="https://static001.geekbang.org/resource/image/8f/96/8fe2cbd57410299a1a36d7eb105ea896.png" alt="">
+
+## 虚拟的“流”
+
+消息的“碎片”到达目的地后应该怎么组装起来呢？
+
+HTTP/2为此定义了一个“**流**”（Stream）的概念，**它是二进制帧的双向传输序列**，同一个消息往返的帧会分配一个唯一的流ID。你可以把它想象成是一个虚拟的“数据流”，在里面流动的是一串有先后顺序的数据帧，这些数据帧按照次序组装起来就是HTTP/1里的请求报文和响应报文。
+
+因为“流”是虚拟的，实际上并不存在，所以HTTP/2就可以在一个TCP连接上用“**流**”同时发送多个“碎片化”的消息，这就是常说的“**多路复用**”（ Multiplexing）——多个往返通信都复用一个连接来处理。
+
+在“流”的层面上看，消息是一些有序的“帧”序列，而在“连接”的层面上看，消息却是乱序收发的“帧”。多个请求/响应之间没有了顺序关系，不需要排队等待，也就不会再出现“队头阻塞”问题，降低了延迟，大幅度提高了连接的利用率。
+
+<img src="https://static001.geekbang.org/resource/image/d8/bc/d8fd32a4d044f2078b3a260e4478c5bc.png" alt="">
+
+为了更好地利用连接，加大吞吐量，HTTP/2还添加了一些控制帧来管理虚拟的“流”，实现了优先级和流量控制，这些特性也和TCP协议非常相似。
+
+HTTP/2还在一定程度上改变了传统的“请求-应答”工作模式，服务器不再是完全被动地响应请求，也可以新建“流”主动向客户端发送消息。比如，在浏览器刚请求HTML的时候就提前把可能会用到的JS、CSS文件发给客户端，减少等待的延迟，这被称为“**服务器推送**”（Server Push，也叫Cache Push）。
+
+## 强化安全
+
+出于兼容的考虑，HTTP/2延续了HTTP/1的“明文”特点，可以像以前一样使用明文传输数据，不强制使用加密通信，不过格式还是二进制，只是不需要解密。
+
+但由于HTTPS已经是大势所趋，而且主流的浏览器Chrome、Firefox等都公开宣布只支持加密的HTTP/2，所以“事实上”的HTTP/2是加密的。也就是说，互联网上通常所能见到的HTTP/2都是使用“https”协议名，跑在TLS上面。
+
+为了区分“加密”和“明文”这两个不同的版本，HTTP/2协议定义了两个字符串标识符：“h2”表示加密的HTTP/2，“h2c”表示明文的HTTP/2，多出的那个字母“c”的意思是“clear text”。
+
+在HTTP/2标准制定的时候（2015年）已经发现了很多SSL/TLS的弱点，而新的TLS1.3还未发布，所以加密版本的HTTP/2在安全方面做了强化，要求下层的通信协议必须是TLS1.2以上，还要支持前向安全和SNI，并且把几百个弱密码套件列入了“黑名单”，比如DES、RC4、CBC、SHA-1都不能在HTTP/2里使用，相当于底层用的是“TLS1.25”。
+
+## 协议栈
+
+下面的这张图对比了HTTP/1、HTTPS和HTTP/2的协议栈，你可以清晰地看到，HTTP/2是建立在“HPack”“Stream”“TLS1.2”基础之上的，比HTTP/1、HTTPS复杂了一些。
+
+<img src="https://static001.geekbang.org/resource/image/83/1a/83c9f0ecad361ba8ef8f3b73d6872f1a.png" alt="">
+
+虽然HTTP/2的底层实现很复杂，但它的“语义”还是简单的HTTP/1，之前学习的知识不会过时，仍然能够用得上。
+
+我们的实验环境在新的域名“**www.metroid.net**”上启用了HTTP/2协议，你可以把之前“进阶篇”“安全篇”的测试用例都走一遍，再用Wireshark抓一下包，实际看看HTTP/2的效果和对老协议的兼容性（例如“[http://www.metroid.net/11-1](http://www.metroid.net/11-1)”）。
+
+在今天这节课专用的URI“/30-1”里，你还可以看到服务器输出了HTTP的版本号“2”和标识符“h2”，表示这是加密的HTTP/2，如果改用“[https://www.chrono.com/30-1](https://www.chrono.com/30-1)”访问就会是“1.1”和空。
+
+<img src="https://static001.geekbang.org/resource/image/fd/d1/fdf1a6916c3ac22b6fb7628de3d7ddd1.png" alt="">
+
+你可能还会注意到URI里的一个小变化，端口使用的是“8443”而不是“443”。这是因为443端口已经被“www.chrono.com”的HTTPS协议占用，Nginx不允许在同一个端口上根据域名选择性开启HTTP/2，所以就不得不改用了“8443”。
+
+## 小结
+
+今天我简略介绍了HTTP/2的一些重要特性，比较偏重理论，下一次我会用Wireshark抓包，具体讲解HTTP/2的头部压缩、二进制帧和流等特性。
+
+1. HTTP协议取消了小版本号，所以HTTP/2的正式名字不是2.0；
+1. HTTP/2在“语义”上兼容HTTP/1，保留了请求方法、URI等传统概念；
+1. HTTP/2使用“HPACK”算法压缩头部信息，消除冗余数据节约带宽；
+1. HTTP/2的消息不再是“Header+Body”的形式，而是分散为多个二进制“帧”；
+1. HTTP/2使用虚拟的“流”传输消息，解决了困扰多年的“队头阻塞”问题，同时实现了“多路复用”，提高连接的利用率；
+1. HTTP/2也增强了安全性，要求至少是TLS1.2，而且禁用了很多不安全的密码套件。
+
+## 课下作业
+
+1. 你觉得明文形式的HTTP/2（h2c）有什么好处，应该如何使用呢？
+1. 你觉得应该怎样理解HTTP/2里的“流”，为什么它是“虚拟”的？
+1. 你能对比一下HTTP/2与HTTP/1、HTTPS的相同点和不同点吗？
+
+欢迎你把自己的学习体会写在留言区，与我和其他同学一起讨论。如果你觉得有所收获，也欢迎把文章分享给你的朋友。
+
+<img src="https://static001.geekbang.org/resource/image/78/42/781da6191d342d71d3be2675cb610742.png" alt="unpreview">
+
+<img src="https://static001.geekbang.org/resource/image/56/63/56d766fc04654a31536f554b8bde7b63.jpg" alt="unpreview">

极客时间专栏/透视HTTP协议/飞翔篇/31 | 时代之风（下）：HTTP|2内核剖析.md

@@ -0,0 +1,177 @@
+<audio id="audio" title="31 | 时代之风（下）：HTTP/2内核剖析" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/1a/ba/1a3b423c943a63c41e476a1693c89cba.mp3"></audio>
+
+今天我们继续上一讲的话题，深入HTTP/2协议的内部，看看它的实现细节。
+
+<img src="https://static001.geekbang.org/resource/image/89/17/8903a45c632b64c220299d5bc64ef717.png" alt="">
+
+这次实验环境的URI是“/31-1”，我用Wireshark把请求响应的过程抓包存了下来，文件放在GitHub的“wireshark”目录。今天我们就对照着抓包来实地讲解HTTP/2的头部压缩、二进制帧等特性。
+
+## 连接前言
+
+由于HTTP/2“事实上”是基于TLS，所以在正式收发数据之前，会有TCP握手和TLS握手，这两个步骤相信你一定已经很熟悉了，所以这里就略过去不再细说。
+
+TLS握手成功之后，客户端必须要发送一个“**连接前言**”（connection preface），用来确认建立HTTP/2连接。
+
+这个“连接前言”是标准的HTTP/1请求报文，使用纯文本的ASCII码格式，请求方法是特别注册的一个关键字“PRI”，全文只有24个字节：
+
+```
+PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n
+
+```
+
+在Wireshark里，HTTP/2的“连接前言”被称为“**Magic**”，意思就是“不可知的魔法”。
+
+所以，就不要问“为什么会是这样”了，只要服务器收到这个“有魔力的字符串”，就知道客户端在TLS上想要的是HTTP/2协议，而不是其他别的协议，后面就会都使用HTTP/2的数据格式。
+
+## 头部压缩
+
+确立了连接之后，HTTP/2就开始准备请求报文。
+
+因为语义上它与HTTP/1兼容，所以报文还是由“Header+Body”构成的，但在请求发送前，必须要用“**HPACK**”算法来压缩头部数据。
+
+“HPACK”算法是专门为压缩HTTP头部定制的算法，与gzip、zlib等压缩算法不同，它是一个“有状态”的算法，需要客户端和服务器各自维护一份“索引表”，也可以说是“字典”（这有点类似brotli），压缩和解压缩就是查表和更新表的操作。
+
+为了方便管理和压缩，HTTP/2废除了原有的起始行概念，把起始行里面的请求方法、URI、状态码等统一转换成了头字段的形式，并且给这些“不是头字段的头字段”起了个特别的名字——“**伪头字段**”（pseudo-header fields）。而起始行里的版本号和错误原因短语因为没什么大用，顺便也给废除了。
+
+为了与“真头字段”区分开来，这些“伪头字段”会在名字前加一个“:”，比如“:authority” “:method” “:status”，分别表示的是域名、请求方法和状态码。
+
+现在HTTP报文头就简单了，全都是“Key-Value”形式的字段，于是HTTP/2就为一些最常用的头字段定义了一个只读的“**静态表**”（Static Table）。
+
+下面的这个表格列出了“静态表”的一部分，这样只要查表就可以知道字段名和对应的值，比如数字“2”代表“GET”，数字“8”代表状态码200。
+
+<img src="https://static001.geekbang.org/resource/image/76/0c/769dcf953ddafc4573a0b4c3f0321f0c.png" alt="">
+
+但如果表里只有Key没有Value，或者是自定义字段根本找不到该怎么办呢？
+
+这就要用到“**动态表**”（Dynamic Table），它添加在静态表后面，结构相同，但会在编码解码的时候随时更新。
+
+比如说，第一次发送请求时的“user-agent”字段长是一百多个字节，用哈夫曼压缩编码发送之后，客户端和服务器都更新自己的动态表，添加一个新的索引号“65”。那么下一次发送的时候就不用再重复发那么多字节了，只要用一个字节发送编号就好。
+
+<img src="https://static001.geekbang.org/resource/image/5f/6f/5fa90e123c68855140e2b40f4f73c56f.png" alt="">
+
+你可以想象得出来，随着在HTTP/2连接上发送的报文越来越多，两边的“字典”也会越来越丰富，最终每次的头部字段都会变成一两个字节的代码，原来上千字节的头用几十个字节就可以表示了，压缩效果比gzip要好得多。
+
+## 二进制帧
+
+头部数据压缩之后，HTTP/2就要把报文拆成二进制的帧准备发送。
+
+HTTP/2的帧结构有点类似TCP的段或者TLS里的记录，但报头很小，只有9字节，非常地节省（可以对比一下TCP头，它最少是20个字节）。
+
+二进制的格式也保证了不会有歧义，而且使用位运算能够非常简单高效地解析。
+
+<img src="https://static001.geekbang.org/resource/image/61/e3/615b49f9d13de718a34b9b98359066e3.png" alt="">
+
+帧开头是3个字节的**长度**（但不包括头的9个字节），默认上限是2^14，最大是2^24，也就是说HTTP/2的帧通常不超过16K，最大是16M。
+
+长度后面的一个字节是**帧类型**，大致可以分成**数据帧**和**控制帧**两类，HEADERS帧和DATA帧属于数据帧，存放的是HTTP报文，而SETTINGS、PING、PRIORITY等则是用来管理流的控制帧。
+
+HTTP/2总共定义了10种类型的帧，但一个字节可以表示最多256种，所以也允许在标准之外定义其他类型实现功能扩展。这就有点像TLS里扩展协议的意思了，比如Google的gRPC就利用了这个特点，定义了几种自用的新帧类型。
+
+第5个字节是非常重要的**帧标志**信息，可以保存8个标志位，携带简单的控制信息。常用的标志位有**END_HEADERS**表示头数据结束，相当于HTTP/1里头后的空行（“\r\n”），**END_STREAM**表示单方向数据发送结束（即EOS，End of Stream），相当于HTTP/1里Chunked分块结束标志（“0\r\n\r\n”）。
+
+报文头里最后4个字节是**流标识符**，也就是帧所属的“流”，接收方使用它就可以从乱序的帧里识别出具有相同流ID的帧序列，按顺序组装起来就实现了虚拟的“流”。
+
+流标识符虽然有4个字节，但最高位被保留不用，所以只有31位可以使用，也就是说，流标识符的上限是2^31，大约是21亿。
+
+好了，把二进制头理清楚后，我们来看一下Wireshark抓包的帧实例：
+
+<img src="https://static001.geekbang.org/resource/image/57/03/57b0d1814567e6317c8de1e3c04b7503.png" alt="">
+
+在这个帧里，开头的三个字节是“00010a”，表示数据长度是266字节。
+
+帧类型是1，表示HEADERS帧，负载（payload）里面存放的是被HPACK算法压缩的头部信息。
+
+标志位是0x25，转换成二进制有3个位被置1。PRIORITY表示设置了流的优先级，END_HEADERS表示这一个帧就是完整的头数据，END_STREAM表示单方向数据发送结束，后续再不会有数据帧（即请求报文完毕，不会再有DATA帧/Body数据）。
+
+最后4个字节的流标识符是整数1，表示这是客户端发起的第一个流，后面的响应数据帧也会是这个ID，也就是说在stream[1]里完成这个请求响应。
+
+## 流与多路复用
+
+弄清楚了帧结构后我们就来看HTTP/2的流与多路复用，它是HTTP/2最核心的部分。
+
+在上一讲里我简单介绍了流的概念，不知道你“悟”得怎么样了？这里我再重复一遍：**流是二进制帧的双向传输序列**。
+
+要搞明白流，关键是要理解帧头里的流ID。
+
+在HTTP/2连接上，虽然帧是乱序收发的，但只要它们都拥有相同的流ID，就都属于一个流，而且在这个流里帧不是无序的，而是有着严格的先后顺序。
+
+比如在这次的Wireshark抓包里，就有“0、1、3”一共三个流，实际上就是分配了三个流ID号，把这些帧按编号分组，再排一下队，就成了流。
+
+<img src="https://static001.geekbang.org/resource/image/68/33/688630945be2dd51ca62515ae498db33.png" alt="">
+
+在概念上，一个HTTP/2的流就等同于一个HTTP/1里的“请求-应答”。在HTTP/1里一个“请求-响应”报文来回是一次HTTP通信，在HTTP/2里一个流也承载了相同的功能。
+
+你还可以对照着TCP来理解。TCP运行在IP之上，其实从MAC层、IP层的角度来看，TCP的“连接”概念也是“虚拟”的。但从功能上看，无论是HTTP/2的流，还是TCP的连接，都是实际存在的，所以你以后大可不必再纠结于流的“虚拟”性，把它当做是一个真实存在的实体来理解就好。
+
+HTTP/2的流有哪些特点呢？我给你简单列了一下：
+
+1. 流是可并发的，一个HTTP/2连接上可以同时发出多个流传输数据，也就是并发多请求，实现“多路复用”；
+1. 客户端和服务器都可以创建流，双方互不干扰；
+1. 流是双向的，一个流里面客户端和服务器都可以发送或接收数据帧，也就是一个“请求-应答”来回；
+1. 流之间没有固定关系，彼此独立，但流内部的帧是有严格顺序的；
+1. 流可以设置优先级，让服务器优先处理，比如先传HTML/CSS，后传图片，优化用户体验；
+1. 流ID不能重用，只能顺序递增，客户端发起的ID是奇数，服务器端发起的ID是偶数；
+1. 在流上发送“RST_STREAM”帧可以随时终止流，取消接收或发送；
+1. 第0号流比较特殊，不能关闭，也不能发送数据帧，只能发送控制帧，用于流量控制。
+
+这里我又画了一张图，把上次的图略改了一下，显示了连接中无序的帧是如何依据流ID重组成流的。
+
+<img src="https://static001.geekbang.org/resource/image/b4/7e/b49595a5a425c0e67d46ee17cc212e7e.png" alt="">
+
+从这些特性中，我们还可以推理出一些深层次的知识点。
+
+比如说，HTTP/2在一个连接上使用多个流收发数据，那么它本身默认就会是长连接，所以永远不需要“Connection”头字段（keepalive或close）。
+
+你可以再看一下Wireshark的抓包，里面发送了两个请求“/31-1”和“/favicon.ico”，始终用的是“56095&lt;-&gt;8443”这个连接，对比一下[第8讲](https://time.geekbang.org/column/article/100502)，你就能够看出差异了。
+
+又比如，下载大文件的时候想取消接收，在HTTP/1里只能断开TCP连接重新“三次握手”，成本很高，而在HTTP/2里就可以简单地发送一个“RST_STREAM”中断流，而长连接会继续保持。
+
+再比如，因为客户端和服务器两端都可以创建流，而流ID有奇数偶数和上限的区分，所以大多数的流ID都会是奇数，而且客户端在一个连接里最多只能发出2^30，也就是10亿个请求。
+
+所以就要问了：ID用完了该怎么办呢？这个时候可以再发一个控制帧“GOAWAY”，真正关闭TCP连接。
+
+## 流状态转换
+
+流很重要，也很复杂。为了更好地描述运行机制，HTTP/2借鉴了TCP，根据帧的标志位实现流状态转换。当然，这些状态也是虚拟的，只是为了辅助理解。
+
+HTTP/2的流也有一个状态转换图，虽然比TCP要简单一点，但也不那么好懂，所以今天我只画了一个简化的图，对应到一个标准的HTTP“请求-应答”。
+
+<img src="https://static001.geekbang.org/resource/image/d3/b4/d389ac436d8100406a4a488a69563cb4.png" alt="">
+
+最开始的时候流都是“**空闲**”（idle）状态，也就是“不存在”，可以理解成是待分配的“号段资源”。
+
+当客户端发送HEADERS帧后，有了流ID，流就进入了“**打开**”状态，两端都可以收发数据，然后客户端发送一个带“END_STREAM”标志位的帧，流就进入了“**半关闭**”状态。
+
+这个“半关闭”状态很重要，意味着客户端的请求数据已经发送完了，需要接受响应数据，而服务器端也知道请求数据接收完毕，之后就要内部处理，再发送响应数据。
+
+响应数据发完了之后，也要带上“END_STREAM”标志位，表示数据发送完毕，这样流两端就都进入了“**关闭**”状态，流就结束了。
+
+刚才也说过，流ID不能重用，所以流的生命周期就是HTTP/1里的一次完整的“请求-应答”，流关闭就是一次通信结束。
+
+下一次再发请求就要开一个新流（而不是新连接），流ID不断增加，直到到达上限，发送“GOAWAY”帧开一个新的TCP连接，流ID就又可以重头计数。
+
+你再看看这张图，是不是和HTTP/1里的标准“请求-应答”过程很像，只不过这是发生在虚拟的“流”上，而不是实际的TCP连接，又因为流可以并发，所以HTTP/2就可以实现无阻塞的多路复用。
+
+## 小结
+
+HTTP/2的内容实在是太多了，为了方便学习，我砍掉了一些特性，比如流的优先级、依赖关系、流量控制等。
+
+但只要你掌握了今天的这些内容，以后再看RFC文档都不会有难度了。
+
+1. HTTP/2必须先发送一个“连接前言”字符串，然后才能建立正式连接；
+1. HTTP/2废除了起始行，统一使用头字段，在两端维护字段“Key-Value”的索引表，使用“HPACK”算法压缩头部；
+1. HTTP/2把报文切分为多种类型的二进制帧，报头里最重要的字段是流标识符，标记帧属于哪个流；
+1. 流是HTTP/2虚拟的概念，是帧的双向传输序列，相当于HTTP/1里的一次“请求-应答”；
+1. 在一个HTTP/2连接上可以并发多个流，也就是多个“请求-响应”报文，这就是“多路复用”。
+
+## 课下作业
+
+1. HTTP/2的动态表维护、流状态转换很复杂，你认为HTTP/2还是“无状态”的吗？
+1. HTTP/2的帧最大可以达到16M，你觉得大帧好还是小帧好？
+1. 结合这两讲，谈谈HTTP/2是如何解决“队头阻塞”问题的。
+
+欢迎你把自己的学习体会写在留言区，与我和其他同学一起讨论。如果你觉得有所收获，也欢迎把文章分享给你的朋友。
+
+<img src="https://static001.geekbang.org/resource/image/3d/49/3dfab162c427fb3a1fa16494456ae449.png" alt="unpreview">
+
+

极客时间专栏/透视HTTP协议/飞翔篇/32 | 未来之路：HTTP|3展望.md

@@ -0,0 +1,140 @@
+<audio id="audio" title="32 | 未来之路：HTTP/3展望" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/3e/4d/3e41a53d39f155573182179cc6c8634d.mp3"></audio>
+
+在前面的两讲里，我们一起学习了HTTP/2，你也应该看到了HTTP/2做出的许多努力，比如头部压缩、二进制分帧、虚拟的“流”与多路复用，性能方面比HTTP/1有了很大的提升，“基本上”解决了“队头阻塞”这个“老大难”问题。
+
+## HTTP/2的“队头阻塞”
+
+等等，你可能要发出疑问了：为什么说是“基本上”，而不是“完全”解决了呢？
+
+这是因为HTTP/2虽然使用“帧”“流”“多路复用”，没有了“队头阻塞”，但这些手段都是在应用层里，而在下层，也就是TCP协议里，还是会发生“队头阻塞”。
+
+这是怎么回事呢？
+
+让我们从协议栈的角度来仔细看一下。在HTTP/2把多个“请求-响应”分解成流，交给TCP后，TCP会再拆成更小的包依次发送（其实在TCP里应该叫segment，也就是“段”）。
+
+在网络良好的情况下，包可以很快送达目的地。但如果网络质量比较差，像手机上网的时候，就有可能会丢包。而TCP为了保证可靠传输，有个特别的“丢包重传”机制，丢失的包必须要等待重新传输确认，其他的包即使已经收到了，也只能放在缓冲区里，上层的应用拿不出来，只能“干着急”。
+
+我举个简单的例子：
+
+客户端用TCP发送了三个包，但服务器所在的操作系统只收到了后两个包，第一个包丢了。那么内核里的TCP协议栈就只能把已经收到的包暂存起来，“停下”等着客户端重传那个丢失的包，这样就又出现了“队头阻塞”。
+
+由于这种“队头阻塞”是TCP协议固有的，所以HTTP/2即使设计出再多的“花样”也无法解决。
+
+Google在推SPDY的时候就已经意识到了这个问题，于是就又发明了一个新的“QUIC”协议，让HTTP跑在QUIC上而不是TCP上。
+
+而这个“HTTP over QUIC”就是HTTP协议的下一个大版本，**HTTP/3**。它在HTTP/2的基础上又实现了质的飞跃，真正“完美”地解决了“队头阻塞”问题。
+
+不过HTTP/3目前还处于草案阶段，正式发布前可能会有变动，所以今天我尽量不谈那些不稳定的细节。
+
+这里先贴一下HTTP/3的协议栈图，让你对它有个大概的了解。
+
+<img src="https://static001.geekbang.org/resource/image/d2/03/d263202e431c84db0fd6c7e6b1980f03.png" alt="">
+
+## QUIC协议
+
+从这张图里，你可以看到HTTP/3有一个关键的改变，那就是它把下层的TCP“抽掉”了，换成了UDP。因为UDP是无序的，包之间没有依赖关系，所以就从根本上解决了“队头阻塞”。
+
+你一定知道，UDP是一个简单、不可靠的传输协议，只是对IP协议的一层很薄的包装，和TCP相比，它实际应用的较少。
+
+不过正是因为它简单，不需要建连和断连，通信成本低，也就非常灵活、高效，“可塑性”很强。
+
+所以，QUIC就选定了UDP，在它之上把TCP的那一套连接管理、拥塞窗口、流量控制等“搬”了过来，“去其糟粕，取其精华”，打造出了一个全新的可靠传输协议，可以认为是“**新时代的TCP**”。
+
+<img src="https://static001.geekbang.org/resource/image/fd/7a/fd99221ede55272a998760cc6aaa037a.png" alt="unpreview">
+
+QUIC最早是由Google发明的，被称为gQUIC。而当前正在由IETF标准化的QUIC被称为iQUIC。两者的差异非常大，甚至比当年的SPDY与HTTP/2的差异还要大。
+
+gQUIC混合了UDP、TLS、HTTP，是一个应用层的协议。而IETF则对gQUIC做了“清理”，把应用部分分离出来，形成了HTTP/3，原来的UDP部分“下放”到了传输层，所以iQUIC有时候也叫“QUIC-transport”。
+
+接下来要说的QUIC都是指iQUIC，要记住，它与早期的gQUIC不同，是一个传输层的协议，和TCP是平级的。
+
+## QUIC的特点
+
+QUIC基于UDP，而UDP是“无连接”的，根本就不需要“握手”和“挥手”，所以天生就要比TCP快。
+
+就像TCP在IP的基础上实现了可靠传输一样，QUIC也基于UDP实现了可靠传输，保证数据一定能够抵达目的地。它还引入了类似HTTP/2的“流”和“多路复用”，单个“流”是有序的，可能会因为丢包而阻塞，但其他“流”不会受到影响。
+
+为了防止网络上的中间设备（Middle Box）识别协议的细节，QUIC全面采用加密通信，可以很好地抵御窜改和“协议僵化”（ossification）。
+
+而且，因为TLS1.3已经在去年（2018）正式发布，所以QUIC就直接应用了TLS1.3，顺便也就获得了0-RTT、1-RTT连接的好处。
+
+但QUIC并不是建立在TLS之上，而是内部“包含”了TLS。它使用自己的帧“接管”了TLS里的“记录”，握手消息、警报消息都不使用TLS记录，直接封装成QUIC的帧发送，省掉了一次开销。
+
+## QUIC内部细节
+
+由于QUIC在协议栈里比较偏底层，所以我只简略介绍两个内部的关键知识点。
+
+QUIC的基本数据传输单位是**包**（packet）和**帧**（frame），一个包由多个帧组成，包面向的是“连接”，帧面向的是“流”。
+
+QUIC使用不透明的“**连接ID**”来标记通信的两个端点，客户端和服务器可以自行选择一组ID来标记自己，这样就解除了TCP里连接对“IP地址+端口”（即常说的四元组）的强绑定，支持“**连接迁移**”（Connection Migration）。
+
+<img src="https://static001.geekbang.org/resource/image/ae/3b/ae0c482ea0c3b8ebc71924b19feb9b3b.png" alt="">
+
+比如你下班回家，手机会自动由4G切换到WiFi。这时IP地址会发生变化，TCP就必须重新建立连接。而QUIC连接里的两端连接ID不会变，所以连接在“逻辑上”没有中断，它就可以在新的IP地址上继续使用之前的连接，消除重连的成本，实现连接的无缝迁移。
+
+QUIC的帧里有多种类型，PING、ACK等帧用于管理连接，而STREAM帧专门用来实现流。
+
+QUIC里的流与HTTP/2的流非常相似，也是帧的序列，你可以对比着来理解。但HTTP/2里的流都是双向的，而QUIC则分为双向流和单向流。
+
+<img src="https://static001.geekbang.org/resource/image/9a/10/9ab3858bf918dffafa275c400d78d910.png" alt="">
+
+QUIC帧普遍采用变长编码，最少只要1个字节，最多有8个字节。流ID的最大可用位数是62，数量上比HTTP/2的2^31大大增加。
+
+流ID还保留了最低两位用作标志，第1位标记流的发起者，0表示客户端，1表示服务器；第2位标记流的方向，0表示双向流，1表示单向流。
+
+所以QUIC流ID的奇偶性质和HTTP/2刚好相反，客户端的ID是偶数，从0开始计数。
+
+## HTTP/3协议
+
+了解了QUIC之后，再来看HTTP/3就容易多了。
+
+因为QUIC本身就已经支持了加密、流和多路复用，所以HTTP/3的工作减轻了很多，把流控制都交给QUIC去做。调用的不再是TLS的安全接口，也不是Socket API，而是专门的QUIC函数。不过这个“QUIC函数”还没有形成标准，必须要绑定到某一个具体的实现库。
+
+HTTP/3里仍然使用流来发送“请求-响应”，但它自身不需要像HTTP/2那样再去定义流，而是直接使用QUIC的流，相当于做了一个“概念映射”。
+
+HTTP/3里的“双向流”可以完全对应到HTTP/2的流，而“单向流”在HTTP/3里用来实现控制和推送，近似地对应HTTP/2的0号流。
+
+由于流管理被“下放”到了QUIC，所以HTTP/3里帧的结构也变简单了。
+
+帧头只有两个字段：类型和长度，而且同样都采用变长编码，最小只需要两个字节。
+
+<img src="https://static001.geekbang.org/resource/image/26/5b/2606cbaa1a2e606a3640cc1825f5605b.png" alt="">
+
+HTTP/3里的帧仍然分成数据帧和控制帧两类，HEADERS帧和DATA帧传输数据，但其他一些帧因为在下层的QUIC里有了替代，所以在HTTP/3里就都消失了，比如RST_STREAM、WINDOW_UPDATE、PING等。
+
+头部压缩算法在HTTP/3里升级成了“**QPACK**”，使用方式上也做了改变。虽然也分成静态表和动态表，但在流上发送HEADERS帧时不能更新字段，只能引用，索引表的更新需要在专门的单向流上发送指令来管理，解决了HPACK的“队头阻塞”问题。
+
+另外，QPACK的字典也做了优化，静态表由之前的61个增加到了98个，而且序号从0开始，也就是说“:authority”的编号是0。
+
+## HTTP/3服务发现
+
+讲了这么多，不知道你注意到了没有：HTTP/3没有指定默认的端口号，也就是说不一定非要在UDP的80或者443上提供HTTP/3服务。
+
+那么，该怎么“发现”HTTP/3呢？
+
+这就要用到HTTP/2里的“扩展帧”了。浏览器需要先用HTTP/2协议连接服务器，然后服务器可以在启动HTTP/2连接后发送一个“**Alt-Svc**”帧，包含一个“h3=host:port”的字符串，告诉浏览器在另一个端点上提供等价的HTTP/3服务。
+
+浏览器收到“Alt-Svc”帧，会使用QUIC异步连接指定的端口，如果连接成功，就会断开HTTP/2连接，改用新的HTTP/3收发数据。
+
+## 小结
+
+HTTP/3综合了我们之前讲的所有技术（HTTP/1、SSL/TLS、HTTP/2），包含知识点很多，比如队头阻塞、0-RTT握手、虚拟的“流”、多路复用，算得上是“集大成之作”，需要多下些功夫好好体会。
+
+1. HTTP/3基于QUIC协议，完全解决了“队头阻塞”问题，弱网环境下的表现会优于HTTP/2；
+1. QUIC是一个新的传输层协议，建立在UDP之上，实现了可靠传输；
+1. QUIC内含了TLS1.3，只能加密通信，支持0-RTT快速建连；
+1. QUIC的连接使用“不透明”的连接ID，不绑定在“IP地址+端口”上，支持“连接迁移”；
+1. QUIC的流与HTTP/2的流很相似，但分为双向流和单向流；
+1. HTTP/3没有指定默认端口号，需要用HTTP/2的扩展帧“Alt-Svc”来发现。
+
+## 课下作业
+
+1. IP协议要比UDP协议省去8个字节的成本，也更通用，QUIC为什么不构建在IP协议之上呢？
+1. 说一说你理解的QUIC、HTTP/3的好处。
+1. 对比一下HTTP/3和HTTP/2各自的流、帧，有什么相同点和不同点。
+
+欢迎你把自己的学习体会写在留言区，与我和其他同学一起讨论。如果你觉得有所收获，也欢迎把文章分享给你的朋友。
+
+<img src="https://static001.geekbang.org/resource/image/58/df/5857f14a3b06b6c0dd38e00b4a6124df.png" alt="unpreview">
+
+

极客时间专栏/透视HTTP协议/飞翔篇/33 | 我应该迁移到HTTP|2吗？.md

@@ -0,0 +1,151 @@
+<audio id="audio" title="33 | 我应该迁移到HTTP/2吗？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/41/28/413e8241fbe9202ebe252b2b3dd0ad28.mp3"></audio>
+
+这一讲是“飞翔篇”的最后一讲，而HTTP的所有知识也差不多快学完了。
+
+前面你已经看到了新的HTTP/2和HTTP/3协议，了解了它们的特点和工作原理，如果再联系上前几天“安全篇”的HTTPS，你可能又会发出疑问：
+
+“刚费了好大的力气升级到HTTPS，这又出了一个HTTP/2，还有再次升级的必要吗？”
+
+与各大浏览器“强推”HTTPS的待遇不一样，HTTP/2的公布可谓是“波澜不惊”。虽然它是HTTP协议的一个重大升级，但Apple、Google等科技巨头并没有像HTTPS那样给予大量资源的支持。
+
+直到今天，HTTP/2在互联网上还是处于“不温不火”的状态，虽然已经有了不少的网站改造升级到了HTTP/2，但普及的速度远不及HTTPS。
+
+所以，你有这样的疑问也是很自然的，升级到HTTP/2究竟能给我们带来多少好处呢？到底“值不值”呢？
+
+## HTTP/2的优点
+
+前面的几讲主要关注了HTTP/2的内部实现，今天我们就来看看它有哪些优点和缺点。
+
+首先要说的是，HTTP/2最大的一个优点是**完全保持了与HTTP/1的兼容**，在语义上没有任何变化，之前在HTTP上的所有投入都不会浪费。
+
+因为兼容HTTP/1，所以HTTP/2也具有HTTP/1的所有优点，并且“基本”解决了HTTP/1的所有缺点，安全与性能兼顾，可以认为是“更安全的HTTP、更快的HTTPS”。
+
+在安全上，HTTP/2对HTTPS在各方面都做了强化。下层的TLS至少是1.2，而且只能使用前向安全的密码套件（即ECDHE），这同时也就默认实现了“TLS False Start”，支持1-RTT握手，所以不需要再加额外的配置就可以自动实现HTTPS加速。
+
+安全有了保障，再来看HTTP/2在性能方面的改进。
+
+你应该知道，影响网络速度的两个关键因素是“**带宽**”和“**延迟**”，HTTP/2的头部压缩、多路复用、流优先级、服务器推送等手段其实都是针对这两个要点。
+
+所谓的“带宽”就是网络的传输速度。从最早的56K/s，到如今的100M/s，虽然网速已经是“今非昔比”，比从前快了几十倍、几百倍，但仍然是“稀缺资源”，图片、视频这样的多媒体数据很容易会把带宽用尽。
+
+节约带宽的基本手段就是压缩，在HTTP/1里只能压缩body，而HTTP/2则可以用HPACK算法压缩header，这对高流量的网站非常有价值，有数据表明能节省大概5%~10%的流量，这是实实在在的“真金白银”。
+
+与HTTP/1“并发多个连接”不同，HTTP/2的“多路复用”特性要求对**一个域名（或者IP）只用一个TCP连接**，所有的数据都在这一个连接上传输，这样不仅节约了客户端、服务器和网络的资源，还可以把带宽跑满，让TCP充分“吃饱”。
+
+这是为什么呢？
+
+我们来看一下在HTTP/1里的长连接，虽然是双向通信，但任意一个时间点实际上还是单向的：上行请求时下行空闲，下行响应时上行空闲，再加上“队头阻塞”，实际的带宽打了个“对折”还不止（可参考[第17讲](https://time.geekbang.org/column/article/104949)）。
+
+而在HTTP/2里，“多路复用”则让TCP开足了马力，“全速狂奔”，多个请求响应并发，每时每刻上下行方向上都有流在传输数据，没有空闲的时候，带宽的利用率能够接近100%。所以，HTTP/2只使用一个连接，就能抵得过HTTP/1里的五六个连接。
+
+不过流也可能会有依赖关系，可能会存在等待导致的阻塞，这就是“延迟”，所以HTTP/2的其他特性就派上了用场。
+
+“优先级”可以让客户端告诉服务器，哪个文件更重要，更需要优先传输，服务器就可以调高流的优先级，合理地分配有限的带宽资源，让高优先级的HTML、图片更快地到达客户端，尽早加载显示。
+
+“服务器推送”也是降低延迟的有效手段，它不需要客户端预先请求，服务器直接就发给客户端，这就省去了客户端解析HTML再请求的时间。
+
+## HTTP/2的缺点
+
+说了一大堆HTTP/2的优点，再来看看它有什么缺点吧。
+
+听过上一讲HTTP/3的介绍，你就知道HTTP/2在TCP级别还是存在“队头阻塞”的问题。所以，如果网络连接质量差，发生丢包，那么TCP会等待重传，传输速度就会降低。
+
+另外，在移动网络中发生IP地址切换的时候，下层的TCP必须重新建连，要再次“握手”，经历“慢启动”，而且之前连接里积累的HPACK字典也都消失了，必须重头开始计算，导致带宽浪费和时延。
+
+刚才也说了，HTTP/2对一个域名只开一个连接，所以一旦这个连接出问题，那么整个网站的体验也就变差了。
+
+而这些情况下HTTP/1反而不会受到影响，因为它“本来就慢”，而且还会对一个域名开6~8个连接，顶多其中的一两个连接会“更慢”，其他的连接不会受到影响。
+
+## 应该迁移到HTTP/2吗？
+
+说到这里，你对迁移到HTTP/2是否已经有了自己的判断呢？
+
+在我看来，HTTP/2处于一个略“尴尬”的位置，前面有“老前辈”HTTP/1，后面有“新来者”HTTP/3，即有“老前辈”的“打压”，又有“新来者”的“追赶”，也就难怪没有获得市场的大力“吹捧”了。
+
+但这绝不是说HTTP/2“一无是处”，实际上HTTP/2的性能改进效果是非常明显的，Top 1000的网站中已经有超过40%运行在了HTTP/2上，包括知名的Apple、Facebook、Google、Twitter等等。仅用了四年的时间，HTTP/2就拥有了这么大的市场份额和巨头的认可，足以证明它的价值。
+
+因为HTTP/2的侧重点是“性能”，所以“是否迁移”就需要在这方面进行评估。如果网站的流量很大，那么HTTP/2就可以带来可观的收益；反之，如果网站流量比较小，那么升级到HTTP/2就没有太多必要了，只要利用现有的HTTP再优化就足矣。
+
+不过如果你是新建网站，我觉得完全可以跳过HTTP/1、HTTPS，直接“一步到位”，上HTTP/2，这样不仅可以获得性能提升，还免去了老旧的“历史包袱”，日后也不会再有迁移的烦恼。
+
+顺便再多嘴一句，HTTP/2毕竟是“下一代”HTTP协议，它的很多特性也延续到了HTTP/3，提早升级到HTTP/2还可以让你在HTTP/3到来时有更多的技术积累和储备，不至于落后于时代。
+
+## 配置HTTP/2
+
+假设你已经决定要使用HTTP/2，应该如何搭建服务呢？
+
+因为HTTP/2“事实上”是加密的，所以如果你已经在“安全篇”里成功迁移到了HTTPS，那么在Nginx里启用HTTP/2简直可以说是“不费吹灰之力”，只需要在server配置里再多加一个参数就可以搞定了。
+
+```
+server {
+    listen       443 ssl http2;
+
+
+    server_name  www.xxx.net;
+
+
+    ssl_certificate         xxx.crt;
+    ssl_certificate_key     xxx.key;
+
+```
+
+注意“listen”指令，在“ssl”后面多了一个“http2”，这就表示在443端口上开启了SSL加密，然后再启用HTTP/2。
+
+配置服务器推送特性可以使用指令“http2_push”和“http2_push_preload”：
+
+```
+http2_push         /style/xxx.css;
+http2_push_preload on;
+
+```
+
+不过如何合理地配置推送是个难题，如果推送给浏览器不需要的资源，反而浪费了带宽。
+
+这方面暂时没有一般性的原则指导，你必须根据自己网站的实际情况去“猜测”客户端最需要的数据。
+
+优化方面，HTTPS的一些策略依然适用，比如精简密码套件、ECC证书、会话复用、HSTS减少重定向跳转等等。
+
+但还有一些优化手段在HTTP/2里是不适用的，而且还会有反效果，比如说常见的精灵图（Spriting）、资源内联（inlining）、域名分片（Sharding）等，至于原因是什么，我把它留给你自己去思考（提示，与缓存有关）。
+
+还要注意一点，HTTP/2默认启用header压缩（HPACK），但并没有默认启用body压缩，所以不要忘了在Nginx配置文件里加上“gzip”指令，压缩HTML、JS等文本数据。
+
+## 应用层协议协商（ALPN）
+
+最后说一下HTTP/2的“服务发现”吧。
+
+你有没有想过，在URI里用的都是HTTPS协议名，没有版本标记，浏览器怎么知道服务器支持HTTP/2呢？为什么上来就能用HTTP/2，而不是用HTTP/1通信呢？
+
+答案在TLS的扩展里，有一个叫“**ALPN**”（Application Layer Protocol Negotiation）的东西，用来与服务器就TLS上跑的应用协议进行“协商”。
+
+客户端在发起“Client Hello”握手的时候，后面会带上一个“ALPN”扩展，里面按照优先顺序列出客户端支持的应用协议。
+
+就像下图这样，最优先的是“h2”，其次是“http/1.1”，以前还有“spdy”，以后还可能会有“h3”。
+
+<img src="https://static001.geekbang.org/resource/image/d8/b0/d8f8606948bbd63c31466e464c1956b0.png" alt="">
+
+服务器看到ALPN扩展以后就可以从列表里选择一种应用协议，在“Server Hello”里也带上“ALPN”扩展，告诉客户端服务器决定使用的是哪一种。因为我们在Nginx配置里使用了HTTP/2协议，所以在这里它选择的就是“h2”。
+
+<img src="https://static001.geekbang.org/resource/image/19/a7/19be1138574589458c96040e1a23b3a7.png" alt="">
+
+这样在TLS握手结束后，客户端和服务器就通过“ALPN”完成了应用层的协议协商，后面就可以使用HTTP/2通信了。
+
+## 小结
+
+今天我们讨论了是否应该迁移到HTTP/2，还有应该如何迁移到HTTP/2。
+
+1. HTTP/2完全兼容HTTP/1，是“更安全的HTTP、更快的HTTPS”，头部压缩、多路复用等技术可以充分利用带宽，降低延迟，从而大幅度提高上网体验；
+1. TCP协议存在“队头阻塞”，所以HTTP/2在弱网或者移动网络下的性能表现会不如HTTP/1；
+1. 迁移到HTTP/2肯定会有性能提升，但高流量网站效果会更显著；
+1. 如果已经升级到了HTTPS，那么再升级到HTTP/2会很简单；
+1. TLS协议提供“ALPN”扩展，让客户端和服务器协商使用的应用层协议，“发现”HTTP/2服务。
+
+## 课下作业
+
+1. 和“安全篇”的第29讲类似，结合自己的实际情况，分析一下是否应该迁移到HTTP/2，有没有难点？
+1. 精灵图（Spriting）、资源内联（inlining）、域名分片（Sharding）这些手段为什么会对HTTP/2的性能优化造成反效果呢？
+
+欢迎你把自己的学习体会写在留言区，与我和其他同学一起讨论。如果你觉得有所收获，也欢迎把文章分享给你的朋友。
+
+<img src="https://static001.geekbang.org/resource/image/fb/55/fb986a7575ec902c86c17a937dbca655.png" alt="unpreview">
+
+