互联网的历史总显得具有不可思议的戏剧性:1996年,4位以色列人发明了IM的鼻祖――ICQ“坏小子”,那时它只是一个主要搞网上寻呼的“小玩意”;1998年,腾讯研发团队为QQ用户突破100人而“兴奋不已”;2000年前后,业内传马化腾打算把QQ作价100万卖给深圳电信,但深圳电信却不要。到2005年腾讯却成为中国收入前三名的互联网公司,而与腾讯一样做即时通讯的朗玛UC,依靠市场份额和用户数排名第二的优势,被新浪收购后换来了3600万美元的现金和股票。
说起中国即时通讯的历史,不得不提马化腾,这个戴着眼镜、温文尔雅的年轻人。1998年的腾讯创始人马化腾还是个睡沙发、吃盒饭的总裁,当他与另两个“元老”一起挤在深圳赛格科技园4楼一间几十平方米的小厂房办公时,他的名片上甚至从来都不敢印“总经理”的头衔,而只印着“工程师”字样――马化腾当时的惟一期望,只是公司能生存下来;他更没想到仅5年之后,他因此就一夜之间成了身价8亿港元的富豪。
聊天其实一直是网民们上网的主要活动之一,只不过,当时网上聊天的主要工具只有聊天室。即时通讯的出现并不像后来所描写的“很自然地崛起”,出身于著名寻呼企业润讯的马化腾最初做的只是与寻呼业相关的ICQ软件。只是当电信寻呼、联通寻呼、润迅寻呼等大寻呼企业都用上了这种网络寻呼机,给马化腾他们赚来了第一桶金后,腾讯才瞄上了在国外正热的互联网产业。1999年,腾讯正式提供互联网的即时通讯服务。
其实新浪在这个领域也可以说是先行者,早在1999年,新浪就推出了一款IM工具叫Sinapager,当时这款工具的功能应该说已经很强大了,比腾讯的QQ毫不逊色,而且当时用户群并不少。只是新浪当时没有那么专注于IM领域上。
从前,并没有多少人认为即时通讯会有多大出路,因为这种需要随时在网上的聊天工具一直受制于互联网的拨号上网。这导致QQ用户数一增加就要不断扩充服务器,马化腾甚至都坚持不下去了,一度决定将QQ卖掉。只是买家深圳电信数据局准备出60万元,而马化腾坚持要卖100万元,最终因为价格无法达成一致,最终谈判告终。
但是,当马化腾在2003年第一次进入“福布斯中国富豪榜”第九十九名,腾讯宣布QQ同时在线人数达到492万,这个互联网业开始为即时通讯沸腾。
先是网易开始发力,在北京推出了新版的即时通讯软件网易泡泡2004;然后是新浪花3600万美元收购已有巨大用户群的UC,加上搜狐在2004年初推出的即时通讯软件“搜Q”的奋力一搏,以及微软的MSN也进入中国插一脚。门户网站们显然希望能够通过自己长久以来累积的用户忠诚度在该领域有所作为。一时之间,即时通讯与搜索引擎一起,成了最热门的互联网领域。以至于在即时通讯软件上做一些插件的增值服务公司也层出不穷。
客观上来说电信运营商对带宽投入的大幅增长导致互联网的更普及是即时通讯繁荣的物质基础;而几个门户网站纷纷选择发力即时通讯市场,不仅仅是简单地给自己补课,更是促进了即时通讯的普及。
“中国即时通讯市场将发生翻天覆地的变化,当然并不是说谁可以把QQ干掉,QQ依然会占领很大的市场份额,但是绝对不是像现在这样的一家独大的垄断性份额。我认为这个时间很快就会来临,或许就在今年底或明年。”前雅虎中国总裁周鸿
}
作者简介: 陈宜龙(),iOS 开发工程师,现任职于 LeanCloud,热爱开源与分享, 获得的 Star 数过万,也是多个开源项目的维护者,比如 、 等。
IM 已经成为当下 App 的必备模块,在不同垂直领域,技术实现不尽相同。究竟该如何选型?技术实现过程中,又该如何进行性能调优?本篇文章分为应用场景、技术实现细节、针对移动网络特点的性能调优三个部分,具体讲解IM即时通讯技术在社交、直播、红包等不同场景下的技术实现与性能调优。
需要注意,本文中所涉及到的所有 iOS 相关代码,均已 100% 开源(不存在 framework ),便于学习参考;本文侧重移动端的设计与实现,会展开讲,服务端仅仅属于概述,不展开;本文还将为大家在设计或改造优化 IM 模块,提供一些参考。
大规模即时通讯的技术难点
- 如何在移动网络环境下优化电量、流量及长连接的健壮性?现在移动网络有 2G、3G、4G 各种制式,且随时可能切换和中断,移动网络优化可以说是面向移动服务的共同问题。
- 如何确保IM系统的整体安全?因为用户的消息是个人隐私,所以要从多个层面来保证。
- 如何降低开发者集成门槛?
- 如何应对新iOS生态下的政策并结合新技术,比如 HTTP/2、IPv6、新的 APNs 协议等。
IM 服务的最大价值在于什么?可复用的长连接。一切高实时性的场景,都适合使用 IM 来做,比如:视频会议、聊天、私信、弹幕、抽奖、互动游戏、协同编辑、股票基金实时报价、体育实况更新;基于位置的应用(Uber、滴滴司机位置)、在线教育、智能家居等。
接下来,我们会挑一些典型场景进行介绍,并分析其中具体的技术细节。
IM 基本的发展历程是:轮询、长轮询、长连接。
下面挑选一些代表性的技术进行介绍:
- 一般的网络请求:一问一答,如图1所示。
- 轮询:频繁的一问一答,见图2。
- 长轮询:耐心地一问一答,见图3,曾被Facebook早期版本采纳。
一种轮询方式是否为长轮询,是根据服务端的处理方式来决定的,与客户端没有关系。
短轮询很容易理解,那么,什么叫长轮询?与短轮询有何区别?长轮询和短轮询最大的区别是,短轮询去服务端查询时,不管服务端有没有变化,服务器就立即返回结果了。而在长轮询中,服务器如果检测到库存量没有变化话,将会把当前请求挂起一段时间(这个时间也叫作超时时间,一般是几十秒)。在这个时间内,服务器会检测库存量有没有变化,变化就立即返回,否则就等到超时为止。
我们可以看到,发展历史是这样:从长短轮询与长短连接,使用 WebSocket 来替代 HTTP。长短轮询到长短连接的区别主要有:
- 概念范畴不同:长短轮询是应用层概念,长短连接是传输层概念;
- 协商方式不同:一个 TCP 连接是否为长连接,是通过设置 HTTP 的 Connection Header 来决定的,且需要两边都设置才有效。
- 实现方式不同:连接的长短是通过协议来规定和实现的。而轮询的长短,是服务器通过编程的方式手动挂起请求实现的。
在移动端上长连接是趋势,其最大的特点是节省 Header。对比轮询与 WebSocket 所花费的 Header 流量即可窥其一二。
假设 Header 是 871 字节,我们以相同的频率 10W/s 去做网络请求,对比轮询与 WebSocket 所花费的 Header 流量。其中,Header 包括请求和响应头信息。出于兼容性考虑,一般建立 WebSocket 连接也采用 HTTP 请求的方式,从这个角度讲,无论请求如何频繁,都只需要一个 Header。
相同的每秒客户端轮询的次数,当次数高达 10W/s 的高频率时,Polling 轮询需要消耗 665Mbps,而 WebSocket 仅仅只花费了 ,网址
}