月度归档:2015年06月

怎么能够像爱奇艺、腾讯那样玩实时直播

大家都知道爱奇艺、腾讯在直播版权上烧钱最凶,而且直播体验也不错。实时直播做的好需要神秘配方,其中有一味重要调料:他们都用HTTP FLV!

那么我们这一节详细解释HTTP
FLV的背景。

Whatis HTTP
FLV

所有的HTTPFLV流都是一个HTTP FLV地址,譬如:http://ossrs.net:8081/live/livestream.flv,但是,流的形式却至少有三种:

1. FLV文件,渐进式HTTP流。放一个文件到nginx目录,可以访问下载在播放器播放,这是HTTP FLV文件,也就是渐进式下载流。所谓渐进式下载,也就是用户观看时无法从未下载的地方开始看。

2. FLV伪流。一般说的HTTP FLV,比上面的渐进式流高级一点,譬如,一个120分钟的电影,作为渐进式流播放时,用户需要从60分钟开始看,如何支持呢?因为nginx是当做文件下载的,无法直接跳转到第60分钟(nginx也不知道60分钟对应的字节偏移是多少呀)。后来有人就支持这种跳着播放,通过指定时间服务器从指定的位置开始给流,这种支持flv?start=,就是httpflv的伪流,本质上还是点播流。

3. FLV直播流。SRS所指的HTTPFLV流,是严格意义上的直播流,有RTMP的所有特征,譬如集群、低延迟、热备、GOPcache,而且有HTTP的优势,譬如302、穿墙、通用。由于SRS内部实现了HTTP服务器,所以SRS是在边缘将RTMP流转换成HTTP流,SRS集群内部还是使用RTMP分发。当前唯一将RTMP和HTTP协议都解析的服务器,目前只有SRS和nginx-rtmp,可惜nginx-rtmp没有实现这个流。

用一句话概括,SRS的HTTP FLV就是增强的RTMP,真正的实时流媒体分发。

ConfuseHTTP
FLV

SRS的HTTP FLV容易和下面的几种分发方式混淆:

1. RTMPT:这个实际上是最接近SRS的HTTP FLV的概念的。但是从本质上来讲,rtmpt是基于HTTP的RTMP,所以还是RTMP而不是FLV。

2. HDL/HFL:国内一些厂家的HXX流,就是FLV流,主要和SRS的区别在于服务器集群内部SRS还是走RTMP,所以延迟可能会有很大差异。SRS的HTTP FLV和RTMP延迟一样,0.8-3秒。

3. HDS:这个差的太远了,不是一个东西。HDS和HLS像,但是HTTP FLV和他们两个都完全不像。

WhyHTTP
FLV

为何要整个HTTPFLV出来呢?当下HTTP FLV流正大行其道。主要的优势在于:

1. 互联网流媒体实时领域,还是RTMP。HTTP-FLV和RTMP的延迟一样,因此可以满足延迟的要求。

2. 穿墙:很多防火墙会墙掉RTMP,但是不会墙HTTP,因此HTTPFLV出现奇怪问题的概率很小。

3. 调度:RTMP也有个302,可惜是播放器as中支持的,HTTP FLV流就支持302方便CDN纠正DNS的错误。

4. 容错:SRS的HTTP FLV回源时可以回多个,和RTMP一样,可以支持多级热备。

5. 通用:Flash可以播RTMP,也可以播HTTPFLV。自己做的APP,也都能支持。主流播放器也都支持httpflv的播放。

6. 简单:FLV是最简单的流媒体封装,HTTP是最广泛的协议,这两个到一起维护性很高,比RTMP简单多了。

互联网视频的实际工业标准RTMP: 有多少个坑?

最简单的PC流媒体应用,可以使用Flash采集摄像头和麦克风后,以RTMP协议推送给流媒体服务器,然后在浏览器中用Flash播放器播放这个RTMP流。总共需要多少行代码?可以100行as代码就可以实现,脏累烦的事情都是flash搞定了。

视频点播,从来就不是RTMP的事情,那是HTTP文件的世界,一个HTTP-MP4文件,可以在所有平台观看。直播呢也不仅仅是PC了,移动互联网、h.265和mpeg-dash,这些视频的新技术,发展的速度非常快。而HLS这个和RTMP一样古老的Apple的流媒体技术,在Android3支持了HLS后,HLS成了移动互联网应用最广泛的技术。

RTMP还是那个RTMP,从视频的编码采集到服务器,还是RTMP;分发到PC,可以RTMP,也可以HLS了;分发到移动互联网,自己的app可以RTMP,浏览器只能HLS了。

而流媒体服务器的角色,也从分发RTMP直播流,变成了分发RTMP和HLS流。RTMP对于直播流媒体服务器,还是扰不过去的大坑。让我们一起数一数RTMP这个坑里有多少个球吧。

第一个球,变更过的加密握手协议。RTMP协议Adobe公开了吗?是的,可以在Adobe官网上下载。按照协议实现一个RTMP服务器时,发现里面的握手是变更过了的;这就是为何SRS需要编译openssl库,需要从客户端的握手信息中获取客户端的公钥,然后按照指定算法交换密钥。如果按照RTMP标准文档握手会怎样?Flash播放器只能播放vp6编码的流,无法播放h.264的流,呵呵。

第二个球,变更过的扩展时间戳传输方法。RTMP的时间戳是24位的,如果超过这个4.5小时连续推流,就需要用到高8位的扩展时间戳。标准中说,chunked的X3包,是不能包含扩展时间戳的;可惜Adobe的所有产品都用了,从flash到FMLE到FMS。而ffmpeg中也有注释抱怨说Adobe太坑爹了,没事改它干啥。而SRS中对于这种处理,是采用猜测,即X3的chunked包先读4字节出来,如果和消息的时间戳吻合那么就是Adobe系统,也有些开源的产品遵守规范的,SRS会自动适配。

第三个球,RTMP的时间戳是32位还是31位?在flv标准中,明确讲了是31位(SI32)即24.8天左,而按照RTMP的49.7天回绕的说法应该是32位。一般没有问题,谁会看一个直播24.8天呢?额,这个不是很严谨的做法,对于服务器来讲。SRS使用31位。

第四个球,不能变更ChunkSize。有些服务器不能变更ChunkSize,所以SRS在Edge模式时,回源某些服务器会有问题。这个球只能配置SRS的默认ChunkSize,配置为128即原始值。

第五个球,溢出的ChunkSize。RTMP标准说ChunkSize最大不超过65535,有个什么球服务器,就喜欢设置一个比这个大得多的ChunkSize,泥马!这个该怎么处理?忽略标准就好,实际上没有这个上限。

