Jack Jiang

我的最新工程MobileIMSDK:http://git.oschina.net/jackjiang/MobileIMSDK
posts - 467, comments - 13, trackbacks - 0, articles - 0

本文由融云技术团队分享,原题“互联网通信安全之端到端加密技术”,内容有修订和改动。

1、引言

随着移动互联网的普及,IM即时通讯类应用几乎替代了传统运营商的电话、短信等功能。得益于即时通讯技术的实时性优势,使得人与人之间的沟通和交流突破了空间、时间等等限制,让信息的传递变的无处不在。

但互联网为我们的生活带来极大便利的同时,用户的隐私和通信安全问题也随之而来。

对于IM应用开发者来说,信息沟通的开放性也意味着风险性,用户与网络和移动设备的高度依赖,也为不法之徒提供了可乘之机。因此,提升即时通讯应用的安全性尤其重要。

本篇文章将围绕IM通信连接层的安全问题及实现方案,聚焦IM网络“链路安全”,希望能带给你启发。

学习交流:

本文已同步发布于:http://www.52im.net/thread-4015-1-1.html

2、系列文章

本文是IM通讯安全知识系列文章中的第10篇,此系列总目录如下:

3、即时通讯面临的安全问题

1)窃取内容:如果在整个即时通讯的通信过程中,其数据内容是未加密或弱加密的,那么其信息被截获后就可以直接被读取出来。

那么,这就会导致用户数据(包括个人隐私数据)的泄露,甚至可能危害用户的财产安全(比如微信这类IM中,红包、钱包都会涉及财产安全)。如果在办公场景下,被窃取的还可能是公司商业机密,那势必将会造成更大的经济损失。

2)篡改内容:如果通信内容被截获后,对其进行修改再发送,会破坏信息的正确性和完整性(此消息已非彼消息)。

3)伪造内容:如果用户通信凭证(比如token)被窃取或在通信过程中穿插其他信息,就可能为冒用用户身份骗取与之通信者的信任创造可能,埋下更大的安全隐患。

4)传播不法内容:基于即时通讯系统的消息推送能力,不法分子除了可能传播涉黄、涉赌、暴恐或危害国家安全的信息外,还可能传播计算机木马病毒等,可能带来的危害范围将进一步扩大。

4、常用的互联网攻击手段

网络通信过程中常见的攻击手段:

1)移植木马:过在终端移植木马,截获或篡改信息。

2)伪造应用:通过伪造 APP 或在 APP 中添加后门等方式,使终端用户误以为是正常应用进行使用,从而达到其不法目的。

3)网络抓包:通过在网络设备上进行抓包,获取用户通信内容。

4)中间人攻击:通过劫持 DNS 等手段,使用户通信连接经过攻击者的设备,从而达到窃取、篡改等目的。

5)漏洞挖掘:服务端或终端除了自有的程序以外还包含了各种三方组件或中间件,通过挖掘其上的漏洞,达到不法目的。

从上图和手段可知,聊天信息从应用经过网络到达服务端,这期间的任何一个环节都有可能被人利用。所以,在“危机四伏”的互联网络通信中,“安全”必须重视。

5、密码学在即时通讯系统中的应用

5.1 基本常识

针对前述的安全问题和攻击手段,将密码学应用在即时通讯系统连接上,对通信数据进行加密就变得尤为重要。

密码学解决信息安全的三要素(CIA)即:

  • 1)机密性(Confidentiality):保证信息不泄露给未经授权的用户;
  • 2)完整性(Integrity):保证信息从真实的发信者传送到真实的收信者手中,传送过程中没有被非法用户添加、删除、替换等;
  • 3)可用性(Availability):保证授权用户能对数据进行及时可靠的访问。

以上表述,好像有点绕口,我们换个通俗一点的表述。。。

密码学在网络通信中的三大作用就是:

  • 1)加密:防止坏人获取你的数据;
  • 2)认证:防止坏人修改了你的数据而你却并没有发现;
  • 3)鉴权:防止坏人假冒你的身份。

除 CIA 外,还有一些属性也是要求达到的,如可控性(Controllability)和不可否认性(Non-Repudiation)。

5.2 在即时通讯中的应用

作为即时通讯中的关键组成,IM即时通讯系统为了实现消息的快速、实时送达,一般需要客户端与服务器端建立一条socket长连接,用以快速地将消息送达到客户端。

通常即时通讯客户端会以 TCP 或 UDP 的方式与服务器建立连接,同时某些场景下也会使用 HTTP 的方式从服务器获取或提交一些信息。

整个过程中所有的数据都需进行加密处理,简单的数据加密和解密过程可以归纳为:发送方输入明文 -> 加密 -> 生成密文 -> 传输密文 -> 接收方解密 -> 得到明文。

这其中,会涉及:

这其中,我国也有一套自有的密码算法(国密算法):国密算法,即国家商用密码算法,是由国家密码管理局认定和公布的密码算法标准及其应用规范,其中部分密码算法已经成为国际标准。如 SM 商用系列密码:对称加密算法 SM4、非对称加密算法 SM2、信息摘要算法 SM3。

6、通信连接层的会话加密

对于连接层面(链路层面)面的加密,应最先考虑的是基于 SSL/TLS 协议进行链路加密(比如微信的作法:《微信新一代通信安全解决方案:基于TLS1.3的MMTLS详解》),这是现代网络通信安全的基石。

很多人认为 SSL/TLS 协议是附加在 HTTP 协议上的,是 HTTPS 的一部分(详见《为什么要用HTTPS?深入浅出,探密短连接的安全性》)。

