标签归档：CDN

nginx 根据IP进行灰度发布

灰度发布，简单来说，就是根据各种条件，让一部分用户使用旧版本，另一部分用户使用新版本。

nginx 的语法本身可以看作是一门小型的编程语言，通过简单的编程，可以轻松实现基于IP的灰度发布。

需求：搭建准生产环境，供开发人员/运维在线上做最后的调整。如果OK，直接用rsync推送至生产环境。

条件：办公室网络出口有固定IP

解决办法：

nginx 负载均衡器判断客户端IP地址，

如果是办公室IP，则反向代理到准生产环境；

如果不是，则反向代理到生产环境。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
upstream prod {
    server 192.168.1.10;
    server 192.168.1.11;
}
upstream pre-prod {
    server 192.168.1.100;
}
server {
    listen 80;
    access_log /var/log/nginx/access.log main;
    set $web_backend prod;
    if ($remote_addr ~ "123.123.123.123") {
        set $web_backend pre-prod;
    }
    location / {
        proxy_pass http://$web_backend;
        include proxy.conf;
    }
}

同理，也可以根据不同的IP，设置不同的网站根目录，达到相同的目的。

1
2
3
4
5
6
7
8
9
10
11
server {
    listen 80;
    access_log /var/log/nginx/access.log main;
    set $rootdir "/var/www/html";
    if ($remote_addr ~ "123.123.123.123") {
        set $rootdir "/var/www/test";
    }
    location / {
        root $rootdir;
    }
}

同理，还可以利用geoip做基于地理位置的灰度发布，不详细介绍。

不看好5G的14个理由（附精彩辩论）

6月18日，一位网名为“蓝色海岸”的业内人士，先后在c114论坛发文《不懂国内为什么那么看好5G？》，阐述了他不看好5G的8个理由，引发众多移动通信业界人士回帖反驳。6月22日，“蓝色海岸”再发文《不懂国内为什么那么看好5G之二—绝地反击》，阐述了他不看好5G的另外6个理由，再次引发众多移动通信业界人士回帖反驳。

这场辩论很精彩，很多地方都说得有理有据，有些观点/说法也具有一定的思辨性，下文就摘录其中的精彩内容，供大家参考。

网名为“蓝色海岸”的业内人士：

1、5G网速达10G， 不可能，即使能达到，也毫无意义，因为没有需要，现在光宽带的网速，EPON是1000兆，GPON是2500兆，可实际开通的一般是20兆，有很少部分用户开通到了100兆，为什么不开通2500兆，因为没必要，没意义，现在高清视频的带宽一般在2至3兆，就算下载需要更快一点，但也有限，因为人眼和人脑是有带宽的，太高了人的眼睛和大脑接受不了，就没意义了。既然光宽带都不需要那么高的网速，手机会需要吗？手机的屏幕就那么小，4K清晰度有意义吗？超过人眼能够识别的极限，标清和4K不是一样吗？

2、千兆无线路由器早已有之，但是市场反映平淡，很显然，只增加最后一公里的带宽，骨干网带宽不增加，也就没有意义了，这就好比只加宽家门口的马路，不加宽主干街道、国道和省道的公路，速度能提高吗？运营商和设备商就是这样愚弄用户的，说是增加到百兆带宽了，可是实际上只是增加了一点点。

3、服务器和手机的处理能力有限，宽带网一端连接的是服务器，也就是电脑吧，一端连接的是手机，电脑的PCIE总线速度已达6G以上，但是硬盘速度也就几百兆，而且这样一台服务器要连接很多用户，就算把电脑的处理能力全部用于一个用户，极限也就几百兆，而手机的处理能力就更弱了，这时候电脑的处理能力变成瓶颈了，网络两端的速度上不去，只是一味的增加中间部分，会有效果吗？

4、现在5G的宣传都说下载一部高清视频只要几秒云云，实际上只要下载视频的速度大于播放的速度，人就感觉不到网速的快慢，手机是一边放视频，一边下载的，你让手机下载那么快干什么呢？让手机几秒钟下载完，就可以歇着了，你心疼它累吗？

5、九几年的时候，上网很卡，后来带宽增加了，上网不卡了，看视频还是很卡，用的很不爽，运营商就告诉用户，是带宽不足，你要把56K猫换成ADSL，有了ADSL，又说要换光宽带，有了光宽带，又说要换4G,这似乎已经形成习惯和趋势了，实际上，上网和看视频，ADSL足够了。为什么ADSL不行，那是骨干网带宽不足，为什么骨干网带宽不足，是因为运营商之间互掐，以及骨干带宽资费不肯下调。接入网的带宽早已远超需要，GPON,EPON,千兆以太网，千兆无线路由器，10G以太网，这些技术早就成熟了，可是下载高清视频的速度也没有说就几秒啊，5G同样是在接入网段的技术，凭什么这么一个接入网段的技术，就能大幅度的提升网速呢？现在有个口号，叫4G改变生活，5G改变社会，的确，3G的带宽只有2兆多一点，而且是很多人分着用，是少了一点儿，但是4G看来是足够了，在没有Iphone的时候，3G搞了10年也发展不起来，那是因为没有需要，同样的5G想要发展起来，需求在哪里呢？

6、现在有了高清视频，有了1080P，甚至有了4K电视,网络快一点，还是有那么一点点道理，离开了大屏电视，就手机那么一个小小的屏幕，它的显示面积就那么一点点，它要那么大带宽干什么呢？再说了，有多少人在室外一边走路一边抱个手机看电影？恐怕没有吧，一般都是看看微信呀，上个网什么的，就这么点需要，难道上百兆的4G还满足不了？恐怕几兆就足够了吧。

7、我们的网速到底有多快，我可以告诉，平均每个用户就100K多一点，但是这是平均值，实际上由于统计复用的原因，并不是所有人都在不停的占用带宽，而是轮流使用的，所以大家使用的实际带宽还是挺大的，几兆应该是有的，如果用户和服务器同处网络边缘，也就是通过CDN加速，再宽一些也是可以达到的。这就好比马路就那么宽，但并不是所有人都站在马路上一样。你要更宽，那就变成经济问题了， 并不是技术实现的问题，试想如果带宽像空气和阳光一样随处可得，尽管没人离得开空气，可是又有谁能把空气变成钱呢？这种事情运营商会干吗？这就是说有价值并不等于有价格，没有价格也就是没有经济趋动力，没有经济趋动力谁肯干呢？骨干网平均带宽100多K，接入网要上一万兆，这意义又在哪里呢？

8、 这些都撤远了，就说通信行业，九十年代炒的火热的ISDN，那时候互联网还不普及，ISDN可以通两部电话，还可以通可视电话，可是可视电话因为视频压缩算法不过关，带宽低图像质量差，画面小，无法激起消费者的购买欲望，很多公司投入几亿几十亿美金，都丢到水里了。阚凯力阚大炮当时看准了ISDN没有未来，ISDN技术可以在一根电话线上装两部电话，可是他认为只要再接一条电话线就可以办到了，那样显然更便宜，何必为这个要搞一代新技术，更何况有多少家庭会需要两部电话啊？接下来是ATM，ATM把主要吸引点放在视频业务上，结果同样因为视频技术不过关，ATM无用武之地，胎死腹中。

楼主并不是说5G永远没价值，至少是在目前能看得见的未来，价值还体现不出来，这就很危险了，你说现在看不到也想不到的应用，就炒得火热，到处宣传到处试点，搞了几个试点是花了好几亿，这是在糊弄老百姓啊，还是在套取国家资金啊?阚大炮当年认为3G是皇帝的新装，结果3G的投资的确打了水漂，有人辩解说3G积累的技术，在5G时代用得上了，还要领先国际水平，可是阚大炮的眼光是很毒的，被他识破的东西要想翻身如同登天，3G时代积累的那些技术能否用在5G上，看来很大的可能性还得落空。

9、 5G现在的确吹的有点邪乎了，刚开始说要搞1G带宽，后来4G+出来了，能上300多兆，这样看来1G带宽好像也不是什么太有吸引力的概念了，然后就搞出个10G出来，这简直就是放卫星了。固网和光宽带现在实用带宽也就几十兆，现在10G的光宽带也已经实用化了，据说到2019 100G的PON标准也将发布，可是用户实际开通的带宽到底有多少呢？这种脱离实际应用，单纯的技术引导能走得远吗？ 论坛里有人说5G是低延迟，这恐怕说的是基站到用户之间100多米的延迟吧，这100多米产生的延迟在整个通信链路中微不足道，基站到城域网，再到骨干网，用的就是光纤了，请问这段延迟是怎么解决的？这早就超过5G技术的范围了。决定延迟的根本原因，还是在于城域网和骨干网，这都不是5G技术能解决的问题了，你说5G能解决，那就明确说明这部分是怎么解决，你不要说那些通信专家肯定考虑到了，他们到底是怎么考虑的？

5G号称低延迟，连郎咸平都出来说话了，说5G的速度快于人的神经的反应速度，在胳膊上扎一针，大脑还没感觉，5G网另一端就已经知道了，这种说法的确够让人震惊，可是光通信的速度早就有这么快了，可就是没人那么说，这不是故弄玄虚糊弄无知群众么？5G厂商够厉害，连著名经济学家都搬出来造势了。5G要想实现低于光宽带的延迟，那得费九牛二虎之力，这一点连任正飞自己都承认还解决不了，可是媒体上都吹的跟真的一样了。

10、5G所使用的频段是毫米波，在这个波段，电波基本是直线传播，绕射和透射能力都很差了，另外5G基站的覆盖范围也很小，可能只有几百米吧，发射功率和带宽呈正相关，带宽加大，发射功率急剧增加，而手机的发射功率是有限的，这就决定了5G基站的覆盖范围很小，大概100多米到几百米的样子吧（网上有文章号称 5G基站能覆盖20公里，到了那个距离，带带还剩多少，还有什么使用价值，有良心的工程师自己知道），这其实比WIFI的覆盖范围也多不了多少了。面积与覆盖半径的平方成正比，这就意味着5G基站的数量和密度可能是4G的5到10倍，这正是设备商努力鼓吹5G的原因了，可是那么密集的基站，手机即使很低的移动速度，也会频繁切换，而切换又会产生很多的延迟和中断，这些问题又怎么解决？这么多的技术缺陷，注定5G如同无线输电一样，描绘的很好，却是个迟早都会破的大泡沫。

11、再说物联网，物联网是5G炒作者最重要的支撑基础，什么万物互联，物物互联。通信说白了，最重要的指标无非就是延迟、带宽和丢包率，这三个指标是基本指标，光通信这三个指标都远优于5G，在这方面有天生的优势，可以说已到了理想化的程度，对5G来说，那是一道永远也不可能突破的墙，现在5G到处宣传，给人感觉好像是什么划时代的技术，可以轻松超越光通信。WIFI加光宽带足以实现物联网的需要，没有WIFI的地方还可以用4G，没有5G物联就实现不了啦，不会吧，不要尽搞些新概念吓唬人好不好。网上有人说5G的频谱利用率有多高，就这一点足以说明5G是个好技术，请问5G提升频谱利用率的最终目的不就是在有限的频谱内提升带宽吗？可是如果连提升带宽都变得没有意义了，那提高频谱利用率的价值何在呢？

12、有人说楼主不懂，服务器和电脑不一样，服务器里面的硬盘早就使用光纤连接了，但是光纤连接的仍然是硬盘啊，硬盘的速度是瓶颈，你用什么连接速度也上不去，这就是木桶理论了。实际上，现在使用的服务器大多仍是PC机，只是PC机集群而已，但也有极少量的小型机，硬盘仍是最主要的存贮介质，你说可以搞个缓存，那样存取速度就会提高，但那毕竟是极少量的，缓存的容量跟硬盘怎么比啊，那是成千上万倍的差距啊，没有大规模推广的技术，证明是没有商业价值的。