RTMP的扩展时间戳传输,请参考:http://blog.csdn.net/win_lin/article/details/13363699

RTMP的复杂握手协议,请参考:https://github.com/winlinvip/simple-rtmp-server/wiki/v1_CN_RTMPHandshake

RTMP的更多信息,请参考:https://github.com/winlinvip/simple-rtmp-server/wiki/v1_CN_DeliveryRTMP

用nginx-rtmp的63%代码,增加80%的功能,SRS用到的ST是个什么球?

这次我要讲的是:ST(state-threads)是个什么球?

趁着吃完饭休息会儿,给大家讲讲ST(state-threads),一个四两拨千斤的想法。基于ST的SRS1只用了4.3万行(63%)代码,比nginx-rtmp多了83%的功能,周期缩短100%;而SRS2只用了6.5万行(95%)代码,比nginx-rtmp多了230%功能。开发周期SRS1用了1年,SRS2用了1年;nginx-rtmp发布1.0用了2年。啥都不说了,SRS3就不再和nginx-rtmp比了,SRS3和SRS2比吧~

如果说代码行数不能说明问题,那再爆料一组数据,SRS1的注释率是22.1%,而SRS2的注释率是23.7,nginx-rtmp注释率是3%。可见SRS用ST简化了多少逻辑。nginx-rtmp的6.8万行代码,是去掉了其他模块,只有core和rtmp等必要模块,总共nginx-rtmp有16万行代码。

ST解决的是服务器的最根本问题:如何以最高效率服务多个客户端连接?答案就是nginx的架构,即单线程异步非阻塞socket(没错还有多进程,我们先只考虑如何一个进程最高效);在linux中,就是epoll+send(MSG_DONTWAIT),具体的可以翻翻书柜,epoll早就不是什么新鲜事了。

这个架构可以打个比方,一个快递员在送快递时,假设有4个客户分别在四个完全不同的方向,东家西家南家北家,快递员每家都要送1000个包裹,快递员的货车有限先送东家1000个包裹,东家收了100个候发现家里没有空间了得腾缓冲区出来,快递员只好暂时不管东家了(非阻塞啦),去给西家送了200个还有800个,南家300个还有700个,北家1个还有999个。

接下来肿么办?最快的方式当然是各家的空间腾出来后,快递员用epoll_wait就知道哪些可以继续了,这就是异步啦。这个异步非阻塞是相当高的效率,但是麻烦的地方在于,快递员每次都要登记各家的状态,然后跑到各家去继续送(调用不同的处理函数),路上不仅浪费很多时间,而且维护这些信息非常之麻烦啊!每次都得把路重新计算规划,再跑一边非常需要费脑筋啦。

最简单的方式是不要登记各家状态,每家都派一个快递员啦(创建线程),各家有空间这个快递员马上就继续发,这样是最简单的逻辑;缺点是要做线程同步咯,而且很昂贵啦,没法一下子服务几万个用户。

孙悟空的毫毛可以用在这里,分身术,实际上还是一个快递员,但是在各家那里分个身。好处是不用登记那些信息,各家有空间了立马就开始写;比线程的优势是不用锁,开销小。ST就是分身术,虚拟线程,即用户空间线程协程,类似goroutine,或者C#的纤程。

协程完全是不同于进程和线程的一套写代码思路,解决问题的思路不一样,当然结果是不一样的啦。在处理rtmp的edge,以及http-flv的hstrs(http stream trigger rtmp source)时,涉及到多个线程交互,这种就相当于两个异步状态空间相乘,那个是相当之复杂的。这是为何nginx-rtmp实现RTMP比较费劲,要实现RTMP-EDGE,以及HTTP-FLV、HSTRS是非常难的事情。

关于ST更多信息,请参考:http://blog.csdn.net/win_lin/article/details/8242653

比nginx-rtmp高三倍性能的SRS的高性能是个什么球?

SRS单进程能支持9000并发,nginx-rtmp单进程最多支持3000个,单进程的性能SRS是nginx-rtmp的三倍。SRS单进程性能如何做到nginx-rtmp的三倍的?SRS哪几个结构极大提升了性能?

先来看看我们遇到的问题,RTMP协议和HTTP协议是又很大不同的。nginx在分发HLS,即m3u8文本文件和ts视频文件时,对所有连接发送的都是同一个内容,甚至可以调用sendfile让内核自己发fd去,nginx服务器自己要干的事情很少了;如果nginx必须把每个ts的内容读出来,修改里面某些字节,然后每个客户端一次发送的数据前还得加点什么,nginx就会很忙了。

这就是RTMP,每个video或audio包,在发送给某个连接之前,都得修改下时间戳(至少FMS是每个连接收到的媒体数据都是从0开始的时间戳),然后把包再拆分成一些小片段(chunked),每个chunk包前面加几个字节的头信息,然后发送。我勒个去~

举个例子,假设有个视频的I帧有200000bytes,默认的chunk包最大是128字节,所以得拆分成200000/128=1562个chunk包来发送,每个chunk包前面都要加chunk头。没有办法sendfile了吧?可以想象得到内存要被蹂躏成什么样子吧?这就是RTMP流媒体服务器麻烦的地方了,客官可以自己想下搞个什么样子的算法能最高效发送粗去~

nginx-rtmp是性能最高的服务器,比crtmpd都要高,red5根本就低两个级别,wowza也没有它高。SRS做了什么能够比nginx-rtmp单进程还要高三倍?

第一点,st-load,这个是SRS能做到高性能的最重要的原因,一个st-load可以模拟2000+的客户端。一个牛逼的benchmark的工具;如果没有st-load,如何知道系统的性能瓶颈在哪里?总不能打开3000个flash页面播放rtmp流吧?开启3000个ffmpeg来抓流?不靠谱。这就是高性能第一定律:高性能不是想象和猜测粗来的,而是测试、调试和改进粗来的。

第二点,gperf/gprof性能benchmark功能。在编译SRS时,就可以打开gcp或者gprof的性能分析选项,灰常方便就可以拿到数据。缩短了改进和优化的开发周期。

第三点,引用计数的msgs避免内存拷贝。从编码器收到的video/audio数据,转换成SrsSharedPtrMessage放到每个连接的发送队列,避免每个都拷贝一次;因为发送给每个客户端的消息(不是chunked包)头可能不一样,譬如时间戳不一样,但是消息的payload是一样的。

