上一篇《零基础IM开发入门(二)：什么是IM系统的实时性？》讲到了IM系统的“立足”之本——“实时性”这个技术特征，本篇主要讲解IM系统中的“可靠性”这个话题，内容尽量做到只讲原理不深入展开，避开深层次的技术性探讨，确保通俗易懂。

最近正在研究 WebSocket 相关的知识，想着如何能自己实现 WebSocket 协议。到网上搜罗了一番资料后用 Node.js 实现了一个WebSocket协议服务器，倒也没有想象中那么复杂，除去注释语句和 console 语句后，大约 200 行代码左右。

自从HTML5里的WebSocket出现后，彻底改变了以往Web端即时通讯技术的基础通道这个“痛点”（在此之前，开发者们不得不弄出了诸如：短轮询、长轮询、Comet、SSE等技术，可谓苦之久矣...），如今再也不用纠结到底该用“轮询”还是“Comet”技术来保证数据的实时性了，幸福来的就是如此突然 ^-^。

本文由融云技术团队原创投稿，作者是融云WebRTC高级工程师苏道，转载请注明出处。1、引言在一个典型的IM应用里，使用实时音视频聊天功能时，视频首帧的显示，是一项很重要的用户体验指标。本文主要通过对WebRTC接收端的音视频处理过程分析，来了解和优化视频首帧的显示时间，并进行了总结和分享。（本文同步发布于：[链...

随着移动互联网络的发展，IM技术的应用已经不仅限于聊天应用本身，它早已融入各种应用形态中，比如：直播中的主播互动、联网游戏中的玩家互动、外卖/打车应用中的实时位置共享、在线教育应用中的互动白板等。

在中大型IM系统中，聊天消息的唯一ID生成策略是个很重要的技术点。不夸张的说，聊天消息ID贯穿了整个聊天生命周期的几乎每一个算法、逻辑和过程，ID生成策略的好坏有可能直接决定系统在某些技术点上的设计难易度。有中小型IM场景下，消息ID可以简单处理，反正只要唯一就行，而中大型场景下，因为要考虑到分布式的性能、...

本文由小米信息技术团队研发工程师陈刚原创，原题“当我们在谈论高并发的时候究竟在谈什么?”，为了更好的内容呈现，即时通讯网收录时有修订和改动。

本文内容编写时，参考了网上的资料，详见“参考资料”部分，感谢分享者。1、引言这个系列文章已经整理了10篇，但都没有涉及到具体的红包算法实现，主要有以下两方面原因。一方面是各社交/IM产品中的红包功能同质化严重，红包算法的“可玩性”便是“核心竞争力所在”，这是同质化功能的差异化竞争思路，不会随便公开。另一方面...

本文由手机淘宝技术团队原创分享，吴志华（天施）、洪海（孤星）、陈虓将（仲升）等专家参与了本文创作，首次发表于公众号“淘系技术”，收录整理时有修订和改动。

最近在从头重写 MobileIMSDK 的TCP版，自已组织TCP数据帧时就遇到了字节序大小端问题。所以，借这个机会单独整理了这篇文章，希望能加深大家对字节序问题的理解，加强对IM这种基于网络通信的程序在数据传输这一层的知识掌控情况。

在一个完善的即时通讯IM应用中，WebSocket是极其关键的一环，它为基于Web的即时通讯应用提供了一种全双工的通信机制。但为了提升IM等实际应用场景下的消息即时性和可靠性，我们需要克服WebSocket及其底层依赖的TCP连接对于复杂网络情况下的不稳定性，即时通讯的开发者们通常都需要为其设计一套完整的连接保活、验活以及...

本文主要以Android客户端为例，记录了有赞旗下 App 中使用自研 IM，并将IM提炼成组件化SDK的设计思路。此项工作由有赞移动开发组 IM SDK 团队共同讨论完成。

虽然网上有很多的博文总结了实时音视频技术的学习路线，但是相关的知识都相对独立，有讲“音视频解码相关”的、有讲“OpenGL相关”的、也有讲“FFmpeg相关的”、还有讲“RTP/RTCP、RTMP、HLS、QUIC等通信相关的”，但是对于新手来说，把所有的知识衔接串联起来，并很好的理解所有的知识，却是非常困难的。

IM聊天消息能保证可靠送达，对于用户来说，就好比把钱存在银行不怕被偷一样，是信任的问题。试想，如果用户能明显感知到聊天消息无法保证送达，谁还愿意来用你的APP？谁也不希望自已的话就像浮云一样随风飘逝。

IM系统看似简单（没错，很多土老板认为开发个qq和微信也就是几万块钱的事... ），实责是众多技术的应用合体，包括网络编程、移动开发、后端开发、高并发、高可用、高安全等技术范畴，再加上多端使用不同的编程语言，想要凑齐一个典型的IM产品技术栈那也不是个容易事。

以阿里的钉钉为例，钉钉的产品定位是用于商务交流，其“强制已读回执”功能，让职场人无法再“假装不在线”、“假装没收到”。更有甚者，钉钉的群聊“强制已读回执”功能，甚至能够知道谁读了消息，谁没有读消息（老板的福音啊）。

IM在Android上的保活问题经常在即时通讯网的论坛和技术群里被讨论，自从Android 8.0后系统大大降低了后台运行应用的保活容忍度（详见《Android P正式版即将到来：后台应用保活、消息推送的真正噩梦》），保活从黑科技横行的时代进入了技术蛮荒阶段，真要实现保活，技术难度越来越大。

好久没写技术文章了，今天这篇不是原理性文章，而是为大家分享一下由笔者主导开发实施的IM即时通讯聊天系统，针对大量离线消息（包括消息漫游）导致的用户体验问题的升级改造全过程。

本文并未就具体的视频编解码概念进行深入的讨论，目的是尽可能以浅显易懂的方式让读者轻松了解本文标题想呈现的内容。如果您想深入了解视频编解码技术，可继续阅读以下文章。

本文中文译文由作者“ably.io”发布于公众号“高可用架构”，译文原题：《深入解读HTTP3的原理及应用》、英文原题：《HTTP/3 deep dive》（文末有译文和原文链接），即时通讯网收录时有少许改动，感谢原作者和译者的分享。

1、引言 网络优化对于移动端App产品的用户体验至关重要，也与公司的运营和营收息息相关。 这里列举两个公开的数据： “《页面加载超过3秒，57%的用户会离开》”“《Amazon页面加载延长1秒，一年就会减少16亿美金营收》” 网络性能对于用户体验的影响，将非常直接地反馈到业务的运营上。 而且，移动网络固有的弱网问题、DNS问...

IM应用的初学者们，在补全了各种基础技术知识后（如果您仍不具备这些知识，建议马上阅读《新手入门一篇就够：从零开发移动端IM》），在动手编码实践时，很多时候纠结的并不是功能该如何实现，而是这个功能该实现成什么样（没有经验，我特玛能找谁问问？）。

本文引用了公众号“鲜枣课堂”的《5G消息（RCS），到底是什么？》和公众号“InfoQ”的《5G消息来了，它会干掉微信还是变成另一个飞信？》两篇文章的部分内容，感谢原作者的分享。

本文引用了后端技术指南针公众号“浅谈RPC那些事儿1”和即时通讯网的“即时通讯新手入门：快速理解RPC技术——基本概念、原理和用途”两篇文章的部分内容。

本文为开源工程：“github.com/GuoZhaoran/fastIM”的配套文章，原作者：“绘你一世倾城”，现为：猎豹移动php开发工程师，感谢原作者的技术分享。

2017年开春之际，阿里诚意献上重磅大礼：《阿里巴巴Java开发手册(规约)》，首次公开阿里官方Java代码规范标准。这套Java统一规范标准将有助于提高行业编码规范化水平，帮助行业人员提高开发质量和效率、大大降低代码维护成本。

本文同时发布于“即时通讯技术圈”公众号，链接是：[链接]。本文参考了公众号鲜枣课堂的“IPv6，到底是什么？”一文的部分内容，感谢原作者。 1、引言 现在IPv6的技术应用已经越来越普及了，很多应用都开始支持IPv6。 ▲ 去年开始，支付宝的官网上就已出现“支持IPv6”标识 对于即时通讯技术（尤其是IM应用）的开发者来说，新产...

本文已同时发布于我的“即时通讯技术圈”公众号。 1、引言 哈罗，大家好，我是Jack Jiang。。。（一股浓浓的自媒体视频旁白味道）。 对于经常看我文章的即时通讯开发者来说，今天要讨论的这个话题，貌似有点不着边际。 是的，自从我整理完《IM开发者的零基础通信技术入门》系列文章之后，对于网络编程的理解，开始有点飘了...

大约3年前，微信技术团队分享了《微信后台基于时间序的海量数据冷热分级架构设计实践》一文，文中总结了微信这种超级IM基于时间序的海量数据存储架构的设计实践，也得以让大家了解了微信后台的架构设计思路。

2020年春节早已过去两月有余，回顾本次腾讯手Q春节红包活动的玩法，主要以答题形式结合中国传统文化（成语、诗词、对联、历史等）的方式进行，达到寓教于乐的效果。