基于QUIC的HTTP/3

大概几个月前,HTTP/3被标准化(RFC 9114),它最大改变是将HTTP传输协议从TCP变成了基于UDP的QUIC,这意味着HTTP不在是绝对的基于TCP的应用层协议。

新技术标准的成立必然有它的使命和原因,关于HTTP/3相关概念、原理的介绍在互联网上很多,本篇文章会减少这方面的介绍,更多聚焦于为什么会出现这种技术,我们为什么需要它的思考,从不一样的角度来看待这个新技术标准。

QUIC是什么

QUIC(QuickUDP Internet Connections)是Google在2012年提出的传输网络协议,它基于UDP实现,提出它的目的之一是为了“淘汰TCP”。既然要淘汰,肯定是要取其精华去其糟粕,那么QUIC解决了TCP哪些“糟粕”?

  • 提高网络切换期间的性能;(其实是UDP特性)
  • 降低连接和传输延迟;(这也是UDP特性)
  • 在用户空间实现,减少上下文切换开销;(用户空间实现TCP的重要特性,即精华)

这些内容给我们的直觉:QUIC并没有什么新的东西,只是利用UDP实现了TCP重要特性的“缝合怪”?

答案是否定的,TCP/UDP作为当今互联网传输协议的基石,差不多是距今40年前正式出现并推广的,而QUIC刚刚经历了10年的发展期,拥有更现代的解决方案:比如,QUIC在拥塞控制上比原生的TCP有着更先进的思想,更符合当下互联网的背景环境;对于发生自动重传的策略也有所优化。

而且随着时代的发展,特别是网络基建的增强,当代的网络状况比几十年前好太多太多,常规情况下网络延迟与丢包率大幅降低,越来越多基于UDP的经典用法在各个领域出现,所以说QUIC选择UDP亦是大势所趋。

那么是不是说QUIC是接近当前时代背景下的完美产物,能代表现代网络协议标准?

答案也是否定的,这个问题其实可以换一种更直接的问法:UDP+QUIC的思路能否完全取代TCP?

首先,我们从使用者的角度来分析。 抛开常谈的TCP几大问题 ,QUIC所罗列出来的特性使用了更合理并且更现代的解决方案,是存在取代TCP的动机(设计初心)和资本的。但是为什么会说无法完全取代,需要从其他角度来分析。

比如TCP当前广泛应用:基于TCP的FTP协议广泛运用在各类资源下载中;还有DNS协议,它在区域传输时使用的TCP协议。很多的软件、硬件、应用都依赖TCP,这些依赖大多都是根深蒂固,无法忽视的。

再者一些现实中的外界因素:UDP在网络运营商一直不受待见,若出现问题往往是最先丢弃的对象。比如在传统的路由器NAT功能中,TCP协议可以通过解析包头SYN,FIN判断连接的建立与终止,对路由映射表做到实时维护,但对于QUIC还无法做到精确判断(对Connection ID支持有限),目前应对手段往往都是Timeout一刀切,在网络切换频繁的情况会造成资源浪费,解决这些问题无法一蹴而就。

最后,UDP+QUIC从本质上来说只是预期解决HTTP这个场景的问题,它想要成为一个更大的趋势或者标准有待检验,并且一个漫长的过程,甚至有生之年不知道能否看到。对于现在固有的网络层级结构,更期待的方案应该出现是”TCP/2″,它完美丢掉TCP的历史包袱,让使用者平滑过渡。

HTTP/3是什么

可以理解成HTTP最新的第三代标准,它的核心就是刚才提到的QUIC。

我们先看一张HTTP发展路径图:

从发展路径总结来看:

  • 1.0版本完善了核心机制
  • 1.1和2.0版本核心是为了提效,加上一些算法上的优化,以及安全性提升;
  • 3.0版本依旧是为了提效,使用了更贴合当代背景环境的方式方法,以及解决移动网络迅猛发展给HTTP所带来的一些问题;

参考下图 (侵删,原出处未找到) 更直观一些,其中HAPCK是HTTP/2特有的压缩算法(前身就是SPDY),QPACK是HTTP/3特有的压缩算法;Stream指的流式传输的机制,核心是支持多路复用与消息有序。

既然提到了流式传输,这里不得不提到另外一个概念:WebSocket

WebSocket一种通俗的解释是HTTP的长连接实现方式,这句话说的既对也不对。WebSocket使用了HTTP的标准,并且连默认端口80和443都是一致的,但是严格的来说它与HTTP没有任何继承上的关系,WebSocket标准与端口与HTTP一致只是为了兼容。

这里好比机动车道,只要你的车符合上路的标准与规则,小轿车、货车、卡车各种车都可以走!

所以说WebSocket与HTTP没有继承关系,它其实是随着HTML5标准进入大家视野。其出现的目的主要是为了使用服务端主动推送,建立更好的实时通讯。可能有人会说HTTP/2也支持推送啊?没错,但是Google今年8月已经把Chrome关于推送的支持给禁用了!主要原因还是支持者少,换一个理解方式就是:使用场景有限。

推送功能需要全双工支持,UDP也是一个全双工的协议,那么QUIC也是天然支持全双工的,所以最终会不会出现HTTP/3兼容了WebSocket 一统江湖,也可以期待一下。

写在最后

鹅厂给的信息显示QUIC相比较HTTP/2提升20%的性能,并且已经在实际场景中使用,能省多少机器我们无法找到数据。但结论是显而易见的:QUIC作为一个新技术标准,能解决问题,确实带来了提升

也听到过这样一个故事:一位程序员优化公司内部RPC通信序列化的代码,让单核平均负载降低了3%。公司大约1W台机器的集群,粗算能省300台机器,按照每台机器平均8核16G,换算成人民币成本大约1个月至少5W。

总之不要小看和轻视这类我们可能“使用不到”的提升,技术始终是向走的,目的是为了解决问题、提升效率。虽然很多东西可能现在用不上,但不代表将来用不上,技多不压身。

(全文结束)


转载文章请注明出处:漫漫路 - lanindex.com

Leave a Comment

Your email address will not be published.