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

本文原文内容来自InfoQ的技术分享,本次有修订、勘误和加工,感谢原作者的分享。

1、前言

自从2018年8月20日子弹短信在锤子发布会露面之后(详见《老罗最新发布了“子弹短信”这款IM,主打熟人社交能否对标微信?》),关于它的讨论不绝于耳,7 天融资 1.5 亿的传闻更是将它推到了风口浪尖(请见《[资讯] “子弹短信”发布一周即融得1.5亿资金》)。

 
▲ 嗯,这个牛逼老罗可以吹很久

同时很多技术人开始分析它的代码,挖出了它的 IM 系统其实不是自研,而是使用网易云信提供的第三方服务(即时通讯网注:其实子弹短信租用网易云信的SDK是共开的秘密,子弹短信官方并没有回避)。

 
▲ 子弹短信火了之后,网易云信也狠狠地蹭了几次热点

有人质疑说,第三方的 SDK 做一个 demo 跑跑还可以,能拿来开发正式产品吗?其实,在实时通信领域,近年来的研发重点并不是即时通讯技术本身,而是由直播带火的实时音视频技术。随着 5G 的到来,WebRTC、SD-RTN、AV1 等新兴技术正在快速的发展当中。相对来说,即时通讯的技术已经比较成熟了,据了解,从子弹短信上线以来,到现在近 800 万激活用户,其服务一直保持稳定运行中。

子弹短信背后的网易云信即可作为一个研究的案例,本文内容来自对网易云信首席架构师周梁伟的采访,采访内容主要围绕网易云信这种海量用户IM云平台的关键技术难点以及对应的技术实践。

言归正传,我们往下看正经内容。。。

学习交流:

- 即时通讯开发交流3群:185926912[推荐]

- 移动端IM开发入门文章:《新手入门一篇就够:从零开发移动端IM》

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

2、IM 开发当中的技术难点

周梁伟介绍,子弹短信目前主要使用网易云信的功能有:

1)即时通信的核心功能,比如 IM 的移动通信,包括图片、文件等等;

2)同时也使用了视频通话的功能,包括点对点,以及群聊形式的视频和语音通话。

在发布会的介绍中重点演示的语言转文字功能并非网易云信提供,据猜测应该使用的是锤子手机之前使用过的语音处理服务提供商科大讯飞提供的功能。

对于 IM,更关注的是社交产品用户体验层面的东西。具体来说就是怎么构建一个更好的沟通逻辑,更快速的帮助用户达到更好的沟通效果?这其实也是子弹短信瞬间能够火起来的重要原因。所以,IM 开发中的技术难点就在于对用户体验的追求。

首先:IM 核心关注点一是消息传输的速度要快,涉及延时方面的问题;第二个是要保证消息的送达率。同时,现在用户的设备多样化,IM 通常需要支持多设备,又涉及到一个多终端消息同步的问题。

其次:IM 产品的用户量和活跃度通常都很大,在一些特殊的时间点经常容易造成流量的波峰,因此技术上需要能够应对突发的量级。所以在前期需要设计好弹性扩容,对系统的伸缩能力提前做好设计。

最后:IM 包含用户的大量隐私,一旦被黑客攻破不堪设想,同时在公共安全方面的影响也越来越受重视,因此很多 IM 产品都投入精力做内容安全、平台可控方面的工作。

本节内容中,涉及IM消息送达保证方面的技术,请深入阅读以下文章:

《从客户端的角度来谈谈移动端IM的消息可靠性和送达机制》

《IM消息送达保证机制实现(一):保证在线实时消息的可靠投递》

《IM消息送达保证机制实现(二):保证离线消息的可靠投递》

《IM群聊消息如此复杂,如何保证不丢不重?》

《完全自已开发的IM该如何设计“失败重试”机制?》

涉及IM消息送达效率的资料,请深入阅读以下文章:

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

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

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

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

涉及IM高性能架构方面的资料,请深入阅读以下文章:

《浅谈IM系统的架构设计》

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

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

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

《从零到卓越:京东客服即时通讯系统的技术架构演进历程》

《蘑菇街即时通讯/IM服务器开发之架构选择》

《腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT》

《微信后台基于时间序的海量数据冷热分级架构设计实践》

《腾讯资深架构师干货总结:一文读懂大型分布式系统设计的方方面面》

《以微博类应用场景为例,总结海量社交系统的架构设计步骤》

