QUIC/HTTP3 协议简析

原创
2020/06/29 10:24
阅读数 5.1W

从 HTTP 的进化历史讲起,细说使用协议的变迁,了解原因发现问题,解码 QUIC 在 HTTP3 中的支撑作用,共同探讨 HTTP3 的未来。

HTTP、HTTP2 和 HTTP3

先和大家来回顾一下 HTTP 的历史,看看 HTTP3 相比 HTTP、HTTP2 都有哪些改进和升级的地方。

HTTP VS HTTP2

HTTP 和 HTTP2 的差别

多路复用:多路复用时,多文件传输有时只需维护一个 TCP 连接。如果是 HTTP1 协议下,每份资源的传输对应一个 TCP 连接,一般最多只能开启 6 个 TCP 连接来传输多路数据,后续每增加一个新链接就会因为拥堵问题卡死,进而导致整个进程无法运行。因此HTTP/2解决了 HTTP 的队头阻塞问题。

头部压缩和 Server Push:HTTP2 会通过 HPACK 做头部压缩。同时 HTTP2 是二进制协议,在解析上相比基于文本的 HTTP解析效率上有所提升,并且 HTTP2 还增加了 Server Push。

在 TCP 下,依然无法解决延迟问题,比如为防止初始阻塞而引入的慢启动;TCP 队头阻塞,比如由于发生丢包,整个连接涉及的传输数据都需要重传而引起的阻塞。

尽管 HTTP2 相比 HTTP 已经有了改进的地方,但是如果你有 2% 的丢包率,那 HTTP2 在性能上就没有优势了。

上图是造成 TCP 队头拥塞(Head of line blocking)的原因。HTTP2 协议是基于 TCP 的,但是 TCP 本身是无法解决队头拥塞,为什么呢?因为 HTTP2 会把一次传输所有的文件都放在一个 TCP 连接中,只要这个 TCP 中发生一个丢包,连接就必须重新建立,之前所有传输内容进行必须重传,从而造成拥塞。

HTTP3 VS HTTP2

  • HTTP3 本质不是对 HTTP 协议本身的改进,它主要是集中在如何提高传输效率。上图是相比 HTTP2 而言 HTTP3 提升的点:

  • HTTP3 使用 stream 进一步扩展了 HTTP2 的多路复用。在 HTTP3 模式下,一般传输多少个文件就会产生对应数量的 stream。当这些文件中的其中一个发生丢包时,你只需要重传丢包文件的对应 stream 即可。

  • HTTP3 不再是基于 TCP 建立的,而是通过 UDP 建立,在用户空间保证传输的可靠性,相比 TCP,UDP 之上的 QUIC 协议提高了连接建立的速度,降低了延迟。

  • 通过引入 Connection ID,使得 HTTP3 支持连接迁移以及 NAT 的重绑定。

  • HTTP3 含有一个包括验证、加密、数据及负载的 built-in 的TLS安全机制。

  • 拥塞控制。TCP 是在内核区实现的,而 HTTP3 将拥塞控制移出了内核,通过用户空间来实现。这样做的好处就是不再需要等待内核更新可以实现很方便的进行快速迭代。

  • 头部压缩。HTTP2 使用的 HPACK,HTTP3 更换成了兼容 HPACK 的 QPACK 压缩方案。QPACK 优化了对乱序发送的支持,也优化了压缩率。

为什么选择 QUIC

从图上可以看到 QUIC 协议层就实现了可靠的数据传输,拥塞控制,加密,多路数据流。

至于 QUIC 为什么使用了 UDP 的问题,在了解这个之前,我们需要先知道一个事情。频繁的用户态和核心态切换会效率问题。理论上说,将应用层的东西迁移到内核从而提升效率是可行的,但是这么做会影响操作系统的稳定性。另一方面,我们可以选择将这部分内容迁移到用户空间。比如目前流行的 DPDK,当网卡将数据包传输过来时,它是绕过内核在用户空间进行控制和应用。目前又拍云的 DNS 就进行了这样的处理,让又拍云的整体效率提升了5-10 倍。

接下来我们来正式说一下 QUIC 为什么使用了 UDP 的问题,是因为以下几点:

  • 避免 ossification(僵化):QUIC 协议加密负载,也是避免协议僵化一种方式,比如当中间层处理 UDP 数据时,只需要按照数据包的方式去处理即可,不需要去关注内部层的具体信息。

  • 放弃改进 TCP 本身

  • 创新方向:QUIC 是由谷歌提出的,所以 UDP 是以浏览器为出发点,从协议、从浏览器方向来进行创新。

TLS 1.3 Vs TLS 1.2

TLS 1.3 跟 1.2 的一些提升主要有上图几点,大家可以大致看一下:

  • TLS 1.3 采用了新的加密套件

  • TLS 1.3 定义了一些新的证书类型以及秘钥交换机制。在 TLS 1.3 你不再需要去特别指定,它可以根据秘钥套件配件进行证书类型的自主推导。

QUIC 存在的问题

