对等网络实时音视频通信技术框架及应用实践

编者按： 摄像头是物联网世界的眼睛，拥有体积小且节能的特征，而视频监控一直是跟音视频紧密结合的领域，同时成本控制要求严苛。传统的视频监控解决方案陈旧且复杂，不能满足灵活访问控制的要求，在视频大时代的背景下，如何才能适应日益增长的需求呢？摄像头虽小，但对音视频秒开、低延迟的要求却一点都不低；随着 RTC 的日渐普及，大家对其了解逐渐深入，会发现并不是只有 WebRTC 才拥有这个特性。本次分享将回顾视频大时代的发展脉络，介绍 P2P 网络架构的协议扩展，并结合 RTC 理论，探索在 IoT 视频监控领域上的应用落地实践。

文 / 张鹏

整理 / LiveVideoStack

大家好，我是张鹏，我来分享一下，对等网络在物联网上的应用，已经成功应用到消费级家用摄像头、智能门铃 / 门锁等产品。这次分享主要有 3 个部分，介绍、高效传输、总结，将重点分享我们结合对等网络如何在物联网上做到极致体验的。

1、Introduction

在此之前，先介绍一些概念。

首先就是一个网络拓扑，其实 P2P 算是音视频领域的一个老朋友了，两年前我在 LiveVideoStackCon 分享过一次，但当时 P2P 主要是是用来节省带宽，放在现在的环境里依然适用，帮助企业降本增效。那 P2P 是什么呢？现在流行的 Web3，它的底层网络就是 P2P，所以 P2P 的应用场景不仅仅是节省带宽那么简单，还有很多场景是可以发挥。我今天分享的就是 P2P 在 IoT 场景的应用。

再说物联网，这个概念已经提出好多年了，但大家对物联网的规模可能还不太了解。举个例子对比一下，微信已经有十亿的用户了，但物联网的规模是上百亿的，这里面的增长性是很好的，到处都充满机会。而腾讯又是专注于连接的一家公司，之前是连接人与人、人与服务，连接线上和线下，现在我们把这个连接扩展到连接人与物、设备与设备，把这个连接做得更彻底。

IoT 行业很大，今天分享的主要是在 IoT Video 行业，跟 LiveVideoStackCon 音视频技术大会的主题也非常相关。上图都是一些摄像头设备，大家对摄像头应该不陌生，可能已经买了一些摄像头在家里做监控。摄像头是整个物联网世界的眼睛，它非常重要，现在有些新兴的行业，比如做机器人的，已经把音视频作为基础，在此之上做智能化。别小看这些摄像头，它的要求丝毫不亚于常规直播，如智慧门铃、智慧门锁这些，都要求延迟要在 1 秒以内且要丝滑流畅，但这些设备和我们手机相比，无论是算力还是网络都差远了，而且对里面能安装的软件要求非常苛刻，都是很底层的接入方式。在这基础上，还要做到低成本、低延迟、秒出图，挑战是非常大的。

2、Effective Communication

接下来分享一下，我们是在 IoT 上如何做到音视频的极致体验优化的。

首先是 P2P，之所以选择 P2P，考虑的依然是隐私和成本，因为 IoT 非常注重隐私，同时客户的成本诉求也很强烈，P2P 打洞成功率越高，就越能节省成本，而 RFC 中的 NAT 划分、ICE 的打洞方式相对比较古老，在国内的打洞成功率并不高。而腾讯的 P2P 依托 QQ、旋风下载、QQ 影音、腾讯视频、微信等积累，能把打洞成功做到大于 80% 的水平，像端口预测、生日攻击这些技术，应有尽有，打洞握手耗时仅 200ms。

P2P 打洞是一个很好的 P2P 入门技术，它很有技巧性，你了解了以后会猛然发现，网络原来还可以这样玩。比如 TCP 打洞，学过计算机网络的同学可能知道，有一种 TCP 四次握手机制，两边同时去发 SYN 主动连接。在工作的几年里，我始终没见到哪儿会用到这种握手，甚至网络上都要搜不到相关资料了。后来才发现，原来是在 TCP 打洞时会用到这种技术，两方都是直接连对方，心中一阵暗暗称奇。

打洞之后，就是传输了，节点可以相互去直连传输通信，但如果不受控制的传输，是万万不行的，所以必须要有传输速率控制，流量控制等。早期 P2P 为什么它的名声比较差，一方面它传输的内容侵犯了版权，另一方面是它无情地抢占了带宽资源，把网络搞得很拥挤，给运营商治理网络造成了很大的困扰，运营商索性就把它封杀了。P2P 之前是这样一个状态，但这是不对的，打洞成功后，一定不能疯狂地发数据，干这种傻事，而是要和所有其他传输协议一样，友好、公平地一起利用好网络。

