微信对网络影响的技术试验及分析(论文全文)

前言


本文来自论文《微信对网络影响的技术试验及分析》,文中研究了微信对现今移动网络的影响,对于即时通信开发人员来讲,文中的某些数据和研究结果,对于实现相似的技术,有必定的参考和借鉴意义。即时通信网(52im.net)现全文收录之。

摘要


针对业界对微信是否影响移动网络性能的争论,进行相关的技术试验,跟踪微信在IP层以及在无线网络信令层的流量,以实际数据分析微信对移动网络的影响,并提出解决微信问题的建议方法。

引言


2013年2月底,一则关于电信运营商要向微信收费的传闻引起了行业震荡,据2013年3月31日财新网报道,工业和信息化部(下文称工信部)部长苗圩当日在参加第二届“岭南论坛”时表示,微信有收费可能,但不会大幅度收费,工信部正在协调运营商微信收费一事, 他们会考虑运营商的合理要求。

在此以后的几个月中,争论并未中止,腾讯一直经过微信官方微博等各类途径表示微信不会收费,而且腾讯将和运营商探讨互惠互利的长远合做;工信部则声明互联网和移动互联网等新业务是否收费由市场决定, 工信部将坚持“其经营者依据市场状况自主决定”的原则;中国计算机学会等社会团体则认为运营商在未经有关法律程序的状况下试图增长收费名目是没有依据的, 涉嫌双重收费。

在争论中,运营商以及通讯行业的专家认为微信过于频繁的心跳和短包致使“信令风暴”,由于据数据显示,微信占据中国移动60%的信令,却只产生10%的流量,已经影响到传统业务的质量;而互联网人士则站在用户与道德的制高点上提出异议,认为微信是合理使用运营商的业务规则。可是不多有人深层次地探究这个问题的技术细节,以数据来分析微信对网络的影响是否巨大,对网络的使用是否符合公平使用原则。

本文将从技术角度出发,跟踪微信的各类操做在IP层产生的数据包收发状况以及在无线侧产生的信令数据,并和语音、短信等传统业务引起的信令进行对比, 在技术层面客观分析微信对移动网络的影响。

一.微信IP层流量分析


微信属于C/S架构的软件系统,为分析微信的流量分布,须要对微信的通讯过程进行如下分析。

  • 通讯协议: 是使用TCP方式进行通讯,仍是使用UDP方式。
  • 链接方式: 若是使用TCP方式,是长链接仍是短连 接。
  • 心跳方式: 若是使用长链接,那么必然须要进行链接有效性检测,使用的心跳包的频次是多少。
  • 通知机制: 在微信切入后台后,服务器端以何种方式通知客 户端。
  • 版本差别: iOS版本和Android版本上的处理方式是否有所不一样。

本试验分别在使用iOS 6.x及Android 4.x系统的终端上进行,使用抓包软件对微信产生的IP流量进行抓取分析。

1微信的通讯过程


通过分析发现,微信的通讯协议采用基于TCP的 HTTP协议,在链接方式上采用长链接和短链接结合的 方式。

微信在登陆的时候,采用TCP短链接的方式进行认证。微信客户端首先发起一个TCP链接到鉴权服务器, 将加密后的用户名及密码用HTTP协议提交给服务器, 服务器返回加密后的认证结果,鉴权完毕后链接断开。一次鉴权过程的数据流量在1K字节左右。在鉴权成功后,微信会向业务服务器从新发起一个TCP链接,该链接会一直保持,并采用心跳包来定时检测链接的有效性(下文中将此链接称为业务链路),微信 客户端主动发送的消息经过此链接传输给服务器,服务器通知客户端的消息也经过此链接发送到客户端。

业务链路链接成功后,微信客户端首先经过此链接 查询是否有新的更新内容(包括新消息、新好友添加记录、新朋友圈信息等),以后进入主界面等待用户进行下一步操做。整个登陆过程以及更新操做产生的流量大约为3K字节。登陆后在微信客户端的各个页签之间切换不产生任何数据交互。

