HTTP/2 存在的缺陷：
队头阻塞
HTTP/2 多个请求是跑在一个 TCP 连接中的，那么当 TCP 丢包时，整个 TCP 都要等待重传，那么就会阻塞该 TCP 连接中的所有请求。
因为 TCP 是字节流协议，TCP 层必须保证收到的字节数据是完整且有序的，如果序列号较低的 TCP 段在网络传输 中丢失了，即使序列号较高的 TCP 段已经被接收了，应用层也无法从内核中读取到这部分数据，从 HTTP 视角看，就是请求被阻塞了。
TCP 和 TLS 的 握手时延
- 发起HTTP 请求需要经过 TCP 三次握手和 TLS（1.2） 四次握手的·1过程。共 3 个 RTT 后才能发出请求数据。
- TCP 具有 【拥塞控制】的特性，对于刚建立连接的 TCP 会有个【慢启动】的过程。它会对 TCP 连接产生“减速”效果。
网络迁移需要重新连接
基于 TCP 传输协议的 HTTP 协议，是通过四元组（源 IP、源端⼝、⽬的 IP、⽬的端⼝）确定⼀条 TCP 连接。
当 IP 地址或端口号变动时，需要 TCP 和 TLS 重新握手。
这不利于移动设备切换网络的场景，如 4G 网络环境切换成 WIFI，意味着 IP 地址变化了。
解决办法：
HTTP/3 把 传输层协议替换成 UDP；还基于 UDP 协议在 应用层 实现了 QUIC 协议。
UDP不需要连接，没有握手和挥手过程，所以 自然比 TCP 快。
QUIC 协议具有类似 TCP 的连接管理、拥塞窗口、流量控制的网络特性。相当于将不可靠传输的 UDP 协议变成“可靠”的。
QUIC 协议
优点：
无队头阻塞
QUIC 协议也有 Stream 与 多路复用的概念。
QUIC 连接上的多个 Stream 之间都是独立的。某个流发生了丢包，只会影响该流。
更快地建立连接
HTTP/3 在传输数据前也需要 QUIC 协议握手，但只需 1 RTT。
握手的目的是为确认双方的【连接 ID】。
QUIC 内部包含了 TLS 1.3，它在自己的帧会携带 TLS 里的 “记录”。因此仅需 1 RTT 就可以 同时 完成建立连接与密钥协商。甚至在第二次连接时，应用数据包可以和 QUIC 握手信息（连接信息 + TLS 信息）一起发送，达到 0 RTT 的效果。
连接迁移
QUIC 协议没有用四元组的方式来“绑定”连接。
而是通过【连接 ID】来标记通信的两个端点。即使移动设备的网络变化导致IP地址改变，只要仍保有上下文信息（连接 ID 、TLS 密钥等），就可以“无缝”对接。
HTTP/3 直接使用 QUIC 里的 Stream
HTTP/2 和 HTTP/3 帧格式对比
HTTP/3 的头部压缩算法
QPACK
QPACK
- 与 HTTP/2 中的 HPACK 编码⽅式相似， HTTP/3 中的 QPACK 也采⽤了静态表、动态表及 Huffman 编码。
- 静态表有91项。
- QUIC 有两个特殊的单向流（mean：只有一端可以发送消息）。用来同步双方的动态表。
解决了 HTTP/2 的问题：动态表具有时序性。如果首次出现的请求包丢失了，后续收到的请求则不能根据动态表上的 index 来解码出 HPACK 头部。因为对方还没建立好动态表。因此请求会阻塞直到 首次丢失的那个数据包重传过来。
标签：TLS,协议,HTTP,TCP,介绍,QUIC,连接 来源： https://www.cnblogs.com/tiddler/p/16651122.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。