Jack Jiang

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

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

​[- 1 -] IM消息ID技术专题(一):微信的海量IM聊天消息序列号生成实践(算法原理篇)

[链接] http://www.52im.net/thread-1998-1-1.html

[摘要] 如何优雅地解决“消息序列号只要保证顺序性而不需要兼顾唯一性”的问题呢?这就是本文所要分享的内容,强烈建议深入理解和阅读。


[- 2 -] IM消息ID技术专题(二):微信的海量IM聊天消息序列号生成实践(容灾方案篇)

[链接] http://www.52im.net/thread-1999-1-1.html

[摘要] 本篇将会介绍 seqsvr 分布式容灾架构的演变。


[- 3 -] IM消息ID技术专题(三):解密融云IM产品的聊天消息ID生成策略

[链接] http://www.52im.net/thread-2747-1-1.html

[摘要] 本文要分享的是融云即时通讯云产品中的聊天消息ID生成算法和策略,一个19字节的ID就能包含:时间戳、消息类型、会话ID、序列号,小ID、大用途,值得借鉴!


[- 4 -]IM消息ID技术专题(四):深度解密美团的分布式ID生成算法

[链接] http://www.52im.net/thread-2751-1-1.html

[摘要] 对于美团的Leaf-segment这个ID生成方案,因为生成的ID全局唯一、全局有序,所以非常适合IM这种应用场景,这也是即时通讯网整理并分享给社区的原因。


[- 5 -] IM消息ID技术专题(五):开源分布式ID生成器UidGenerator的技术实现

[链接] http://www.52im.net/thread-2953-1-1.html

[摘要] 本文是专题系列文章的第5篇,专门介绍百度开源的分布式消息ID生成器UidGenerator的算法逻辑、实现思路、重点源码解读等,或许能带给你更多的启发。


[- -] IM消息ID技术专题(六):深度解密滴滴的高性能ID生成器(Tinyid)

[链接] http://www.52im.net/thread-3129-1-1.html

[摘要] 本文将要分享的是滴滴开源的分布式ID生成器Tinyid的技术原理、使用方法等等,希望能进一步为你打开这方面的技术视野。


[- 7 -] IM消息ID技术专题(七):深度解密vivo的自研分布式ID服务(鲁班)

[链接] http://www.52im.net/thread-4378-1-1.html

[摘要] 本文通过对分布式ID的3种应用场景、实现难点以及9种分布式ID的实现方式进行介绍,并对结合vivo业务场景特性下自研的鲁班分布式ID服务从系统架构、ID生成规则与部分实现源码进行分享,希望为本文的阅读者在分布式ID的方案选型或技术自研提供参考。


[- 8 -] IM开发宝典:史上最全,微信各种功能参数和逻辑规则资料汇总

[链接] http://www.52im.net/thread-3008-1-1.html

[摘要] 本文将根据微信官方目前已公开的资料,将它的一些常用功能参数和逻辑规则资料进行了汇总整理,希望能助力你的IM开发!


[- -]  IM开发干货分享:我是如何解决大量离线消息导致客户端卡顿的

[链接] http://www.52im.net/thread-3036-1-1.html

[摘要] 今天这篇不是原理性文章,而是为大家分享一下由笔者主导开发实施的IM即时通讯聊天系统,针对大量离线消息(包括消息漫游)导致的用户体验问题的升级改造全过程。


[- 10 -] 零基础IM开发入门(一):什么是IM系统?

[链接] http://www.52im.net/thread-3065-1-1.html

[摘要] 本系列文章将尽量从理论概念入手,通俗易懂的梳理IM中的基础技术概念和热门技术点,希望能帮你理清看似一团乱麻的IM知识体系,助你找到清晰的IM技术学习方向。


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

[链接] http://www.52im.net/thread-3143-1-1.html

[摘要] 对于技术门外汉来说,到底什么是IM的“实时性”?该如何理解它?这就是本文想要讨论的主题。


[- 12 -] 零基础IM开发入门(三):什么是IM系统的可靠性?

[链接] http://www.52im.net/thread-3182-1-1.html

[摘要] 本篇主要讲解IM系统中的“可靠性”这个话题,内容尽量做到只讲原理不深入展开,避开深层次的技术性探讨,确保通俗易懂。


[- 13 -] 零基础IM开发入门(四):什么是IM系统的消息时序一致性?

[链接] http://www.52im.net/thread-3189-1-1.html

[摘要] 本文尽量以通俗简显的文字为你讲解IM消息时序一致性问题的产品意义、发生原因、解决思路等。


👉52im社区本周新文:《IM跨平台技术学习(十):快速对比跨平台框架Electron、Flutter、Tauri、React Native等》,欢迎阅读!👈

我是Jack Jiang,我为自已带盐!https://github.com/JackJiang2011/MobileIMSDK/

posted @ 2024-01-10 13:24 Jack Jiang 阅读(48) | 评论 (0)编辑 收藏

本文由字节跳动技术团队李晨光、匡建鑫、陈鉴平分享,本文有修订和改动。

1、引言

新媒体互动直播已成为了广大网民最重要的休闲娱乐方式之一。丰富的传统文化、新闻、竞技体育、法律、知识共享等内容,通过移动端互动直播的形式得以更加高效的展现传播,既让优质的直播内容可以实现爆发式传播扩散,又可以让用户有更多的机会感受,学习甚至主动参与直播互动。超低延时视频直播技术正在走上一条全新的发展之路。

本文将带您了解超低延时视频直播技术的优化和演进历程。

 
技术交流:

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

2、系列文章

