我在一家CDN公司,这篇文章(也许是系列文章)总结我们在移动互联网加速中的实践。

写在前面的话

背景

我在国内一家著名的CDN公司,非常幸运的近距离接触2位硅谷的大牛, 一位是CDN行业的老专家,刷新了我无数的理念, 另一位是顶级码农,让我感受到了码农的极致。

做出了很多东西,也验证了很多东西是不靠谱的。 可惜由于公司的高(zheng)层(zhi)变(dou)动(zheng),最终都是一样的悲剧结局。 心情并不太好,但其实也没有关系,我做的就是我做的,成了的就是成了,不成的也是验证了它的不成。 对我个人而言,这是一段人生难得的奇遇,对我的锻炼和成长,都起了质的改变。

本文是否有暴漏公司机密的嫌疑?我的答案是没有。 现在很多科技公司都会在自己的官网上带上”blog”之类的页面,刻意的发布一些技术相关的文章, 表现出自己对技术的自信,(其实本质就是宣传软文)。 我写此文时定的调调是,去掉一些废话和实话,可以作为一片宣传软文,只担心表达能力不够。 本文的知识来源有很大一部分都是开源软件和互联网上公开的信息,实质上也没什么机密。 但是你懂得,产品吹的牛皮一般都比实际技术高出几个档次, (个人感觉技术人员眼里的世界总是没有产品经理眼里的世界那么美妙)。

鉴于一些担心,本文会故意隐去一些产品特性,只关注技术部分, 并且会有一些自己的想法和非本公司实现的内容,以免误伤公司的产品。

目标在于自我总结,欢迎各位留言讨论,如果能够得到专家们的指点一二,就更好了。

先推荐些资料

术业有专攻,如果你觉得对这个话题有兴趣,但看这篇文章有障碍时,不妨先把这些资料看了。 (也不排除是我的写作水平有限,如果是我表达能力不足的话,看官们看完资料就洗洗睡吧。)

  • 《High Performance Browser Networking》,中文译名《Web性能权威指南》

书是作者2013~2014年出版的,2014年5月份有了中文版。 可以在oreilly的官网上免费看英文版的

这本书在我们组经历了一系列的推荐链:

  • 刚开始接触TCP优化时,我在网上偶尔搜到了这本书的某章,我把它推荐给了我一个同事;
  • 这个同事看了后觉得非常好,就邮件推荐给我们的老大AT;
  • AT看了邮件后,生气的转给了我们一封8个月前的邮件——他在8个月前就推荐让我们看这本书;
  • 后来的后来,一个做TCP优化的哥们,向我推荐这本书,并且说可惜没有中文的,看的费劲。我告诉他,这本书我们已经推荐2年了,而且中文版都出来了。

每个专业方向都会有本圣经级别的好书,这本书个人认为是圣经级别的,就是薄了点。 其实我只想说,这本书是本好书,非常推荐CDN从业人员或http相关的技术人员看的一本书。(虽然我只看了前3部分~)

pagespeed是google的Make the Web Faster中的重要一环。 Google在Make the Web Faster中真的是做了极大的努力和开放, 其中包括很多众所周知的项目,比如spdy, 8.8.8.8,webp。而pagespeed是他们的一个兄弟。

顺便说一下,我blog的副标题Make the Web Better就是山寨的google的这个标语 lol 。

理念

项目的初衷并不是为了做移动互联网优化,而是为了做端到端的内容感知解决方案。 这一句话就有2个关键词:

  • 内容感知网络服务(Content Aware Network Service)
  • 端到端(End to End)

当然,事实上在CDN行业,这两个关键词早已被炒烂了, 烂到大家都不知道概念背后到底有什么实质的东西了。

我只能说,我们把它做出来了,而且真的很有效。效果怎么样请参考产品们吹的,我这里只说技术。

内容感知网络服务

其实本身就是个理念啦,每人都有各自的理解,本文只说我的一家之谈,不代表公司。 我理解的内容感知,是分为两部分:实现多样化内容;通过感知做选择具体使用哪个。

  • 内容部分:通过一些手段,让同一份资源,有不同的实例。比如最简单的例子:图片,我们可以存多份,可以存成高清原图,清晰图片,极度缩减图片。图片的清晰度和大小是成比例的,小的图片的传输时间要比大的图片的传输时间少很多的,当然用户的观感也会差很多。
  • 感知部分:在服务器端,我们可以使用一些手段,得知客户端访问服务器端时所使用的客户端类型、带宽速度等等。

二者合在一起,就可以实现让每个客户端,收到最适合他的内容。白话是:

  • 客户端是慢速网络时,例如2G或者信号弱的3G,访问网页时得到的是一些不太清晰的图片,但速度是很快的;
  • 而客户端是快速网络时,例如4G,访问网页是就可以得到原版的清晰图,速度还是很快的。