第四点,使用writev发送chunked包,避免消息到chunked包的内存拷贝。可以开辟一个header的缓冲区,专门放每个chunked包的header,然后用iovc保存头的指针和大小,payload的指针和大小,用writev就可以一次发送。

第五点,mw(merged-write)技术,即一次发送多个消息。虽然每个消息使用writev可以避免拷贝,还有更高效的是一次发送多个消息,即把多个消息的chunked头写在header的缓冲区,iovc保存多个消息的chunked头和payload指针,一次writev发送多个消息。这个是最关键所在。

第六点,减少timeout recv,每个连接都是一个st-thread在服务。在发送之前,线程得尝试从连接收取消息,譬如客户端的stop之类的;所以只能recv时指定timeout,譬如300毫秒如果还没有收到消息,就发送连接队列中的消息。这个会导致st的timeout红黑树操作频繁。实际上,可以直接开启一个recv线程,因为客户端的消息非常少,避免timeout接收。

第七点,fast buffer和cache。譬如每次取消息的数组,使用cache;使用fast buffer避免频繁删除;使用header的cache。

第八点,vector还是list?有的地方看起来list更高效,譬如simple buffer这种频繁删除头,以及在结尾加入数据,看起来是list应该做的事情。但是实际上测试发现,vector比list高10%性能。所以,回到第一点,高性能不是猜测和想象粗来的;有的时候有些代码写得很慢,但是这个频率非常低,那么就不要考虑性能,而要考虑可读性。我觉得可以算是高性能第二定律:不要总是考虑高性能,可读性更重要。

另外,nginx-rtmp有多进程啦。没错,可惜SRS也可以有多进程啦;可以有为何没有做呢?首先,9000个连接还不够么?1Mbps的码率可以到9Gbps了哦,伦家的机房交换机有那么牛逼么?敢一个服务器服务那么多用户么?其次,多进程不是万金油的,不过是一种技术,不是没有多进程就低人一等,有了多进程就高人一等,别那么技术控,关键在于对于客户有啥价值。再次,可以用RTMP302支持多进程,这个是最稳定的多进程技术。最后,杰哥的BLS已经实现了多进程,他设计的多进程架构,即一个源站fork多个边缘的进程的结构,是最简单的多进程通信模型。这可以引申出高性能第三定律:表当真呢,高性能不是万金油。

SRS的性能测试,请参考:https://github.com/winlinvip/simple-rtmp-server/wiki/v1_CN_Performance

SRS的性能优化commit,请参考:https://github.com/winlinvip/simple-rtmp-server/tree/2.0release#performance

宝德CDN行业再传捷报,为客户发展注入动力

近日,宝德又一次在CDN领域收获新成果,成功中标某新兴CDN公司服务器采购项目,高性能、高扩展和超高性价比的宝德存储服务器极大满足客户全国IDC节点计算资源的扩展需求,为客户扩大业务规模提供坚实的保障。

该公司是一家专业提供网络带宽接入、电信增值业务、并从事服务器托管、租用、数据中心维护、专线接入、网络加速平台研发与维护等服务的互联网技术服务公司,公司拥有雄厚的网络技术力量,在网络接入、网络保障、信息安全等领域有巨大的技术保障。为扩展公司CDN业务规模,该公司正加速在全国部署CDN计算节点,面对业务数据的急剧增长,原有系统的存储能力以及处理能力捉襟见肘,为此,该客户启动了服务器采购项目。

针对客户对于服务器存储能力以及计算能力的迫切需求,宝德向客户提供了存储服务器PR2012GS,其凭借高性能与高性价比赢得了客户的青睐,在激烈的竞争中一举胜出。

宝德大容量存储服务器PR2012GS

宝德PR2012GS集计算、存储、可扩展性及能效特性于一身,适用于网络服务供应商、成长性数据中心、云计算解决方案等应用环境。它最大支持2 颗八核英特尔® 至强® E5-2600V3系列处理器,可提供强大的计算能力,帮助用户应对较重的计算压力,帮助用户解决当前日益动态化的计算环境中的存储、网络和安全性挑战;内部存储高达 40TB,能够充分满足用户的存储需求;具备5个PCI-E扩展槽,可以为用户提供灵活的连接选配件;板载四口千兆数据网卡,1个1000M远程管理专用网口,具有负载均衡、故障恢复和边带支持特性,可有效减少网络延迟;支持降频功能,可根据热关键器件温度综合调节风扇转速,具备出色的能源效率。

同时,PR2012GS服务器还具备以下特性:集成远程KVM, 可以为服务器系统的大规模部署和远程分布式应用提供便捷的管理能力;允许从任何地点通过网络访问、安装、配置和控制远端服务器;低网络带宽需求,可以消除服务器系统管理和使用地域的限制,可以加快反应速度方面的挑战;硬件级别的访问及控制,与操作系统无关,提供完全的兼容性;高安全性,所有传输的数据均经过数据加密。

此次中标,延续了宝德在CDN行业连连中标的势头,巩固了宝德在该细分市场的领先优势。今后,宝德将继续立足客户在计算、存储等方面的更多需求,为客户提供高性价比的产品与服务,为客户发展注入更加强劲的动力,进而促进自身业务的持续稳健增长。

CDN唯快不破

360网站卫士”是奇虎360旗下为中小网站量身打造的加速及安全防护平台,主要为中小网站提供高防DNS解析服务、网站加速服务以及防黑客、防CC、防DDOS等安全防护服务。目前已有超过40万家网站使用了网站卫士的相关服务。近日,网站卫士为向用户提供更优质的服务,选择AppEx Networks北京华夏创新科技(以下简称AppEx)来优化其CDN服务。

1

CDN为何备受青睐

CDN的全称是Content Delivery Network,即内容分发网络。其实现方式是在现有的Internet中增加一层新的网络架构,将网站的内容发布到最接近终端用户的网络节点,使终端用户可以就近取得所需的内容。

传统的内容分发模式是所有用户都访问源服务器,容易造成源服务器网络拥堵或者负载过高,这种模式很难扩展。而CDN架构将可分发的内容推送到大量的边缘节点服务器上,由距离用户最近的边缘节点服务器为用户提供直接内容访问服务,两者的架构对比如图1所示。

QQ截图20150618115745.jpg

1:传统分发模式与CDN分发模式对比图

CDN节点服务器会缓存来自源站的大量静态内容信息,就像一个靠近用户的网站服务器一样响应本地用户的访问请求。对于普通的Internet用户来讲,每个CDN节点就相当于一个放置在它周围的WEB。通过全局负载均衡的控制,终端用户的请求被透明地指向离他最近的节点,节点中CDN服务器会像源服务器一样响应终端用户的访问请求。由于它离用户更近,因而响应时间更快。

