微信收费事件背后被广泛忽略的技术细节

作为一个横跨通信与互联网两大行业的从业者,前四年的核心网经验和后五年的互联网经验让我不得不感慨一个非常遗憾的现实:通信与互联网两大行业本来可以有珠联璧合的技术协同,为移动互联网提供近乎零耗电零流量的PUSH机制,但由于两个行业之间长期以来的价值观隔阂和互防心态,导致如今的手机PUSH技术不仅为用户增加了显著的电量消耗,还对移动运营商的基础设施造成了完全不必要的信令压力。微信与运营商的纷争正是这种冲突集中爆发的结果。

看到不少来自两个行业的专业分析,通信行业的专家谴责微信过于频繁的心跳和短包导致“信令风暴”,而互联网人士则往往站在用户与道德的制高点上对移动运营商挖苦讥讽,双方都很少探究这个问题的深层次技术和利益矛盾。这里我不妨提一提有些大家没有真正重视的技术细节。

为什么使用同样PUSH技术的Apple和Google等巨头,没有被运营商卯上,唯独单单拿微信下手?大家也许会认为这是运营商欺软怕硬,拿Apple和Google没办法。其实从实际数据上来看(下面将提到),微信确确实实产生了远超Apple和Google的信令需求。难道是因为腾讯技不如人,被逮着了尾巴?其实不然,我们曾经也在PUSH技术上投入了较多的分析研究,其中一项发现或许可以解释各种原委。根据分析,一般当基带空闲超过一定时间后,运营商的IP网关会自动释放(关闭)连接。目前各家所使用PUSH通道的实现原理虽然同为『长连接慢心跳』,但这个『慢』字却有很大的文章。Google在Android系统中使用蜂窝(2G/3G)网络连接GCM的PUSH通道时,默认采用的心跳周期是28分钟,这才是所谓“慢”的含义 —— 尽可能降低心跳的频度,从而达到尽量省电的目的。但这个放诸全球绝大部分地区借行得通的规则,到了中国大陆,就出现了问题。以中移动的2.5G网络为例,经过粗略测试,大约5分钟左右的基带空闲,连接就会被释放,这就是为什么微信Android版本选择以『5分钟』为周期发送连接心跳。可能有人会有疑问了,『那Google以28分钟发送心跳,岂不是在中移动的2.5G网络下无法保持PUSH长连接?』事实上,确实如此,这也是为什么Google的PUSH通道经常『迟到』。当我们活跃使用手机时,由于基带往往并不会闲置,所以部分掩盖了问题的本质。另外,当连接到Wi-Fi时,宽带的网关一般没有空闲释放机制,所以长连接会得到保持,这也进一步减少了我们平时遭遇的PUSH迟到。

『5分钟』的心跳周期到底是什么概念?可以理解为,每部安装了微信的Android设备每天发送近300条短信(其实占用的信令资源还远超这个数量);还意味着每天你的手机将被从待机省电状态唤醒近300次,每次相当于打一个几秒钟的电话。粗略测算,一般的Android手机每天有超过15-20%的电量被消耗在发送过度频繁的心跳上。其实,这都还远不是最糟糕的事情。由于众所周知的原因,大陆行货渠道发售的Android手机都无法使用Google的PUSH通道,原本每个手机中只需要建立的唯一共享的PUSH通道,被人为分裂,以至于每一个声称为用户提供实时通知的国内App,基本都在重复上面微信所做的行为。当你的手机中同时安装了多个这类App时,无论手机的耗电,还是运营商的信令负担,都要数倍于上述情形。

虽然我向来不惮以最坏的恶意揣测国内的垄断巨头,但在这个事情上,中移动或许确有它的苦衷。正如很多技术文章中所言,2G网络的基础结构和协议并未针对IP传输优化,其服务IP链路的信令承载能力相对较弱,而TD-SCDMA又长期得不到真正的发展,导致中移动的2.5G网络承受了超龄超载的负荷。刻意缩短空闲连接的释放超时,可能原本是期望能起到节省信道资源的目的,没想到聪明反被聪明误,这一限制性的举措让互联网应用不得不以远高于正常的频率发送心跳以维持PUSH长连接,结果大大加重的信令负担,给本就脆弱的2.5G网络雪上加霜,而且更给用户的手机造成了远超常规PUSH技术的电量消耗,造成了如今这一『三输』的格局。

