ons）是Google设计的一套可靠UDP传输协议，旨在为HTTP提供一个安全、可靠、高效和低延时的基础。QUIC协议已被IETF采纳为标准，并且HTTP/3已选择使用QUIC来代替TCP作为其传输层协议。LiveVideoStkCon2022 北京站邀请了清华大学的马川为我们介绍QUIC协议的诞生、目前的拓展成果以及未来的发展方向。

　　大家好，我今天分享的题目是：《面向流媒体的确定时延传输——从QUIC出发，走向未来》。可能有人对此会有疑问：什么是QUIC？未来又是什么？这个标题到底是什么意思？ QUIC是一个全新的用户态的传输协议。目前在流媒体传输优化方面，以QUIC为基础，我们有了一些全新的发展可能。那么具体有什么，它的未来又是什么样，现在有哪些工作涉及它，这就是本次的演讲主题。

　　首先做一个简单的自我介绍，我是清华大学2021级计算机系网络所的硕士研究生马川，我的导师是崔勇教授。目前我的主要工作是，基于最新的QUIC传输协议来开发和研究具有自主知识产权的相关协议，该协议目前被称作DTP协议。

　　DTP协议现在已经被清华的A类会议ICNP所收录，并且成为了CCSA的通信协会标准。除此之外我还积极参与了IETF若干工作组的相关工作，推广发展DTP的思想，并且尝试对该协议进行落地和应用。现阶段取得的主要成果是关于DTP协议的相关研究工作被列为国家重点研发项目亮眼成果。

　　本次是希望与大家分享我们随着互联网发展同步开展的研究工作。首先世界上出现了全新的标准，有了统一的协议，于是我们在新协议基础上创新了新技术，并且尝试将新技术进行落地。从IETF的QUIC协议开始，我们按照上图中的流程取得了相关工作成果，包括流媒体方向、内部接入方向，协议接入方向。

　　未来也许有未来的方向。但由于我经验尚浅，所以本次只是希望从学术和标准化角度给大家提供一些全新的思路。大家可以权当听个故事，通过展示我们走过的道路可以有进一步的交流讨论。

　　以上是本次演讲的主要内容，首先为大家简单介绍IETF组织，然后对QUIC协议进行介绍，随后向大家介绍我们所做的DTP协议，最终是对未来的展望和总结。

　　首先介绍IETF组织，它名字的中文含义即互联网工程任务组，它是一种国际民间自治组织，并没有强大的政府和企业在背后支持。它的主要工作就是制定互联网标准，如TCP、IP、HTTP等协议标准均尤其所制定。它分为很多方向（Area），例如路由、传输等，每个方向下由很多工作组（WorkingGroup）来承担。以上为各工作组最新的研究成果，如TLS1.3、WebRTC以及QUIC协议。

　　那么IETF是如何工作的？整个过程是通过RFC来实现的，它是一种经过大家讨论交流后进行归档的文档，也是一种不成文的规定，是不自称为标准的事实标准。

　　IETF每年开三次会，大家会就有关工作进行交流讨论。它是免费的组织，只要加入邮件列表就可以参与。David Clark曾提出一句名言：“我们拒绝国王、总统和投票，简单多数和可运行的代码就是我们的信仰。”

　　接下来介绍RFC的诞生过程，首先需要完成一篇稿子，稿子在经过讨论后可能被某工作组接受，称为Adoption，待成为工作组文稿后再进行讨论，经过大家一致同意后会进入一个Last Call的环节，相当于公示，公示后再经IESG审核通过就可以形成RFC。整个过程历时较长，可能要2到3年。

　　那么各国对RFC的贡献情况如何呢？目前全球有约9000个RFC，美国占到其中的三分之二。我国也在逐渐发力，贡献度达到了500多个。从某种角度上来说，我国确实是一个互联网大国，但还难说是互联网强国，我们还无法将优势推给其他人，让其他人按照我们的思路进行设计发展。

