2023年12月14日 随笔档案 -凯发k8网页登录

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

2023年12月14日

     摘要: 本文由字节跳动技术团队杨晨曦分享,本文有修订和改动。1、引言本文将带你一起初步认识thrift的序列化协议,包括binary协议、compact协议(类似于protobuf)、json协议,希望能为你的通信协议格式选型带来参考。  技术交流:- 移动端im开发入门文章:《新手入门一篇就够:从零开发移动端im》- 开源im框架源码:https://github.com/jackj...  阅读全文

posted @ 2023-12-28 10:52 jack jiang 阅读(13) | 评论 (0)编辑 收藏

为了更好地分类阅读 52im.net 总计1000多篇精编文章,我将在每周三推送新的一期技术文集,本次是第29 期。

[- 1 -] 

[链接] 

[摘要] 到底是“登陆”还是“登录”?这是很多处女坐开发者纠结的问题,不过它不是本文本讨伦的内容。本文将针对移动端im的登陆功能给出相应的优化建议。


[- 2 -] 

[链接] 

[摘要] 移动网络时代,手机的流量是个很昂贵的资源(至少暂时是这样)。一个典型的移动端im在登录后,往往要向服务器同步非常多的数据,如果处理的不好是很费流量的,那么从技术上来讲,有没有节省流量的方法呢?这就是本文要讨论的话题。


[- 3 -] 

[链接] 

[摘要] 本文将展开聊聊移动端im“多点登陆”与“消息漫游”的原理。


[- 4 -]

[链接] 

[摘要] 如何设计好这个失败重试的机制,使得客户端能做好失败重试,服务器有能够排除这种重复消息,但是排重处理不太复杂?


[- 5 -] 

[链接] 

[摘要] 本文将以基于tcp数据传输协议的移动端im为例,通过循序渐进地方式,分享如何构建一个基于分布式集群的移动端im接入层的设计和实现。


[- -] 

[链接] 

[摘要] 本文来自论文《微信对网络影响的技术试验及分析》,文中研究了微信对现今移动网络的影响,对于即时通讯开发人员来说,文中的某些数据和研究结果,对于实现类似的技术,有一定的参考和借鉴意义。即时通讯网(52im.net)现全文收录之。


[- 7 -] 

[链接] 

[摘要] 首先,介绍即时通信的概念、特点和技术原理,较为全面地剖析了实现即时通信系统涉及的关键技术,包括即时通信传输协议、相关安全技术和音/视频编解码技术等;其次,简要概述了即时通信系统在我校的应用情况;最后,说明当前即时通信工具存在的问题及其发展趋势。


[- 8 -] 

[链接] 

[摘要] 本文将简要介绍teamtalk开源的过去和现在,为打算研究和采用teamtalk的同行提供一定程度的参考。文中所涉及内容如有不妥,还请各位看官见谅。


[- -]  

[链接] 

[摘要] 实际在生产环境下,群消息的发送都会想尽办法进行压缩,并开展各种改善性能的处理办法,而不是像上述举例里的直接扩散写(即2000人群里,一条消息被简单地复制为2000条一对一的消息投递)。具体有哪些优先策略?本文或许可以带给你一些启发。


[- 10 -] 

[链接] 

[摘要] 关于压缩图片在诸如即时通讯应用场景下的好处,我们就不再赘述,不言自明。本篇将承接上篇《qq音乐团队分享:android中的图片压缩技术详解(上篇)》,继续讨论图片的尺寸压缩和常用的几种尺寸压缩算法。


[- 11 -] 

[链接] 

[摘要] 本文内容是由腾讯tmq专项测试团队针对手机qq图片上传速度和成功率问题,在各种复杂移动网络环境下的优化实践总结和整理而成。文章虽是针对手机qq图片上传这一特定业务功能,但内容中大量涉及复杂移动网络环境下无线网络的特性、特点以及相关第一手测试数据,都是非常珍贵的,尤其值得移动端im开发、消息推送这种深度依赖移动网络的应用开发者借鉴和参考。


[- 12 -] 

[链接] 

[摘要] 本文将给读者们一个一年多以前为公司的某产品成功优化网络流量的案例。速度、成功率与流量正好是 apps 网络优化的几大重点,希望本文我们分享的思路能够给诸位正在开展或将来会开展此类工作的读者们一些启发。


[- 13 -] 

[链接] 

[摘要] 本篇中将详细介绍我们的具体分析方法和实践优化思路,以及在优化过程中总结出来的法则等。


[- 14 -] 

[链接] 

[摘要] 本文正文内容引用了微信开发团队的资料。


[- 15 -] 

[链接] 

[摘要] 研究yelp的极致图片压缩技术,或许能给即时通讯开发者同行带来一定的借鉴意义,而这也是此文的意义所在。


[- 16 -] 

[链接] 

[摘要] 本次文章跟大家分享如何在保障质量(指的是图片质量、音视频质量)前提下所做的带宽和网络流量压缩,进而达到运营成本的优化。