其实,不光是微信,整个移动互联网行业都在努力解决PUSH机制目前所面对的各方面问题。包括Google、Apple这样在整个行业举足轻重的巨头,都仅仅在OSI通信协议的4层以上作各种努力,目前几乎所有的PUSH机制都基于『TCP长连接慢心跳』方式实现。虽然『慢心跳』如果得以正常工作,可以在一定程度上降低手机基带模块的工作频度,但无论互联网行业在技术上再如何标榜“PUSH”相比“PULL”的流量优势,但在OSI的下三层来看,基带模块所承受的负担和“PULL”仍然没有本质差别。这就决定了耗电问题不可能从互联网技术层面彻底解决。事实上,在移动通信网络中,信令是一种天然的最佳PUSH载体,它不需要任何IP层的收发包(也就不需要TCP连接)就能实现秒级的实时性,最重要的是它没有任何额外的电量负担,手机完全只需处于正常的待机状态。可惜移动运营商只会将其运用在一本万利的SMS(及WAP PUSH)服务,压根不可能无偿提供给互联网产业使用。结果,互联网行业选择了虽然不用付费,但却代价高昂的『TCP长连接』,只为让用户享受到免费的通知服务。这种两大行业置用户体验于不顾的分庭抗礼,已经相持近10年,而当互联网终究开始以免费服务反噬移动运营商的SMS甚至语音业务时,运营商再也坐不住了…… 但与其饱受信令风暴的折磨,不如主动免费开放信令通道作为更高效的PUSH通道给互联网产业使用,再以『免费增值』的思路构建有QoS保障的VIP PUSH服务。不仅可以大幅度节约信令资源,更能以用户体验的提升打造核心竞争优势和增值空间。能否走出这样一条转折的道路,就看运营商是否愿意转变思维了。

注:由于iOS系统的相对封闭性,暂时未能测定Apple的Push通道APNS在2.5G网络下的长连接心跳周期。欢迎了解的朋友补充测试数据。


UPDATE:更正微信Android版在中移动2.5G网络下的心跳周期为5分钟(此前测定的2.5分钟存在偏差)

用Chrome更高效的网购

疯狂淘宝的网购达人,都有一个共同的烦恼 —— 打开了太多浏览器标签,以至于标签栏拥挤得只剩图标,混乱到快要抓狂。

以前,我一般会建议用『多窗口』的方式对标签进行分割,在开始一段将用到大量标签的浏览之旅前,开启一个新窗口将会让接下来的浏览脉络更为清晰。因为在『多标签』成为浏览器的标配后,大家往往忽视了窗口的价值。

但我逐渐发现,除了对事物有很强梳理习惯的人士外,普通用户大多很难养成这个习惯,因为『事前规划』在很多人看来比预测地震还要困难,往往都是在标签泛滥成灾之后,才会意识到苦痛已然铸成……

不过现在有一个更易行的技巧让没有事前规划习惯的人,也能轻松驾驭,而且无论是深陷标签的泥潭,还是初涉痛苦的沼泽,都能随时全身而退!前提是用Chrome浏览器。

例如当一个网购达人在不自不觉中打开了20多个淘宝窗口(画外迷音:淘宝前端最喜target=”_blank”……)已然完全分不清哪些窗口是『牛仔裤』,哪些窗口是『爱疯舞』,还有哪些只是路过的搜索和店铺…… 这个时候,要在Chrome中把这几十个窗口理清楚,其实相当容易!如果你之前搜索了『牛仔裤』并从结果页打开了很多件商品,那么随便在任何一个商品页或者搜索页的Tab标签上点击右键,点选『按打开者选择 (Select by opener)』,这时你会发现整个标签栏会变暗,而精确地留下了所有牛仔裤相关的商品页和搜索页的标签被点亮。接下来只要简单的将它们轻轻往下拖拽,就把这组标签划到了一个新窗口中。亦或不需要这些页面了?直接关掉整个新窗口~

按打开者选择