后续全部涉及到通讯的功能所有在业务链路上进行数据交互,如文字信息的收发、图片的收发、语音信息的收发等,下面对数据包跟踪记录进行简单的分析。

1) 收发文字。当接收一条文字微信时,会跟踪到4个数据包。

第一、2个数据包长度为116字节,分别表示对方正在输入和开始发送信息(第一个包在打字的时候产生, 第二个包在点击发送按钮以后产生),能够认为,传递 对方输入状态的数据包长度为116字节。

第3个数据包是发送的具体内容,通过分析发现, 数据包的内容是加密的,若是发送的是全英文字符, 10个字符之内所产生的流量包都是386字节,11~26个字符是402字节,27~42个字符是418字节,43~62个字符是434字节......;发送中文时,1~3个字是386字节, 4~7个字是402字节,8~11个字是418字节,12~15个字 是434字节......,大体状况是内容每增长4个字数据包就要增长16个字节。根据数据量的规律能够推断,微信采用了相似于DES或者AES这种以16字节为分组单位的对称加密算法。

最后,文字内容发送完毕以后还会产生一个66字节的数据包,标识着本条信息发送完毕。

2) 收发图片。当发送图片时,微信会默认只接收和显示图片的缩略图,传送缩略图产生的数据包大概3K字节左右。当用户点击查看大图以后才会下载完整的图片内容

3) 收发语音。收发语音信息和文字信息的数据包相似,测试发现,每秒语音大概对应0.9K字节数据,当一段语音的数据量比较大时,微信按照最长1.5K字节一个包进行分割发送,例如3秒语音将产生3K不到的数据,会分红2~3个1.5K字节数据包发送;7秒语音会产生6K字节左右数据,会分红4个1.5K字节数据包发送。和发送文字同样,每次发送完内容以后都还会产生的一个66字节的结束包。

微信在工做过程当中,除了业务连接的长链接会一直保持以便用于通讯功能外,还额外使用一些TCP短链接来进行临时性的操做,如好友搜索、头像下载、漂流瓶等。整体来看,在活动状态下(即用户打开微信的主界 面进行各类操做的状态),微信的数据包收发和其余的互联网应用没有多大区别。

2微信的心跳和通知机制


根据TCP协议的特征能够知道,在断开一个TCP链接时,须要进行四次握手,首先由主动断开的一方发送一个FIN消息给另外一方,另外一方回复ACK消息,而后由另外一方发起一样FIN/ACK交互流程后,整个链接断开。TCP链接在没有数据收发的状况下,不会有任何的数据 包交互,当链接异常断线时,只有主动发数据包的一方能够检测到链接断线,由于这时能够发现对端无应答; 等待接收的一方是没法检测到的,由于主机宕机、网线断开等异常状况将致使等待方永远不会接收到FIN信息。检测TCP长链接有效性的惟一方法是由一方定时发送一个数据包(俗趁心跳包),若是链接异常断线,发送方在发送的时候便可检测到,而另外一方则设置一个网络 空闲计时器,当超过约定时间未收到心跳包,则认为连 接已异常断开。

心跳周期(即网络空闲定时器的超时时间)过长,则服务器端要等比较长的时间才能检测到链接断线;心跳周期太短时虽然可以很快检测到链接断线,可是消耗在心跳包上的网络资源会过大。业界对微信的最大诟病正是在于微信在非活动状态下 的过于频繁的心跳机制。

因为操做系统的不一样特征,微信在iOS下以及Android操做系统下的心跳机制有着显著的区别。根据市场研究机构Strategy Analytics发布的数据代表,2012年第4季度, 在中国大陆市场出货的智能手机当中,98%采用Android和iOS两大操做平台。其中,Android智能手机占86%,iOS智能手机只占12%。这就意味着,要分析微信对网络的影响,主要分析微信在Android系 统上的工做特征便可。