本文是系列文章中的第 11 篇,本系列总目录如下:

3、低延时直播技术的作用

网络基础设施升级、音视频传输技术迭代、WebRTC 开源等因素,驱动音视频服务时延逐渐降低, 使超低延时直播技术成为炙手可热的研究方向。实时音视频业务在消费互联网领域蓬勃发展, 并逐渐向产业互联网领域加速渗透。经历了行业第一轮的红利爆发期,我国实时音视频行业的场景效能逐渐深化,步入到理性增长阶段。

延时的指标选择很大程度上取决于用户与内容制作方的交互耦合程度,场景丰富多样。

在这些极端场景下,延时在用户侧希望越小越好,接近于实时通信的低延迟模式可以最大化地激发用户的参与感,无缝地与内容生产方产生互动效应,调动用户所见即所得的积极性。比如在主播秀场的PK、送礼、工会冲榜、打赏的活动关键环节,竞争双方的储值大户都希望实时地观察到自身主播在礼物刷榜后的反应,为后台运营决策团队或者后续活动策略提供第一时间的信息反馈。

下图体现了从技术/产品/运营的三方角度来综合思考低延时直播技术的作用;从外部-内部综合因素考虑技术的变迁对整个生态正向循环的影响。

4、传统直播技术中RTMP协议的延迟问题

RTMP 协议是最传统的直播协议,主播端采用 RTMP 协议推送 H.264/5 和 AAC 编码的视音频数据到云厂商 CDN 服务器进行转封装分发,端到端延迟一般控制在 3 到 7 秒。

问题是 RTMP 的可扩展性存在缺陷,同时对于延迟的进一步下探存在一定的技术困难。

RTMP 协议情况下:为了满足延时降低必然压缩播放器的下载缓冲区,这样会引发显著的卡顿问题,使得播放的观感产生不舒适的感受(延时下探至 2 秒以下)。

5、传统直播技术在实时互动场景中的不足

1)视频延时和弹幕交互的延时存在显著差异,问题聊天内容互动与视频传输图像节奏不匹配:

2)观众与主播互动形式单一,是单向内容传导无法做到双向(在 RTC 技术引入之前无法显著解决)。

3)单向传导的局限第一个方面表现在:观众端拉流传输无法做到根据网络情况自适应调节。用户只能以固定的码率进行流媒体传输无法做到动态感知,在网络情况实时变化的场景(比如弱网,移动基站切换等)固定单向码率传输有较大概率造成丢帧卡顿等因素影响观播体验。另一方面在网络条件更好时,固定码率传输无法动态提升视频传输码率(更高的画质带来更加舒适的体验)

4)在直播和连麦场景共存的互动直播场景下,主播采用传统RTMP推流在遇到连麦PK场景时,会产生推流/本地连麦合流/服务器连麦合流的切换问题,这种场景变换的切换会使得观众端产生瞬间的卡顿问题。如果采用基于webRTC直播技术的超低延时直播方案,这种推流--连麦逻辑的合流切换问题可以得到比较友好的解决(只需要改变服务器转发-订阅流通道的分发逻辑,不涉及推流媒体数据流的旁路调度切换)。

6、 超低延时直播与标准直播的区别

6.1超低延时直播

超低延时直播是近年来新兴起的一类应用。

如电商直播、赛事直播等场景,兼具高并发与低延时的特性,传统直播 3-20s 的时延难以满足其需求,但对实时互动的要求又不及视频会议等典型的实时音视频应用,无需将时延降低至 400ms 以下。

为此,超低延时直播融合了传统直播与实时音视频的技术架构,通过取长补短的方式实现了介于二者之间的端到端时延。

尽管针对超低延时直播厂商尚无一套标准的技术路径,但大体可以归纳为拉流协议、网络架构和推流协议三个方面的改造, 在实际应用过程中,厂商会平衡成本及性能指标等因素,在不同的协议和网络架构之间进行选择。

6.2传输层协议的差异

基于 UDP 协议的可靠性优化,为弱网对抗策略提供依据。

传统直播 FLV/RTMP 等采用的是 TCP 协议(或者 QUIC 协议)TCP 是牺牲传输实时性来换取数据完整性的可靠传输协议。

弱网环境下,其在数据传输前的“三次 握手”连接会带来较大延时。

而 UDP 作为不可靠的传输协议,其最大的优点为高实时性,但不保证数据的到达和排序。

实时音视频 产品(如 RTM 超低延时直播)往往采用 UDP 协议,并在此之上进行协议层与算法层的优化,来提高传输的可靠性与逻辑性。

相关文章可阅读:

  1. 网络编程懒人入门(五):快速理解为什么说UDP有时比TCP更有优势
  2. 技术扫盲:新一代基于UDP的低延时网络传输层协议——QUIC详解
  3. 不为人知的网络编程(六):深入地理解UDP协议并用好它
  4. 不为人知的网络编程(七):如何让不可靠的UDP变的可靠?

6.3UDP 协议的优化

UDP 协议往往和 RTP/RTCP 协议一起在实际应用中出现。

RTP 负责数据传输,其协议头中的序列号、 端口类型、时间戳等字段,可为数据包的分组、组装、排序提供逻辑依据。

RTCP 作为 RTP 的控制协议,负责对 RTP 的传输质量进行统计反馈,并为弱网对抗策略提供控制参数。

7、RTM 协议本身的演进历程

a=extmap:18 "http://www.webrtc.org/experiments/rtp-hdrext/decoding-timestamp"

a=extmap:19 "uri:webrtc:rtc:rtp-hdrext:video:CompositionTime"