我们自主研发的传输协议 ETC，则是将 Pacing 和 Burst 相结合，因为它们单独来讲都有各自的优缺点，ETC 则是综合这两者的优点，抑制它们彼此的缺点，最终得到了一个能最大程度利用带宽，延迟低，反应快，友好、公平的效果。如右图所示，在 100M 的链路空间内，1 个流的时候要利用到 100M，2 个流的时候每个 50M，5 个流时每个 20M，利用率很高。反应灵敏，带宽调整收敛速度快，相比慢启动而言能一下子利用到 100M，2 个流的时候，一下子各自带宽调整到 50M，很公平。因为网络是实时变化的，这一刻可能 5 个流，每个 20M，下一刻可能就是剩下 4 道流每条 25M，这种就是要能做到立刻感知，也就是不停地探测、调整，传输协议最好的办法就是不停地向上探测一下有没有可用带宽，超过了就向下调整一下，以打水漂的方式来回探测，而且在稳定态这个打水飘探测的幅度越小越好，这块 ETC 做得相当不错。

有了 P2P 和传输之后，接下来要解决低延迟、秒出图的需求。这里有个前辈 WebRTC，它也有 P2P 和传输，又和音视频结合，很值得借鉴。

这里想先和大家探讨下，WebRTC 是怎么做到低延迟的？我之前听到最多的一句回答，就是使用了 UDP，但 UDP 和低延迟还差了十万八千里。也有常见回答说因为使用了 P2P，两个节点直连或许会更好一点，比如在同一个内网下，但也有时候可能还没经过公网转发时效果好。

如果对 WebRTC 了解更深刻一点，可能会回答说，因为使用了 RTP/RTCP，或者是因为 WebRTC 有内置 TCC 传输控制，这是比较好一点的答案了。

如果再对 WebRTC 更了解一点的话，会回答说是因为 WebRTC 有非常优秀的 jitter buffer 管理，这已经接近标准答案了，但大家对 jitter buffer 可能还是只知概念，不知具体怎么管理的，觉得 jitter buffer 是不是播放器的缓冲区少了就把它给拉长慢放，缓冲区多了就快进一些，跳帧追帧，然后是不是就实现低延迟了？那是不是把 jitter buffer 策略挪到 TCP 上实现，TCP 上也能实现低延迟了呢？带着这些疑问，我们继续向下深究。

我们整个行业，把低延迟的大部分精力放在两个方向上，第一个是编解码，如何能更快地编码出帧来发送给对方；第二个就是去搞传输协议，认为低延迟和传输协议很相关。其实我们前面做的直连、P2P、传输协议都已经很优秀了，但距离低延迟依然有一定差距，为什么呢？编解码是有一定作用，可是现在编码性能已经很高，基本都是硬件加速，编码出一帧只需要几毫秒小几十毫秒，对 1 秒 2 秒的延迟占比很小，它并不构成延迟的主要成因。

要探讨这个问题，就要老生常谈延迟到底发生在什么地方。如图所示，延迟可能发生在编码、采集、前处理、端到端延时、解码、后处理等，这里像编码、采集、前处理、后处理都是硬件控制的，对延迟不苛刻到百毫米以内的话，编解码和网络时延的占比对延迟的影响微乎其微，基本就是 10 毫秒量级。距离的影响也不大，虽然深圳到北京肯定要比上海到北京要慢，但基本上也都是 30 毫秒一个 RTT，差不太多。那这里面是什么造成了延迟，我们能控制的又是什么呢？一个是 GOP 的长度，另一个就是大家经常忽略的全链路的缓冲时长，这个才是重点，最值得关注。

从 GOP 入手降低延迟，比较典型的就是 HLS 和 LL-HLS。直接降低 GOP 长度，把 TS 切片从 10s 降低到 2s。但这有一点问题，GOP 短了，会影响压缩效率，所以 GOP 肯定还是大于 2s，那还是有平均 1s 的延迟解决不了。

从缓冲区入手降低延迟，经常的做法就是如果播放器缓冲区变长，那就快进，两年前我和一个同事还聊到，标准直播能不能做到低延迟的程度，当时的结论是可以，配合播放器，播放器如果有缓冲，就去快进，就能实现低延迟，但很少有播放器做这个策略，我们的视立方有做，大家可以试用一下，其实绝大部分情况下也都能满足。但做了这个之后，有些场景下的延迟效果依然不尽人意，为什么呢？因为忽略了发送侧的发送缓冲区！

