关于微信技术的论文 微信对网络影响的技术试验及分析
下面是好好范文网小编收集整理的关于微信技术的论文 微信对网络影响的技术试验及分析，仅供参考，欢迎大家阅读！
前言
摘要
针对业界对微信是否影响移动网络性能的争论,进行相关的技术试验,跟踪微信在IP层以及在无线网络信令层的流量,以实际数据分析微信对移动网络的影响,并提出解决微信问题的建议方法。
引言
2013年2月底,一则关于电信运营商要向微信收费的传闻引发了行业震荡,据2013年3月31日财新网报道,工业和信息化部(下文称工信部)部长苗圩当日在参加第二届“岭南论坛”时表示,微信有收费可能,但不会大幅度收费,工信部正在协调运营商微信收费一事, 他们会考虑运营商的合理要求。
在此之后的几个月中,争论并未停止,腾讯一直通过微信官方微博等各种途径表示微信不会收费,并且腾讯将和运营商探讨互惠互利的长远合作;工信部则声明互联网和移动互联网等新业务是否收费由市场决定, 工信部将坚持“其经营者依据市场情况自主决定”的原则;中国计算机学会等社会团体则认为运营商在未经有关法律程序的情况下试图增加收费名目是没有依据的, 涉嫌双重收费。
在争论中,运营商以及通信行业的专家认为微信过于频繁的心跳和短包导致“信令风暴”,因为据数据显示,微信占据中国移动60%的信令,却只产生10%的流量,已经影响到传统业务的质量;而互联网人士则站在用户与道德的制高点上提出异议,认为微信是合理使用运营商的业务规则。但是很少有人深层次地探究这个问题的技术细节,以数据来分析微信对网络的影响是否巨大,对网络的使用是否符合公平使用原则。
本文将从技术角度出发,跟踪微信的各种操作在IP层产生的数据包收发情况以及在无线侧产生的信令数据,并和语音、短信等传统业务引发的信令进行对比, 在技术层面客观分析微信对移动网络的影响。
一．微信IP层流量分析
通信协议: 是使用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字节的数据包,标识着本条信息发送完毕。
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>
后续的编号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>
可以看到,发送一条短信会引发30条信令,文中未列出接收一条短信的信令流程,实际测试发现接收短信和发送短信产生的信令数量类似。
图3 接收一次语音呼叫在无线侧产生的信令：
<ignore_js_op>
在图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 黄文良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与的跨平台UDP双向通信实战》
《NIO框架入门(四)：Android与的跨平台UDP双向通信实战》
[2] 有关IM/推送的通信格式、协议的选择：
《为什么QQ用的是UDP协议而不是TCP协议？》
《移动端即时通讯协议选择：UDP还是TCP？》
《如何选择即时通讯应用的数据传输格式》
《强列建议将Protobuf作为你的即时通讯应用数据传输格式》
《移动端IM开发需要面对的技术问题（含通信协议选择）》
《简述移动端IM开发的那些坑：架构设计、通信协议和客户端》
《理论联系实际：一套典型的IM通信协议设计详解》
《58到家实时消息系统的协议设计等技术实践分享》
[3] 有关IM/推送的心跳保活处理：
《Android进程保活详解：一篇文章解决你的所有疑问》
《为何基于TCP协议的移动端IM仍然需要心跳保活机制？》
《移动端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.264、V8的前世今生》
《简述开源实时音视频技术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详解：设计思路、技术原理及缺陷等》
《扫盲贴：认识MQTT通信协议》
《一个基于MQTT通信协议的完整Android推送Demo》
《求教android消息推送：GCM、XMPP、MQTT三种方案的优劣》
《移动端实时消息推送技术浅析》
《扫盲贴：浅谈iOS和Android后台实时消息推送的原理和区别》
《绝对干货：基于Netty实现海量接入的推送服务技术要点》
《移动端IM实践：谷歌消息推送服务(GCM)研究（来自微信）》
《为何微信、QQ这样的IM工具不使用GCM服务推送消息？》
[11] 更多即时通讯技术好文分类：
