IM即时通讯设计----聊天服务（附源码）_im服务端

来源：微信公众号「编程学习基地」

IM即时通信程序设计

界面相对简陋，主要界面如下

• 登录界面

• 注册界面

• 聊天界面

• 添加好友界面

支持的功能

• 注册账号
• 登录账号
• 添加好友
• 群聊

• 私聊
  

后续UI美化以及功能增加持续更新，关注微信公众号「编程学习基地」最快咨询…

IM即时通讯

本系列将带大家从零开始搭建一个轻量级的IM服务端，麻雀虽小，五脏俱全，我们搭建的IM服务端实现以下功能：

• 注册
• 登录
• 私聊
• 群聊
• 好友关系

第一版只实现了IM即时通讯的基础功能，其他功能后续增加.

设计一款高并发聊天服务需要注意什么

1. 实时性

在网络良好的状态下服务器能够及时处理用户消息

1. 可靠性

服务端如何防止粘包，半包，保证数据完全接收，不丢数据，不重数据

1. 一致性

保证发送方发送顺序与接收方展现顺序一致

实时性就不必细说了，保证服务器能够及时处理用户消息就行，重点说下可靠性

如何设计可靠的消息处理服务

简单来说就是客户端每次发送的数据长度不定，服务端需要保证能够解析每一个用户发送过来的消息。

这就涉及到粘包和半包，这里说下粘包和半包是什么情况

什么是粘包

多个数据包被连续存储于连续的缓存中，在对数据包进行读取时无法确定发生方的发送边界.

例如：客户端需要给服务端发送两条消息，发送数据如下

char msg[1024] = "hello world";
int nSend = write(sockFd, msg, strlen(msg));
nSend = write(sockFd, "粘包", strlen("粘包"));
1
2
3

服务端接收

char buff[1024];
read(connect_fd,buff,1024);
printf("recv msg:%s\n",buff);
1
2
3

结果就是服务端将两条消息当成一条消息全部存入buff中。输出如下

recv msg:hello world粘包
1

当客户端两条消息发的很快的时候，服务端无法判断消息边界导致照单全收的情况就是粘包。

什么是半包

单个数据包过大，服务端预定缓冲不够，导致对数据包接收不全

例如：客户端需要给服务端发送一条消息，发送数据如下

char msg[1024] = "hello world";
int nSend = write(sockFd, msg, 1024);	//发送字节大小为1024
1
2

服务端接收

char buff[128];
read(connect_fd,buff,128);
printf("recv msg:%s\n",buff);
1
2
3

结果就是服务端缓冲不够，只能读取部分包内容。

解决粘包和半包

如何解决粘包和半包的问题？

通过自定义应用协议，客户端给数据包进行封包，服务端进行拆包。

以项目实例来说，定义包头 + 包 +负载

其实就是发送数据包的时候先发一个包头，包头里面有一个字段表示包的大小

包头后紧跟着包，这个包还不是数据包，只是数据包的描述信息，例如发送消息代表一个命令，字段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;    //命令号
};
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

负载就是你真正要发送的数据包结构了，可能是msg消息，又或者其他的自定义消息。

IM通信协议

所谓“协议”是双方共同遵守的规则.

协议有语法、语义、时序三要素：

（1）语法：即数据与控制信息的结构或格式

（2）语义：即需要发出何种控制信息，完成何种动作以及做出何种响应

（3）时序：即事件实现顺序的详细说明

一套典型的IM通信协议设计分为三层：应用层、安全层、传输层。

应用层协议设计

在通信过程中，chat_room使用的是tcp作为传输层的协议，暂时未引入数据加密解密，所以未涉及安全层协议。

应用层协议选型，常见的有三种：文本协议、二进制协议、流式XML协议。

文本协议

文本协议是指 “贴近人类书面语言表达”的通讯传输协议，典型的协议是http协议。

一个http协议大致长成这样：

GET / HTTP/1.1
User-Agent: curl
Host: musicml.net
Accept: */*
1
2
3
4

文本协议的特点是：

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];
};
1
2
3
4

服务端和客户端双方约定好一个数据结构就可以了，特点就是简单。

聊天服务设计

目前采用的是多线程处理客户端请求，即一个客户端一个线程，这周会改成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;
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

先读取头，在读取到head包头之后申请body(包+负载)所需空间，再读取body,body读取完毕之后传给消息分发的逻辑。

消息分发

服务端是如何区分群聊消息和私聊消息？在我们解决粘包和半包问题的时候就给出了答案。

客户端封包结构为：包头 + 包 +负载

在Pack包里面有一个代表命令的字段 command.

struct DeMessagePacket
{
    int mode;  //1 请求,2 应答,3 消息通知
    int error; //0 成功,非0,对应的错误码
    int sequence;   //序列号
    int command;    //命令号
};
1
2
3
4
5
6
7

服务端可客户端双方约定的 cmmand 如下

//命令枚举
enum{
    CommandEnum_Registe,
    CommandEnum_Login,
    CommandEnum_Logout,
    CommandEnum_GroupChat,
    CommandEnum_AddFriend,
    CommandEnum_delFriend,
    CommandEnum_PrivateChat,
    CommandEnum_CreateGroup,
    CommandEnum_GetGroupList,
    CommandEnum_GetGroupInfo,
    CommandEnum_GetFriendInfo,
};
1
2
3
4
5
6
7
8
9
10
11
12
13
14

服务端通过switch匹配各个命令，进而对每个命令进行处理。

用户注册

用户注册请求，响应的数据格式如下

/**
 * @brief 注册用户信息
 */