是不是很神奇?别激动,还有更智能的!假如你从搜索到商品页后,又进入到这个卖家的店铺去逛了一圈,打开了店铺中的很多商品浏览,这时候,同样是用『按打开者选择』(无论是对店铺页还是其中的商品页),这次被点亮的就是这个店铺和店里的商品了~

除了『按打开者选择』外,还有另一个『按域选择 (Select by domain)』。它适合当你在多个B2C网站之间穿梭浏览时,轻松的把他们按网站区分开,或是想关掉所有的商品页,抽出打开的搜索页…… 慢慢去体会和发现更多的适用场景吧~

这就是Chrome,把复杂的技术融入简单的交互之中,激发出使用者无尽的形象力~

注:上述特性在本文发表时仅限Windows版Chrome中提供。

UPDATE: 如果你的Chrome中没有发现上述标签页菜单,可以尝试在『about:flags』中打开『向标签页右键菜单中添加分组选项』这个功能开关。

阿里云主机试用体验

内部受邀试用了一下阿里云主机,让我此前对阿里云的印象有所改观。在云主机产品上,感觉阿里云还是比较能沉下心来客观面对国内的中低端市场的,并没有摆出阳春白雪的姿态来。

尽管内部试用邀请是针对『标准A型』的规格,但我坚持换成了『经济A型』,因为最低端的型号往往更能看出一家主机公司的态度和良心。

规格

阿里云主机目前的规格搭配,感觉不是特别合理,可能影响到成本及性价比。比如经济A型,单核、512M内存,60G空间,1Mbps的带宽。在这个CPU及内存规格下,空间显得太充裕,而带宽则较局促。相比之下,盛大的云主机似乎更为人性化,类似的规格『超微』,也是512M内存,存储是7.5G,带宽可独立选配(这一点是大爱),更贴合小型创业团队的需求。(也许阿里云更多面向的是电商建站,规格需求略有不同)

从阿里云的产品线布局来看,存储方案应会主推OSS和RDS。或许限制主机带宽是推广OSS的一个市场策略,但大容量的主机存储却感觉与这个目的背道而驰。

价格

因为阿里云主机的规格是绑定了带宽的,所以跟盛大云对比,同规格的价格差不多各有胜场。但是考虑到盛大云的规格搭配对小型互联网初创产品更为合理,而且带宽规格可以分开购买,就显得更有性价比了。

注:最近阿里云的高调团购促销,让价格无形中增添了相当的吸引力。预付一年省两个月,实际享受最高16个月(视团购成交量),还可以升级到1G内存和2Mbps带宽(对应『经济A型』)。相当于¥66/月的价钱购买接近『经济B型』的规格,已经比大多数国内VPS服务商的促销给力很多了。

配置

基于Xen PV虚拟化技术,目前提供的OS安装选项有点少,尤其是32bit系统,只有CentOS 5.3一个选择,对于选择小规格主机的用户有些不便。毕竟小规格主机,尤其是在内存有限的情况下,更倾向于使用32bit系统以节省内存。

后台因为上线不久的缘故,还显得略微粗糙了些,小问题不少,不过都影响不大,但其中有一点需要特别小心:管理控制太上面的停止和重启操作,是没有任何确认过程的。这样一个下拉选择框执行关键的维护动作,稍有不慎就误操作了……

性能(测试篇)

用hosting社区标准的性能测试工具unix-bench作了一个简单的横向测试(测试条件有限,数据仅供参考)。作为对比的几款主机除了大家所熟知的Linode 512之外,还有Lightwave的Xen VPS,阿里云的老双开集群Linux主机。

Aliyun Eco.A Lightwave PV.Tiny Linode 512 Aliyun Old
Specifications Virt 1 core Virt 8 cores Virt 4 cores Virt 2 cores
Dhrystone 2 using register variables 2127.5 1929.0 3024.8 2170.6
Double-Precision Whetstone 523.7 2572.6 1375.3 925.6
Execl Throughput 836.0 596.7 564.0 1673.0
File Copy 1024 bufsize 2000 maxblocks 2190.0 556.3 783.7 280.1
File Copy 256 bufsize 500 maxblocks 1495.3 441.2 489.7 183.4
File Copy 4096 bufsize 8000 maxblocks 2939.5 826.4 1573.5 461.2
Pipe Throughput 1436.6 1985.2 1242.4 1527.8
Pipe-based Context Switching 776.4 716.8 440.3 1429.7
Process Creation 966.8 532.4 407.8 1822.5
Shell Scripts (1 concurrent) 1036.6 1471.0 1355.7 2396.1
Shell Scripts (8 concurrent) 989.5 1347.6 1275.7 2516.0
System Call Overhead 2147.2 1049.8 838.5 895.1
System Benchmarks Index Score 1290.3 995.4 937.0 1045.8