[- 17 -] 

[链接] 

[摘要] 本文接上篇《腾讯技术分享:腾讯是如何大幅降低带宽和网络流量的(图片压缩篇)》,继续腾讯公司分享如何在保障质量(指的是图片质量、音视频质量)前提下所做的带宽和网络流量压缩,进而达到运营成本的优化。


[- 18 -] 

[链接] 

[摘要] 所以今天,我将尽量试着以用户的眼光,去描述这样一种现实:什么拳打qq、脚踩微信,自嗨式的创业就像浮云一样......


👉52im社区本周新文:《》,欢迎阅读!👈

我是jack jiang,我为自已带盐!https://github.com/jackjiang2011/mobileimsdk/

posted @ 2023-12-27 15:23 jack jiang 阅读(19) | 评论 (0)编辑 收藏

本文由冰河分享,作者博客 binghe.gitcode.host,原题“这套分布式im即时通讯系统如何写到简历上?我给你整理好了!”,本文有修订和改动。

分布式im即时通讯系统本质上就是对线上聊天和用户的管理。

针对聊天本身来说,最核心的需求就是:发送文字、图片、文件、语音、视频、消息缓存、消息存储、消息未读、已读、撤回,离线消息、历史消息、单聊、群聊,多端同步,以及其他一些需求。

对用户管理来说,存在的需求包含:添加好友、查看好友列表、删除好友、查看好友信息、创建群聊、加入群聊、查看群成员信息、退出群聊、修改群昵称、拉人进群、踢人出群、解散群聊、填写群公告、修改群备注以及其他用户相关的需求等。

为了更好的理解分布式im即时通讯系统的设计,我站在架构师的角度,在充分了解系统需求、业务流程和技术流程后,从全局视角为系统设定方案目标,对技术方案进行选型,对系统进行总体架构设计和分层架构设计,并梳理清楚发送消息的交互链路、单聊和群聊的交互链路。希望对你有帮助。

 
技术交流:

- 移动端im开发入门文章:《》

- 开源im框架源码:()

(本文已同步发布于:)

在进行技术选型与总体架构设计之前,需要明确一个事项,就是系统无论采用哪种方案,采用哪种架构设计都需要明确这种方案的业务目标、技术目标和架构目标,并在研发过程中不断评估系统的总体性能表现,发现系统瓶颈并不断进行优化。

总体上,我们搭建和开发的分布式im即时通讯系统,需要满足如下方案目标。

具体是:

  • 1)业务目标:满足需求设计篇章中的各类需求场景;
  • 2)技术目标:支持无限扩容,百万用户同时在线聊天;
  • 3)架构目标:高并发、高性能、高可用、可监控、可预警、可伸缩,支持无限扩展。

在技术选型上,除了采用springboot等基础框架外,也会采用容器化方案。

同时,考虑到为了尽量降低技术门槛,在整个分布式im即时通讯系统的技术选型中,主要采用市面上比较流行的技术框架和方案。

具体选型如下所示:

  • 1)开发框架:springboot、springcloud、springcloud alibaba、dubbo;
  • 2)缓存:redis分布式缓存 guava本地缓存;
  • 3)数据库:mysql、tidb、hbase;
  • 4)流量网关:openresty lua;
  • 5)业务网关:springcloud gateway sentinel;
  • 6)持久层框架:mybatis、mybatis-plus;
  • 7)服务配置、服务注册与发现:nacos;
  • 8)消息中间件:rocketmq;
  • 9)网络通信:;
  • 10)文件存储:minio;
  • 11)日志可视化治理:elk;
  • 12)容器化管理:swarm、portainer;
  • 13)监控:prometheus、grafana;
  • 14)前端:vue;
  • 15)单元测试:junit;
  • 16)基准测试:jmh;
  • 17)压力测试:jmeter。

对于im即时通讯系统来说,涵盖了即时通讯后端服务、大后端平台、sdk接入服务、openai接入服务、大前端ui,我相信不少小伙伴多多少少能够画出im即时通讯系统的架构图,大致如下图所示。

 

其实,这种这种架构设计也比较常见,在这种架构设计中,kong/openresty/nginx只做负载均衡和反向代理,研发人员更多的是关注业务层和基础层的开发,流量比较小时,这种架构设计一般不会有什么问题。但是一旦流量比较大,用户调用后端平台的接口发送消息时,即时通讯sdk同步调用即时通讯服务的接口就会出现性能问题。

因为每个终端同时只能与一个im即时通讯服务实例建立连接,如果大量的用户终端恰好都与一个im即时通讯服务建立连接,那即时通讯sdk频繁同步调用同一个im即时通讯服务的接口就会出现性能瓶颈。此时,出现性能瓶颈时,不仅仅会影响到im即时通讯服务,也会对后端平台接收请求的业务造成一定的影响。

既然上节图中所示的架构设计存在性能瓶颈,那我们如何进行优化呢?

为此我们在前图基础上进行了优化,优化后的架构如下图所示。

