8月 252013
 

本月 11 号到 14 号,因为参加学术会议的缘故,去了一趟深圳和香港。日程很紧,时间有限,不过我还是挤出来些时间感受下当地的景致。学术方面的会议总结已经在实验室里做了交流,这里的看官一般也不会感兴趣,因此本文就只描述会议之余的行程。

我是 11 号周日上午从学校出发坐地铁换机场快线去的首都国际机场,在机场快线上时只见窗外大雾弥漫,只觉是要延误。到了机场登机口时,外面就雷声轰鸣,不一会儿就大雨倾注,延误无误了。最后,九点半的飞机,十点多登机,下午一点时分才起飞。起飞时外面还是有雾,不过已大大好过之前。

IMG_2614

第一次坐飞机,起飞时拉起升空的感觉很棒。遇到颠簸时下坠又有些心虚。由于是第一次且是白天,所以选了靠窗的位置,以便拍照。在空中飞行时窗外的蓝天和云海是非常漂亮的。

IMG_2631 IMG_2636

近三个小时的飞行后,飞机降落在深圳宝安机场。在跑道上滑行时深圳突然又下起了不小的阵雨。

IMG_2639

由于当晚要住香港,所以下飞机后乘 330 路直奔罗湖口岸,在进港的关口排起了长队,队里等待时间大概有半个小时。之后乘地铁东港线去大学站。不禁为港中文有如此霸气的站名感叹。香港地铁不挤,但票价贵,和北京正相反。在那边一个大学同学的热情帮助下,吃了晚饭,摸到了晚上住宿的地点。晚上是住在港中文的国际生舍堂三座,是三人间,感觉比在自己学校住的都宽敞(也许是房间比较空产生的错觉),后来发现另外两人是来自华为的参会者。住的地方是在山上(学校其实就是依山建的),可谓海景房,能看到两侧高楼林立的沙田海夜景。值得一提的是,港中文有许多电梯,方便学生爬山,不是同学指路我是断然想不到的。另外还有免费的校车,只是假期车次较少。另外,在住的地方第一次见到并用了会掉冰块的饮水机,显然是后知后觉会用的。

第二天白天是会议时间,午饭是在晨兴书院的餐厅。饭后有一小段时间到餐厅外侧看了看风景,不由的打开相机按下了许多次。

IMG_2698

下午茶歇时顺便逛了会议地点(康本国际学术园)一楼的书店,买到了朋友托付要买的书。会后要办香港住处的 check out,而已经过了他们的工作时间。后来得到了一位同学的积极帮助,等待了一段时间后顺利地 check out。等待期间是在学校外面附近的凯悦酒店,回头拍了几下港中文。其实我只走过了港中文的一个角落,里面的校区都没有工夫转。

IMG_2788

之后,素未谋面的 fqj 童鞋帮我解决了晚饭,此时已经是晚上八点多钟。一番思虑之后,我决定冒着回深圳后赶不上地铁的风险,去尖沙咀维多利亚港看一看。fqj 表示也没看过维多利亚港夜景,愿意同行。于是我们倒地铁到了尖沙咀,出来后因为不知道路又找了一会儿,终于找到了海边,到了星光大道。海边风大,颇为凉爽。游客也不少。

IMG_2794 IMG_2800

从海边返回已经是十点多钟,待我到罗湖深圳一侧,恰为 11 点,地铁末班已经赶不上了。于是排队等出租车。到了住的地方,却被告知查不到预约信息。折腾一番,零点半方真正入住。我住的地方离深圳的华强北很近,也算是深圳的一个知名地段。

IMG_2900 IMG_2906

周二周三白天都是会议。周三晚上我就得回北京,所以尽管周二晚上是阵雨天气,我还是去了一趟东门老街。这里其实就是商业街、步行街、加小吃街,但是建筑可以看到是旧时的楼宇。另外当天晚上是七夕,街上有不少卖花的。

IMG_2916

周三香港是八级风球预警,上午那边会议的日程都取消了。这让我一度认为当晚在深圳恐怕走不了了。然而深圳一直是台风黄色预警没有升级,下午等到了是航班晚点而非取消的消息。本来是 19:15 的飞机,晚点通知是改为 20:25,最终是九点多一些起飞,零点到的北京。之后坐机场大巴和出租车回到了宿舍,结束了四天匆匆的行程。