接下来说一下 QUIC 目前存在的问题。

首先是因为这些年性能的优化提升都针对 TCP ,使得 UDP 性能没有任何改进。当然随着 QUIC3 的发布,相信后续应该会有相对的投入。

其次是安全问题,也就是反射攻击,即伪造原地址。这个指发送数据包时的原地址是伪造的,不是真正的地址,会引起放大攻击。原因是 QUIC 握手过程是不对称的,特别是第一次请求时,客户端只需要发送几个字节的信息到服务器,而服务器则需要把证书等很多东西返还给客户端,这个不对称的机会造成了放大。草案 27 定义了两个规则和机制来限制反射攻击:客户端发送Initial包,即第一个数据包时,其长度必须在 1200 bytes以上,不足部分用 Padding 帧填充,同时,当服务端不确定客户端可靠性时,可以发送 Retry 包要求客户端再次提供验证信息。

开源 QUIC 的实现

接下来我们简单说一下目前开源的使用情况:

  • quiche:这个是用 Rust 做的库,通过 Nginx 调用。google 自己的库也叫 quiche,C++写的。

  • ATS:Apache Traffic Server

  • golang:Caddy;

  • python+C,aioquic

  • 微软msquic

开源 QUIC 的实现有很多,上面只是其中的一部分,同时我选择了quiche 和 aioquic 做了一些简单测试。

上图展示的是从 cloudflare 提供支持 HTTP3 的 curl ,可以看到这个返回的值就是 HTTP/3 200。其中 alternative service 段,指示为 h3—27,表示支持 http3 draft-27 的服务跑在 UDP 443 端口。这个 alt-svc 是 HTTP2 时代就存在,在 HTTP3 也持续使用,因为有些时候浏览器并不知道服务器是否支持 QUIC,所以通过 TCP 发起请求,确定有 H3 支持后,再通过 UDP连接。

这个是 HTTP2 的,目前可能是因为本身库的问题,使用 curl 打不开谷歌,但是从信息上可以看到 27、25 这些都是支持的。

如何部署以及达成 HTTP3 的 QUIC 实现

目前主要有两种方式来实现,一种是代理,第二种是通过 Nginx。

腾讯是通过整合到 Nginx 利用它来实现框架的。同时因为 QUIC 每一条请求的含有头的数据都会经过加密,腾讯有一个单独的硬件加密群,如果你使用腾讯,那么你所有的加解密都会通过他们的硬件来加速。

从腾讯这个可以看出加解密部分有着很可观的 CPU 占用率,如果后续所有的请求都是通过 HTTP3 来进行的话,在提升这块占用率上需要未雨绸缪。当然就像前面提到的 DPDK,也就是把数据丢到 FPGA 内去加解密是一个可以考虑的解决方案。

通过代理来实现的这种方式,目前官方暂时还没有消息。我可以像 cloudflare 那样,先在外面进行整合,然后再讲整合链接转到 Nginx 内。

又拍云目前有 LBS 和 Marco ,这个是因为 LBS 只认 TCP/UDP,它看不到 HTTP。也就是我们做了一个负载均衡的集群,通过这个集群在转到 Nginx 上。而使用 UDP 则相当于已经走过了一个四层的负载均衡,那么后续可以尝试将 QUIC 的基线提取出来使用,在代理上做加解密,从而提高效率。

往期技术文章都在微信同步分享,可以添加微信:upyun0001

推荐阅读

容器化技术在数据中心的实践

从新冠疫情出发,漫谈 Gossip 协议

