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