在第14讲里，我们看到HTTP有两个主要的缺点：安全不足和性能不高。
刚结束的“安全篇”里的HTTPS，通过引入SSL/TLS在安全上达到了“极致”，但在性能提升方面却是乏善可陈，只优化了握手加密的环节，对于整体的数据传输没有提出更好的改进方案，还只能依赖于“长连接”这种“落后”的技术（参见第17讲）。
所以，在HTTPS逐渐成熟之后，HTTP就向着性能方面开始“发力”，走出了另一条进化的道路。
在第1讲的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讲），也是“化整为零”的思路，但HTTP/2数据分帧后“Header+Body”的报文结构就完全消失了，协议看到的只是一个个的“碎片”。
虚拟的“流”
消息的“碎片”到达目的地后应该怎么组装起来呢？
HTTP/2为此定义了一个“流”（Stream）的概念，它是二进制帧的双向传输序列，同一个消息往返的帧会分配一个唯一的流ID。你可以把它想象成是一个虚拟的“数据流”，在里面流动的是一串有先后顺序的数据帧，这些数据帧按照次序组装起来就是HTTP/1里的请求报文和响应报文。
因为“流”是虚拟的，实际上并不存在，所以HTTP/2就可以在一个TCP连接上用“流”同时发送多个“碎片化”的消息，这就是常说的“多路复用”（ Multiplexing）——多个往返通信都复用一个连接来处理。
在“流”的层面上看，消息是一些有序的“帧”序列，而在“连接”的层面上看，消息却是乱序收发的“帧”。多个请求/响应之间没有了顺序关系，不需要排队等待，也就不会再出现“队头阻塞”问题，降低了延迟，大幅度提高了连接的利用率。
为了更好地利用连接，加大吞吐量，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复杂了一些。
虽然HTTP/2的底层实现很复杂，但它的“语义”还是简单的HTTP/1，之前学习的知识不会过时，仍然能够用得上。
我们的实验环境在新的域名“www.metroid.net”上启用了HTTP/2协议，你可以把之前“进阶篇”“安全篇”的测试用例都走一遍，再用Wireshark抓一下包，实际看看HTTP/2的效果和对老协议的兼容性（例如“http://www.metroid.net/11-1”）。
在今天这节课专用的URI“/30-1”里，你还可以看到服务器输出了HTTP的版本号“2”和标识符“h2”，表示这是加密的HTTP/2，如果改用“https://www.chrono.com/30-1”访问就会是“1.1”和空。
你可能还会注意到URI里的一个小变化，端口使用的是“8443”而不是“443”。这是因为443端口已经被“www.chrono.com”的HTTPS协议占用，Nginx不允许在同一个端口上根据域名选择性开启HTTP/2，所以就不得不改用了“8443”。
小结
今天我简略介绍了HTTP/2的一些重要特性，比较偏重理论，下一次我会用Wireshark抓包，具体讲解HTTP/2的头部压缩、二进制帧和流等特性。
- HTTP协议取消了小版本号，所以HTTP/2的正式名字不是2.0；
- HTTP/2在“语义”上兼容HTTP/1，保留了请求方法、URI等传统概念；
- HTTP/2使用“HPACK”算法压缩头部信息，消除冗余数据节约带宽；
- HTTP/2的消息不再是“Header+Body”的形式，而是分散为多个二进制“帧”；
- HTTP/2使用虚拟的“流”传输消息，解决了困扰多年的“队头阻塞”问题，同时实现了“多路复用”，提高连接的利用率；
- HTTP/2也增强了安全性，要求至少是TLS1.2，而且禁用了很多不安全的密码套件。
课下作业
- 你觉得明文形式的HTTP/2（h2c）有什么好处，应该如何使用呢？
- 你觉得应该怎样理解HTTP/2里的“流”，为什么它是“虚拟”的？
- 你能对比一下HTTP/2与HTTP/1、HTTPS的相同点和不同点吗？
欢迎你把自己的学习体会写在留言区，与我和其他同学一起讨论。如果你觉得有所收获，也欢迎把文章分享给你的朋友。
精选留言
2020-01-19 10:46:04
2.客户端将多个请求分成不同的流，然后每个流里面在切成一个个帧，发送的时候是按帧发送的。每个帧存着一个流ID来表示它属于的流。服务端收到请求的时候将帧按流ID进行拼接。从传输的角度来看流是不存在的，只是看到了一个个帧，所以说流是虚拟的。
3.相同点：都是基于TCP和TLS的，url格式都是相同的。都是基于header+body的形式。都是请求-应答模型。
4.不同点： 1.使用了HPACK进行头部压缩。
2.使用的是二进制的方式进行传输。
3.将多个请求切分成帧发送，实现了多路复用。这个感觉上利用了多道程序设计的思想。
4.服务器可以主动向客户端推送消息。充分利用了TCP的全功双通道。
2019-08-05 12:24:40
h2的流是虚拟的因为它是使用帧传输数据的，相同streamid的帧组成了虚拟消息以及流；
相同点：都是基于tcp或TLS，并且是基于请求-响应模型，schema还是http或https不会有http2。
不同点：h2使用二进制传输消息并且通过HPACK压缩请求头，实现流多路复用、服务器推送
2019-08-05 15:12:12
2019-08-05 12:43:09
2019-12-09 20:37:06
2020-06-26 12:54:07
2.http2改变了http1.1的“请求-应答”模式，将head+body的请求报文在传输过程中改为 head帧 + data帧，在同一个TCP/IP中，可以将多个请求分解为多个帧，从连接层面来看，这些帧是无序的，为了让接受端准确的将这些帧还原为一个一个独立的请求或响应，就给了每一个帧分配了streamid，streamid相同的即为同一个请求或响应的数据。因此，此处的流并不是真实有序的二进制字节，所以叫‘虚拟流’。
3.http1.1解决的是在万维网中，计算机之间的信息通信的一套规范，包括定义其属于应用层协议，建立在tcp/ip之上，请求响应的报文结构等。https不改变http1.1的原有属性，是在其之上新增了对数据安全性和有效性的特性，解决的是数据安全的问题，通过使用加密解密，数字证书，TLS握手等过程保证了这一点。http2解决的是性能问题，通过头部压缩，使用二进制传输，多路复用，服务器推送等策略使得http的性能更好。http2和https本质上都是对http1.1的扩展和延伸。
2019-08-05 21:54:54
1.内网用h2c会比https快么?
2.感觉回答虚拟流之前给先回答啥是真真的流。我对流的理解是有序，切只能读一次。http2支持乱序发，我猜也支持，部分帧重发，所以就是虚拟的了。
3.共同，都是应用层协议，传输成都用的TCP。
不同:https=TLS+HTTP/HTTP2，安全。
http2:二进制传输，对header压缩，通过二进制分帧解决了队头阻塞，传输效率更高，服务端可推数据
http:明文，队头阻塞，半双工。
问题1:一个TCP链接可以打开很多channel是吧，每一个channel都可以传输数据。底层具体怎么实现的啊，是怎么区分channel里的数据谁是谁的?
问题2:我之前看见TPC好像是通过服务端IP,服务端端口号,客户端端IP,客户端端口号。来唯一标识一个链接的。http1的时候队头阻塞，继续要多建http链接。每建立一个链接客户端就用一个不同的端口号么?
2019-08-29 08:21:23
2020-11-30 13:38:10
2、流和请求/应答一样，但是流是相同流id的帧组合，不同流可以无序，相同流有序。整个看起来是无序的，请求之间不受影响。这也解决了http1.1的队头阻塞。
3、三者都是基于tcp的，基本语义是一样的。http2在性能上做了提升，比如二进制帧，流，服务器推送，HPACK算法等；https在安全上做了提升，下层多了TLS/SSL，要多做一些握手加密证书验证等操作。
2020-05-18 20:59:26
1.兼容性
兼容以前的http1.1 ，https等。
2.性能提升
报文变成了 二进制数据帧，提高传输效率，和减少歧义。
①header 采用了头部压缩，来减小传输体积。
②body数据 放到了 data帧。
a.同一请求或响应的数据帧具有相同的帧标识(流ID)，两端接受到的帧数据可以通过同一帧标识，重新组装成请求或响应数据。
b.不同请求/响应的数据帧可以乱序发，避免生成请求队列造成的队头阻塞。
c.同一个TCP连接上，可以并行发送多种流的数据帧(多路复用，PS： http1的 多路复用是分母效应，同一连接串行增加http通信 )。
d.强化了请求响应模式，服务器可以主动发送信息-服务器推送。
3.安全性
①.要求下层必须是 TlS1.2以上，支持前向安全，废除安全性比较低的密码套件。
2021-07-29 11:12:30
在HTTP/1.1中，请求方的字符串在TCP层被解码为Unicode二进制，然后应答方在HTTP层编码为utf-8字符串。
而在HTTP/2中，请求方的字符串在HTTP层被解码为二进制，然后应答方在浏览器处编码为字符串。所以好像没有省去时间或者资源。请老师赐教
2020-11-20 19:57:54
2019-09-09 09:41:30
2021-07-16 09:12:30
2022-06-24 12:02:03
2020-09-07 19:23:27
2020-05-12 10:07:28
2023-02-13 17:29:16
是怎么一步步在全世界范围内被广泛应用的？协议颁发出来，是会有一些大头企业领头去实现基于HTTP/2的协议吗？
2023-01-10 14:49:19
1.同一个TCP连接中，多个流是怎么并发请求的？再怎么并发，不都是需要这个TCP连接去一个个数据包进行传输吗？那为什么还需要有多个流？
2.多个TCP连接，每个连接都能单独去发送数据包，这种形式不是更快吗？
本来我以为我了解这章了，现在重新复习的时候，有些点还是不太了解
2021-09-09 15:50:49