通过分析发现,在iOS系统下微信对网络的影响并不大,微信在 刚开始运行或者刚从后台切换到前台时,都会以一个新的Session的方式从新发起登陆,登陆成功后再建立一个TCP长链接做为业务链 接,该链接以2分钟的频次发送长度为86字节的心跳包。当微信被切入后台后,因为iOS系统不容许程序在后台运行,业务连接断开, 微信转而采用iOS的PUSH机制来通知客户端有到达的信息。iOS的PUSH链接由操做系统维护,心跳周期为10分钟左右,整个系统的全部应用共用一个PUSH链接,因此在iOS系统下,微信的业务特征和大部分互联网应用区别不大。

而在Android系统下,微信的业务特征则有显著的区别,微信自从登陆成功后,建立的业务连接每隔2分钟即会向服务器发送一个82字节的心跳包。因为Android系统容许程序在后台运行,当微信被 切入后台后,微信的业务连接并无断开,将继续以此频次发送心跳包。也就是说,Android版本的微信只要运行并登陆成功后,将24小时不间断地发送心跳包,这样, 即便对微信不进行任何操做,微信 天天将发送24x30=720个数据包, 数据量为24x30x82=59K字节,按月计算折合每个月22 320个数据包或 1.83M字节数据。

二.微信信令流量分析


1微信的信令流量


经过在无线网管系统中挂表跟踪发现,微信每发送一个心跳包时在网络侧抓取的信令如图1所示。图中体现了微信一次心跳包引起的用于无线资源管理的信令流程,其中,从编号72197到72201的5条信令为RRC链接的创建信令。终端处于空闲模式时,当终端请求创建信令链接时,将发起RRC链接创建过程,其步骤以下[1]:

  • From-UE/ RRC_RRC_CONNECT_REQ, 终端发送RRC Connect Request 消息。
  • To-NodeB/NBAP_RL_ SETUP_REQ,SRNC进行资源分配后,向Node B发送Radio Link Setup Request消息,要求Node B分配RRC链接所需的无线链路 资源。
  • From-NodeB/NBAP_ RL_SETUP_RSP,Node B分配资源后,应答Radio Link Setup Response消息。
  • SRNC发起Iub 接口用户面传输承载的创建,并完成RNC与NodeB之间的同步。
  • To- UE/RRC_RRC_CONN_SETUP, SRNC向终端发送RRC Connection Setup消息。
  • From-UE / RRC_ RRC_CONNECT_SETUP_CMP, 终端回复RRC Connection Setup Complete消息。

图1 微信每次心跳包在无线侧产生的信令:
<ignore_js_op>微信对网络影响的技术试验及分析(论文全文)_QQ20160331-1.png 

后续的编号72203到72220的信令为IP数据包传输过程当中的信令,大部分是终端和核心网之间的直传消息。在此期间,心跳包的IP数据从终端经过无线网络传输到了 服务器。

须要重点关注的信令在于编号72221,发自终端的RRC_SIG_ CONNECT_REL_IND信令,该信令在IP包传送完毕7秒钟后出现, 表示终端主动要求释放信令链接。后续的8条信令是标准的RRC释放流程,表示无线资源被释放的过程。终端主动要求释放链接的缘由是当前大部分智能手机为了省电, 每次检测到网络空闲后,2~10秒 内会释放链接。

当2分钟后终端再次发送心跳包的时候,上述信令流程将重复一遍。这里须要注意的是,RRC连 接以及无线资源的释放,并不意味着TCP链接的断线,无线资源能够在TCP层须要收发数据包时才临时从新分配,虽然从新分配意味着上述RRC链接创建和释放的信令开销,可是对于无线网络来讲,无实际数据流量时继续占用无线资源的成本更加昂贵。

在当前的网络侧配置中,即便终端在2~10秒内不主动释放链接,网络侧也会在网络空闲15秒后释放无线资源。因此微信2分钟的心跳周期,每次心跳包必然会引起一次完整的无线资源申请和释放的信令开销,根据统计,每次流程中须要引起30多条信令,其中RNC需处理15条信令消息(图1中黑色字体而且不带DIRECT标识的部分,带 DIRECT标识表示直传消息,无需 RNC处理)。

2传统电信业务的信令流量


如今咱们来抓取一下传统的电信业务对应的信令流程,以便和微信引起的信令进行对比,发送一条短信的信令流程如图2所示,一次语音被叫的信令流程如图3所示。