对比两图可以看出,在屏蔽掉技术实现细节的前提下,我们将对业务的校验和流量管控进行前置化,放大kong/openresty/nginx的职责,使得这些软件不仅具备反向代理和负载均衡的功能,还能实现限流、黑白名单、流量管控、业务校验等功能。

也就是说,在这种架构模式下,我们充分发挥了整个分布式im即时通讯系统的入口职责,充分利用kong/openresty/nginx的高并发、高吞吐量的能力,尽量将大部分无效请求挡在整个系统之外。例如,用户在没登录系统的前提下,就尝试调用发送消息、添加好友、添加群组等等接口。这样会大大减轻后台平台的业务压力。

除了在kong/openresty/nginx中实现限流、黑白名单、流量管控、业务校验等功能外,我们还引入了业务网关集群,实现限流、降级、熔断、流控、校验、鉴权等功能,进一步保证下游系统的稳定性和安全。

为了解决大量用户终端恰好连接到同一个im即时通讯服务实例,im即时通讯sdk频繁调用同一个im即时通讯服务实例的接口造成的性能问题。我们在im即时通讯服务sdk与im即时通讯服务之间引入了rocketmq集群。

im即时通讯服务集群中的每一个im即时通讯服务实例在集群中都有一个唯一的id,并且每个im即时通讯服务实例在启动后,只会监听rocketmq中与自身id相关的topic。这样每个im即时通讯服务只会收到与自身id相关的topic中的消息,不会接收所有的消息。

当用户登录系统后,就会与im即时通讯服务建立长连接,并且会以用户id和终端为key,以im即时通讯服务的id为value,将其存储到分布式缓存中。同时,会以用户id和终端为key,以用户终端与im即时通讯服务建立的长连接为value,将其存储到im即时通讯服务本地内存中。

当用户调用后端平台的接口发消息时,会带上目标用户的id,并且在im即时通讯sdk中会指定用户登录的终端设备,最终会通过im即时通讯sdk向rocketmq发送消息。

此时im即时通讯sdk会根据目标用户id和终端从分布式缓存中获取目标用户连接的im即时通讯服务的id,并向此id相关的topic发送消息。此时与目标用户建立长连接的im即时通讯服务就会接收到rocketmq中的消息,随后根据用户id和终端从本地缓存中获取到与用户终端建立的长连接,并基于此长连接向用户推送消息。

另外,在实际实现中,为了避免大量用户同时只连接im即时通讯服务集群中的某一个服务实例,会对用户连接的ip、浏览器指纹、手机设备等做hash和取模运算,使其尽量均匀分布到集群中的每一个服务实例上。

那么问题来了,这种架构设计还有进一步优化的空间吗?

为进一步增强分布式im即时通讯系统的性能、可用性和弹性伸缩能力,我们可以对分布式im即时通讯系统进行容器化架构设计,如下图所示。

可以看到,我们对分布式im即时通讯系统的架构设计进行了进一步优化,采用了容器化架构设计。在原有架构的基础上,我们进行了如下改进和优化。

1)基础支撑服务:基础支撑服务会由各种基础中间件、数据存储服务、以及监控服务实现,包含:mysql数据库、tidb数据库、hbase、redis缓存、rocketmq消息队列、prometheus监控和portainer容器管理等基础中间件实现,基础支撑服务会对整个分布式im即时通讯系统提供最基础的数据、传输、监控和容器管理等服务。

2)容器化:在容器化层面,会通过docker、swarm和portainer实现,其中,会基于swarm和portainer对容器化进行管理。

3)其他基础性功能实现:除了上述分层架构外,对于建设分布式im即时通讯系统来说,还要考虑异常监控、服务注册与发现、可视化、服务降级与兜底数据、服务限流、服务容灾、容量规划与扩缩容和全链路压测等。

在分布式im即时通讯系统中,不管是大后端平台,还是im即时通讯服务,我们都会对业务层的代码采用分层业务架构。

这里,可以借鉴ddd的分层架构思想,将代码总体上分成展示层、应用层、领域层和基础设施层四个层次。

但是,考虑到分布式im即时通讯系统的特殊性,又不会严格按照ddd的原则来设计代码分层,具体按照如下图所示。

可以看到,分布式im即时通讯系统会借鉴ddd的设计思想,但是不会完全按照ddd的方式进行设计。

1)展示层:展示层,也叫做用户ui层,是ddd设计的最上层,对外提供api接口,接收客户端请求,解析参数,返回结果数据,并对异常进行处理。

2)应用层:应用层,也叫做application层,应用层主要处理容易变化的业务场景,可对相关的事件、调度和其他聚合操作进行相关的处理。

3)领域层:领域层,也叫做domain层,领域层可以说是ddd设计的精髓所在,它是将业务系统中相对不变的部分抽象出来封装成领域模型。在分布式im即时通讯系统的设计中,领域层基本不会依赖其他层,也不会依赖基础设施层,这里是与ddd设计存在区别的地方。

