WebIM实践过程中可能遇到的问题及总结

2015年4月26日 10:25 阅读 2041
昨天晚上到今天早晨,在微信群QCon可扩展高可用框架群,被  @TimYang 拉进群,主要讨论了一下 WebIM前端的相关问题。

把群里的讨论内容和我自己的一些看法总结如下:

1、对于PC端的WebIM,使用WebScoket结合长轮询的方式。使用长轮询,不仅仅因为WebSocket浏览器兼容性问题,还有就是网络原因,有些网络对WebSocket有限制,原来遇到过,能和WebSocket Server建立链接,但是数据包发送,对方收不到的情况。要视情况,切换到长轮训方式。
2、关于长轮询,它的及时性是很高的。不同于定时轮询,它的原理是,Client端发请求,Server端Pendding,当有需要推送的消息或者超过一定时间,才会Response。然后Client端再发起请求。这样能保证,推送消息的及时性。同域可以用Ajax,跨域可以用Jsonp。因为url长度限制的原因,Jsonp形式对消息长度有限制。或者限制消息长度,或者消息过长,分多次请求发送。
3、在支持http1.1的浏览器里,可以用长链接,用得很少,坑未知。
4、移动Web上,用WebSocket兼容性问题少,理论上绝大多数机型,都支持WebScoket,但是耗电量和持续性不好处理,页面在后台时,线程可能被停掉,这样不能保证在停掉期间,消息的及时推送。现在移动端纯Web端,对于及时通信,个人暂时没有了解到比较靠谱的方案。
5、对于服务,可以用CometD。如果考虑node的话,可以看一下socket.io。
6、Ack,为了适应各种『糟糕』的网络情况,和消息相关的都要做ack确认,服务端,在一定时间内,没收到ack,要重新push消息。而前端要对消息进行判重(有可能前端发ack了,服务端没收到,又重新push了)。
7、状态同步,主要是已读状态同步,一端阅读消息后,要通过服务器将已读状态分发给其他各端。状态同步,还涉及到一个地方是重练后的状态同步。网络断开、请求超时、心跳超时,前端都会进行重练,重练后需要同步所有的状态,因为你不知道重练期间,究竟发生了什么。当然,重练也有逻辑的,不能一有问题就立即重练,要做延时。否则出问题时,容易滚雪球造成更大问题。
8、使用Flash,可以用Flash与服务器创建Tcp链接,激活的页面与服务端及时同步,非激活页面同步时间长。(@58 沈剑)
最后,感谢各位的对技术的热情和毫无保留的解答疑问。

前端打杂工程师