时间虽紧,但也算逛了一逛。在我待的几天里,香港天气很好,风景很赞,大学里的人们都很帮忙,说普通话也没问题;深圳雨水有点多,但空气质量优良。总体印象很好,唯愿今后能有机会去更多地了解。

8月 222013
 

NOTE: For Chinese version, please refer to this post.

Last Saturday (Aug 17), the Fedora 19 Release Party in Beijing, China was successfully held by the joint organization of Fedora Chinese User Group (FZUG) and ChinaUnix community (CU), with the help of Beijing GNOME User Group (BJGUG). The weather was nice that day, and more than 40 people attended the activity.

The release party was scheduled to begin at 14:30 (UTC+8, local time). A few early birds came just after 13:00. Once the attendees registered, they can pick a Live CD among GNOME 32bit, GNOME 32bit, and KDE 64bit ones. The total number of prepared CDs is 50.

After the short welcome by Alick Zhao from FZUG and Rongmao Zhou from CU, the release party entered the first talk. It was “Openshift and Cloud” by Gerard Braad, who is a long term active Fedora ambassador, regional mentor for APAC, member of FZUG. He explained different projects (OpenStack and Openshift), different levels of virtualization (full virtualization, para-virtualization, and OS-level virtualization), and XaaS (IaaS, PaaS, and SaaS).

Openshift and Cloud by Gerard

Openshift and Cloud by Gerard

Following was the talk “SystemTap Introduction” by Robin Lee, who is an active Fedora packager and skilled programmer. The talk covered some basic and advanced stuff, and was interleaved with quite a lot of examples and demonstrations.

SystemTap Introduction by Robin Lee

SystemTap Introduction by Robin Lee

Then after a short break Tong Hui, an open source evangelist, gave the speech “3D Printing at Fedora 19”. He introduced history of 3D Printing, open source 3D printing, 3D printing at Fedora 19, and so on. He highlighted that Fedora 19 is the first OS, not just the first Linux distribution, to fully support 3D printing. He also gave some outlook for 3D printing in the future.

3D Printing by Tong Hui

3D Printing by Tong Hui

We had Q&A between speakers and the audience, and distributed several T-shirts and books as gifts. Then we shared the Fedora cake to celebrate Fedora 19 release. At last we took group photos.

Group photo

Group photo

The slides links of above talks will be available on the wiki page. The photos of the event can be found on G+. Don’t forget to take the post-event survey! We need your feedback!

8月 222013
 

上周六(8 月 17 日)北京天气晴好,由 Fedora 中文用户组与 ChinaUnix 社区联合举办,并由北京 GNOME 用户组协办的 Fedora 19 发行派对北京站活动成功举行。活动有超过 40 人参加。活动正式开始时间是下午两点半,一些听众刚过一点就早早地来到了会场。会场门口设有注册环节,注册后每人可以领取一张 Live 光盘和一枚贴纸。光盘准备了 50 张,有 GNOME 32 位、GNOME 64 位以及 KDE 64 位可供选择。

开场时有 Fedora 中文用户组的赵涛和 ChinaUnix 的周荣茂分别致辞。之后便开始了第一个主题演讲。演讲由吉拉德带来,题为“Openshift 与云”。吉拉德是 Fedora 中文社区的成员,是 Fedora 项目长期活跃的贡献者,Fedora 大使,并且是亚太地区的大使导师。他在演讲中介绍了诸如 OpenStack、Openshift 等开源项目的异同,不同层次的虚拟化技术(全虚拟化、半虚拟化以及操作系统级虚拟化),还有各种云计算服务模式(架构即服务、平台即服务、软件即服务)的内涵。

吉拉德介绍 Openshift 与云

吉拉德介绍 Openshift 与云

紧接着是活跃的 Fedora 打包人员、程序员李瑞彬带来的“SystemTap 简介”。他的演讲由浅入深,介绍了 SystemTap 这一系统跟踪工具的基本特点、简单应用、强大之处等,并给出了综合应用,讲解过程中穿插了许多示例与现场演示。

李瑞彬介绍 SystemTap