4)基础设施层:基础设施层,也叫做infrastructure层,基础设施层会对其他各层提供通用的基础能力,在分布式im即时通讯系统中,就包括了缓存、通用工具类、消息、系统的持久化机制等。

在分布式im即时通讯系统中,我们忽略掉其他一些细节信息,重点关注下发送消息的交互链路逻辑。不管是单聊还是群聊,最终都需要通过im即时通讯服务将消息推送给用户的终端。此时发送消息的流程如下图所示。

可以看到:用户在分布式im即时通讯系统发送消息时,不管是单聊还是群聊,最终的消息都会推送到用户登录的终端设备上。假设此时用户a给用户b发送消息,或者用户a和用户b在同一个群组,用户a向群组发送消息,用户b接收消息的主要流程如下。

具体是:

  • 1)用户a调用后端平台的接口向用户b发送消息,并且发送的消息中会带有用户b的id以及终端信息;
  • 2)后端平台将消息缓存起来,并且会将消息异步写入消息库;
  • 3)后端平台从redis中获取用户b连接的im即时通讯服务的id;
  • 4)后端平台获取到用户b连接的im即时通讯服务的id后,会向rocketmq中用户b连接的im即时通讯服务id对应的topic发送消息;
  • 5)im即时通讯服务会监听自身服务id对应的rocketmq中topic的消息,此时,用户b连接的im即时通讯服务会接收到消息;
  • 6)im即时通讯服务接收到消息后,会根据用户b的id以及终端信息从缓存中获取用户b与im即时通讯服务建立的连接,并且通过这个连接向用户b推送消息。

要实现如上发送消息的流程,前提是要满足如下条件:

  • 1)后端平台满足分布式条件,可随时横向扩展;
  • 2)im即时通讯服务满足分布式条件,可随时横向扩展;
  • 3)每个启动的im即时通讯服务实例在集群中都有一个唯一的id;
  • 4)每个im即时通讯服务,都只监听自身id对应的rocketmq中topic的消息;
  • 5)用户登录分布式im即时通讯系统后,会与im即时通讯服务建立长连接,并且会根据用户id和所在的终端缓存长连接,同时会根据用户id和所在的终端将连接的im即时通讯服务的id缓存到redis;
  • 6)用户发送消息时,会根据目标用户的id和终端从redis中获取im即时通讯服务的id,进而向当前im即时通讯服务的id对应的rocketmq的topic发送消息;
  • 7)对应的im即时通讯服务监听并接收到rocketmq消息后,会根据目标用户的id和终端从缓存中获取到用户的连接信息,向目标用户推送消息。

单聊就是在分布式im即时通讯系统中,一个用户直接与另外一个用户聊天,也就是一对一的聊天。在这种场景下,很有可能单聊的两个用户中,出现用户不在线的情况。

例如:用户a给用户b发送消息时,用户b可能不在线。

此时,我们就需要将用户a向用户b发送的消息存储起来。

其实,在我们实现的分布式im即时通讯系统中,无论把用户b是否在线,都会存储消息记录。当用户b登录系统后,将消息同步给用户b,如下图所示。

可以看到,用户a向用户b发送消息时:

  • 1)如果用户b在线,就可以按照发送消息的交互链路向用户b发送消息了;
  • 2)如果用户b不在线,此时就无法向用户b正常推送消息。当用户b登录分布式im即时通讯系统后,就会调用后端平台的接口拉取所有未读消息,并通过用户b在线流程向用户b推送消息。

群聊就是在分布式im即时通讯系统中,多个用户在同一个群组中进行聊天。

此时在发送消息时,我们可以通过群组id找出群内所有在线的用户,将消息即时发送给在线的用户。

那些未在线的用户就按照单聊未在线的用户进行处理,如下图所示。

可以看到,群聊的交互链路流程如下所示:

  • 1)用户调用后端平台的接口向群组发送消息;
  • 2)后端平台将消息缓存并异步写入消息库;
  • 3)由于是向群组发送消息,群里有多个用户,此时就会从redis中获取所有用户连接的im即时通讯服务id列表;
  • 4)对用户按照服务id分组,将相同服务id下的用户分在同一个逻辑分组里,方便后续推送消息,并且会记录未在线的用户列表;
  • 5)循环向每个服务id对应的rocketmq中的topic发送消息;
  • 6)广播处理未在线用户的未读消息id;
  • 7)im即时通讯服务会监听自身服务id对应的topic,会随时接收推送到自身服务的消息;
  • 8)当im即时通讯服务接收到消息后,此时用户掉线,或者用户不在线,向用户推送消息就会失败,或者未查询到用户与im即时通讯服务建立的连接,就不会向用户推送消息;
  • 9)当用户登录分布式im即时通讯系统后,会从后端平台拉取历史(离线)消息,并通过用户在线的流程,向用户推送消息;

好了,看到这里,你明白如何设计一个高度可扩展的分布式im即时通讯系统了吗?

[1] 

[2] 

[3] 

[4] 