a=extmap:21 uri:webrtc:rtc:rtp-hdrext:video:frame-seq-range

a=extmap:22 uri:webrtc:rtc:rtp-hdrext:video:frame-type

a=extmap:23 uri:webrtc:rtc:rtp-hdrext:video:reference-frame-timestamp

a=extmap:27 uri:webrtc:rtc:rtp-hdrext:audio:aac-config

RTP 使用 RTP 私有扩展头携带 DTS/CTS 值,每一帧 RTP 数据包通过 RFC5285-Header-Extension 扩展头携带该帧的 DTS 值,每一帧首个 RTP 包和 VPS/SPS/PPS 包通过 RFC5285-Header-Extension 扩展头携带该帧的 CTS 值,通过 PTS = DTS + CTS 计算当前帧的时间戳。用于启播快速音画同步和播放器播控逻辑精准音画同步。

扩展头携带帧的起始/结束序号:如果首帧的前几个包丢失,那么可根据起始序号快速发起重传加快首帧;如果当前帧的后几个包丢失,那么可根据该帧的结束序号快速发起重传,降低延时,减少卡顿。

扩展头携带帧的类型:如果携带并解析了正确的帧类型,客户端可以不用解析 metadata ;同时在弱网情形,客户端可以跳过 B 帧直接解码 P 帧,加速出帧并减少潜在卡顿。

扩展头携带 P 帧的参考帧信息:如果发生弱网情形,那么客户端可以依照扩展头指定的参考帧关系及其对应时间戳,跳过 B 帧解码 ,减少卡顿发生。

为了加速信令交互的速度,CDN 可以在某些条件下不去查询媒体信息,直接向客户端返回支持的音视频能力;此时 SDP 的媒体描述中将不包含有具体的音视频配置详细信息。在音频层面,此时AnswerSDP 中不包含 aac 解码所需的头信息;此时我们需要采取 RTP 扩展头模式携带 AAC-Config 供客户端在 RTP 收包时刻自行解析处理完成解码动作,作用是减少信令交互时间,提升拉流成功率。

miniSDP 信令标准实现部分(抖音)。

CDN 信令异步回源。

RTP 携带扩展头组成部分。

8、WebRTC 协议在直播播放器的移植

RTM 低延时直播基于 WebRTC 技术衍生,基于 WebRTC 标准构建点到点传输一般有如下几个步骤:

  • 1)通信双方要进行媒体协商,会话详细规范即 SDP(Session Description Protocol) 交互;
  • 2)随后进行交互式网络地址协商(查询对端真实 IP 地址)准备构建媒体传输通道;
  • 3)当上述条件准备完毕即进入最终的 Peer to Peer 点对点媒体数据传输。

信令部分客户端-服务器单独开发,利用了 SDP 标准报文模式。媒体传输部分采用开源的 WebRTC 框架和字节自研的实时音视频媒体引擎进行媒体传输。

9、RTC 信令协议的改造升级

MiniSDP压缩协议:https://github.com/zhzane/mini_sdp

标准 SDP 比较冗长(5-10KB 左右),不利于快速高效传输。在直播场景下,会尤其影响首帧时间。

MiniSDP 对标准 SDP 文本协议进行高效能压缩,将原生 SDP 转换成更小的二进制格式,使其能够通过一个 UDP 包来传输。

降低信令交互时间,提高网络传输效能,降低直播拉流首帧渲染时间,提高拉流秒开率/成功率等 QoS 统计指标。

10、CDN对RTM 信令的异步回源优化

降低 RTM 信令交互时间,降低 RTM 拉流首帧渲染时间。

原来的流程在服务端缓存不命中时需要等待回源拿到数据,才能返回带有 AacConfig 信息的 AnswerSDP。客户端收到 AnswerSDP 后发送 STUN,而服务端只能在收到 STUN 才能开始下发数据。

如下图左:当异步回源情况下,服务端不再等待回源结果直接返回 AnswerSDP,之后回源和WebRTC 建连流程同步进行。

如上图右:等到 WebRTC 建连成功且回源拿到数据立即下发 RTP 数据。

11、视频渲染卡顿的优化(百秒卡顿平均降低4秒)

改善人均看播时长,改变 RTC 引擎的组帧/解码策略;禁止 RTC 在低延时模式下的丢帧,改善直播的视频渲染卡顿。

传统的 RTC 场景优先保时延,全链路会触发各种丢帧(包括但不限于解码模块,网络模块),FLV 直播场景会优先保证观播体验(不丢帧,良好的音画同步效果)。

RTM 要想减少卡顿,取得 qoe 的收益,播控策略需进行定制化,定制逻辑修改点:

1)确保不会由于软解的解码耗时或者硬解的 dequeuinputbuffer 等其它 api 操作阻塞 jitterbuffer ,内核层有一层强制的音画同步逻辑,可以确保音视频的播放体验;

2)同时上层在监控网络模块和解码模块的缓存长度,有相应的兜底逻辑:

  • a. 判断硬解确实解不过来,dec_cache_frames 过多,上报错误,会降级到软解;
  • b. jitterbuffer 异常,缓存的 frame_list 过多,触发播放器异常逻辑,上报错误,重新拉流。

12、RTM播控逻辑的优化

改善移动端看播渗透,RTC 统一内核方案天生存在缺陷( MediaCodec 硬件解码器初始化耗时久)。将 RTM 视频解码模块从 RTC 内核中迁移至 TTMP 播放内核,复用了 FLV 的视频解码模块( MediaCodec 避免重新初始化)。显著的降低了安卓平台的首帧渲染时间,提升了拉流的成功率。