CDN虽好,但由于其建设费用十分高昂,一般的中小型内容提供商很难自建。而“360网站卫士”精准分析市场需求,在CDN市场竞争激烈的大环境下,向中小企业提供免费及低收费的CDN服务,并为中小网站提供优质低价的CDN提速服务。

2

即便是“360网站卫士”也不可避免地为CDN固有的问题所困扰。

首先,为了控制成本,节点建设通常优先保证对热点区域的覆盖;而对于非热点区域的用户,因为其距离CDN边缘节点较远,广域网链路的网络质量无法保证,因此其访问效果往往欠佳。

其次,对于移动互联网络来说,CDN架构几乎无用武之地。

再次,CDN的全局负载均衡技术尚有不足,未能做到完全的最合理分配,导致一些用户的请求未被调度到距离最近的节点,以致访问效果不佳。

最后,为了进一步缓解源服务器的压力,CDN节点在做缓存内容更新时并非所有节点都从源站获取内容,而是由一部分节点先从源站获取内容,之后再做节点间内容的同步操作。在某些情况下会出现两个内容同步节点间的网络质量差、内容同步效率低的情况,从而导致内容无法及时更新。

虽然以上问题并不能否定CDN架构的价值,但是如果能结合一些技术方案将这些问题加以解决,则必然能使 CDN 架构如虎添翼,从而在更大需求范围内提供更好的方案解决能力。

3

AppEx网络优化专家针对以上问题,提供了有效解决方案。

AppEx通过在“360网站卫士”CDN架构的各个节点服务器上部署LotServer服务器加速软件,显著提高了在网络质量较差情况下的网络数据传输效率,从而提升了上层应用的响应速度,加强了CDN 节点服务器的网络访问性能,最终显著改善了CDN的一系列固有问题。

AppEx CDN优化方案示意图如下所示:

QQ截图20150618115829.jpg

第三方测试结果显示AppEx CDN优化方案效果显著

Alibench(阿里测)显示,360网站卫士CDN线上服务器部署LotServer后,对100KB文件进行多次下载,下载时间明显缩短,由加速前平均976ms(取5次测试数据平均值)下降到加速后平均467ms(取5次测试数据平均值),下降比率为52.7%。测试数据如下图所示:

QQ截图20150618115909.jpg

目前,AppExLotServer服务器加速软件已经广泛部署在国内知名CDN服务提供商(如蓝汛、网宿、帝联科技等)的节点服务器上,为其优化各项应用访问效率,并提升整体CDN架构服务能力。

【CDN大家谈之一】蓝汛:美国是赢家通吃,中国不是

“中国做CDN难在带宽成本太高,BAT有可能在这方面颠覆;阿里提供的是标准化服务,但CDN服务需要全球化、分时段、个性化”

5月27日,蓝汛科技(ChinaCache )首席执行官、董事长及联合创始人,国内最早的CDN玩家王松接受了财新记者专访。作为中国CDN市场两大垄断寡头之一,王松解读了中国CDN市场发展,并对比中美CDN市场发展,分析了BAT等玩家进场的逻辑。

“在美国,CDN已经被证明是一个百分百赢家通吃的市场。”王松指出,但中国市场由于底层宽带网络被运营商垄断,CDN服务公司的受限于宽带成本,并非高毛利的行业。王松告诉财新记者,和互联网行业已经追平甚至赶超美国同行不同,中国的CDN行业落后于美国同行七八年时间。

这次互联网公司高调进入市场,王松态度乐观:“阿里云的高调进入对于整合行业的认知度和市场培育有积极作用。”但在他看来,阿里云等提供的服务多为标准化服务,而CDN网络只有实现全球跨区域、分时段、个性化的服务才能让资源最有效配置。

在这样的背景下,王松称看不到中国的CDN市场会形成“赢家通吃”的趋势。

1

中国CDN市场核心问题是带宽太高

财新记者:我们要怎么理解CDN(内容分发服务)?作为基础服务,CDN服务有什么特点或者说有什么门槛?

王松:CDN我们可以理解为云分发服务,目前的云服务分为云计算、云存储、和云分发。互联网要提供商业服务,这三者缺一不可。云计算是生产,云存储像仓库,云分发是物流,这就是互联网产业的形态。

对于CDN,云分发平台而言,门槛一个是平台能不能支持,二是在平台上面能否快速开发出应用。平台打好之后,你要在上面快速地建出房子。

其实在美国市场,已经证明了CDN是一个百分百赢者通吃的领域。而且,CDN绝对应该是全球性的业务,不是区域性的业务。当然中国经常会颠覆这一结论,可能中国的市场的确比美国大。在美国除了Akamai一家CDN公司其余都赔钱。对于CDN企业来说,它的网络规模越大,企业优势就更加明显。因为CDN会有时间复用、客户量复用,还有更重要的是区域复用。

比如北京现在是白天,而美国是晚上,通过全球调度就可以降低使用成本。某巨型国际客户就和我们合作,利用北京的夜间流量支持美国西海岸的日常服务,这样资源可以24小时地利用起来。当然不同的业务需求也不同。有的业务可能非常敏感,跨境服务可能就有问题,比如网购、游戏。有的业务不那么敏感,就可以选择跨境来支持。

财新记者:您刚才提到美国的CDN市场,能否跟我们分享一下CDN业务在美国是如何发展的?

王松:中国的CDN产业发展比美国晚7到8年,美国CDN领域已经经历了至少三轮的发展。从表面上看中国各个种类的公司发展都很快,但是做底层业务的公司并不多。比如美国第一轮互联网泡沫的时候,Akamai的泡沫是最大的,短短两年就经历了过山车式的增长和下跌。

但与此同时,第一轮互联网泡沫也带动了后端企业的发展,比如做CDN的Akamai,做存储的NetApp,还有一大批类似的公司。所以美国第一轮互联网发展出现许多做底层业务的公司,包括数据中心。第二轮是做视频的内容分发,YouTube等企业就此发展起来了;所以美国在每一轮互联网高峰的时候都有很多基础的公司起来。而在中国,我们是第一个CDN行业在美国上市的公司,但比美国整整晚了十年。中国整个CDN产业跟美国有很大的差距。比如我们得到的一个数据,2013年美国骨干网中一半的流量是CDN的流量。现在美国做CDN的公司很多,各种各样的模式都在出现,CDN领域的垂直和细分越来越明显。

