推荐阅读：https://www.cnblogs.com/zwtblog/tag/计算机网络/
计算机网络-相关文章可以移步：https://www.cnblogs.com/zwtblog/tag/计算机网络/
HyperText Transfer Protocol -- 超文本传输协议
状态码分类：
完整详情见：https://www.cnblogs.com/zwtblog/p/16077173.html
| 分类 | 分类描述 |
|---|---|
| 1** | 信息，服务器收到请求，需要请求者继续执行操作 |
| 2** | 成功，操作被成功接收并处理 |
| 3** | 重定向，需要进一步的操作以完成请求 |
| 4** | 客户端错误，请求包含语法错误或无法完成请求 |
| 5** | 服务器错误，服务器在处理请求的过程中发生了错误 |
各个版本示意图：
HTTP/1.1 相? HTTP/1.0 性能上的改进：
但 HTTP/1.1 还是有性能瓶颈：
缓存
服务器在发送 HTTP 响应时，有过期的时间，并把这个信息放到响应头部中，这样客户端在查看响应头部的信息时，?旦发现缓存的响应是过期的，则就会重新发送?络请求。
如果数据并未变更，也可以对比摘要。
减少重定向
合理使用代理服务器
合并请求
例如合并图片
延迟发送请求
例如 在博客园访问我的博客的时候，页面时一次性加载出来的，是否可以优化成?户向下滑动??的时候，再向服务器获取接下来的资源，这样就达到了延迟发送请求的效果。
最?性能问题就是 HTTP/1.1 的?延迟，主要原因如下?个：
HTTP/2 只在应?层做了改变，还是基于 TCP 协议传输，应?层??为了保持功能上的兼容，HTTP/2 把 HTTP 分
解成了「语义」和「语法」两个部分，「语义」层不做改动，与 HTTP/1.1 完全?致，?如请求?法、状态码、头
字段等规则保留不变。
但是，HTTP/2 在「语法」层?做了很多改造，基本改变了 HTTP 报?的传输格式。
HTTP/1.1 报?中 Header 部分存在的问题：含很多固定的字段，?如Cookie、User Agent、Accept 等，?量的请求和响应的报??有很多字段值都是重复的。字段是 ASCII 编码的。
HTTP/2 对 Header 部分做了?改造，把以上的问题都解决了。
HTTP/2 没使?常?的 gzip 压缩?式来压缩头部，?是开发了 HPACK 算法，HPACK 算法主要包含：
客户端和服务器两端都会建?和维护「字典」，??度较?的索引号表示重复的字符串，再? Huffman 编码压缩数据，可达到 50%~90% 的?压缩率。
Web 服务器都会提供类似 http2_max_requests 的配置，?于限制?个连接上能够传输的请求数量，
避免动态表?限增?，请求数量到达上限后，就会关闭 HTTP/2 连接来释放内存。
HTTP/2 将 HTTP/1 的?本格式改成?进制格式传输数据，使?位运算能?效解析。
HTTP/2 把响应报?划分成了两个帧（Frame）， HEADERS（?部）和 DATA（消息负载） 是帧的类型。
通过 Stream 这个设计，多个 Stream 复??条 TCP 连接，达到并发的效果，解决了HTTP/1.1 队头阻塞的问题，提?了 HTTP 传输的吞吐量。
HTTP 消息可以由多个 Frame 构成，以及 1 个 Frame 可以由多个 TCP 报?构成。
在 HTTP/2 连接上，不同 Stream 的帧是可以乱序发送的（因此可以并发不同的 Stream ），因为每个帧的头部会携带 Stream ID 信息，所以接收端可以通过 Stream ID 有序组装成 HTTP 消息，?同一 Stream 内部的帧必须是严格有序的。
HTTP/2 还可以对每个 Stream 设置不同优先级，帧头中的「标志位」可以设置优先级
客户端发起的请求，必须使?的是奇数号 Stream，服务器主动的推送，使?的是偶数号 Stream。
服务器在推送资源时，会通过 PUSH_PROMISE 帧传输 HTTP 头部，并通过帧中的 Promised Stream ID 字段告知客户端，接下来会在哪个偶数号 Stream 中发送包体。
HTTP/2 协议是基于 TCP 实现的，于是存在的缺陷有三个。
由下图可知：此次升级使用 谷歌制定的一种基于UDP的低时延的互联网传输层协议， QUIC（Quick UDP Internet Connection） 。再就是帧格式在HTTP/2的基础上做了一些改变。
详情见：https://www.cnblogs.com/zwtblog/p/16081957.html
肝不动了，见谅。下次更新，更新了加链接。