《快速理解高性能HTTP服务端的负载均衡技术原理》

有关IM通信安全的资料,请深入阅读以下文章:

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

《传输层安全协议SSL/TLS的Java平台实现简介和Demo演示》

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

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

《来自阿里OpenIM:打造安全可靠即时通讯服务的技术实践分享》

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

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

>> 更多同类文章 ……

3、IM 通信协议设计的考量

其实在上面没有提到一点,也是在 IM 中最为核心的一点,就是通信协议的开发。

在这方面,目前行业里有一些开源的方案如 XMPP、MQTT 等(MQTT请见《扫盲贴:认识MQTT通信协议》)。但是,这些开源的方案对后期产品的增长,用户量级的突发式爆增是非常不利的。

开源通信协议的劣势主要有几方面:

1)这些开源项目出现的较早,其实并没有考虑到移动互联网 2/3/4G 等复杂的网络情况,包括应对电信运营商在信令等方面的复杂设置;

2)目前鲜有对这些开源技术软件和服务把控度比较强的技术团队,难以进行源码级的扩展和修改,出现问题也难以及时解决;

3)商业化 IM 里消息的传递在过程中是否安全可控是非常核心的要求,如果使用一些标准的协议,就代表了这个东西是开放的,也就是说是有能够被破解的潜在风险,在企业服务场景里有些企业也因此而拒绝通信协议的开源。

有鉴于此,市面上注流的IM包括 QQ、微信等在内的,通信协议都是自研的。

 

▲ 市面上部分主流IM的通信协议(本图来自《史上最全即时通讯软件简史(精编大图版)[附件下载]》)

一个成熟的通信协议都是多年经验沉淀下来的,网易云信的 IM 服务并不是凭空产生,而是继承了之前网易泡泡、易信的技术。对于通信协议需要关注的地方,周梁伟介绍,云信的私有协议首先关注几个层面,一是安全性,也就是通信过程中所有数据序列化的算法、加密的机制,以及加密的级别,全都是自己定义的。同时也考虑到,在整个传输的过程中可能长期存在的安全风险,比方第三方的攻击,以及数据在网络流转过程中被拷贝和重放的潜在安全风险,这些在设计过程中都需要被规避掉。

第二个,因为现在即时通信更多的往移动互联网方向发展,用户的网络环境具有非常强的多变性,经常属于跨网和弱网的环境下,所以传输协议非常关注对消息的压缩,以及网络带宽的占用,网易云信在这方面也做了很多的工作。这也和标准协议有差别,标准协议的消息结构都是 JSON 或 XML 格式,承载同样的有效内容,最终呈现出来的消息体会变得非常庞大,但在这一块私有协议可以做得非常好。

还有一个很重要的方面是私有协议对扩展性的支持,传统的协议不能做到很好的扩展,或者做完扩展后整个消息会变得非常大。对私有协议来说,可以随时的做各种场景的定义、各种新协议的增加和各种版本的兼容。

其实目前业务主流IM,使用的私有协议格式基本都是基于Google开源的Protobuf(或者改进优化分支,比如微信就是基本Profobuf优化后的分支)。

有关Protobuf的文章,请深入阅读以下内容:

《Protobuf通信协议详解:代码演示、详细原理介绍等》

《如何选择即时通讯应用的数据传输格式》

《强列建议将Protobuf作为你的即时通讯应用数据传输格式》

《全方位评测:Protobuf性能到底有没有比JSON快5倍?》

《移动端IM开发需要面对的技术问题(含通信协议选择)》

《金蝶随手记团队分享:还在用JSON? Protobuf让数据传输更省更快(原理篇)》

《金蝶随手记团队分享:还在用JSON? Protobuf让数据传输更省更快(实战篇)》

4、如何做到IM消息的高到达率和低延迟

对一个 IM 平台来说,到达率和即时性是两个核心功能点。对于消息传输机制的设计来说,首先设计的时候把 100% 的送达率作为一个核心要求,关键性的指标,要抱着必须要达到的态度来设计。

主要的技术手段是通过不同消息类型的相互组合来补充。

消息类型分为以下几种:

1)一种是在线消息:在线消息是指双方用户都处于实时在线的情况,在网络中实时送达;

2)另一个是离线消息:如果用户当时不在线,可能处于暂时离线的状态,我们把消息在缓存中存下来,缓存的消息可以保证更高的读取效率,用户下次上线的时候可以很快的取回来。