struct RegistInfoReq{
    char m_userName[32];
    char m_password[32];
};
struct RegistInfoResp{
    int m_account;
};
1
2
3
4
5
6
7
8
9
10

在用户注册时，服务端生成一个唯一的账号发送给客户端，客户端只能通过该账号与服务端交互。

用户注册完成之后会存放在服务端的一个全局map表中,方便集中管理

typedef std::map<int,RegistInfoReq*>    mapAccountInfo;      //注册用户表
static mapAccountInfo   g_AccountInfoMap;   //注册账户信息表
1
2

用户登陆

用户登陆请求，响应的数据格式如下

struct LoginInfoReq{
    int m_account;      //账号
    char m_password[32];
};
1
2
3
4

用户登陆成功后会创建一个用户信息 UserInfo 并将该用户信息添加到全局的一个用户map表中集中管理

typedef std::map<int,UserInfo*>         mapUserInfo;          //在线用户表
static mapUserInfo      g_UserInfoMap;      //在线用户信息表
1
2

登陆成功之后发回给客户端的是一个没有负载的包，包中的error字段置0.

用户登出

客户端直接断开即可，具体登出数据格式暂未实现.

群聊

此次设计中有一个公共群聊（账号为0），所有用户都在群聊里面。

用户群聊请求，响应的数据格式如下

truct GroupChatReq
{
    int m_UserAccount;      //发送的账号
    int m_msgLen;
    int m_type;             //数据类型 0:文本,1:图片 ...
    int m_GroupAccount;     //发送群号 0:广播
};
1
2
3
4
5
6
7

看着没啥毛病但是群消息在哪？要发送的数据在哪？

还记得我们客户端封包结构：包头 + 包 +负载

负载里面包含了 数据传输格式+其他数据

在群聊请求里面有一个 m_msgLen字段用来区分消息的边界，因为客户端发送的消息是不定长的，所以需要这么一个字段来区分消息的边界。

私聊

用户私聊请求，响应的数据格式如下

struct PrivateChatReq
{
    int m_UserAccount;      //发送的账号
    int m_msgLen;
    int m_type;             //数据类型 0:文本,1:图片 ...
    int m_FriendAccount;    //发送好友账号
};
1
2
3
4
5
6
7

跟群聊类似，其实这两个数据格式可以用同一个。

添加好友

用户添加好友请求，响应的数据格式如下

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
};
1
2
3
4
5
6
7
8
9
10
11
12

添加好友的流畅比较复杂，我在设计的时候也卡了一下。

主要流程如图

1. 客户端A给服务器发送添加好友的请求 AddFriendInfoReq,服务器解析请求将B的信息添加到客户端A的好友表中。
2. 服务器B给客户端B转发好友请求。
3. 客户端B同意或者拒绝，给服务器发送添加好友的响应 AddFriendInfoResp，服务器解析请求将A的信息添加到客户端B的好友表中，将客户端A的好友表中属于客户端B的好友状态字段m_status置1或0。

获取好友信息

用户获取好友信息请求，响应的数据格式如下

/*  好友请求接口封装  */
struct GetFriendInfoResp
{
    int m_size;         //群成员大小
};
struct FriendInfo{
    char m_userName[32];//好友用户名
    int  m_account;     //账号
    int  m_status;      //是否添加成功 0:等待添加   1：同意
};
1
2
3
4
5
6
7
8
9
10

这里大伙可能有点蒙了，又是包头，又是包，又是负载的，拿着数据格式到底属于那块的

其实数据格式（例如GetFriendInfoResp结构体）和数据都属于负载里面的,如图所示。

对于通信协议为二进制的协议来说，解析起来效率是最快的。

获取群列表

用户获取群列表信息请求，响应的数据格式如下

struct GetGroupListResp
{
    int m_size;             //群数量大小
};
struct GroupChatInfo
{
    char m_groupName[32]; //群名称
    int  m_account;       //群账号
    int  m_size;          //群大小
};
1
2
3
4
5
6
7
8
9
10

数据的传输同获取好友信息，在这里群列表也有一个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:群主
};
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

这里的数据传输和获取好友信息一样。

到这里我们的服务端介绍完了，比较复杂，但是知识点超多。客户端设计相对容易些，但是我感觉单纯的终端客户端太掉逼格了，就又写个一个qt的客户端，重温了一边qt的UI设计，简直不要太爽，qt的客户端设计会另外再补一篇文章。

github源码

chat_room:https://github.com/ADeRoy/chat_room

欢迎慷慨 star

熬夜写的文章，想要鸡腿…