展开阅读全文
打赏
8
80 收藏
分享
加载中
1
2020/07/07 16:43
回复
举报
您好,请问HTTP协议版本的变动影响应用端的tomcat和浏览器吗?tomcat需要做判断浏览器是否用不同协议的版本的HTTP协议吗?
2020/07/06 10:11
回复
举报
然而国内各种内网套内网环境, UDP丢包丢得很厉害, 还不如TCP靠谱
2020/07/06 10:10
回复
举报
谁说的
2020/07/06 22:03
回复
举报
搜索"UDP QOS"
2020/07/07 10:02
回复
举报
该评论暂时无法显示,详情咨询 QQ 群:912889742
这就是UDP丢包的最大来源, 运营商搞的你能怎么办?
2020/07/07 12:04
回复
举报
其实,不是运营商要搞你,QOS的目的是保证正常的通讯质量不受影响,在网络拥堵的情况下,如果没有QOS,网络质量就会出现大问题,那么设置QOS队列,可以将不同业务流量设置不同的优先级,UDP是不可靠通讯,在拥堵的情况下,丢包也无所谓,所以,UDP 的优先级就相对较低,触发QOS,通常发生在流量超过一定程度,可能影响网络正常服务质量的情况下,触发QOS进行临时性封堵,对于小流量的udp业务没有问题。不存在频繁丢包的问题,更何况http3完全支持后,运营商可以修改qos优先级,这样就不会有问题了
2020/07/07 12:32
回复
举报
顺便说下,QOS策略,在任何国家任何机房都有相关设置,只是网络环境和设置不一样
2020/07/07 12:33
回复
举报
该评论暂时无法显示,详情咨询 QQ 群:912889742
该评论暂时无法显示,详情咨询 QQ 群:912889742
回复 @dwingo : 它不用分辨,直接改队列优先级就行,现在的网络设备转发速度和以前大不相同了,合理修改影响应该也不大,更何况,只有流量过大的UDP会被QOS,正常网页访问,影响不大
2020/07/07 13:17
回复
举报
回复 @dwingo : QOS,在大流量场景下,有重要的使用意义,各国都有,别担心了哈
2020/07/07 13:21
回复
举报
该评论暂时无法显示,详情咨询 QQ 群:912889742
回复 @欧阳春晖 : 正常的网页访问? 你可知道很多网站下载视频/音频下载都是通过HTTP的? HTTP3的普及就代表着TCP成为小众了.
2020/07/07 13:38
回复
举报
回复 @dwingo : 你还是自己看着吧,qos策略是人设置的,国内国外都有,在大流量场景下,使用qos有很重要的意义的
2020/07/07 18:23
回复
举报
回复 @欧阳春晖 : QoS当然是人设置的, 还分三六九等, 最便宜的家庭宽带是最低等的, 手机流量收费的中等, 高价企业宽带最高. 企业和手机流量高的时候, 家庭宽带就大量丢包让步吧.
2020/07/07 19:14
回复
举报
回复 @dwingo : 如果你不懂,奉劝你不要乱说,任何大流量网络场景,包括机房,包括主干网,都必然存在QOS。QOS在具有网络瓶颈的应用场景下,是有不可或缺的作用的,各种企业级路由器设备,也都支持qos服务质量控制。。。希望你不要再臆测人家设置qos的动机,不要再臆测qos的功能,这些场景下,如果没有qos,绝对不一定是好事
2020/07/07 22:31
回复
举报
回复 @欧阳春晖 : 你反复说这些没有用, QoS的结果就是丢包, 再怎么解释都无法避免丢包!
2020/07/08 10:03
回复
举报
回复 @dwingo : 你不懂qos,我玩专业软路由vyos的比你知道的多,你不懂就别说了,另外,tcp也一样是走qos,只是优先级不同,流量整形用的
2020/07/08 12:46
回复
举报
回复 @欧阳春晖 : 你又不是运营商, 就别装懂了. TCP的QoS优先级远远高于UDP. 你去看看抱怨QoS的几乎都是UDP.
2020/07/08 14:18
回复
举报
回复 @dwingo : 这很正常,udp流量大了自然要封堵,要不然,会形成大流量网络瓶颈的,毕竟tcp通讯可靠性还是要保证的,但是其实qos有不同的策略,这个策略可以做修改的,你根本没接触过所谓的QOS
2020/07/08 16:48
回复
举报
回复 @dwingo : https://docs.vyos.io/en/lastst/qos.html
自己好好恶补下qos,如果有需要保证quic,自然有方法。。修改qos策略就行了,但是这在大流量场景下,几乎是不可缺少的,因为一定会遇到流量瓶颈
2020/07/08 16:51
回复
举报
该评论暂时无法显示,详情咨询 QQ 群:912889742
该评论暂时无法显示,详情咨询 QQ 群:912889742
该评论暂时无法显示,详情咨询 QQ 群:912889742
该评论暂时无法显示,详情咨询 QQ 群:912889742
回复 @欧阳春晖 : 你太小看我了吧...有审计就有反审计, 而且在quic这种本身自带加密的协议普及时会更难审计.
2020/07/08 20:15
回复
举报
回复 @dwingo : 哎,多看点书把
2020/07/08 20:18
回复
举报
回复 @欧阳春晖 : 我上网20年了, 什么没见过, 你还是自己多点见识吧
2020/07/08 20:32
回复
举报
该评论暂时无法显示,详情咨询 QQ 群:912889742
回复 @slyang520 : 你确信? 根据我了解的公开信息(如 https://www.zhihu.com/question/35218543), 只有实时视频/语音传输用了UDP(这种用法确实是惯例), 其它都是TCP.
2020/07/18 20:45
回复
举报
回复 @欧阳春晖 : 跟满地打gun说不听不听我觉得这样就是这样的人聊天也是难为你了
02/01 17:22
回复
举报
该评论暂时无法显示,详情咨询 QQ 群:912889742
QUIC/HTTP3 协议简析
2020/07/05 15:21
回复
举报
http/2什么问题普及呢
2020/07/05 13:16
回复
举报
已经普及了,各大浏览器已经完成http2支持,我的网站早已支持http2
2020/07/05 18:57
回复
举报
建议给出HTTP/3的核心编码和解码算法,这样的简析才有深度和启发性.
2020/07/05 10:29
回复
举报
有的地方懂了。有的地方不懂。不管怎样先支持一下
2020/06/29 19:41
回复
举报
更多评论
打赏
39 评论
80 收藏
8
分享
返回顶部
顶部