正是因为这段白话,我们的项目就变成了移动互联网项目了。。。。

不过这些事情也可以在源站做,说实话,源站做反倒有很多优势。 但是一般源站都会更关注自己的内容部分,CDN做感知、多样性,理论上至少是不会反对的, 事实上确实有是有客户市场的。

Content:优化和多样性

pagespeed

我们的后台优化技术是基于google的开源项目pagespeed。

有些公司非常忌讳别人说自己是基于某某开源软件,努力的将原开源软件隐藏的丝毫不漏。 (包括我们公司)。 其实开源软件都是有自己的license的,只要你遵循他的license,你改的东西,版权就是你的。 而不遵循license,一味的隐藏,就真的是剽窃了。 话说回来,现代的IT企业,哪家不用开源软件?

每个新进组的同事,我都会要求他通读google的pagespeed官网。 我们在2013年初时就接触pagespeed这个项目,那时他的核心代码都有了,但是很多feature还都没有, 尤其是没有OptimizeForBandwidthIPRO(In Place Resource Optimization),让我们走了不少弯路。 但现在好了,pagespeed的官方团队对CDN场景也都做了很多假设,真的可谓是拿来就能用, 而且保障了以后也会越来越好用。

Pagespeed的功能,基本涵盖了现今对http优化的所有点,详情请参考Yahoo性能优化的N条军规和Pagespeed的官网。 Pagespeed的功能列表,足够一个好的产品经理写篇论文了,但是本文不做详细介绍,请各位自行查阅官网。

从我的角度,pagespeed做了2种类型的功能:

  • 为源站而设计的技术点。比如做一些图片合并,资源inline,扩展cache,等等。如果你是网站的站长,恰好你的网站的后台是Apache或Nginx,我建议你毫不犹豫的尝试一下mod_pagespeed
  • 可以在CDN中使用的技术。比如图片缩减(图片质量变换、图片类型转码),css、js、html优化,等等。这些点,将为我们所用,并且经过我们的二次开发,会做出一些客户愿意为之多花钱的功能点。

提到2次开发,我们一直坚守着一个原则,就是尽量减少不必要的改动,即便是不得不去动他的代码, 也一定尽量在独立的位置开发,一定要用宏隔开。 这个原则很大程度上保证了我们可以尽快的更新pagespeed的最新代码。

我们就是站在巨人的肩膀上的。

pagespeed在CDN中的使用方式相对比较随性:

  • 可以直接使用apache的mod_pagespeed;
  • 也可以直接使用ngx_pagespeed;
  • 也可以移植他抽象出来的pagespeed library,ngx_pagespeed其实就是这种移植,不过做的比较好,被google收录了。
  • 还有一种很有意思的方法,把pagespeed的库连同libapr部分,一起移植。

当然,不能指望pagespeed的cache部分出菜,pagespeed和cache的融合, 还是需要自己思考和努力的。

我们在cache融合上做了很多尝试,比较靠谱的是libapr+pagespeed整体移植,和lightweight方案设计

  • libapr+pagespeed整体移植: 这是我前文提到的顶级码农MT的原创idea,(我辅助他实现的,也出了很大力量~)。libapr是apache抽象出来的公共库,modpagespeed的代码实现时时分为2部分的,一部分是优化部分,就是前文提到的pagespeed library,一部分是平台相关的中间层,modpagepseed中只依赖了libapr。我们只需要实现很小的一些功能,就可以轻松的(也不太轻松)把modpagespeed对接到很多cache软件中,然后使用cache软件自身的cache部分。
  • lightweight方案:这个方案本身是我们设想仅在上层cache中使用pagespeed技术时设计的,也就是cachepagespeed内容优化是两个分开的独立主体,之间使用标准http协议通信,辅助一些特殊的http头。实现要比上一种容易一些。

转码

内容优化的另外一条路是转码,例如百度转码、云适配,二者都会改变网页的framework, 生成手机专用的页面框架(简化版页面),只是入口不一样。

这个方向的技术方案我个人比较匮乏,不多说了, 如果各位知道有什么好的开源实现或思路,欢迎交流。

存粹的图片转码

单纯的图片优化(图片质量变化,图片类型转换,图片大小改变),是pagespeed的一个子功能, 也有很多开源软件、开源库实现了,例如ziproxy,也有几个基于nodejs的实现。看起来也比较有市场。 (从实现角度上看,包括pagespeed和这些软件,大家底层都是用的类似的几个开源库, 巨人也是站在巨人的肩膀上的。)

