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