13、有人又说到AR,VR，反正这些技术还没走进人们的生活，大家但吹无妨，这两种技术可能需要三十多兆的带宽，4K高清需要16兆带宽，也就是这样了，这也不需要10G带宽啊，有人又说了，基站的带宽是大家共享的，你以为光宽带的带宽就不是共享的吗？这种AR,VR要戴个大眼镜捂住双眼，你不怕在外面走路会撞电线杆吗？这AR,VR恐怕还只能在家里用用吧，在家里用当然是WIFI和光宽带更好了，5G信号要穿透家里的墙，那丢包率和延迟还不得蹭蹭的往上窜啊。回到物联网的问题，物联网所连的物，绝大部分应该还是在室内吧，室内当然是光宽带和WIFI的地盘了，5G信号穿墙到室内，那信号还不知道差到哪里去了？

14、通信行业这些年的走向，让人摸不着头脑了，就说SDH，明明在延迟、带宽、丢包率三个指标上都远优于PTN，也远优于IP网，却被说成是淘汰技术，许多地方拆了SDH上PTN,结果E1线路经常帧失步，你说这不是在开历史的倒车么？这说明一些人的确可以颠倒黑白，指鹿为马啊？我们还要被那些所谓的技术专家糊弄到哪里去？这已经到了对那些技术专家万分警惕的时刻了，弄不好就会被他们带进坑里去了。

网名为“winnyterry”的业内人士：

唉，再见文科生另一神论，其实论调和理据和上一篇一样，只是写得长了一点。回复较为费时。

首先，这篇神论第一段的逻辑就有问题：楼主的逻辑是：任何技术的发展，都必须先有大需求，再去发展技术。否则就是冒天下之大不讳。但我回忆了一下中学小学学过的中国五千年，和世界近两百年的发展。中国和世界都是在矛盾和失败中前行。人类的每一个成功的发明，一开始的需求其实都和移动通信技术很相似，需求不明显，但发明出来后，这个需求就极之可能变种成爆发式的增涨。

其次，楼主纠结国内为什么看好5G，我想说，移动通信技术从电报通信开始，一直到现在的4.5G，就不只是国内的事，而是全世界的事。5G技术也不只是国内在准备，全世界都在准备，看不看好另说。但如果全世界都5G，就中国4G，我就一定不看好了。中国从电报通信到现在，一直在全球通信产业中都处于模仿跟进付专利费的地位，这个局面直到3G开始有了松动，4G开始有点点的话语权，再到5G话语权又会再增加一点。这种进步对于中国通信产业的意义并不是4G有300Mb/s，5G有1Gb/s这么简单的对比可以概括的了。

再次，wifi与5G对比的问题。坦白说，wifi通信和移动数据通信其实分属于两种不同的群组技术,wifi是计算机通信群组技术，5G是传统移动数据通信技术。这两种技术从2G时代起就一直在对抗，希望获得移动通信的话语权。但自己从传统移动通信技术不停的更新迭代，wifi的速率和容量优势早已不复存在。再加上现在全球特别是中国的通信资费以火箭速度下降，wifi注定在未来是小众应用，只剩下企业内网和大型mall用于宣传之用。根本不可能再回复在2G、3G时代的火爆。可以预料，在5G时代，wifi衰落的速度会更快。作为我本人，从2008年起就很少用到wifi了，除非我所在的那个地方完全没有3、4G信号。但这基本上在我全国跑的经历看，这不可能出现。

最后，我实在无法理解楼主说的：“请问5G提升频谱利用率的最终目的不就是在有限的频谱内提升带宽吗？可是如果连提升带宽都变得没有意义了，那提高频谱利用率的价值何在呢？”再次强调，频谱利用率的要考虑是主要是如何在有限的无线频谱下，容纳更多的并发数据。这点比速率的提升更重要。如果GSM一个载扇能容纳200个客户在线，但WCDMA一个载扇能容纳400个客户在线并能保持超过2G的速率，FDD一个载扇能容纳800个客户在线并能保持3G的速率……你还会认为频谱提升没有意义吗？！

网名为“jeffyko”的业内人士：

个人角度，看5G这个问题，如下几点：

（1）相比4G，物理层上没有重大突破，速率的增加无非是通过更高阶mimo更大带宽来实现，

（2）时延上的改进一是架构的优化，二是芯片技术的提高

（3）iot/mtc未来可能会有很大应用价值，毕竟与每个人的生活息息相关

（4）如楼主所述，路铺的宽又如何，应用在哪里？

所以，不要把5g吹的太悬，最终它也要走下神坛。如同volte一样

网名为“winnyterry”的业内人士：

唉，又见文科生神论！通篇的着眼点只有：速度。太片面了。每一代移动通信技术的革新，其它有三点是最重要的，按重要程度排序是：频谱利用率，时延，网速。

频谱资源不论什么时代在移动通信领域都是最为稀缺的，如何在有限不可再生的无线频谱下，容纳更多的并发数据，这是每一代移动通信进步最重要的出发点。特别是物联网时代，万物互联，频谱利用率不提高，一切都是空谈。

其次是时延，现在4g时延基本上能在20毫秒内，对于打游戏，是够了，但如果是VR应用和智能导航呢，又太慢了，测试要在8毫秒内，智能导航才不会错过执行指令的最佳时点。而5g据说时延能控制在5毫秒内。

而网速仅仅是每一代移动通信技术中重要性排在第三位的，可以说只是在提高频谱利用率和降低时延时顺便提高一下而已。对于用户而言，网速的感知最为明显，运营商设备商的宣传着墨于此不难理解，而前面的两点对于用户的感知远远没有第三点的网速明显，但切勿因此就认为移动通信技术就只是网速的提高，这样就大错特错了。

网名为“heipang”的业内人士：

有人说楼主是文科生观点，其实很多通信业内从业多年的人也会有类似观点。说几个自己的想法：

1. 视频是推动宽带发展的需求，但真的作用有限，有些厂商在大肆鼓吹视频和IPTV，其实无非是想多卖设备带宽，体验、运维这些问题在IP网络里没有提供有效的方案解决。

2. 有些需求真的是我们普通上班族体验不到的，每天早出晚归，三四十岁的人了，哪有时间玩游戏，VR/AR这些将来一定对网络的质量要求很高，也许要等到它们渗透到每个生活的角落，你才能感受到。

3. 物联网，个人觉得在部分场景里用处比较大，比如工业、农业、娱乐园区里，家里那点东西真的需要都联网么，有那个精力多陪孩子读点书吧。

4. 法律法规的建设如果不完善，大家怎么放心去联网，家里装个IP摄像头被入侵了咋办，放在云上的视频被流出怎么办：）当然这个担心有点多余，我们的发展模式一直都是野蛮生长再逐步约束。

网名为“risse”的业内人士：

不知道楼主为何这么抵触。带宽大延迟低，不好吗？难道想回到56K的时代？一张图片显示出来都要10来秒！

标清、高清、4K的视频真的是有很大的差别，不要看到现在网站上的在线播放视频，那些都是压缩了的，只是分辨率没有变而已，有机会你下载北京烤鸭完整版的4K视频看看，就知道区别了。

看了你所说的那么多，感觉你就像老一辈的那种没技术的技术而已。

时代的进步，离不开网络的发展，2G的时候你用手机玩游戏？3G的时候你用手机看视频？4G的时候这些都有了吧！5G的时候就不是简简单单的这些应用了。

网名为“jiu_mao”的业内人士：

各位，技术发展和业务的发展是相辅相成的，没有业务强有力的驱动，不会这么快产生一代又一代的通信技术的。5G也是如此，相信现在有很多炒作的概念，但我觉得更主要的动力还是来自于整个社会的进步、人们更高的需求。

楼主，从你鼓吹5G不如wifi加光宽带这一点来看，我觉得你可能是资深的工程师，但绝不会是移动通信相关的工程师！

网名为“frewave”的业内人士：

3GPP定义的5G最大速度是20G，这是指整个基站的速率，分配到个人的没那么多，5G的进步是通过新的技术极大提升频谱效率和基站容量，对于现有的技术，运营商为何不敢像固网那样包月？到了5G极快的的速率，低廉甚至包月的流量，极大的扩展了移动互联网的使用范围（包括万物互联），这些比固网更便利，基础设施上去了，应用才能推广，在2G时代，不可能有微信这类的应用。对于VR、AR这些应用，就像3G时代的智能手机，只有硬件条件到了，才会推广应用。4K的VR只是入门，楼主说的十几兆就够了，这是经过200倍的视频压缩比才能到的，在对延迟不敏感的视频场景问题不大，对直播或游戏就有问题了，这也是为何HTC的VR要有线连接。一两年后8K的VR才是基本配置。

楼主可能只是做固网的，对移动通信的理解还是不深！

网名为“lovebugzhang”的业内人士：

我觉得楼主还是有很多地方没理解上一贴那么多人反驳你的地方，特别是对频谱利用率，还有服务器的传输速度的理解有点问题。5G有很多优势，，低延迟只是其中之一，而且你逻辑并不清晰，低延迟是优势，自动驾驶是应用，不可混为一谈．你不可能因为自动驾驶这个应用距目前太遥远，就认为整个5G是忽悠的．

网名为“winddt”的业内人士：

立场影响观点。

在4G时代，就有wifi+光取代LTE的说法，结果大家都清楚了，各自都发展的很好。这个时代是你可以发展的很好，但你的光芒不是一定要让别人暗淡无光。

5G时代，wifi+光本就已经纳入5G系统的一部分了，这个在去年的IEEE802会议上已经确定了，以前还可以说lte和wifi两者互为补充，5G时代移动宽带和无线宽带深度融合，均成为整个5G系统的的重要组成部分。

网名为“cano”的业内人士：

之前在公众号上看过一篇关于5G的批评文章，有理有据，深以为然。这次本来是抱着寻找同道中人的念头入坑，没想到大失所望。

拜读了LZ第一篇文章之后，我就有了一个猜测，也闻到了一股熟悉的味道。在读了第二篇后，我觉得，我的猜测和那股味道终于被证实了。

楼主应该是搞固网接入和光通信的吧，从这两篇中大谈ISDN、ADSL、EPON、GPON、STN、PTN这些就能看出来。另外，楼主应该是北邮某教授的铁粉吧，第一篇中只是闻到的味道，第二篇中直接就点出了，呵呵。不过自从在某教授狂喷3G的文章中发现一个初中生都不会错的大漏洞后，我和某教授的文章基本就拜拜了。

我觉得LZ对于无线通信的基础知识，对于5G的基本目标和场景都缺乏最基本的认识。

有线通信和无线通信最大的不同在于信道。有线通信可以毫不费力的搞到一组正交信道，无线就要头拱地；有线通信发现一根管子不够了，再加一根就是了，无线还是头拱地……

对于5G的三大场景，或许那些回复也没说清楚，还请LZ自己回去看看。另外，请楼主注意，现在4G的基站也是对用户数和并发业务数有限制的，而且没你想象的那么多。

共襄盛举，帝联科技成为2017亚太CDN峰会金牌赞助商

机遇与挑战并存。用这句话来形容近两年的CDN行业再合适不过：一方面流量持续爆发，前景看好;另一方面竞争加剧，行业一片红海。这样的行业背景下，即将召开的2017年亚太CDN峰会具有特殊的意义。

“GFIC——2017亚太CDN峰会”由DVBCN&AsiaOTT(众视网)主办，将于2017年4月12日至13日在北京凯宾斯基大酒店(亮马桥50号)2楼举行。帝联科技作为CDN行业的领军企业之一，已经连续第五年深度参与亚太CDN峰会，自首届起从未缺席。

本次峰会，帝联科技将作为金牌赞助商，携重量级产品与技术亮相并发表演讲，与众多行业同仁一起，分享其对于行业发展的见解。



历届亚太CDN峰会全球顶级CDN合作伙伴