其实这种理解不完全正确,SSL/TLS 是独立于应用层协议的,高层协议可以透明地分布在 SSL/TLS 协议上面。因此基于socket长连接的IM即时消息通讯协议也可以构建在 SSL/TLS 协议上面。

SSL/TLS 是独立于应用层协议:

SSL/TLS 可以被简单地归纳为:利用基于公私钥体系的非对称加密算法,传输对称加解密算法的密钥,并将后续通讯的数据包基于双方相同的对称加解密算法和密钥进行加密并传输,从而达到保证数据安全通讯的目的。

非对称加密算法里面的公钥和私钥在数学上是相关的,这样才能用一个加密、用另一个解密。不过,尽管是相关的,但以现有的数学算法,是没有办法从一个密钥算出另一个密钥。

另外需要着重强调的是:在系统中不要使用自签证书,而要使用具备 CA 认证的证书,这样可以有效的防止中间人攻击。

7、基于SSL/TLS的通信连接层如何实现会话的快速恢复

7.1 概述

客户端和服务器端建立 SSL/TLS 握手时,需要完成很多步骤:密钥协商出会话密钥、数字签名身份验证、消息验证码 MAC 等。

整个握手阶段比较耗时的是密钥协商,需要密集的 CPU 处理。当客户端和服务器断开了本次会话连接,那么它们之前连接时协商好的会话密钥就消失了。在下一次客户端连接服务器时,便要进行一次新的完整的握手阶段。

这似乎没什么问题,但是当系统中某一时间段里有大量的连接请求提交时,就会占用大量服务器资源,导致网络延迟增加。

为了解决上面的问题,TLS/SSL 协议中提供了会话恢复的方式,允许客户端和服务器端在某次关闭连接后,下一次客户端访问时恢复上一次的会话连接。

会话恢复有两种:

  • 1)一种是基于 Session ID 的恢复;
  • 2)一种是使用 Session Ticket TLS 扩展。

下面来看看两种方式的优劣。

7.2 基于Session ID的SSL/TLS长连接会话恢复

一次完整的握手阶段结束后,客户端和服务器端都保存有这个 Session ID。

在本次会话关闭,下一次再次连接时:客户端在 Client Hello 子消息中附带这个 Session ID 值,服务器端接收到请求后,将 Session ID 与自己在 Server Cache 中保存的 Session ID 进行匹配。

如果匹配成功:服务器端就会恢复上一次的 TLS 连接,使用之前协商过的密钥,不重新进行密钥协商,服务器收到带 Session ID 的 Client Hello 且匹配成功后,直接发送 ChangeCipherSpec 子协议,告诉 TLS 记录层将连接状态切换成可读和可写,就完成会话的恢复。

基于Session ID 会话恢复原理:

虽然使用 Session ID 进行会话恢复可以减少耗时的步骤,但由于 Session ID 主要保存在服务器 Server Cache 中,若再次连接请求时由于负载均衡设定将请求重定位到了其他服务器上,此时新的服务器 Server Cache 中没有缓存与客户端匹配的 Session ID,会导致会话无法恢复无法进行,因此不建议选用  Session ID 方式进行会话恢复。

7.3 基于SessionTicket的SSL/TLS长连接会话恢复

一次完整的握手过程后,服务器端将本次的会话数据(会话标识符、证书、密码套件和主密钥等)进行加密,加密后生成一个 ticket ,并将 ticket 通过 NewSessionTicket 子消息发送给客户端,由客户端来保存,下一次连接时客户端就将 ticket 一起发送给服务器端,待服务器端解密校验无误后,就可以恢复上一次会话。

基于SessionTicket 会话恢复原理:

由于加解密都是在服务端闭环进行,多服务只需要共享密钥就可以完成此过程,相较于 Session ID 的方式,可以不依赖 Server Cache,因此 SessionTicket 会话恢复方式更有利于大型分布式系统使用。

8、本文小结

本文分享了IM即时通讯的通信连接层安全知识和加密技术等。

并着重强调了两方面内容。首先,在IM即时通讯系统中使用具备 CA 认证的 SSL/TLS 证书可以保证传输安全,防止传输过程被监听、防止数据被窃取,确认连接的真实性。其次,利用 SessionTicket 快速地进行会话恢复可以提高整体系统性能,降低连接延时。

本文的下篇《即时通讯安全篇(十一):IM聊天系统安全手段之传输内容端到端加密技术》,将继续分享基于IM传输内容的端到端加密技术,敬请关注。

9、参考资料

[1] TCP/IP详解 - 第11章·UDP:用户数据报协议

[2] TCP/IP详解 - 第17章·TCP:传输控制协议

[3] 网络编程懒人入门(三):快速理解TCP协议一篇就够

[4] 网络编程懒人入门(四):快速理解TCP和UDP的差异

[5] 零基础IM开发入门(二):什么是IM系统的实时性?

[6] 对称加密技术在Android平台上的应用实践

[7] 非对称加密技术的原理与应用实践

[8] 常用加解密算法与通讯安全讲解

[9]微信新一代通信安全解决方案:基于TLS1.3的MMTLS详解

[10] 为什么要用HTTPS?深入浅出,探密短连接的安全性

[11] 探讨组合加密算法在IM中的应用

本文已同步发布于:http://www.52im.net/thread-4015-1-1.html

