关于XMPP、WEBIM等内容,比较初级,用于扫盲及培训

最近做了一点关于即时通信的研究和探索,一方面是工作需要,另一方面,想研究一下主流的通信协议,自己搞一个可以和多方通信的玩意。话说多方通信其实正规渠道还是要走人家的openapi,合法、授权机制、安全。

这个玩意其实比较老了,现在除了腾讯的即时通信体系,其他的诸方看来都开始使用标准协议。当然腾讯比较NB,用户也大,人家不屑于和你们搞,人家自己搞自己就足够了。腾讯想方设法要搞掉那些不合法的端,因为人家就是靠端吃饭的。

据说 人家 用多了是故意装纯,我咋没觉出来呢。

关于XMPP,它就是个标准,规定大家怎么传输消息内容,当然也规定了诸如好友、分组、个人信息等内容,使用这个协议的东西还是挺多的,比如人人的即时通信、新浪的即时通信、Facebook的即时通信、Gtalk、MSN等。

嗯,协议一样,怎么验证呢,用一个小玩意就行了--Pidgin。经常在Linux环境下工作的同学肯定知道这个,而且用的很多,当然它也有Windows版本。装上之后添加一个账号的东西,记得选XMPP,账号就是登录人人Web之后,个人主页的后边的一串数字


记得这个只能用来聊天。人人的客户端是在这个协议基础之上的扩展,把SNS相关的信息根据格式推送到端。

再添加一个Gtalk的试试,把域换成gmail.com就可以了。

记得试试就可以了,由于人人把所有推送的消息及状态都会发布出来,所以中午连发了三个我目前不在...

上班了,晚上再写。

说一下即时通信。即时通信是个好东西,大家用的都比较多了,其实在即时通信里最基础的两个元素是在线状态和消息,这两个东西都是需要实时传递到每个好友那里的。在实际情况中,在线状态并不需要那么实时,晚个几秒也没关系,而且由于需要广播到每一个好友那里,所以可能经过多级路由,实时性就不那么精确了。基于端的即时通信在技术实现上还是比较简单的,难点主要在于后端的集群、分发、客户端穿透、路由策略、稳定性、丢包处理等。像是QQ能支持那么庞大的用户群,真的要花极大地功夫去不断改进、优化。

下边说一下webim的东西。webim就是在浏览器上聊天,基于相同的技术、也可以实现其他消息推送,比如谁在线、谁给你留言了等等。webim比基于端的即时通信技术应用要晚一些,因为在浏览器上最基本的协议http其实并不算强大的。

先说一下啥是http,我们平时打开网页其实是这么个过程,我来画下


你每一次点一个网页,都是这么个过程。网页是马上返回的,在你得到网页后,你和服务器就断开连接了,再点网页又这么来一次。这一个网页可能从几K到几M不等,如果你的带宽大,比如10M的,你下载这个网页的时间就短。如果网络好,服务器也好,页面也小,你的机器解析的也快,那么打开一个网页可能只要几十毫秒。当然,图片一般是在页面渲染完再去服务端取的,每个图片要单独再取一次。这就是为什么图片较多的网页一般打开比较慢。这个过程是要耗费服务器资源的,人多了,次数多了,服务器就卡了,我们自己电脑开东西多了还卡呢,这就是为啥12306.cn过年的时候老卡。

我们可以通过这个方式去服务器取数据,比如每10秒一次,如果有人给我发消息了,我就把消息解析解析,显示在页面上,同时右下角提醒不断闪就行了。这个过程的弊端比较明显:第一,10秒一次,不太实时,如果有人问你“干啥呢?”,运气不好的话,你十秒后才能看到,回句“XX呢,你呢?”,如果运气又不好,对方要10秒后才能看到,聊句天要20+X秒,显然不能接受,这个问题可以通过减少轮询时间解决,嗯,1秒轮一次,聊天就只要2+X秒了,当然,请求次数多了,服务器要变卡;第二,像是我这种,半天也没人理的人,可能永远也不会在右下角出现提醒的信息,服务器不厌其烦的告诉你,没有你的消息-没有你的消息-没有你的消息-没有你的消息,于是所有的请求都浪费了,人家服务器白卡了。

