本文共 1831 字，大约阅读时间需要 6 分钟。
从HTTP历史来看HTTP协议的问题
- HTTP1.0
1个请求1个TCP连接，如果要请求一个网站有大量内容，就会建立大量的到服务器的连接，导致过多的延迟和资源消耗。
- HTTP1.1
为了解决1.0的问题引入了默认带流水线的持久连接支持连接的复用，实现在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。一个包含有许多图像的网页文件的多个请求和应答可以在一个连接中传输，但每个单独的网页文件的请求和应答仍然需要使用各自的连接。
HTTP 1.1还允许客户端不用等待上一次请求结果返回，就可以发出下一次请求，但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果，以保证客户端能够区分出每次请求的响应内容，这样也显著地减少了整个下载过程所需要的时间。
同时浏览器本身也限制了HTTP请求的并发程度，比如Chrome就限制同一域名只能6个并发连接，这样也就限制了HTTP1.1处理效率。
Head-of-line blocking问题，就是当服务器发送的上一个请求的包丢失时，后续的请求必须等待服务器重发成功后才能恢复正常发送
HTTP/2对问题的解决
- 多路复用和Streams
多路复用保证每个http request/response交互关联自己的流，流之间完全独立；一个Stream的阻塞不会阻塞其他的Stream
HTTP/2新增的特色
- 二进制消息
HTTP/2 采用二进制格式传输数据，而非 HTTP/1.x 的文本格式。二进制格式可以进行优化和压缩使传输更快。
- 消息头压缩
能够节省消息头占用的网络的流量。而 HTTP/1.x 每次请求，都会携带大量冗余头信息，浪费了很多带宽资源。头压缩能够很好的解决该问题
- Flow controller
- Prioritization
- Server push
HTTP/2连接过程
HTTP/2的连接有三种情况
- Client发起upgrade header http请求
针对非安全加密HTTP请求，发起带upgrade: h2c 头的请求。
- Client发起upgrade header https请求
针对安全加密https请求，发起带 upgrade:h2 头请求
- Client直接发起Connection Preface请求
针对客户端已知服务端支持HTTP/2协议，所以不用协商直接发起HTTP/2请求。
直接发起Connection Preface，此为 PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n 开头的一串字符串，总共24字节，后面跟上Settings Frame
下面以http请求流程为例
- 客户端发起请求，只有请求报头：
GET / HTTP/1. 1Host: server.example.comConnection: Upgrade, HTTP2-SettingsUpgrade: h2cHTTP2-Settings:
- 服务器若不支持HTTP/2，直接按照HTTP/1.1响应即可
HTTP/1.1 200 OKContent-Length: 11Content-Type: text/html
-
服务器支持HTTP/2，通知客户端一起切换到HTTP/2协议下吧
HTTP/1.1 101 Switching ProtocolsConnection: UpgradeUpgrade: h2c[ HTTP/2 connection . . .
- 101响应空行之后，服务器必须发送的第一个帧为SETTINGS帧（其负载可能为空）作为连接序言
- 客户端接收到101响应后，也必须发送一个序言作为响应，其逻辑结构：
PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n // 纯字符串表示，翻译成字节数为24个字节SETTINGS帧 // 其负载可能为空
服务器端和客户端所发送的连接序言有所不同。 - 客户端可以马上发送请求帧或其它帧过去，不用等待来自服务器端的SETTINGS帧
- 任一端接收到SETTINGS帧之后，都需要返回一个包含确认标志位SETTIGN作为确认
- 其它帧的正常传输
HTTPS和HTTP Upgrade方式协商
统一的连接过程
这里不论是HTTP还是HTTPS，在两端成功协商之后（或HTTP的直接连接），其连接过程都是一样的
引用：
视频演示HTTP2的提升
转载地址：http://azrgf.baihongyu.com/