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

编者按： 摄像头是物联网世界的眼睛，拥有体积小且节能的特征，而视频监控一直是跟音视频紧密结合的领域，同时成本控制要求严苛。传统的视频监控解决方案陈旧且复杂，不能满足灵活访问控制的要求，在视频大时代的背景下，如何才能适应日益增长的需求呢？摄像头虽小，但对音视频秒开、低延迟的要求却一点都不低；随着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和音视频技术拓展到更多领域，希望大家共勉，谢谢！

---

---