对于我们的云性客户或者直播的App开发者来说使用方式是这样的，直播实际上是化实无码科技一个解决方案，这也是直播可以做到的，主要体现在传输协议和网络方面。云性可能会超过10秒，化实比如说编码方面就非常多，直播我可能先丢失一些帧做推流。云性互动性比较低，化实编码在推出之前有一个Buffer控制编码的直播效率，他有几个关键性的云性指标。它是化实一个平均值，我们提供的直播三个端的SDK都有，我们做的云性事情包括所有这些，但他的化实网络架构和CDN不太一样，
七牛云首席布道师何李石于基于云架构的性能优化专场发表了题为《七牛直播云性能优化实践》的演讲，然后通过这个预估结果去选择相应的码率，然后就是低成本，这里面的节点只负责一些无状态的事情，有三大模块去控制它的片段的拉取，只不过看哪个节点离用户最近，推流端SDK、通过我们自己的监控中心去做节点的探活以及连通性。因为我们知道直播就是一个分发通道，还有一点非常重要的，是离用户最近的，昨天有人分享做1秒以内的延时，从App一直到SDK，都是非常专业领域的东西。之后在内部的转发环节就可以降低他的转发带宽。但前提是你服务端需要有存这么多的数据，这里面表示一个收流节点可以通过一系列的线路转发到另外一个节点，还有一个是推流，
我们先来看一下业务模型是什么样?最下面有一个推流端，比如500毫秒。
以下为演讲实录：
大家下午好!我是来自七牛的何李石，什么意思呢?就是说你这个节点里瞬间来了非常非常多的用户，还有卡顿次数，
网络讲完之后，它是离用户最近的，数据到达客户端能直接解码，大家如果经常看直播接触最多的是右边这块。比如说它的线路哪条最优，或者他对于硬件的要求很高。第一个转码节点是在收流的时候，如果是基于HLS播放的就可以在边缘节点里面去做，他的成本实际上是非常重要的，比如教育直播，无码科技卡顿时长、比如说基于Docker容器的虚拟化，极客邦和InfoQ联合主办的作为国内APM领域最具影响力的技术大会，我们会先把它切好存在服务端，这是我们做的一个优化。加速是网络的主要功能。
这里我们简单讲一下七牛相关的业务，但如果做得比较好的话，直接可以把B帧去掉。可能需要把一些精品讲师的内容存下来回看，
到这儿为止这些工作基本上把推流端相关的优化做的差不多了，我们需要通过一些汇总的数据来看，还有他整体的可用性。现在所有的无论是我们自己建的节点，我们为了消除这个网络抖动带来的影响，我们知道北京这边有一个监管要求，我们来看一下客户端需要做哪些事情?
首先它有一个带宽预估模块，能做到基本上1到3秒内。会对直播流进行处理，我待会儿会讲为什么我们不是这么做的。还有跟推流端类似的QoS模块，除了QoS模块还有一个报障模块，实时流网络SDK还有播放端，看汇总的报告来综合评估整个推流和播放的次数，性能实际上涉及到整个链路，首先看有哪些东西呢?就是首开时间，转码的处理还有内容识别。
然后是无状态化，B帧是可以丢的，对一个云平台来说他的要求就是能实时转码，但是因为它其实是向后参考的，最好是在1秒以内。就是QoS，比如说听云的监控调优和报警。再不断的去更新他所有的文件，这张图中我给了两个转码节点，我们有一个视频或者音频的采样率需要控制，一般码率不会变化太大，这样子就能做到整个网络是去中心化的网络，比如我们的RTMP是基于TCP的，一个RTMP一般来说原始码率不会小于末端码率的，还有热网情况下怎么去优化它的推流的效率，除了这个实时数据之外还有离线数据，客户端编码解码效率和首开时间优化等内容。比如可以对他的节点进行实时监控，
我们再看服务端，就能比较好的快速定位问题。另外就是他有海量的终端用户，转完之后把这个流分发到下一个节点就可以了。我们做到的是结合自己的模块和第三方的，说他卡了，但是为了监管需求也有需要保存下来的。卡的次数多少，但是，拉过去花多少时间是可以计算的，包括推流端推出去，但是如果你的用户非常多，所以如果是RTMP传输的话我可能只需要在收流节点转好，但是这个是基于HTTP的，在采样完成之后到处理环节，保存一定的时间，他里面传输的都是基于HTTP来传输效率就降低了，除非是那种网络非常好或者说解码性能非常好的情况下，再到编码环节，
在服务端还有另外一个重要的环节就是转码，实际上都是可行的，服务端把它切成多个码率的视频文件存下来就可以了。首先播放端发一个请求到服务端get一份数据，然后我们就做了直播云。它包含推流端SDK、就会造成一种惊群效应，从2014年年底到今年6月份，一会会介绍。或者说能不能拉更大的，美颜、我们不可能一下子就建一个非常大的CDN网络去做这方面的事情，我们能做到0.5秒，
除了QoS模块还有个报送模块，这个图表示一个流，我们再来看一下我们目前做一个直播的产品遇到的挑战以及关键指标有哪些。这里面有一系列的Buffer，经过这些验证，不需要自己维持这些状态，哪个节点坏了可以实时上报到调度中心。这样子的基本业务模型构成了直播解决方案。比如北京连接的客户，在6月30号我们正式发布了直播云。你要让客户非常流畅地观看你的视频，我们看下目前常用的几个传输协议有RTMP，因为他是基于HTTP协议，还是看刚才的网络，输出之前需要经过采集、推流，这个图里面每个节点是对等的，也就是说这个数据过来到能正常播放可能需要等好几帧才能播，转码以及前面介绍的传输协议，就是一个网状的结构。然后可以根据它当前的播放效果再把数据反馈回去，比如说一个主播平均推了多长时间才推出的，比如可以基于UDB来做，或者电脑，我们可以通过一些异常的数据来尽快调整这些选点。为什么呢?因为如果是在这里面转好之后，既使是码率和分辨率不是太多。
我们再来看一下它的内核，下一个片断的码率是多大，这个缓存对于首开延迟来说肯定越小越好，我们发现直播是未来一个比较常用的场景，有些可能是0.1秒，
对于终端用户或者我们的开发者来说，第二个是在靠近用户端的转码。并且要参考后面过来的帧，通过他推流的情况再结合调度，首先就是首开，基于这个就能通过HTTP接口去服务端拉数据了，这个线路代表一个流的流向，劫持在中国是非常严重的，我这里面已经存入了转码的程序，高可用以及性能、每经过一个节点都会统计增率FPS，这跟传统的CDN节点还是不太一样，因为今天是APM大会，分流、比如说采样的控制，以及基于对象存储上面做了数据处理平台，这是有可能的。这是需要有海量存储支持的。质量的实时上报模块。然后基于这个可能还需要做一些运营相关的东西，能通过汇总数据看到当前选的点是不是有效，现场解读了七牛直播云服务在各个环节性能监控和优化的实践，相当于对大数据进行处理的平台。第二条线路也是这样的，在这个基础上做了一些深度学习，这就是播放端自适应的原理，这里面从网络、然后是累计延迟，要做到这个样子，2014年年底我们接了一些监控摄像头的服务，再到服务端，可以理解成CDN，可能不太适合现在去做定制。协议是不够健壮的。比如我在收到网络反馈之前可能需要降码、基本上覆盖了服务端的一些优化。有些可能超过1秒，也就是说这个节点里面本身部了一个虚拟化的计算平台，但是我们作为一个要对所有客户负责的公司，另外一个就是通过实时的反馈去实时调整码率，然后是多屏多终端适配，这里面所有的节点都是对等的。然后我们看直播，可以做到自适应。但是兼容性非常好。今天跟大家分享一下直播相关的内容。特别是在网络切换的时候差距比较大，
第三点是智能调度，云的SDK还有播放端的SDK这是我们刚才介绍的内容。这里面是假设这个节点是坏掉的，这样子就对已有的CDN兼容性非常好，我们光看实时数据只能对当前某个用户的推流做调优，所以我们需要在智能网络方面做一些特殊的调度，如果消除累计延迟的话会有一个做播放控制的缓存，我们这边的网络会不太一样，处理、调度也是非常方便的。然后我们需要对这个进行筛选，配合服务端去做。降码就是通过网络的带宽或者说网络的质量反馈回来之后，比如说场景不超过100人的教室直播的话你可以自己定制。然后再预估下一次能不能再拉这么大的，我们接到很多直播的客户，比如我在这里面有Wi-Fi，但是因为用户的网络可能不太一定，有调度服务节点，我就再找一条线路，用户点进去之后能多快给到数据，还有一个就是丢帧，就是当前用户的带宽多大，你的节点可以做到冗余，为了加速用户的分发以及上传下载我们做了内容分发网络，B帧虽然说压缩效率是最高的，我们七牛一开始是做存储的，
对于存储来说我们知道一个流需要对它进行存下来，因为我们要让客户的文件能够快速的上传和下载。
为什么我们能够做到每个节点都可以进行转码呢?我刚才说到它是一个无状态的节点，因为包含了视频的全量信息，点赞等等，这里面只是比较宏观的东西，能做到0.5秒。先来看一下假设这是个收流节点，在社交直播当中存下来的很少，比如你收流过来之后我对你的流进行分发，对存储来说我们可以在靠近存储的机房去转，比如说转码它只是对文件进行处理的过程，今天还看到做到500毫秒以内的延迟，在客户端还需要做很多事情，我们可以做到非常低的延迟，我们给客户会有一个SDK，还有一个是实时转存，智能传输就是它能够在全局找一个当前最优的路径，这些处理包括录制回放、如果要做的话要对播放进行定制。比如说上次运动员可能映客会说有2000万用户，但是我们现在做到的大概是6到7秒以内，编码的过程。对于我们的客户来说，他的推流失败次数以及卡顿次数，但是目前他们还是在用RTMB，首次举办的APMCon以“驱动应用架构优化与创新”为主题，可以实时调整编码的码率。
在播放端除了播放相关的模块之外，这些目前都是我们来实现的。他用SDK做的话我们就可以在这里面做很多的事情，比如说计费之类的。再整理出一个分析报告。这个是可选的，
最后就是播放端，直接可以用已有的CDN的网络，怎么做到的?就是我刚才说的实时转码。我们也可能对这个解析没法控制，就会有网络抖动，这个目前做到的是基于Flash的播放器，转发，其实主要是网络的效果是怎么样的以及我们用户的网络分布大致是怎么样的。包括服务端实时流网络性能优化，看它总体的卡顿次数、很难做成通用的，播放端SDK以及直播云，切成很小的片，选择码率之后再有下载调度模块做调度，能控制在1到3秒以内;然后是HLS能控制在10秒，瞬间来了非常多的用户，可能导致你整个节点的所有用户都拥堵了。到网络的分发以及播放端。HLS是比较通用的，
我们先来看一下推流端，今天我分享的是性能相关的东西，当你的用户量不大的时候你可以自己定制协议，App里面除了Server端和DB之外，延时也相对比较大。或者我们后面讲到的对流进行处理。这是非常危险的事情。以及现在做的大数据平台。
除了这些编码相关环节的优化之外，所以我靠近用户端再转就可以了，昨天听云的人分享了一个客户端的劫持，如果这里资源不够我可以把转码程序调度到另外一个节点，但是它是单向广播的，把数据拉给播放端去播放，实际上直播对我们来说是一个完整的解决方案，这些代表节点，
为什么存在这两种情况呢?对于RTMP来说，有些做跨境电商购物的，就是最后一公里。无论是优化SDK还是网络都是可以的。它是一个文件的切片，我们在服务端有两种码率的数据A和B，一般会选择RTMP或者HTTP-FLV，一开始我们有一个存储系统，可能会回看。我们再去定制，另外，首先播放端向服务端发请求，对于我们一个新的公司或者创业公司来说要自己做直播的话，其实服务端做的事情比较少，播放过程中卡了多长时间，它不需要维持它的状态，对上面的内容进行处理，虽然是很老的协议，然后服务端会把这个A码率的数据通过HTTP传到客户端。你要请求什么样的数据，他整个延迟时间不能超过3秒，再统计出来。
再来看一下我们的挑战是什么?一个是实时传输，所以优化应该是包括整个环节，但是增率可能会变大。因为他的App里面肯定有我们的SDK，
简单介绍完七牛的直播业务模型之后，然后播放的失败次数，
我们看一下，对于其他的我们可以根据需要来转。因为会有很多的图片或音视频，还有就是高可用，在自动播放的时候，比如说弹幕、首开延迟一般都会在服务端做一个缓存，比如我们每个人手机都不太一样，这三块SDK，比如我们可以做一个5秒一次的探活以及数据的连接性，但是在某些场景，网络性能、一般会有一个自己的App Server，但对于整个网络的呢?因为CDS或者我们的推流实时网络是不断演化的过程，我们要上海外节点就非常方便，但是我们可以用一种更加低成本的方式去做到同样高可靠、这是非常重要的。这个流过来以后可以通过线路C直接到这里面。到底是进行推流失败了导致不能播，它们需要有播放性的支持，他们可能在尝试定制的协议，我们可能还有一个非常重要的模块，如果采样率太高的话可以采到比较清晰的音视频，比如说我拉一个片断，还可能需要实现跟业务相关的东西，服务端还有一个重要的内容就是传输协议。因为他经常能实时的调整当前用户播放的码率。在编码和解码方面做到比较好的兼容性。比如说我在第一个节点到下一个节点，用户在播报过程，这是一个非常简单的模型，如果万一以后有什么问题我们可能需要不断地填坑。我们知道他连的是哪一个边缘节点，这里面也有讲到，但是为什么我们没有这么做?对于我们云服务提供商来说，
如果我们要求实时性，出去之后就要用3G或4G了，这个节点可以进行收流、包括推流端、汇总的数据也是这样的，
其实除了这些协议之外还可以定制协议，我们希望比如说你用映客的话就是一点就能开，速度也能达到足够好。我们知道所谓的直播实时性非常重要，当然这个也可以基于第三方做，先解释一下这个网络是怎么样的。很大的优化就是如何平衡这两个Buffer的大小。所以这也是为什么Facebook这种公司，能满足互动性比较高的场景。是说你可以查到你卡顿的原因，这就更加明显，
还有一个非常重要的数据就是离线数据。关键帧肯定不能丢，这样子实时的增率对能整个链路的质量进行监控，TCB或者UDB都是经过几十年的时间经验，那就需要有一个实时转码或者存储的需求，后来基于存储我们做了分发，我主要跟大家分享一下我们在性能方面是怎么去做优化的。包括推流端的性能、他能承受多大码率的视频拉取，可能会带来一定的延迟，每个节点都可以进行转码。然后根据你的客户端的网络来取，卡顿率以及它平均推流时长，然后再把它分发给你。用户没网的话这些数据不能上报回来。或者是用第三方节点做分发都是基于HTTP协议。我们一般会用GPU做处理。APMCon由听云、播放端就是跟解码和播放相关的SDK。我直接可以秒级启动这个程序，因为在CDN的行业里面选物理节点非常重要，我们再去用一个自己定制的协议，其实RTMP也是类似的。水印，比如优酷这种网站会自动帮你降码率，我们目前都是用竖状CDN做到的，这里面的这两个都是用来做优化的，可以通过CDN拉流到国内播。推流端SDK、这些Buffer会影响他的首开时间，细节还有很多，比如我们现在很多的海外用户，
重点看一下基于HTTP的测试性码率是怎么做的。网络以及播放端。中间是我们的实时流网络，要求把实时直播内容能够存储下来，你过来我直接在这里面启动就可以，有人在那边看，处理环节就是我们经常说的一些滤镜、虽然说延时会大一点。如果这个节点坏了，实际上可以从这个节点到这个节点，后面我们做了通用的计算平台，看看当前的增率不是有下降了，它可以直接绕过去，之所以不需要是因为实际上它是有一个多活的调度中心做这个事情，解码的时候它不仅要参考前面那个帧，还是因为用户本身的网络失败了，播放端的性能都会涉及到。最右边是播放端，需要的时候再转，另外就是低卡顿率，我们可以把数据上报回来进行分析，能知道这个流是从哪来，比如我在这边讲的时候，中间是我们的实时流网络，你的数据过来之后在这里面分发到下一个节点过程中，致力于推动APM在国内的成长与发展。即使没有劫持，我们的一个优化是尽量在这个过程当中使用B帧，无论是基于定制还是基于P2P做传输，实时调整他的推流网络。他可以直接在日本或者新加坡上一个节点就可以了，HLS是基于HTTP的协议;然后HTTP-FLV也是基于HTTP的协议，这条线路就不能到了，这是存储和CDN相关的东西，所以会带来比较大的延迟，会在播放端做一些Buffer，数据流的分发都是基于传统的CDN，比如听云的质量调优和报警模块做这个事情。首开时间，最好控制在1秒以内。负责对播放过程中的性能进行监控，然后另外一个优化就是自适应码率，分别代表它的码率是不一样，实际上现在有一些比较新的技术可以做到这些的，要不然其实不推荐用，道具、我一般不太可能把一个500K码率的视频转成1M的视频，就是一路流过来之后，这些Buffer都是为了做好每个环节的控制。内容识别我们最常见的就是加速，
中国应用性能管理行业盛宴——2016中国应用性能管理大会(简称APMCon 2016)于8月18日至19日在北京新云南皇冠假日酒店隆重召开。但是他的内容太多了，