李瑞彬介绍 SystemTap

短暂的中间休息后,来自 DFRobot 的开源布道师佟辉做了题为“用 Fedora 19 玩转 3D 打印”的演讲。他介绍了 3D 打印的历史,开源的 3D 打印解决方案以及在 Fedora 19 中的支持情况。他着重指出了 Fedora 19 是第一款完全支持 3D 打印的操作系统。此外他还对 3D 打印的未来发展做了展望。

佟辉介绍 3D 打印

佟辉介绍 3D 打印

我们事先准备了若干 T 恤衫和 Linux 图书,在问答互动环节作为奖励进行了分发。之后我们分享了定做的 Fedora 蛋糕。最后大家合影留念。

集体合影

集体合影

活动演讲的讲稿链接会放在维基页面上。活动照片可以在 G+ 上看到。最后,参加了活动的朋友别忘了填下调查问卷!我们非常希望得到您的反馈!

8月 192013
 

写在前面

这是这学期的一个课程论文,原文由 LaTeX 写成,这里用 pandoc 转换成 Markdown,再转换为 HTML。做了一些必要的格式修正(参考文献引用、siunitx 宏包命令、图片),以及错别字的勘误。内容上没有删减更改,因此有如下问题:

  1. 文章写于今年 6 月份下旬,文章中的“今天”“迄今为止”都是那个时间点。有些信息可能已经过时。
  2. 可以看到引用文献多为互联网上新闻报道等链接,可靠性可能偏低。
  3. 数值分析可以发现是很粗糙的,完全可能有谬以千里的结果。

不过,课程已经结束,希望贴出来对更多人有所帮助。

序言

微信是当下十分流行的一个移动互联网应用。日前运营商对信令风暴和微信收费的讨论使其受到更多的关注。本文从学术研究角度,分析微信的技术原理、发展前景、技术挑战,并提出相应对策。

微信原理

微信APP/服务器

微信是一款类 Kik 的移动互联网应用。它支持文字与图片分享、文字聊天、语音对讲、视频聊天、广播消息、基于位置的社交(如“摇一摇”等)等功能,是通信软件和社交网络的混合产品 1

微信的语音对讲功能利用了压缩编码技术,降低数据速率,减小对流量的需求。目前微信语音产生的流量为 0.9–1.2 K/秒 2。基于地理位置信息的社交功能需要手机支持 GPS 定位和/或 WiFi 定位,“摇一摇”还利用到了手机的重力感应功能,这些特性在目前的主流出厂手机上都有支持。微信 FAQ 表示其在后台运行时只需要极少流量,这得益于其精心设计的通信协议。

微信的架构秉承“重后台轻客户端”的设计理念 3。这使得客户端的逻辑得到简化,帮助微信团队在发布后很短时间内就支持了 Apple iOS、Android、Symbian 三大移动操作系统。1 另一方面,服务器端的更新不需要用户参与,可以快速变更,使开发部署更加敏捷高效。 下图给出了微信的前后端架构框图。微信的服务器端采用分离部署的服务器集群,提供接入、推送、业务逻辑、存储等支持。在通信协议方面,微信的没有采用业界常见的 XMPP 或 SIP 协议,而是参考 ActiveSync 实现了名为 SYNC 的协议。虽然实现更为复杂,但对用户来讲使用流量更少、且可以保证消息的可靠传输和有序到达 4

weixin architecture

网络环境(3G、WLAN、IPv4和NAT)

微信面临的网络环境是复杂多样的。实际运行的蜂窝网络是不同运营商、多种制式网络的混合。与有线网相比,移动网络支持的数据传输速率较低,网络较不可靠。用户的移动性又使得所处的网络可能随时变化。 近年来 WiFi 日益流行,目前主流手机及平板设备均支持 WLAN 接入。这进一步使得无线网络多样化和复杂化。

