请选择 进入手机版 | 继续访问电脑版

默认
打赏 发表评论 5
想开发IM:买成品怕坑?租第3方怕贵?找开源自已撸?尽量别走弯路了... 找站长给点建议
网络编程懒人入门(十):一泡尿的时间,快速读懂QUIC协议

1、TCP协议到底怎么了?


现时的互联网应用中,Web平台(准确地说是基于HTTP及其延伸协议的客户端/服务器应用)的数据传输都基于 TCP 协议。

但TCP 协议在创建连接之前需要进行三次握手(如下图 1,更详细原理请见《理论经典:TCP协议的3次握手与4次挥手过程详解),如果需要提高数据交互的安全性,既增加传输层安全协议(TLS),还会增加更多的更多握手次数(如下图 2)。

11111.png        2.png
▲ 图 1 - TCP的三次握手原理图                                           ▲ 图 2  - TLS的初始化握手原理图

正如上面两张图里演示的原理,TCP 协议连接建立的成本相对较高。

所以,一般的稳定网络传输都是通过TCP,但是在网络基建本身就已经越来越完善的情况下,TCP设计本身的问题便暴露了出来,特别是在弱网环境下,让我们不得不考虑一些新的可能性。

2、QUIC协议登场


和 TCP 相反,UDP 协议是无连接协议。客户端发出 UDP 数据包后,只能“假设”这个数据包已经被服务端接收。这样的好处是在网络传输层无需对数据包进行确认,但存在的问题就是为了确保数据传输的可靠性,应用层协议需要自己完成包传输情况的确认。

此时,QUIC 协议就登场了。

QUIC 是 Quick UDP Internet Connections 的缩写,谷歌发明的新传输协议。

与 TCP 相比,QUIC 可以减少延迟。

QUIC 协议可以在 1 到 2 个数据包(取决于连接的服务器是新的还是已知的)内,完成连接的创建(包括 TLS)(如下图3所示)。

3-0.png
▲ 图 3  - QUIC 协议握手原理图

从表面上看:QUIC 非常类似于在 UDP 上实现的 TCP + TLS + HTTP/2。由于 TCP 是在操作系统内核和中间件固件中实现的,因此对 TCP 进行重大更改几乎是不可能的(TCP 协议栈通常由操作系统实现,如 Linux、Windows 内核或者其他移动设备操作系统。修改 TCP 协议是一项浩大的工程,因为每种设备、系统的实现都需要更新)。但是,由于 QUIC 建立在 UDP 之上,因此没有这种限制。QUIC 可以实现可靠传输,而且相比于 TCP,它的流控功能在用户空间而不在内核空间,那么使用者就不受限于 CUBIC 或是 BBR,而是可以自由选择,甚至根据应用场景自由调整优化。

QUIC 与现有 TCP + TLS + HTTP/2 方案相比,有以下几点主要特征:

  • 1)利用缓存,显著减少连接建立时间;
  • 2)改善拥塞控制,拥塞控制从内核空间到用户空间;
  • 3)没有 head of line 阻塞的多路复用;
  • 4)前向纠错,减少重传;
  • 5)连接平滑迁移,网络状态的变更不会影响连接断线。

3-2.png

从图上可以看出,QUIC 底层通过 UDP 协议替代了 TCP,上层只需要一层用于和远程服务器交互的 HTTP/2 API。这是因为 QUIC 协议已经包含了多路复用和连接管理,HTTP API 只需要完成 HTTP 协议的解析即可。

有关QUIC的详解请见:技术扫盲:新一代基于UDP的低延时网络传输层协议——QUIC详解》。

3、QUIC协议的目标


QUIC 协议的主要目的,是为了整合 TCP 协议的可靠性和 UDP 协议的速度和效率

一张图看懂QUIC协议的优势:
4.png

对于 Google 来说优化 TCP 协议是一个长期目标,QUIC 旨在创建几乎等同于 TCP 的独立连接,但有着低延迟,并对类似 SPDY 的多路复用流协议有更好的支持。 如果 QUIC 协议的特性被证明是有效的,这些特性以后可能会被迁移入后续版本的 TCP 和 TLS 协议(它们都有很长的开发周期)。

值得注意的是,虽然理论上来说,如果 QUIC 的特性被证明是有效的,这些特性以后可能会被迁移到后续版本的 TCP 协议中,但鉴于TCP协议长达几十年在互联网通信里的垄断地位,以及这么多年积累下来的沉重历史报复,想要根本性地优化或改进TCP协议,难度相当大(或许,有些事情,只能是想想而已,IPV6还喊了这么多年呢,不是一样没普及。。。)。

4、QUIC协议这么好,可以大规模切换为QUIC吗?


理想和现实总是有一定的差距:虽然经过多年的推广的应用,但QUIC协议目前仍未达到大量普及的阶段,在 IETF上的QUIC 依然还是草稿,并且还存在Google QUIC与IETF QUIC两类不稳定的协定。