RTC 内核通用逻辑:

改进的 RTM 内核播控逻辑:

13、相关文章

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

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

[3] 零基础入门:基于开源WebRTC,从0到1实现实时音视频聊天功能

[4] 实时音视频入门学习:开源工程WebRTC的技术原理和使用浅析

[5] 零基础快速入门WebRTC:基本概念、关键技术、与WebSocket的区别等

[6] 学习RFC3550:RTP/RTCP实时传输协议基础知识

[7] 基于RTMP数据传输协议的实时流媒体技术研究(论文全文)

[8] 技术扫盲:新一代基于UDP的低延时网络传输层协议——QUIC详解

[9] 让互联网更快:新一代QUIC协议在腾讯的技术实践分享

[10] 实时音视频面视必备:快速掌握11个视频技术相关的基础概念

[11] 实时音视频开发理论必备:如何省流量?视频高度压缩背后的预测技术

[12] 移动端实时音视频直播技术详解(一):开篇

[13] 直播系统聊天技术(九):千万级实时直播弹幕的技术实践

[14] 在线音视频直播室服务端架构最佳实践(视频+PPT) [附件下载]

[15] 视频直播技术干货:一文读懂主流视频直播系统的推拉流架构、传输协议等

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

posted @ 2024-01-04 11:45 Jack Jiang 阅读(83) | 评论 (0)编辑 收藏

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

​[- 1 -] 全面掌握移动端主流图片格式的特点、性能、调优等

[链接] http://www.52im.net/thread-1802-1-1.html

[摘要] 本文我们一起全面分析学习目前主流和新兴的几种图片格式的特点、性能、调优等,以及相关开源库的选择,希望能为您的移动端应用(包括本社区主要讨论的即时通讯应用)中的图片优化带来一些启发。


[- 2 -] 最火移动端跨平台方案盘点:React Native、weex、Flutter

[链接] http://www.52im.net/thread-1870-1-1.html

[摘要] 本篇主要以react-native、weex、flutter,深入聊聊当前最火的这3种跨平台移动开发方案的实现原理、现状与未来。至于为什么只讲它们,因为对比ionic、phoneGap,它们更于 “naive” (˶ ⁻̫ ˵)。看完本篇,相信你会对于当下跨平台移动开发的现状、实现原理、框架的选择等有更深入的理解。


[- 3 -] 子弹短信光鲜的背后:网易云信首席架构师分享亿级IM平台的技术实践

[链接] http://www.52im.net/thread-1961-1-1.html

[摘要] 本文内容来自对网易云信首席架构师周梁伟的采访,采访内容主要围绕网易云信这种海量用户IM云平台的关键技术难点以及对应的技术实践。


[- 4 -] IM开发基础知识补课(五):通俗易懂,正确理解并用好MQ消息队列

[链接] http://www.52im.net/thread-1979-1-1.html

[摘要] 消息是互联网信息的一种表现形式,是人利用计算机进行信息传递的有效载体,比如即时通讯网坛友最熟悉的即时通讯消息就是其具体的表现形式之一。


[- 5 -] 微信技术分享:微信的海量IM聊天消息序列号生成实践(容灾方案篇)

[链接] http://www.52im.net/thread-1999-1-1.html

[摘要] 本篇将会介绍 seqsvr 分布式容灾架构的演变。


[- 6 -] 阿里技术分享:深度揭秘阿里数据库技术方案的10年变迁史

[链接] http://www.52im.net/thread-2050-1-1.html

[摘要] 阿里数据库事业部研究员张瑞,将为你讲述双11数据库技术不为人知的故事。


[- 7 -] 自已开发IM有那么难吗?手把手教你自撸一个Andriod版简易IM (有源码)

[链接] http://www.52im.net/thread-2671-1-1.html

[摘要] 本文不是一篇即时通讯理论文章,文章内容全部由实战代码组织而成。


[- 8 -] 融云技术分享:解密融云IM产品的聊天消息ID生成策略

[链接] http://www.52im.net/thread-2747-1-1.html

[摘要] 本文要分享的是融云即时通讯云产品中的聊天消息ID生成算法和策略,一个19字节的ID就能包含:时间戳、消息类型、会话ID、序列号,小ID、大用途,值得借鉴!


[- -]  IM开发基础知识补课(六):数据库用NoSQL还是SQL?读这篇就够了!

[链接] http://www.52im.net/thread-2759-1-1.html

[摘要] 本文将分析传统数据库(即SQL数据库)存在的一些问题,以及盘点目前市面上几大类 NoSQL 特性、优缺点等,希望给大家提供一些在不同业务场景下存储技术选型方面的参考。


[- 10 -] 适合新手:从零开发一个IM服务端(基于Netty,有完整源码)

[链接] http://www.52im.net/thread-2768-1-1.html

[摘要] 本文写的比较浅显但不太易懂,建议结合代码一起来读,文章配套的完整源码请从本文文末 “11、完整源码下载” 处下载!


[- 11 -] 拿起键盘就是干:跟我一起徒手开发一套分布式IM系统

[链接] http://www.52im.net/thread-2775-1-1.html

[摘要] 本文记录了我开发的一款面向IM学习者的 IM系统——CIM(全称:CROSS-IM),同时提供了一些组件帮助开发者构建一款属于自己可水平扩展的 IM。


[- 12 -] 适合新手:手把手教你用Go快速搭建高性能、可扩展的IM系统(有源码)

[链接] http://www.52im.net/thread-2988-1-1.html

[摘要] 本文适合有一定网络通信技术基础的IM新手阅读。如果你对网络编程,以及IM的一些理论知识知之甚少,请务必首先阅读:《新手入门一篇就够:从零开发移动端IM》,按需补充相关知识。


