标题详情作者简介愚公搬代码头衔华为云特约编辑，华为云云享专家，华为开发者专家，华为产品云测专家，CSDN博客专家，CSDN商业化专家，阿里云专家博主，阿里云签约作者，腾讯云优秀博主，腾讯云内容共创官，掘金优秀博主，亚马逊技领云博主，51CTO博客专家等。近期荣誉2022年度博客之星TOP2，2023年度博客之星TOP2，2022年华为云十佳博主，2023年华为云十佳博主等。博客内容.NET、Java、Python、Go、Node、前端、IOS、Android、鸿蒙、Linux、物联网、网络安全、大数据、人工智能、U3D游戏、小程序等相关领域知识。欢迎👍点赞、✍评论、⭐收藏
文章目录
🚀前言
在最常见的HTTP（Hypertext Transfer Protocol，超文本传输协议）2.0所在分层中，TCP（Transmission Control Protocol，传输控制协议）提供了可靠按序传输、拥塞控制、流控功能，TLS（Transport Layer Secnrity，传输层安全）协议提供了认证、加密、完整性保护。每个层都在尝试解决现实世界中遇到的问题。其中最想要的特性就是尽早发送数据，减少用户感知到的延迟；另外，应用希望更快地发送和接收数据。这方面的改进如HTTP的多路复用，但可能遇到TCP的队首阻塞导致的带宽利用率不足的问题；在解决这些问题的过程中又遇到了协议僵化，无法将新特性广泛应用。我们希望能有一个新的传输协议彻底解决这些问题，于是QUIC来了！本文将讨论QUIC的诞生及其未来发展。
🚀一、QUIC的诞生
谷歌于2012年提出了QUIC，随后开始在浏览器和服务中使用。QUIC最初的定义是Quick UDP Internet Connections，思想是基于UDP提供并发、安全的传输方式，同时改进了TCP中存在的一些其他问题，比如拥塞控制、协议僵化、启动慢、重连慢、安全弱等QUIC基本功能和位置如图所示。
本文送出的书籍是这本：
🔎1.QUIC的优势
QUIC主要从以下几个方面改进了传统的传输方式。
1）实现了没有队首阻塞的并发
HTTP2为了支持并发，增加了流和帧的概念，通过帧的封装实现了流的并发，如图2所示。但是HTTP2是基于TCP的，所有帧作为一个字节流传输，如果一块数据丢失，其他数据即使收到了也不能交付，这就是TCP的队首阻塞，影响了HTTP2的并发。
为了解决这个问题，QUIC借鉴了HTTP2中流的思想，将流的概念引入传输层，传输层通过帧的封装识别了流；通过递增的报文编号检测丢包，与应用数据交付分离，从而实现了传输层的并发。如果QUIC丢了一个报文，仅仅影响对应流的交付，不会阻塞其他流。
2）尽可能地加密
QUIC与TLS1.3紧密协作，完成了数据加密，提供了数据的安全性和保密性，实现了比TCP+TLS更好的安全，如图所示。
此外，QUIC报文的首部加密，还提高了攻击门槛，还避免了协议僵化。这是因为中间件看不到QUIC报文的报文编号等信息，无法做进一步处理，后续端点想要修改QUIC的行为就不需要考虑大部分中间件的兼容性了。
3）选择UDP作为底层传输
QUIC底层传输基于UDP，从而提供避免队首阻塞的条件，也兼容了主机和中间件。
- 一方面，UDP只管发送数据报（其中封装了一个或多个QUIC报文），而不管报文之间的顺序，所以UDP本身不会形成队首阻塞，可以更好地实现并发。
- 另一方面，多年以来互联网技术的发展使主机（包括电脑、手机、服务器、虚拟机等）和中间件（NAT、防火墙、负载均衡器等）几乎成了TCP和UDP的天下，而且中间件大部分都不受自己控制，所以要使用新的协议，UDP作为底层传输是现实的选择。
4）用户态实现
QUIC将功能放在了用户态（而TCP位于内核态），如图4所示，这样可以更加灵活地修改、升级，防止了重演TCP在主机上的僵化问题。前文提到的很多问题，都可以通过改进TCP来解决，但都没有大规模应用，这是由于TCP位于内核态，难以单独升级，当然中间件的僵化也是原因之一，这应该也是QUIC对于僵化如此敏感的原因。
5）低延迟的连接建立
QUIC通过与TLS1.3的紧密结合，实现了首次最低1-RTT发送应用数据；恢复连接时发送应用数据最低只需0-RTT。这样在时延较大或者丢包率较高的弱网环境中可以提供更好的用户体验，与其他方案的对比如图所示。
首次连接对比：
恢复连接对比：
需要说明的是，TFO+TLS1.3也能实现首次1-RTT和重连0-RTT的数据发送，但是除了在最早发送应用数据与QUIC相同之外没有其他优势，比如：避免队首阻塞、更强的安全性、防止协议僵化等。
6）无缝的连接迁移
QUIC的连接基于连接标识，改变IP或者UDP端口号并不影响连接的识别，因此可以实现无缝的连接迁移。但是这给负载均衡带来了挑战，另外也增加了放大攻击风险。
7）改进的流量控制
QUIC的流量控制通过对偏移的限额实现，可以支持连接和流两个级别。除此之外，还可以限制打开中流的个数。因为完成了报文编号和数据偏移的分离，可以支持乱序确认，这比TCP+HTTP2的流量控制更加灵活。
8）改进的拥塞控制
QUIC在拥塞控制方面做出了很多优化，包括不同加密级别互相独立的报文编号空间、单向递增的报文编号、更清晰的丢包周期、确认过的报文不允许反悔、支持更多的确认范围、显式修正延迟等。对于使用多个TCP连接实现并发的应用来说，更明显的好处是可以协调所有数据间的网络占用，而不会像多个TCP连接一样竞争网络资源。
9）协议行为作为负载
TCP将协议的行为都放在首部，如ACK、序号、选项等，由于TCP首部长度限制为40字节，表达力受到了很大限制，扩展也会比较困难，而且即使使用了TLS，协议行为还是都暴露了出来。QUIC则将协议的行为大部分都作为不同的帧放在负载中携带，可以方便地扩展。
🔎2.QUIC的发展历程
谷歌最初使用的是gQUIC，跟IETF QUIC有些不同。直到2015年6月，谷歌将QUIC提交给IETF，才开始了QUIC的标准化之路。之后，IETF正式认定QUIC为一个名称，而不再作为缩写。QUIC的发展历程如图所示。
2021年5月，QUIC一系列核心草案获得标准化，包括如下内容。
●《RFC8999 QUIC的版本无关属性》定义了QUIC所有版本通用的属性。
●《RFC9000 QUIC：基于UDP的多路和安全传输》定义了传输协议的核心内容。
●《RFC9001 使用TLS保护QUIC》描述了怎么使用TLS来保护QUIC。
●《RFC9002 QUIC丢包检测和拥塞控制》描述了QUIC的丢包检测和拥塞控制机制。
此后，QUIC标准被不断完善。2022年3月，QUIC的不可靠扩展实现了标准化——《RFC9221 QUIC不可靠数据报扩展》。2022年8月，《RFC9287使用QUIC位》也标准化了。
很多应用从2022年也开始了使用QUIC的标准化之路。2022年5月，DNS标准化了基于QUIC的传输方式，发布了《RFC9250基于专用QUIC连接的DNS》。
2022年6月基于QUIC的HTTP3也标准化了，包括两个QUIC定制化的标准：
●《RFC9114 HTTP3》描述了基于QUIC的HTTP语义映射，还确定了QUIC包含的HTTP2功能，并描述了如何将HTTP2扩展移植到HTTP3。
●《RFC9204 QPACK：HTTP3的字段压缩》基于QUIC改进了HPACK，以尽量避免队首阻塞。
2022年9月，IETF标准化了用于指导中间件管理QUIC和应用使用QUIC的两个标准，即《RFC9312 QUIC传输协议的可管理性》和《RFC9308 QUIC传输协议的适用性》。
🚀二、QUIC未来发展
虽然目前来看，QUIC的应用还有很多问题，例如对中间件警惕、受限于运营商、开发和运维十分复杂等，但很多问题会随着QUIC的采用越来越多而得到根本改变。
浏览器普遍先尝试TCP+TLS的HTTP2的连接，如果在HTTP2连接中服务器通告支持HTTP3，浏览器才会重新使用HTTP3建立连接，重连也是先尝试HTTP2恢复连接。这使得QUIC的尽早发送数据、尤其是0-RTT的优势没法发挥出来，浏览器也就不能明显感受到QUIC带来的延迟改进。但这种选择是考虑到目前支持HTTP2的服务器远大于支持HTTP3的服务器，以后随着支持HTTP3的服务器越来越多，浏览器肯定会改变策略。
目前仍然有些中间件不认识QUIC、限制UDP流量，这使得客户端和服务器支持HTTP3都需要支持回退至HTTP2。但是服务提供商对HTTP3有着很大的热情，这除了由于QUIC带来的性能和安全好处外，还由于QUIC将传输协议的控制权从网络提供商和操作系统提供商手中抢了过来。这将倒逼中间件的更新，在未来也不应该是什么问题。
在QUIC本身的技术发展方面，优秀的解决方案会逐渐标准化。比如前向纠错依然没有标准化的解决方案，这对丢包明显的长链路上的传输有明显的效果，尤其是跨洋的长链路，这样的链路RTT较大，识别到丢包的周期较长，如果使用前向纠错能避免重传，提升用户的体验。另外，随着APP的发展，定制化也会加强。
所以，现在可以看到，尽管我们分析出QUIC存在种种问题，但都无法阻挡服务提供商的脚步。无论在国内还是国外，大型互联网厂商都在争取支持QUIC。
在浏览器方面，2020年10月Chrome宣布支持IETF QUIC（以前仅支持Google QUIC），2020年11月微软Edge发布了支持HTTP3的版本，2021年4月Firefox发布了支持HTTP3的版本。
在国外互联网的服务器中，截至2023年年初大约有四分之一的网站已经支持了HTTP3。这个数据来自HTTP3标准化一年多的时候。可以看出，互联网对于QUIC的采用还是很迅速的，预计QUIC会以更快的速度占领传输领域。
苹果2021年9月发布了支持HTTP3的版本iOS15；脸书在2020年宣布上线QUIC，当时脸书在互联网上的流量已经有75%以上基于QUIC。
国内互联网上的服务器没有确切的统计数据，但大部分的互联网厂商都发布了关于QUIC支持的研究成果和优化方案，也有很多厂商支持了QUIC，如百度、腾讯、阿里等。
🚀三、总结
QUIC来源于谷歌，也就更在意终端用户的感受，所以QUIC作为应用的传输层更在意首包低时延，可以更快地发送应用数据，让用户感受到更低的时延。QUIC也在意更弱网环境和移动设备，设计上对手机等要使用无线传输的设备来说比较友好；同时QUIC也考虑了中间件的支持，底层传输选用UDP，这在复杂网络环境中能更好地传输，同样也是对个人终端友好的表现。QUIC还支持了不可靠的数据报方式，对于终端上的直播和游戏类应用提供了更好的支持。
多宿主多流模式是传输协议的发展方向，安全也成为传输协议需要考虑的重要问题，总的来说传输层功能越来越多了。
目前市面上关于QUIC/HTTP3的系统性书籍十分稀少，如果您对该领域想要有更深入的了解，推荐您阅读刘准、陈保军老师的新书《解析QUIC/HTTP3：未来互联网的基石》。
本文摘编自《解析QUIC/HTTP3：未来互联网的基石》（书号：9787111759287），经出版方授权发布，转载请保留文章来源。
《解析QUIC/HTTP3：未来互联网的基石》：随着通信技术的不断进步，越来越多的应用开始向HTTP3迁移，这极大地提升了互联网的数据传输效率与安全性。本书深入浅出地剖析了HTTP3的网络传输层协议QUIC，是作者在多年实践中总结的智慧结晶。本书不仅可以帮助读者精准判断QUIC技术的适用场景，还能在问题出现时，迅速帮助读者分析原因并找到解决方案。本书适用于那些对新兴互联网技术感兴趣的网络工程师、开发人员和科研人员。
作者简介
刘准，紫金山实验室未来网络研究中心工程师，主要从事新型网络传输协议的研究与设计工作。曾在中兴通迅与华为从事路由器研发工作数十年。
陈保军，工学硕士。在通信行业从事通信软件研发工作近20年，对通信协议有深刻理解，发明通信协议工程应用专利多项。
需要完全了解本书可以看下面：
直达京东链接🔗：地址《解析QUIC/HTTP3：未来互联网的基石》
版权归原作者 愚公搬代码 所有， 如有侵权，请联系我们删除。