首页 > 其他分享> 文章详细

Dissect HTTP3

2022-02-07 12:03:06 阅读：212 来源： 互联网

标签：HTTP HTTP3 Dissect TCP RTT QUIC 连接请求

Core Concepts(核心概念)

首先，提出几个问题:

HTTP/3 是什么？
为什么在 HTTP/2 之后这么快就需要 HTTP/3？
HTTP/3 如何提升 Web 性能？

那 HTTP/3 是什么？为什么需要HTTP/3？

实际上我们并不需要一个新的 HTTP 版本，而是底层传输控制协议 (TCP) 的升级

QUIC 就是用来替代 TCP、SSL/TLS 的传输层协议，运行在 QUIC 之上的 HTTP 协议被称为 HTTP/3

为什么需要 QUIC？

因为 TCP 并没有真正考虑到最大效率

为了确保客户端和服务器都存在，并且能够交换数据
TCP需要"握手"来建立新的连接，这需要耗费一个 RTT(完整的网络往返时间) 才能完成
TCP 将其传输的所有数据视为单个“文件”或字节流，即使实际上它同时传输着多个文件
队头阻塞：如果包含单个文件数据的 TCP 数据包丢失，那么所有其他文件也将延迟，直到这些数据包被恢复
QUIC 连接可以保持更长时间

零 RTT 建立连接

HTTP/2 的连接需要 3 RTT，如果考虑会话复用，即把第一次握手算出来的对称密钥缓存起来，那么也需要 2 RTT；如果 TLS 升级到 1.3，那么 HTTP/2 连接需要 2 RTT，考虑会话复用则需要 1 RTT(TLS 1.3 的握手不再支持静态的 RSA 密钥交换，使用带有前向安全的 Diffie-Hellman 进行全面握手)

HTTP/3 首次连接只需要 1 RTT，后面的连接更是只需 0 RTT，意味着客户端发给服务端的第一个包就带有请求数据

HTTP/1.1 提出了 Pipelining 技术，允许一个 TCP 连接同时发送多个请求

一个 TCP 连接同时传输 10 个请求，

其中第 1、2、3 个请求已被客户端接收，但第 4 个请求丢失，那么后面第 5 - 10 个请求都被阻塞，需要等第 4 个请求处理完毕才能被处理，这样就浪费了带宽资源

HTTP/2 中每个请求都被拆分成多个 Frame 通过一条 TCP 连接同时被传输，这样即使一个请求被阻塞，也不会影响其他的请求

在一条 TCP 连接上同时发送 N 个 Stream，其中 Stream1 已正确送达，Stream2 中的第 2 个 Frame 丢失，

TCP 处理数据时有严格的前后顺序，先发送的 Frame 要先被处理，这样就会要求发送方重新发送第 2 个 Frame，Stream3 和 Stream4 虽然已到达但却不能被处理，那么这时整条连接都被阻塞

那 QUIC 是如何解决队头阻塞问题的呢？

QUIC 的传输单元是 Packet，加密单元也是 Packet，整个加密、传输、解密都基于 Packet，这样就能避免 TLS 的队头阻塞问题
QUIC 基于 UDP，UDP 的数据包在接收端没有处理顺序，即使中间丢失一个包，也不会阻塞整条连接，其他的资源会被正常处理

QUIC 支持连接迁移

TCP 连接基于四元组（源 IP、源端口、目的 IP、目的端口），切换网络时至少会有一个因素发生变化，导致连接发生变化(比如，NAT重新绑定)

当连接发生变化时，如果还使用原来的 TCP 连接，则会导致连接失败，就得等原来的连接超时后重新建立连接

QUIC 连接不以四元组作为标识，而是使用一个 64 位的随机数，这个随机数被称为 Connection ID，这个 CID 是在 QUIC 本身的传输层定义的

所以即使 IP 或者端口发生变化，只要 Connection ID 没有变化，那么连接依然可以维持

QUIC 使用单独的帧来发送元数据

QUIC 具有较短的数据包头，并在数据包有效载荷中使用各种“帧”来传达额外信息。例如，一个 ACK 帧（确认）、一个 NEW_CONNECTION_ID 帧（帮助建立连接迁移）和一个 STREAM 帧（携带数据）

使用帧的作用是，将来定义新的帧类型作为 QUIC 的扩展将非常容易

Performance Improvements(性能表现)

QUIC 和 HTTP/3 具有巨大的 Web 性能潜力，但主要适用于网络速度较慢的用户

拥塞控制

传输协议如何有效地使用网络的全部带宽

TCP 通过使用称为拥塞控制的机制不断尝试发现可用带宽

尽管 TCP 的拥塞控制使其稳健，但这也意味着需要一段时间才能达到最佳发送速率，具体取决于 RTT 和实际可用带宽

QUIC 拥塞控制的实现

QUIC 实际上使用与 TCP 非常相似的带宽管理技术。它也从较低的发送速率开始，并随着时间的推移而增长，使用确认（ACK）作为衡量网络容量的关键机制。所以 QUIC 在管理带宽方面没有比 TCP 更聪明，只是 QUIC 比 TCP 更灵活，更容易演进。

官方的 QUIC Recovery RFC 9002 指定了 NewReno 拥塞控制算法的使用

参考
HTTP/3 From A To Z: Core Concepts (Part 1) — Smashing MagazineWhat exactly is HTTP/3? Why was it needed so soon after HTTP/2 (which was only finalized in 2015)? How can or should you use it? And especially, how does this improve web performance? Let’s find out.https://www.smashingmagazine.com/2021/08/http3-core-concepts-part1/HTTP/3: Performance Improvements (Part 2) — Smashing Magazinehttps://www.smashingmagazine.com/2021/08/http3-performance-improvements-part2/The Road to QUIChttps://blog.cloudflare.com/the-road-to-quic/#onenattobringthemallandinthedarknessbindthem

标签：HTTP,HTTP3,Dissect,TCP,RTT,QUIC,连接,请求
来源： https://blog.csdn.net/weixin_41836765/article/details/122095208

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

ICode9