[- 13 -] IM里“附近的人”功能实现原理是什么?如何高效率地实现它?

[链接] http://www.52im.net/thread-2827-1-1.html

[摘要] 本文将简要的为你讲解“附近的人”的基本理论原理,并以Redis的GEO系列地理位置操作指令为例,理论联系实际地为你讲解它们是如何被高效实现的。


[- 14 -] IM开发基础知识补课(七):主流移动端账号登录方式的原理及设计思路

[链接] http://www.52im.net/thread-2863-1-1.html

[摘要] 本文将分享几种典型的移动端账号登陆方式的技术原理,以及设计思路,理解后,完全可以快速实施于你的各种应用系统(并不限于IM系统)中。


[- 15 -] IM“扫一扫”功能很好做?看看微信“扫一扫识物”的完整技术实现

[链接] http://www.52im.net/thread-2887-1-1.html

[摘要] 本文将详细为你解密微信“扫一扫识物”功能背后的技术秘密。


[- 16 -] IM要做手机扫码登录?先看看微信的扫码登录功能技术原理

[链接] http://www.52im.net/thread-2941-1-1.html

[摘要] 本文将以轻松活泼的语言形式,为你分析和讲解微信手机扫码登录的技术原理,希望在你的IM中开发此功能时有所启发。


👉52im社区本周新文:《视频直播技术干货(十一):超低延时视频直播技术的演进之路》,欢迎阅读!👈

我是Jack Jiang,我为自已带盐!https://github.com/JackJiang2011/MobileIMSDK/

posted @ 2024-01-03 11:57 Jack Jiang 阅读(15) | 评论 (0)编辑 收藏

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

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

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

[- 1 -] 谈谈移动端 IM 开发中登录请求的优化

[链接] http://www.52im.net/thread-282-1-1.html

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


[- 2 -] 移动端IM登录时拉取数据如何作到省流量?

[链接] http://www.52im.net/thread-787-1-1.html

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


[- 3 -] 浅谈移动端IM的多点登录和消息漫游原理

[链接] http://www.52im.net/thread-867-1-1.html

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


[- 4 -] 完全自已开发的IM该如何设计“失败重试”机制?

[链接] http://www.52im.net/thread-280-1-1.html

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


[- 5 -] 通俗易懂:基于集群的移动端IM接入层负载均衡方案分享

[链接] http://www.52im.net/thread-802-1-1.html

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


[- -] 微信对网络影响的技术试验及分析(论文全文)

[链接] http://www.52im.net/thread-195-1-1.html

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


[- 7 -] 即时通讯系统的原理、技术和应用(技术论文)

[链接] http://www.52im.net/thread-218-1-1.html

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


[- 8 -] 开源IM工程“蘑菇街TeamTalk”的现状:一场有始无终的开源秀

[链接] http://www.52im.net/thread-447-1-1.html

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


[- -]  QQ音乐团队分享:Android中的图片压缩技术详解(上篇)

[链接] http://www.52im.net/thread-1208-1-1.html

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


[- 10 -] QQ音乐团队分享:Android中的图片压缩技术详解(下篇)

[链接] http://www.52im.net/thread-1212-1-1.html

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


[- 11 -] 腾讯原创分享(一):如何大幅提升移动网络下手机QQ的图片传输速度和成功率

[链接] http://www.52im.net/thread-675-1-1.html

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


[- 12 -] 腾讯原创分享(二):如何大幅压缩移动网络下APP的流量消耗(上篇)

[链接] http://www.52im.net/thread-696-1-1.html

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


[- 13 -] 腾讯原创分享(三):如何大幅压缩移动网络下APP的流量消耗(下篇)

[链接] http://www.52im.net/thread-697-1-1.html

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


[- 14 -] 如约而至:微信自用的移动端IM网络层跨平台组件库Mars已正式开源

[链接] http://www.52im.net/thread-684-1-1.html

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


[- 15 -] 基于社交网络的Yelp是如何实现海量用户图片的无损压缩的?

[链接] http://www.52im.net/thread-1191-1-1.html

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


[- 16 -] 腾讯技术分享:腾讯是如何大幅降低带宽和网络流量的(图片压缩篇)

[链接] http://www.52im.net/thread-1559-1-1.html

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


[- 17 -] 腾讯技术分享:腾讯是如何大幅降低带宽和网络流量的(音视频技术篇)

[链接] http://www.52im.net/thread-1560-1-1.html

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


[- 18 -] 为什么说即时通讯社交APP创业就是一个坑?

[链接] http://www.52im.net/thread-1619-1-1.html

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


👉52im社区本周新文:《IM通讯协议专题学习(十):初识 Thrift 序列化协议》,欢迎阅读!👈

我是Jack Jiang,我为自已带盐!https://github.com/JackJiang2011/MobileIMSDK/

posted @ 2023-12-27 15:23 Jack Jiang 阅读(48) | 评论 (0)编辑 收藏

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

1、引言

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

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

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

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

 
技术交流:

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

2、方案目标

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

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

具体是:

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

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)网络通信Netty
  • 10)文件存储:Minio;
  • 11)日志可视化治理:ELK;
  • 12)容器化管理:Swarm、Portainer;
  • 13)监控:Prometheus、Grafana;
  • 14)前端:Vue;
  • 15)单元测试:Junit;
  • 16)基准测试:JMH;
  • 17)压力测试:JMeter。

4、初步架构设计

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

 

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

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

5、架构设计优化

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

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