[5] 

[6] 

[7] 

[8] 

[9] 

[10] 

[11] 

[12] 

[13] 

[14] 

[15] 

[16] 

[17] 

[18] 

[19] 

[20] 

[21] 

(本文已同步发布于:)

posted @ 2023-12-21 11:29 jack jiang 阅读(31) | 评论 (0)编辑 收藏

为了更好地分类阅读 52im.net 总计1000多篇精编文章,我将在每周三推送新的一期技术文集,本次是第28 期。

[- 1 -] 

[链接] 

[摘要] 本文将以新手的视角引导你阅读相关文章,便于你从零开发一个移动端im做好方方面面的知识准备:包括但不限于网络编程基础、通信协议的选型、im的架构设计等等。文笔有限,如有不妥之处还请批评指正,希望对你有用。

[- 2 -] 

[链接] 

[摘要] 本文的目的,就是希望以通俗易懂的语言,帮助移动端im开发者更好地理解移动网络的各种特性,使得开发出的功能能更好地适应移动网络,给用户带来更好的使用体验。

[- 3 -] 

[链接] 

[摘要] 本文将针对上篇中提到的特性,结合我们的实践经验,总结了四个方法来追求极致的“爽快”:快链路、轻往复、强监控、多异步,从理论讲到实践、从技术讲到产品,理论联系实际,举一反三,希望给您带来启发。

[- 4 -]

[链接] 

[摘要] 这篇文章和大家聊下从移动端客户端的角度所关注的im消息可靠性和送达机制

[- 5 -] 

[链接] 

[摘要] 本文整理的有关内容,对于移动端即时通讯im应用来说,同样具有启发意义

[- 6 -] 

[链接] 

[摘要] 为了进一步降低运营带宽成本,减小用户访问流量及提升页面加载速度,社交网络 cdn运维紧跟行业图片优化趋势,创新引入webp、sharpp、自适应分辨率、guetzli等图像压缩技术到现网,经过三年多的多部门联合攻关,已逐渐形成一套覆盖全图片类型(jpeg、jpg、png、webp、gif)多场景的图片压缩运营体系,适用于各类型终端,每年节约外网带宽几百g。

[- 7 -] 

[链接] 

[摘要] 本文的写作目的是以最白话地方式,通俗易懂的为你讲清http协议中的session和token等概念,希望读完全文,您仍能满怀信心,继续义无反顾地跳入程序员这个职业深坑 ^_^。更深入的技术细节,请阅读《im开发基础知识补课(四):正确理解http短连接中的cookie、session和token》。

[- 8 -] 

[链接] 

[摘要] 针对上述主流移动im系统中“长”、“短”连接的分工方式,其中最为重要也是用户最先接触到的——就是基于http的sso单点登陆接口(有的系统里可能并不叫sso接口,本文讨论的是其广义:即实现身份认证功能的http接口),那么这个sso接口工作原理是什么?可以怎么来实现?有无最佳实践建议?

[- -]  

[链接] 

[摘要] 实际在生产环境下,群消息的发送都会想尽办法进行压缩,并开展各种改善性能的处理办法,而不是像上述举例里的直接扩散写(即2000人群里,一条消息被简单地复制为2000条一对一的消息投递)。具体有哪些优先策略?本文或许可以带给你一些启发。

[- 10 -] 

[链接] 

[摘要] 这两年多一直从事网易云信 ios 端 im sdk的开发,期间不断有兄弟部门的同事和凯发k8网页登录的合作伙伴过来问各种技术细节,干脆统一介绍下一个im app的方方面面,包括技术选型(包括通讯方式,网络连接方式,协议选择)和常见问题。

[- 11 -] 

[链接] 

[摘要] 自己设计协议的话,协议用字节流好还是字符流好? 各有什么优缺点?

[- 12 -] 

[链接] 

[摘要] 请问有人知道语音聊天的主流实现方式吗?就是类似微信那种,按住说话,录一段,发送那种。这语音文件录好之后是直接转成二进制发送。还是说当成一个文件上传到服务器,然后发送一个消息给对方,对方收到后下载?

[- 13 -] 

[链接] 

[摘要] 本文将要讨论的是即时im应用中极其重要但也不被用户感知的消息送达保证机制(即qos机制),文中将给出目前主流的参考实现思路。

[- 14 -] 

[链接] 

[摘要] 实时在线投递针对的是消息收发双方都在线的情况(如当发送方用户a发送消息给接收方用户b时,用户b是在线的),那如果消息的接收方用户b不在线,系统是如何保证消息的可达性的呢?这就是本文要讨论的问题。

[- 15 -] 

[链接] 

[摘要] 实时消息时序和一致性是分布式系统架构设计中非常难的问题(尤其im应用这种以消息为中心的应用形态),困难在哪?有什么常见优化实践?这就是本文要讨论的内容。

[- 16 -] 

[链接] 

[摘要] im类系统中,都需要考虑消息时序问题,如果后发送的消息先显示,可能严重扰乱聊天消息所要表达的意义。