　　以上是每一届IETF的参会人数。很遗憾，和美国、欧洲相比Clash 的安卓版本，中国的参会人数还较少，参会人数整体上呈现美、欧、亚三足鼎立的趋势，美国尤其最强。

　　那么参与者的构成是什么，最主要是设备商，如思科、华为等企业，然后是互联网大厂，如谷歌、META等，剩下的是网络运营商和大学研究者。

　　那么参加这个会议有什么意义？第一是为了提高我国的国际影响力，既然谷歌、苹果、思科等大厂都在参与，那为什么不能是我们呢，我国在互联网领域并不落于人后。可能有人觉得不懂技术的人才去做标准，懂技术的人都在敲代码，实际当然并不是这样，如果没有核心的技术，自然也就没有可以作为标准的材料。其次，这不仅可以为国家和企业做出贡献，也有利于搭建自己的人脉，认识更多的新人，了解全新的技术标准。

　　那么如何参加呢？最简单就是到官网直接加入工作组mailing list来参与讨论交流。另一个方法是加入IETF的中国群，大家如果感兴趣可通过以上二维码来入群。

　　从2012年开始，谷歌对它的原型系统进行测试；13年开始在Chromium中进行进一步部署测试；14年开始，QUIC协议开始在YouTube等网站作为HTTPS的底层协议在谷歌进行部署；16年-21年QUIC工作组成立，相关工作在IETF上进行了大量讨论，最终发布了RFC9000，即正式的QUIC协议。 截至2017年，QUIC协议初展拳脚；2018年，IETF宣布，HTTP/3将弃用TCP协议，改用QUIC协议实现；2020年，华为也在自研的内核组件中推出了自己的QUIC，被称为hQUIC；2020年，Facebook宣布其超过75%的流量将使用QUIC协议，它的流行度未来有望进一步提升。

　　那么QUIC协议的优势是什么？QUIC的谐音代表了它高性能和快速迭代两种特性，它在基础上是TCP协议的拓展。

　　以上为QUIC与TCP的对比表，QUIC主要针对两个方向，首先是TCP协议的头部阻塞问题，前面的数据没传完，后面就不许传。这种情况在HTTP/2中尤为严重，虽然它使用一个TCP流代表很多HTTP流，但前面发生阻塞，后面就传不到。

　　其次是TCP的握手时间较长，尤其跟TLS1.2结合总是要重新握手。QUIC协议提出了一种更快的，不需要RTT即可握手成功的方法。基于TCP协议长年累月的积累，QUIC协议在此基础上创造了全新的体系，在IP协议之上，HTTP协议之下结合了安全的加密系统形成了如今QUIC协议的全新内容。

　　那么QUIC协议有什么意义，我们该如何看待它？从上面可以看到，有大量的公司都已经有了自己内部的QUIC协议，或多或少地构筑了自己的体系。QUIC协议以自己的全新生态带給互联网全新的可能，例如UDP over QUIC的出现。可以说QUIC协议有一统传输层的趋势，有大量的生态将基于它进行设计。

　　QUIC协议相关的研究方向也非常丰富，例如它的灵活性、它的多径、它的拥塞控制、它的QoE等等方向，以上在学术界也有相关的研究展示。可以看到，对于QUIC协议而言，它的优化空间很大，应用范围很广，并且使用场景多样。

　　到此为大家简单介绍了QUIC协议的定义，接下来介绍我们的工作成果，即被称为DTP的协议。它到底是什么？

　　从标题上看，它是一个QUIC协议的拓展，那么是如何拓展的？该协议的全称为Deadline-aware Transport Protocol，即时延敏感的传输协议。

　　它的使用场景为满足应用在截止时间之前完成块传输的需求。截止时间和块的定义都是什么呢？以观看直播为例，我们实际需要在短时间（如一秒钟）内完成视频画面传输，这个时延即为截止时间，假如超出这个时间，即使画面完成传输，对直播的效果影响也很大。而块相当于视频帧、控制信令，它是一个单独的，可控的并且可以单独使用的数据组件。

