HTTP3/QUIC 时代的来临，能给App带来什么？

最新推荐文章于 2024-10-10 11:29:27 发布

Finger_ebic

最新推荐文章于 2024-10-10 11:29:27 发布

阅读量1k

点赞数 25

文章标签：安卓

本文链接：https://blog.csdn.net/KQe397773106/article/details/137127201

版权

前言

在本文发布时，HTTP3/QUIC 早在几年前就有了初版协议，去年就发布了正式版本协议。为何现在才发文呢？因为 HTTP3/QUIC 基于 UDP 协议，需要后端服务器的支持，那时能正劲提供 HTTP3/QUIC 协议的云服务商没几个，基本都是大厂内部在自己玩。时至今日，HTTP3/QUIC的铺开已经时机成熟。

QUIC的落地现状

咱们先来看看大厂的落地情况：

1.网易新闻

4.提速 30％！腾讯TQUIC 网络传输协议

腾讯自定义的 TQUIC，针对内部业务做了定制化处理，不对外开放。

5.阿里自研标准化协议库 XQUIC 正式开源！

阿里巴巴定制化的XQUIC

通过查看 App 是否有Cronet静态库，来判断App是否已支持 QUIC

图就不贴了，通过LibChecker软件来查看是否包含so库。（如有错误，欢迎指出）

哔哩哔哩
淘宝
Boss
飞书、抖音
微博

QUIC的特点，能带给App什么呢？

网上的技术细节解析文章很多，这里不做赘述，只做特点介绍

灵活性

TCP 协议固化在系统内部，并且存在的时间实在太长，已经充斥在各种设备中，并且这个协议是由操作系统内核实现的，更新和部署新款操作系统内核的过程十分缓慢，需要付出很大的努力，这几乎是一件不可能完成的任务。

QUIC 是软件层面实现的，更新迭代起来非常方便，甚至还能定制化。QUIC 的传输控制不再依赖内核的拥塞控制算法，而是实现在应用层上，这意味着我们根据不同的业务场景，实现和配置不同的拥塞控制算法以及参数。在 QUIC 下我们可以根据业务随意指定拥塞控制算法和参数，甚至同一个业务的不同连接也可以使用不同的拥塞控制算法。

TCP没有任何版本协商（version negotiation）扩展位，相比之下，QUIC有32位，所以它有很多空间部署新版本，厂商也可以利用这些空间定义自己的专属版本。

安全性

QUIC始终保证安全性。QUIC没有明文的版本，所以想要建立一个QUIC连接，就必须通过TLS 1.3来安全地建立一个加密连接。

更快的连接建立

HTTP2 在首次建立连接时，需要3次RTT时间，而在非首次建连（已经交换过TLS密钥），并且使用最快的 TLS1.3 也至少需要1次RTT时间。

QUIC 的握手连接更快，因为它使用了 UDP 作为传输层协议，这样能够减少三次握手的时间延迟。而且 QUIC 的加密协议采用了最新版本 TLS 1.3，相对之前的 TLS 1.1-1.2，TLS1.3 允许客户端无需等待 TLS 握手完成就开始发送应用程序数据的操作，可以支持1 RTT 和 0 RTT，从而达到快速建立连接的效果。

同时，UDP 本身是无序传输的，这在单个连接上并行传输多个数据有天生的优势：多个数据直接发送即可，由 QUIC 对收到的数据进行重新组合排序，然后送往上层应用。这中间不用等待各种数据确认包，效率非常高。

独立的数据流避免队头阻塞问题

不同于TCP的在单一链路上传输多种类型数据包，QUIC清楚地知道它在多路复用多个、独立的字节流。当然，它并不知道自己在传输 Json、CSS、JavaScript 和图像；它只知道这些流是彼此分开的。因此，QUIC可以在每个流的基础上执行丢包监测和恢复逻辑。

在发生丢包时，TCP 会重传丢失的包。而 QUIC，则使用了一种非常神奇的前向纠错算法，通过连续的几个数据包的校验和，可以直接恢复出丢失的包内容，而不需要重传。即便需要重传数据包，也不会造成其他数据流的阻塞。

支持连接迁移（在移动端表现更好)

在TCP中，为了区分网络连接和它们所属的应用，每个单独连接都会在两个端点处被分配一个端口号。因此，要定义各种机器和应用间的连接，我们需要一个四元组：客户端IP地址+客户端端口+服务器IP地址+服务器端口。

仅使用四元组就可以识别连接。所以，如果这四个参数之一发生了变化，就会变成无效连接并需要重新建立连接（包括一次新的握手）

如果你的手机从 Wi-Fi 切换到了 4G网络。因为这是一个新的网络，它将获得一个全新的IP地址。现在，服务器将看到TCP数据包来自之前从未见过的客户端IP。

但是服务器怎么知道来自新IP的数据包属于“之前的WI-FI连接”？很遗憾，它不知道。

因为在我们还幻想着移动网络和智能手机的时候，TCP就已经发明了，所以没有任何机制让服务器知道客户端已经更改了IP。甚至没有办法“关闭”连接，因为发送到旧四元组的TCP重置和fin命令不会再到达客户端。因此，每次的网络更改都意味着无法再使用现有的TCP连接。（这也是僵尸网络来源的原因）

每开启一条TCP链接是极其昂贵的开销，重启TCP链接会带来严重的影响（等待新的握手、重新开始下载、重建context），例如：视频会议，在切换网络时，你也许会遇到短暂的停顿。

为了解决这些问题，QUIC推出了一个被称为连接标识符（CID， connection identifier）的新概念（而不是 IP + 端口），QUIC 在数据包头部分配了连接标识符，用于两端识别。QUIC服务器和客户端只需看下连接标识符，就能知道还是之前的同一个连接，接着继续使用它即可。不需要新的握手，下载状态也可以维持原样。

由于此设计特性，不论是处于固网、Wi-Fi、4G还是5G，都能进行平滑的连接迁移。

支持 Brotli 压缩

大家在使用okhttp的时候，见的最多的是使用Gzip 对数据压缩对吧。QUIC 所支持的 Brotli 是 google 开源的一种新型压缩算法, Brotli 压缩比 Gzip 压缩性能更好。

总结

可见以上几个特点，对于App来说，个个都是直点关键穴位。哪怕不用做定制化，只需用上标准版的 HTTP3/QUIC ，就能享受到这免费的性能提升。

现今网络带宽已经大幅提升的情况下，传输的数据大小已经不是主要的性能瓶颈，反而网络延时变得更为重要。基于这个背景，QUIC 不再使用TCP作为传输层协议，而是另辟蹊径采用了UDP，适应了时代网络状况的变化。在某种程度上，QUIC 应该被看作是一个 TCP 2.0。它包括 TCP 的所有特性（可靠性、拥塞控制、流量控制、排序等）的最佳版本，以及更多其他特性。QUIC还完全集成了TLS，不允许未加密的连接。同时拥有 0 RTT 建立连接、平滑的连接迁移、基本消除了队头阻塞、改进的拥塞控制和流量控制等特性，我相信QUIC前途无量。