[- 17 -] 

[链接] 

[摘要] “用户在线状态的一致性”(单聊好友在线状态、群聊用户在线状态)是im应用领域比较难解决的一个技术问题,如何精准实时的获得好友、群友的在线状态,是今天将要探讨的话题。

[- 18 -] 

[链接] 

[摘要] 由于“消息风暴扩散系数”的存在(概念详见《im单聊和群聊中的在线状态同步应该用“推”还是“拉”?》),群消息的复杂度要远高于一对一的单聊消息。群消息的实时性、可达性、离线消息是今天将要讨论的核心话题。

👉52im社区本周新文:《》,欢迎阅读!👈

我是jack jiang,我为自已带盐!https://github.com/jackjiang2011/mobileimsdk/

posted @ 2023-12-21 10:30 jack jiang 阅读(32) | 评论 (0)编辑 收藏

本文由networkfox分享,来源于华三通信,原题“什么是国密算法?”,本文有修订和改动。

最近几年经常能听到im应用的开发者讨论国产信创方面的技术问题,在某些场景下,国密算法是硬性要求,所以学习一下国密算法还是很有必要的。

国密算法是指由中国国家密码管理局发布的密码算法标准,旨在保障国家信息安全。目前,国家密码管理局已发布了一系列国产商用密码标准算法,包括sm1(scb2)、sm2、sm3、sm4、sm7、sm9以及祖冲之密码算法(zuc)等。通过在金融、电子政务及安防等领域广泛应用国密算法,在对敏感数据进行机密性、完整性和可用性保护的同时,减少对外部密码产品的依赖,提升国家信息安全水平。

本文将尽量以通俗易懂的文字,为你分享国密算法的种类、技术原理和应用场景等。

 
 
技术交流:

- 移动端im开发入门文章:《》

- 开源im框架源码:()

(本文已同步发布于:)

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

《》

《》

《》

《》

《》

《》

《》

《》

《》

《》

《》

《》

《》(* 本文)

3.1国密算法的产生背景

在网络信息传输和存储过程中,数据的保密性和安全性是一项重要的需求。

传统的国际标准加密算法虽然安全可靠,但由于无法保证源代码的安全性,因此存在着源代码被外部恶意攻击者渗透或篡改的风险。为了构建安全的行业网络环境并增强国家行业信息系统的“安全可控”能力,中国积极开展了针对信息安全需求的研究和探索。

自2007年开始,中国制定了国密算法标准,并于2010年正式发布。

经过多年的发展、改进和完善,国密算法已成为中国自主研发的密码算法标准,并在各行业得到广泛应用。它的诞生不仅显著提升了中国在密码技术领域的核心竞争力,还为国家信息安全建设作出了重要贡献。

3.2国密算法的特点

国密算法具备如下特点:

1)安全性高:国密算法采用了严密的密码学原理和复杂的运算方式,具有较高的安全性。它在加密、数字签名和哈希等功能上都能提供可靠的保护,抵抗了各种传统和现代密码攻击手段。

2)高效性与灵活性:国密算法在保证安全性的同时,注重算法的效率。它的加密速度和运行效率相对较高,同时也能适应不同的密码长度和密钥长度,以满足不同场景的需求。

3)标准化广泛:国密算法已被国家标准化机构认可和采用。它符合国际密码学标准的基本要求,具备与国际算法相媲美的能力。同时,国密算法也在国内推广和应用广泛,成为中国信息安全领域的基础核心算法之一。

4)自主创新:国密算法是中国自主研发的密码算法,所以对于算法的实现和推广都具有独立的掌控能力。这意味着中国可以更好地保护自己的国家信息安全,减少对外依赖,提高自主抵抗能力。

5)面向多领域应用:国密算法不仅局限于某个特定领域的应用,它适用于金融业、电子商务、通信、物联网、区块链等不同领域的信息安全保护。它的广泛应用范围使得国密算法可以满足不同行业的安全需求。

国密算法包括sm1(scb2)、sm2、sm3、sm4、sm7、sm9以及祖冲之密码算法(zuc)等。

其中:

  • 1)sm1、sm4、sm7、祖冲之密码(zuc)属于对称算法;
  • 2)sm2、sm9属于非对称算法;
  • 3)sm3属于杂凑算法。

下文将主要介绍国密算法中的常用算法sm1、sm2、sm3和sm4的实现和应用。

sm1算法是国密算法中的一种对称加密算法,其特点是加解密使用相同密钥。利用sm1对称加密算法加解密数据的过程。

sm1算法未公开,仅以ip核(intellectual property core,一种预先做好的集成电路功能模块)的形式存在于芯片中。

sm1算法主要用于小数据量的加密保护,因此被广泛用于研制智能ic卡、智能密码钥匙、门禁卡、加密卡等安全产品。

6.1概述