图2 发送一条短信在无线侧产生的信令:
<ignore_js_op>微信对网络影响的技术试验及分析(论文全文)_QQ20160331-2.png 

能够看到,发送一条短信会引起30条信令,文中未列出接收一条短信的信令流程,实际测试发现接收短信和发送短信产生的信令数量相似。

图3 接收一次语音呼叫在无线侧产生的信令:
<ignore_js_op>微信对网络影响的技术试验及分析(论文全文)_QQ20160331-3.png 

在图3所示的一次语音被叫信令流程中,信令总数为40多条。其中编号92的RANAP_PAGING表示寻呼信令,编号93到97的信令为RRC链接的创建,编号118的信令为被叫振铃,编号120的信令为被叫摘机,编号122的信令为双方开始通话,编号124的信令为被叫挂机,编号132到编号135表示RRC 链接的释放。

一次语音主叫产生的信令和语音被叫相似。

三.总结


从以上的信令跟踪分析能够发现,微信一次心跳产生的信令,基本等同于发送或接收一条短信的信令,稍少于呼出或接听一个电话的信令。由第2节对微信IP层心跳数据包的分析可知,在一个月中,微 信用户即便不进行任何操做,也会发送22 320个心跳包,至关于消耗了发送22 320条短信的信令处理能力(或者拨打1万多个电话的信令处理能力),可是只产生1.83M字节 的流量。考虑到微信用户正常使用 的状况下,多少会进行一些其余操做,使其带来的实际流量消耗达到几十或者上百M字节,可是其对信令资源的巨大消耗是不争的事实, 因此中国移动声称的“微信占用了60%的信令资源,却只产生了10%的流量”是有事实依据的。

微信对信令资源的过多消耗, 的确会影响传统业务的质量。由于运营商的信道分为控制信道和业务信道,流量、语音这些数据走的是业务信道,信令等控制信号走的是 控制信道。每次发起通话、接收短信首先要发出控制信号也就是信令,而后才能有数据传输,因为协议和标准的限制,运营商在采购网络设备时,控制信道与业务信道的分配是成比例的。若是某个业务占用的业务信道和控制信道的比例严重不符,将致使控制信道阻塞,这时即便业务信道再通畅,电话也打不进去,数据也没法传输。

以一个普通用户每个月平均发送100条短信,打200个电话计算, 一个微信用户占用的控制信道资源至关于近100个用户使用传统电信业务的控制信道资源, 考虑到微信的高普及率,在忙时彻底可能致使控制信道拥塞,这在国际上也已经有过先例,2012年1月,日本最大的移动运营商NTTDOCOMO在东京地区的网络发生故障,有252万用户受到影响,过后调查发现,某款能够免费进行语音通讯的安卓应用,每隔3至5分钟便发送控制信令,正是这款应用致使了运营商信道堵塞。

因为无线网络的频带资源相比计算机网络的光纤传输带宽而言稀缺得多,无线信号所受到空中干扰大,信号随距离的衰减快,要达到一样的带宽及一样的覆盖范围,配置密集基站的成本远比建设光纤传输网要高得多,正是由于如此,移动通讯网络中才须要频繁地经过释放和从新申请无线资源来对宝贵的无线资源进行复用。微信用传统互联网的方法来设计移动互联网的应用,实际上是利用了当前运营商只对业务流量进行收费,并不对控制信令流量进行收费的计费体系缺陷, 有违网络公平使用原则。以银行的业务做为类比,本质上至关于每一个用户都到银行柜台存钱,可是每次只存1分钱,一天存下来银行的收益也远没法收回营业场因此及营业人员的成本支出,个别用户这样操做并无什么问题,可是不少用户由于某种能够带来额外收益的缘由,都到银行以这种方式存钱,那么结果必然是银行要么关闭营业网点,要么提升单次服务的门槛,不然这种模式确定难觉得继。

解决微信问题的方法,要么运营商经过其余业务的补贴,来消化网络扩容的成本;或者腾讯经过下降微信心跳机制的频次, 减小对移动网络信令资源的消耗。相信不久的未来,腾讯和运营商之间能够完美解决微信过多消耗信令资源的问题。