posted @ 2022-08-22 11:35 Jack Jiang 阅读(123) | 评论 (0)编辑 收藏

     摘要: 本文引用自InfoQ社区“5亿用户如何高效沟通?钉钉首次对外揭秘即时消息服务DTIM”一文,作者陈万红等、策划褚杏娟,有修订和改动。一、引言本文是国内企业IM的事实王者钉钉首次对外深度解密其即时消息服务(即DingTalk IM,简称DTIM)的技术设计实践。本篇文章内容将从模型设计原理到具体的技术架构、最底层的存储模型到跨地域的单元化等,全方位展现了 DTIM 在实际生产...  阅读全文

posted @ 2022-08-15 12:32 Jack Jiang 阅读(225) | 评论 (0)编辑 收藏

     摘要: 本文由vivo互联网服务器团队李青鑫分享,有较多修订和改动。1、引言本文内容来自vivo互联网服务器团队李青鑫在“2021 vivo开发者大会”现场的演讲内容整理而成(现场演讲稿可从本文末附件中下载)。本文将要分享的是手机厂商vivo的系统级推送平台在架构设计上的技术实践和总结。这也是目前为止首次由手机厂商分享的自建系统级推送平台的技术细节,我们也得以借此机会一窥厂商ROO...  阅读全文

posted @ 2022-08-09 12:11 Jack Jiang 阅读(120) | 评论 (0)编辑 收藏

一、关于RainbowChat-Web

RainbowChat-Web是一套Web网页端IM系统,是RainbowChat的姊妹产品(RainbowChat是一套基于开源IM聊天框架 MobileIMSDK(Github地址) 的产品级移动端IM系统)。

不同于市面上某些开源或淘宝售卖的demo级代码,RainbowChat-Web的产品级代码演化自真正运营过的商业产品,其所依赖的通信层核心SDK(即MobileIMSDK-Web)已在数年内经过大量客户及其辐射的最终用户的使用和验证。

二、v4.1 版更新内容

此版更新内容更多历史更新日志):

  • 1)[bug][前端]解决了掉线后发出的消息,在被判定未送达的情况下,重连成功时会再次重发的问题(这是MobileIMSDK-Web的bug);
  • 2)[优化][前端]解决了发送的html等内容,对方显示正常,而自已这边显示不正常的问题(没被转义);
  • 3)[优化][服务端-独立交付版]解决了log4j2的两个jar包冲突导致在linux下不能正常输出log的问题;
  • 4)[优化][服务端-RainbowChatMQserver]优化了使用mysql8.0驱动时,不能正确读取SQL异常信息的问题(会报空指针异常);
  • 5)[优化][前端]解决了位置消息发送功能无法正常使用的问题(高德地图官方API升级,已适配并升级完成);
  • 6)[优化][前端]解决了位置消息查看时的地图控制工具不正常的问题(高德地图官方API升级,已适配并升级完成)。

升级后的位置消息相关功能截图(更多截图点此查看):

三、关于兼容性

截止目前:RainbowChat-Web努力保证在各主流系统、主流浏览器、不同分辨率屏幕上的一致体验,包括但不限于:Chrome、Safari、FireFox、Edge、360浏览器、世界之窗浏览器等▼

▲ 在各种主流浏览器上的运行情况更多截图点此进入更多演示视频点此进入

▲ 超宽屏上的显示情况更多截图点此进入更多演示视频点此进入

 

▲ 不同系统、不同分辨率屏幕的真机运行情况更多截图点此进入更多演示视频点此进入) 

四、主要界面截图概览

 

▲ 主界面更多截图点此进入更多演示视频点此进入

▲ 主界面(聊天窗全屏时)更多截图点此进入更多演示视频点此进入

▲ 主界面(聊天窗关闭时)更多截图点此进入更多演示视频点此进入

posted @ 2022-08-06 12:14 Jack Jiang 阅读(120) | 评论 (0)编辑 收藏

     摘要: 本文由vivo互联网技术团队LinDu、Li Guolin分享,有较多修订和改动。1、引言IM即时消息模块是直播系统的重要组成部分,一个稳定、有容错、灵活的、支持高并发的消息模块是影响直播系统用户体验的重要因素。本文针对秀场直播,结合我们一年以来通过处理不同的业务线上问题,进行了技术演进式的IM消息模块架构的升级与调整,并据此进行了技术总结、整理成文,希望借此机会分享给大家。在目前大部分主流的直播...  阅读全文

posted @ 2022-08-01 12:37 Jack Jiang 阅读(132) | 评论 (0)编辑 收藏

本文由作者“大白菜”分享,有较多修订和改动。注意:本系列是给IM初学者的文章,IM老油条们还望海涵,勿喷!

1、引言

前两篇《编码实践篇(单聊功能)》、《编码实践篇(群聊功能)》分别实现了控制台版本的IM单聊和群聊的功能。

通过前两篇这两个小案例来体验的只是Netty在IM系统这种真实的开发实践,但对比在真实的Netty应用开发当中,本系列的案例是非常的简单的,主要目的其实是让大家可以更好地了解其原理,从而写出更高质量的 Netty 代码。

不过,虽然 Netty 的性能很高,但是也不能保证随意写出来的项目就是性能很高的,所以本篇将主要讲解几个基于Netty的IM系统的优化实战技术点。

学习交流:

本文同步发布于:http://www.52im.net/thread-3988-1-1.html

2、写在前面

建议你在阅读本文之前,务必先读本系列的前三篇《IM系统设计篇》、《编码实践篇(单聊功能)》、《编码实践篇(群聊功能)》。

