流水不争先,争的是滔滔不绝

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

微信QQ 云聊IM 1163℃

本文来自论文《微信对网络影响的技术试验及分析》,文中研究了微信对现今移动网络的影响,对于即时通讯开发人员来说,文中的某些数据和研究结果,对于实现类似的技术,有一定的参考和借鉴意义。

摘要

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

引言

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

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

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

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

一.微信IP层流量分析

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

  1. 通信协议: 是使用TCP方式进行通信,还是使用UDP方式。
  2. 连接方式: 如果使用TCP方式,是长连接还是短连 接。
  3. 心跳方式: 如果使用长连接,那么必然需要进行连接有效性检测,使用的心跳包的频次是多少。
  4. 通知机制: 在微信切入后台后,服务器端以何种方式通知客 户端。
  5. 版本差异: iOS版本和Android版本上的处理方式是否有所不同。

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

1、微信的通信过程

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

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

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

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

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

第1、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小时不间断地发送心跳包,这样, 即使对微信不进行任何操作,微信 每天将发送24×30=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 微信每次心跳包在无线侧产生的信令:

后续的编号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 发送一条短信在无线侧产生的信令:

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

图3 接收一次语音呼叫在无线侧产生的信令:

在图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分钱,一天存下来银行的收益也远无法收回营业场所以及营业人员的成本支出,个别用户这样操作并没有什么问题,但是很多用户因为某种可以带来额外收益的原因,都到银行以这种方式存钱,那么结果必然是银行要么关闭营业网点,要么提高单次服务的门槛,否则这种模式肯定难以为继。

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

版权声明:部分文章、图片等内容为用户发布或互联网整理而来,仅供学习参考。如有侵犯您的版权,请联系我们,将立刻删除。
点击这里给我发消息