尽管协议细节不同,各种制式的蜂窝网络都有移动回传网络最终通过网关与互联网联通。而 WiFi 一般都直接接入互联网。因此, 作为一款移动互联网应用,微信在 GPRS/EDGE/3G/WiFi 等诸多网络模式下工作在技术上是没有问题的。但在现网中仍存在诸多挑战。一是数据传输速率有限,例如 GPRS 制式下典型速率约为 ,在传递语音、图片、视频前必须进行高效的压缩。另外,用户的网络有无、蜂窝网络接入或WLAN 接入会频繁地变动,而微信需要维护总是在线的状态,频繁的心跳信息会加重信令负担。 蜂窝网和 WLAN 普遍给终端分配 NAT 背后的内网地址,微信需要解决 NAT 穿透的问题。此外值得一提的是,中国移动人为地将 GPRS 接入点区分为 CMWAP 和 CMNET 两个 5。只有基于 HTTP 协议或 支持 WAP 网关协议的应用才可以在 CMWAP 中工作。 微信在 Android 等平台上支持 CMWAP 网络,但 iPhone 版尚无法在 CMWAP 接入点下使用 6

信令风暴分析

信令风暴指的是终端用户进行过多的信令请求,导致网络信令资源紧张,甚至引起雪崩效应。随着移动互联网的迅速发展,要求长时在线的应用越来越多越来越流行。为了保持在线状态,心跳信息被广泛利用。心跳信息一般只是用于保活,不承载用户数据,但频繁的心跳会使得连接被频繁的建立和拆除,消耗大量的信令资源。

中国移动指责“微信给中国移动带来了约10%的流量收入,但占用了60%信令资源” 7,微信团队在微博上回应称问题本质上是传统的 2G 网络无法支持长期联网的移动互联网应用,升级网络是根本之道,但微信也表示会和运营商一同探讨 2.5G 网络下信令优化方案 8

微信团队的回应从技术层面上讲是合理的,但其认为网络升级就能解决问题有待商榷。GPRS 作为 2.5G 技术,是在仅支持传统话音业务的 2G GSM 网络中增加数据服务设备(SGSN、GGSN 等),在空中接口使用空闲的频率时隙资源,所能提供的数据服务速率相当有限,其信令资源也比较有限。对于蜂窝网络来说,移动回传网的设备升级相对容易、设备性能更高,故资源的瓶颈一般在无线接入网即空中接口。微信等长时在线的应用对信令的需求较高,容易给 GPRS 网络带来负担。中国移动仍有大量 2.5G 用户,迁移到 TD 3G 的比例还较低,所以中国移动受到的影响最大,反应也最激烈。但另一方面,我们要对认为网络升级就能使问题迎刃而解的态度持审慎态度。诚然网络升级可以有效提高系统容量,提升网络对数据业务特别是信令资源的支持能力。但应该看到应用的发展十分迅猛,显著快于网络升级的速度。日益增多日益流行的长时在线应用仍然会对未来网络带来不小的挑战。

在网络对信令风暴的讨论中,有人指出这一问题并非只是技术问题,而是经济问题 9。在信令风暴讨论的同时,对微信收费的讨论也在进行。从经济利益的角度出发,运营商希望能够向微信等 OTT 业务收费,而不仅仅作为管道。诚然运营商已经对数据流量进行了收费,但相比传统的语音通话、短信业务而言,数据流量的每比特收益是很低的。 OTT 对运营商的冲击不是一个新鲜事物,微信只是作为一个新兴的流行移动互联网应用成了争论的引爆点。

微信的应用场景

目前微信已经是一个兼有通信与社交功能的产品。其文字聊天、语音对讲、视频 聊天功能可以在一定人群中在一定程度上取代运营商提供的传统语音通话、短信 功能,而且支持多人群聊与视频会议。 免费特性是一大吸引力。在社交方面,它既有朋友圈供熟人间做私密的 交流,又有基于地理位置的陌生人社交功能。 此外,微信也在发展其公众平台,有望演化为品牌宣传、客户服务的平台。 最近,微信推出了语音提醒特性,可以用语音识别技术提供生活提醒的功能。

微信的经济模型

目前腾讯表示微信完全免费,使用任何功能微信都不会收费 6。在使用微信的过程中,用户需要向运营商支付一定的数据流量费用。从长远来看,微信必须向腾讯提供经济收益,运营商也希望提高数据业务的收益,因此微信的经济模型在今后必然会发生改变。

发展分析

网络环境(4G、5G、IPv6、未来互联网)