最后,在开始本文之前,请您务必提前了解Netty的相关基础知识,可从本系列首篇《IM系统设计篇》中的“知识准备”一章开始。

3、系列文章

本文是系列文章的第3篇,以下是系列目录:

4、基于Netty的IM系统常见优化方向

常见优化方向脑图:

我们逐条详细解释一下这些优化的目的:

  • 1)心跳检测:主要是避免连接假死现象;
  • 2)连接断开:则删除通道绑定属性、删除对应的映射关系,这些信息都是保存在内存当中的,如果不删除则造成资源浪费;
  • 3)性能问题:用户 ID 和 Channel 的关系绑定存在内存当中,比如:Map,key 是用户 ID,value 是 Channel,如果用户量多的情况(客户端数量过多),那么服务端的内存将被消耗殆尽;
  • 4)性能问题:每次服务端往客户端推送消息,都需从Map里查找到对应的Channel,如果数量较大和查询频繁的情况下如何保证查询性能;
  • 5)安全问题:HashMap 是线程不安全的,并发情况下,我们如何去保证线程安全;
  • 6)身份校验:如何 LoginHandler 是负责登录认证的业务 Handler,AuthHandler 是负责每次请求时校验该请求是否已经认证了,这些 Handler 在链接就绪时已经被添加到 Pipeline 管道当中,其实,我们可以采用热插拔的方式去把一些在做业务操作时用不到的 Handler 给剔除掉。

以上是基于Netty的IM系统开发当中,需要去注意的技术优化点,当然还有很多其他的细节,比如:线程池这块,需要大家慢慢去从实战中积累。

5、本篇优化方向

本篇主要的优化内容主要是在第二篇单聊功能第三篇群聊功能的基础上继续完善几点。

具体的优化方向如下:

  • 1)无论客户端还是服务端都分别只有一个 Handler,这样的话,业务越来越多,Handler 里面的代码就会越来越臃肿,我们应该想办法把 Handler 拆分成各个独立的 Handler;
  • 2)如果拆分的 Handler 很多,每次有连接进来,那么都会触发 initChannel () 方法,所有的 Handler 都得被 new 一遍,我们应该把这些 Handler 改成单例模式(不需要每次都 new,提高效率);
  • 3)发送消息时,无论是单聊还是群聊,对方不在线,则把消息缓存起来,等待其上线再推送给他;
  • 4)连接断开时,无论是主动和被动,需要删除 Channel 属性、删除用户和 Channel 映射关系。

6、业务拆分以及单例模式优化

6.1 概述

主要优化细节如下:

  • 1)自定义 Handler 继承 SimpleChannelInboundHandler,那么解码的时候,会自动根据数据格式类型转到相应的 Handler 去处理;
  • 2)@Shareable 修饰 Handler,保证 Handler 是可共享的,避免每次都创建一个实例。

6.2 登录Handler优化

@ChannelHandler.Sharable

public class ClientLogin2Handler extends SimpleChannelInboundHandler<LoginResBean> {

    //1.构造函数私有化,避免创建实体

    private ClientLogin2Handler(){}

    //2.定义一个静态全局变量

    public static ClientLogin2Handler instance=null;

    //3.获取实体方法

    public static ClientLogin2Handler getInstance(){

        if(instance==null){

            synchronized(ClientLogin2Handler.class){

                if(instance==null){

                    instance=new ClientLogin2Handler();

                }

            }

        }

        return instance;

    }

 

    protected void channelRead0(

        ChannelHandlerContext channelHandlerContext,

        LoginResBean loginResBean) throws Exception {

 

        //具体业务代码,参考之前

    }

}

6.3 消息发送Handler优化

@ChannelHandler.Sharable

public class ClientMsgHandler extends SimpleChannelInboundHandler<MsgResBean> {

    //1.构造函数私有化,避免创建实体

    private ClientMsgHandler(){}

    //2.定义一个静态全局变量

    public static ClientMsgHandler instance=null;

    //3.获取实体方法

    public static ClientMsgHandler getInstance(){

        if(instance==null){

            synchronized(ClientMsgHandler.class){

                if(instance==null){

                    instance=new ClientMsgHandler();

                }

            }

        }

        return instance;

    }

 

    protected void channelRead0(

        ChannelHandlerContext channelHandlerContext,

        MsgResBean msgResBean) throws Exception {

 

        //具体业务代码,参考之前

    }

}

6.4 initChannel方法优化

.handler(newChannelInitializer<SocketChannel>() {

    @Override

    public void initChannel(SocketChannel ch) {

        //1.拆包器

        ch.pipeline().addLast(new LengthFieldBasedFrameDecoder(Integer.MAX_VALUE,5,4));

        //2.解码器

        ch.pipeline().addLast(new MyDecoder());

        //3.登录Handler,使用单例获取

        ch.pipeline().addLast(ClientLogin2Handler.getInstance());

        //4.消息发送Handler,使用单例获取

        ch.pipeline().addLast(ClientMsgHandler.getInstance());

        //5.编码器

        ch.pipeline().addLast(new MyEncoder());

    }

});

6.5 小结

这种业务拆分以及单例模式优优化是Netty开发当中很常用的,可以更好的维护基于Netty的代码并提高应用性能。

7、数据缓存优化

为了提高用户体验,在发送消息(推送消息)时,如果接收方不在线,则应该把消息缓存起来,等对方上线时,再推送给他。

7.1 数据缓存到集合

//1.定义一个集合存放数据(真实项目可以存放数据库或者redis缓存),这样数据比较安全。

