Media over QUIC Transport（MOQT）协议概览-低时延可扩展的实时媒体流传输协议

这是一个短视频，实时视频，视频会议的时代。在日常生活中，无论是工作场景，娱乐还是日常沟通大家都频繁使用了视频的形式来进行沟通。用户的需求量在不断增加，而且要求更稳定，高质量的服务，这对服务提供商提出了一个非常大的挑战，如何实现低延时和让服务架构具备良好的弹性是服务提供商一直想解决的问题。这些问题的解决可能需要从技术底层来重新构建。为了解决传输的问题，目前很多大厂已经在尝试使用QUIC协议。

视频服务的业务随着微软teams，思科的Webex和Zoom的兴起，用户可以快速实现视频的支持，也取得了比较好的，低延时的视频质量。但是，这些服务保证都基于服务提供商能够不断投入其基础架构的扩展来实现的，其投入产出比存在很大问题，最终不能实现一个高性价比的解决方案。通过不断地实践，最终因为大厂的支持，大家推荐的新技术架构是通过 Media Over QUIC Transport (MOQT)来实现。其中，思科负责安全和协同产品的CEO Cullen Fluffy Jennings对MOQT给予了很高的评价，他本人也积极参与了MOQT草案的制定。因为他的参与，看来这个草案和其技术最终可能会成为新的行业技术规范。下面，我们根据目前的一些关于MOQT的技术讨论为大家梳理一下关于MOQT的相关概念和技术细节。

Media over QUIC Transport（MOQT）协议概览-低时延可扩展的实时媒体流传输协议

关于MOQT和MoQ背景说明

现在我们首先了解一下关于MOQT的概念。根据草案的声明，MOQT是一种优化的协议来支持QUIC协议，它通过直接或者WebTransport方式对媒体进行分发处理。MOQT使用了publish/subscribe（发布/订阅模式）工作模式在媒体发布方发布数据，通过多端点订阅的模式协议请求的方式获取媒体。MOQT支持了多种应用场景，在不影响传输内容的基础上，实现弹性扩展和时延需求。这种处理方式基本上属于SFU的处理方式，因此和MCU方式有着非常大的不同。如果读者不了解关于SFU和MCU的处理方式，建议阅读以下链接文章：

关于开源WebRTC视频会议服务器性能以及测试据分享

媒体发布订阅协议支持了多媒体格式，不同媒体兼容性支持，可根据修改的编码速率或已选的媒体解码/质量支持可调整的速率策略，友好的缓存机制。为了实现低延时，高质量媒体，此协议通过转发机制来配合工作，通过缓存机制存储已接收的媒体数据，然后根据需要分发到其它端点。

在媒体加密方面，因为MoQ是基于QUIC协议，因此所有收发媒体都可以通过传输层使用QUIC加密，也满足支持了端对端的加密。其实时传输媒体流的技术架构借鉴了RTP传输协议，在扩展能力支持方面HLS/DASH和HTTP的CDNs。订阅用户仅通过命名的数据对需要的数据进行订阅，然后通过缓存机制来存储分发到订阅用户，突出了其灵活性，订阅方式不仅仅满足了媒体数据的收发，也支持了互联网上的其它数据的收发功能。

接下来我们看看MoQ是如何工作。和传统的传输方式不同的是，MoQ传输充分利用了云服务商和CDN传输架构。发布者通过云服务商然后再通过CDN网络传输到ISP服务商，最后到家庭用户的接收终端。

在传输过程中，数据丢失是不可避免的。为了解决数据包的丢失，用户媒体流应用端将要求服务提供商重新发送请求来保证数据的完整性。所有请求都通过CDN路径进行传输。在传输过程中，时延也是不可避免的，为了解决时延问题，在通过多层传输转发时，数据将被复制存储，如果发现数据有丢包，可以从最近转发中获取丢失的数据包，而不需要重新从远端发送请求。MoQ支持了错误还原机制，通过近距离转发存储数据包重新整合，降低了丢包和时延，同时降低了带宽使用量和网络消耗。MoQ可以支持多种媒体流传输功能。三大亮点值得我们关注。

首先，MoQ可以支持一个媒体备份进行上百次的分发处理，不需要将上百次的媒体备份通过网络进行传输。例如在实时的会议中，MoQ通过转发形式实现了同一会议，同一用户群体，仅执行一次媒体备份的转发，抵达所有终端用户。如果不使用MoQ存储转发的话，在一般的实时会议中，需要多同一会议内容对所有用户终端进行分发，这样就会增加太多的网络数据流量，消耗太多的网络带宽。

其次，基于MoQ传输可以支持媒体内容的端对端加密处理。

最后，MoQ提供了一个解决方案支持不同应用要求的时延处理，实现了时延可调整的策略设置。一些用户是WebRTC用户，另外一些用户可能是视频点播用户。这些用户对时延的要求是不同的。WebRTC用户是针对用户端回放进行的优化处理，但是针对点播回放用户来说，如果不能进行时延调整的话，点播用户会生成大量的时延。目前，MoQ支持了三种场景中时延的处理，包括实时场景，互动场景和点播场景的时延支持。

技术创新的第一推动力来源于商业。MoQ同样如此。通过MoQ的使用，两个目前蓬勃发展的行业将会受益。一个是实时协同软件工具，例如ZOOM，微软的Teams，Webex等。另外一个行业是实时媒体流直播。这两个行业在传输方面都面临差不多同样的问题和诉求。实时协同工具需要低时延，高质量和更广泛的传播触达方式。实时直播的需要更低时延的互动的沟通，同时能够支持更灵活的扩展能力。MoQ比较完美地满足了以上两个行业的需求，同时CDN技术也很好支持了MoQ传输技术。当然，MoQ还支持了其它几种比较热门的用户场景，包括IOT监控，推送提醒，5G网络中MoQ支持和文本消息协议支持。