如果把 WebRTC 的 jitter buffer 放到 TCP 上去实现的话，TCP 依然做不到低延迟。因为 TCP 发送端有一个内核里的发送缓冲区，当网络变差时，发送缓冲区会先填满，应用层却控制不了，因为在内核里面。此时，应用层还不知道发送缓冲区已经拥堵了，之后发送缓冲区会被填满，无法写进，这时应用层的才能感知到，网络拥堵了，要开始应对了，但这时已经晚了。TCP 就是这种，感受网络的变化太晚了，而且应用层对发送缓冲区内的数据无能为力。

可以看到，产生延迟的另一个重要原因是在发送端的缓冲区，这是播放器快进追帧策略鞭长莫及的。再对比一下 RTP 和 RTCP 的是如何解决这个问题的，RTP 和 RTCP 配合 WebRTC 的传输从根本上而言是让传输和音视频的特性紧密的结合起来，来实现的低延迟。当对端发现网络卡的时候，它会通过 RTCP 立即告诉发送端，网络差了，数据少发些，因为这时网络资源变得紧缺了，然而少发哪些数据也是有讲究的，不是说把这 1s 的后半秒全都丢了，而是均匀地去丢才好，先把均匀地丢 B 帧，再是均匀地丢 P 帧，它需要发送端配合做一些决策，或者更直接地降低码率，让数据依然能均匀地发送到对端。

总结一下就是，全链路缓冲区管理防积压，网络不足时主动减，减有降码率和降帧率两种方法，我们在做物联网时，端到端各项参数都由我们控制，比如帧率 40fps，网络变差了，我们可以让发送端直接变成 20fps。其他场景下，直播可以利用 SVC 编码，不断地能把 B 帧 P 帧优先丢掉，均匀地去丢帧，也能把帧率降下来。关键还要及时反馈，像 RTCP 一旦网络变差，可以马上传送给接受端，TCP 的弱点就在不能马上反馈给发送端，RTCP 就可以根据视频帧级别的去反馈，jitter buffer 机制的核心就在这里。

现在知道了低延迟是怎么做的了，那如何扩展到非 WebRTC 场景呢？这里面有几个难点。第一个在于发送缓冲区有多少数据未发送，其实发送端丝毫不知情，但这里面可能积压有数秒的数据了，造成的延迟已经很高了。第二个难点是播放端要有一个及时反馈的通道，这个通道大部分直播方案是没有的，唯一的解法，好像只有通过将音视频的特性和传输协议相结合的 RTP。RTP/RTCP 将网络传输与音视频特性相结合的思路是好的，但很多传输协议却又是分层的，设计时并不替音视频应用特性考虑。这里也借此纠正一个误区，前段时间遇到个说法 RTMP/HTTP-Flv 等这些都是传输层的，其实并不是，他们都是应用层的，比如 RMTP 就感知不到 TCP 的缓冲区积压了多少。

以上 2 个难点不好解决，但也并非毫无办法，主要思路便是通过应用层接管缓冲区管理。可以在应用层建立自己的帧级别的队列，接收端收到一个帧就要向发送端反馈一个 Ack，此 Ack 非传输层的 Ack，而是应用层自己的，这样就能越过传输层，令发送端能感知到发送缓冲区里的帧数据是否已经传输过去。

更具体一点，首先把发送缓冲区设置足够小，接收缓冲区一有数据就马上读出来。然后，作为直播应用层协议的 HTTP GET 请求，是没有及时反馈通道的；但变成 POST 请求，POST 请求带请求体的，就可以让 POST 请求每解析完一帧，就在请求体中写一行在什么时间点收到了一帧，帧的 pts 是多少，播放器的 buffer 多少，这样就建立起了一个反馈通道。这个反馈通道完全是应用层的，可以告诉服务器（发送端)，让服务器及时调整。最后，因为发送端并没有把很多数据写给发送缓冲区，相当于应用层接管了待发送数据的管理权，所以当网络变差，发送端就可以根据 POST 请求的反馈去降帧率 / 码率，这样就能够实现低延迟了。