但仅仅靠在线和缓存是不够的,因为缓存可能会丢,网络可能出现会丢包,所以我们在数据库里储存关键消息。这类的消息是强一致性的要求,用户发送完成之后,服务端必须要确认数据被存入关键数据库里,否则客户端上的表现是消息未发送成功,是可以触发到上层去从事这种机制的。

存在数据库里的消息,用户可以在更长时间的离线以后实时同步,即使缓存里没有也可以拿到。另外还要考虑更长时间范畴的消息存储,应用的场景是什么呢?用户可能一个月以前开始使用这个 IM 产品,或者 1 年前使用了这个 IM 产品,现在更换手机了,更换手机以后消息如何在新手机上拿到?这种称为云端的历史消息(详见《浅谈移动端IM的多点登陆和消息漫游原理》)。

在所有消息的流转的过程中,这个消息到最后被存储在数据仓库里,数据仓库存储消息的时间维度可能是 1 年或者几年。在用户跨平台或者更换新设备之后,可以随时从云端再获取到这部分的消息。通过不同消息的相互组合之后,我们是可以达到消息 100% 送达的效果。

另外,从即时性的角度来说,现在的 IM 基本都采用长连接的方案作为消息实时送达的渠道。因为现在的移动设备对于 App 在后台的服务有限制,以前 Android 上还流行过后台保活、互相唤醒等等方式(请见《应用保活终极总结(三):Android6.0及以上的保活实践(被杀复活篇)》、《Android进程保活详解:一篇文章解决你的所有疑问》、《深入的聊聊Android消息推送这件小事》)。

不过,在 Android 系统的不断更新和手机厂商打压下,App 在后台的保活能力逐渐消失,现在基本都是接入各大推送平台,IM 消息即时性在 App 开发者这里能做的不多,主要看推送服务的实力了(Android高版本对后台保活越来越严格了,比如AndroidP的《Android P正式版即将到来:后台应用保活、消息推送的真正噩梦》)。

5、IM 实时消息监控和分析

有一个以前人们不怎么提,但实际存在的问题,就是 IM 的合规。IM 是谣言等不良信息的高发地,在印度,WhatsApp 上谣言流传致使私刑案频发,到目前印度官方仍束手无策。

周梁伟介绍,IM 通信平台目前承载很多很重要的功能是传统运营商做的部分业务。以前我们用短信、电话,现在大家转移到即时通信的工具上,对监管层来说是有要求的。从平台角度来说,本身做的是一个消息通道的功能,消息就代表了会有舆论的传播,特别在群组或者聊天室这样参与者众多的状态下,所以舆论监管对平台来说是必须承担的责任,这是监管层面对平台运营方的要求。平台必须具备内容审核的能力,云信会按照开发者的配置把平台上产生的内容在云端保存起来,以备监管层随时做内容的审核。

同时在开发者 APP 运营的层面,内容运营或者内容审核、内容安全运营都是非常重要的范畴,目前网易云信和子弹短信在一起合作解决这样的问题。网易云信有一个专门的团队会负责内容审核的工作,包括会对所有的数据提取特征,会去做同步的、实时的内容审核,以及异步的内容审核,甚至涉及到机器学习的功能和人工介入审核的工作。

从技术层面来说,关于内容审核,目前用到产品上有两种场景,一种是同步审核,在消息发送过程中,这个消息就可以直接进入到内容审核系统里进行识别,如果识别出来有敏感词或者安全风险,会直接拦截掉。在第一时间避免消息的传播。还有一种内容,用户发的视频文件和非常大的图片,像这样的内容做实时审核会带来比较高的时间成本,这种情况下云信目前的做法是采用异步审核,消息投递出去了会进入审核系统,里面有机器算法的部分和人工审核的部分去进行鉴别,一旦审核出此消息违规,会触发 IM 消息撤回和删除的能力,避免风险的二次传播。

6、如何保证IM消息安全性

对 IM 来说,除了用户数据需要做安全防范外,还需要关注消息内容的安全,包括两个层面:

1)一个是:消息传输层面的安全,在传输过程中,通过协议和加密,以保证传输过程中的消息是不可逆的。恶意用户即使抓到网络传输的包也没有办法破译出来;

2)另一个:加密级别做到会话级别,是指一个用户的一次长链接行为,即使同一个用户多次登录,或者在不同时间点登录,加密的密钥都是不一样的。所以能够保证传输过程中是安全的。