新一代的蜂窝网络需要满足日益增长的数据服务需求。4G 标准要求支持峰值、高速移动场景下的速率要求, LTE-A 通过移动回传网的简化和全 IP 化更好地支持互联网业务。 目前 4G 已经在国内部分城市开始试运行。业界对于 5G 尚无统一的认识,但进一步提升容量很有可能是必须要求之一。未来的蜂窝网络会对微信等长时在线应用提供更好的支持,有望缓解甚至解决信令风暴的问题。不过,网络的演讲是一个逐渐过渡的过程,在过渡过程中新网络和现有网络会并存,这可能使得微信面临的网络环境更加复杂和多样。

从互联网的角度看,IPv6 作为下一代互联网的关键技术,有望解决 IPv4 地址枯竭的问题,而且通过摒弃 NAT 恢复端到端的联通性,可以化解 NAT 穿透的难题。未来互联网有望对用户移动性、终端在线状态提供更好的感知和支持,使得微信可以无需心跳信令确认用户状态。另外,假如网络可以无所不在,提供任意时刻的连通性,那么用户都将一直在线,检测在线的逻辑就可以省去了。2

未来应用

微信已经拥有比较完善的通信功能。可能是为了避免和运营商直接竞争,微信目前不支持直接进行实时的语音通话。未来这是有可能出现的。另外,与非微信用户包括移动电话用户通话(类似 Skype),也可能会实现。这方面的阻力更多来自于政策而非技术。

社交方面,位置信息会提供很多新的应用场景。朋友聚会、线下活动、签名点到都可以在微信平台下得到支持。通过与传统行业结合,有望催生更多的应用场景,例如公交位置查询、打出租车等。

微信的公众平台可以承载许多的在线业务,包括媒体宣传、商户推广、移动支付等。有报道称微信有望于 7 月上线支付业务 10

经济模型

展望微信未来的经济模型,有如下几种。

一是广告投放与品牌推广。广告是互联网企业的主要收入来源之一。在应用中投放广告也是一种常规的营收手段。微信还可以借鉴新浪微博在信息流中投放广告的做法。

二是建立会员等级体系,对高级会员进行收费并提供增值服 务。QQ 是一个典型的例子,此方法也已被人人网、新浪微博等采用。和非微信用户通话的服务就可能作为付费服务提供。

三是游戏。现有的网络游戏可以提供很好的借鉴。通过向游戏玩家销售装备,可以获得可观的收益。

此外,微信可以利用现有的公众平台和对开发者的开放平台,发展第三方应用。作为应用平台,从付费应用中提成来营利。移动支付也可以为微信打开盈利渠道。

数值分析

目前微信用户数、潜在用户数

微信自 2011 年 1 月 21日发布以后,在 433 天后用户数突破 1 亿, 2012年9月17日超过 2 亿。2013年1月15日,微信用户数突破3亿。 1, 11 根据现有数据可以得到如下图的用户数变化曲线。可以看到微信用户数从发布到 2013 年 1月 一直在增长,且增长速度也在加快。根据这个趋势,微信可以在2013年6月底达到 4亿用户数,但目前并没有相关消息。这暗示微信用户数在 2013 年的增长速度已经放慢。

微信用户数变化

国内智能手机用户数在 2013 年第一季度已达 4.2 亿,仍处于增长阶段 12。新媒体蓝皮书预测 2013 年网民总数将超过 6亿 13,电子商务蓝皮书预计微信在 2013 年活跃用户数将超 3.8亿 14。 有研究机构预测到 2017 年全球使用 OTT 移动 VoIP 通话服务的用户将突破 10 亿 15。根据现有的市场份额估算,届时微信用户数可达 5 亿。

值得注意的是,微信 2.0 版本添加语音对讲功能,以及 2.5 版本支持附近的人即基于位置的陌生人社交功能后的一段时期内,用户数显著增加 16。由此可见引爆点对用户增长的重要性。未来用户数也会与新的引爆点直接有关。

使用带宽、信令风暴、网络地址

首先考虑微信服务器所用带宽。目前中国 IDC 带宽租赁费平均约为 10万/GB/月。目前微信有上千台服务器,我们假定它们带宽均为千兆,则每月微信服务器花费的带宽租赁费就达到 1亿。这和其公开透露的信息一致 17

