中国应用性能管理行业盛宴——2016中国应用性能管理大会(简称APMCon 2016)于8月18日至19日在北京新云南皇冠假日酒店隆重召开。APMCon由听云、极客邦和InfoQ联合主办的作为国内APM领域最具影响力的技术大会，首次举办的APMCon以“驱动应用架构优化与创新”为主题，致力于推动APM在国内的成长与发展。
云帆加速创始人王羲桀于CDN加速专场发表了题为《1秒延时的直播CDN与P2P服务实例分析》的演讲，现场解读了关于CDN +P2P直播服务的优势以及目前尚未突破的技术点。
以下为演讲实录：
今天，我来给各位分享一下直播以及P2P的结合应用。我们将围绕着直播以及P2P的结合，从以下五个维度开始给大家展开讨论：
这是直播今年火爆的一个数据，我相信在座的各位都有所了解。
直播的发展不像点播，点播其实从2004年是爆发点，大家开始认识到点播的CDN怎样使用，随着时间的积累，开源软件包括商业的系统都有大量的积累和改善，所以说可以看到的程序有Squdi、Nginx等很多。
直播从去年开始成为大家的焦点，过程中其实没有太多允许我们程序员去积累的时间，所以整个直播的体系大家用到的比较常见的是Nginx-RTMP、SRS两套开源程序。
整个直播服务和点播服务的中心要做的事情比较多，比如说转码、切块、录制加水印以及渐黄等等。CDN做的事情比较简单，文件的复制，当然现在也会用到存储以及切块的服务。直播对性能的要求更高，比如说现在在做直播整个业界都做到1秒延时，甚至低于1秒。如果用户在看今天的直播会议都会出现一些延时，而点播用户相对是分开的，所以对整个性能的要求，直播会更高一些。从直播的内容可以看得出来，直播的流媒体比较复杂，当然这也涉及到动态，比较火的AR以及降噪、美颜这类的技术。
我们简单说一下Nginx-RTMP以及SRS的改进版，RTMP的性能比较弱，只是简单做了RTMP的转发，实现高可扩展性，简单测试进程可以做到高的连接数。而SPR可以做到良好的提升，有丰富的一些开放接口。在SRS的改进版里面，就有做到刚刚前面提到的流媒体的处理功能，做了很多的结合。
在此基础上，当前还有SRTMP的作者去做了一个商业版本，以及云帆自己的版本。我们做一个简单的对比，云帆的直播服务器也是自研的，没有用开源的系统。网络协议支持的就是大家常用的RTMP，当然也提到了HIS+，我跟各位简单说一下，在BMS的HIS+，是把文件传输变成流件传输，在边缘节点进行处理。云帆做的是在核心层处理，再边缘化处理，能解决的问题就是把HIS的流速降低。
前面比较多的时间在讲系统，是希望大家能够对直播系统架构有一些认识，方便我们后面去讲如何跟P2P进行结合。
其实所有的程序都是在功能、性能、稳定性，以及响应程度四个维度去做考核的。前面提到的几个开源系统在功能、性能、稳定性方面都比现在的低一些，所以这里列出了一些指标。比如说现在两个系统都能支持上万的单机并发，延时能做到1秒以内，并且可以进行可追溯日志。在这个基础上整个的直播系统要满足我们的高响应度，这就是一个数据的分析块，数据分析这块有蛮大的关系。然后现在做可追溯日志，同时也会进入听云的第三方平台进行监测。CDN厂商也会做大量的自我的监测、自我的查询。做ANS这块我们把所有的服务节点放在一个平面图上了解每一个节点的性能、网络的卡顿以及知道每条流信息的音视频卡顿。除了原来看到的网络抖动以外，我们更多做一些流媒体相关的整合，去做性能的改进。
基于整体直播性能的提升，我们把CDN直播的质量做到比较高，这样才能结合P2P的较差质量用户进行整合。
通过这张图可以看出直播业务与点播业务峰值的差异，为什么我们要把直播跟P2P进行整合?直播的CDN已经通过各家CDN的努力，通过功能、性能、稳定性以及响应度各种努力，把它做到非常好了，一秒的延时、秒开、高质量、低卡顿，为什么要去结合?
从这张图可以看到，下面是点播业务峰值，非常均衡，而直播大家可以看到，这是我们真实平台里面的，我们自己平台的一些客户的数据。直播往往并发非常高，也就两个小时，会带来高额的带宽成本。在此基础上我们引入P2P结合CDN，以降低整体产品的使用成本。
传统的P2P，就是早期的以及在快播做的P2SP架构，这两块属于传统的P2P，它们最大的特点就是高分享率、低可用性。比如说原来在QUD做的数据分享率可以做到99%，但质量是无法保障的。
所以我们去做CDN+P2P的融合互补，把前面花了很长时间讲的高可用性的服务、可管理、可运维的服务去和P2P的服务，系统的可靠性以及突发处理能力，跟这些做一个结合。这里想说的是CDN跟P2P本身是两块业务，它是可以去有机的结合在一起，换句话说这个P2P可以选择任何一家的P2P，去跟CDN进行结合。也可以选择任何一家CDN跟任何一家P2P进行结合，并没有完全的相依赖的关系。
CDN+P2P其实不是简单的叠加，我们在网络层面提高了系统的可扩展性，降低了成本，降低了跨域、跨流量的问题。最大的问题就是P2P的内容不可控，所以加了CDN，并在控制层面和内容层面做了提升。
这里讲到的是云帆自己的一个CDN+P2P的架构。首先云帆是一家CDN公司，只是我们相比其他CDN公司拥有较长时间的P2P积累，所以我们跟P2P进行了一个结合。云帆的P2P能适配蓝讯等各家CDN公司。
从这个架构图上面我们可以看到，整个原端体系的协议进行切块系统，再分发到的CDN系统，最后终端可以进行P2P的传输，下面会讲到具体的逻辑策略。终端可以覆盖的是Android、iOS各端的P2P数据，是双通道获取数据的。
这是一个类似的架构模型，只是走的是RTMP的系统。整个P2P的体系里有两种做法，我们现在已经大量成熟的，在市面上大量公司在做，包括芒果直播、几个电视台大量用的有延时的P2P，比如说把用户有机的分开，进行0到30秒的延时，这种P2P可以做到80%的分享率。也就是说刚才我们看到的前面的峰值图将大幅度的下降。然后无延时的P2P是我们最近新研发的一个产品，目前正在客户内公测，目前看到的数据是可以做到40%的分享率，延时可以控制在1秒。
这里我们将讲一讲P2P跟CDN的真正结合。我们通过这张示意图假设我们有30秒的延时时间，CDN一定将发挥自己的性能和特性，去提供自己可靠、高速、有效的服务，P2P里面的节点最大的差异就是随时可以下线，随时可以中断。所以我们在0到30秒的时候，可以看到我们前面的时间段会尽量的使用CDN，会有富余的数据，以至于下面的数据补偿可以通过P2P。如果P2P的速度够高，我们将不会回到CDN的模式，不会回到CDN的使用时段，我们将一直保持P2P的长时间的使用。当然如果P2P的这条通道来了数据不够的情况下，我们自然会调回20秒以内，回到我们的CDN使用阶段，使用高可用性的数据保证它的流量，20秒到0秒的过程，我们有20秒的时间可以去做大量的补救工作。
这里讲到的是我们如何去筛选?如何把P2P放到10秒、20秒、30秒的阶段?如何释放?如果所有的P2P都在30秒的话，我们没有可分享的东西。所以我们会有机的分开，传统的做法都会随机，也就是我们看到的橙色的线，所有的用户分布在每一个时间点，其实也挺好的，分享率也不错，但是它会比较容易曝露出P2P节点的缺点：速度不佳、随时可以掉线。所以我们在做P2P的时候结合了大数据，这么多年来大家都在讲大数据，但却是做大数据容易、用大数据比较难。我们通过把每个用户历史的习惯、速度，以及他的网络分布，我们尽可能的去预判所谓的分析，预测出这个用户的上传能力，以及他将会在线的时长。我们会把速度上传大的、在线时长长的放在前面，让他延时尽可能少，可能只有两三秒，放在前面意味着他有更多的时间，有更多别人感兴趣的数据去分享，因为他的速度更大，他在线时长更长。我们还有其他的维度进行详细的分析。
这里我也讲一下无延时P2P的做法，大家会使用CDN来保证质量，不会用P2P去做质量的保证。因为P2P的用户他的带宽有限，以及他随时下线，随时会中断服务。再结合我们的大数据中心之后，我们发现其实用户的能力有的上传能力非常高，可能已经到了两兆、三兆，发现有的人在线时长非常长。所以我们在进行大数据结合的利用之后，我们抽取了高质量的，把他做成我们前几秒的数据提供方。实际测试的情况非常有效，方案我自己非常感动，我做了P2P做了七年，我终于可以看到P2P的用户跟CDN放在同级别的情况下去产生了。
在大家传统的意识里P2P就是会导致体验差、导致各种问题的架构，包括用户上传高，浪费用户流量的架构。实际上我们在客户的应用上面会看到下面这张图：
CDN这个是白色的线，理解为99.9%，但是有的用户在最后一段距离没办法访问到这个节点，这种情况下将导致整个用户使用的质量下降。而P2P充分随机的情况就是绿线，我们解决了最后终端的距离，可能简单理解为双通道。在A通道拿不到数据的时候，哪怕它会卡，我们用B通道代表它。而且整个P2P做的时候我们有就近原则，我们在场的一两百位观众，我们优先在本场找到感兴趣资源的节点，然后再会离开北京，到北京电信，到整个华北地区，然后到全网，然后再跨运营商，再去国外，会按这种思路就近的获取资源。所以我们往往拿到的是本地的，今天我在这里做一个P2P的直播，我今天拿到我跟Wood之间连接的速度一定是最快的，因为我们是局域网。这个速度一定高于我在北京电信的节点质量，延时也会大大低于公网回来的数据。所以CDN+P2P的有机结合，在实践中我们看到是这条红线，实际上我们最优秀的一家客户，加上了P2P的方案之后确实没有下降体验，并且得到了有效的提升。
最近我们做了美国跟中国的打通。这块我觉得唯一值得讲的就是我们通过香港的中转已经做到了，通过TCP加速的概念，和香港的中转节点，做到了代替国际光纤，实现了美国纽约到深圳电信，到北京电信一秒的延时，以及秒拍的传输。
这是一个简单的，本来我想现场展示，但是环境的问题没有手机能拍摄。这是一条纽约过来的视频，这块做优化加速以及弱网的情况下的一些交流，会后大家可以进行多交流。接下来我们进入到问答环节，有需要问问题的可以举手。
Q&A
Q1：您好，您前面说到有一些用户端你们发现他上传的带宽比较大，但是我理解大部分其实还是固网的用户，如果移动端直播的用户比较多的话，其实直播端的情况很复杂，很难保持一个比较稳定的上传速率。你们现在做的还是针对固网的用户呢?还是在移动端的环境下也可以达到这样的效果?
王羲桀：移动端的环境下，应该这么说，首先在手机端上看视频，90%到95%以上还是在wifi环境，但现在开始，这个数据越来越大了，这是第一个背景。第二个背景是我们手机打开，在通常环境下并不比我们固网差，所以我认为可以。但我们的应用上都会给所有的使用者提供一个是否是局域上传和是否是局域下载的开关，目前大家都比较保守，不会打开的。
我刚才说到大部分人还是在wifi环境下，如果有大量的用户应对这个问题的时候，也是符合我们现在的判断逻辑。就是在P2P里面，再讲细的话有一个超时极致系统，比如说你上传能力有限，或者说你的速度很快但是网络不稳定，这种情况下我们在用户端会主动放弃对你的选择和使用。但如果大面积出现你刚才说的问题的话，那可能会一个很大的挑战，是一件值得让自己感到要去做的事。
Q2：我想问一下咱们的P2P的SDK如果切入到移动端，主流的移动端手机的话会增加，像我们说的视频、移动直播的，会增加终端的崩溃或者是稳定性吗?
王羲桀：我觉得在国内能做P2P的公司确实比较少，今年随着大家的需求变多以后，确实已经冒出了很多的P2P公司，但是这个SDK很危险的，装一个SDK到我们的程序里是非常大的风险，不管是你技术风险还是商业风险，比如你是过亿的终端，如果我在你的终端上面执行SDK，是非常大的风险。
实际我们现在在芒果TV全平台、Android、iOS，这是典型的用户，当然还有很多的公司在使用，活跃的用户已经非常大了。从他们的数据反馈来说，现在没有崩溃率提升。在他们的体系里崩溃率是非常严格的指标，我知道的应该是在百分之零点几以下。
Q3：会有别的发热现象吗?
王羲桀：P2P的开销非常非常低，我们的SDK有网站你可以测试一下。P2P本身的算法是相对比较简单，唯一的开销就是加解密，以及校验。因为P2P的数据不安全，所以来源都会进行比CDN复杂的逻辑，你的数据下载速度不会超过50k，我们现在手机做的时候对耗电以及发热没有太大的影响。
Q4：刚刚您说到在香港做一个网络中转节点之后，美国和中国之间的传输会优化很多。那你们TCP方面的优化主要是通过同传机制还是什么技术做的?
王羲桀：一定是基于你刚才说的做的，只是不是简单的TCP，这里面也结合了P2P的思路。我们整个美国的出口是用洛杉矶做出口，中国的中转点是香港，这部分数据的传输也是结合了P2P，我们会用空间换时间。如果它掉的情况下我们会多节点传输，让它通过P2P的通道。因为你会发现P2P在下载数据的时候不只是连一个人，是多个人，并且每一个分块会分的非常细，可能最后细到4k，如果你的网络质量越差，他的分块越细，网络质量越好分块越大。这种基础上我们通过P2P的多连接的传输，去降低丢包对我们的要求，我们实际测试的时候30%的丢包提升了40%几的流量，但不会受到网络影响，也就是刚刚我们展示的视频，做秒拍和低延时的有效保障。
同时我们还进行了数据测试，因为还没有得到大量的验证，所以我们不敢拿出来。大概的数据是原来我到洛杉矶的延时是150毫秒，实际上我们可以把数据的延时缩减到30到50毫秒，我们也结合了TCP加速，包括慢启动的打开，我们一开始就会把一些TCP本身底层要做的事情做掉。
