学习日期：2024.6.29
内容摘要：基于HTTP的功能追加协议和HTTP/2.0
HTTP的瓶颈与各功能追加协议
需求的产生
在Facebook、推特、微博等平台，每分每秒都会有人更新内容，我们作为用户当然希望时刻都能收到最新的消息，为了尽可能实时的显示最新的内容，服务器上一有消息更新，就需要同步到客户端上。这看起来不是狠复杂，但HTTP并不能很好的完成这一任务。
因为HTTP有以下标准，导致其难以满足我们的需求：
①一条连接上只能发送一个请求。
②请求只能从客户端开始，客户端不能接受除响应以外的任何指令。
③请求/响应首部未经压缩就会发送，首部信息发送越多延迟越大。
Ajax的解决方法
Ajax（Asynchronous Javascript and XML，异步Javascript和XML技术，[eɪˈsɪŋkrənəs] adj.异步的；不同时的）
Ajax的核心技术是名为XMLHttpRequest的API，可以达到局部页面替换加载的作用，借由这种手段，可以从已经加载完毕的Web页面上发起请求，然后只更新局部页面，从而减少响应中传输的数据，加快速度。
但使用Ajax实时从服务器获取内容，依然没有解决请求只能从客户端发送的问题，在服务器没有更新时，可能会导致大量徒劳的请求产生。
Comet的解决方法
一旦服务器端有内容更新，Comet方法能立刻向客户端返回响应。这是一种通过延迟应答来模拟服务器端向客户端推送的功能。
Comet方法在收到请求时，不会在处理完成后立刻返回响应，而是先挂起，当服务器端有内容更新时再返回响应，以此达到一种伪主动发送更新的功能。
此方法内容是虽然可以实现实时更新，但是为了保留响应，一次连接的持续时间也变长了，为了维持连接会消耗更多的资源。另外Comet也未能解决HTTP协议本身存在的问题。
SPDY
SPDY没有完全改写HTTP协议，而是在TCP/IP的应用层与传输层之间通过新增SPDY会话层的方式解决问题，同时考虑到安全性问题，SPDY规定通信中采用SSL，以下为示意图
|------|-----|
| HTTP | 应用层 |
| SPDY | 会话层 |
| SSL | 表示层 |
| TCP | 传输层 |
在使用SPDY后，HTTP获得以下功能：
1. 多路复用 请求优化
通过单一的TCP连接，可以无限制处理多个HTTP请求，所有请求的处理都在一条TCP连接上完成，处理的效率得到了提高。同时SPDY可以给各个请求分配优先级顺序，主要是针对在发送多个请求时，针对带宽低导致的响应速度变慢的问题。
2. 支持服务器推送技术
服务器可以主动向客户端发起通信向客户端推送数据，这样服务器在更新时可以主动发送数据，不必等待客户端的请求。
3. SPDY 压缩了 HTTP 头
舍弃掉了不必要的头信息，经过压缩之后可以节省多余数据传输所带来的等待时间和带宽。
4. 强制使用 SSL 传输协议
Google 认为 Web 未来的发展方向必定是安全的网络连接，全部请求 SSL 加密后，信息传输更加安全。
5. 服务器提示功能
服务器可以主动提示客户端所需的资源，由于在客户端发现资源之前就可以得知资源的存在，因此在资源已经缓存的情况下，无需发送不必要的请求。
HTTP/2.0
HTTP/2.0牛逼在哪？
HTTP/2.0是HTTP1.1基础上的改进，利用了SPDY和HTTP Speed+ Friendly等协议，解决并发传输、服务器推送、头部压缩这几个HTTP1.1中的难题
头部压缩
HTTP的报文是由头部和主体部分组成的，HTTP/1.1只能压缩报文主体部分，不能压缩头部。但头部，特别是带有Cookie的头部，大小并不算小，也需要压缩。
HTTP/2 没使用常见的 gzip 压缩方式来压缩头部，而是开发了 HPACK 算法，HPACK 算法主要包含三个组成部分：
- 静态字典；
- 动态字典；
- Huffman 编码（压缩算法）；
客户端和服务器两端都会建立和维护「字典 」，用长度较小的索引号表示重复的字符串，再用 Huffman 编码压缩数据，可达到 50%~90% 的高压缩率。
并发传输
HTTP2引入了Stream ，通过这个设计，多个 Stream 复用一条 TCP 连接，达到并发的效果，解决了 HTTP/1.1 队头阻塞的问题，提高了 HTTP 传输的吞吐量。
为了理解 HTTP/2 的并发是怎样实现的，我们先来理解 HTTP/2 中的 Stream、Message、Frame 这 3 个概念。
你可以从上图中看到：
①1 个 TCP 连接包含一个或者多个 Stream，Stream 是 HTTP/2 并发的关键技术；
②Stream 里可以包含 1 个或多个 Message，Message 对应 HTTP/1 中的请求或响应，由 HTTP 头部和包体构成；
③Message 里包含一条或者多个 Frame，Frame 是 HTTP/2 最小单位，以二进制压缩格式存放 HTTP/1 中的内容（头部和主体）；
因此，我们可以得出结论：多个 Stream 跑在一条 TCP 连接，同一个 HTTP 请求与响应是跑在同一个 Stream 中，HTTP 消息可以由多个 Frame 构成， 一个 Frame 可以由多个 TCP 报文构成。
在 HTTP/2 连接上，不同 Stream 的帧是可以乱序发送的（因此可以并发不同的 Stream ） ，因为每个帧的头部会携带 Stream ID 信息，所以接收端可以通过 Stream ID 有序组装成 HTTP 消息，而同一 Stream 内部的帧必须是严格有序的。
举个例子就是说，TCP连接就像是一个轨道，不同的Stream就是开过去不同颜色的火车，可以是先开红色的火车过去，再开绿色的火车过去（并发发送），但是到站的顺序，每种颜色的车辆一定是按顺序到站的。即（红1，绿1，蓝1，绿2，蓝2，红2...）
服务器推送
客户端和服务器双方都可以建立 Stream，因为服务端可以主动推送资源给客户端， 客户端建立的 Stream 必须是奇数号，而服务器建立的 Stream 必须是偶数号。
比如下图，Stream 1 是客户端向服务端请求的资源，属于客户端建立的 Stream，所以该 Stream 的 ID 是奇数（数字 1）；Stream 2 和 4 都是服务端主动向客户端推送的资源，属于服务端建立的 Stream，所以这两个 Stream 的 ID 是偶数（数字 2 和 4）。
内容总结自人民邮电出版社《图解HTTP》