sm2算法是基于ecc(elliptic curve cryptography)椭圆曲线的非对称加密算法,包括了sm2-1椭圆曲线数字签名算法、sm2-2椭圆曲线密钥交换协议和sm2-3椭圆曲线公钥加密算法,分别用于实现数字签名、密钥协商和数据加密等功能。

sm2算法在许多领域都有广泛的应用。

在电子商务领域:sm2算法被用于保护用户个人信息的安全传输,确保用户在网上交易过程中的隐私和财产的安全。

在互联网金融领域:sm2算法被用于数字支付、电子银行等场景,实现用户身份认证和交易的安全性。

此外,sm2算法还适用于物联网领域,保护物联网设备之间的通信安全,确保数据的可靠传输。

6.2数据加密

在非对称加密算法中,可对外公布的密钥称为“公钥”,只有持有者所知的密钥称为“私钥”。发送者使用接收者的公钥来加密消息,接收者用自己的私钥解密和读取该消息。

利用sm2非对称加密算法加解密数据的过程:

6.3密钥协商

由于椭圆曲线的计算复杂性高,破解难度大,因此sm2算法在密钥协商技术领域也起着关键作用。

利用sm2算法进行密钥协商的过程:

  • 1)会话双方生成自己的私钥(随机数);
  • 2)会话双方由私钥、ecc椭圆曲线参数g各自计算出公钥;
  • 3)会话双方将自己的公钥传递给对方,传递过程公开。由于椭圆曲线的计算复杂性高,破解难度大,因此攻击者难以通过公钥和椭圆曲线参数g反推出私钥;
  • 4) 双方将自己的私钥与对方的公钥进行运算,最终得到相同的会话密钥,该会话密钥可作为共享密钥用于对称加密(例如sm4算法)通信。

6.4数字签名

数字签名是一种用于验证信息完整性、真实性和来源的技术手段。它通常用于确保数据在传输或存储过程中没有被篡改,并且可以追溯到特定的发送方。

发送方使用自己的私钥对消息进行加密,生成数字签名。接收方使用发送方的公钥对签名进行解密和验证,以验证消息的完整性和真实性。

在数字签名应用中,sm2算法通常与sm3摘要算法一起使用。

sm3杂凑(hashing)算法是国密算法中的一种摘要算法。

sm3算法通过哈希函数将任意长度的消息压缩成固定长度的摘要。摘要具有唯一性,即不同信息生成的摘要不同,且无法由摘要恢复出原始信息,更无法伪造信息获得相同摘要,因此sm3算法被广泛用于实现数字签名、数据完整性检测及消息验证等功能。

基于sm3算法的特点,在信息安全领域,sm3算法被用于保护密码学协议、数字证书和电子签名等数据的完整性。在区块链领域,sm3算法被用于加密货币的区块生成和链上交易的校验,确保区块链的安全性。

此外,sm3算法还可以应用于密码学随机数的生成和伪随机序列的校验等领域,增加了数据的安全性和可靠性。

利用sm2算法和sm3算法对用户数据进行数字签名认证及完整性校验的过程:

  • 1) 用户a发送的数据a经过sm3哈希算法运算生成摘要a。
  • 2) 摘要a经过用户a的私钥加密生成数字签名。
  • 3) 用户a的明文数据和数字签名经加密算法(sm1/sm2/sm4)加密成密文后发送给用户b。加密算法以非对称加密算法sm2为例,即加解密使用不同密钥。
  • 4)密文到达用户b处,经加密算法(sm1/sm2/sm4)解密后,还原成明文数据和数字签名。
  • 5)用户b使用用户a的公钥解密数据包中的数字签名:
  •      解密成功,数据来源合法,得到摘要a;
  •      解密失败,数据来源非用户a,丢弃本次数据。
  • 6)收到的数据包中的明文数据经过sm3哈希运算生成摘要a’。对比摘要a和摘要a’:
  •      摘要a’=摘要a,数据完整;
  •      摘要a’≠摘要a,数据被篡改,丢弃本次数据。

8.1概述

与sm1算法分类相同,sm4算法同样为分组对称加密算法,但sm4算法实现公开。

分组加密算法是将明文数据按固定长度进行分组,用同一密钥逐组加密,密文解密时同样使用相同密钥逐组解密。

sm4算法实现简单,因此加解密速度较快,消耗资源少,主要用于大数据量的加密和解密,例如静态储存或数据信号传输通道中数据的加解密。

在网络安全领域,sm4算法被用于保护网络传输和存储的敏感数据,如银行卡信息、密码等。在物联网领域,sm4算法被用于物联网设备之间的通信和数据加密,确保物联网数据的隐私安全。

此外,sm4算法还可以应用于区块链领域,保护加密货币的交易安全等领域,为相关系统和数据的安全提供了保障。

sm4算法支持ecb、cbc、cfb等多种分组模式,下文将介绍ecb和cbc两种基础模式。

8.2加解密模式:ecb模式

