[TOC] ### 一些对IM架构的思考 #### 短连接 HTTP协议扩展，运行8080 端口，http body为二进制（protobuf）。  主要用途（接口）： ``` 用户登录验证; 好友关系（获取，添加）； 消息sync (newsync)，自有sync机制； 获取用户图像； 用户注销； 行为日志上报。 朋友圈发表刷新 ``` #### 长连接  tcp 长连接，端口为8080，类似微软activesync的二进制协议。  主要用途（接口）： ``` 接受/发送文本消息； 接受/发送语音； 接受/发送图片； 接受/发送视频文件等。 ``` ### 报文 #### 分三种： ``` 请求报文（request，后简称为为R）； 应答报文（acknowledge，后简称为A）； 通知报文（notify，后简称为N）。 R：客户端主动发送给服务器的报文 A：服务器被动应答客户端的报文，一个A一定对应一个R N：服务器主动发送给客户端的报文 ```` #### 普通消息投递流程 ``` * client-A向im-server发送一个消息请求包，即msg:R * im-server在成功处理后，回复client-A一个消息响应包，即msg:A * 如果此时client-B在线，则im-server主动向client-B发送一个消息通知包，即msg:N（当然，如果client-B不在线，则消息会存储离线） ``` #### 应用层确认+im消息可靠投递的六个报文 >UDP是一种不可靠的传输层协议，TCP是一种可靠的传输层协议，TCP是如何做到可靠的？答案是：超时、重传、确认。（即时通讯网注：实际上IM中，数据通讯层无论用的是UDP还是TCP协议，都同样需要消息送达保证（即QoS）机制，原因在于IM的通信是A端-Server-B端的3方通信，而非传统C/S或B/S这种2方通信) 要想实现应用层的消息可靠投递，必须加入应用层的确认机制，即：要想让发送方client-A确保接收方client-B收到了消息，必须让接收方client-B给一个消息的确认，这个应用层的确认的流程，与消息的发送流程类似： ``` * client-B向im-server发送一个ack请求包，即ack:R * im-server在成功处理后，回复client-B一个ack响应包，即ack:A * 则im-server主动向client-A发送一个ack通知包，即ack:N ``` 至此，发送“你好”的client-A，在收到了ack:N报文后，才能确认client-B真正接收到了“你好”。 你会发现，一条消息的发送，分别包含（上）（下）两个半场，即msg的R/A/N三个报文，ack的R/A/N三个报文。一个应用层即时通讯消息的可靠投递，共涉及6个报文，这就是im系统中消息投递的最核心技术（如果某个im系统不包含这6个报文，不要谈什么消息的可靠性) #### 协议 ``` 传输层协议:tcp 应用层协议: protobuf 安全协议:ssl ``` #### 数据库 数据存储:mysql-mongodb 缓存:redis ### 离线消息 ### 万人群