财新记者:中国的产业发展情况呢?中国的CDN市场最终怎么就只剩下蓝汛和网宿两家巨头?我们和美国差七八年的原因是什么?

王松:在中国CDN企业生存非常难,最核心的问题是带宽成本高。CDN服务中50-60%的成本是带宽成本,而对于Akamai来说这个比例是15%。为什么美国视频领域能够发展出YouTube?当然有谷歌支持的因素,但是它的带宽成本远远低于我们的成本。

财新记者:中国市场上现在有一种声音,认为商用CDN市场发展前景有限,你怎么看商用CDN和自建CDN在中国的趋势?

王松:自建和商用永远不是非此即彼的关系,选择自建还是商用主要根据公司自身业务的发展,考虑哪种方式更有效率。比如对于物流领域,足够大的公司可能会考虑自建物流体系,认为这种方式更具效率。也有些产业随着发展越来越成熟,专业化分工也更加明显。比如汽车行业发展前期,汽车制造公司从头到尾都自己制造。而发展到现在,轮胎、发动机、玻璃等等都委托给别人做。除非他认为这个是非常核心的业务,否则都会交给第三方来做。

2

BAT做新兴企业和小企业,我们主做大客户

财新记者:你怎么看待阿里加速布局CDN领域这件事情?阿里云高调宣布下调CDN价格,你最开始知道这件事时是什么感受?

王松:其实阿里云布局CDN市场,我觉得是在模仿亚马逊的做法。亚马逊最早提供CDN服务的时候,它的主要业务就是云计算(EC2)、云存储(S3)、云分发(CloudFront)这三块业务。亚马逊发展早期有四分之一到三分之一的收入来自这一部门。大型的云服务商都会把CDN当作一个服务去提供,微软的Windows Azure在美国也跟第三方合作来提供CDN服务。把CDN服务和云计算服务打包提供给客户的话,这是全球一个典型的模式。

我刚听到阿里云CDN降价的时候,并没有太大的反应。但是股票市场对这件事非常紧张,我才认识到大家对这个事情的认知并不太一样。在CDN的普及率还很低的情况下,阿里云进入这个市场并参与市场竞争,对提高行业认知度来说是很好的事。另外,阿里云提供CDN服务可以培育许多小的客户,使他们建立使用CDN的习惯,我觉得从长远来说是帮我们培养大中型客户。当客户的业务逐渐发展起来,就需要更专业更大规模的CDN提供商来获得更高质量的服务。

阿里云做CDN服务相比目前的主营业务投资回报效率并不高。首先,CDN领域并非高毛利的业务,仅30%左右,跟互联网企业动辄60%甚至70%的毛利率相比算是比较低的。也就是说100元钱阿里云投入到主营业务中有60元的回报,但放在CDN行业里仅仅30%的回报。从投资角度来说肯定是不划算的。

这和亚马逊做CDN不一样,亚马逊是个位数的毛利,它对成本控制非常严格,因此有投资CDN领域的动力。

财新记者:所以您认为CDN不会成为BAT真正会去布局的核心业务?

王松:阿里的云平台和淘宝平台到现在实际上还没有完全融合,在这个层面跟我们新平台相比还是落后的。但是阿里有淘宝这样一个特殊应用,所以他们在电商的配套服务上面的理解肯定比我们要深得多。针对电商的应用来说,应该有很多独到之处。所以他们这部分的分发是基于自己提供的服务和定制化但是对于一个电商行业,它的网络究竟该按照什么标准来构建,这是一个需要理清的问题。如果按照每年流量的高峰来建它的网络,一年中大部分时间都会出现空闲,造成浪费;如果按照日常的使用量来建起网络,高峰时的使用就成了一个问题。但是它又希望建立一个很大的平台,所以选择了按照高峰来建立网络,而把富余的流量拿出来开放使用。但是这样也有一个问题,阿里巴巴的平台要优先满足自己的业务,那在双十一这样的流量高峰时,它该兼顾哪边呢?

互联网公司做CDN,客户群会受到限制。现在阿里云的客户都是小型的客户,这些客户做大了之后肯定会面临一个问题:CDN服务、数据中心的服务要求这个服务提供者本应是中立的第三方,但是BAT这三家基本每个行业都涉及,所以跟他相关的行业可以说风险巨大,这就是CDN产业面临的非常现实的问题。但是BAT进入CDN这个领域,对这个行业来说是个好事,尤其对于初创公司,可以帮他们真正把门槛降低。

财新记者:大客户这方面有没有感到直面的来自BAT的竞争?你们担心阿里云这样的互联网公司来做蓝汛现有的业务服务么?

王松:直面的竞争没有,潜在的竞争有的。我们的CDN业务主要服务大型的企业。但是行业发展到现在,CDN业务越来越普及,这个市场对大家来说是个蓝海,全新的市场。未来新兴的互联网公司和小型企业可能是我们跟BAT竞争的市场。另一个方面,我们对每个行业的了解积累会有帮助,比如银行业,我们把某国有银行做好了,以后这个行业的其他客户我们也都能做好了。

未来的竞争是要看谁把这块成本做得更低。看在所有的环节里,谁能把哪个环节的成本去掉。

阿里巴巴最大的问题是节点都在一线城市。早期的调度可能要放在核心的网络环境好的位置,而现在越分散到二三线城市,成本越低。就好像把北京的蔬菜卖给顺义的人吃,顺义的人肯定觉得你比我们当地的价格还高,所以他们对于成本还是没有那么敏感。

互联网公司真想做个商业化的CDN,还有很长的路要走。就这种成本控制、接下来还想着怎么把夜里的空闲量用上,因为他们的用户模型是非常单一的。

财新记者:运营商也说布局CDN领域,你怎么看?

王松:全世界运营商都试图在做这一领域。现在互联网不是最简单的技术问题,而是快速地迭代更新能力。比如说运营商要建立一个平台,昨天还是微博,今天大家就都用微信了,它该怎样适应这种模式呢?

财新记者:传统CDN企业是不是也在布局云服务,包括存储运算?往底层走?移动互联网方面我们有什么新布局?

王松:其实CDN最早就是做规模化的云计算的服务,当然云计算的层次不太一样。早期是一个PAAS层面的云计算服务。我们也在不断地演进,去年开始推出新的HPCC平台上线,实现完全云化。从底层的平台到存储、前端全部都是一个平台,可以实现全网在一个平台来调度。HPCC平台服务于蓝汛ChinaCache的页面加速、文件分发下载、视频流媒体、移动互联网等核心业务,降低客户资源成本、大幅提升用户体验。更灵活的缓存模式及更快速的应变能力, 全面提升各项性能指标。