sm4算法基于ecb模式对数据加解密的过程:

  • 1)发送端将明文按固定长度分组,对每个明文分组分别使用相同的密钥进行加密生成密文分组。完整的密文由所有密文分组按序排列组合而成;
  • 2)接收端将密文按固定长度分组,对每个密文分组分别使用相同的密钥进行解密生成明文分组。所有明文分组按序排列组合而成完整的明文数据。

ecb模式实现简单,各段数据间互不影响,有利于并行运算,但相同的明文块会被加密成相同的密文块,不能提供严格的数据保密性。

8.3加解密模式:cbc模式

sm4算法基于cbc模式对明文加密的过程:

  • 1)将明文按固定长度分组;
  • 2)明文分组1与初始向量iv进行异或运算,异或运算的结果经密钥加密后得到密文分组1;
  • 3)剩余的明文分组依次与前一个密文分组进行异或运算后再加密,得到对应的密文分组;
  • 4)完整的密文由所有密文分组按序排列组合而成。

sm4算法基于cbc模式对密文解密的过程:

  • 1)将密文按固定长度分组后,对密文分组进行倒序处理;
  • 2)对密文分组n先使用密钥进行解密,密文分组n解密后的数据与密文分组n-1进行逻辑逆运算,得到明文分组n;
  • 3) 同理,剩余的密文分组解密后再与前一个密文分组进行逻辑逆运算,得到对应的明文分组;
  • 4)最后,密文分组1用密钥解密后的数据是与初始向量进行逻辑逆运算,然后得到明文分组1;
  • 5)完整的明文由所有明文分组按序排列组合而成。

cbc模式安全性高于ecb,但明文块不能并行计算,且误差会传递下去。

国密算法和国际标准算法都是现代密码学中常用的加密算法,但在技术和优劣方面存在一些区别。

常见国密算法与国际标准算法各参数性能的对比如下:

 

10.1ad-wan纵向ip/mpls组网

国密算法可以与ad-wan技术结合,应用于ip/mpls纵向网场景。

通过ad-wan智能运维平台,实现国密配置一键下发,在网络中构建国密数据加密通道,实现基于国密的端到端的ipsec隧道保护。

国密算法在端到端的ipsec隧道中的工作原理如下:

1)在ike密钥协商阶段,使用ike协议进行密钥协商过程中,采用sm2算法生成会话密钥。

2)在身份认证阶段,本端使用sm2和sm3算法生成身份信息的数字签名,并使用sm1或sm4算法和会话密钥对身份信息和数字签名进行加密;对端收到加密的身份信息后,使用相同的会话密钥解密,然后通过sm2和sm3算法进行身份认证。

3)在数据传输阶段,本端使用sm2和sm3算法生成用户数据的数字签名,并使用sm1或sm4算法以及会话密钥对用户数据和数字签名进行加密;对端收到加密的用户数据后,使用相同的会话密钥解密,然后通过sm2和sm3算法进行数据完整性检查。

10.24g/5g vpdn业务组网

4g/5g vpdn(virtual private dialup network,虚拟专有拨号网络)业务是在4g/5g无线网络中采用拨号方式实现的一种虚拟专有网络业务。它利用l2tp技术为客户构建与互联网隔离的隧道,以满足客户分支和总部内网通信的需求。vpdn组网同时支持将l2tp和ipsec技术结合,通过l2tp完成用户认证确保接入安全,并利用ipsec保障通信数据安全。

1)4g/5g vpdn组网中分支网关由4g/5g路由设备担任,通过拨号接入运营商网络。

2)运营商对4g/5g路由设备的apn(access point name,接入点名称)、账户、sim/usim卡信息进行认证。

3)4g/5g路由设备认证通过后被运营商判断是vpdn用户,同时由运营商aaa服务器向lac(l2tp access concentrator,l2tp访问集中器)设备下发l2tp隧道属性,lac设备将基于下发的l2tp隧道属性信息向该vpdn用户所属总部的lns(l2tp network server,l2tp网络服务器)设备发起隧道建立请求。

4)l2tp隧道建立后,lac设备会通过此隧道向lns设备透传用户的认证信息。lns设备向总部内网的aaa服务器发起对vpdn用户的二次认证,认证通过后为vpdn用户分配一个企业内网ip地址。分支终端用户和总部可以开始通信。

5)分支网关与总部网关设备上均安装有国密板卡,通过ipsec协商建立起端到端的ipsec隧道,使用国密算法对传输的数据报文进行加密保护和数据完整性检查。

6)经ipsec加密后的数据报文在lac设备处进行l2tp封装后,通过l2tp隧道传输到lns。

7)lns收到数据报文后首先对l2tp报文进行解封装,然后经过ipsec解密还原出数据报文,根据报文目的ip地址转发报文。

[1] 

[2] 

[3] 

[4] 

[5] 

[6] 

[7] 

[8] 

[9] 


(本文已同步发布于:)

posted @ 2023-12-14 11:06 jack jiang 阅读(46) | 评论 (0)编辑 收藏

jack jiang的 mail: jb2011@163.com, 联系qq: 413980957, 微信: hellojackjiang
网站地图