参考文献


[1] 华为公司-WCDMA系统基本原理:点击查看

本文做者


罗云彬1 黄文良1 王建海2 徐 青1
1 中国联通研究院 北京 100032
2 浙江联通杭州分公司 杭州 310003

论文下载


微信对网络影响的技术试验及分析 [附件下载]:点击进入

全站即时通信技术资料分类


[1] 网络编程基础资料:
TCP/IP详解 - 第11章·UDP:用户数据报协议
TCP/IP详解 - 第17章·TCP:传输控制协议
TCP/IP详解 - 第18章·TCP链接的创建与终止
TCP/IP详解 - 第21章·TCP的超时与重传
理论经典:TCP协议的3次握手与4次挥手过程详解
理论联系实际:Wireshark抓包分析TCP 3次握手、4次挥手过程
计算机网络通信协议关系图(中文珍藏版)
NAT详解:基本原理、穿越技术(P2P打洞)、端口老化等
UDP中一个包的大小最大能多大?
Java新一代网络编程模型AIO原理及Linux系统AIO介绍
NIO框架入门(三):iOS与MINA二、Netty4的跨平台UDP双向通讯实战
NIO框架入门(四):Android与MINA二、Netty4的跨平台UDP双向通讯实战
>> 更多同类文章 ……

[2] 有关IM/推送的通讯格式、协议的选择:
为何QQ用的是UDP协议而不是TCP协议?
移动端即时通信协议选择:UDP仍是TCP?
如何选择即时通信应用的数据传输格式
强列建议将Protobuf做为你的即时通信应用数据传输格式
移动端IM开发须要面对的技术问题(含通讯协议选择)
简述移动端IM开发的那些坑:架构设计、通讯协议和客户端
理论联系实际:一套典型的IM通讯协议设计详解
58到家实时消息系统的协议设计等技术实践分享
>> 更多同类文章 ……

[3] 有关IM/推送的心跳保活处理:
Android进程保活详解:一篇文章解决你的全部疑问
Android端消息推送总结:实现原理、心跳保活、遇到的问题等
为什么基于TCP协议的移动端IM仍然须要心跳保活机制?
微信团队原创分享:Android版微信后台保活实战分享(进程保活篇)
微信团队原创分享:Android版微信后台保活实战分享(网络保活篇)
移动端IM实践:实现Android版微信的智能心跳机制
移动端IM实践:WhatsApp、Line、微信的心跳策略分析
>> 更多同类文章 ……

[4] 有关WEB端即时通信开发:
新手入门贴:史上最全Web端即时通信技术原理详解
Web端即时通信技术盘点:短轮询、Comet、Websocket、SSE
SSE技术详解:一种全新的HTML5服务器推送事件技术
Comet技术详解:基于HTTP长链接的Web端实时通讯技术
WebSocket详解(一):初步认识WebSocket技术
socket.io实现消息推送的一点实践及思路
>> 更多同类文章 ……

[5] 有关IM架构设计:
浅谈IM系统的架构设计
简述移动端IM开发的那些坑:架构设计、通讯协议和客户端
一套原创分布式即时通信(IM)系统理论架构方案
从零到卓越:京东客服即时通信系统的技术架构演进历程
蘑菇街即时通信/IM服务器开发之架构选择
腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT
微信技术总监谈架构:微信之道——大道至简(演讲全文)
如何解读《微信技术总监谈架构:微信之道——大道至简》
快速裂变:见证微信强大后台架构从0到1的演进历程(一)
17年的实践:腾讯海量产品的技术方法论
>> 更多同类文章 ……

[6] 有关IM安全的文章:
即时通信安全篇(一):正确地理解和使用Android端加密算法
即时通信安全篇(二):探讨组合加密算法在IM中的应用
即时通信安全篇(三):经常使用加解密算法与通信安全讲解
即时通信安全篇(四):实例分析Android中密钥硬编码的风险
传输层安全协议SSL/TLS的Java平台实现简介和Demo演示
理论联系实际:一套典型的IM通讯协议设计详解(含安全层设计)
微信新一代通讯安全解决方案:基于TLS1.3的MMTLS详解
来自阿里OpenIM:打造安全可靠即时通信服务的技术实践分享
>> 更多同类文章 ……