第二个维度是,消息存储过程中是安全的,这里分为几个角度:

1)是对数据做自定义的序列化的方式,包括数据存储后,序列化或反序列化过程中的效率更高;

2)是如果泄露,是不可见、不可读的。另外,对于关键数据需要做加密,避免出现拖库之类的行为。

即时通讯网注:什么是黑客拖库?

拖库本来是数据库领域的术语,指从数据库中导出数据。到了黑客攻击泛滥的今天,它被用来指网站遭到入侵后,黑客窃取其数据库。

拖库可以通过数据库安全防护技术解决,数据库安全技术主要包括:数据库漏扫、数据库加密、数据库防火墙、数据脱敏、数据库安全审计系统。

另外,周梁伟表示,用户怎么使用云平台才能在过程中保证业务数据的安全,一般他们会建议,在使用平台的时候对业务数据做脱敏。比如说开发者自己的平台是用用户的手机号作为用户账号的,在云信里面注册用户的账号的时候,可以在业务层做一个关联。使用随机数或者随机的、无意义的字符串作为云平台数据库里的 ID,手机号的映射关系仅仅在业务方。通过这种脱敏保证数据的安全。

有关IM安全方面的文章,请深入阅读:

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

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

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

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

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

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

《传输层安全协议SSL/TLS的Java平台实现简介和Demo演示》

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

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

《来自阿里OpenIM:打造安全可靠即时通讯服务的技术实践分享》

《简述实时音视频聊天中端到端加密(E2EE)的工作原理》

《移动端安全通信的利器——端到端加密(E2EE)技术详解》

《Web端即时通讯安全:跨站点WebSocket劫持漏洞详解(含示例代码)》

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

《IM开发基础知识补课(四):正确理解HTTP短连接中的Cookie、Session和Token》

《快速读懂量子通信、量子加密技术》

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

>> 更多同类文章 ……

7、本文小结

看完上面的内容,想必你对 IM 系统研发会遇到哪些问题,以及相应的解决方案有了大致的概念。当然这里只提到了其中的一些,还有其它方面,比如不同用户量级的系统需要不同的架构,QQ 在它的发展过程中就经历多次重构,感兴趣的可以继续阅读下面的文章。

《腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT》

《微信后台基于时间序的海量数据冷热分级架构设计实践》

《微信技术总监谈架构:微信之道——大道至简(演讲全文)》

《如何解读《微信技术总监谈架构:微信之道——大道至简》》

《快速裂变:见证微信强大后台架构从0到1的演进历程(一)》

《17年的实践:腾讯海量产品的技术方法论》

《WhatsApp技术实践分享:32人工程团队创造的技术神话》

《微信朋友圈千亿访问量背后的技术挑战和实践总结》

《王者荣耀2亿用户量的背后:产品定位、技术架构、网络方案等》

《以微博类应用场景为例,总结海量社交系统的架构设计步骤》

《微信后台基于时间序的海量数据冷热分级架构设计实践》

《微信后台团队:微信后台异步消息队列的优化升级实践分享》

《一份微信后台技术架构的总结性笔记》

《架构之道:3个程序员成就微信朋友圈日均10亿发布量[有视频]》

《快速裂变:见证微信强大后台架构从0到1的演进历程(一)》

《快速裂变:见证微信强大后台架构从0到1的演进历程(二)》

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

相关推荐

鸿蒙原生即时通讯/IM系统RainbowTalk v2.8版发布,基于MobileIMSDK框架、ArkTS编写

💧 此版本解决了若干bug,以及ui和功能细节优化,同时支持最新鸿蒙7.0系统。

hellojackjiang2011的博客 165

深度剖析IM消息乱序的根本原因及优化方法

本文深度剖析即时通讯IM消息乱序的问题,梳理IM客户端时间戳不可信、多端并发、群消息扇出重试三大核心陷阱,拆解微信、钉钉、企业微信的时序设计方案,并从锚点设计、多端去交错、幂等兜底、可观测性等维度,给出IM项目消息时序性保证的落地优化策略。

hellojackjiang2011的博客 293

IM聊天不掉线?生产级WebSocket断线重连、心跳保活实战

本文将给出一套生产级Web端即时通信方案,包括心跳检测保活 + 指数退避重连,代码直接能跑。