作为一家创立12年的老牌网络平台服务商，帝联科技成长、蜕变以及云服务平台形成的内在逻辑，本就代表着CDN行业生态化、精细化和智能化的方向，具有行业指导性意义。

帝联科技依靠分布式数据中心(IDC)起步，积累了广泛的客户群体，为开展CDN业务打下坚实基础。随着行业发展，公司业务重心逐步转向CDN行业。2007年，帝联科技推出7*24全国统一400客户服务热线，CDN平台储备带宽超250G，这也标志着帝联的第一次转型完成，CDN业务占据主导。

随后几年，借着互联网行业流量爆发的热潮，帝联科技资源和技术实力高速提升。截止2016年，公司500+CDN节点遍布全国，海外节点64个，带宽储备超过6.5T，形成了覆盖广、稳定强、价格优的高品质互联网资源，综合实力跃居行业前列。

随着流媒体业务剧增以及行业竞争的日趋激烈，传统CDN服务面临着前所未有的挑战。流量爆发之下，CDN平台构建必须进行升级。帝联科技投入了巨额资金，配置了大量优质设备和带宽资源，聘请了以CTO为首的业内知名技术人才，优化技术团队。

经过一年的努力，帝联科技逐步做到了资源部署精细化和网络链路动态选择智能化。其中，DnDns系统更是较大程度地实现了运维自动化，引领了CDN行业的技术趋势。

据帝联科技CTO洪克柱介绍：DnDns系统由帝联科技投入大量研发资源，完全自主开发而成。DnDns系统基础解系包含UDP/TCP，IPV4/6，泛域名，edns0-client-subnet，高性能Zone文件解析等;智能解析则包含精准动态更新的地址库，高效区域(view)拓扑分级策略，灵活简易的区域配置：个位数的配置文件，DNS切量迅速收敛：IP Ratio等。各项技术指标均处于行业前列。

从央视春晚直播到315晚会，再到近期火热的世界杯预选赛，DnDns系统已经在热点网络视频直播中发挥重要作用，大大的缩短了响应时间，为客户带来更流畅更快捷的服务。

十二年来，一步一个脚印的发展使帝联科技形成了稳固的资源、技术以及人才优势，也积累了超3000 家客户，其中包括腾讯、百度、阿里巴巴、360、京东、搜狐、新浪、网易、央视国际、广电集团、苏宁集团、中国移动、中国安全部门等一系列行业代表企业。并以良好的服务态度与技术升级赢得了客户赞许，在腾讯供应商评分中位居第一。

基础扎实是起飞的前提。帝联云存储、帝联弹性计算平台、帝联监控报警、帝联运营一体化系统等产品和系统方案将会为帝联科技向前发展持续提供动力。未来，帝联科技正在逐步成长为一家集数据存储、分发、计算、安全为一身的云服务平台。

关于2017亚太CDN峰会

“GFIC——2017亚太CDN峰会”由DVBCN&AsiaOTT(众视网)主办，是GFIC系列峰会中，围绕CDN如何为“宽带中国战略”做好基础服务，为电子政务，移动直播，在线视频，虚拟现实，智慧城市，人工智能，互联网金融行业等提供加速传输，云计算，云存储，大数据，安全防护，应用推广，流量变现等专业服务为主题的亚太区最大规模年度盛会。

亚太CDN峰会汇聚了全球多个国家，500多家企业，数千人参与。伴随着互联网高速发展的红利，“亚太CDN峰会”专注于聚焦内容分发领域，邀请来自Akamai、Fastly、Level3、Limelight、Telefonica、Orange、TWC、网宿、蓝汛、帝联、UCloud、云帆加速、阿里云、腾讯云、百度云、乐视、爱奇艺、PPTV聚力、高德地图、京东云、东方明珠、芒果TV、华数传媒等行业内的领袖企业，共同探索下一个互联网时代的内容分发新格局。

直播平台大火，最赚钱却是CDN网宿、帝联、快网、蓝汛、ucloud、腾讯云

   在十年前，视频网站刚刚兴起时，也是这般光景，当时视频网站也有数十家，其中两大巨额的开支，一是带宽支出，二是版权内容的购买成本，这两大成本支出让大多数独立视频网站难以为继，直至消失。最终的结局是优酷、土豆这两家最大的视频网站完成合并，而后又被阿里巴巴全资收购，腾讯视频和爱奇艺风靡，网络视频行业最终成为了互联网巨头们的独角戏。

直播平台步视频网站后尘，钱被传统CDN赚走，最终被巨头收割？

如今，直播平台似乎又要重蹈覆辙。根据IT桔子的数据统计，国内的直播创业平台多达288家，有很多直播平台还融到千万甚至过亿的融资。比如2015年11月，斗鱼TV获腾讯、南山资本、红杉1亿美元B轮融资；B站获超2亿人民币D轮融资；2016年3月易直播获A轮6000万人民币融资等等，而更多的直播创业平台都还在处在A轮。

不过，目前为止，这些直播平台基本上都未盈利，一边需要支付高额的带宽成本，另一边只是高价对明星主播资源的签约争夺，这看起来似乎又是一场类似于网络视频行业的“烧钱大战”，而结局似乎早已写好，在弹药补充足的情况下，有很多直播创业很可能将要倒在黎明之前。尤其是，近一年以来，国内的融资形势不容乐观，这更需要直播创业小心谨慎的“花钱”。

而与直播创业平台们面临的危险境遇形成鲜明对比则是，传统CDN厂商却在这一波直播平台创业浪潮当中，利用自身垄断的带宽资源优势大赚特赚。根据网宿科技助理总裁孙孝思在接受界面新闻记者采访时就表示，目前行业里80%的直播平台是网宿科技的客户。而目前直播创业平台最大的开支来自于带宽成本，在30%到50%之间，这是一家直播创业平台的最大头的运营成本支出，而这些支出基本上都流入了传统CDN厂商手里。

实际上，这些带宽成本的开支完全可以省下来一大半。目前国内能够为直播平台提供CDN服务的并不是仅仅只有传统CDN厂商，此外还有以阿里云、腾讯云为首的云服务厂商，以及以星域CDN为代表的创新型CDN服务商，他们提供的服务成本都要远低于传统CDN厂商。以星域CDN为例，其在今年5月份曾发布专为直播平台提供服务的产品，极速版的价格仅为传统CDN厂商的十分之一，仅为0.5元/Mbps/天；而旗舰版产品的价格更低，仅为0.27元/Mbps/天，只相当于传统CDN厂商的5%。这样的价格可以让直播创业平台的运营成本直线下降，可以使得直播平台逃离开烧钱大战的魔咒，从而能够将钱花在其他增加自身竞争力的用处上。

直播创业平台选择传统CDN，缘于三大行业认知误区

不过，既然创新CDN厂商的产品如此便宜，为何这些直播平台还是愿意选择网宿科技这样的传统CDN厂商呢？这可能是由于直播创业平台对于创新型的CDN服务商的认知误区所造成的，主要有以下三个方面：

第一，直播创业平台对于创新CDN厂商的产品和技术能力没有认识。对于直播平台而言，用户的观看体验至关重要，尤其是需要保证视频的清晰流畅的播放不发生卡顿，因此他们在选择CDN厂商时更倾向于选择传统CDN厂商，认为他们网络节点多，可以最大程度的得到保障。实际上，现在整个CDN行业已经进入到技术革新的阶段，而不再是原来那个粗放发展到时代。很多创新型的CDN厂商通过技术手段突破了原来的行业限制，从而能够以更低的成本提供更好的服务。以星域CDN为例，其首创“无限节点”技术，已经拥有了在全国布建百万量级服务节点的能力，其中包括400余个骨干节点和百万量级末梢节点，并且通过推出智能硬件产品赚钱宝以共享经济的方式首次实现了下沉至家庭内拉取内容数据，从而开辟出了一条总量更庞大、分布更均匀，数据传输距离可近至1km的网络加速通道，此外星域还有其独特的调度技术，以及动态防御和弱网加速技术等，这就意味着，在服务质量方面，创新型CDN厂商丝毫不输传统CDN厂商。

第二，很多直播创业平台对于创新CDN厂商的服务质量没有信心，误认为传统CDN厂商的成立时间更久，技术可能更加成熟。实际上，事实可能恰恰相反，尽管传统CDN厂商运营时间很长，但由于在云服务商和创新型CDN厂商出现之前，面临的竞争压力很小，导致传统CDN厂商在产品方面缺乏更多的创新，更多的是通过在全国各地架设节点来提高加大自己的带宽，而在具体的产品服务方面，尤其是针对不同的垂直行业方面，并不会及时的推出专业化的解决方案。相较而言，新兴的CDN服务商以产品创新立足，创新的意愿更为强烈，以星域CDN为例，其在今年5月推出了针对直播行业的新产品，而且还具体到了泛娱乐直播、教育直播、事件直播、移动户外直播、/全景直播等几个方面，这使得不同的直播创业平台可以选择更加专业化的服务。显然，在成本更低的情况下，创新CDN厂商对于直播创业平台的服务可能更加到位。

第三，很多直播创业平台选择传统CDN厂商主要看重其行业知名度，迷信其之前服务过的知名企业案例，而不是选择能够与其共进退的合作伙伴。实际上，在服务的主动性方面，创新CDN厂商可能更好，而传统CDN厂商由于长期以来占据着资源的垄断优势，普遍缺乏服务意识，更多的将直播平台看作是客户关系，而并不是合作伙伴，这就意味着并不会真正从合作伙伴的角度去着手解决问题，而更多的看重其营业收入，因此在这些年以来，带宽价格从来没有主动降价过，直到像星域这样的创新CDN厂商出现之后，带宽价格才有了小幅降低，但是仍然比云服务商和创新CDN厂商的价格高出许多。而早在2015年6月，网心科技CEO陈磊在接受媒体采访时就指出，传统CDN厂商的服务心态有问题。相较而言，创新CDN厂商更愿意与直播创业平台一起发展，也因如此，在星域CDN直播产品的发布会上，获得了包括小米直播、大鹏VR、触手TV等多家直播创业平台的力挺。

总体而言，在直播创业大火的当下，创业公司随时面临倒闭危险，而传统CDN厂商却赚的盆满钵满，这是非常不合理的现象。如此下去，独立的直播创业平台可能最终也只能是投入到巨头的门下，而如果想要改变这种不利的局面，第一步或许可以从降低带宽成本开始，而创新的CDN服务商无疑是一个不错的选择。

全民大直播，流媒体选择Nginx是福还是祸？

CDN，视频云，已经“僧多粥少”

视频直播的持续升温，无意间也让带宽生意的争夺变得异常残酷。一时间，各种云计算、CDN、视频云提供商都在视频尤其是直播上投入重兵，揭竿而起的新生起义军们也正马不停蹄的赶往这方战场，各种号称可以在IaaS、PaaS、SaaS不同层面提供平台级、接口级以及产品级服务的花式作战口号此起彼伏，让人眼花缭乱，“僧多粥少”可能成为了当前支撑视频技术解决方案市场最恰当的提法。如此局面之下，视频云和CDN们，技术上到底是在竞争什么？作为视频平台和即将要进入视频领域的运营者，在技术平台的选型和搭建上又如何才能避免掉入大坑？

一个播放器的背后

谁都知道视频直播最重要的是流畅和高清，但这光鲜亮丽的背后是技术和成本的双高门槛，是诸多技术环节艰难积累和苦逼的人肉运维。主播发起一个简单的直播，主干流程就历经了采集、编码、推流、转码、分发、拉流、解码和播放这么多环节，还要求在数秒内完成，除此之外直播还有如录制、流控、安全、审核等等诸多复杂功能需求。

再如下图，仅一个屌丝观众从播放器看这个主播，就可能出现如此多不可知情形发生。这个屌丝的接入网络怎么样？使用的系统环境又怎么样？一个观众尚且如此，要保障百万千万级别流畅的观看，难度可想而知。