　　DTP协议通过使用截止时间和块的概念，联合应用提供的相关数据来使用网络提供对应服务，包括使用冗余编码来防止数据重传带来的时延。为了避免排队时延，采用一些全新的拥塞控制算法以及数据调度和丢弃的思路，使其内部不会自我进行拥塞。

　　结合这一系列的优化方法，相对于QUIC协议，DTP协议可以让数据预期的按时到达率提高最大约 10 倍。

　　我们进行了一些简单的数据层面的测试，发现DTP协议确实可以使高优先级数据的按时到达率明显提高，也可以使低优先级数据的到达率相对于QUIC协议而言大量提高。可以看到，在一些网络场景下针对平均数据的传输也可以得到明显的优化效果。

　　视频效果会更加直观，我们模拟了一个低轨卫星的链路场景，在如此场景下，相对于QUIC协议，DTP协议可以使卡顿更少，视频质量更高，传输时延更低。

　　下面来进行一个简单的总结，DTP协议和QUIC协议相比有什么优势？那便是时延更低，安全性和灵活性更高。但它的问题是它只是一个半可靠的传输协议，数据的到达率不稳定，有些数据可能会因为传输速率而进行一定的丢弃，它在适用的流媒体和弱网环境下传输可以展现出很明显的优化效果。

　　关于DTP协议我们做了若干工作，例如参加开源点亮计划，将它作为一个可供参与的开源项目给大家提供相关工作和服务；我们也在QUIC工作组进行了相关推广，发布了相关的draft；我们还在MoQ工作组进行了相关的讨论和推广，在MoQ将这种思路进行讨论和延伸。

　　针对DTP协议的其他应用方案我们也有一些自己的思路，首先要考虑的问题是应用可能难以随着协议的修改而改变，因此我们希望为应用提供一种更快捷的接入方式，现阶段思考了三种方法。第一种是采用API，第二种是搭建中间Proxy，用代理节点在维护现有传输逻辑的前提下接入全新协议，甚至可以通过某种网关设备让两端使用无感知的数据传输。

　　下面看第一个想法，我们在另一个国家重点研发项目中考虑，基于现有TCP的CDN系统可以在终端应用上使用DTP协议实现一些应用。然后在中间部署Proxy，将TCP和DTP的信令进行转换，使得原来的业务逻辑不会发生变化，只要前面部署一个代理应用，就可以保证业务逻辑持续正常的运行下去。

　　右侧视频是系统的测试结果，可以看到相对于QUIC协议，DTP协议可以得到10%～20%的时延优化，整个过程非常流畅，其中在CDN端仍然是TCP协议，另一侧是DTP协议，视频在限网中播放得非常流畅。

　　第二是隧道方案。假设有两个自治域（AS），我们不希望它们知道DTP协议的存在，那么是否通过可以部署某种网关设备，在中间使用某种DTP隧道来辅助两个自治域之间的数据传输。我们通过网关捕捉这个数据，通过某种方法使用DTP隧道传输到另一侧来保证服务质量。

　　我们在此进行了一个简陋的测试，该测试在TSN网络上进行，TSN网络上有若干设备，例如大家看到的灯泡，我们使用终端对灯泡进行一定操控。中间网络是带宽有波动，具有丢包率的不稳定网络，但是通过这种隧道方案就可以在这种具有大量波动，不可靠的网络上提供更好的服务质量保障，以上是我们关于无感知接入所做的一种尝试。

　　另一个尝试就是端网结合，它的意义是什么？这个想法听起来好像不是非常的计算机，尤其不是非常的计算机网络，端侧搞端侧的事情，网络侧搞网络侧的事情当然最好。但只靠端侧处理难以掌握网络的具体情况，无论探测得再好，设备哪儿排队了，要转发什么，我们无法得知。网络侧最大的问题就是它不能适应应用的需求。 于是我们考虑能否通过传递应用的需求，利用传输协议提供给网络的设备，用例如SDWAN和传输协议结合的方法将网络设备与端侧设备进行结合，得到更好的优化效果。

