去年初，突如其来的新冠肺炎疫情让线下就医渠道几乎被切断，在此背景下，在线问诊模式快速解决了大量急需就医病患的燃眉之急。而作为在线问诊中重要的一环——医患之间的视频问诊正是应用了实时音视频技术才得以实现。

对Feed流的定义，可以简单理解为只要大拇指不停地往下划手机屏幕，就有一条条的信息不断涌现出来。就像给牲畜喂饲料一样，只要它吃光了就要不断再往里加，故此得名Feed（饲养）。

传统意义上来说，实时消息推送通常都是IM即时通讯这类应用的技术范畴，随着移动端互联网的普及，人人拥有手机、随时都是“在线”已属常态，于是消息的实时触达能力获得了广泛的需求，已经不再局限于IM即时通讯这类应用中。

类似于IM中的聊天记录查找、联系人搜索这类功能，有了全文检索能力后，确实能大大提高内容查找的效率，不然，让用户手动翻找，确实降低了用户体验。

综合考虑业务场景、系统复杂度、网络流量、终端能耗等，我们的亿级分布式IM消息系统精心设计了消息收发机制，并不断打磨优化，形成了现在的消息可靠投递机制。

本次为主要版本更新（本次更新内容见文末“MobileIMSDK v6.0更新内容 ”一节），强势升级，将同时支持TCP、UDP、WebSocket三种协议，精心封装之下，实现同一套API、三种协议同时并存。

本文总结了企业微信的IM消息系统架构设计，阐述了企业业务给IM架构设计带来的技术难点和挑战，以及技术方案的对比与分析。同时总结了IM后台开发的一些常用手段，适用于IM消息系统。

Andriod端比较奇葩（主要指国内的手机），为了实现离线推送，各种保活黑科技层出不穷，随着保活难度的不断升级，可以使用的保活手段也是越来越少，有兴趣可以读一读我整理的下面这些文章，感受一下（文章是按时间顺序，随着Andriod系统保活难度的提升，不断进阶的）。

本文总结了阿里闲鱼技术团队使用Flutter在对闲鱼IM进行移动端跨端改造过程中的技术实践等，文中对比了传统Native与现在大热的Flutter跨端方案在一些主要技术实现上的差异，以及针对Flutter技术特点的具体技术实现，值得同样准备使用Flutter开发IM的技术同行们借鉴和参考。

这次的文章由作者张彦飞原创分享，写作本文的原因是现在本机网络 IO 应用非常广。在 php 中 一般 Nginx 和 php-fpm 是通过 127.0.0.1 来进行通信的；在微服务中，由于 side car 模式的应用，本机网络请求更是越来越多。所以，如果能深度理解这个问题在各种网络通信应用的技术实践中将非常的有意义。

近期，微信小游戏支持了视频号一键开播，将微信升级到最新版本，打开腾讯系小游戏（如跳一跳、欢乐斗地主等），在右上角菜单就可以看到发起直播的按钮一键成为游戏主播了（如下图所示）。

从 20 世纪 90 年代以来，数字音视频编解码技术迅速发展，一直是国内外研究的热点领域。随着5G的成熟和广泛商用，带宽已经越来越高，传输音视频变得更加容易。视频直播、视频聊天，已经完全融入了每个人的生活。

即时通讯网整理的大量IM技术文章中（见本文末“参考资料”一节），有关消息可靠性和一致性问题的文章占了很大比重，原因是IM这类系统抛开各种眼花缭乱的产品功能和技术特性，保证消息的可靠性和一致性几乎是IM产品必需的素质。

网关是一个比较成熟的产品，基本上各大互联网公司都会有网关这个中间件，来解决一些公有业务的上浮，而且能快速的更新迭代。如果没有网关，要更新一个公有特性，就要推动所有业务方都更新和发布，那是效率极低的事，有网关后，这一切都变得不是问题。

对Web端即时通讯技术熟悉的开发者来说，我们回顾网页端IM的底层通信技术，从短轮询、长轮询，到后来的SSE以及WebSocket，使用门槛越来越低（早期的长轮询Comet这类技术实际属于hack手段，使用门槛并不低），技术手段越来越先进，网页端即时通讯技术的体验也因此越来越好。

丛所周之，HTTP协议是一种无状态、基于TCP的请求/响应模式的协议，即请求只能由客户端发起、由服务端进行响应。在大多数场景，这种请求/响应的Pull模式可以满足需求。但在某些情形：例如消息推送（IM中最为常见，比如IM的离线消息推送）、实时通知等应用场景，需要实时将数据同步到客户端，这就要求服务端支持主动Push数...