而且,QUIC还面临以下挑战:

  • 1)小地方,路由封杀UDP 443端口( 这正是QUIC 部署的端口);
  • 2)UDP包过多,由于QS限定,会被服务商误认为是攻击,UDP包被丢弃;
  • 3)无论是路由器还是防火墙目前对QUIC都还没有做好准备。

5、QUIC协议实践


Chrome 浏览器从 2014 年开始已经实验性的支持了 QUIC 协议。可以通过在 Chrome 浏览器中输入 chrome://net-internals/#quic 查看是否已经支持 QUIC 协议。如果还未支持,可以在 chrome://flags/#enable-quic 中进行开启。

开始 Chrome 浏览器对 QUIC 协议的支持之后,可以在 chrome://net-internals/#quic 中查看到当前浏览器的 QUIC 一些连接。当然目前只有 Google 服务才支持 QUIC 协议(如 YouTube、 Google.com)。

666.png

Google 在 2015 年的一篇博文中分享了一些关于 QUIC 协议实现的结果,这些优势在诸如 YouTube 的视频服务上更为突出:用户报告通过 QUIC 协议在观看视频的时候可以减少 30% 的重新缓冲时间

6、我想试试QUIC协议,可以怎么做?


目前支持 QUIC 协议的 web 服务只有 0.9 版本以后的 Caddy 。其他常用 web 服务如 nginx、apache 等都未开始支持。

整个 QUIC 协议比较复杂,想自己完全实现一套对笔者来说还比较困难。

所以先看看开源实现有哪些。

1)Chromium
这个是官方支持的。优点自然很多,Google 官方维护基本没有坑,随时可以跟随 chrome 更新到最新版本。不过编译 Chromium 比较麻烦,它有单独的一套编译工具。暂时不建议考虑这个方案。

2)proto-quic
从 chromium 剥离的一个 QUIC 协议部分,但是其 github 主页已宣布不再支持,仅作实验使用。不建议考虑这个方案。

3)goquic
goquic 封装了 libquic 的 go 语言封装,而 libquic 也是从 chromium 剥离的,好几年不维护了,仅支持到 quic-36, goquic 提供一个反向代理,测试发现由于 QUIC 版本太低,最新 chrome 浏览器已无法支持。不建议考虑这个方案。

4)quic-go
quic-go 是完全用 go 写的 QUIC 协议栈,开发很活跃,已在 Caddy 中使用,MIT 许可,目前看是比较好的方案。

那么,对于中小团队或个人开发者来说,比较推荐的方案是最后一个,即采用 caddy 来部署实现 QUIC。caddy 这个项目本意并不是专门用来实现 QUIC 的,它是用来实现一个免签的 HTTPS web 服务器的(caddy 会自动续签证书)。而QUIC 只是它的一个附属功能(不过现实是——好像用它来实现 QUIC 的人更多)。

从Github的技术趋势来说,有关QUIC的开源资源越来越多,有兴趣可以自已逐一研究研究:https://github.com/search?q=quic

7、本文小结


QUIC 协议开创性的使用了 UDP 协议作为底层传输协议,通过各种方式减少了网络延迟。

虽然目前 QUIC 协议已经运行在一些较大的网站上,但离大范围普及还有较长的一段距离,期待 QUIC 协议规范能够成为终稿,并在除了谷歌浏览器之外的其他浏览器和应用服务器中也能够实现。

8、参考资料



Google的“ Next generation multiplexed transport over UDP”文档:
Next generation multiplexed transport over UDP.pdf (563.01 KB , 下载次数: 0 , 售价: 1 金币)

即时通讯网 - 即时通讯开发者社区! 来源: - 即时通讯开发者社区!

上一篇:不为人知的网络编程(九):理论联系实际,全方位深入理解DNS下一篇:求教,对于有关TCP协议文章的图片的内容有疑问

本帖已收录至以下技术专辑

推荐方案
评论 5
群主,我一泡屎都拉完了,还没看懂,肿么办!
签名: 秋天到了,终于凉快了
引用:clark.li 发表于 2019-11-01 15:44
群主,我一泡屎都拉完了,还没看懂,肿么办!

你这是拉稀了吧,拉个shi能比拉尿还快...
签名: 《即时通讯音视频开发(十九):零基础,详解视频编码技术原理》http://www.52im.net/thread-2840-1-1.html
群主这篇我看了个把小时,你这泡尿是怎么肥事
引用:李瑞啊 发表于 2019-11-06 15:25
群主这篇我看了个把小时,你这泡尿是怎么肥事

下次不能叫这标题,矛盾很大。。。
签名: 《即时通讯音视频开发(十九):零基础,详解视频编码技术原理》http://www.52im.net/thread-2840-1-1.html
引用:JackJiang 发表于 2019-11-06 15:33
下次不能叫这标题,矛盾很大。。。

把尿改成shi就没问题  就是有点恶心
打赏楼主 ×
使用微信打赏! 使用支付宝打赏!

返回顶部