至于用户侧的带宽使用情况,考虑 2.5G GPRS 网络速率典型值为 80kbps,3G 网络则速率可达 1Mbps。为了简化我们设平均每个用户的带宽为 200 kbps。微信用户数目前超过 3亿,同时在线活跃用户数设为 5000 万,则用户带来的总带宽消耗为 \(1\times10^4\) Gbps。注意蜂窝系统的频率重用机制可以有效地减少所需的实际带宽。

下面通过一个 GPRS 小区分析信令风暴问题。心跳信息携带数据量很小,但仍需完整的信令流程完成传输,会给网络的信令开销变大。考虑GPRS 系统,每次数据传输前都需要激活 PDP 上下文、通过 PRACH 请求数据信道、PAGCH 返回信道信息,心跳信息传输完成后又要解除 PDP 上下文。由于心跳信息数据量很小,我们认为它需要的数据帧数目与信令请求数据帧相当。这样每次心跳信息传输时基站与终端间的通信过程中用于信令的数据帧比信息本身的数据帧的比例达到了 75%,远高于一般数据传输时的比例。当小区内用户数较多时,就会对基站及回传网设备进行大量而频繁的信令请求,使系统处于高负载状态,网络性能恶化。考虑有 \(s=6\) 个 GPRS 信道的场景,当业务量 \(a = 0.5s = 3\) 时,丢失率 \(P_L = E_6(3) = 0.052\),但当 \(a = 0.8s = 4.8\) 时,丢失率 \(P_L = 0.176\),意味着有接近 1/5 的请求是无法得到服务的。如果此时被拒绝服务的终端多次重试,则会进一步加重网络负担,可能引起信令风暴。

对网络地址的估计仍分用户和服务器两部分考虑。3 亿用户理论上需要 3 亿个 IP 地址,数目达到了 IPv4 地址空间的 7.5%。在 IPv4 地址枯竭的今天,这一挑战是通过大量使用 NAT 解决的。对于 IPv6 网络这个数目并不紧缺。服务器端设服务器总数为 1000 台, 考虑虚拟化技术可以使每台服务器运行 5 个系统实例, 每个实例假定需 2 个 IP 地址,再假设所有服务器中仅有一半需要公共可访问的IP 地址,则服务器端共需要 5000 个公网 IP 地址和 5000 个内网地址。这一需求相对不高,但仍需设计地址的聚类,以避免加重路由表爆炸问题。

对于现有业务的影响

我们考虑微信对运营商现有业务的影响。具体来讲,我们考虑部分微信用户使用微信的语音、文本聊天功能取代传统的短信和电话后,运营商收益的变化。我们设每个用户一天过去有 10min 语音通话、发送10条短信的需求。现在该用户使用微信满足以上需求,则根据微信的业务流量 6,他一天消耗的流量(语音、文字和后台流量)约为 \[10\times 60 \times 1 \text{K} + 0.01 \text{M} + 24 \times 2.4 \text{K} = 667.6 \text{K}.\]

不考虑套餐,运营商对流量计费一般为 0.01 元/KB,于是一天的流量费用为 6.676 元。取语音通话费用为 0.4 元/min,短信费用为 0.1 元/条,则该用户使用传统业务时每天花费 \(10\times 0.4 + 10 \times 0.1 = 5\) 元。可以看到不使用套餐时使用微信的花费反而更高,由此可见运营商对流量定价的精明。

实际生活中,用户往往会选择某一套餐。以中国移动北京动感地带用户为例,他很可能会选择25元的校园套餐,它提供每月300条短信和 30M 数据流量,对语音计费为 0.2 元/min 18。可以看到使用改套餐后短信需求可以被满足,微信流量也可满足。因此改用微信前后用户花费的差额只是原来的语音通话部分,为每月 \(30\times 10\times 0.2 = 60\) 元。这一数值也是运营商营收的减少量。假设3亿微信用户中有 10% 选择用微信完全替代传统的短信和电话,那么运营商每月营收减少 \(3\times10^8 \times 10\% \times 60 = 18\) 亿元。由此可见微信对运营商经济利益的冲击是不可忽视的。