关于MoQ传输方式的讨论

关于发布MoQ的目的，MoQ传输方式得益于某些技术的成熟和发展。首先基于对媒体传输非常友好的QUIC协议的使用。另外， HTTP Adaptive Streaming (HAS-基于HTTP的动态自适应流)，使得高质量流媒体流可以通过传统的HTTP网络服务器进行传输。因为无论是TCP或者UDP都是基于数据传输时代设计的协议框架，所以基于TCP或者UDP传输都各自有其挑战，或者存在拥塞检测不及时的问题，或者重新数据包重打包，重新传输时延等问题。MoQ最终目标是解决TCP或者UDP传输所面临的一些挑战。另外，MoQ的使用具有普遍性和通用性。最后，转发机制实现了扩展性支持，方便媒体流服务扩展。

关于技术架构方面，在MoQT的草案中定义了层级结构的对象object模式，这种模式支持data，object构建，组和组路径。object由两个部分组成，一部分是metadata，此部分数据是看见的，从来不加密，相对于转发实体来说是可见的。另外一部分是payload（有效载荷），此部分可以是加密的。

MoQ定义了一种协议来实现内部交互实现，提供了会话创建支持，支持了通过QUIC直接连接支持和WebTransport支持。其中，关于QUIC服务器访问的语法如下：

moq-URI = "moq" "://" authority path-abempty [ "?" query ]

QUIC客户端通过以上URL地址访问服务器端。会话初始是通过打开第一个媒体流，通过客户端双向控制媒体流，通过远端端点创建交互消息。会话取消可以通过发送方或者接收方来控制。如果结束会话是通过QUIC来实现的，会话结束是通过 CONNECTION_CLOSE frame（参考QUIC-section19）来实现。如果结束会话是使用的WebTransport的话，结束会话通过CLOSE_WEBTRANSPORT_SESSION capsule（参考WebTransport-section 5 ）来实现。MoQ定义的错误码如下：

MoQ定义了优先级和拥塞响应处理。在优先级处理中定义了优先级顺序和拥塞处理的算法等，

MoQ定义了转发的处理机制来支持服务的扩展。转发机制包括了订阅方交互和发布方交互，转发时的拥塞响应处理和转发的object处理。

无论是单向还是双向媒体流都长度限定的消息顺序。如果终端收到了未知消息类型的消息必须关闭这个会话。MOQT消息原型如下：


MOQT Message {
  Message Type (i),
  Message Payload (..),
}

其消息参数格式如下：

Parameter {
  Parameter Type (i),
  Parameter Length (i),
  Parameter Value (..),
}

MOQT客户端和服务器端消息创建流程如下：


CLIENT_SETUP Message Payload {
  Number of Supported Versions (i),
  Supported Version (i) ...,
  Number of Parameters (i) ...,
  Setup Parameters (..) ...,
}

SERVER_SETUP Message Payload {
  Selected Version (i),
  Number of Parameters (i) ...,
  Setup Parameters (..) ...,
}

消息创建ROLE参数定义如下：


0x01:
Only the client is expected to send objects on the connection. This is commonly referred to as the ingestion case.

0x02:
Only the server is expected to send objects on the connection. This is commonly referred to as the delivery case.

0x03:
Both the client and the server are expected to send objects.

MoQ还定义了Object，这是MoQ消息中object的核心格式。一个object消息包含了指定track中持续的byte数据范围，以及其关联的metadata，这些数据是传输，缓存处理和转发时需要的必要数据。MoQ还专门定义了订阅方的处理机制。订阅方从发布方接收订阅。在订阅方的定义中包括了订阅方定位，订阅格式和订阅状态。其中，订阅状态包括了十种状态，比较常见的有订阅成功，订阅错误，未订阅，订阅重启，订阅完成，订阅声明，订阅声明错误等。以下是一个订阅成功的处理格式：


SUBSCRIBE_OK
{
  Subscribe ID (i),
  Expires (i)
}

重新订阅的格式：

SUBSCRIBE_RST Message {
  Subscribe ID (i),
  Error Code (i),
  Reason Phrase (b),
  Final Group (i),
  Final Object (i),
}

关于MoQ订阅的定义，建议读者参考草案-section 6进行深入了解。笔者不再做太多解释。最后，MoQ草案中还讨论了关于安全方面的挑战，不过此部分内容未做太多讨论。

总结

在本文章中讨论了关于MoQ的背景介绍和关于MOQT的草案的第二版本。MoQ是技术发展的产物，为了更好适应实时互动媒体流的用户场景，结合CDN技术实现的低时延，可扩展的传输架构。虽然草案的初稿仍然在讨论中，但是，目前一些大厂已经在部署MoQ传输技术，并且也有很多的成功案例。通过目前几个大厂的推动，MoQ是目前除了TCP，UDP传输之外比较完美地解决传输问题的主要方法。希望在不久的将来，我们能够看到MOQT正式成为一个新的传输协议规范。

参考资料：

https://www.ietf.org/archive/id/draft-ietf-moq-transport-02.html

https://quic.video/

www.sip.org.cn

https://www.ietf.org/archive/id/draft-ietf-moq-transport-02.html

https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3-08