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

作为一个横跨通信与互联网两大行业的从业者,前四年的核心网经验和后五年的互联网经验让我不得不感慨一个非常遗憾的现实:通信与互联网两大行业本来可以有珠联璧合的技术协同,为移动互联网提供近乎零耗电零流量的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分钟存在偏差)

《微信收费事件背后被广泛忽略的技术细节》有108个想法

  1. 电信运营商也有苦衷,关键还是中国特色的社会主义。任何东西只要一戴上中国特色就会有各种坑了。不得不埋单啊。。。

  2. 信令是最佳的push载体能否详细说下,为什么它就不需要tcp连接,手机和基站又是怎么实时通讯的,短信接收的通讯原理又是怎样的

    1. 信令是由手机中低功耗的基带处理器(一般独立于CPU)控制,它工作在比TCP更低的层面,是手机与基站之间时刻保持互通的通道。基带大部分时候工作在一个低耗电的模式下,只维持这种基本的信令通道。短信、WAP PUSH都是基于信令的扩展服务,而语音通话和数据网络则是按需开辟单独的传输通道,因此无论耗电和资源消耗都远高于前者。

      至于手机与基站之间如何实时通讯,就很难三言两语讲清楚了,不妨查阅一下相关的技术文章。

        1. 在读者没有技术基础的情况下,作者也只能讲解到这个程度了吧…作为计算机相关专业学生一枚我觉得还是比较容易懂的- –

          1. 昨天写这篇文章时,没有想到会传播的这么远,所以也就没有考虑到普通非技术读者而把本文写的通俗易懂……

      1. 学过一点儿通信,但是不太了解当前各层设备可扩展性的现状。暂时不谈现实当中的利益掣肘,探讨一下技术实现吧:你提出的这个方案,按我的粗浅理解应该是要增加一些信令类型用于支持高层协议的长连接保持功能,一方面运营商要升级支撑数据业务的大量设备支持这些信令,一方面每个手机基带模块也要升级支持通过新的信令保持长连接,再一方面相关的手机操作系统要增加这一块儿的基带驱动,然后各种应用程序再开始使用手机操作系统新增的这一块功能
        ……目测工程相当浩大……如果都是软件升级能解决的话还好,我担心那么多手机的基带芯片,都是能升级的吗?
        而且信令这种东西,电信设备厂家还要在ITU商量出个标准,折腾一圈下来最顺利恐怕也要10年吧?

        1. 其实现有的信令协议设计已经提供了很多扩展空间,比如早期七号信令的UCIC,SMS中的非标端口。甚至即使使用SMS本身,也可以特殊编码后通过手机端预处理实现PUSH。

          1. 这么一说的话,实际上彩信就是一种特殊的SMS,至少俺一直是这么理解的,从早期不支持彩信的手机收到彩信会好像乱码短信一样就可以看出来了吧

  3. 难道微信不是使用苹果的APNs吗?!那跟苹果有毛关系啊。只是Android傻比,噢,是我党傻比,封了google的。那有最傻比的中移动,去死吧,拖慢中国的通信发展多少年啊!!草!!!

  4. 技术文章,原理讲得清楚。
    两大运营商长期处于垄断地位,能拉下身段和互联网公司谈判分蛋糕么?

      1. 其实运营商更应升级3G,虽然3G也会有这样的问题,但却也很大程度上缓解了这样的问题,而且升级3G对运营商和用户来说者是有利的。

  5. 好文!
    我以前也是这样猜测的,不过不懂个所以然。多谢作者的详细解释。
    黑莓的Push Mail用的是运营商的信令吗?

    我就一直奇怪为什么android不想IOS一样把推送都整合起来,原来是因为国内大局域网的原因。
    我用联通3G,有时候Gtalk打开的时候也看到掉线了,过一会儿又登上去,难道就是作者说的心跳时间过长被运营商断开了?

    1. GTalk也使用的同其它GCM PUSH共享的一条长连接,因此你说的掉线问题很可能也是这个原因。但我没有在联通3G网络下测试过,无法下结论。

  6. 关于超时释放连接有点不明白。TCP连接只是个虚拟连接,只在两个端点存在,那么运营商释放连接是什么意思呢?是不是说移动设备得到的其实只是个内网IP,需要有运营商的网关做NAT,超过5分钟就把NAT转换信息删掉了?

    1. 目前国内的移动设备所分配的IP地址都是内网IP。除了清除NAT、释放IP这类手段外,即使要仅仅断开连接也很容易,他们在国际出口网关上干这事儿已经驾轻就熟了。

  7. 受教了。
    那岂不是对于飞聊,翼信之辈,如果能搞定这个,就是对微信等的巨大卖点?
    只能说他们太不专业了,连自己的优势都一无所知

    1. 飞信离线时的短信接收消息其实就是变相在利用信令资源优势,但也只能局限于中移动网内。说到底,产品跟不上,再强的靠山和后盾在互联网市场也没有机会。

  8. 有一个问题想请教,andorid可以理解,是app有独立的心跳机制,要周期发送连接来保持tcp的连同,那是发往具体app所在的服务器的。但是在ios上的话,push机制中终端是与APNS通信的,那么收钱应该收apple的吧,和具体app还有关系么?

      1. 好吧,那这句话的意思是说运营商的压力主要来自于安卓系统带来的负担而不是ios的?还想请问下,这样说来国内外运营商压力的区别来自于这个基带空闲,您后面说中国的短是因为运营商处于信令的考虑,结果聪明反被聪明误,那是说这个与国外的区别在技术上是没有障碍的吗?那对于运营商有什么敝处使得他们不加长这个空闲呢?
        我是完全小白,所以如果理解错了的地方请谅解。

        1. 站在运营商的角度,你挂着个连接长时间没有数据流通,也是种对资源的浪费。所以这个时间空闲设置多少合适,是个找平衡点的问题。

          1. 谢谢。那目前看来这么短的空闲对于运营商来说是压力很大的,他们不会想加长时间减少自己的压力吗?难道有其他的顾虑?这种收费是最直接cover成本的方法,但感觉也是最笨的,就好像公司裁人让报表好看似的。。。而不是从更本质的方面去改变现状。

    1. 那就是说,只是应该对android上的使用信令比较频繁的APP收取费用,是这样吗?
      另外,我是一名计算机系的在校生,对博文中提到的一些通信的东西比较感兴趣,但是没怎么涉猎过,能否推荐点书供学习? 谢谢。

  9. 有点意思啊 不过说中移动因此不堪重负也不尽然吧 既然提供了上网功能 那么这种push机制应该是最轻量的了 比起刷网页 看视频玩网游来说 这个简直就是毛毛雨 只能说智能手机如今更加普及 移动互联网用户剧增 而中移动的3G网络推广不力

    1. 恰恰相反,PUSH机制对信令的占用往往是24小时不间断的,而刷网页、玩网游能占多少时间呢。况且数据网络的信令占用主要集中在接入的起始和结束阶段,使用中反而对信令层压力不大。

    1. 我的博客文章欢迎遵循『“创作共用”
      署名-非商业-相同方式分享』的转载,不用经过我的单独授权。除此之外的转载方式,请邮件联系(blog@oasisfeng.com)。

  10. 在联通3G网络下,大概几分钟的基带空闲,连接就会被释放呢? 是否能和移动的2.5G粗略比较下谁更省电呢?

  11. 其实想要解决这样的事情,就是运营商直接提供PUSH机制(类似于APN),移动网络不提供空闲长连接。这样的解决会更加完美。

    只不过,这个标准谁先来做。。

  12. 从文章的内容看起来,这个技术问题不是中移动gsm网单独的问题(当然,他们的问题大一点。)。而是全球化的两个行业间没有充分利用利用资源的问题,那么目前有没有国外的解决案例?如果作者说的问题是个主要因素,那么其实运营商倒是可以利用资源优化行货手机的性能。

    1. 确切说是彩信的通知和对方收到通知这类服务器发起的通信用的是WAP PUSH。数据传输还是HTTP连接。

  13. 看了这个终于明白了,为什么iphone 的i-message经常会出现不能实时收到的情况。可以看出两个问题:1、联通3G的信令资源也不丰富;2、apple国内的信令周期应该和国际通用的。

  14. 开放信令使用权给开发者,从技术角度讲,确实是最优方案。但是考虑到实际情况就只能笑而不语了。真开放了sms就彻底淘汰了。

    1. 其实我还有个最根本的问题没有解决,想也问您一下,这个基带释放的东东我理解的是说其他国家的更长,所以二十几分钟才推送一次,而中国的很短,所以推送的频率要多四五倍,因此运营商的压力更大是么?

  15. 关闭连接后,为何不能在网络信息中心有信息需要发送时才主动与客户端联系,然后才由客户端发送心跳重建连接?

    1. 主动下发通知的前提是中心能找到客户端,而既然TCP连接已经被超时释放了,应用层的服务器怎么知道客户在哪里?除非按照通信网的机制去寻呼手机,让手机知道中心在找它,就像打电话发短信的时候通信网做的一样,这就是所谓信令通道在做的事情之一。按我的理解,现在IP网上的服务器现在是不具备寻呼手机的能力的,除非按照作者说的这样去扩充信令体系。

  16. 有点不清楚这个信令的问题
    您说因为心跳频率过快 造成“信令风暴”
    但下面又说目前的信令仅限于SMS和wap push 还未开放给互联网企业
    这两个信令不是一回事吗?

    1. 我讲的『没有开放』指的是互联网业务中直接运用信令通道的能力,而信令本身是通信网络现有很多上层技术的支撑机制之一,比如语音通话、GPRS和HSPA。所以,当使用这些上层技术时,虽然并不直接与信令打交道,但仍然在消耗信令资源。

  17. sms和mms通道是不可能开放的,这些对运营商有辉煌的贡献历史。最有可能就是流量收费改革,不是分app而是以占信令资源分类的收费标准,比如这样1分1KB,那样2分1KB。。。

  18. 黑莓也有推送通知服务,与运营商深度合作,不但不向运营商付费,反而向运营商收费。微信为何也不采取这种合作方式呢?http://blog.csdn.net/andyweike/article/details/6562351

    1. 这里谈的是所有基于ip的移动应用的共同需要,提醒机制,最简单的实现,就是wap push, 只是在os的层面做一些调整,能识别扩展的类型,这个在wap push标准中其实有扩展,但是运营商不愿意这么做,因为这个触动了运营商的核心利益,短信和语音业务。当年的飞信实现微信的功能很容易,但是CMCC不愿意这么做,包括语音对讲,QQ很多年前就实现了,为什么不上,就是运营商,工信部不让,当年QQ还要靠着这些运营商,现在他强大了,飞信什么的只有被微信等打死的份儿。

      1. 运营商有QoS保障的服务只会向付费用户开放,而只有商务用户才愿意付费,所以只会向黑莓这样的高端用户开放。对于运营商来说,微信用户是一个大众的低价值的产品,向用户收费是不可能的。既然运营商不会在底层免费提供QoS保障,那么只能在更高层通过更大的开销保障QoS。像iOS、Windows Phone 这样的操作系统为有通信需求的应用软件(不只是微信、QQ离线推送)提供统一的消息推送服务,而不像 Android 上需要应用软件自己各自在保持运行状态不停发送心跳消息。这本来是一个相对完美的解决方案,不过前提是在3G网络上。用户有需求,而在2G网络上实现又捉襟见肘。根本的解决方法是,换3G手机,2G网络就不要奢求这种高级的服务了。

        1. 没必要也不应该向用户收费。就像我在下面的评论中所说的,其实很多互联网公司是愿意付费使用更高效更省资源的PUSH通道的,只要价格成本低于自己开发和维护PUSH服务器的运维开销,再算上用户体验的牺牲成本。

          1. 恐怕这个成本要大到开发商根本无法独自承担,不得不向用户收费来分担成本。看看黑莓的收费模式就知道了。

        2. 其实Google 的 Android 也有一个叫GCM(Google Cloud Messaging)的东西,https://developer.android.com/google/gcm/index.html 。需要Google Play的支持。但是国内是不会有人敢用的,原因是Google Play行货都没有集成,Google服务还被墙,所以使用该服务的国内开发者并不多。国内 Android 系统的手机占有率又高,更是导致了这样一个局面的恶化,不能不说这就是一个悲剧。

    2. 黑莓的黑莓服务就是利用短信来push,然后再启用http来pull,也就是文章中提到的”信令“来控制。所以黑莓服务是最省电的”push”,又很及时,但不启用黑莓服务就没法用,黑莓服务却是收费的,黑莓公司向运营商收钱,而运营商又向用户收钱。黑莓这个模式显然是终极解决方案。

  19. GSM用慢随路信道发送短信本身只是权宜之计,lte里都没有了这样的做法。博主的想法看似美好其实不切实际,控制信道和业务信道区分来才合理,控制信道传送信令需要高可靠性和低延时,业务信道则面向用户需求提供大容量和qos保证。如果非要把高层应用塞到控制信令中,就好像平时出门买菜都要坐警车开道……

    1. 也许在通信行业的专业人士看来,很多互联网的做法都是不太『优雅』的,就像当年英国贵族看待美洲大陆的拓荒者一样。

      这一点我坦然承认。权宜也好,滥用也好,总好过在长连接心跳造成的信令风暴苦苦挣扎。如果通信行业仍旧在追寻『更切实际』的大容量和有QoS保证的新技术新协议中蹒跚前行的话,只会又一次掉进像IMS这样的镜花水月之中。

      也许,两个行业离真正互相了解甚至理解,还有很长的路要走。

  20. 2004年的时候就和CMCC谈基于信令的push服务了,CMCC坚持打压IP的服务,当时我就说,CMCC终有一天会沦落到当时的网通那样的,一个渠道商

  21. SMS同样需要page唤醒用户进入连接态,一样会增加耗电,而且大规模频繁的paging对于无线网络也是一件不可忍受的事情。同时paging+SMS发送的delay对于TCP连接也不一定可行。更重要的是这不是运营商愿意不愿意的事情,现在的标准就不支持从IP数据包识别心跳消息然后转化成SMS,即使标准支持了,设备也不太容易实现。LTE标准在讨论一些解决各种心跳消息包括TCP,NAT的优化方案,但是没有太好的办法。

    1. 你可能理解错我的意思了,我们根本没必要去解决心跳的问题。通过信令(SMS)实现PUSH,就根本不需要App维持长连接,也就完全没有必要定时发送心跳了。心跳都不存在,还哪里会有『大规模频繁的paging』呢?:)

      当没有消息需要PUSH时,无需消耗任何信令资源,也就是信令PUSH的最大优势。

  22. 通过信令通道实现PUSH听起来是最理想的途径,但貌似全球目前为止没有一个可行的解决方案。假设运营商方面能实现用户TCPIP数据通道与IMSI,ICCID绑定推送,使用不同平台不同基带不同运营商的客户端应用又该如何处理?
    除非在基带硬件,操作系统,和软件应用方面进行大融和,还要获得全球大多数电信运营商的支持。

    ps.这里说的只是PUSH的实现方法,但心跳连接与PUSH不能完全划等号。即使通过信令通道实现PUSH,客户终端的心跳信号又如何实现?如果设备仍然需要定时向服务器发送心跳数据包,那信令风暴仍可能存在,没得到根本解决。
    如果把客户端状态交给运营商管理,根据UE的GSM和GPRS状态向服务提供商反馈客户端状态,运营商无法得知UE正在运行那几款软件。

    1. 软件层面只需要在App内集成一个轻量级的SDK即可实现信令方式PUSH(WAP PUSH)的接收,硬件和操作系统都无需改变。

      由于不需要再维持长连接实现PUSH,心跳自然也就不复存在了。

  23. 现在微信对2.5G信令网络造成冲击,那能理解现在微信就是利用了移动的信令网络传心跳信息,那您的结论是让移动开放免费的信令通道给微信等OTT应用?不是已经把信令网络给微信用了么?不理解,请指教。

  24. 楼主的分析精神值得表扬。不过要指出一点,互联网与通讯行业之间的并不是楼主所说“相互之间的价格观隔阂和互防心态”,两者本是同根生。如果说非有这样的心态,更多是因为我国对通讯与互联网行业利益上追求的不一致所导致的。换句话说,电信运营商与互联网企业在本土境内对利益的追求才导致了现今隔阂对立的价值观

  25. 其实你推荐的信令Push模式就是黑莓在Verizon的网络下的模式。可惜好东西总是不得人心,唉。

  26. 真看不下去这么多不懂的人这篇文下面胡乱评论。
    连接释放有三个因素:NAT会话释放,TCP连接释放和无线信道释放,IM之所以做应用层的心跳就是要屏蔽掉这些因素的影响。
    IM要做到message及时交互,无非就是要client和server一直在互相问:hi,你还活着吗?那你在哪里?这样想很容易就知道im和运营商的矛盾在哪里了

  27. 我觉得解决方法不是免费开放信令通道,而是收费开放,移动通信提供商才愿意去做,才能使三方得益,

    说不定还能进一步推动通信行业的发展甚至技术革命

  28. 非常不错,几年前研究PUSHMAIL时候就已经感觉到了信令PUSH机制带来的明显优势,除了黑莓和移动电信合作的服务以外,国内多家号称PUSHMAIL的供应商都是利用长连接或者心跳来实现的,客户端经常收不到邮件,或者一下来好几封,手机电池消耗飞快。后来国内几家PUSHMAIL的供应商都已经不在了,运营商明显是不希望有人分这块蛋糕,而黑莓的模式正好能弥补运营商利益的诉求

  29. 林,好久不了,现在玩啥呢,从深圳最后一别到现在都10年了。从毕业到现在一直都在原公司,记得发邮件给我。把微信告我

  30. 请问“绿色守护”作者就是您 吧,一直无法在市场进行购买,可以给个淘宝链接吗?我希望付费支持正版!!!!

  31. 现在国内运营商释放nat资源一般udp是1分钟,tcp是5分钟,这就是为啥国内各种app的心跳都是4-5分钟的原因。

    国外运营商以美国为例,nat资源释放一般也是tcp 5分钟,但是运营商对苹果和google的push做了特殊处理的。苹果和谷歌的push用的都是5228端口,运营商对这个端口的nat资源释放时间设置成30分钟,这就是为什么谷歌的push心跳缺省是28分钟。苹果的push应该也是介于20-30分钟之间。

发表评论

电子邮件地址不会被公开。 必填项已用*标注