IM即时通讯设计 高并发聊天服务:服务器 + qt客户端(附源码) |
您所在的位置:网站首页 › 群聊类型 › IM即时通讯设计 高并发聊天服务:服务器 + qt客户端(附源码) |
界面相对简陋,主要界面如下 登录界面支持的功能 注册账号 登录账号 添加好友 群聊后续UI美化以及功能增加持续更新,关注微信公众号「编程学习基地」最快咨询.. IM即时通讯本系列将带大家从零开始搭建一个轻量级的IM服务端,麻雀虽小,五脏俱全,我们搭建的IM服务端实现以下功能: 注册 登录 私聊 群聊 好友关系第一版只实现了IM即时通讯的基础功能,其他功能后续增加. 设计一款高并发聊天服务需要注意什么 实时性在网络良好的状态下服务器能够及时处理用户消息 可靠性服务端如何防止粘包,半包,保证数据完全接收,不丢数据,不重数据 一致性保证发送方发送顺序与接收方展现顺序一致 实时性就不必细说了,保证服务器能够及时处理用户消息就行,重点说下可靠性 如何设计可靠的消息处理服务简单来说就是客户端每次发送的数据长度不定,服务端需要保证能够解析每一个用户发送过来的消息。 这就涉及到粘包和半包,这里说下粘包和半包是什么情况 什么是粘包多个数据包被连续存储于连续的缓存中,在对数据包进行读取时无法确定发生方的发送边界. 例如:客户端需要给服务端发送两条消息,发送数据如下 char msg[1024] = "hello world"; int nSend = write(sockFd, msg, strlen(msg)); nSend = write(sockFd, "粘包", strlen("粘包"));服务端接收 char buff[1024]; read(connect_fd,buff,1024); printf("recv msg:%s\n",buff);结果就是服务端将两条消息当成一条消息全部存入buff中。输出如下 recv msg:hello world粘包当客户端两条消息发的很快的时候,服务端无法判断消息边界导致照单全收的情况就是粘包。 什么是半包单个数据包过大,服务端预定缓冲不够,导致对数据包接收不全 例如:客户端需要给服务端发送一条消息,发送数据如下 char msg[1024] = "hello world"; int nSend = write(sockFd, msg, 1024); //发送字节大小为1024服务端接收 char buff[128]; read(connect_fd,buff,128); printf("recv msg:%s\n",buff);结果就是服务端缓冲不够,只能读取部分包内容。 解决粘包和半包如何解决粘包和半包的问题? 通过自定义应用协议,客户端给数据包进行封包,服务端进行拆包。 以项目实例来说,定义包头 + 包 +负载
其实就是发送数据包的时候先发一个包头,包头里面有一个字段表示包的大小 包头后紧跟着包,这个包还不是数据包,只是数据包的描述信息,例如发送消息代表一个命令,字段command用来从存储命令,让服务器能够解析这是群聊数据包还是私聊数据包。包头和包定义付下 struct DeMessageHead{ char mark[2]; // "DE" 认证deroy的协议 char version; char encoded; //0 不加密,1 加密 int length; }; struct DeMessagePacket { int mode; //1 请求,2 应答,3 消息通知 int error; //0 成功,非0,对应的错误码 int sequence; //序列号 int command; //命令号 };负载就是你真正要发送的数据包结构了,可能是msg消息,又或者其他的自定义消息。 IM通信协议所谓“协议”是双方共同遵守的规则. 协议有语法、语义、时序三要素: (1)语法:即数据与控制信息的结构或格式 (2)语义:即需要发出何种控制信息,完成何种动作以及做出何种响应 (3)时序:即事件实现顺序的详细说明 一套典型的IM通信协议设计分为三层:应用层、安全层、传输层。 在通信过程中,chat_room使用的是tcp作为传输层的协议,暂时未引入数据加密解密,所以未涉及安全层协议。 应用层协议选型,常见的有三种:文本协议、二进制协议、流式XML协议。 文本协议文本协议是指 “贴近人类书面语言表达”的通讯传输协议,典型的协议是http协议。 一个http协议大致长成这样: GET / HTTP/1.1 User-Agent: curl Host: musicml.net Accept: */*文本协议的特点是: a. 可读性好,便于调试 b. 扩展性也好(通过key:value扩展) c. 解析效率一般(一行一行读入,按照冒号分割,解析key和value) d. 对二进制的支持不好 ,比如语音/视频 二进制协议二进制协议是指binary协议,典型是ip协议。二进制协议一般定长包头和可扩展变长包体 ,每个字段固定了含义,此次项目设计chat_room采用的就是二进制协议作为应用层的传输协议。 二进制协议有这样一些特点: a. 可读性差,难于调试 b. 扩展性不好 ,如果要扩展字段,旧版协议就不兼容了。 c. 解析效率超高 QQ使用的就是二进制协议 流式XML协议这个一般场景用的比较少了,我所接触的就是Onvif协议交互用的就是流式XML协议。 XML协议特点: a.它是准标准协议,可以跨域互通 b.XML的优点,可读性好,扩展性好 c.解析代价超高 d.有效数据传输率超低(大量的标签) 数据传输格式即时通讯应用(包括IM聊天应用、实时消息推送应用等)在选择数据传输格式的时候比较纠结,不过我个人建议将Protobuf作为即时通讯应用的首选通讯协议格式。此次项目设计未使用Protobuf是因为不想导入第三方库,怕有些同学直接劝退。 据说,手机QQ的数据传输协议已在使用Protobuf了,而从官方流出资料来看微信很早就在使用Protobuf(而且为了尽可能地压缩流量,甚至对Protobuf进行了极致优化)。 此次项目使用的是二进制数据流作为数据传输格式,其实就是一堆结构体变量。 例如登陆的数据包定义如下: struct LoginInfoReq{ int m_account; char m_password[32]; };服务端和客户端双方约定好一个数据结构就可以了,特点就是简单。 聊天服务设计目前采用的是多线程处理客户端请求,即一个客户端一个线程,这周会改成IO多路复用,用epoll来接受更高的并发。 整体设计如下:
第一步:客户端发送数据包 第二步:服务端解析数据包,传递给各个业务处理模块 第三步:业务处理模块按照通信协议解析并处理消息 消息处理对客户端的消息处理就是接受一个完整的数据包,传递给服务器。 由于采用封包-拆包作为通信的传输协议,所以在处理数据包的时候需要一个健壮的数据处理逻辑 此次项目处理逻辑如下 int Session::readEvent() { int ret = 0; switch (m_type) { case RECV_HEAD: ret = recvHead(); break; case RECV_BODY: ret = recvBody(); break; default: break; } if (ret == RET_AGAIN) return readEvent(); return ret; }先读取头,在读取到head包头之后申请body(包+负载)所需空间,再读取body,body读取完毕之后传给消息分发的逻辑。 消息分发服务端是如何区分群聊消息和私聊消息?在我们解决粘包和半包问题的时候就给出了答案。 客户端封包结构为:包头 + 包 +负载 在Pack包里面有一个代表命令的字段 command. struct DeMessagePacket { int mode; //1 请求,2 应答,3 消息通知 int error; //0 成功,非0,对应的错误码 int sequence; //序列号 int command; //命令号 };服务端可客户端双方约定的 cmmand 如下 //命令枚举 enum{ CommandEnum_Registe, CommandEnum_Login, CommandEnum_Logout, CommandEnum_GroupChat, CommandEnum_AddFriend, CommandEnum_delFriend, CommandEnum_PrivateChat, CommandEnum_CreateGroup, CommandEnum_GetGroupList, CommandEnum_GetGroupInfo, CommandEnum_GetFriendInfo, };服务端通过switch匹配各个命令,进而对每个命令进行处理。 用户注册用户注册请求,响应的数据格式如下 /** * @brief 注册用户信息 */ struct RegistInfoReq{ char m_userName[32]; char m_password[32]; }; struct RegistInfoResp{ int m_account; };在用户注册时,服务端生成一个唯一的账号发送给客户端,客户端只能通过该账号与服务端交互。 用户注册完成之后会存放在服务端的一个全局map表中,方便集中管理 typedef std::map mapAccountInfo; //注册用户表 static mapAccountInfo g_AccountInfoMap; //注册账户信息表 用户登陆用户登陆请求,响应的数据格式如下 struct LoginInfoReq{ int m_account; //账号 char m_password[32]; };用户登陆成功后会创建一个用户信息 UserInfo 并将该用户信息添加到全局的一个用户map表中集中管理 typedef std::map mapUserInfo; //在线用户表 static mapUserInfo g_UserInfoMap; //在线用户信息表登陆成功之后发回给客户端的是一个没有负载的包,包中的error字段置0. 用户登出客户端直接断开即可,具体登出数据格式暂未实现. 群聊此次设计中有一个公共群聊(账号为0),所有用户都在群聊里面。 用户群聊请求,响应的数据格式如下 truct GroupChatReq { int m_UserAccount; //发送的账号 int m_msgLen; int m_type; //数据类型 0:文本,1:图片 ... int m_GroupAccount; //发送群号 0:广播 };看着没啥毛病但是群消息在哪?要发送的数据在哪? 还记得我们客户端封包结构:包头 + 包 +负载 负载里面包含了 数据传输格式+其他数据 在群聊请求里面有一个 m_msgLen字段用来区分消息的边界,因为客户端发送的消息是不定长的,所以需要这么一个字段来区分消息的边界。 私聊用户私聊请求,响应的数据格式如下 struct PrivateChatReq { int m_UserAccount; //发送的账号 int m_msgLen; int m_type; //数据类型 0:文本,1:图片 ... int m_FriendAccount; //发送好友账号 };跟群聊类似,其实这两个数据格式可以用同一个。 添加好友用户添加好友请求,响应的数据格式如下 struct AddFriendInfoReq { int m_friendAccount; //好友账号 int m_senderAccount; //发送端账号 char m_reqInfo[64]; //请求信息 例如我是xxx }; struct AddFriendInfoResp { int m_friendAccount; //好友账号 int m_senderAccount; //发送端账号 int status; //同意0,不同意-1 };添加好友的流畅比较复杂,我在设计的时候也卡了一下。 主要流程如图 用户获取好友信息请求,响应的数据格式如下 /* 好友请求接口封装 */ struct GetFriendInfoResp { int m_size; //群成员大小 }; struct FriendInfo{ char m_userName[32];//好友用户名 int m_account; //账号 int m_status; //是否添加成功 0:等待添加 1:同意 };这里大伙可能有点蒙了,又是包头,又是包,又是负载的,拿着数据格式到底属于那块的 其实数据格式(例如GetFriendInfoResp结构体)和数据都属于负载里面的,如图所示。 对于通信协议为二进制的协议来说,解析起来效率是最快的。 获取群列表用户获取群列表信息请求,响应的数据格式如下 struct GetGroupListResp { int m_size; //群数量大小 }; struct GroupChatInfo { char m_groupName[32]; //群名称 int m_account; //群账号 int m_size; //群大小 };数据的传输同获取好友信息,在这里群列表也有一个map表统一管理。 获取群信息用户获取群信息请求,响应的数据格式如下 struct GetGroupInfoReq { int m_GroupAccount; //群号 0:广播 }; struct GetGroupInfoResp { char m_groupName[32]; //群名称 int m_GroupAccount; //群号 0:广播 int m_size; //群成员大小 }; struct GroupUserInfo{ char m_userName[32]; int m_account; //账号 int m_right; //权限 0:群成员 1:群管 2:群主 };这里的数据传输和获取好友信息一样。 到这里我们的服务端介绍完了,比较复杂,但是知识点超多。客户端设计相对容易些,但是我感觉单纯的终端客户端太掉逼格了,就又写个一个qt的客户端,重温了一边qt的UI设计,简直不要太爽,qt的客户端设计会另外再补一篇文章。 github源码chat_room:https://github.com/ADeRoy/chat_room 欢迎慷慨 star |
CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3 |