我们已经投资建设了蓝汛首鸣云数据中心,是中国第一个这种规模的数据中心。其实今天在中国还没有一个真正意义的互联网交换中心。工信部今年增加了7个交换中心,还停留在让三家运营商做互联互通的层面。其实在美国已经到了第二步,叫内容交换,前面只是网络交换。



网络交换仅是网络流量进行交换,同样一个内容一百个人就需要一百次交换;内容交换只需要一次网络交换,以后再访问的时候就不需要流量交换。

今天在中国网络交换还没完成,内容层面就更没有。我们跟西安交大正在建立研发中心,在学校周边做配套升级。西安交大出基础设施,我们出所有的技术来进行合作。所以接下来会在西安交大建立西北五省的交换中心,小的运营商、内容商都可以在那交换。美国所有大的内容商都会把自己的内容尽量放在交换中去,小企业就不需要通过网络被大的运营商绑架,从而大幅降低成本。我们的带宽成本降不下来,因为我们没有第三方的交换中心。

移动互联网方面,蓝汛于今年初发布了专门针对移动互联网的产品MPlus,该解决方案是面向移动互联网终端用户、内容提供商的B2B2C商务模式与访问加速技术的综合解决方案,帮助企业获得高于正常基础60%的通信速率,并开创性地具备了减免终端用户无线流量费用的特性,为移动互联网内容提供商业务推广与终端用户体验提升提供了更多空间。

财新记者:CDN最后会赢家通吃吗?

王松:看吧,现阶段还没有这个趋势。

【CDN大家谈之二】阿里云:冲着第一而来

阿里云宣布CDN市场降价后随即引来质疑之声,认为降价策略有门槛,并未真正惠及所有企业。宣布降价后三天,财新记者在杭州采访了阿里云CDN系统研发负责人朱照远(叔度)。

朱照远再度阐发了阿里对市场的基础判断:这个市场需要更多竞争者。在他看来,中国的CDN相比云存储和计算仍是高毛利行业,互联网企业入场将带来从价格到技术的革新,并最终影响市场格局。

“阿里做CDN和做其他业务一样,都是冲着行业第一去的。”朱照远称。

财新记者:阿里为什么进入CDN这个行业?

朱照远:CDN行业是一个需要革新的行业,这个行业有几个点:一是价格,一是技术。现有CDN服务的价格比较贵,相比云计算而言成本比较高,现在CDN市场的厂商其实是低价买进高价卖出,并没有和云计算结合,仅仅提供一个CDN的服务。另外就是价格不透明,同样的服务,三家不同大小的客户,会给出差异很大的价格。如果客户本身的议价能力不强,就可能为此付出大代价。这都是传统CDN存在的问题。

技术层面,如果只给网站一个CDN服务是不够的,很多用户都有主机和存储的需求。阿里云提供的就是一个包括主机、包括云的生态的需求,还有很多其他的服务,包括PaaS层级的服务。而这些都是传统厂商不提供的。

我们最近看了听云的一个报告,提到40%的CDN是自建的,包括BAT和优酷都是自建的。自建CDN为什么能发展,就是因为商用CDN无法满足用户需求。淘宝就是自建CDN,为什么自建?因为技术上商用CDN满足不了需求。淘宝这样的业态需要的技术服务是很复杂的,BAT三家目前都是自建CDN,互联网公司的技术能力也超过传统厂商。

以阿里云在CDN上的技术革新为例,我们的服务器是从头自主研发的,我面试过很多厂商的技术人员,他们都没有能力来研发这类服务器。阿里的LBS,四层负载均衡软件、七层负载均衡软件,都是我们自主研发的,目前都已经开源了,包括我们在TCP协议服务站也花了很大的功夫。在听云平台的CDN性能监测的结果显示,我们的CDN性能比传统厂商的服务快10%。这个10%来自于硬件、软件和基础网络的革新。听云平台是一个独立机构,和我们,和传统的CDN厂商都没有直接关系。

在阿里提供的商业CDN层面,我们从我们的客户新浪微博获得反馈是我们的CDN性能比目前最好的传统厂商好不只10%。

此外,我们云计算的CDN,是按需开通、按量分配,不是按月按年来签合同,阿里云的CDN可以按照使用量来服务。这类都需要技术适配。

我们支持海量级的域名,目前传统厂商说支持3000家客户,但我们发展不到一年已经支持2万家客户。随着传统厂商接入域名的增加,难度系数也是增加的。

阿里云进入这个市场可以和当时余额宝进入市场来类比,对于传统的基金公司而言,他们会说你这些都是小客户,每个账户才几千块钱。阿里在CDN市场也是从小客户做起。

财新记者:和传统厂商相比,你觉得阿里或者互联网公司进入CDN市场有哪些优势?



朱照远:阿里云的优势就是快,因为自建CDN的出发点和商用CDN是不一样的。淘宝的CDN自研是从2007年开始,到现在差不多八年时间,我们做CDN主要的目的是给商家提供服务,所以一开始我们都是买最好的东西。阿里在这方面不差钱,因为我们一开始就不是冲着赚钱去的。

但是对于CDN厂商来说,这是生意,所以一开始就会去采购质量差的节点,比如说我们在三四线城市建点,甚至五六线城市建点。带宽质量、稳定性和成本是不一样的,所以他们是成本优先,我们是质量优先。这是硬件层面。

为什么我们都用最好的,我们的CDN还是赚钱而不是赔钱的呢?这就是自建CDN最大的优势,我们有淘宝、天猫这么大的量将我们的峰值拉上去。举一个极端的例子:淘宝天猫的CDN使用峰值是在晚上9点、10点,其他用户都在半夜使用,我们以峰值计费,但是如果我们的用户都在后半夜使用,那这部分成本我们是没有的,我们有一个永远不和我们离婚的业务来支持。

软件层面,我们已经有很多人才来做研发,比如在防攻击方面,技术安全方面,BAT包括360都是超过百人的防攻击的技术团队。去年我们防止了一次450G的攻击,这也是中国互联网历史上已知的最大一次攻击,持续了整整一天多。

财新记者:CDN市场有技术门槛么?传统厂商在这个市场是怎么形成两家独大的格局的?

朱照远:首先,这个格局是历史造成的,从上世纪90年代末,采购带宽不是一般人能做的。能够采购带宽的人掌握了话语权和渠道。第二,这个行业没有激烈竞争。和云计算竞争已经很激烈不同,这里没有很多技术很强的企业参与竞争。我相信从今天局面会发生变化,阿里进来腾讯进来,局面会不一样的。