private List<Map<Integer,String>> datas=new ArrayList<Map<Integer,String>>();

 

//2.服务端推送消息

private void pushMsg(MsgReqBean bean,Channel channel){

    Integer touserid=bean.getTouserid();

    Channel c=map.get(touserid);

 

    if(c==null){//对方不在线

        //2.1存放到list集合

        Map<Integer,String> data=new HashMap<Integer, String>();

        data.put(touserid,bean.getMsg());

        datas.add(data);

 

        //2.2.给消息“发送人”响应

        MsgResBean res=new MsgResBean();

        res.setStatus(1);

        res.setMsg(touserid+">>>不在线");

        channel.writeAndFlush(res);

 

    }else{//对方在线

        //2.3.给消息“发送人”响应

        MsgResBean res=new MsgResBean();

        res.setStatus(0);

        res.setMsg("发送成功);

        channel.writeAndFlush(res);

 

        //2.4.给接收人推送消息

        MsgRecBean res=new MsgRecBean();

        res.setFromuserid(bean.getFromuserid());

        res.setMsg(bean.getMsg());

        c.writeAndFlush(res);

    }

}

7.2 上线推送

private void login(LoginReqBean bean, Channel channel){

    Channel c=map.get(bean.getUserid());

    LoginResBean res=new LoginResBean();

    if(c==null){

        //1.添加到map

        map.put(bean.getUserid(),channel);

        //2.给通道赋值

        channel.attr(AttributeKey.valueOf("userid")).set(bean.getUserid());

        //3.登录响应

        res.setStatus(0);

        res.setMsg("登录成功");

        res.setUserid(bean.getUserid());

        channel.writeAndFlush(res);

 

        //4.根据user查找是否有尚未推送消息

        //思路:根据userid去lists查找.......

 

    }else{

        res.setStatus(1);

        res.setMsg("该账户目前在线");

        channel.writeAndFlush(res);

    }

}

8、连接断开事件处理优化

如果客户端网络故障导致连接断开了(非主动下线),那么服务端就应该能监听到连接的断开,且此时应删除对应的 map 映射关系。但是映射关系如果没有删除掉,将导致服务器资源没有得到释放,进而影响客户端的下次同一个账号登录以及大量的客户端掉线时性能。

8.1 正确写法

实例:

public class ServerChatGroupHandler extends ChannelInboundHandlerAdapter {

    //映射关系

    private static Map<Integer, Channel> map=new HashMap<Integer, Channel>();

    //连接断开,触发该事件

    @Override

    public void channelInactive(ChannelHandlerContext ctx) throws Exception {

        //1.获取Channel

        Channel channel=ctx.channel();

 

        //2.从map里面,根据Channel找到对应的userid

        Integer userid=null;

        for(Map.Entry<Integer, Channel> entry : map.entrySet()){

            Integer uid=entry.getKey();

            Channel c=entry.getValue();

            if(c==channel){

                userid=uid;

            }

        }

        //3.如果userid不为空,则需要做以下处理

        if(userid!=null){

            //3.1.删除映射

            map.remove(userid);

            //3.2.移除标识

            ctx.channel().attr(AttributeKey.valueOf("userid")).remove();

        }

    }

}

8.2 错误写法

Channel 断开,服务端监听到连接断开事件,但是此时 Channel 所绑定的属性已经被移除掉了,因此这里无法直接获取的到 userid。

实例:

public class ServerChatGroupHandler extends ChannelInboundHandlerAdapter {

    //映射关系

    private static Map<Integer, Channel> map=new HashMap<Integer, Channel>();

 

    //连接断开,触发该事件

    @Override

    public void channelInactive(ChannelHandlerContext ctx) throws Exception {

        //1.获取Channel绑定的userid

        Object userid=channel.attr(AttributeKey.valueOf("userid")).get();

 

        //2.如果userid不为空

        if(userid!=null){

            //1.删除映射

            map.remove(userid);

            //2.移除标识

            ctx.channel().attr(AttributeKey.valueOf("userid")).remove();

        }

    }

}

9、本篇小结

本篇内容还是相对容易理解的,主要是优化前面两篇实现的IM聊天功能,优化内容是业务 Handler 的拆分以及使用单例模式、接受人不在线则缓存数据、等其上线再推送、监听连接断开删除对应的映射关系。

限于篇幅,本系列文章文章没办法真正讲解开发一个完整IM系统所涉及的方方面面,如果有兴趣,可以继续阅读更有针对性的IM开发文章,比如IM架构设计IM通信协议IM通信安全群聊优化弱网优化网络保活等。

10、参考资料

[1] 新手入门:目前为止最透彻的的Netty高性能原理和框架架构解析

[2] 理论联系实际:一套典型的IM通信协议设计详解

[3] 浅谈IM系统的架构设计

[4] 简述移动端IM开发的那些坑:架构设计、通信协议和客户端

[5] 一套海量在线用户的移动端IM架构设计实践分享(含详细图文)

[6] 一套原创分布式即时通讯(IM)系统理论架构方案

[7]  一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践

[8] 一套亿级用户的IM架构技术干货(上篇):整体架构、服务拆分等

[9] 从新手到专家:如何设计一套亿级消息量的分布式IM系统

[10] 基于实践:一套百万消息量小规模IM系统技术要点总结

[11] 探探的IM长连接技术实践:技术选型、架构设计、性能优化

[12] 拿起键盘就是干,教你徒手开发一套分布式IM系统

[13] 万字长文,手把手教你用Netty打造IM聊天

[14] 基于Netty实现一套分布式IM系统

[15] SpringBoot集成开源IM框架MobileIMSDK,实现即时通讯IM聊天功能

本文同步发布于:http://www.52im.net/thread-3988-1-1.html

posted @ 2022-07-25 12:02 Jack Jiang 阅读(129) | 评论 (0)编辑 收藏

一、更新内容简介

本次更新为次要版本更新,进行了若干优化(更新历史详见:码云 Release Nodes)。可能是市面上唯一同时支持 UDP+TCP+WebSocket 三种协议的同类开源IM框架。

二、MobileIMSDK简介

MobileIMSDK 是一套专为移动端开发的原创IM通信层框架:

  • 历经8年、久经考验;
  • 超轻量级、高度提炼,lib包50KB以内;
  • 精心封装,一套API同时支持UDP、TCP、WebSocket三种协议(可能是全网唯一开源的);
  • 客户端支持 iOSAndroid标准JavaH5小程序(开发中..)、Uniapp(开发中..);
  • 服务端基于Netty,性能卓越、易于扩展;👈
  • 可与姊妹工程 MobileIMSDK-Web 无缝互通实现网页端聊天或推送等;👈
  • 可应用于跨设备、跨网络的聊天APP、企业OA、消息推送等各种场景。

MobileIMSDK工程始于2013年10月,起初用作某产品的即时通讯底层实现,完全从零开发,技术自主可控!

您可能需要:查看关于MobileIMSDK的详细介绍

三、代码托管同步更新

OsChina.net

GitHub.com

四、MobileIMSDK设计目标

让开发者专注于应用逻辑的开发,底层复杂的即时通讯算法交由SDK开发人员,从而解偶即时通讯应用开发的复杂性。

五、MobileIMSDK框架组成

整套MobileIMSDK框架由以下5部分组成:

  1. Android客户端SDK:用于Android版即时通讯客户端,支持Android 2.3及以上,查看API文档
  2. iOS客户端SDK:用于开发iOS版即时通讯客户端,支持iOS 8.0及以上,查看API文档
  3. Java客户端SDK:用于开发跨平台的PC端即时通讯客户端,支持Java 1.6及以上,查看API文档
  4. H5客户端SDK:暂无开源版,查看精编注释版
  5. 服务端SDK:用于开发即时通讯服务端,支持Java 1.7及以上版本,查看API文档

整套MobileIMSDK框架的架构组成:

 另外:MobileIMSDK可与姊妹工程 MobileIMSDK-Web 无缝互通,从而实现Web网页端聊天或推送等。

六、MobileIMSDK v6.2更新内容 

【重要说明】:

MobileIMSDK v6.2 为次要版本,进行了若干优化! 查看详情

【新增的特性】:

  1. [服务端] 新增两个聊天消息前置处理回调,方便开发者进行内容鉴黄、过滤、修改等运营管理;
  2. [服务端] 新增新增了一个与 Web 互通情况下的 C2C 模式回调,用于开发者在互通模式下实现离线消息 Push 逻辑;

【其它优化和提升】:

  1. [Andriod] 支持最新的 Andriod 12,解决了 Demo 工程中的 Andriod12 兼容问题;
  2. [Andriod] 解决了 Demo 工程在最新 Android Studio 编译时报方法数超过 65535 的经典问题;
  3. [服务端] 升级 log4j2 至 2.17.0,解决 Log4j2 远程代码执行高危漏洞;
  4. [服务端] 为 ServerEventListener 类中的 onUserLogout 回调增加 beKickoutCode 参数;
  5. [服务端] [优化] 尝试解决与 Web 互通情况下,MQProvider 中的 work 方法会因异步消息导致的 AlreadCloseException 问题;

【版本地址】:

https://gitee.com/jackjiang/MobileIMSDK/releases/6.2

posted @ 2022-07-20 10:29 Jack Jiang 阅读(96) | 评论 (0)编辑 收藏

     摘要: 本文由作者“大白菜”分享,有较多修订和改动。注意:本系列是给IM初学者的文章,IM老油条们还望海涵,勿喷!1、引言接上两篇《IM系统设计篇》、《编码实践篇(单聊功能)》,本篇主要讲解的是通过实战编码实现IM的群聊功能,内容涉及群聊技术实现原理、编码实践等知识。学习交流:- 移动端IM开发入门文章:《新手入门一篇就够:从零开发移动端IM》- 开源IM框架源码:https://...  阅读全文

posted @ 2022-07-18 15:06 Jack Jiang 阅读(108) | 评论 (0)编辑 收藏

     摘要: 本文由作者“大白菜”分享,个人博客 cmsblogs.cn,有较多修订和改动。注意:本系列是给IM初学者的文章,IM老油条们还望海涵,勿喷!1、引言接上篇《IM系统设计篇》,本篇主要讲解的是通过实战编码实现IM的单聊功能,内容涉及技术原理、编码实践。补充说明:因为本系列文章主要目的是引导IM初学者在基于Netty的情况下,如何一步一步从零写出IM的逻辑和思维能力,因而为了简...  阅读全文

posted @ 2022-07-11 11:39 Jack Jiang 阅读(103) | 评论 (0)编辑 收藏

本文收作者“大白菜”分享,有改动。注意:本系列是给IM初学者的文章,IM老油条们还望海涵,勿喷!

1、引言

这又是一篇基于Netty的IM编码实践文章,因为合成一篇内容太长,读起来太累,所以也就顺着作者的思路分开成4篇,读起来心理压力也就没那么大了。

这个系列的几篇文章分享的是:假设在没有任何成型的第3方IM库或SDK的情况下,以网络编程的基础技术视野,思考和实践如何基于Netty网络库从零写一个可以聊天的IM系统的过程,没有眼花缭乱的架构设计、也没有高端大气的模式设计方法论,有的只是从IM入门者的角度的思路和实战,适合IM初学者阅读。

本篇主要是徒手撸IM系列的开篇,主要讲解的是的IM设计思路,不涉及实践编码,希望给你带来帮助。

学习交流:

本文已同步发布于:http://www.52im.net/thread-3963-1-1.html

2、知识准备

* 重要提示:本系列文章主要是代码实战分享,如果你对即时通讯(IM)技术理论了解的不多,建议先详细阅读:《零基础IM开发入门:什么是IM系统?》、《新手入门一篇就够:从零开发移动端IM》。

不知道 Netty 是什么?这里简单介绍下:

Netty 是一个 Java 开源框架。Netty 提供异步的、事件驱动的网络应用程序框架和工具,用以快速开发高性能、高可靠性的网络服务器和客户端程序。

也就是说,Netty 是一个基于 NIO 的客户、服务器端编程框架,使用Netty 可以确保你快速和简单的开发出一个网络应用,例如实现了某种协议的客户,服务端应用。

Netty 相当简化和流线化了网络应用的编程开发过程,例如,TCP 和 UDP 的 Socket 服务开发。

Netty的基础入门好文章:

如果你连Java的NIO都不知道是什么,下面的文章建议优先读:

Netty源码和API的在线查阅地址:

3、系列文章

本文是系列文章的第1篇,以下是系列目录:

  1. 基于Netty,徒手撸IM(一):IM系统设计篇》(* 本文
  2. 《基于Netty,徒手撸IM(二):编码实践篇(单聊功能)》
  3. 《基于Netty,徒手撸IM(三):编码实践篇(群聊功能)》
  4. 《基于Netty,徒手撸IM(一):编码实践篇(系统优化)》

4、需求分析

业务场景: 本次实战就是模拟微信的IM聊天,每个客户端和服务端建立连接,并且可以实现点对点通信(单聊),点对多点通信(群聊)。

设计思路: 我们要实现的是点(客户端)对点(客户端)的通讯,但是我们大部分情况下接触的业务都是客户端和服务端之间的通讯(所谓的C/S模式?),客户端只需要知道服务端的 IP 地址和端口号即可发起通讯了。那么客户端和客户端应该怎么去设计呢?

技术思考:难道是手机和手机之间建立通讯连接(所谓的P2P),互相发送消息吗?

这种方案显然不是很好的方案:

  • 1)首先: 客户端和客户端之间通讯,首先需要确定对方的 IP 地址和端口号,显然不是很现实;
  • 2)其次: 即使有办法拿到对方的 IP 地址和端口号,那么每个点(客户端)既作为服务端还得作为客户端,无形之中增加了客户端的压力。