可以看出,阿里云主机的优势在于相当强劲的IO性能(可能受益于现阶段母机整体IO负载较低),而在整数运算方面,Linode的优势更为明显;Lightwave的浮点性能强劲得益于它的AMD Opteron CPU。遗憾的是,在系统调用的开销上,阿里云主机似乎显得不太正常的高,可能与采用的虚拟机架构及参数调优有关。整体得分,仍然是阿里云主机胜出,显示出了阿里云主机目前在规格方面相当的诚意。

对于大部分Web或Mobile应用来说,主要关注整数和IO性能两方面,其次关注系统调用开销。JVM型后端可以不用太过关注进程创建和pipe方面的性能。

性能(感受篇)

为了有一个更为直观的感受,我在阿里云的主机上测试了一下Android源码的编译(CyanogenMod 10),首次编译大约耗时8小时,增量编译在2小时多一点。整体来说感觉比较满意。

操作过程中,shell的整体响应很稳定,没有出现国外低端VPS常见的卡顿(非网络原因)。

网络性能由于暂时没条件作国内云主机间的对比测试,就简单说一下直观感受吧。测试100M单线程下载,下行速度稳定在标称的带宽限额上,而上行带宽则没有作带宽限制,测试过程中曾经稳定达到了8M/s,这一点非常适合上行带宽需求不小的应用类型。

总结

整体上,阿里云主机给人的感觉是中规中矩,仍有较多值得改善的方面。但在一些细处,仍显示出特殊的吸引力,例如强悍的IO性能、无限制的上行带宽、高质量的双线阿里机房。作为一家国内一线的主机服务商,售后服务和技术实力方面还是有所保障的。鉴于阿里云敢于作出『100倍故障时长赔偿』的承诺,看来对于自己的可靠性技术相当自信。

无论是国内的小规模初创团队,还是Geek们希望跨越电信/联通的互通鸿沟,都值得趁阿里云此次难得力度的促销优惠,低价入手这个还处在培育期的云主机,至少可以少受小型主机服务商普遍的超售困扰。

Dropbox使用技巧拾零

Dropbox可以算是文件云同步领域的鼻祖了,即使不是最早出现的,也是第一个推动云同步向普通互联网用户普及的。Dropbox的成功并非偶然,其强大而且独一无二的功能和技术是支撑其用户忠诚度的基石。作为一个Dropbox的早期用户,使用至今,有些小经验小技巧,在这里与大家分享一下,希望能帮助大家把Dropbox的作用发挥到最大。

值得信赖的差量同步

『差量同步』是Dropbox相比其它同类云同步工具的核心技术优势。其效果可以简单理解为,文件的变更只需同步变化的部分,为用户节省流量和时间。差量同步所带来的好处其实还不仅仅是文件的变化同步更快,你还可以随心所欲的将文件或整个文件夹从Dropbox下的一个位置移至另一个位置、更名,甚至拿掉一段时间之后再放回来,它们都不必重新被上传到服务器。而其它云同步工具就未必能这么省心了。

Dropbox的其它一些特性,也是建立在这个机制之上的。就拿『文件历史』功能来说,别担心Dropbox会消耗数倍的空间来保存文件的历史版本,其实它只是保存了多个版本的差异,这样消耗的空间通常是非常少的。

得益于强大的差量同步,你甚至可以在Dropbox之上构建其它存储技术,并保持高效率的同步。比如在Dropbox中使用TrueCrypt,由于后者对加密数据的变更作用到卷文件上体现为局部的变化,所以可被Dropbox高效的同步,而完全不必担心一点变化而导致整个庞大的卷文件需要重新上传,这是其它一些云同步工具所无法比拟的。不过,在这类场景下需要非常小心『变更冲突』可能带来的不良后果(产生两份不和谐的副本),尽可能不要同时在多处对数据进行修改。