财新记者:CDN和云存储和计算在市场中是怎样一种关系?我们看到阿里云进军CDN市场的同时,传统CDN服务商也开始开展云的服务。

朱照远:阿里云提供的是全面的服务,有云存储,有CDN、有计算,不是说一定要用阿里云才可以用CDN,不是这样的逻辑。在这个事情上,用户可以选择。

但是对于CDN传统厂商而言,用户没有选择,就只有CDN服务。传统CDN厂商意识这一点,所以开始革自己的命,因为云计算的竞争已经是红海了。我举一个例子,对于目前排名第一的CDN厂商(网宿),它去年的净利润是25%,这净利润在云计算公司是不可想象的。

我们在云计算领域目前已经获得很好的用户口碑,你去问陌陌,问那些使用我们服务的用户,我们的服务性能好,价格还便宜。这样的业态在CDN市场是不存在的,因为竞争不激烈。

财新记者:我们知道阿里提供的是标准化的,相对通用的CDN产品,而传统厂商提供定制化的服务。这是双方产品的区别么?

朱照远:说到定制化,其实阿里除了标准化的产品之外也给客户开发定制化的服务,比如微博。我刚才说了,传统CDN厂商说他们定制化好,但是淘宝之所以要自建CDN就是因为他们的商用CDN发展得不好,否则我们也不用自建了,当然成本考虑也是另外一个因素。

如果说商用CDN认为定制化是优势,那么至少在我们这里是说不通的。另外,定制说到底是技术,这个技术在IT界、物联网界还没有公司可以超过BAT三家。中国前十的网站中有4家是阿里CDN服务的,包括一些竞争对手都在用阿里的CDN。

实际上,CDN产品不会有巨大的差异,差异体现在产品特性上,是视频、图片或者是文件下载,但是没有所谓电商CDN、游戏CDN这样的区别。因为CDN是一个偏底层的技术,不是按上层业务来划分的。

所谓定制化就是“建权”,比如说你这个用户接进来,需要对用户做出限制,不是所有人都可以接入的。但是这样的开发,阿里云每天能够搞定好几十个,没有很高的技术门槛。

财新记者:阿里云打价格战,最后大家就会说实际上也不是所有用户都是你们标出来的这个价格。

朱照远:对于大客户当然有折扣,传统CDN厂商也是如此。我们公布出来价格具备行业参考价值。对于一个想要使用CDN服务的用户而言会知道价格区间是怎样的。

其实我们之前一直都没有做商业推广,价好质优没有道理没有客户,除非是商用CDN厂商给到用户采购人员回购。其实这也是我们之前接触客户知道的商用CDN厂商给惯出来的毛病,采购的时候会问有没有回扣可以拿。我就回答说没有,可以谈折扣,但没有回扣。

CDN缓存服务器现状,squid、nginx、trafficserver、ATS性能测试

今天谈一个问题,目前cache软件在业界的使用现状。cache系统其实最大的使用场景,还是主要集中在CDN厂商里。

大概在2010年之前,各大CDN厂商基本清一色的使用squid。那时候的squid是绝对的主力。

squid的作为cache领域的鼻祖,正是由于历史的久远,很多近10年左右流行起来的很多系统特性,它本身并不支持。比如sendfile,splice和多核等方面的支持,由于这些特性属于核心架构方面的功能,后期如果想引进的话,需要对squid的核心做大量的修改。对于CDN厂商来说,稳定性是大于性能上的考量的。所以在面临业务增长的性能压力之下,几乎各个厂商内部的cache团队都要去忍痛,咬着牙去做这些大伤元气的改造。

