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