小型即时通讯软件架构的选择

Question

问这个问题的背景是，学校的小学期项目是用C++实现一套小型的即时通讯软件，包括服务器端和客户端。一般来说想到的解决方案都是Socket异步通信、基于XMPP协议等等，但我没有C++写网络的经验，只会一些PHP写HTTP服务器端，时间上也比较紧迫，所以想到了这样的几个问题：

1. 即时通信软件是否可以采用Web应用的模式，即客户端和服务器使用HTTP请求通信？
2. Socket是对传输层的TCP/IP协议的封装，而HTTP则属于应用层，那么“使用Socket编写网络编程”和“使用HTTP请求进行通信”这两者有什么区别和联系？
3. C++编写Web服务器实现API，有没有轻量级的实现？

Answer 1

1 可以 相关技术 ajax comet websocket
2 资源占用不同 实时性不同
3 这个问题和你前面的问题冲突 到底是想问PHP的还是C++的

Answer 2

服务器可以使用C++,增加web socket服务，那么客户端就可以使用浏览器，用javascript+websocket（html5）实现

Answer 3

web 下 ajax最容易实现。

Answer 4

给出一个比较超前的解决方案，作为参考：
node-webkit + Socket.io + Web前端综合技术

关于node-webkit的介绍，可以看这里

Answer 5

做im的方案一般有两种：自研or使用第三方sdk

一、首先我们说下自研，自研的坑主要有两个

1、成本高

2、稳定性差
im这块做起来不难，几个工程师花个十天半个月就能做出一套系统来。但是做过IM 的工程师一般不会去做，因为im拾是个坑，功能不全面，而且很容易出bug，比如消息到达不及时、消息记录看不到，尤其是用户量起来后，问题会更多，这个坑很难填完。

自己做im稳定性差，除非经验非常丰富。这个感悟是我的两个经历得出的感悟：
1）我曾经做过产品经理，参与到了一个平台性的产品开发，初期这个产品是团队自研的，功能本身不全面，后来用户越来越多，im这块问题也原来越多，而且影响到了整个web端和移动产品的开发进程
2）我后来的工作就是为开发者提供im服务，有很多开发者联系到我们说本来自己做的im，做好之后问题很多。

二、利益相关

我和我的团队为开发者提供im的sdk、api接口、demo源码，我们的主要优势有：

1、稳定性
做过im的同学应该都知道，im做不好的话是个填不完的坑，尤其是用户量起来后，收发消息延迟等等各种问题都就出来了，那我们是怎么保障稳定性的呢？
1）采用消息必达策略，已成功发送1000亿条消息；
2）即使同时在线人数飚升，自动水平扩展可以应接海量并发；
3）选用BGP机房、全球多点覆盖

2、安全保障
1）不切入用户系统，选择性托管帐号系统；
2）采用私有二进制加密协议、RSA+流式加密传输，数据文件多重备份确保数据安全；
3）IT信息安全体系认证

3、服务
我们在开发同学接触到云信开始就提供7*24小时1对1的技术支持，有任何问题都可以在任何时间找到我们，并给予解决方案，这样一来开发同学的效率也高，产品开发进展也快

获取sdk包 api接口 demo源码请私信我