　　我们考虑了两种优化方法，第一是差异化转发，首先利用DTP协议在端侧进行流量优化整形，将乱序数据依据优先级重要性进行调度。整形后通过通知中间节点使高优先级数据利用某条更加空旷、高效的道路得到优先转发服务。

　　以上为测试结果，图中蓝色线条代表高优先级数据按时到达率，黄色线条代表低优先级数据按时到达率。可以看到，在只使用端侧优化的情况下，两者的按时到达率会有明显下降。采用端网协同方式便可使两者服务质量得到明显的提升和保障。原因是我们可以更好地分配链路的带宽资源，使高低优先级数据之间不会互相抢占。从而得到更高的优化效果。

　　那么假如将这种差异化端网结合的思路放到路由器上呢？我们也进行了相应尝试，例如使用差异化路由使高低优先级数据通过不同链路进行传输，选择不同路由方式来适配应用需求。

　　以上为测试结果，可以看到最终可以得到更好的传输效果。当然该方法目前仅用作学术讨论，在实际场景下能否适用还有待商榷。

　　在开发过程中发生了一些小故事在此想和大家进行分享，首先我们发现有时换个版本将代码更新一下，即可获得二十倍的传输效率提升。老版本可能跑出100Mbps就到头了，而换个版本可能瞬间即到达1Gbps速度。

　　但老版本可能早已搭建了很大的系统架构，代码难以说改就改。在这个问题上我们按并行思路来考虑，需要功能就使用老版本，需要性能就用新版本，一点一点迁移，不要让历史成为包袱，而是要成为优势。虽然我们了解原来的代码，但为了得到新功能，必须要向前迈进。

　　另一个小故事就是关于公平性分析。在此强调一下，TCP、UDP是写在Kernel里，要修改就需要改动Kernel的操统代码。QUIC协议是基于UDP的用户态的协议，它支持任意修改。这会带来公平性的问题，例如Zoom、Meet等应用都存在协议公平性的问题。

　　图中的研究成果主要介绍了Zoom、Meet这些应用在带宽抢占上的表现，结论是它们（尤其是Zoom）拥有更强的抢占性，使得整体表现并不够公平，当然国内的一些软件也存在同样的问题。虽然以QUIC为代表的用户态的协议为用户提供了强大的自定义能力，不过我们仍然需要保护网络环境，不能把网络变得更差更拥塞。

　　接下来是未来展望环节，刚才谈到了IETF组织；谈到了怎样把基于UDP的拥有全新特性的QUIC协议逐渐变成未来的新可能、新基石；介绍了DTP协议，基于QUIC协议如何采用调度冗余和丢弃的思路使流媒体传输效果更好。

　　那么未来可以利用这些成果做什么呢？首先要介绍近期刚刚成立的Media over QUIC工作组，以上四点总结是该工作组成立时最初的愿景，一是关注媒体传输的时延与交互性之间的差异问题，例如连麦因为交互非常高，要求时延必须非常低，而普通的直播场景也许等个十秒都无所谓，针对不同应用有不同需求。

　　Media over QUIC聚焦的核心场景就是低时延媒体传输场景，像点播这种对时延要求不高的场景不在其考虑范围内。工作组提出的Media over QUIC架构可以支持多种不同的媒体格式，用QUIC或WebTransport等下层支持来完成多种低时延的媒体传输，并且允许有全新的加密方法，中间Relay的处理等等全新的工作。