其实:我们可以使用服务端作为IM聊天消息的中转站,由服务端主动往指定客户端推送消息。如果是这种模式的话,那么 Http 协议是无法支持的(因为Http 是无状态的,只能一请求一响应的模式),于是就只能使用 TCP 协议去实现了。

Jack Jiang注:此处作者表述不太准确,因为虽然HTTP是无状态的,但一样可以实现即时通讯能力,有兴趣的读者可以阅读以下几篇文章,了解一下这些曾经利用HTTP实现即时通讯聊天的技术方法:

  1. 新手入门贴:史上最全Web端即时通讯技术原理详解
  2. Web端即时通讯技术盘点:短轮询、Comet、Websocket、SSE
  3. 网页端IM通信技术快速入门:短轮询、长轮询、SSE、WebSocket

5、IM单聊思路设计

5.1 通讯架构原理

以下是通讯架构原理图:

 

如上图所示,通讯流程解析如下:

  • 1)实现客户端和客户端之间通讯,那么需要使用服务端作为通讯的中转站,每个客户端都必须和服务端建立连接;
  • 2)每个客户端和服务端建立连接之后,服务端保存用户 ID 和通道的映射关系,其中用户 ID 作为客户端的唯一标识;
  • 3)客户端 A 往客户端 B 发送消息时,先把消息发送到服务端,再有服务端往客户端 B 进行推送。