高清流畅到底靠的是什么

也许对于部分视频运营商和新进入者来说，直播推流端和播放器端依然觉得头大，但整体来说，除移动端外，PC端推流和播放技术已经比较成熟。难，主要难在传输和分发！正常情况下，只要推流端网络状况良好，传输和分发决定着直播是否能够流畅。

传输和分发，涉及到了视频最核心技术、巨额服务器和带宽成本以及国内网络环境极度错综复杂。也因为如此，视频平台基本上都将传输和分发环节交由专业的第三方视频云服务商或CDN服务商来完成。我们从网络传输的七层中拿出与视频传输分发相关的四层，如下图：

L2资源层：对视频云和CDN来说，资源的确存在差别，但在其可承受范围内，可以视为差别不大；

L4传输层：传输层可针对不同业务场景，比如针对超低延迟可以基于UDP做私有协议等。本文侧重阐述视频流畅的保障，不同应用场景的支持后续文章将专门介绍；

L3网络层：视频云和CDN公司在该层实现各运营商网间打通、多层Cache系统设计以及用户就近调度。该层的设计及优化对访问质量极为重要，随着CDN技术的日益成熟，虽然各家可能存在架构区别，但基本都能保障网络路由正常运转；

L7应用层：抛开细枝末节，视频流的主线还是输入、传输与输出，承担这些工作的就是视频平台最核心组件流媒体服务器，这就是视频直播分发最本质的特点，需要专门的流媒体服务器来分发，所有视频云和CDN，都需要在中心层和边缘层部署流媒体Server。

 

通过以上逐层分析可知，当资源和网络层面相差不大的情况下，流媒体Server的性能决定了视频流分发的效果和质量，故流媒体Server才是视频云和CDN技术竞争的至高点。



市面主要的流媒体服务器对比

目前市面上主流的流媒体服务器，有以Adobe FMS、Real Helix、Wowza为代表的第一代产品，它们的特点是单进程多线程。基于Linux2.7 epoll技术，出现了以多进程单线程为特点的第二代流媒体服务器，NginxRTMP、Crtmpd为其优秀的代表，另外还有基于JAVA的流媒体祖先Red5等。

观止云开源流媒体服务器SRS（Simple RTMP Server），凭借其功能强大、轻量易用、特别适合互动直播等诸多特点备受海内外视频从业者的青睐。蓝汛Chiancache曾用SRS承载其直播边缘分发业务，高升CDN基于SRS搭建其流媒体基础平台，其它还有赛维安讯、VeryCDN、VeryCloud、云博视等也将SRS应用到了自身的业务当中。各家视频云、云计算平台在源站的对接上也非常注重对SRS的支持。SRS作为纯国产的开源Server，在中国流媒体业界实属难能可贵。

观止云源站集群BMS（Bravo Media Server）是SRS的商业版，BMS在SRS基础上增强了11项大功能，新增了9个大功能：

增项的11项大功能：



新增的9项大功能：





流媒体Server的话说来也不短，上述列举的目前市面上主流流媒体服务器中，有名副其实的先烈RED5，有生不逢时的CRTMPD，都未大规模商用就不过于讨论了。其中应用最为广泛莫属nginx-rtmp，以下是nginx-rtmp几个盛行于世的重要因素：

  • 2012年CDN业务开始极增长，随之直播需求也多了起来，彼时业界都还没有一套公认的特别满意的流媒体服务器；

  • Nginx是HTTP领域绝对的霸主，大家（尤其是CDN运维）对Nginx熟悉程度很高，便于上手维护；

  • 基于Nginx，直播点播使用一套服务器，这也极具诱惑力，一套管理起来总比多套要简单；

  • CDN是靠运维的行当，运维的信心都是长年运出来的，Nginx在图文上那么优秀，Nginx RTMP也差不了。



nginx-rtmp确实生来就自带光环外，性能也的确是高，比Crtmpd还要高。然而，时过境迁，随着互动直播、移动直播的强势兴起的大直播时代，选择nginx-rtmp到底是福还是祸？

下面小编将从协议支持、体系架构、核心功能支持、配置运维、性能、服务器日志、数据这七大维度将目前市面主流的流媒体Server做一个横向对比，供视频从业者根据自身业务场景特性择优选用。



1
网络协议对比

BMS支持HDS、DASH、RTMPE/S/T等协议的分发，这将支持更多业务应用场景，FLASH P2P的支持能够显著降低网络带宽成本。



2
体系架构对比

架构方面，较之于nginx-rtmp的16万行代码，SRS仅用了6.5万行代码就实现了比nginx-rtmp 多了230%的功能，nginx-rtmp注释率为3%，而SRS是23.7%。由此可见SRS在体系架构上的轻，Simple。

观止云BMS在SRS的基础上新增了多进程支持、源站集群、动态配置、可追溯日志等方面能力。源站集群子系统打通了跨网跨地区的源站分布式部署难题；动态配置子系统从业务系统读取配置，依据更新机制动态更新配置，保证直播业务配置变化时依然不中断；端到端的可追溯日志及监控排错子系统将直播故障定位时间缩短到了分钟级别。



3
核心功能对比

核心功能方面，BMS支持了当期互动直播、移动直播急需的大规模直播流实时转码、大规模录制、秒级低延迟、HLS+、并发回源等其它所有流媒体系统不具备的功能。HLS+基于每个播放请求实现了流媒体的“虚拟连接 ”（UUID标识），在减小回源量、排错、防盗链、移动Web端低延迟等方面具有诸多优势。并发回源能够解决回源网络状况差、跨国传输丢包严重等方面能够显著提升回源质量。



4
配置运维对比

以下仅是流媒体众多配置之中几个常用例子，运维日常工作中，需要操作的配置数量更多。

（1）vhost配置

FMS

拷贝默认vhost目录：sudo cp -r conf/_defaultRoot_/_defaultVHost_ conf/_defaultRoot_/bravo.sina.com



nginx-rtmp

不支持



SRS/BMS

动态获取配置文件：vhost bravo.sina.com { }

结论：BMS动态获取配置最简单

（2）app配置

 FMS

拷贝默认app目录：cp applications/live applications/mylive -r



nginx-rtmp

修改配置文件，增加如下内容：application live {  live on; }



SRS/BMS

无需配置

结论：BMS无需配置，最简单 

（3）http配置

在输出为hls、http-flv等基于http协议的直播流时，需要配置http服务

FMS

配置FMS内置的Apache服务器文件：Apache2.2/conf/httpd.conf

再修改如下字段：

<Location /hds-live>

    HttpStreamingEnabled true

    HttpStreamingLiveEventPath “../applications” 

    HttpStreamingContentPath “../applications” 

    HttpStreamingF4MMaxAge 2

    HttpStreamingBootstrapMaxAge 2

    HttpStreamingFragMaxAge -1

    Options -Indexes FollowSymLinks

</Location



nginx-rtmp

nginx本身就是一个http服务器，

修改其配置文件：

conf/nginx.conf

设置端口和根目录：

http {

    include       mime.types;

    default_type  application/octet-stream;

    sendfile        on;

    keepalive_timeout  65;

    server {

        listen       80;

        server_name  localhost;

        location /dash {

            root /tmp;

            add_header Cache-Control no-cache;

        }

    }

}



SRS/BMS

修改其配置文件：

conf/http.hls.conf

设置端口和根目录：

http_stream {

    enabled         on;

    listen          8080;

    dir             ./objs/nginx/html;

}

结论：nginx-rtmp需指定与app对应的ts文件存放目录，SRS/BMS会自动生成，更简单。

（4）推流、播放URL配置

RTMP直播时，各大服务器推流、播流URL均为：

rtmp://server_ip_or_dns/app/stream



用作HLS直播时，

FMS 

推流域名：

rtmp://fms-ip-or-dns/app/stream?adbe-live-event=liveevent

播流域名：

http://fms-ip-or-dns/hds-live/app/_definst_/liveevent/stream.f4m



nginx-rtmp

推流域名：

rtmp://server_ip_or_dns/app/stream

播流域名：

http://server_ip_or_dns/app/stream.m3u8



SRS/BMS

同nginx-rtmp

结论：nginx-rtmp、SRS/BMS均简单，FMS较复杂。



5
性能

先说结论：

SRS单进程能支持9000并发，nginx-rtmp单进程最多支持3000个，单进程的性能SRS是nginx-rtmp的三倍。单进程性能SRS > nginx-rtmp > crtmpd > wowza > fms > RED5

 

再例举SRS性能如此高的几个原因：

1. st-load，这个是SRS能做到高性能的最重要的原因，一个st-load可以模拟2000+的客户端，如果没有st-load，如何知道系统的性能瓶颈在哪里？总不能打开3000个flash页面播放rtmp流吧？开启3000个ffmpeg来抓流？高性能不是想象和猜测出来的，而是反复测试、调试和改进出来的。

2. gperf/gprof性能，编译SRS时，就可以打开gcp或者gprof的性能分析选项，非常方便的拿到数据。缩短了改进和优化开发周期。

3. 引用计数的msgs避免内存拷贝。

4. 使用writev发送chunked包，避免消息到chunked包的内存拷贝。

5. mw(merged-write)技术，即一次发送多个消息。

6. 减少timeout recv，每个连接都是一个st-thread在服务。

7. fast buffer和cache。

8. vector还是list？vector！vector比list高10%性能。



6
服务器日志

日志是定位故障的唯一途径，定位故障才能快速排错。可以这么说，对于直播，10分钟的排错，谁都会觉得长。然而，当前的视频云或CDN，谁又能做到10分钟呢？

来看看日志吧。

FMS的日志是这样的，恕我愚钝，你能看得出什么信息么？

2015-03-24 12:23:58 3409 (s)2641173 Accepted a connection from IP:192.168.1.141, referrer:http://www.ossrs.net/players/srs_player/release/srs_player.swf?_version=1.23,pageurl: http://www.ossrs.net/players/srs_player.html?vhost=dev&stream=livestream&server=dev&port=1935-

702111234525315439     3130         3448         normal      livestream         –        –         rtmp://192.168.1.185:1935/live/livestream     rtmp://192.168.1.185:1935/live/livestream        –        flv     –        –        0       –        0       0         –        –    http://www.ossrs.net/players/srs_player.html?vhost=dev&stream=livestream&server=dev&port=1935    -1      -1.000000         

crtmpd的日志详细，但我又愚钝，若是上千人在线，你又能看出什么有用的东西么？

/home/winlin/tools/crtmpserver.20130514.794/sources/thelib/src/netio/epoll/iohandlermanager.cpp:120Handlers count changed: 15->16 IOHT_TCP_CARRIER

/home/winlin/tools/crtmpserver.20130514.794/sources/thelib/src/netio/epoll/tcpacceptor.cpp:185Client connected: 192.168.1.141:54823 -> 192.168.1.173:1935

/home/winlin/tools/crtmpserver.20130514.794/sources/applications/appselector/src/rtmpap

curl实践HTTP206状态:部分内容和范围请求

HTTP 2xx范围内的状态码表明了:”客户端发送的请求已经被服务器接受并且被成功处理了”.HTTP/1.1 200 OK是HTTP请求成功后的标准响应,当你在浏览器中打开www.cyberciti.biz后,你通常会得到一个200状态码.HTTP/1.1 206状态码表示的是:”客户端通过发送范围请求头Range抓取到了资源的部分数据”.这种请求通常用来:

  1. 学习http头和状态.
  2. 解决网路问题.
  3. 解决大文件下载问题.
  4. 解决CDN和原始HTTP服务器问题.
  5. 使用工具例如lftp,wget,telnet测试断电续传.
  6. 测试将一个大文件分割成多个部分同时下载.

查明远程服务器是否支持HTTP 206