继续阅读Dropbox使用技巧拾零

时代的弥思(2)——角斗士的悲怆

把刀用力刺进另一个人的身体里,观众会为此向你喝采、崇拜你。
而你,也会开始为了喝采声,而爱上他们……

最终,我们都会化为一堆枯骨。
可悲的是我们无权选择命运,但有权决定如何面对死亡。
唯有如此,才能像个人一般的。被人们追忆。

——电影《角斗士》

 

对角斗士而言,荣耀之外,就只剩下深深的悲怆。他们无法为命运抗争,因为在那个时代,他们仍旧是奴隶,只是比其它的奴隶活的更体面一些。

奴隶社会脱胎于那个崇尚『各尽所能、按需分配』的原始共产主义,看似是一种倒退,但却有其内秉的必然性。劳动生产率的大幅提升,尤其是手工业的出现,使部落有了富余的产出,从而推动了财产公有制向私有制的转变。人性中的私欲被释放和激发,催生了部落内的背叛、对立、压迫和剥削。战俘和刑律只是蓄奴开始的幌子,对财产的占有和对资源的控制成为了奴隶社会的阶级基础。表面上看,不平等的阶级结构削弱了投入生产的劳动力,但恰恰是这种『不平等』释放了奴隶主阶层的时间和思维,从而产生了脑力劳动和体力劳动的分化,进而孕育了知识经济并在往后的历史中长期主导生产的变革。生产力在这种残酷的不平等制度中得到了长足的进步。

可是,在我们感叹于教科书上对那个久远年代略带嘲弄的描绘时,有多少人真正意识到,我们正在又一遍重演这个无法阻挡的历史进程?或许看起来并非那么的雷同和明显,但背后左右社会演进的冰冷规律却是惊人的一致。互联网正在你、我、及每个人眼前,迅速的从那个曾经自由、无私的原始共产主义社会大步踏上走向奴隶社会的不归路……

这并不是危言耸听,请试着回答以下两个问题,然后再回头审视上面的结论:

  1. 互联网的『自由』和『免费』精神,是否正在被Facebook、Apple,甚至曾经高举这面大旗的Google所边缘化?
  2. Web所倡导的『开放』与『互联』的精神,是否正在被一个个所谓的『平台』筑起的一道道高墙所摒弃和切断?

继续阅读时代的弥思(2)——角斗士的悲怆

时代的弥思(1)——这是一个什么社会?

『这是最好的时代,也是最坏的时代』,周围的人常常这么感叹,但对这个时代的理解,却是仁者见仁智者见智。既然谁也说不清楚这到底是一个怎样的时代,反正离世界末日说不定也剩不到一年了,那我也就不惮来发表一下自己对这个互联网时代的拙见,算是为这个博客扫扫门前积雪吧。

2011年,读了两本有意思的书,一本是上半年老陆赠予的《Facebook效应》,另一本是年底前在亚马逊上购买的《认知盈余》。两本书我都是抱着批判的心态来读的,对前者的批判是启发我思考的线索,每当我的思路陷入停滞的时候,我只要翻开《Facebook效应》来读一读,并顺着书中理论的反方向走下去,就豁然开朗了;对后者的批判并不是我的目的,但每当我的模型遇到挑战时,就翻开《认知盈余》相关的章节,试图从中发掘破绽,这些破绽往往能指引我化解模型中的矛盾和冲突,让它重归优雅。所以,我非常感激这两本书,它们让我在2011年末经历了一次有生以来最为激烈的头脑激荡,并为我的2012年指明了方向。

继续阅读时代的弥思(1)——这是一个什么社会?

评价机制在C2C网购发展历程中的浮沉变迁

和不少人聊过关于网购的评价机制,尤其是C2C模式下的评价,大部分人都会抱怨淘宝或是拍拍现有的评价体系中存在着这样那样的问题。但实际上,评价机制也是随着C2C市场环境本身的变化,而在发生着相应的改变。只不过有时候市场的变化很快,走在了前头,而评价却有些跟不上脚步……

第一阶段:网购市场的圈地时期

