昨天晚上到今天早晨，在微信群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链接，激活的页面与服务端及时同步，非激活页面同步时间长。

最后，感谢各位的对技术的热情和毫无保留的解答疑问。