首先你需要知道文件大小以及远程服务器是否支持HTTP 206请求.使用curl命令可以查看任意资源的HTTP头,使用下面的curl命令可以发送一个HEAD请求: 

$ curl -I http://s0.cyberciti.org/images/misc/static/2012/11/ifdata-welcome-0.png

输出结果为: 

HTTP/1.0 200 OK
Content-Type: image/png
Content-Length: 36907
Connection: keep-alive
Server: nginx
Date: Wed, 07 Nov 2012 00:44:47 GMT
X-Whom: l3-com-cyber
Cache-Control: public, max-age=432000000
Expires: Fri, 17 Jul 2026 00:44:46 GMT
Accept-Ranges: bytes
ETag: "278099835"
Last-Modified: Mon, 05 Nov 2012 23:06:34 GMT
Age: 298127

其中有两个我们比较关注的请求头:

Accept-Ranges: bytes – 该响应头表明服务器支持Range请求,以及服务器所支持的单位是字节(这也是唯一可用的单位).我们还能知道:服务器支持断点续传,以及支持同时下载文件的多个部分,也就是说下载工具可以利用范围请求加速下载该文件.Accept-Ranges: none 响应头表示服务器不支持范围请求.

Content-Length: 36907 –  Content-Length响应头表明了响应实体的大小,也就是真实的图片文件的大小是36907字节 (37K).

如何发送一个range请求头?

现在,你知道了该图片所在的服务器支持范围请求,你需要发送一个包含Range请求头的GET请求: 

Range: bytes=0-1024

完整的请求数据应该是这样的.首先第一行是: 

GET /images/misc/static/2012/11/ifdata-welcome-0.png HTTP/1.1

然后需要发送Host请求头来指定请求资源所在的主机和端口号: 

Host: s0.cyberciti.org

最后是要发送的Range请求头,指定了你想要的字节范围: 

Range: bytes=0-1024

使用telnet命令

telnet命令允许你使用Telnet协议来与远程主机(服务器)进行通信.所有的类Unix操作系统以及MS-Windows都包含有Telnet客户端.启动Telnet客户端并进入Telnet提示符,要执行命令: 

telnet your-server-name-here www
telnet your-server-name-here 80

想要通过端口号80连接远程服务器s0.cyberciti.org,输入: 

telnet s0.cyberciti.org 80

输出结果为: 

Trying 54.240.168.194...
Connected to d2m4hyssawyie7.cloudfront.net.
Escape character is '^]'.

在本例中,使用范围请求(0-1024 字节)来请求s0.cyberciti.org上的/images/misc/static/2012/11/ifdata-welcome-0.png文件,输入: 

GET /images/misc/static/2012/11/ifdata-welcome-0.png HTTP/1.1
Host: s0.cyberciti.org
Range: bytes=0-1024

输出结果为:

Fig.01: Telnet command Range-requests bytes header example (HTTP 206)

上图中,

  1. 区域1 – GET请求以及请求头.
  2. 区域2 – 206状态以及响应头.
  3. 区域3 – 二进制数据.

使用curl命令

curl命令是一个和远程服务器交换数据的工具.它支持HTTP/FTPSFTP/FILE协议上的范围请求,在下例中,使用两段范围来请求远程文件ifdata-welcome-0.png,然后使用cat命令将两段数据合并成完整文件: 

curl  --header "Range: bytes=0-20000" http://s0.cyberciti.org/images/misc/static/2012/11/ifdata-welcome-0.png -o part1
curl  --header "Range: bytes=20001-36907" http://s0.cyberciti.org/images/misc/static/2012/11/ifdata-welcome-0.png -o part2 cat part1 part2 >> test1.png
gnome-open test1.png

还可以使用-r选项(可以同时添加-v选项查看请求头和响应头): 

curl  -r 0-20000 http://s0.cyberciti.org/images/misc/static/2012/11/ifdata-welcome-0.png -o part1
curl  -r 20001-36907 http://s0.cyberciti.org/images/misc/static/2012/11/ifdata-welcome-0.png -o part2 cat part1 part2 >> test2.png
gnome-open test2.png

如何开启Accept-Ranges响应头?

大部分web服务器都原生支持字节范围请求. Apache 2.x用户可以在httpd.conf中尝试mod_headers: 

Header set Accept-Ranges bytes

Lighttpd用户尝试在lighttpd.conf中进行下面的配置: 

## enabled for all file types ##
server.range-requests = "enable" ## But, disable it for pdf files ##
$HTTP["url"] =~ "\.pdf$" { server.range-requests = "disable" }

移动直播技术秒开优化经验（含PPT）

徐立，七牛创始合伙人兼产品副总裁，负责七牛直播云的整体研发，是国内 Go / Docker / Container 技术早期布道者，Go / Containers / Distributed Systems 技术的忠实爱好者和实践者。曾合著国内第一本 Go 语言图书《Go 语言编程》，翻译《Go 语言程序设计》。

现今移动直播技术上的挑战要远远难于传统设备或电脑直播，其完整的处理环节包括但不限于：音视频采集、美颜/滤镜/特效处理、编码、封包、推流、转码、分发、解码/渲染/播放等。

直播常见的问题包括

  • 主播在不稳定的网络环境下如何稳定推流？

  • 偏远地区的观众如何高清流畅观看直播？

  • 直播卡顿时如何智能切换线路？

  • 如何精确度量直播质量指标并实时调整？

  • 移动设备上不同的芯片平台如何高性能编码和渲染视频？

  • 美颜等滤镜特效处理怎么做？

  • 如何实现播放秒开？

  • 如何保障直播持续播放流畅不卡顿？

本次分享将为大家揭开移动直播核心技术的神秘面纱。

视频、直播等基础知识

什么是视频？

首先我们需要理解一个最基本的概念：视频。从感性的角度来看，视频就是一部充满趣味的影片，可以是电影，可以是短片，是一连贯的视觉冲击力表现丰富的画面和音频。但从理性的角度来看，视频是一种有结构的数据，用工程的语言解释，我们可以把视频剖析成如下结构：

内容元素 ( Content )

  • 图像 ( Image )

  • 音频 ( Audio )

  • 元信息 ( Metadata ) 

编码格式 ( Codec )

  • Video : H.264，H.265, …

  • Audio : AAC， HE-AAC, …

容器封装 (Container)

  • MP4，MOV，FLV，RM，RMVB，AVI，…

任何一个视频 Video 文件，从结构上讲，都是这样一种组成方式：

  • 由图像和音频构成最基本的内容元素；

  • 图像经过视频编码压缩格式处理（通常是 H.264）；

  • 音频经过音频编码压缩格式处理（例如 AAC）；

  • 注明相应的元信息（Metadata）；

最后经过一遍容器（Container）封装打包（例如 MP4），构成一个完整的视频文件。

如果觉得难以理解，可以想象成一瓶番茄酱。最外层的瓶子好比这个容器封装（Container），瓶子上注明的原材料和加工厂地等信息好比元信息（Metadata），瓶盖打开（解封装）后，番茄酱本身好比经过压缩处理过后的编码内容，番茄和调料加工成番茄酱的过程就好比编码（Codec），而原材料番茄和调料则好比最原本的内容元素（Content）。

视频的实时传输

简而言之，理性的认知视频的结构后，有助于我们理解视频直播。如果视频是一种“有结构的数据”，那么视频直播无疑是实时传输这种“有结构的数据”（视频）的方式。

那么一个显而易见的问题是：如何实时（Real-Time）传输这种“有结构的数据”（视频）呢？

这里边一个悖论是：一个经过容器（Container）封装后的视频，一定是不可变的 ( Immutable ) 视频文件，不可变的 ( Immutable ) 的视频文件已经是一个生产结果，根据“相对论”，而这个生产结果显然不可能精确到实时的程度，它已经是一段时空的记忆。

因此视频直播，一定是一个 “边生产，边传输，边消费”的过程。这意味着，我们需要更近一步了解视频从原始的内容元素 ( 图像和音频 ) 到成品 ( 视频文件 ) 之前的中间过程 ( 编码 )。

视频编码压缩

不妨让我们来深入浅出理解视频编码压缩技术。

为了便于视频内容的存储和传输，通常需要减少视频内容的体积，也就是需要将原始的内容元素(图像和音频)经过压缩，压缩算法也简称编码格式。例如视频里边的原始图像数据会采用 H.264 编码格式进行压缩，音频采样数据会采用 AAC 编码格式进行压缩。

视频内容经过编码压缩后，确实有利于存储和传输; 不过当要观看播放时，相应地也需要解码过程。因此编码和解码之间，显然需要约定一种编码器和解码器都可以理解的约定。就视频图像编码和解码而言，这种约定很简单：

编码器将多张图像进行编码后生产成一段一段的 GOP ( Group of Pictures ) ， 解码器在播放时则是读取一段一段的 GOP 进行解码后读取画面再渲染显示。

GOP ( Group of Pictures ) 是一组连续的画面，由一张 I 帧和数张 B / P 帧组成，是视频图像编码器和解码器存取的基本单位，它的排列顺序将会一直重复到影像结束。

I 帧是内部编码帧（也称为关键帧），P 帧是前向预测帧（前向参考帧），B 帧是双向内插帧（双向参考帧）。简单地讲，I 帧是一个完整的画面，而 P 帧和 B 帧记录的是相对于 I 帧的变化。

如果没有 I 帧，P 帧和 B 帧就无法解码。

小结一下，一个视频 ( Video ) ，其图像部分的数据是一组 GOP 的集合, 而单个 GOP 则是一组 I / P / B 帧图像的集合。

在这样的一种几何关系中，Video 好比一个 “物体”，GOP 好比 “分子”，I / P / B 帧的图像则好比 “原子”。

想象一下，如果我们把传输一个 “物体”，改成传输一个一个的 “原子”，将最小颗粒以光速传送，那么以人的生物肉眼来感知，将是一种怎样的体验？

什么是视频直播？

不难脑洞大开一下，直播就是这样的一种体验。视频直播技术，就是将视频内容的最小颗粒 ( I / P / B 帧，…)，基于时间序列，以光速进行传送的一种技术。

简而言之，直播就是将每一帧数据 ( Video / Audio / Data Frame )，打上时序标签 ( Timestamp ) 后进行流式传输的过程。发送端源源不断的采集音视频数据，经过编码、封包、推流，再经过中继分发网络进行扩散传播，播放端再源源不断地下载数据并按时序进行解码播放。如此就实现了 “边生产、边传输、边消费” 的直播过程。

理解以上两个关于 视频 和 直播 两个基础概念后，接下来我们就可以一窥直播的业务逻辑了。

直播的业务逻辑

如下是一个最精简的一对多直播业务模型，以及各个层级之间的协议。

各协议差异对比如下

以上就是关于直播技术的一些基础概念。下面我们进一步了解下影响人们视觉体验的直播性能指标。

影响视觉体验的直播性能指标

直播第一个性能指标是延迟，延迟是数据从信息源发送到目的地所需的时间。

根据爱因斯坦的狭义相对论，光速是所有能量、物质和信息运动所能达到的最高速度，这个结论给传播速度设定了上限。因此，即便我们肉眼感觉到的实时，实际上也是有一定的延迟。

由于 RTMP/HLS 是基于 TCP 之上的应用层协议，TCP 三次握手，四次挥手，慢启动过程中的每一次往返来回，都会加上一次往返耗时 ( RTT )，这些交互过程都会增加延迟。

其次根据 TCP 丢包重传特性，网络抖动可能导致丢包重传，也会间接导致延迟加大。

一个完整的直播过程，包括但不限于以下环节：采集、处理、编码、封包、推流、传输、转码、分发、拉流、解码、播放。从推流到播放，再经过中间转发环节，延迟越低，则用户体验越好。

第二个直播性能指标卡顿，是指视频播放过程中出现画面滞帧，让人们明显感觉到“卡”。单位时间内的播放卡顿次数统计称之为卡顿率。