对比两图可以看出,在屏蔽掉技术实现细节的前提下,我们将对业务的校验和流量管控进行前置化,放大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和取模运算,使其尽量均匀分布到集群中的每一个服务实例上。

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

6、容器化架构设计

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

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

1)基础支撑服务:基础支撑服务会由各种基础中间件、数据存储服务、以及监控服务实现,包含:MySQL数据库、TiDB数据库、HBase、Redis缓存、RocketMQ消息队列、Prometheus监控和Portainer容器管理等基础中间件实现,基础支撑服务会对整个分布式IM即时通讯系统提供最基础的数据、传输、监控和容器管理等服务。

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

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

7、DDD分层业务架构设计

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

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

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

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

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

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

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

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

8、总体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和终端从缓存中获取到用户的连接信息,向目标用户推送消息。

9、IM单聊交互链路

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

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

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

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

可以看到,用户A向用户B发送消息时:

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

10、IM群聊交互链路

群聊就是在分布式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即时通讯系统了吗?

11、相关资料

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

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

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

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

[5] 移动端IM中大规模群消息的推送如何保证效率、实时性?

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

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

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

[9] 企业微信的IM架构设计揭秘:消息模型、万人群、已读回执、消息撤回等

[10] 融云技术分享:全面揭秘亿级IM消息的可靠投递机制

[11] 阿里IM技术分享(三):闲鱼亿级IM消息系统的架构演进之路

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

[13] 跟着源码学IM(十):基于Netty,搭建高性能IM集群(含技术思路+源码)

[14] 一套十万级TPS的IM综合消息系统的架构实践与思考

[15] 得物从0到1自研客服IM系统的技术实践之路

[16] 海量用户IM聊天室的架构设计与实践

[17] 史上最通俗Netty入门长文:基本介绍、环境搭建、动手实战

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

[19] 写给初学者:Java高性能NIO框架Netty的学习方法和进阶策略

[20] 手把手教你用Netty实现网络通信程序的心跳机制、断线重连机制

[21] 史上最强Java NIO入门:担心从入门到放弃的,请读这篇!

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

posted @ 2023-12-21 11:29 Jack Jiang 阅读(58) | 评论 (0)编辑 收藏

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

[- 1 -] 新手入门一篇就够:从零开发移动端IM

[链接] http://www.52im.net/thread-464-1-1.html

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

[- 2 -] 移动端IM开发者必读(一):通俗易懂,理解移动网络的“弱”和“慢”

[链接] http://www.52im.net/thread-1587-1-1.html

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

[- 3 -] 移动端IM开发者必读(二):史上最全移动弱网络优化方法总结

[链接] http://www.52im.net/thread-1588-1-1.html

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

[- 4 -] 从客户端的角度来谈谈移动端IM的消息可靠性和送达机制

[链接] http://www.52im.net/thread-1470-1-1.html

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

[- 5 -] 现代移动端网络短连接的优化手段总结:请求速度、弱网适应、安全保障

[链接] http://www.52im.net/thread-1413-1-1.html

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

[- 6 -] 腾讯技术分享:社交网络图片的带宽压缩技术演进之路

[链接] http://www.52im.net/thread-1391-1-1.html

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

[- 7 -] 小白必读:闲话HTTP短连接中的Session和Token

[链接] http://www.52im.net/thread-1686-1-1.html

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

[- 8 -] IM开发基础知识补课:正确理解前置HTTP SSO单点登录接口的原理

[链接] http://www.52im.net/thread-1351-1-1.html

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

[- -]  移动端IM中大规模群消息的推送如何保证效率、实时性?

[链接] http://www.52im.net/thread-1221-1-1.html

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

[- 10 -] 移动端IM开发需要面对的技术问题

[链接] http://www.52im.net/thread-133-1-1.html

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

[- 11 -] 开发IM是自己设计协议用字节流好还是字符流好?

[链接] http://www.52im.net/thread-150-1-1.html

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

[- 12 -] 请问有人知道语音留言聊天的主流实现方式吗?

[链接] http://www.52im.net/thread-175-1-1.html

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

[- 13 -] IM消息送达保证机制实现(一):保证在线实时消息的可靠投递

[链接] http://www.52im.net/thread-294-1-1.html

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

[- 14 -] IM消息送达保证机制实现(二):保证离线消息的可靠投递

[链接] http://www.52im.net/thread-594-1-1.html

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

[- 15 -] 如何保证IM实时消息的“时序性”与“一致性”?

[链接] http://www.52im.net/thread-714-1-1.html

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

[- 16 -] 一个低成本确保IM消息时序的方法探讨

[链接] http://www.52im.net/thread-866-1-1.html

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

[- 17 -] IM单聊和群聊中的在线状态同步应该用“推”还是“拉”?

[链接] http://www.52im.net/thread-715-1-1.html

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

[- 18 -] IM群聊消息如此复杂,如何保证不丢不重?

[链接] http://www.52im.net/thread-753-1-1.html

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

👉52im社区本周新文:《一套分布式IM即时通讯系统的技术选型和架构设计》,欢迎阅读!👈

我是Jack Jiang,我为自已带盐!https://github.com/JackJiang2011/MobileIMSDK/

posted @ 2023-12-21 10:30 Jack Jiang 阅读(49) | 评论 (0)编辑 收藏

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

1、引言

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

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

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

 
 
技术交流:

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

2、系列文章

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

即时通讯安全篇(一):正确地理解和使用Android端加密算法

即时通讯安全篇(二):探讨组合加密算法在IM中的应用

即时通讯安全篇(三):常用加解密算法与通讯安全讲解

