最近做了一点关于即时通信的研究和探索，一方面是工作需要，另一方面，想研究一下主流的通信协议，自己搞一个可以和多方通信的玩意。话说多方通信其实正规渠道还是要走人家的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啥的。
太晚了，明天再写。
扫一扫
1219
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