就拿多核的支持来说,因为squid本身是单进程架构,基本上大家的处理方式就是起多实例,所谓的多实例,就是启动多个squid,通过这样的方式让它可以起到多进程的效果。(心好累

当然除了squid之外,还有一个比较新的cache,就是varnish。varnish的作者曾经在自己的博客上批评过squid中很多过时的思想。宣称自己的性能和架构要比squid强大很多。但是作为一个只支持内存的缓存系统(有可以持久化的外围手段),使用的场景是有限的。目前使用varnish的,都是一些小站,或者说热点很集中,缓存总量不大的业务场景。在前几年,我了解到新浪微博有在用它。

随着nginx的崛起,cache领域里也有了它的身影。nginx的proxy_cache功能就是为cache而设计的。关于nginx的cache功能上的一些设计,前面的系列文章里花了不少的篇幅去讲。但是要想作为一个专业的cache,nginx还有很长的路要走。新浪在2010年左右,曾经针对nginx的cache中的不足,专门开发了cache模块来来作为补充,并且开源了,名字就ncache,不过这个项目估计早就死掉了。

2009年,apache trafficserver开源。这个事件,我认为应该是cache领域的重大转折。关于trafficserver,这里有个插曲值得一提。(后面我们简称为ATS)

ATS故事就是一个悲剧。当年03年,雅虎收购了inktomi,当时公司已经彻底把ATS相关产品、代码、资料、人员全部K掉了,资产接手工程师发现在某个角落有个机器,好多土,就问问这机器干嘛的,然后某个还在公司的老员工介绍了一下,雅虎的人还挺实在,就开机看看,发现机器是一个开发测试机器,机器里的系统还能跑,里面有一些不太齐全的代码,然后测试了一下程序,看性能比squid应该好,就把代码入库到雅虎的cvs,cvs tag名字:ts-gold。代码checkin时间,2003年6月20号左右,这就是当年的yts-1.4= i ts-1.4,是ATS的祖宗。后来,ATS发展到09年,1.17版本,砍掉50%代码后,开源出来的yts1.17就是ATS2.0版本。完全是垃圾堆捡回来的,只有一个临时的像是开发测试export出来的代码,没cvs历史,没文档。据猜测,这个机器是因为放角落,不显眼所以没被烧掉,其他能烧的都烧了。

其实有心的话,你去翻开ATS开发团队,其实跟squid是有交集的。很多在squid中不完善的功能,在trafficserver中得到了完善和强化,比如squid中的COSS文件系统,就是个公认的半成品。而在ATS中COSS的思想被发扬光大,其设计和架构让人叹为观止。

正是由于ATS的出现,很多在技术上有远见的公司和CDN厂商开始对ATS的研究和使用。就目前而言,CDN厂商里网宿和帝联已经将ATS用于了生产环境。而很多新兴的小CDN服务商或者云服务提供商也纷纷使用了ATS。蓝汛则在调研后放弃了ATS,还是抱着他们的squid不放。不过近两年,他们开始拿出一部分精力研究nginx。这个属于他们团队更替的结果,这里不做评论。

关于ATS有哪些特性,性能为什么那么强这里就不细说了。以后有机会在讨论。有一点可以提一下,对于HTTP协议的兼容性,ATS是仅次于squid。squid是目前世面上HTTP类服务器里对协议支持最全面的。nginx大概只有50%。

QQ截图20150618114600.jpg

跳出CDN厂商的圈子,我们看看在互联网公司内,cache软件的状况。大概在2010年之前,淘宝内部的cache也是主要以squid为主,后来新团队在调研过ATS之后,开始将其在cache业务上推广,大概花了3年的时间,ATS慢慢变成了主力,并且在2013年的双11期间挑起了大梁。不过这两年,他们自己开发的swift缓存系统逐渐成形(这里的swift不是openstack的组件,不要混了),并且开始逐步替代ATS。

那么在阿里放弃ATS之后,其他的大公司的使用者,据我了解就是京东,新浪微博这些了。对了,小米也在用ATS。

国外的情况来看,ATS的使用目前也不是太多,比较大的有akamai,yahoo,linkedin这些了。据说google也在用哦。ATS之所以没有普及开来,跟它本身的复杂性是有直接关系的。某人曾说过,如果nginx是初中生的话,ATS就可以是博士生。(逃

不过这几年,服务器领域风头最劲的,还要属nginx。特别是国内范围内nginx的火爆场面,真是让人羡慕。这跟阿里的不遗余力的推广有很大关系。在2010年左右,网上能找到的关于nginx分析得比较好的博客,作者基本都是阿里的,或者后来去了阿里。这里面必须要提到的就是章亦春(agentzh)。他几乎是靠一己之力,将nginx推上了一个新高度。nginx lua模块的诞生可以说是革命性的。

现在使用nginx的公司,几乎都在使用nginx lua。在WAF领域,nginx lua的出现,在技术实现上来说,完全变成了傻瓜式。

由于lua天生跟c,c++的密切性,使得连ATS都支持了lua模块。所以很多公司的后端服务的架构也随之发生了改变。他们开始讲纯粹的业务逻辑剥离出来,用nginx lua来实现,放在前端。这样原来必须在cache里面用c或者c++写业务逻辑的苦逼状况得以极大的改善。

所以nginx+ats,nginx+squid的架构开始出现,并得到了广泛过的应用。而阿里现在的架构也是这样的:

QQ截图20150618114730.jpg

在上图中我们可以看到前面的nginx(也即是tengine)充当业务处理和调度,后面的cache(swfit)做缓存。这样的架构,让业务开发变得很容易,而且很高效。nginx+lua可以轻松搞定。

那么问题来了,这样的架构相比较直接用c/c++在cache写业务处理,性能上肯定会降低,那么就需要评估下性能降低的情况,如果太多,那么即使是nginx+lua换来了开发和维护的低成本,可能也是难以接受的。我专门针对这两种架构,进行了性能测试,cache使用的是ATS。

单纯使用ATS:

QQ截图20150618114813.jpg

Nginx+ATS: 

QQ截图20150618114844.jpg

  • con: 并发连接数。并发连接数,单进程单cpu处理能力取决于CPU与测试场景,请酌情设置,推荐小于9999

  • new: 每秒新建连接数。这个参数取决于并发连接数量与长连接效率。

  • ops: 每秒请求数。也作qps,是比较体现服务器性能的关键指标。

  • 1byte:首字节平均响应时间。这个是体现整体转发效率的关键指标。

  • lat: 完成请求整体响应时间(收到最后一个字节)。cache系统性能关键指标。

  • bytes/per:每秒字节流量/每秒每连接流量

  • total:服务器端总请求的字节数

  • time:测试时间(秒)

通过数据对比我们可以看到,nginx+ats的性能较纯ats,要降低大概5%,这个是完全可以接受的。注意这里的nginx跟ats是放在一台服务上的,如果分开不同的机器,那就得不偿失了,不仅latency增加,机器的数量也随之增加。

网宿科技孙靖泽:大客户需求并非标准CDN服务能满足

据数据统计,全球CDN产业规模已从1999年的2500万美元增长到2013年的40亿美元,预计2015年将达到60亿美元,全球CDN市场正进入快速增长期。

在国内,随着互联网、移动互联网流量的爆发式增长,尤其是来自视频以及云计算的高速增长,中国CDN市场更是孕育着巨大的潜力,并吸引了越来越多的厂商开始涉足CDN领域。

但就在国内CDN市场一片繁荣之时,一场轰轰烈烈的价格战打响了。5月22日,阿里云CDN宣布下调资费,最高下调21.2%;5月26日,腾讯云CDN也紧跟其后,宣布最高下调25%;5月27日,UPYUN 宣布下调CDN资费,最高下调达到27.5%……这场硝烟弥漫的价格战也不禁给业界带来无数猜想。

“阿里云的CDN服务和网宿这样的第三方CDN公司之间业务重合度很低,在CDN市场上不是直接的竞争对手。” 传统CDN企业代表网宿科技营销中心总经理孙靖泽认为,双方在平台、目标客户群、服务方式上都有很大的差异。网宿CDN主要是面向中大型客户,包括传统互联网公司、中大型企业以及政府机构等。大中型客户对CDN服务的质量要求更高,也有很多定制化的需求。与标准化自助式的平台相比,网宿CDN平台有较好的适应性、灵活性和稳定性,能更好的满足客户个性化的需求,确保服务质量。此外,网宿与客户之间是一种紧密的合作关系,网宿从销售、客服、产品及研发各个环节都和客户需求紧密耦合在一起,能保证和客户之间更好的粘性,并提供更优质的服务质量。

孙靖泽举出了美国市场的案例,此前AWS在美国市场采取降价获取市场的策略,也并未冲击到Akamai这样的专业CDN公司的市场份额,正是因为大中型客户更需要定制化的CDN服务,其需求并非标准CDN服务所能满足。第三方专业CDN公司在中立性,服务运维能力等很多方面上都具备优势,当小微企业发展壮大后,对于CDN服务有复杂的需求,网宿相信能更好的满足其要求,提供更好的CDN服务;

但孙靖泽也表示,阿里的降价策略对整个市场来说是一件好事,能让更多企业认识和更低成本的使用到CDN服务,有利于CDN市场的培育,和更好发展,并让CDN服务于更多企业与应用,惠及网民,提升整个互联网访问体验。