即时通讯安全篇(四):实例分析Android中密钥硬编码的风险

即时通讯安全篇(五):对称加密技术在Android平台上的应用实践

即时通讯安全篇(六):非对称加密技术的原理与应用实践

即时通讯安全篇(七):用JWT技术解决IM系统Socket长连接的身份认证痛点

即时通讯安全篇(八):如果这样来理解HTTPS原理,一篇就够了

即时通讯安全篇(九):你知道,HTTPS用的是对称加密还是非对称加密?

即时通讯安全篇(十):为什么要用HTTPS?深入浅出,探密短连接的安全性

即时通讯安全篇(十一):IM聊天系统安全手段之通信连接层加密技术

即时通讯安全篇(十二):IM聊天系统安全手段之传输内容端到端加密技术

即时通讯安全篇(十三):信创必学,一文读懂什么是国密算法》(* 本文)

3、为什么需要国密算法?

3.1国密算法的产生背景

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

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

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

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

3.2国密算法的特点

国密算法具备如下特点:

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

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

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

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

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

4、国密算法应用概述

国密算法包括SM1(SCB2)、SM2、SM3、SM4、SM7、SM9以及祖冲之密码算法(ZUC)等。

其中:

  • 1)SM1、SM4、SM7、祖冲之密码(ZUC)属于对称算法;
  • 2)SM2、SM9属于非对称算法;
  • 3)SM3属于杂凑算法。

下文将主要介绍国密算法中的常用算法SM1、SM2、SM3和SM4的实现和应用。

5、SM1算法的原理和应用场景

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

SM1算法未公开,仅以IP核(Intellectual Property Core,一种预先做好的集成电路功能模块)的形式存在于芯片中。

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

6、SM2算法的实现和应用场景

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摘要算法一起使用。

7、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、SM4算法的实现和应用

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,但明文块不能并行计算,且误差会传递下去。

9、国密算法与国际标准算法的对比

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

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

 

10、国密算法的典型应用场景有哪些?

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地址转发报文。

11、相关文章

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

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

[3] IM聊天系统安全手段之通信连接层加密技术

[4] IM聊天系统安全手段之传输内容端到端加密技术

[5] 通俗易懂:一篇掌握即时通讯的消息传输安全原理

[6] 基于Netty的IM聊天加密技术学习:一文理清常见的加密概念、术语等

[7] 理论联系实际:一套典型的IM通信协议设计详解(含安全层设计)

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

[9] 手把手教你为基于Netty的IM生成自签名SSL/TLS证书


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

posted @ 2023-12-14 11:06 Jack Jiang 阅读(59) | 评论 (0)编辑 收藏

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

[- 1 -] 专访微信视频技术负责人:微信实时视频聊天技术的演进

[链接] http://www.52im.net/thread-1201-1-1.html

[摘要] 本次专访是对谷沉沉老师在即将到来的 2017ArchSummit 全球架构师峰会上,以《数亿微信视频通话背后的视频技术二三事》为题发表演讲的一次预热。


[- 2 -] 腾讯音视频实验室:使用AI黑科技实现超低码率的高清实时视频聊天

[链接] http://www.52im.net/thread-1308-1-1.html

[摘要] 腾讯音视频实验室和优图实验室X-lab的戴宇榮老师的团队联合开发的基于神经网络的实时视频超分辨率技术,在极小的神经网络模型大小的条件下,在手机实时视频通话上实现了基于机器学习的超分辨率技术,起到了主观上提升一档分辨率的效果。此技术即将应用在手机QQ 7.3.5的iOS版本上的实时视频聊天。


[- 3 -] 微信团队分享:微信每日亿次实时音视频聊天背后的技术解密

[链接] http://www.52im.net/thread-1311-1-1.html

[摘要] 本文将为大家介绍微信实时音视频聊天在不同发展阶段的各个关键视频技术环节采用的方案,同时分享在实时音视频聊天中的视频编码器研发的方法和经验。


[- 4 -]福利贴:最全实时音视频开发要用到的开源工程汇总

[链接] http://www.52im.net/thread-1395-1-1.html

[摘要] 本文汇总了一些能帮助到正在学习或进行实时音视频开发的同行们的开源工程,这些工程分为几类:音视频编解码类、视频前后处理、服务端类等,希望能加速您的学习或研究过程。


[- 5 -] 实时音视频聊天中超低延迟架构的思考与技术实践

[链接] http://www.52im.net/thread-1465-1-1.html

[摘要] 从直播在线上抓娃娃,不断变化的是玩法的创新,始终不变的是对超低延迟的苛求。实时架构是超低延迟的基石,如何在信源编码、信道编码和实时传输整个链条来构建实时架构?在实时架构的基础之上,如果通过优化采集、编码、传输、解码和渲染中的关键环节来降低延迟?本文将会介绍即构在这方面的思考与实践。


[- 6 -] 理解实时音视频聊天中的延时问题一篇就够

[链接] http://www.52im.net/thread-1553-1-1.html

[摘要] 音视频实时通讯的应用场景已经随处可见,从“吃鸡”的语音对讲、直播连麦、直播答题组队开黑,再到银行视频开户等。对于开发者来讲,除了关注如何能快速实现不同应用场景重点额音视频通讯,另一个更需要关注的可能就是“低延时”。但是,到底实时音视频传输延时应该如何“低”,才能满足你的应用场景呢?


[- 7 -] 写给小白的实时音视频技术入门提纲

[链接] http://www.52im.net/thread-1620-1-1.html

[摘要] 本文是由一篇演讲稿整理出来的文章,目标读者是对实时音视频开发感兴趣但是又不知道如何下手的初学者们,对大家有所帮助。