[7] 有关实时音视频开发:
即时通信音视频开发(一):视频编解码之理论概述
即时通信音视频开发(二):视频编解码之数字视频介绍
即时通信音视频开发(三):视频编解码之编码基础
即时通信音视频开发(四):视频编解码之预测技术介绍
即时通信音视频开发(五):认识主流视频编码技术H.264
即时通信音视频开发(六):如何开始音频编解码技术的学习
即时通信音视频开发(七):音频基础及编码原理入门
即时通信音视频开发(八):常见的实时语音通信编码标准
即时通信音视频开发(九):实时语音通信的回音及回音消除概述
即时通信音视频开发(十):实时语音通信的回音消除技术详解
即时通信音视频开发(十一):实时语音通信丢包补偿技术详解
即时通信音视频开发(十二):多人实时音视频聊天架构探讨
即时通信音视频开发(十三):实时视频编码H.264的特色与优点
即时通信音视频开发(十四):实时音视频数据传输协议介绍
即时通信音视频开发(十五):聊聊P2P与实时音视频的应用状况
即时通信音视频开发(十六):移动端实时音视频开发的几个建议
即时通信音视频开发(十七):视频编码H.26四、V8的前世此生
简述开源实时音视频技术WebRTC的优缺点
良心分享:WebRTC 零基础开发者教程(中文)
>> 更多同类文章 ……

[8] IM开发综合文章:
移动端IM开发须要面对的技术问题
开发IM是本身设计协议用字节流好仍是字符流好?
请问有人知道语音留言聊天的主流实现方式吗?
IM系统中如何保证消息的可靠投递(即QoS机制)
谈谈移动端 IM 开发中登陆请求的优化
彻底自已开发的IM该如何设计“失败重试”机制?
微信对网络影响的技术试验及分析(论文全文)
即时通信系统的原理、技术和应用(技术论文)
开源IM工程“蘑菇街TeamTalk”的现状:一场虎头蛇尾的开源秀
>> 更多同类文章 …… 

[9] 开源移动端IM技术框架资料:
开源移动端IM技术框架MobileIMSDK:快速入门
开源移动端IM技术框架MobileIMSDK:常见问题解答
开源移动端IM技术框架MobileIMSDK:压力测试报告
开源移动端IM技术框架MobileIMSDK:Android版Demo使用帮助
开源移动端IM技术框架MobileIMSDK:Java版Demo使用帮助
开源移动端IM技术框架MobileIMSDK:iOS版Demo使用帮助
开源移动端IM技术框架MobileIMSDK:Android客户端开发指南
开源移动端IM技术框架MobileIMSDK:Java客户端开发指南
开源移动端IM技术框架MobileIMSDK:iOS客户端开发指南
开源移动端IM技术框架MobileIMSDK:Server端开发指南
>> 更多同类文章 ……

[10] 有关推送技术的文章:
iOS的推送服务APNs详解:设计思路、技术原理及缺陷等
Android端消息推送总结:实现原理、心跳保活、遇到的问题等
扫盲贴:认识MQTT通讯协议
一个基于MQTT通讯协议的完整Android推送Demo
求教android消息推送:GCM、XMPP、MQTT三种方案的优劣
移动端实时消息推送技术浅析
扫盲贴:浅谈iOS和Android后台实时消息推送的原理和区别
绝对干货:基于Netty实现海量接入的推送服务技术要点
移动端IM实践:谷歌消息推送服务(GCM)研究(来自微信)
为什么微信、QQ这样的IM工具不使用GCM服务推送消息?
>> 更多同类文章 ……

[11] 更多即时通信技术好文分类:
http://www.52im.net/forum.php?mod=collection&op=all

即时通信网 - 即时通信开发者社区! 来源:即时通信网 - 即时通信开发者社区!php

 

转载:http://www.52im.net/?1html

相关文章
相关标签/搜索