hellojackjiang2011的博客 325

IM全文检索技术(五):vivo敏感词匹配系统的技术实践

本文将从算法选型入手,结合两个实际场景来介绍谛听系统的敏感词匹配算法。包括底层算法选型思路和两种实际场景下提升敏感词精准度、降低漏杀率的方案。

hellojackjiang2011的博客 189

Nginx生产级WebSocket实时长连接负载均衡,一文搞定

本文从基础配置、生产配置、Docker / K8s、安全、排障、性能调优,系统性讲清 WebSocket 在 Nginx 中的正确打开方式。

hellojackjiang2011的博客 308

即时通讯IM离线消息该怎么存?全面盘点主流存储方案

离线消息是IM系统的核心能力,当用户不在线时,消息必须可靠存储,待用户上线后完整推送。本文将对比主流的离线消息存储方案,帮你找到最适合业务场景的架构。

hellojackjiang2011的博客 310

移动端实时音视频聊天框架 RainbowAV v2.2.7发布

1)

hellojackjiang2011的博客 247

都HTML5了,Web端即时通讯技术到底该用什么?一文即懂!

本文分享的是 Web 端最常用即时通讯技术(包括 WebSocket、SSE、WebRTC、轮询等)的原理、优缺点与适用场景等,以及生产环境下的高并发场景下的进阶实践。

hellojackjiang2011的博客 341

基于开源MobileIMSDK框架,即时通讯IM产品RainbowChat v12.1发布

此版本新增了短信验证码的注册和登录功能,解决了Android 16手机上发送文件失败等问题。

hellojackjiang2011的博客 209

IM千人群聊该不该用消息写扩散?详细算算成本账!

本文将为你详解 IM 群聊消息的写扩散技术原理以及写扩散过程中的服务端详细性能成本,同时对比了市面上IM大厂的技术方案,给出分规模架构选型与以及性能优化策略等。

hellojackjiang2011的博客 402

直播系统聊天技术(十):基于实时消息总线的活动系统架构设计

本文分享的是网易云音乐技术团队基于实时消息总线技术,解决了直播活动系统的模块灵活组合、消息治理与异步履约等问题,希望能给你带来启发。

hellojackjiang2011的博客 369

轻量级Web端IM即时通讯框架MobileIMSDK-Web,基于Socket.io库

MobileIMSDK-Web是一套Web端即时通讯框架,超轻量级、极少依赖,高度提炼、简单易用。

hellojackjiang2011的博客 286

socket长连接在手游场景下的技术实践

本文介绍了37手游基于B站goim框架自研长连接系统的实践。系统采用分层设计,支持多协议和发布/订阅机制,用于直播弹幕、实时推送等场景,实现了高性能与业务适配。

hellojackjiang2011的博客 404

基于开源MobileIMSDK框架,即时通讯IM产品RainbowChat v12.0发布

RainbowChat 是一套基于 MobileIMSDK 开源通信框架的产品级移动端IM系统。可能是市面上开放源码的,唯一一款同时支持TCP、UDP、WebSocket三种网络通信协议的IM产品。

hellojackjiang2011的博客 518

社交场景下的统一即时通讯im消息流交互层模块化技术实践

这些IM场景,在消息流的展示形式上是极为相似的,同时每个业务又有着自己特殊的交互需求。基于此,我们对IM消息流能力做了标准化的构建,来减少IM功能的业务接入成本;同时也是为了统一各个业务的技术方案,减少跨业务开发的理解和维护成本。

hellojackjiang2011的博客 572

现代IM系统中聊天消息的同步和存储方案探讨

本文内容主要涉及IM系统中的消息系统架构,探讨一种适用于大用户量的消息同步以及存储系统的架构实现,能够支持消息系统中的高级特性“多端同步”以及“消息漫游”。在性能和规模上,能够做到全量消息云端存储,百万TPS以及毫秒级延迟的消息同步能力。

hellojackjiang2011的博客 75

即时通讯安全篇(十六):对称加密 vs 非对称加密?一文搞懂

本文将以通俗案例讲解加密本质,介绍对称加密(含 AES、迪菲–赫尔曼密钥交换)与非对称加密(RSA)原理、特点及应用,并阐释其数学基础。

hellojackjiang2011的博客 397

网络编程入门如此简单(五):UDP跟TCP相比,到底差了什么?