至于对同类竞争应用的影响,微信在市场占用率上已处于优势地位,会借助已有的用户基数巩固其地位。同类应用不大可能超越微信的市场地位,但可以通过对特定人群的针对性,在特定服务上赢得自己的市场。特别地,运营商开发的类似应用可以与自己的网络和已有业务做更好的融合吸引用户。考虑到目前同类应用均无营利途径,这里就不再讨论经济影响。

对策

阐述立场

本文定位于学术研究,下面将从学术研究角度对微信的发展提出若干对策。

政策对策

政策对策的出发点应该是鼓励创新。新兴应用出现时,往往会对现有业务产生冲击,在一定程度上危及现有业务的利益。但应看到,新生事物中的创新会推动整个行业的进步,最终给用户和社会带来益处。政府部门应鼓励创新和良性竞争,适当照顾新应用,促进行业发展。微信是移动互联网大趋势的一个代表,可以促使整个网络的升级优化,应当受到政策层面的支持和鼓励。

技术对策

针对微信对现有网络带来的信令风暴压力,运营商和腾讯均应从技术上进行调整。对运营商而言,网络升级、扩容是长久之计,网络运行中需要资源监控和动态调整。从腾讯的角度来说,微信应用程序的逻辑处理需要做调节和优化,应当动态适配网络环境。微信可以在较差的网络环境下减缓心跳频率,减轻对网络的负担。

从更长远的角度来说,未来的网络设计可以考虑让网络动态感知业务,根据业务类型分配合适的网络资源。这可以是解决信令风暴等问题的新思路之一。

经济对策

微信等应用的持续发展无法违背基本的经济规律。一种比较好的经济对策是让运营商、互联网公司和用户公共分担成本和收益。前文已经给出了腾讯可以采取的若干营利手段。运营商可以租赁专门的链路或网络资源给长时在线应用,并收取一定的费用。普通用户可能会根据业务等级接受差分定价(包括免费)的服务。

结论

微信是新兴移动互联网应用的典型代表,它的流行对运营商的网络和利益带来了冲击。问题的解决需要政府、互联网企业、运营商、用户协调配合,多管齐下。此外,微信等应用对网络的影响,未来网络应该如何更好地支持微信等应用,有望成为学术研究中的新课题。

参考文献

[1]“微信 – 维基百科.” http://zh.wikipedia.org/zh/%E5%BE%AE%E4%BF%A1.

[2]“微信 FAQ.” http://weixin.qq.com/cgi-bin/readtemplate?uin=&stype=&promote=&fr=&lang=zh_CN&ADTAG=&check=false&nav=faq&t=weixin_faq&loc=readtemplate,weixin,body,4.

[3]“微信技术总监解读微信架构的秘密.” http://djt.qq.com/article/view/201, apr-2012.

[4]周颢, “微信之道-至简.” http://djt.qq.com/article/view/201.

[5]wangqiaowqo, “cmwap和cmnet接入点的区别.” http://wangqiaowqo.iteye.com/blog/701363.

[6]“微信相关流量问题.” http://weixin.qq.com/cgi-bin/readtemplate?uin=&stype=&promote=&fr=&lang=zh_CN&ADTAG=&check=false&nav=contact&t=weixin_faq_networkflow.

[7]谢晓萍, “腾讯伸出‘橄榄枝:’微信启动2.5G网络优化计划缓解信令困扰.” http://www.nbd.com.cn/articles/2013-04-11/731513.html.

[8]腾讯微信团队, http://e.weibo.com/1930378853/zro8fc0Tb, apr-2013.

[9]“微信的大规模使用真的会过多占用信令,影响通讯稳定吗?- 知乎.” http://www.zhihu.com/question/20849677.

[10]“微信支付业务预计7月上线 或采用二维码支付.” http://news.xinhuanet.com/info/2013-04/20/c_132324462.htm.

[11]C. Zhang, “微信——精品背后的打磨.” http://djt.qq.com/article/view/369.

[12]“2013Q1中国智能手机市场季度报告.” http://www.iimedia.cn/36650.html.

[13]“新媒体蓝皮书:2013年中国新媒体发展十大趋势.” http://www.gmw.cn/media/2013-06/25/content_8065624.htm.