造成卡顿的因素有可能是推流端发送数据中断，也有可能是公网传输拥塞或网络抖动异常，也有可能是终端设备的解码性能太差。卡顿频次越少或没有，则说明用户体验越好。

第三个直播性能指标首屏耗时，指第一次点击播放后，肉眼看到画面所等待的时间。技术上指播放器解码第一帧渲染显示画面所花的耗时。通常说的 “秒开”，指点击播放后，一秒内即可看到播放画面。首屏打开越快，说明用户体验越好。

如上三个直播性能指标，分别对应一个低延迟、高清流畅、极速秒开 的用户体验诉求。了解这三个性能指标，对优化移动直播 APP 的用户体验至关重要。

那么移动直播场景下具体而言有哪些常见的坑呢？

根据实践总结下来的经验，移动平台上视频直播的坑主要可以总结为两方面：设备差异，以及网络环境这些场景下带来的技术考验。

移动直播场景的坑与规避措施

不同芯片平台上的编码差异

iOS 平台上无论硬编还是软编，由于是 Apple 一家公司出厂，几乎不存在因为芯片平台不同而导致的编码差异。

然而，在 Android 平台上，Android Framework SDK 提供的 MediaCodec 编码器，在不同的芯片平台上，差异表现很大， 不同的厂家使用不同的芯片，而不同的芯片平台上 Android MediaCodec 表现略有差异，通常实现全平台兼容的成本不低。

另外就是 Android MediaCodec 硬编层面的 H.264 编码画质参数是固定的 baseline，所以画质通常也一般。因此，在 Android 平台下，推荐是用软编，好处是画质可调控，兼容性也更好。

低端设备如何上高性能地采集和编码？

例如 Camera 采集输出的可能是图片，一张图的体积并不会小，如果采集的频次很高，编码的帧率很高，每张图都经过编码器，那么编码器又可能会出现过载。

这个时候，可以考虑在编码前，不影响画质的前提下（前面我们讲过帧率的微观意义），进行选择性丢帧，以此降低编码环节的功耗开销。

弱网下如何保障高清流畅推流

移动网络下，通常容易遇到网络不稳定，连接被重置，断线重连，一方面频繁重连，建立连接需要开销。另一方面尤其是发生 GPRS / 2G / 3G / 4G 切换时，带宽可能出现瓶颈。当带宽不够，帧率较高/码率较高的内容较难发送出去，这个时候就需要可变码率支持。

即在推流端，可检测网络状态和简单测速，动态来切换码率，以保障网络切换时的推流流畅。

其次编码、封包、推流 这一部分的逻辑也可以做微调，可以尝试选择性丢帧，比如优先丢视频参考帧（不丢 I 帧和音频帧 )，这样也可以减少要传输的数据内容，但同时又达到了不影响画质和版视听流畅的目的。

需要区分直播流的状态和业务状态

直播是媒体流、APP 的交互是 API 信令流，两者的状态不能混为一谈。尤其是不能基于 APP 的交互的 API 状态来判断直播流的状态。

以上是移动直播场景下常见的几个坑和规避措施。

移动直播场景其他优化措施

一、怎么优化打开速度，达到传说中的 “秒开”？

大家可能会看到，市面上某些手机直播 APP 的打开速度非常快，一点就开。而某些手机直播 APP，点击播放后要等好几秒以后才能播放。是什么原因导致如此的天壤之别呢？

大部分播放器都是拿到一个完成的 GOP 后才能解码播放，基于 FFmpeg 移植的播放器甚至需要等待音画时间戳同步后才能播放（如果一个直播里边没有音频只有视频相当于要等待音频超时后才能播放画面）。

“秒开”可以从以下几个方面考虑：

1. 改写播放器逻辑让播放器拿到第一个关键帧后就给予显示。

GOP 的第一帧通常都是关键帧，由于加载的数据较少，可以达到 “首帧秒开”。

如果直播服务器支持 GOP 缓存，意味着播放器在和服务器建立连接后可立即拿到数据，从而省却跨地域和跨运营商的回源传输时间。

GOP 体现了关键帧的周期，也就是两个关键帧之间的距离，即一个帧组的最大帧数。假设一个视频的恒定帧率是 24fps（即1秒24帧图像），关键帧周期为 2s，那么一个 GOP 就是 48 张图像。一般而言，每一秒视频至少需要使用一个关键帧。

增加关键帧个数可改善画质（GOP 通常为 FPS 的倍数），但是同时增加了带宽和网络负载。这意味着，客户端播放器下载一个 GOP，毕竟该 GOP 存在一定的数据体积，如果播放端网络不佳，有可能不是能够快速在秒级以内下载完该 GOP，进而影响观感体验。

如果不能更改播放器行为逻辑为首帧秒开，直播服务器也可以做一些取巧处理，比如从缓存 GOP 改成缓存双关键帧（减少图像数量），这样可以极大程度地减少播放器加载 GOP 要传输的内容体积。

2. 在 APP 业务逻辑层面方面优化。

比如提前做好 DNS 解析（省却几十毫秒），和提前做好测速选线（择取最优线路）。经过这样的预处理后，在点击播放按钮时，将极大提高下载性能。

一方面，可以围绕传输层面做性能优化；另一方面，可以围绕客户播放行为做业务逻辑优化。两者可以有效的互为补充，作为秒开的优化空间。

二、美颜等滤镜如何处理？

在手机直播场景下，这就是一个刚需。没有美颜功能的手机直播 APP，主播基本不爱用。可以在采集画面后，将数据送给编码器之前，将数据源回调给滤镜处理程序，原始数据经过滤镜处理完后，再送回给编码器进行编码即可。

除了移动端可以做体验优化之外，直播流媒体服务端架构也可以降低延迟。例如收流服务器主动推送 GOP 至边缘节点，边缘节点缓存 GOP，播放端则可以快速加载，减少回源延迟。

其次，可以贴近终端就近处理和分发

三、如何保障直播持续播放流畅不卡顿？

“秒开”解决的是直播首次加载的播放体验，如何保障直播持续播放过程中的画面和声音视听流畅呢？因为，一个直播毕竟不是一个 HTTP 一样的一次性请求，而是一个 Socket 层面的长连接维持，直到直到主播主动终止推流。

上述我们讲过卡顿的定义：即播放时画面滞帧，触发了人们的视觉感受。在不考虑终端设备性能差异的情况下，针对网络传输层面的原因，我们看看如何保障一个持续的直播不卡顿。

这其实是一个直播过程中传输网络不可靠时的容错问题。例如，播放端临时断网了，但又快速恢复了，针对这种场景，播放端如果不做容错处理，很难不出现黑屏或是重新加载播放的现象。

为了容忍这种网络错误，并达到让终端用户无感知，客户端播放器可以考虑构建一个FIFO（先进先出）的缓冲队列，解码器从播放缓存队列读取数据，缓存队列从直播服务器源源不断的下载数据。通常，缓存队列的容量是以时间为单位（比如3s），在播放端网络不可靠时，客户端缓存区可以起到“断网无感”的过渡作用。

显然，这只是一个“缓兵之计”，如果直播服务器边缘节点出现故障，而此时客户端播放器又是长连接，在无法收到对端的连接断开信号，客户端的缓冲区容量再大也不管用了，这个时候就需要结合客户端业务逻辑来做调度。

重要的是客户端结合服务端，可以做精准调度。在初始化直播推流之前，例如基于 IP 地理位置和运营商的精确调度，分配线路质量最优的边缘接入节点。在直播推流的过程中，可以实时监测帧率反馈等质量数据，基于直播流的质量动态调整线路。

Q&A 

1. 关键帧设置频率一般是多少？有没有根据接入动态设置？过长首屏秒会很难做到。

徐立：关键帧间隔越长，也就是 GOP 越长，理论上画面越高清。但是生成 HLS 直播时，最小切割粒度也是一个 GOP，所以针对交互直播，通常不建议 GOP 设置太长。直播一般 2 个关键帧间隔即可。比如帧率是 24fps， 那么 2 个关键帧的间隔就是 48fps ，这个 GOP 就是2s。

2. 七牛这个直播是用的网宿加速？有遇到什么坑没？

徐立：七牛在直播方面主要是自建节点，也支持融合众多第三方 CDN 服务商，多样化的线路组合为客户提供更优质的服务。在和第三方 CDN 合作的过程中遇到的问题等有机会再做更细粒度的交流和分享。

3. RTMP 直播流除了优化线路外，还有什么加速手段吗？

徐立：物理上优化线路，逻辑上优化策略，比如选择性丢帧，不影响编码画质的前提下减轻传输体积。

4. OBS 推流，播放端 HLS 出现视/音频不同步是哪个环节的问题？怎么优化？

徐立：有可能是采集端的问题，如果是采集端编码环节就出现音画不同步，可以在收流服务器上做音画时间戳同步，这样是全局的校对。如果是播放端解码性能问题，那么需要调节播放逻辑，比如保证音画时间戳强一致性的前提下，选择性丢一部帧。

5. PPT 前几页中一个概念好像错了，I 帧不是关键帧，IDR 帧才是。IDR 帧是 I 帧，但是 I 帧不一定是 IDR 帧。只有 IDR 帧才是可重入的。

徐立：中文都把 I 帧翻译成关键帧了，不过既然提到了 IDR 帧，可以展开说明一下。所有的 IDR 帧都是 I 帧，但是并不是所有 I 帧都是 IDR 帧，IDR 帧是 I 帧的子集。I 帧严格定义是帧内编码帧，由于是一个全帧压缩编码帧，通常用 I 帧表示 “关键帧”。IDR 是基于 I 帧的一个 “扩展”，带了控制逻辑，IDR 图像都是 I 帧图像，当解码器解码到 IDR 图像时，会立即将参考帧队列清空，将已解码的数据全部输出或抛弃。重新查找参数集，开始一个新的序列。这样如果前一个序列出现重大错误，在这里可以获得重新同步的机会。IDR 图像之后的图像永远不会使用 IDR 之前的图像的数据来解码。

6. 有没有调研过 nginx rtmp module，为什么没有用，对它有什么评价？

徐立：有调研过，nginx_rtmp_module 是单进程多线程，非 go 这种轻量级线程/协程用并发自然语义的方式编写流业务。nginx 原本的代码量较大（约 16 万行，但和直播业务相关的功能并不是很多）。且主要靠写 nginx.conf 做配置租户，通常单租户可以，但业务可扩展性方面不是很灵活，可满足基本需求，不满足高级功能。

7. 用到了那些开源软件？编码用的是 x264 吗？直播服务器你们自己开发还是开源的？

徐立：直播服务器用 go 开发的，移动端编码优先硬编，软编用 x264

8. 请教一下用 OBS 推流到 nginx_rtmp_module 的时候是已经做了视频压缩了还是需要基于 OBS 再开发？

徐立：OBS 把编码压缩都做了，不需要再开发。

9. 视频直播想在 HLS 流中无缝插入一段广告的 ts 文件，有问题想请教一下：1、这段 ts 的分辨率是否一定要和之前的视频流一致？2、pts 时间戳是否要和上一个 ts 递增？

徐立：1、可以不一致。这种情况两段视频完全是独立状态，可以没有任何关系，只需要插入 discontinue 标记，播放器在识别到这个标记之后重置解码器参数就可以无缝播放，画面会很平滑的切换。2、不需要递增。举个例子，视频 A 正在直播，播放到 pts 在 5s 的时候，插入一个视频 B，需要先插入一个 discontinue，再插入 B，等 B 播放完之后，再插入一个 discontinue，再插入 A，这个时候 A 的 pts 可以和之前递增，也可以按照中间插入的 B 的时长做偏移，一般做点播和时移的时候 pts 会连续递增，直播的话会算上 B 的时长。

PPT 下载地址

全民大直播，流媒体选择Nginx是福还是祸？

