• 谈论信令风暴


    由于移动和腾讯微信负责争吵近期问题,很多混合“知道真相”的big mouth。商收费的问题。无厘头地作为电信运营商向用户收费而破口大骂。

    信令风暴的问题在去年開始有接触。影响不是一般的大,对于扩容,有60%是因为信令过载引起的,全部也想整理一下各方材料。

    信令风暴与空口有关,而有人在微博上却以为是承载在IP上的互联网消息。而迫不及待地开骂。

    终端在休眠时,触发向发送数据(如心跳消息发送,有如微博消息提醒的定期向server查询),须要主叫连接建立。分组控制功能块(Packet Control Function,PCF)主要作为射频部分与分组网络(IP网络)间的接口。

    终端在休眠时。假设服务器向它推送数据(如push,即业务在IP上的建立TCP长连接实施server à client推送消息,注意IP层是PSDN后面的事情了)。须要被叫连接建立。

    由此可见:

    1、 假设连接处于休眠。不管是终端主动发送,还收被动接收,应须要进行进行空口信令的协商以进行激活;

    2、 被动接收比主动发送须要的交换的空口信令多。寻呼过程中的容量表现为寻呼容量,接入过程中的前向信令容量容量表征为控制信道容量。接入过程中的发现信令容量有反向接入容量表征。而眼下的载扇的首要瓶颈在寻呼容量(寻呼容量小于控制信令容量和反向接容量)。假设容量不足必须进行扩容,否则会出现寻呼受阻。

    微博业务是查询类业务,为主叫连接。

    微信类业务是双向业务。为主叫连接和被叫连接。手机上有不同应用,不同业务之间的心跳/轮询的发送时间不一致,push时间也不一致,假设同一时候Andriod后台执行若干应用,则累加的信令很可观。而微信触发激活的频率特别高,特别消耗空口信令。

    问题的关键在于:为什么终端会出现休眠,而导致不断进行空口连接激活?

    导致休眠有两个方面:

    一、 智能终端系统通过高速休眠(Fast Dormancy)的方式实施节能省电,提高电池续航能力。以下资料来自未经验证的网络资料:Android智能手机频繁休眠所带来的信令是普通手机是否频率的7.5倍[1]。也有某些资料说是10倍。详细的Android和iOS系统进入休眠的时间查不到,能查到的仅仅是主进程堵塞的时间。大致是5秒,不清楚两者是否关联?

    当智能手机在短期内不使用时。它们将进入空暇状态。当用户须要使用时。须要和网络进行信令交换来唤醒手机。

    为了省电,高速休眠支持智能手机高速回到省电空暇状态。详细时间多长,没有查到,可是程序须要对应用户的操作,最要能在200ms(0.2s)之内。假设超过5秒没有反应,ActivityManager会没有提示就kill了activity进程,激活须要又一次onCreate(),因此对于长时间操作。须要採用后台程序。

    写过程序的都知道。要让程序对用户输入响应及时,避免程序在某个操作时僵死的情况,那就要把耗时操作放到后台去做。然后通过异步的通知或者回调来接着流程往下走。否则的话耗时操作会把主线程堵塞,导致程序非常长时间不回到主事件循环。这 在移动平台上尤其重要,一般移动平台上系统都会有一个专门的检查机制,看程序有没有非常长时间被堵塞住。没有回来检查主消息队列。发现这样的情况一般都是把程 序作为“无响应”干掉。iOS普通情况下是10秒为上限。10秒内程序没有回到主消息循环就被干掉。在前台后台切换时更严格,大概是5秒左右。[2]

    二、运营商基站,假设连接长时间不用。也会将资源释放出来

    依据资料[3]:中移动的 2.5G 网络为例。经过粗略測试,大约 5 分钟左右的基带空暇,连接就会被释放,这就是为什么微信 Android 版本号选择以“5 分钟”为周期发送连接心跳。

    导致不断激活也有两个方面:

    一、 应用是怎样实施心跳/轮询机制。依据资料[4],微信具有:1)单次传输的数据量较小。 2)接入和释放频次较高;;3)在线时间长但传送数据的时间非常短;;4)上下行传输的数据量较为对称。具有典型的信令风暴业务的特点。

    二、 有没有可能多个应用同步实时心跳,这样空口信令就可大量节省。


    中国移动和腾讯的矛盾在于用户为移动流量进行的支付,可是业务的空口信令资源,也即微信所依赖的基础建设所有由运营商支付,而作为微信业务的主要盈利者腾讯公司没有提供一分钱的基础建设费用。

    中移动方面提供的统计数据显示,微信已经占用了中移动60%的信令资源。但只带来了10%的移动数据流量[5]

    正如电信行业的资深专家韦乐平所说:产业链关系失衡,建网者赔钱(利润非常低),应用商赚钱(利润高速增长),利益相上层互联网应用上转移,底层电信运营商边缘化、低值化。韦总还说:基于IP承载层设计的移动互联网业务应用与基于集中调度的移动网是天然不匹配的。基于IP层平等理念的业务应用开发导致了大量网络容量和信令资源的浪费,但互联网和移动网这两边谁也动不了。这话非常精彩,移动基站要集中调度,反复地利用频谱资源。而平铺的互联网并不考虑这些。而在电信基础建设运营商向互联网运营商收费补贴基础建设的博弈中,有一拨人有意无意地误导为向用户收费进行煽动。而一些自觉得懂点IT就是,会点编程,就觉得懂电信通信的人在起哄,只能说明运营商在已经沦为弱势群体。

    为何公布这种感叹,有些以学富五车自居的如 @李开复 就发出了如此不懂技术并极具误导的微博,我分几条微博评论道:实际刚好和不学无术的 @李开复 所说相反,为了避免QQ和微信造成基站的信令风暴,应该避免要使用这类互联网服务。以保障基站有足够容量可以为真正有须要的服务,尽量使用短信,少使用语音,不要使用QQ/微信。@李开复 将这条删了,虽信口开河,但知错能改。

    但我仍极不喜欢他。他的big mouth常常不负责任。被称人生误导师,是有道理的。



    [1] http://www.gsta.com/news/15006.html

    [2] http://www.cnblogs.com/linyawen/archive/2012/07/24/2606709.html

    [3] http://www.alibuybuy.com/posts/81071.html

    [4] http://www.weste.net/2013/4-7/90227.html

    [5] http://jingji.cntv.cn/2013/04/05/VIDE1365097318724308.shtml

  • 相关阅读:
    apache-atlas 深度剖析
    Robot Framework自动化测试框架核心指南-如何使用Java编写自定义的RobotFramework Lib
    Hbase架构剖析
    Mysql 执行计划以及常见索引问题总结
    RobotFramework自动化测试框架-Selenium Web自动化(三)关于在RobotFramework中如何使用Selenium很全的总结(下)
    kafka connector 使用总结以及自定义connector开发
    flink 流式处理中如何集成mybatis框架
    RobotFramework自动化测试框架-Selenium Web自动化(二)关于在RobotFramework中如何使用Selenium很全的总结(上)
    一次flume exec source采集日志到kafka因为单条日志数据非常大同步失败的踩坑带来的思考
    MongoDB Java API操作很全的整理以及共享分片模式下的常见操作整理
  • 原文地址:https://www.cnblogs.com/blfshiye/p/4582659.html
Copyright © 2020-2023  润新知