quic 协议分析

HTTP 3 ，它来了，QUIC（quick udp internet connection “快速 UDP 互联网连接”）正如其名一样，它就是快。其正在标准化为新一代的互联网传输协议。是由google提出的使用udp进行多路并发的传输协议。

QUIC解决了什么问题呢？从上世纪90年代至今，互联网一直按照一成不变的模式发展着。使用ipv4进行路由，使用tcp进行连接层面的拥塞控制，并保证其传输的可靠性，使用tls层进行安全加密和身份验证，使用http进行应用的数据传输。

这么多年的发展，这些协议只是小部分或者细节上有了改变，tcp提出了几个新的拥塞控制算法，tls改变了加密方式，http层进化出了h2。但是互联网发展至今，网络传输的内容越来越大，用户对传输的时延，带宽提出越来越大的要求。

tcp虽然也在拥塞控制上提出了一些优秀的拥塞控制算法，如BBR但是限制于其对 *** 作系统内核版本的要求，tcp 的 TFO，windows *** 作系统又支持不好等。导致想要切换成更高效的协议成本巨大。

这里列出几个主要的矛盾。

1、协议历史悠久导致中间设备僵化。

2、依赖于 *** 作系统的实现导致协议本身僵化。

3、建立连接的握手延迟大。

4、队头阻塞。

QUIC孕育而生，其抛开了TCP直接采用UDP，如一些拥塞算法，可靠性保证机制，不再依赖 *** 作系统内核，而是可以自定义。

Quic 相比现在广泛应用的 http2+tcp+tls 协议有如下优势：

1、减少了 TCP 三次握手及 TLS 握手时间。

2、改进的拥塞控制。

3、避免队头阻塞的多路复用。

4、连接迁移。

5、前向冗余纠错。

有些防火墙只允许通过 80 和 443，不放通其他端口。NAT 网关在转换网络地址时重写传输层的头部，有可能导致双方无法使用新的传输格式。因为通信协议栈都是固化到 *** 作系统中的，只能通过内核参数进行调整，但是这样的调整极其有限，如果想要新加协议，只能重新编译内核。而现实是，可能还有一些Centos5 还作为某些古董公司的线上服务器。另外，windows xp 可能还是某些事业单位的办公电脑上装的 *** 作系统，尽管xp的时代已经过去20年了。另外TCP Fast Open 也在2013年就提出了，但是windows *** 作系统也有些不支持。

知道一个首次https网站的访问都要有哪些步骤吗？dns解析需要1个RTT，TCP三次握手，HTTP 302 跳转 HTTPS又需要RTT，TCP重新握手。TLS握手再消耗2个。解析CA的DNS（因为浏览器获取到证书后，有可能需要发起 OCSP 或者 CRL 请求，查询证书状态）再对CA进行TCP握手，OCSP响应。密钥协商又是RTT。当然这种情况是最极端的，大部分情况下不是所有流程都需要走一遍的。（参考 大型网站的 HTTPS 实践（二）-- HTTPS 对性能的影响 ）

基于以上的原因，QUIC选择了UDP。没有了三次握手，在应用层面完成了传输的可靠性，拥塞控制还有TLS的安全性。只要应用软件的客户端和服务端支持就行，绕开了 *** 作系统内核版本这个硬骨头。

在HTTPS over TCP+TLS的时代。HTTPS需要3个RTT，在session 复用的情况下是2个RTT。而QUIC做到了1RTT和会话复用的0RTT。

QUIC的TLS只能使用TLS1.3，这就可以做到PSK的0RTT。

TCP 的拥塞控制实际上包含了四个算法：慢启动，拥塞避免，快速重传，快速恢复。其中TCP中拥塞控制是被编译进内核中的，如果想要更改就需要改变内核参数，但是想要对已有的拥塞控制算法进行更改就需要重新编译内核，Linux 4.9 中引入了基于时延的拥塞控制算法 BBR，这打破了以往是靠丢包驱动的拥塞控制算法，但是想要在TCP中使用，就必须升级内核至4.9以上。

QUIC 协议当前默认使用了 TCP 协议的 Cubic 拥塞控制算法 [6]，同时也支持 CubicBytes, Reno, RenoBytes, BBR, PCC 等拥塞控制算法。

QUIC和TCP的对比

其中α 从 0到 1（RFC 推荐 0.9），越大越平滑

如 UBOUND为1分钟，LBOUND为 1 秒钟， β从 1.3 到 2 之间

对于QUIC

参考： 科普：QUIC协议原理分析 罗成

Linux 内核维护者 Greg Kroah-Hartman 在私人 Google+ 发布一条短消息，将 Linux Kernel 4.9 分支标记为 “longterm”，意味着 4.9 版本将会作为长期支持版本。

事实上关于 Linux Kernel 4.9 是否是长期支持版本的故事要从 2016 年 8 月 12 日开始说起，当时 Greg Kroah-Hartman 在 Google+ 上发布信息，说 “4.9 == next LTS kernel”；去年 9 月 6 日，Greg Kroah-Hartman 改变了这个想法，表示将会在 Kernel.org 网站上保留给 4.9 当作 “长期支持” 的权利。

在他的私人博客中写道：“因为很多人滥用这个通知这给我们造成了很大的困扰， 因此我保留是否选择 4.9 作为长期支持的权利。如果是这样，我可能会重新选择 4.8 分支或者等待 4.10 版本。如果有了进一步的消息，我们将会在 kernel.org 网站上进行更新让所有人都知道。”

关于更多Linux的学习，请查阅书籍《linux就该这么学》。

参考资料

介绍：数字音频接口DAI

docs.nvidia.jetson.ASoC - 非常重要

Nuvoton NAU88C22资料（或其他如RT5659\WM8960等等）

软件版本

JetPack4.2.1 (R32.2.0)

Jetson Nano Upstream

Linux-4.9 Version

硬件连接

1、介绍 Jetson Audio ALSA

2、音频调试Audio Debugging

Step1. Jetson Nano output MCLK (12.288MHz or ...) and I2S4 configuration

Step2. Check I2C communication &codecs probe

Step3. Check dai routes and sound cards

附录：

1. 调试过程的Buglist

2.Jetson ASoC Audio Hub Introduction

4. Ubuntu Shell 播放MP3

5. Tegra210 --- DAMP 列表

---