例子是:又拍云和腾讯智图(可能还有其他很多产品),可以上传图片,并且可以做图片质量变换、类型转换之类的事情。

Aware:做选择

如果我告诉客户,google开源的mod_pagespeed是一个非常稳定的、强大的apache/nginx模块, 可以大幅度优化你的网站。 而且客户的服务器恰好是apache/nginx,(二者基本占了6成以上的市场),客户也非常愿意动手去使用。 那么,客户为什么要多花钱用我们CDN的优化服务?换句话问,CDN上做内容感知服务的不可替代点在哪里?

在CDN中做,可以额外做到的就是多样性。 pagespeed(或者其他的内容优化手段)可以配置不同的参数,来得到不同优化率的结果。 但是在源站处,通常缺乏做选择的依据,所以源站可以使用pagespeed做通用优化, 但不能做更极端的优化。

而CDN通常是离客户最近的,在CDN上可以很准确的获得一些客户信息, 一个简单的例子就是感知客户端的带宽:服务器端通过发包时的RTT、发包速率等因素, 估计出客户端使用的网络类型。

当然,这个感知部分还有可能包含很多其他的因素,比如user-agent,客户端屏幕尺寸,等等。

这个技术我们还在实验中,但可以很轻松的区别2G、3G、4G的来源。 当然也会有一些问题,其中之一就是拿什么做key。 最简单的是拿对端ip做key值,但是现实是很残酷的,很多情况下2G、3G混用相同的NAT出口, 如果真是只拿ip做key的话,相互干扰非常严重,服务器端的判断就成了随机事件了。 如果使用ip+port做key,那么key不断变化、没有连续性。 目前的结论是这块很难真正的做好,除非引入SDK:sdk中生成一个uuid, 这样可以拿uuid+网络类型做key,相对稳定、连续、唯一。

SDK还可以做很多精彩的事情,但是SDK的推广永远是个痛。

TCP优化

[ ] TBC:

关于随机丢包:

有很多针对2G、3G的移动网络TCP优化算法中,都重点提到了无线网络中的随机丢包。 但是我们在实际监控中,发现随机丢包率很低,甚至低于1%。 猜测是移动网络底层对随机丢包做了重传,所以链路层的随机丢包在ip层的表现为乱序了,有待证明。

数据压缩、数据去冗余

[ ] TBC: DRE

端到端

SDK

[ ] TBC: SDK的思考,SDK的Type A B C D。

轻量级伪SDK

我们毕竟是做CDN的,推广SDK是件极难的事情。所以我个人更喜欢另外2种方式:推出加速APP,或者推广轻量级伪SDK。

我叫他轻量级伪SDK,是因为他本身不是SDK,只是一个标准: 我们可以指导我们的app客户,你们的app在做http请求时,如果在http头中加入了某些信息,那么我们的加速服务就可以非常的牛B了。

这个某些信息,就是我们的定制化协议了。例如: 手机的网络类型,uuid。

具体效果是多少还没有得到验证,不吹牛了。

APP

android、ios市面上有很多省流量加速的各种app、各种,形式各样,推广方式各样。 这类产品的鼻祖应该是onavo,我之前做过些简单的反汇编调研, 发现国内好多都是直接借(chao)鉴(xi)onavo的。。。。

基于上面说的这些技术,可以搭建出一个我自己的加速app:

  • 前端可以借鉴各种fan qiang软件;
  • 后端可以直接使用pagespeed+某种代理;

我曾计划开发一个自己的加速app,叫TomToy加速,用来实验我自己的各种想法。 不过这件事有个很不靠谱的因素: CDN行业,三分靠技术,七分靠资源。 如果没有合理的资源,加速就会变成减速了,无论技术有多靠谱。

目前手里只搞出来了一个不太稳定、加速效果不太好的demo,后续搞成了,再继续写(chui)。

HTTP 2

HTTP 2

书里有句话是说,大家在http1.x时想了很多歪点子来加快访问速度, 而http 2.0就是把这些歪点子变成了新的标准。

很幸运的在http 1.1时代也想了一些歪点子~ ~

[ ] TBC: app/sdk中引入SPDY/http 2代理的话题。

QUIC

Google在做spdy时,有个目前还不太引人注意的实验,是QUIC。 我计划把他嵌到我的app中,到时再继续分享。

[ ] TBC: UDT、QUIC、TCPEP的课题

写在后面的话

这两年做了很多东西,学到了很多,但是缺乏梳理。 这篇文章还没写完,理论上短时间内就是一片残缺的文章,不断完善。

慢慢来吧。


本文作者Thomas Zhao, 欢迎评论、交流。
转载请务必标注出处: 移动互联网优化-我们的一次CDN实践


«Previous:   使用systemtap获取.ko文件

»Next:         None.