[- 8 -] 微信多媒体团队访谈:音视频开发的学习、微信的音视频技术和挑战等

[链接] http://www.52im.net/thread-1746-1-1.html

[摘要] 腾讯多媒体内核中心高级研究员时永方接受了LiveVideoStack的邮件采访,谈及了个人成长中的关键时刻,学习多媒体开发的三点核心,以及在5G和高清时代下,微信多媒体团队面临的挑战。


[- 9 -]  腾讯技术分享:微信小程序音视频技术背后的故事

[链接] http://www.52im.net/thread-1799-1-1.html

[摘要] 本文来自腾讯视频云终端技术总监rexchang(常青)的技术分享,讲述的是微信小程序中音视频技术构思、设计和实现等方方面的内容,希望能为你的音视频技术实践带来启发。


[- 10 -] 微信多媒体团队梁俊斌访谈:聊一聊我所了解的音视频技术

[链接] http://www.52im.net/thread-1828-1-1.html

[摘要] 从华为2012实验室到腾讯,过去十余年梁俊斌一直专注在音频技术。他告诉LiveVideoStack:音频技术还有许多难点需要解决,而作为技术人也延展到应用场景,关注用户需求。本文整理了本次访谈的主要内容,仅供参阅。


[- 11 -] 新浪微博技术分享:微博短视频服务的优化实践之路

[链接] http://www.52im.net/thread-1843-1-1.html

[摘要] 本文的短视频技术跟IM的单聊、群聊、朋友圈里的小视频是类似的东西,文中针对短视频的相关优化实践可以为您的IM小视频开发提供一定的参考和借鉴意义,希望对您有用。


[- 12 -] 以网游服务端的网络接入层设计为例,理解实时通信的技术挑战

[链接] http://www.52im.net/thread-1915-1-1.html

[摘要] 本文将尝试从开发者角度:梳理开发网游服务端的网络接入层的过程中面临的各种技术挑战,并针对性地提供相应的实时通信网络接入层解决思路,希望对于即时通讯应用的开发者来说,可以从中得到些许启发。


[- 13 -] 腾讯技术分享:微信小程序音视频与WebRTC互通的技术思路和实践

[链接] http://www.52im.net/thread-1988-1-1.html

[摘要] 本文来自腾讯视频云终端技术总监rexchang(常青)技术分享,内容分别介绍了微信小程序视音视频和WebRTC的技术特征、差异等,并针对两者的技术差异分享和总结了微信小程序视音视频和WebRTC互通的实现思路以及技术方案。希望能带给你启发。


[- 14 -] 爱奇艺技术分享:轻松诙谐,讲解视频编解码技术的过去、现在和将来

[链接] http://www.52im.net/thread-3028-1-1.html

[摘要] 本文以轻松幽默的语气,讲解了视频编解码的一些基本常识,并以爱奇艺为例,讲述了视频编解码技术在国内的发展以及未来的一些展望。


[- 15 -] 零基础入门:实时音视频技术基础知识全面盘点

[链接] http://www.52im.net/thread-3079-1-1.html

[摘要] 本文是作者自已根据入门实时音视频的亲身经历,对于基础知识点的认知总结。虽然很浅显,但相对小白来说,能稍微系统的了解这些概念就已经是很好的起点了。


[- 16 -] 实时音视频面视必备:快速掌握11个视频技术相关的基础概念

[链接] http://www.52im.net/thread-3194-1-1.html

[摘要] 本文将通过通俗的文字,言简意赅地为你讲解实时音视频技术中跟视频技术在关的11个非常重要的基础知识概念,希望能为你日后从事这方面的工作起到抛砖引玉的作用。


[- 17 -] 实时音视频开发理论必备:如何省流量?视频高度压缩背后的预测技术

[链接] http://www.52im.net/thread-3581-1-1.html

[摘要] 本文将从视频编解码技术的基础知识入手,引出视频编解码技术中非常基础且重要的预测技术,学习帧内预测和帧间预测的技术原理。


👉52im社区本周新文:《即时通讯安全篇(十三):信创必学,一文读懂什么是国密算法》,欢迎阅读!👈

我是Jack Jiang,我为自已带盐!https://github.com/JackJiang2011/MobileIMSDK/

posted @ 2023-12-13 11:57 Jack Jiang 阅读(63) | 评论 (0)编辑 收藏

一、关于RainbowChat-Web

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

二、v6.0 版更新内容

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

  • 1)[bug][服务端] - 解决了群成员从首页“消息”列表中删除已解散群的item时没有反应的问题;
  • 2)[新增][服务端] - 安全提升,实现了一套新的token生成、校验机制(支持对称加密和非对称加密两种模式);
  • 3)[新增][服务端] - 安全提升,启用了AppKey校验机制;
  • 4)[新增][前端]    - 优化了http接口、文件上传接口校验逻辑,提升安全性;
  • 5)[新增][前端]    - 安全提升,启用了AppKey校验机制;
  • 6)[新增][前端]    - 新增发送“群名片”消息功能;
  • 7)[新增][前端]    - 新增了消息转发功能;
  • 8)[优化][前端]    - 其它细节优化等。

三、v6.0 版新增特性截图

“群名片”功能运行截图查看演示视频更多运行截图):

“消息转发”功能(查看演示视频更多运行截图):

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

仅列出标题
共43页: 上一页 1 2 3 4 5 6 7 8 9 下一页 Last 
Jack Jiang的 Mail: jb2011@163.com, 联系QQ: 413980957, 微信: hellojackjiang