针对上述第“3)”点,服务端如何找到客户端 B 呢?

客户端 A 往服务端发送消息时,消息携带的信息有:“客户端 A 用户 ID”、“客户端 B 用户 ID”、“消息内容”。这样服务端就能顺利找到服务端 B 的通道并且进行推送消息了。

5.2 消息推送流程

每个客户端和服务端建立连接的时候,必须把个人用户信息上传到服务端,由服务端统一保存映射关系。如果某个客户端下线了,则服务端监听到连接断开,删除对应的映射关系。

其次:发起群聊的时候,需要传递 touser 字段,服务端根据该字段在映射表里面查找到对应的连接通道并发起消息推送。

上述逻辑原理如下图所示:

5.3 更多的细节

其实在真正要做IM之前,要考虑的技术细节还是很多的,以下这几篇文章就步及到了典型的几个IM热门技术点,有兴趣的一定要读一读:

  1. 移动端IM开发需要面对的技术问题
  2. 谈谈移动端 IM 开发中登录请求的优化
  3. IM消息送达保证机制实现(一):保证在线实时消息的可靠投递
  4. IM消息送达保证机制实现(二):保证离线消息的可靠投递
  5. 如何保证IM实时消息的“时序性”与“一致性”?

6、IM群聊思路设计

群聊指的是一个组内多个用户之间的聊天,一个用户发到群组的消息会被组内任何一个成员接收 。