在网购诞生的初期,C2C市场可以说是一个冒险者的乐园。大部分在这个时期接触并开始网购的人,都能回想起那种“提心吊胆”的网购感受。那个时候,市场其实还很单纯,并没有多少投机的商家,尤其是在淘宝推出“担保交易”的背景下。

初期的C2C市场,需要的是高速的、爆发性的增长,网购相关的机制设计都围绕着这个中心展开,评价也不例外。“好中差评”机制虽然从现在的眼光来看,有着种种内在的缺陷,但在当时的历史条件下,它所强调的“量”的积累价值和对“好评率”的追求,承载了拉动和助推网购高速发展的关键作用。

第二阶段:爆发式增长后的巩固时期

当C2C网购经历了初期的爆发式增长后,市场规模已变得日渐庞大。这个时候,必然会出现各种各样的市场秩序搅局者。“好中差评”的方式,也开始逐渐暴露出其负面的问题:

继续阅读评价机制在C2C网购发展历程中的浮沉变迁

从胶水到运河——Google Wave的战略使命

  先来看一下Google的愿景及其诞生至今的战略布局。Google的终极愿景很明确,也几乎没有改变过,那就是:“整合全球信息,使人人皆可访问并从中受益。” 这句话讲的挺有技巧,整合全球信息,并非简单的供你们搜索和访问,“从中受益”,那前提是Google需要充分从这些信息中挖掘出价值,而后才能造福大众。“掌握和控制信息”是Google所有从属战略的核心。

  第一代搜索引擎所代表的是“整合互联网静态信息”的愿景,Google借助其强大的搜索引擎和海量存储成功的树立了搜索领域的霸主地位。在这个年代,整合互联网信息的方式相对比较直接了当,那就是“蜘蛛+索引+搜索”。大部分静态内容都是可以方便的直接访问到的,因此Google只需要构建一个巨型索引就可以达到整合信息的战略目的了。

继续阅读从胶水到运河——Google Wave的战略使命

探究Google的Iterative Web App软件架构

Google的软件架构向来是最吸引广大开发者的眼球并被人们乐此不彼的津津乐道,尤其是那些运作在Google最杰出服务背后的软件架构。

Google在2004年“愚人节”推出的Gmail服务可以说是Google众多服务中,除搜索外最杰出的典范之一。Gmail在过去五年多的时间里,也经历了一个持续发展和演进的过程。新功能的推出和用户体验的改善或许是大家谈的最多的,但其底层架构的变迁却并不常常能被用户切实感受到。其实,正是因为Gmail底层架构的不断升级,才支撑其众多新特性和功能的更快开发并上线。

早在2007年10月,Gmail的官方Blog上就曾经发表过一篇关于其架构变迁的文章“Code changes to prepare Gmail for the future”,其中提到:
继续阅读探究Google的Iterative Web App软件架构

Twitter启示录

Twitter的成功,证明了挖掘已有产品间覆盖交叠的薄弱地带,面向用户需求作精确的定向设计,并不需要提供强大的功能,也能脱颖而出,创造一片蓝海。

蓝海是怎样发掘的

在Twitter这种微博客形式出现之前,博客(Blog)和即时消息群(IM.Group)是两种泾渭分明的在线交流形式。博客以博文为中心,辅以评论作为异步交流的空间;而即时消息群则强调实时性和直接交流。前者由于其过于中心化的倾向,弱化了交流的过程,而且过于依赖博文作者的写作意向;后者因其受众的相对固定性,难以充分满足个体的自我表达欲,同时也阻碍了更为广泛的交流,使得讨论主题不易凝聚。

如何才能兼顾博客“自我中心的表达”和即时消息群“及时广泛的交流氛围”,Twitter给出了答案。通过限制字数来有效降低博客的写作门槛并拓展其题材空间,鼓励更多的普通人群加入自我表达中来;另一方面,引入follow机制,吸收SNS的理念,增强了交互的广泛性和及时性。虽然最终的融合使得Twitter上的消息既没有博客看起来那么正式,也没有即时消息群那么及时和活跃,但却有效的弥补了两者的不足。满足用户最切实的需要是Twitter成功的关键。

简单和开放铸就成功

继续阅读Twitter启示录