CDN，视频云，已经“僧多粥少”

视频直播的持续升温，无意间也让带宽生意的争夺变得异常残酷。一时间，各种云计算、CDN、视频云提供商都在视频尤其是直播上投入重兵，揭竿而起的新生起义军们也正马不停蹄的赶往这方战场，各种号称可以在IaaS、PaaS、SaaS不同层面提供平台级、接口级以及产品级服务的花式作战口号此起彼伏，让人眼花缭乱，“僧多粥少”可能成为了当前支撑视频技术解决方案市场最恰当的提法。如此局面之下，视频云和CDN们，技术上到底是在竞争什么？作为视频平台和即将要进入视频领域的运营者，在技术平台的选型和搭建上又如何才能避免掉入大坑？

一个播放器的背后

谁都知道视频直播最重要的是流畅和高清，但这光鲜亮丽的背后是技术和成本的双高门槛，是诸多技术环节艰难积累和苦逼的人肉运维。主播发起一个简单的直播，主干流程就历经了采集、编码、推流、转码、分发、拉流、解码和播放这么多环节，还要求在数秒内完成，除此之外直播还有如录制、流控、安全、审核等等诸多复杂功能需求。

再如下图，仅一个屌丝观众从播放器看这个主播，就可能出现如此多不可知情形发生。这个屌丝的接入网络怎么样？使用的系统环境又怎么样？一个观众尚且如此，要保障百万千万级别流畅的观看，难度可想而知。

高清流畅到底靠的是什么

也许对于部分视频运营商和新进入者来说，直播推流端和播放器端依然觉得头大，但整体来说，除移动端外，PC端推流和播放技术已经比较成熟。难，主要难在传输和分发！正常情况下，只要推流端网络状况良好，传输和分发决定着直播是否能够流畅。

传输和分发，涉及到了视频最核心技术、巨额服务器和带宽成本以及国内网络环境极度错综复杂。也因为如此，视频平台基本上都将传输和分发环节交由专业的第三方视频云服务商或CDN服务商来完成。我们从网络传输的七层中拿出与视频传输分发相关的四层，如下图：

L2资源层：对视频云和CDN来说，资源的确存在差别，但在其可承受范围内，可以视为差别不大；

L4传输层：传输层可针对不同业务场景，比如针对超低延迟可以基于UDP做私有协议等。本文侧重阐述视频流畅的保障，不同应用场景的支持后续文章将专门介绍；

L3网络层：视频云和CDN公司在该层实现各运营商网间打通、多层Cache系统设计以及用户就近调度。该层的设计及优化对访问质量极为重要，随着CDN技术的日益成熟，虽然各家可能存在架构区别，但基本都能保障网络路由正常运转；

L7应用层：抛开细枝末节，视频流的主线还是输入、传输与输出，承担这些工作的就是视频平台最核心组件流媒体服务器，这就是视频直播分发最本质的特点，需要专门的流媒体服务器来分发，所有视频云和CDN，都需要在中心层和边缘层部署流媒体Server。

 

通过以上逐层分析可知，当资源和网络层面相差不大的情况下，流媒体Server的性能决定了视频流分发的效果和质量，故流媒体Server才是视频云和CDN技术竞争的至高点。



市面主要的流媒体服务器对比

目前市面上主流的流媒体服务器，有以Adobe FMS、Real Helix、Wowza为代表的第一代产品，它们的特点是单进程多线程。基于Linux2.7 epoll技术，出现了以多进程单线程为特点的第二代流媒体服务器，NginxRTMP、Crtmpd为其优秀的代表，另外还有基于JAVA的流媒体祖先Red5等。

观止云开源流媒体服务器SRS（Simple RTMP Server），凭借其功能强大、轻量易用、特别适合互动直播等诸多特点备受海内外视频从业者的青睐。蓝汛Chiancache曾用SRS承载其直播边缘分发业务，高升CDN基于SRS搭建其流媒体基础平台，其它还有赛维安讯、VeryCDN、VeryCloud、云博视等也将SRS应用到了自身的业务当中。各家视频云、云计算平台在源站的对接上也非常注重对SRS的支持。SRS作为纯国产的开源Server，在中国流媒体业界实属难能可贵。

观止云源站集群BMS（Bravo Media Server）是SRS的商业版，BMS在SRS基础上增强了11项大功能，新增了9个大功能：

增项的11项大功能：



新增的9项大功能：





流媒体Server的话说来也不短，上述列举的目前市面上主流流媒体服务器中，有名副其实的先烈RED5，有生不逢时的CRTMPD，都未大规模商用就不过于讨论了。其中应用最为广泛莫属nginx-rtmp，以下是nginx-rtmp几个盛行于世的重要因素：

  • 2012年CDN业务开始极增长，随之直播需求也多了起来，彼时业界都还没有一套公认的特别满意的流媒体服务器；

  • Nginx是HTTP领域绝对的霸主，大家（尤其是CDN运维）对Nginx熟悉程度很高，便于上手维护；

  • 基于Nginx，直播点播使用一套服务器，这也极具诱惑力，一套管理起来总比多套要简单；

  • CDN是靠运维的行当，运维的信心都是长年运出来的，Nginx在图文上那么优秀，Nginx RTMP也差不了。



nginx-rtmp确实生来就自带光环外，性能也的确是高，比Crtmpd还要高。然而，时过境迁，随着互动直播、移动直播的强势兴起的大直播时代，选择nginx-rtmp到底是福还是祸？

下面小编将从协议支持、体系架构、核心功能支持、配置运维、性能、服务器日志、数据这七大维度将目前市面主流的流媒体Server做一个横向对比，供视频从业者根据自身业务场景特性择优选用。



1
网络协议对比

BMS支持HDS、DASH、RTMPE/S/T等协议的分发，这将支持更多业务应用场景，FLASH P2P的支持能够显著降低网络带宽成本。



2
体系架构对比

架构方面，较之于nginx-rtmp的16万行代码，SRS仅用了6.5万行代码就实现了比nginx-rtmp 多了230%的功能，nginx-rtmp注释率为3%，而SRS是23.7%。由此可见SRS在体系架构上的轻，Simple。

观止云BMS在SRS的基础上新增了多进程支持、源站集群、动态配置、可追溯日志等方面能力。源站集群子系统打通了跨网跨地区的源站分布式部署难题；动态配置子系统从业务系统读取配置，依据更新机制动态更新配置，保证直播业务配置变化时依然不中断；端到端的可追溯日志及监控排错子系统将直播故障定位时间缩短到了分钟级别。



3
核心功能对比

核心功能方面，BMS支持了当期互动直播、移动直播急需的大规模直播流实时转码、大规模录制、秒级低延迟、HLS+、并发回源等其它所有流媒体系统不具备的功能。HLS+基于每个播放请求实现了流媒体的“虚拟连接 ”（UUID标识），在减小回源量、排错、防盗链、移动Web端低延迟等方面具有诸多优势。并发回源能够解决回源网络状况差、跨国传输丢包严重等方面能够显著提升回源质量。



4
配置运维对比

以下仅是流媒体众多配置之中几个常用例子，运维日常工作中，需要操作的配置数量更多。

（1）vhost配置

FMS

拷贝默认vhost目录：sudo cp -r conf/_defaultRoot_/_defaultVHost_ conf/_defaultRoot_/bravo.sina.com



nginx-rtmp

不支持



SRS/BMS

动态获取配置文件：vhost bravo.sina.com { }

结论：BMS动态获取配置最简单

（2）app配置

 FMS

拷贝默认app目录：cp applications/live applications/mylive -r



nginx-rtmp

修改配置文件，增加如下内容：application live {  live on; }



SRS/BMS

无需配置

结论：BMS无需配置，最简单 

（3）http配置

在输出为hls、http-flv等基于http协议的直播流时，需要配置http服务

FMS

配置FMS内置的Apache服务器文件：Apache2.2/conf/httpd.conf

再修改如下字段：

<Location /hds-live>

    HttpStreamingEnabled true

    HttpStreamingLiveEventPath “../applications” 

    HttpStreamingContentPath “../applications” 

    HttpStreamingF4MMaxAge 2

    HttpStreamingBootstrapMaxAge 2

    HttpStreamingFragMaxAge -1

    Options -Indexes FollowSymLinks

</Location



nginx-rtmp

nginx本身就是一个http服务器，

修改其配置文件：

conf/nginx.conf

设置端口和根目录：

http {

    include       mime.types;

    default_type  application/octet-stream;

    sendfile        on;

    keepalive_timeout  65;

    server {

        listen       80;

        server_name  localhost;

        location /dash {

            root /tmp;

            add_header Cache-Control no-cache;

        }

    }

}



SRS/BMS

修改其配置文件：

conf/http.hls.conf

设置端口和根目录：

http_stream {

    enabled         on;

    listen          8080;

    dir             ./objs/nginx/html;

}

结论：nginx-rtmp需指定与app对应的ts文件存放目录，SRS/BMS会自动生成，更简单。

（4）推流、播放URL配置

RTMP直播时，各大服务器推流、播流URL均为：

rtmp://server_ip_or_dns/app/stream



用作HLS直播时，

FMS 

推流域名：

rtmp://fms-ip-or-dns/app/stream?adbe-live-event=liveevent

播流域名：

http://fms-ip-or-dns/hds-live/app/_definst_/liveevent/stream.f4m



nginx-rtmp

推流域名：

rtmp://server_ip_or_dns/app/stream

播流域名：

http://server_ip_or_dns/app/stream.m3u8



SRS/BMS

同nginx-rtmp

结论：nginx-rtmp、SRS/BMS均简单，FMS较复杂。



5
性能

先说结论：

SRS单进程能支持9000并发，nginx-rtmp单进程最多支持3000个，单进程的性能SRS是nginx-rtmp的三倍。单进程性能SRS > nginx-rtmp > crtmpd > wowza > fms > RED5

 

再例举SRS性能如此高的几个原因：

1. st-load，这个是SRS能做到高性能的最重要的原因，一个st-load可以模拟2000+的客户端，如果没有st-load，如何知道系统的性能瓶颈在哪里？总不能打开3000个flash页面播放rtmp流吧？开启3000个ffmpeg来抓流？高性能不是想象和猜测出来的，而是反复测试、调试和改进出来的。

2. gperf/gprof性能，编译SRS时，就可以打开gcp或者gprof的性能分析选项，非常方便的拿到数据。缩短了改进和优化开发周期。

3. 引用计数的msgs避免内存拷贝。

4. 使用writev发送chunked包，避免消息到chunked包的内存拷贝。

5. mw(merged-write)技术，即一次发送多个消息。

6. 减少timeout recv，每个连接都是一个st-thread在服务。

7. fast buffer和cache。

8. vector还是list？vector！vector比list高10%性能。



6
服务器日志

日志是定位故障的唯一途径，定位故障才能快速排错。可以这么说，对于直播，10分钟的排错，谁都会觉得长。然而，当前的视频云或CDN，谁又能做到10分钟呢？

来看看日志吧。

FMS的日志是这样的，恕我愚钝，你能看得出什么信息么？

2015-03-24 12:23:58 3409 (s)2641173 Accepted a connection from IP:192.168.1.141, referrer:http://www.ossrs.net/players/srs_player/release/srs_player.swf?_version=1.23,pageurl: http://www.ossrs.net/players/srs_player.html?vhost=dev&stream=livestream&server=dev&port=1935-

702111234525315439     3130         3448         normal      livestream         –        –         rtmp://192.168.1.185:1935/live/livestream     rtmp://192.168.1.185:1935/live/livestream        –        flv     –        –        0       –        0       0         –        –    http://www.ossrs.net/players/srs_player.html?vhost=dev&stream=livestream&server=dev&port=1935    -1      -1.000000         

crtmpd的日志详细，但我又愚钝，若是上千人在线，你又能看出什么有用的东西么？