　　我们来看看它的整体结构，它针对上层主要提供了一种媒体分发方案，包括上传、下载、编解码同步等等。这里说的媒体即低时延的媒体传输，例如直播、互动、远程桌面等。对下层则基本上是使用QUIC或HTTP/3的WebTransport接口进行传输。对中间设备它们会使用接力节点并基于Media over QUIC的思路和逻辑对数据进行转发处理。

　　由于详解所需的时间太长，所以在此就他们的设计方向我为大家做一个简单总结。首先关于传输特征分为以上三类问题，一是视频和控制信息是否可靠，我们需要考虑到数据传输的可靠性来决定是使用Message还是Quick Stream传输。第二是与媒体信息的强结合性，Media over QUIC工作组和Codec工作组的工作交流相当密切，如何联系这些内容进行工作也是重点内容之一。然后就是如何提供灵活的中间设备支持，使中间设备更加智能，更加适配Media over QUIC的工作思路。

　　接下来是一系列基本上已经在不同实践方案中使用的优化策略，例如针对不可靠传输使用QUIC的datagram来进行，或是为了节约带宽丢弃中间传输的数据帧，除此之外还有很多类似的优化思路；其次数据帧的抽象在工作中也非常关键，它在Media over QUIC工作组中被称作object；然后是使用一些合适的重传与冗余策略来防止时延的增加；最后是通过在接力节点中允许一些调度和缓存的思路来节约传输时间。

　　接下来我们看看未来还有哪些工作要做。例如解码器怎么用，迁移会话是不是要做，能否对特定时延范围进行特定优化，对接力节点又应有什么策略？

　　第一个问题是关于CDN的拓补设计，右图是一个关于Media over QUIC Relay和CDN设计空间的draft。它有不同的拓补结构，第一种是最朴素的树状结构，从发布者到订阅者之间按树状传输。除此之外也可以使用其他方式，例如使用mesh的Relay，在中间用一些中央控制节点使数据之间可以自由交换，这类似于覆盖网络的思路。可以决定用哪些Relay来传输数据也类似于阿里Livenet的思路。

　　第二个问题就是媒体元数据要放在哪里，以上问题虽然看起来都比较trivial，但实际上是标准制定的关键，你要告诉大家你要做点儿什么，大家要怎么做。既然他们还不知道，我们也可以上去提提意见。

　　下一个问题是为什么要做MoQ，首先工作组的前景是有望使MoQ作为RTP的代替品成为下一代流媒体的传输协议。

　　我和工作组交流了他们对未来的愿景，工作组说现在很多在线的视频用的是WebRTC。如果有一个直播场景，WebRTC写一个，又来一个在线会议场景，WebRTC又需要重新写一个。怎么办，那么应该有一种统一的分发低时延媒体的协议，来作为某种统一的基石。

　　目前有很多大厂（苹果、思科、Twitch、Meta等）都在推进相关的标准化工作，我们希望能有更多的中国公司带来一些奇招妙招。然后也有大量业界大佬重点关注这方面工作。在这里简单介绍一下Ted Hardie，他之前是WebRTC的主席，现在跳到了MoQ工作组。可见WebRTC已经难以满足当下大众的需求。其他著名人士基本都来自IAB，IAB是IETF上最聪明的决策者团体，可谓是一人之下万人之上。

　　接下来进行一个简单的总结，MoQ的整体设计思路就是针对流媒体低时延的传输协议，它的核心优化场景是面向直播这样对时延有一定要求的场景。它有多样的优化策略，未来也有大量的可以供大家进行设计和讨论的空间。众多大厂和业界大佬也在关注这方面工作，我们也在努力做一些事情，发布了一些draft。同时也欢迎大家加入邮件列表来讨论，看看大家对此有什么样的思路。本页下方有邮件列表的订阅方法，大家如果感兴趣可以关注一下。

　　接下来是最后的展望，目前QUIC的生态系统有两大发展方向，第一大方向是QUIC+，通过刚才我们可以了解到QUIC协议是非常棒的用户态协议，支持任意修改，QUIC+是关于如何向QUIC增加我们特定的需求，例如不可靠传输、优先级调度等等。它大量的优化方向代表它具备大量迭代和优化的可能。例如我们完成了DTP，阿里团队做了XLINK，基于QUIC的协议设计已经成为我们探索的一大方向。