解决方案就是服务器要把你的请求HOLD住。如下图


说白了就是,你发给服务器的请求他不给你马上返回,先HOLD住,等到你有消息了才返回,于是当有人给你发消息的时候,你可以立即收到。

而且在很长的一段时间里只要保持一个请求就可以了,解决了你玩弄人家服务器的问题,但是服务器仍然怕你玩弄他,要过段时间就断掉,于是你要每隔一段时间重新连接一下。就像是你和你弟弟捉迷藏,你藏好了,50分钟之后,发现你弟弟根本没找你,自己在那看电视呢,你什么心情,于是当你5分钟还没被找到的时候,你就要偷偷看看你弟弟是不是真的在找你,或者重新藏重新找。

请求返回后,马上就会建立一个新的连接,继续如上过程。这种方式的优势显而易见,但是服务器要同时HOLD住很多个来自客户端的http连接,其实压力也很大,但是操作系统经过多年的发展,已经有了此类问题的解决方案,有兴趣的同学可以阅读有关Socket模型的知识,据说Windows的IOCP比Linux的epoll能承受更多的等待连接,做C/C++、网络游戏的同学应该精于此道,像是我们做上层的,其实也是一知半解。

我们来验证一下人人的webim。

首先你得有个好用的可以调试的浏览器,chrome就可以了,打开人人主页,按F12,选到Net

work选项卡,然后用其他的账号给你这个账号发一个消息,于是下边就会显示如下


说明客户端接到请求了,看time一列,第一行,13.94秒,说明经过13.94秒的“你等着吧”之后,才有了你的消息,马上又会出现第四行的同样一条请求,time显示Pending,说明正在请求,你这时候再给这个账号发个消息,这个Pending就会变成时间,也就是这次请求等待的时间。我们看看过来的内容是啥,单击第一行的comet_get,Response选项卡,信息如下

<msglist>

<message type="chat" id="3" from="446327447@talk.xiaonei.com/TalkProxy41_13299459921241" fname="高味儿"

   to="49641516@talk.xiaonei.com/WTalkProxy6_0">

   <body>内容</body><attachment></attachment>

</message>

</msglist>

可以看到,这是从我的马甲账号发过来的消息,并且JID的域名是xiaonei,说明人人的推送服务器还是使用的早期的虚拟域体系并没有更换,也没必要更换。

从第一个选项卡Headers里,我们能看到人人消息推送服务器的名字是XNHttpServer1.0,从主页中我们看到人人的服务器使用的是nginx/1.0.10,由于要解决跨域问题,这个校内http服务器应该是nginx代理重写。nginx可是个好东西,现在诸多SNS、微博能如此流畅其实多亏了它。

我们来看看人人的服务器多长时间断开一次。等两分钟之后,在network选项卡就可以看到变红了的comet_get,时间显示2.0min,说明人人要求两分钟大家就得重新玩,不能占着MKBLS。

基本的东西都说完了,具体的细节大家可以自己研究下,同样大家可以去看看新浪微博的那个,淘宝的那个,FaceBook的那个。

然后是服务器,这个服务器有成熟的东西可以用,比较成熟的有erlang语言的ejabberd和Java语言的openfire。erlang语言晦涩,写惯了面向对象的我们看了真的很不爽,但是erlang的通信很给力,著名的rabbitMQ也是这玩意写的,而且ejabberd对集群的支持很好。openfire是咱java体系的,比较好控制,基于mina的通信层虽然也很不错,但终究比不上尼玛二郎。于是考虑在通信引擎服务器少做改动,尽量在业务系统和前端支持好XMPP协议,做到业务与通信引擎分离。以下是初步的架构思路


初步构想,也没啥技术含量,应该不会被XX。

这个下次培训拿给人看。还得再诸如消息存储方面做一些设计,用点流行的redis啥的。

太晚了,明天再写。

发布了39 篇原创文章 · 获赞 5 · 访问量 13万+
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 大白 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览