/home/winlin/tools/crtmpserver.20130514.794/sources/thelib/src/netio/epoll/iohandlermanager.cpp:120Handlers count changed: 15->16 IOHT_TCP_CARRIER

/home/winlin/tools/crtmpserver.20130514.794/sources/thelib/src/netio/epoll/tcpacceptor.cpp:185Client connected: 192.168.1.141:54823 -> 192.168.1.173:1935

/home/winlin/tools/crtmpserver.20130514.794/sources/applications/appselector/src/rtmpappprotocolhandler.cpp:83Selected application: flvplayback (live)

/home/winlin/tools/crtmpserver.20130514.794/sources/thelib/src/application/baseclientapplication.cpp:246Protocol CTCP(17) <-> TCP(18) <-> [IR(19)] unregistered fromapplication: appselector

/home/winlin/tools/crtmpserver.20130514.794/sources/thelib/src/application/baseclientapplication.cpp:257Stream NR(5) with name “ registered to application `flvplayback` from protocolIR(19)

/home/winlin/tools/crtmpserver.20130514.794/sources/thelib/src/application/baseclientapplication.cpp:268Stream NR(5) with name “ unregistered from application `flvplayback` fromprotocol IR(19)

/home/winlin/tools/crtmpserver.20130514.794/sources/thelib/src/application/baseclientapplication.cpp:257Stream NR(6) with name “ registered to application `flvplayback` from protocolIR(19)

/home/winlin/tools/crtmpserver.20130514.794/sources/thelib/src/protocols/rtmp/basertmpappprotocolhandler.cpp:1043Play request for stream name `livestream`. Start: -2000; length: -1000

/home/winlin/tools/crtmpserver.20130514.794/sources/thelib/src/application/baseclientapplication.cpp:268Stream NR(6) with name “ unregistered from application `flvplayback` fromprotocol IR(19)   

到了nginx-rtmp，日志总算有进步了，能按照连接区分了。只是可惜，nginx日志也就只能知道这个连接而已，这个连接在CDN多层网络中的路径，这个连接本身的网络状况等依然不知。

2015/03/2411:42:01 [info] 7992#0: *3 client connected ‘192.168.1.141’

2015/03/2411:42:01 [info] 7992#0: *3 connect: app=’live’ args=” flashver=’MAC17,0,0,134’swf_url=’http://www.ossrs.net/players/srs_player/release/srs_player.swf?_version=1.23’tc_url=’rtmp://192.168.1.173:1935/live’page_url=’http://www.ossrs.net/players/srs_player.html?vhost=dev&stream=livestream&server=dev&port=1935’acodecs=3575 vcodecs=252 object_encoding=3, client: 192.168.1.141, server:0.0.0.0:1935

2015/03/2411:42:01 [info] 7992#0: *3 createStream, client: 192.168.1.141, server:0.0.0.0:1935

2015/03/2411:42:01 [info] 7992#0: *3 play: name=’livestream’ args=” start=0 duration=0reset=0 silent=0, client: 192.168.1.141, server: 0.0.0.0:1935



在SRS，尤其是BMS身上，终于有了流媒体可追溯日志，能从播放连接追到对应的推流连接，打印出连并接的摘要信息，这也是观止云能将故障定位时间控制到分钟级别的原因。之前小编专门介绍过观止云可追溯日志，有兴趣可参考《可追溯日志：视频云时代的新运维大胸器》，此处简单看看可追溯日志运行方式：

播放流：rtmp://dev:1935/live/livestream 客户端显示ID能看到SrsIp，即服务器IP为192.168.1.107，由此知道是哪个边缘节点在提供该流的服务。SrsPid为12665，SrsId为114，所以去这个服务器上grep关键字“[12665] [114]”。







连续grep追踪，最终发现这是source_id=149 的编码器推上来的流ID。再去查149的日志，整个流的日志将快速呈现在眼前。Encoder => Origin => Edge => Player，流在观止云整体分发过程中的日志能够几分钟内找到。



7
数据

小编尚且不完全知晓，数据对于一个视频运营平台来说价值到底有多大。小编知道的，至少对于视频直播，依托于越实时的数据，越能够快速定位、解决部分用户故障问题；保障不同付费等级、不同终端、不同区域、不同内容等的观看体验；进行CDN计费数据对账；精准广告等等。

所以观止云BMS还是尽能力的提供了一些数据，而且是几乎实时的数据，上几张图：



可以看到实时在线观看人数，以及区域、运营商分布，观看流畅度，实时带宽负载等

 



可定位到某个具体用户，监控用户的终端环境（操作系统、浏览器、播放器版本），观看体验。

 

其它系统呢，对不起，小编没有见到过。

CDN已成云商必争之地 看CDN年整体收入增速800%的阿里云如何放大招？

近日，阿里云PR一改往日规模会议的模式，落脚创业大街，在3W咖啡办起了CDN专项技术媒体分享会。据笔者观察，这是阿里云2016年PR思路的一大改观，与同为BAT级的腾讯云一同走起了小清新路线。从邀请函中明显看出，本场媒体沙龙的主题剑指传统CDN，“传统CDN会更好?”的疑问在本次技术分享中被揭晓。

传统CDN闷声挣大钱的时代已去

随着用户应用需求类型的改变，CDN作为网络的一部分，已经成为企业级市场追捧的焦点之一。因为通过CDN可以更多的把计算和存储推向边缘，实实在在的让用户感受到最真实的体验。所以，当云计算大规模落地，云化CDN越来越受到用户的青睐。

我们知道，传统CDN一直以来，盘踞在产业链条的一端，悄默声的挣去高额利润。但在阿里云首席科学家章文嵩的眼里，这种传统CDN闷声发大财的局面，很快或者已经被打破。“云化CDN会完全重新将CDN定义。”因为随着创新技术的发展，用户应用习惯的更改。更多的应用场景会更多的被推到边缘节点上，不光是云上的计算，也可能变成边缘计算。“CDN可以说是云的入口，对于任何的云厂商来说CDN都很重要，而且CDN一定是云计算厂商的必争之地。” 章文嵩表示。

为什么肯定?原因很简单，可以被主要归纳为两点。第一，云时代里，企业级需求在改变。用户不在单一将CDN当做一个固定资源来所取，而是在其中加入更多计算、存储、网络、安全等多方面需求，而传统CDN厂商并不具备这样的综合技术实力，所以云服务商就有了更大的机会;第二，池化资源是云计算的本质属性，CDN一旦池化，将会带来更多的规模与价格优势，而这也是传统CDN能力达不到的。据介绍，像云厂商或者国内的BAT级别的互联网公司，他们在基础设施规模的建设上都比传统的CDN厂商大得多。整体的规模效应会带来成本下降，从而会带来更低的价格。

CDN的C从内容(Content)到云(Cloud)的改变

“未来三五年，随着云厂商的进入，整个CDN产业的格局将会发生翻天覆地的变化。” 章文嵩预测。

CDN原来的单词是Content Delivery Network，侧重整体应用的内容分发。而随着云厂商在产业内的介入，大部分企业用户的应用构建、传输都将在云上进行，所以CDN的内涵也将逐步转变为Cloud Delivery Network，云上网络分发的印记将更加深入。

“随着用户需求的适时而变，CDN技术的发展将会融合更多的创新思维和前瞻性的理念进去，云厂商凭借自身的综合实力优势，发展会越来越快。未来两到三年，传统CDN服务商光环不在，有可能整个CDN的行业江湖就会易主。” 章文嵩表示。

对此，阿里云CDN事业部总监朱照远用实际案例带来例证。分享当天，他举了阿里云与芒果TV合作打造风靡全球“超级女声”APP的例子。芒果TV对阿里云提出了苛刻的CDN需求：两周打造一个原型出来!其中APP要实现包括视频的海选、直播与终极PK的功能，其中技术实现要能提供视频的转码、网络专用通道、数据库、消息中间件等等十几种的能力。“这对传统CDN是不可能做到的，因为他们解决不了用户的所有痛点，或需求的功能点。传统的CDN只能提供单一的CDN组件，但是客户需要的却是计算、存储、分发、大数据、安全等等系列解决方案。”

所以，传统CDN在面临复杂的业务场景以及复杂的客户需求时，会表现出能力不足，束手无策。在云时代里，单一的内容分发，已经不能满足用户的多样化需求，云化CDN将给用户带来全新选择。

CDN6.0版本有哪些绝杀技?

阿里云CDN发源于淘宝自有CDN，并于2014年3月开始正式对外为提供服务。在商业化服务2周年之际，阿里云发布了经过10年淘宝历练，5次更新迭代的CDN6.0版本。

据介绍，此次发布的极速CDN 6.0版本，除了首次在业界提出Cloud Delivery Network(云分发网络)理念外。还融合了云计算、大数据技术，涵盖视频和移动两个解决方案以及大数据分析、HTTPS加速等新功能，可以为客户提供一站式的云CDN解决方案。

具体说来，6.0版本针对视频类应用推出视频云解决方案，提供一站式视频点播、直播服务，集内容采集、上传加速、存储、码转/截图、鉴黄服务、CDN分发及播放器等功能于一体，极大地优化了客户体验。据测算，视频云端到端时延仅2秒，流畅度95%，在同等清晰度下，码率低30%，这意味着客户可以节省30%的成本。

另外，新版CDN还提供了HTTPS加密功能，可以让客户内容防劫持、防篡改、防窃密，保证通信的安全。

大数据工具也是6.0版本的重要特色。阿里云将打通CDN和“数加”平台的大数据计算产品MaxCompute，客户如果需要，可以一键上传自己的日志数据，使用强大的MaxCompute进行精细化分析数据，让数据产生商业价值。



▲阿里云CDN用户展示

据透漏，移动端的CDN整体解决方案也即将上线，移动加速可提升40%性能，并具备HTTPDNS功能，具有防域名劫持、调度精确、稳定可靠等特点。

2015年阿里云CDN客户数已突破10万，客户规模是传统CDN厂商客户之和的20倍，在整个CDN市场稳居行业第一。业务营收同比增长800%，增长率也比传统CDN厂商的增速快了约20倍。“这一年越来越多的大中型企业级CDN客户采用CDN和云计算证明了我们对于行业前景的判断。企业在使用公共云架构的同时选择了云CDN，其综合竞争优势显著，这与传统IT架构向云计算转变的历史趋势一致。” 朱照远表示。

▲国内500+节点，超过10T带宽，单节点40-300G，海外覆盖6大洲（图示是阿里云CDN有部署节点的国家或地区）

去掉http响应头Cache-Control及Pragma造成的缓存问题

最近在折腾CDN缓存配置，就发现在伪静态环境下，缓存命中率还是非常低，一番折腾后发现如果源站的http头部包含一些不缓存的信息，那么CDN”也许“会相应的继承源站发出的HTTP状态。
通常喜欢用LNMP安装包的朋友会发现，在动态及伪静态的环境中，HTTP头部信息会包含Cache-Control: no-store,no-cache,must-revalidate,post-check=0,pre-check=0 和 Pragma: no-cache，就是这种状态影响了CDN对源站缓存的判断，proxy。

如何去掉Cache-Control及Pragma在http头部中的状态呢？
如果没有看到此文的话，你会非常痛苦的认为是网站程序本身所发出的状态，然后一番查找修改后发现依然无解，我理解这个过程，因为我就是这么干的。非常之痛苦。。。。

其实解决Cache-Control: no-store,no-cache.....和Pragma: no-cache很简单，只需修改php.ini中的session.cache_limiter参数，军哥lnmp默认值是nocache，只要修改为none即可解决这个HTTP状态中的缓存问题。耶！耶！耶！耶！耶~~~~~~~~~ 

老外vps无特别说明(即使用优惠码)都按优惠后的价格续费。此vps无爱可看之前其它文章
发现Out of Stock说明缺货中，可考虑购买其它VPS。自备谷歌浏览器有简单的翻译功能。