本文引用了作者“大古同学”的“二维码扫码登录是什么原理”一文的主要内容，为了更好的理解和阅读，即时通讯网收录时有修订和改动，感谢原作者的分享。

本文原题“百度直播消息服务架构实践”，由百度APP消息中台团队原创分享于“百度Geek说”公众号，为了让文章内容更通俗易懂，本次已做排版优化和内容重新划分，原文链接在文末。

对于IM开发者而言，网络保活这件事再熟悉不过了，比如这是我最近一篇有关网络保活话题文章《一文读懂即时通讯应用中的网络心跳包机制：作用、原理、实现思路等》，以及我分享的大量代码实战编码中也都必须要考虑这个问题的实现，比如最近的这篇《跟着源码学IM(五)：正确理解IM长连接、心跳及重连机制，并动手实现》。

本文作者芋艿，原题“使用 Netty 实现 IM 聊天贼简单”，本底价有修订和改动。一、本文引言上篇《跟着源码学IM(七)：手把手教你用WebSocket打造Web端IM聊天》中，我们使用 WebSocket 实现了一个简单的 IM 功能，支持身份认证、私聊消息、群聊消息。然后就有人发私信，希望使用纯 Netty 实现一个类似的功能，因此就有了本文...

WebSocket如今在Web端即时通讯技术应用里使用广泛，不仅用于传统PC端的网页里，也被很多移动端开发者用于基于HTML5的混合APP里。对于想要在基于Web的应用里添加IM、推送等实时通信功能，WebSocket几乎是必须要掌握的技术。

本文将在亿级消息量、分布式IM系统这个技术前提下，分析和总结实现这套系统所需要掌握的知识点，内容没有高深的技术概念，尽量做到新手老手皆能读懂。

接上篇《一套亿级用户的IM架构技术干货(上篇)：整体架构、服务拆分等》，本文主要聚焦这套亿级用户的IM架构的一些比较细节但很重要的热门问题上，比如：消息可靠性、消息有序性、数据安全性、移动端弱网问题等。

经历过稍有些规模的IM系统开发的同行们都有体会，要想实现大规模并发IM（比如亿级用户和数十亿日消息量这样的规模），在架构设计上需要一些额外的考虑，尤其是要解决用户高并发、服务高可用，架构和实现细节上都需要不短时间的打磨。

随着直播和类直播场景在微信内的增长，这些业务对临时消息（在线状态时的实时消息）通道的需求日益增长，直播聊天室组件应运而生。直播聊天室组件是一个基于房间的临时消息信道，主要提供消息收发、在线状态统计等功能。

作为即时通讯技术的开发者来说，高性能、高并发相关的技术概念早就了然与胸，什么线程池、零拷贝、多路复用、事件驱动、epoll等等名词信手拈来，又或许你对具有这些技术特征的技术框架比如：Java的Netty、Php的workman、Go的gnet等熟练掌握。但真正到了面视或者技术实践过程中遇到无法释怀的疑惑时，方知自已所掌握的不...

网络编程能力对于即时通讯技术开发者来说是基本功，而计算机网络又是网络编程的理论根基，因而深刻准确地理解计算机网络知识显然能夯实你的即时通讯应用的实践品质。本文风格类似于《网络编程懒人入门》、《脑残式网络编程入门》两个系列，但通俗又不失内涵，简洁又不简陋，非常适合对计算机网络知识有向往但又有惧怕的...

网络编程能力对于即时通讯技术开发者来说是基本功，而计算机网络又是网络编程的理论根基，因而深刻准确地理解计算机网络知识显然能夯实你的即时通讯应用的实践品质。

作为即时通讯技术的开发者来说，高性能、高并发相关的技术概念早就了然与胸，什么线程池、零拷贝、多路复用、事件驱动、epoll等等名词信手拈来，又或许你对具有这些技术特征的技术框架比如：Java的Netty、Php的workman、Go的gnet等熟练掌握。但真正到了面视或者技术实践过程中遇到无法释怀的疑惑时，方知自已所掌握的不...

作为即时通讯技术的开发者来说，高性能、高并发相关的技术概念早就了然与胸，什么线程池、零拷贝、多路复用、事件驱动、epoll等等名词信手拈来，又或许你对具有这些技术特征的技术框架比如：Java的Netty、Php的workman、Go的gnet等熟练掌握。但真正到了面视或者技术实践过程中遇到无法释怀的疑惑时，方知自已所掌握的不...