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

JackJiang · 8 年前

前言

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

关于移动端网络的优化手段总结性文章可参见《现代移动端网络短连接的优化手段总结：请求速度、弱网适应、安全保障》、《移动端IM开发者必读(一)：通俗易懂，理解移动网络的“弱”和“慢”》、《移动端IM开发者必读(二)：史上最全移动弱网络优化方法总结》。

摘要

针对业界对微信是否影响移动网络性能的争论,进行相关的技术试验,跟踪微信在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个数据包。

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

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

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

参考文献

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

本文作者

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

论文下载

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

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

附录：有关QQ、微信的文章汇总

[1] 有关QQ、微信的技术文章：
《微信后台团队：微信后台异步消息队列的优化升级实践分享》
《微信团队原创分享：微信客户端SQLite数据库损坏修复实践》
《腾讯原创分享(一)：如何大幅提升移动网络下手机QQ的图片传输速度和成功率》
《腾讯原创分享(二)：如何大幅压缩移动网络下APP的流量消耗（下篇）》
《腾讯原创分享(二)：如何大幅压缩移动网络下APP的流量消耗（上篇）》
《微信Mars：微信内部正在使用的网络层封装库，即将开源》
《如约而至：微信自用的移动端IM网络层跨平台组件库Mars已正式开源》
《开源libco库：单机千万连接、支撑微信8亿用户的后台框架基石 [源码下载]》
《微信新一代通信安全解决方案：基于TLS1.3的MMTLS详解》
《微信团队原创分享：Android版微信后台保活实战分享(进程保活篇)》
《微信团队原创分享：Android版微信后台保活实战分享(网络保活篇)》
《Android版微信从300KB到30MB的技术演进(PPT讲稿) [附件下载]》
《微信团队原创分享：Android版微信从300KB到30MB的技术演进》
《微信技术总监谈架构：微信之道——大道至简(演讲全文)》
《微信技术总监谈架构：微信之道——大道至简(PPT讲稿) [附件下载]》
《如何解读《微信技术总监谈架构：微信之道——大道至简》》
《微信海量用户背后的后台系统存储架构(视频+PPT) [附件下载]》
《微信异步化改造实践：8亿月活、单机千万连接背后的后台解决方案》
《微信朋友圈海量技术之道PPT [附件下载]》
《微信对网络影响的技术试验及分析（论文全文）》
《一份微信后台技术架构的总结性笔记》
《架构之道：3个程序员成就微信朋友圈日均10亿发布量[有视频]》
《快速裂变：见证微信强大后台架构从0到1的演进历程（一）》
《快速裂变：见证微信强大后台架构从0到1的演进历程（二）》
《微信团队原创分享：Android内存泄漏监控和优化技巧总结》
《全面总结iOS版微信升级iOS9遇到的各种“坑”》
《微信团队原创资源混淆工具：让你的APK立减1M》
《微信团队原创Android资源混淆工具：AndResGuard [有源码]》
《Android版微信安装包“减肥”实战记录》
《iOS版微信安装包“减肥”实战记录》
《移动端IM实践：iOS版微信界面卡顿监测方案》
《微信“红包照片”背后的技术难题》
《移动端IM实践：iOS版微信小视频功能技术方案实录》
《移动端IM实践：Android版微信如何大幅提升交互性能（一）》
《移动端IM实践：Android版微信如何大幅提升交互性能（二）》
《移动端IM实践：实现Android版微信的智能心跳机制》
《移动端IM实践：WhatsApp、Line、微信的心跳策略分析》
《移动端IM实践：谷歌消息推送服务(GCM)研究（来自微信）》
《移动端IM实践：iOS版微信的多设备字体适配方案探讨》
>> 更多同类文章 ……

[2] 有关QQ、微信的技术故事：
《技术往事：创业初期的腾讯——16年前的冬天，谁动了马化腾的代码》
《技术往事：史上最全QQ图标变迁过程，追寻IM巨人的演进历史》
《开发往事：深度讲述2010到2015，微信一路风雨的背后》
《开发往事：微信千年不变的那张闪屏图片的由来》
《开发往事：记录微信3.0版背后的故事（距微信1.0发布9个月时）》
《一个微信实习生自述：我眼中的微信开发团队》
>> 更多同类文章 ……

2 楼: JackJiang · 8 年前

这篇文章利用浅显易懂的语言，将本身晦涩的电信用语和技术原理很好的阐述了出来，值得即时通讯开发人员一看哦。

目前市面上的绝大多数即时通讯应用可能都不需要像微信一样产生这种苦恼（因为用户规模远比不上微信），但文章中以实测数据的方式描述的微信某些技术原理还是可以借鉴的。

3 楼: 你好二哥 · 8 年前

这文章里说的tcp短连接，就是指的http服务吧！说的挺诡异的

4 楼: 花子x · 8 年前

语音留言这样的数据，是通过即时通讯通道，像pc上的im一样实时传输的？对于移动端的im来说，这不科学吧！

5 楼: 不要·不要 · 8 年前

引用：花子x 发表于 2016-04-01 11:29
语音留言这样的数据，是通过即时通讯通道，像pc上的im一样实时传输的？对于移动端的im来说，这不科学吧！

我也觉得挺奇怪的。

不过对于微信来说，很多技术都是自已弄的。比如这个文章里：http://www.52im.net/thread-177-1-1.html 好像有提到微信自已实现过仿tcp的可靠实时数据传输技术，据说传输速度可以秒传百兆。

还有jack另一个帖子里提到的微信图片和qq的语音，明明都只是在接收方读消息里才下载的，看那个下载进度条就知道：http://www.52im.net/thread-175-1-1.html

6 楼: 李坤 · 7 年前

mark

7 楼: ashura12342000 · 7 年前

楼主非常棒，学习了，膜拜一下

8 楼: TeochewZhang · 7 年前

Mark. Thx.

9 楼: ipray · 6 年前

分析的不错，学习了

10 楼: linee · 6 年前

很好很强大

11 楼: 妮子 · 4 年前

楼主威武，感谢

12 楼: mark_lin · 4 年前

之前有文章写过TCP方式在移动弱网下的问题，也提到TX基本UDP协议创建了类TCP机制的协议，但这边文章的实际分析却又发现TX用了tcp长链接的业务链路，非常疑惑。。。。。。怎么可以抓到微信手机端发出的报文？

13 楼: 夏日里的春天 · 4 年前

哈哈哈哈哈好

14 楼: fqeeeebrje · 5 个月前

楼主写得真好，让我学到了！

本文目录

前言

摘要

引言