具体架构思路如下所示:

如上图所示,群聊通讯流程解析如下。

1)群聊其实和单聊整体上思路都是一致的,都是需要保存每个用户和通道的对应关系,方便后期通过用户 ID 去查找到对应的通道,再跟进通道推送消息。

2)如何把消息发送给多个组内的成员呢?

其实很简单,服务端再保存另外一份映射关系,那就是聊天室和成员的映射关系。发送消息时,首先根据聊天室 ID 找到对应的所有成员,然后再跟进各个成员的 ID 去查找到对应的通道,最后由每个通道进行消息的发送。

3)成员加入某个群聊组的时候,往映射表新增一条记录,如果成员退群的时候则删除对应的映射记录。

通过上面的架构图可以发现,群聊和单聊相比,其实就是多了一份映射关系而已。

其实群聊是IM里相对来说技术难度较高的功能,有兴趣的读者可以阅读下面这几篇:

  1. IM单聊和群聊中的在线状态同步应该用“推”还是“拉”?
  2. IM群聊消息如此复杂,如何保证不丢不重?
  3. 移动端IM中大规模群消息的推送如何保证效率、实时性?
  4. 现代IM系统中聊天消息的同步和存储方案探讨
  5. 关于IM即时通讯群聊消息的乱序问题讨论
  6. IM群聊消息的已读回执功能该怎么实现?
  7. IM群聊消息究竟是存1份(即扩散读)还是存多份(即扩散写)?
  8. 一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践

另外,对于超大规模群聊,技术难度更是指数上升:

  1. 网易云信技术分享:IM中的万人群聊技术方案实践总结
  2. 阿里钉钉技术分享:企业级IM王者——钉钉在后端架构上的过人之处
  3. IM群聊消息的已读未读功能在存储空间方面的实现思路探讨
  4. 企业微信的IM架构设计揭秘:消息模型、万人群、已读回执、消息撤回等
  5. 融云IM技术分享:万人群聊消息投递方案的思考和实践
  6. 微信直播聊天室单房间1500万在线的消息架构演进之路

7、本文小结

本篇主要是帮助读者掌握单聊和群聊的核心设计思路。

单聊: 主要是服务器保存了一份用户和通道之间的映射关系,发送消息的时候,根据接收人 ID 找到其对应的通道 Channel,Channel 的 write () 可以给客户端发送消息。

群聊: 保存两份关系,分别是用户 ID 和 Channel 之间的关系、群组 ID 和用户 ID 的关系。推送消息的时候,首先根据聊天组 ID 找到其对应的成员,遍历每个成员再进行找出其对应的通道即可。

整体来说,思路还是很简单的,掌握了该设计思路以后,你会发现设计一款 IM 聊天软件其实也不是很复杂。

8、相关文章

如果你觉得对本系列文章还不够详细,可以系统学习以下系列文章:

  1. 跟着源码学IM(一):手把手教你用Netty实现心跳机制、断线重连机制
  2. 跟着源码学IM(二):自已开发IM很难?手把手教你撸一个Andriod版IM
  3. 跟着源码学IM(三):基于Netty,从零开发一个IM服务端
  4. 跟着源码学IM(四):拿起键盘就是干,教你徒手开发一套分布式IM系统
  5. 跟着源码学IM(五):正确理解IM长连接、心跳及重连机制,并动手实现
  6. 跟着源码学IM(六):手把手教你用Go快速搭建高性能、可扩展的IM系统
  7. 跟着源码学IM(七):手把手教你用WebSocket打造Web端IM聊天
  8. 跟着源码学IM(八):万字长文,手把手教你用Netty打造IM聊天
  9. 跟着源码学IM(九):基于Netty实现一套分布式IM系统
  10. 跟着源码学IM(十):基于Netty,搭建高性能IM集群(含技术思路+源码)
  11. SpringBoot集成开源IM框架MobileIMSDK,实现即时通讯IM聊天功能

9、参考资料

[1] 新手入门:目前为止最透彻的的Netty高性能原理和框架架构解析

[2] 理论联系实际:一套典型的IM通信协议设计详解

[3] 浅谈IM系统的架构设计

[4] 简述移动端IM开发的那些坑:架构设计、通信协议和客户端

[5] 一套海量在线用户的移动端IM架构设计实践分享(含详细图文)

[6] 一套原创分布式即时通讯(IM)系统理论架构方案

[7]  一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践

[8] 一套亿级用户的IM架构技术干货(上篇):整体架构、服务拆分等

[9] 一套亿级用户的IM架构技术干货(下篇):可靠性、有序性、弱网优化等

[10] 从新手到专家:如何设计一套亿级消息量的分布式IM系统

[11] 基于实践:一套百万消息量小规模IM系统技术要点总结

[12] 探探的IM长连接技术实践:技术选型、架构设计、性能优化

本文已同步发布于:http://www.52im.net/thread-3963-1-1.html

posted @ 2022-07-04 18:38 Jack Jiang 阅读(164) | 评论 (0)编辑 收藏

仅列出标题
共47页: First 上一页 14 15 16 17 18 19 20 21 22 下一页 Last 
Jack Jiang的 Mail: jb2011@163.com, 联系QQ: 413980957, 微信: hellojackjiang