回顾一下直播兴起的历程，其实直播的兴起离不开 HTTP。整个音视频里有很多协议，这无形中增加了大家进入音视频行业的门槛，而 Web 能发展如此迅速，就是因为它只有一个大家都耳熟能详的 HTTP 协议。直播兴起的时候，恰逢 HTTP-FLv、HLS 和 DASH 的出现，他们有很明显的特征，就是都是 HTTP 的，因此能很方便的被接入到互联网的任何一个角落，比如浏览器，使用 HTTP 发送请求，就非常 easy，但如果你让浏览器 RTMP 去拉一个直播流就会非常麻烦。像 IoT 这个行业，它的协议簇也非常繁杂，但我们觉得如果要把 IoT Video 进一步扩展到互联网每个角落，都统一收敛到一个 HTTP 的话，在 HTTP 上又能实现低延迟、低成本、好效果，那无疑是能让很多人更快进入这个领域。

所以我们整个架构是这样的，底层利用了 IP/IPv6、ICMP、UDP，再做了一层 P2P，在之上的传输层，实现了高效可靠传输，再上面实现了应用层协议 HTTP，支撑各种各样的应用场景。这样的架构最大的好处，就是分层清晰，对开发者很友好，大家都懂 HTTP，但如果是 WebRTC 这么复杂的东西，想必大家会感到很头痛。

这样我们做音视频摄像头的场景支持起来就非常的简单，比如摄像头是简单的 HTTP 直播源服务器，手机便是 HTTP 直播客户端，可以向服务器发起请求。不仅适用于 1v1 还适用于 1v 多，多人观看摄像头搭配 P2P 的方式。在效果上，使用前文讲的低延迟之道，延迟也能做到很低。实现低延迟并不一定非要直接采用 WebRTC，更好的方式是把 WebRTC 的理念思想，给学习过来，应用到我们所需的场景中，把它的复杂度降低，才能促进产业的繁荣。

与 WebRTC 相比，WebRTC 的 P2P 是标准的 ICE，在国内的环境里成功率没那么高，成本高，WebRTC 也更复杂、更耗 CPU，在 IoT 去集成它是很难的，IoT 本来可用的存储空间都已经非常小，把 WebRTC 弄进去更难，所以它行不通。我们这个则是轻量级的，打洞成功率又高，又通过全链路缓冲区管控实现了很低的延迟，接入也非常简单，只要懂 HTTP 协议，就可以轻松地理解使用。

3、Summary

最后总结一下。首先是低延迟之道，这张图可以帮大家回答低延迟的关键步骤，除了很快的编解码，还有经常被忽视的、更重要的全链路缓冲区管理。第一步是起播的低延迟，因为我们是做 IoT 的，一开始就是 I 帧，没有 GOP 的影响，但是如果做直播内容分发，就有 GOP 影响了。起播低延迟处理最好的，应该是腾讯云的快直播 WebRTC，它的起播处理，非常有技巧性，这里因为时间原因就不再具体分享了，有兴趣的话可以了解一下腾讯云快直播 WebRTC 产品。第二步就是传输协议的加持，传输协议的延迟，虽然不会影响很大，但还是很重要的，如果你用 TCP 也能做低延迟，但和 WebRTC 的低延迟相比还是差一些。第三步是播放端的反馈通道，要想办法建立一个通道能及时反馈，播放器每收一帧，就把收帧时长反馈过去。第四步就是延迟保持，服务器和播放器中的缓冲就应该尽量小，大了播放器快进追帧，服务器则通过均匀丢帧降帧率或者降码率来适配。

我们在 IoT 上还做了很多其他的工作。IoT 的使用场景都是智能硬件，有很多系统，比如 FreeRTOS、展锐 RTOS。我们适配了很多设备，这些设备可以按照统一的协议和安卓 iOS 互通。还能与小程序互动，直接在微信小程序上看家中摄像头的直播。和微信小程序打通后，还带来了其他收益，比如说，能够把家中摄像头很容易的分享给其他人，可以利用微信小程序的登录、分享等诸多功能运营私域流量。

对比一下其他的 IoT Video 接入方式，如 RTMP 或者 H5+WebRTC，我们的优势在于，出图时间快，延迟低，程序大小可以满足 IoT 设备的要求，还是熟悉的 HTTP 协议，接入起来非常简单，网络直连率也比 WebRTC 要高，更加隐私同时节省成本。

以上就是我这次分享的关于 P2P 在 IoT 领域上的应用。P2P 之前是在内容分发上帮助降本增效节省成本，做到了跨端，安卓 /iOS/ 小程序都支持，延迟、秒开质量效果都很好，现在我们又成功地把这些功能特性拓展到物联网 IoT 领域，这套产品对用户网络和客户开发者都很友好。最后，我们致力于将 P2P 和音视频技术拓展到更多领域，希望大家共勉，谢谢！