[14]“2013:中国电子商务发展步入临界点.” http://www.chinadaily.com.cn/hqzx/2012-11/26/content_15959843.htm.

[15]“未来五年语音通话量下降 VoIP用户将突破10亿.” http://tech.cn.yahoo.com/ypen/20121214/1491341.html.

[16]“张小龙:微信背后的产品观.” http://tech.ifeng.com/mi/detail_2013_01/20/21396463_0.shtml?_from_ralated.

[17]“微信每月服务器花费1亿.” http://www.doserv.com/article/2012-12-24/7668550.shtml.

[18]“中国移动北京动感地带校园套餐.” http://www.bj.10086.cn/service/zfzq/mzone/content_1/.


  1. 除此之外目前微信还支持 Windows Phone、Blackberry 等平台。.

  2. 然而网络的部署可能总是赶不上需求的发展。当地球上实现了网络的完全覆盖时,或许人们已经开始有了星际旅行深空通信的需求。.

8月 182013
 

上周六参加了 Perl China 2013 的活动,总体上收获颇丰。由于日程紧张,只听了上午的演讲。又由于分身乏术,只听了一个厅的主题。活动地点在高端大气的朝阳区万通中心,离朝外 SOHO、CCTV 大裤衩、国贸都不远。根据百度地图指的路线,从呼家楼地铁站 H 出口最为近便。不过从 10 号线下车找到 6 号线的 H 口就费了一些周折。之后从地铁口出来到会议地点不慎又走了冤枉路,深入到了这片城中村。最后发现正确的路线需要经过一个栅栏门,这在地图上是显示不出来的。终于到了会议地点,拿到了 T 恤衫。这次上面是 Perl 6 的吉祥物蝴蝶 Camelia,颇为可爱。只是赞助商的标志也很明显。之后的开场致辞,不得不提的是有漂亮的赞助商 HR 发言。

第一个演讲主题是扶凯带来的 Mojolicious Web 框架 (简称 Mojo)。根据介绍,Mojo 是一个全功能的 Web 框架,支持 IPv6、TLS 等,支持热部署。Mojo 在路由时可以用正则表达式约束匹配。Mojo 伸缩性也很好,可以做简单的单文件应用,也可以提供复杂应用的框架结构和模板。Mojo 的 HTML 模板可以用 EP,也可以用 XSlate 等。Mojo 还提供了 Web 客户端,支持 CSS 选择器,能容易地进行 DOM 操作。附讲稿链接

第二个演讲是 Robin Lee 的 Perl on Fedora 介绍。演讲介绍了 CPAN 包与 Fedora 仓库中的 RPM 包的映射关系,包括 CPAN distribution 到 RPM 的映射(加 perl- 前缀,双冒号换成减号 -)、Perl 模块到 RPM 的映射(命名为 perl(module name))。另外还介绍了用 cpanspec 打包 CPAN 包的步骤。附讲稿链接

上午最后一个演讲是 @ARGV 对 ElasticSearch (简称 ES)的介绍。通过演讲了解到了 ES 是一个基于 Lucene 的全文检索工具。其中还介绍了 logstash,一个支持众多输入源、众多输出源的日志收集分析暂存工具。还有 Kibana,一个疯狂重构的日志搜索 Web 前端。Kibana 1 是 PHP 写的,Kibana 2 变成了 Ruby,Kibana 3 则是纯 HTML 和 Javascript。PPT 全文链接

会上还学到了两个有用的知识点。其一是用 cpanm 来安装 CPAN 包。相比于 cpan 命令,cpanm 最小化,追求零配置,简单易用。cpanm 还可以直接接一个 git 代码库的 URL 进行安装。其二是用 metacpan 来搜索 CPAN 包/模块,比起 search.cpan.org 来 metacpan 是一个更年轻的项目、提供更友好的搜索界面。

最后是两点注记。cpanm 在 Fedora 上可以用 yum 安装:yum install perl-App-cpanminus。要在非系统目录下安装 CPAN 包,需要安装 local::lib (yum -y install perl-local-lib),然后在 ~/.bash_profile 或对应文件中加上一行

eval $(perl -I$HOME/perl5/lib/perl5 -Mlocal::lib)