　　第二就是我们怎么站在它的肩膀上进一步发展，刚才提到QUIC有一统传输层的趋势，并且已经可以看到万物over QUIC的前景，现在出现了DNS over QUIC、RTP over QUIC、QUIC Proxy（类似于UDP over QUIC）、Media over QUIC等，接下来会有什么？是否会有CDN基于QUIC的变化？路由、资源搜寻、内部结构等在未来也可能通通会发生变化。底层原本是TCP和UDP，未来在UDP之上又有一层QUIC来帮助我们实现全新的目标，那么未来可以利用它做些什么，这是现在值得思考的事情。

　　接下来是最后的总结，刚才我们看到了IETF组织的发展流程，了解了IETF在传输协议层面上如何从TCP转到QUIC，使QUIC协议成为了现在的标准。而后我为大家介绍了DTP协议的内容，展示了未来的一些思路，包括MoQ以及QUIC新生态的介绍。

　　在此我想说，在大厂工作的各位相对于我一定会更加了解用户需求，那么关键就是如何把历史经验作为自己的力量，把握用户需求开发全新内容。希望大家可以尝试在QUIC协议的基础上完成一些新的成果，站在巨人的肩膀上为自己和未来创造一些发展空间。

　　文章出处：【微信号：livevideostack，微信公众号：LiveVideoStack】欢迎添加关注！文章转载请注明出处。

　　日前，来自佐思汽研的《2024年全球及中国电子后视镜行业研究报告》新鲜出炉。 数据显示，2024年1-4月，

　　后视镜市场份额连续6年称霸全国，新产品即将上市 /

　　实时数据流的服务器软件，广泛用于视频直播、视频会议、音频播放等应用场景。在嵌入式开发领域，将

　　服务器 /

　　是一个复杂的过程，涉及到许多因素和原则。 1. 引言 电源是电子系统中不可或缺的组成部分，它为系统提供所需的电能。电源的空载电压是指在没有负载的情况下，电源输出的电压值。空载电压

　　服务MX Player达成了一项引人注目的收购协议。据悉，亚马逊将收购MX Player的部分资产，而此次交易的估值不到1亿美元，远低于市场对该公司的预期。

　　后视镜搭载联发科MT6761处理器，采用12nm工艺制造，集成四核A53 CPU主频达2.0GHz。这一高速处理器确保了后视镜的快速响应和顺畅运行，画面质量不打折，无论白天黑夜都能清晰捕捉影像。

　　云镜_行车记录仪主板方案定制 /

　　中起着核心作用，主要表现在以下几个方面： 1. 视频和音频编码：编解码一体机能够对视频和音频数据进行高效的编码，将原始的多

　　中的核心作用 /

　　优化效果明显。以直播业务为例，使用同一服务器，推两路1M码率的直播流到同一边缘节点，在丢包20%的情况下，

　　的技术方案实践 /

　　的影响 /

　　一、UDP的特性与应用场景 采用UDP有3个关键点： 网络带宽需求较小，而实时性要求高 大部分应用无需维持连接 需要低功耗 应用场景： 网页浏览：新浪微博就已经用了

　　混合式步进电机驱动器的供电电源电压一般是一个较宽的范围（比如IM483的供电电压为12～48VDC），电源电压通常根据电机的工作转速和响应要求来选择。如果电机工作转速

　　专利侵权 10月31日诺基亚在美国特拉华州联邦地区法院提起诉讼，诺基亚认为亚马逊和惠普侵权了多项视频

　　时基是指一种标准时间的参考信号，它是通过一些精密的时钟或震荡器产生的。在电子测量和控制过程中，时基是非常重要的，因为它可以确保系统中不同时间