本文将通俗易懂地为你类比解释UDP与TCP的核心差异,包括如何基于UDP实现TCP的可靠传输:通过模拟三次握手、添加序列号与确认机制解决顺序和丢包问题,利用滑动窗口控制流量,并引入拥塞控制算法来动态调整发送速率等。

hellojackjiang2011的博客 448

基于WebSocket的IM即时通信方案在H5游戏场景下的技术实践

本文将从H5游戏场景下的实时信息更新需求切入,探讨下在类似这种高并发、低延迟的业务需求中,如何使用 IM 方案来解决频繁的数据更新问题,也顺便介绍下 WebSocket 的基本运作流程等。

hellojackjiang2011的博客 1069

鸿蒙Next原生IM即时通讯RainbowTalk,纯ArkTS编写,基于开源MobileIMSDK框架

RainbowTalk 是一套基于 MobileIMSDK 开源通信框架的产品级纯血鸿蒙NEXT端IM系统。RainbowTalk 由纯ArkTS编写、全新开发,没有套壳、也没走捷径,原生“纯血”。

hellojackjiang2011的博客 1231

如何保障分布式IM聊天系统的消息可靠性(即消息不丢)

本文主要聚焦分布式IM聊天系统消息可靠性问题,即如何保证消息不丢失。

hellojackjiang2011的博客 732

如何保障分布式IM聊天系统的消息有序性(即消息不乱)

本篇主要总结和分享分布式IM聊天系统架构中关于消息有序性的设计和实践。

hellojackjiang2011的博客 835

B站即时通讯IM消息系统的新架构升级实践

本文要分享的是B站IM消息系统的新架构升级实践总结,内容包括原架构的问题分析,新架构的整体设计以及具体的升级实现等。

hellojackjiang2011的博客 714

AI大模型爆火的SSE技术到底是什么?万字长文,一篇读懂SSE!

本文从SSE(Server-Sent Events)技术的原理到示例代码,为你通俗易懂的讲解SSE技术的方方面面。

hellojackjiang2011的博客 787

腾讯新闻APP的消息推送Push架构技术重构实践

本文主要分享的是腾讯技术团队近年来对腾讯新闻消息推送PUSH系统做的架构优化和技术实践。

hellojackjiang2011的博客 843

移动端弱网优化专题(十五):字节跳动移动端网络HttpDNS优化实践

本文要分享的是字节跳动团队针对火山HTTPDNS Cache2.0通过自研网段库与动态划分算法,将缓存粒度从“城市-运营商”细化为“网段”,解决了传统方案的城市级调度污染问题。配合缓存分级、预取等优化,在提升调度精准度的同时保证了高命中率,最终实现了服务端调度准确性提升和客户端性能优化。

hellojackjiang2011的博客 720

转转客服IM聊天系统背后的技术挑战和实践分享

在当今互联网时代,高效的用户服务是提升用户体验的关键。转转自研的客服IM聊天系统作为用户与客服沟通的桥梁,承担着传递信息、解决问题的关键角色。然而,消息数据的流转并非一帆风顺,本文将深入探讨IM系统在消息传递过程中遇到的问题和挑战,以及相应的技术解决方案。

hellojackjiang2011的博客 1096

ChatGPT如何实现聊天一样的实时交互?快速读懂SSE实时“推”技术

本文将带你快速认识SSE实时通信协议,包括它的技术原理、常见使用场景、与同类技术的对比以及简单的示例代码等。

hellojackjiang2011的博客 124

全面适配iOS 26液态玻璃,基于开源IM即时通讯框架MobileIMSDK:RainbowChat-iOS端v10.2发布

RainbowChat是一套基于开源IM即时通讯聊天框架 MobileIMSDK 的产品级移动端IM系统。

hellojackjiang2011的博客 1157

可靠传输的TCP协议send成功就意味着数据一定发出去了?

本篇文章我们以TCP协议的网络编程逻辑,从Socket缓冲区的角度去拆解,为什么号称可靠传输的TCP协议,在代码中调用send并成功发出数据,并不意味着这个数据就一定通过物理网络发出去了。

hellojackjiang2011的博客 125
上一篇: QQ现状深度剖析:你还认为QQ已经被微信打败了吗?
下一篇: 迈向高阶:优秀Android程序员必知必会的网络基础
jackjiang2025
jackjiang2025 网际时代技术分享账号 网际时代技术分享账号
博客等级 码龄8年 700粉丝 318原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值