1、引言

京东的京麦商家后台2014年构建网关，从HTTP网关发展到TCP网关。在2016年重构完成基于Netty4.x+Protobuf3.x实现对接PC和App上下行通信的高可用、高性能、高稳定的TCP长连接网关。

早期京麦搭建HTTP和TCP长连接功能主要用于消息通知的推送，并未应用于API网关。随着逐步对NIO的深入学习和对Netty框架的了解，以及对系统通信稳定能力的愈加高要求，采用NIO技术应用网关实现API请求调用的想法，最终在2016年实现，并完全支撑业务化运行。由于诸多的改进，包括TCP长连接容器、Protobuf的序列化、服务泛化调用框架等等，性能比HTTP网关提升10倍以上，稳定性也远远高于HTTP网关。

本文重点介绍京麦TCP网关的技术架构及Netty的应用实践。

简单介绍一下京麦是什么：

京麦工作台是京东商城为京东的商家准备的一款后台管理工具，它可以使您不登陆商家后台就能进行订单生产，快速实现订单下载发货流程。类似于淘宝的旺旺商家版（现在叫淘宝千牛）这样的东西。

学习交流：

- 即时通讯开发交流群：320837163  [推荐]

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

（本文同步发布于：http://www.52im.net/thread-1243-1-1.html ）

2、本文作者

- 京东商家研发部架构师；

- 丰富的构建高性能高可用大规模分布式系统的研发、架构经验；

- 2013年加入京东，目前负责京麦服务网关和京麦服务市场的系统研发工作。

3、TCP网关的网络结构

基于Netty构建京麦TCP网关的长连接容器，作为网关接入层提供服务API请求调用。

客户端通过域名+端口访问TCP网关，域名不同的运营商对应不同的VIP，VIP发布在LVS上，LVS将请求转发给后端的HAProxy，再由HAProxy把请求转发给后端的Netty的IP+Port。

LVS转发给后端的HAProxy，请求经过LVS，但是响应是HAProxy直接反馈给客户端的，这也就是LVS的DR模式。

4、TCP网关长连接容器架构

TCP网关的核心组件是Netty，而Netty的NIO模型是Reactor反应堆模型（Reactor相当于有分发功能的多路复用器Selector）。每一个连接对应一个Channel（多路指多个Channel，复用指多个连接复用了一个线程或少量线程，在Netty指EventLoop），一个Channel对应唯一的ChannelPipeline，多个Handler串行的加入到Pipeline中，每个Handler关联唯一的ChannelHandlerContext。

TCP网关长连接容器的Handler就是放在Pipeline的中。我们知道TCP属于OSI的传输层，所以建立Session管理机制构建会话层来提供应用层服务，可以极大的降低系统复杂度。所以，每一个Channel对应一个Connection，一个Connection又对应一个Session，Session由Session Manager管理，Session与Connection是一一对应，Connection保存着ChannelHandlerContext（ChannelHanderContext可以找到Channel），Session通过心跳机制来保持Channel的Active状态。

每一次Session的会话请求（ChannelRead）都是通过Proxy代理机制调用Service层，数据请求完毕后通过写入ChannelHandlerConext再传送到Channel中。数据下行主动推送也是如此，通过Session Manager找到Active的Session，轮询写入Session中的ChannelHandlerContext，就可以实现广播或点对点的数据推送逻辑。如下图所示。

京麦TCP网关使用Netty Channel进行数据通信，使用Protobuf进行序列化和反序列化，每个请求都将被封装成Byte二进制字节流，在整个生命周期中，Channel保持长连接，而不是每次调用都重新创建Channel，达到链接的复用。

我们接下来来看看基于Netty的具体技术实践。

5、TCP网关Netty Server的IO模型

具体的实现过程如下：

1）创建ServerBootstrap，设定BossGroup与WorkerGroup线程池；

2）bind指定的port，开始侦听和接受客户端链接（如果系统只有一个服务端port需要监听，则BossGroup线程组线程数设置为1）；

3）在ChannelPipeline注册childHandler，用来处理客户端链接中的请求帧。

6、TCP网关的线程模型

TCP网关使用Netty的线程池，共三组线程池，分别为BossGroup、WorkerGroup和ExecutorGroup。其中，BossGroup用于接收客户端的TCP连接，WorkerGroup用于处理I/O、执行系统Task和定时任务，ExecutorGroup用于处理网关业务加解密、限流、路由，及将请求转发给后端的抓取服务等业务操作。

NioEventLoop是Netty的Reactor线程，其角色：

1）Boss Group：作为服务端Acceptor线程，用于accept客户端链接，并转发给WorkerGroup中的线程；

2）Worker Group：作为IO线程，负责IO的读写，从SocketChannel中读取报文或向SocketChannel写入报文；

3）Task Queue／Delay Task Queu：作为定时任务线程，执行定时任务，例如链路空闲检测和发送心跳消息等。

7、TCP网关执行时序图

如上图所示，其中步骤一至步骤九是Netty服务端的创建时序，步骤十至步骤十三是TCP网关容器创建的时序。

步骤一：创建ServerBootstrap实例，ServerBootstrap是Netty服务端的启动辅助类。

步骤二：设置并绑定Reactor线程池，EventLoopGroup是Netty的Reactor线程池，EventLoop负责所有注册到本线程的Channel。

步骤三：设置并绑定服务器Channel，Netty Server需要创建NioServerSocketChannel对象。

步骤四：TCP链接建立时创建ChannelPipeline，ChannelPipeline本质上是一个负责和执行ChannelHandler的职责链。

步骤五：添加并设置ChannelHandler，ChannelHandler串行的加入ChannelPipeline中。

步骤六：绑定监听端口并启动服务端，将NioServerSocketChannel注册到Selector上。

步骤七：Selector轮训，由EventLoop负责调度和执行Selector轮询操作。

步骤八：执行网络请求事件通知，轮询准备就绪的Channel，由EventLoop执行ChannelPipeline。

步骤九：执行Netty系统和业务ChannelHandler，依次调度并执行ChannelPipeline的ChannelHandler。

步骤十：通过Proxy代理调用后端服务，ChannelRead事件后，通过发射调度后端Service。

步骤十一：创建Session，Session与Connection是相互依赖关系。

步骤十二：创建Connection，Connection保存ChannelHandlerContext。

步骤十三：添加SessionListener，SessionListener监听SessionCreate和SessionDestory等事件。

8、TCP网关源码分析

8.1 Session管理

Session是客户端与服务端建立的一次会话链接，会话信息中保存着SessionId、连接创建时间、上次访问事件，以及Connection和SessionListener，在Connection中保存了Netty的ChannelHandlerContext上下文信息。Session会话信息会保存在SessionManager内存管理器中。

创建Session的源码：

通过源码分析，如果Session已经存在销毁Session，但是这个需要特别注意，创建Session一定不要创建那些断线重连的Channel，否则会出现Channel被误销毁的问题。因为如果在已经建立Connection(1)的Channel上，再建立Connection(2)，进入session.close方法会将cxt关闭，Connection(1)和Connection(2)的Channel都将会被关闭。在断线之后再建立连接Connection(3)，由于Session是有一定延迟，Connection(3)和Connection(1/2)不是同一个，但Channel可能是同一个。

所以，如何处理是否是断线重练的Channel，具体的方法是在Channel中存入SessionId，每次事件请求判断Channel中是否存在SessionId，如果Channel中存在SessionId则判断为断线重连的Channel，代码如下图所示。

8.2 心跳

心跳是用来检测保持连接的客户端是否还存活着，客户端每间隔一段时间就会发送一次心跳包上传到服务端，服务端收到心跳之后更新Session的最后访问时间。在服务端长连接会话检测通过轮询Session集合判断最后访问时间是否过期，如果过期则关闭Session和Connection，包括将其从内存中删除，同时注销Channel等。如下图代码所示。

通过源码分析，在每个Session创建成功之后，都会在Session中添加TcpHeartbeatListener这个心跳检测的监听，TcpHeartbeatListener是一个实现了SessionListener接口的守护线程，通过定时休眠轮询Sessions检查是否存在过期的Session，如果轮训出过期的Session，则关闭Session。如下图代码所示。

同时，注意到session.connect方法，在connect方法中会对Session添加的Listeners进行添加时间，它会循环调用所有Listner的sessionCreated事件，其中TcpHeartbeatListener也是在这个过程中被唤起。如下图代码所示。

8.3 数据上行

数据上行特指从客户端发送数据到服务端，数据从ChannelHander的channelRead方法获取数据。数据包括创建会话、发送心跳、数据请求等。这里注意的是，channelRead的数据包括客户端主动请求服务端的数据，以及服务端下行通知客户端的返回数据，所以在处理object数据时，通过数据标识区分是请求-应答，还是通知-回复。如下图代码所示。

8.4 数据下行

数据下行通过MQ广播机制到所有服务器，所有服务器收到消息后，获取当前服务器所持有的所有Session会话，进行数据广播下行通知。如果是点对点的数据推送下行，数据也是先广播到所有服务器，每天服务器判断推送的端是否是当前服务器持有的会话，如果判断消息数据中的信息是在当前服务，则进行推送，否则抛弃。如下图代码所示。

通过源码分析，数据下行则通过NotifyProxy的方式发送数据，需要注意的是Netty是NIO，如果下行通知需要获取返回值，则要将异步转同步，所以NotifyFuture是实现java.util.concurrent.Future的方法，通过设置超时时间，在channelRead获取到上行数据之后，通过seq来关联NotifyFuture的方法。如下图代码所示。

下行的数据通过TcpConnector的send方法发送，send方式则是通过ChannelHandlerContext的writeAndFlush方法写入Channel，并实现数据下行，这里需要注意的是，之前有另一种写法就是cf.await，通过阻塞的方式来判断写入是否成功，这种写法偶发出现BlockingOperationException的异常。如下图代码所示。

使用阻塞获取返回值的写法：

关于BlockingOperationException的问题我在StackOverflow进行提问，非常幸运的得到了Norman Maurer（Netty的核心贡献者之一）的解答：

最终结论大致分析出，在执行write方法时，Netty会判断current thread是否就是分给该Channe的EventLoop，如果是则行线程执行IO操作，否则提交executor等待分配。当执行await方法时，会从executor里fetch出执行线程，这里就需要checkDeadLock，判断执行线程和current threads是否时同一个线程，如果是就检测为死锁抛出异常BlockingOperationException。

9、本文小结

本篇文章粗浅的向大家介绍了京麦TCP网关中使用的Netty实现长连接容器的架构，涉及TCP长连接容器搭建的关键点一一进行了阐述，以及对源码进行简单的分析。在京麦发展过程里Netty还有很多的实践应用，例如Netty4.11+HTTP2实现APNs的消息推送等等。

（本文同步发布于：http://www.52im.net/thread-1243-1-1.html）

附录：更多精编资料汇总

[1] 网络编程基础资料：

《TCP/IP详解-第11章·UDP：用户数据报协议》

《TCP/IP详解-第17章·TCP：传输控制协议》

《TCP/IP详解-第18章·TCP连接的建立与终止》

《TCP/IP详解-第21章·TCP的超时与重传》

《技术往事：改变世界的TCP/IP协议（珍贵多图、手机慎点）》

《通俗易懂-深入理解TCP协议（上）：理论基础》

《通俗易懂-深入理解TCP协议（下）：RTT、滑动窗口、拥塞处理》

《理论经典：TCP协议的3次握手与4次挥手过程详解》

《理论联系实际：Wireshark抓包分析TCP 3次握手、4次挥手过程》

《计算机网络通讯协议关系图（中文珍藏版）》

《UDP中一个包的大小最大能多大？》

《P2P技术详解(一)：NAT详解——详细原理、P2P简介》

《P2P技术详解(二)：P2P中的NAT穿越(打洞)方案详解》

《P2P技术详解(三)：P2P技术之STUN、TURN、ICE详解》

《通俗易懂：快速理解P2P技术中的NAT穿透原理》

《高性能网络编程(一)：单台服务器并发TCP连接数到底可以有多少》

《高性能网络编程(二)：上一个10年，著名的C10K并发连接问题》

《高性能网络编程(三)：下一个10年，是时候考虑C10M并发问题了》

《高性能网络编程(四)：从C10K到C10M高性能网络应用的理论探索》

《不为人知的网络编程(一)：浅析TCP协议中的疑难杂症(上篇)》

《不为人知的网络编程(二)：浅析TCP协议中的疑难杂症(下篇)》

《不为人知的网络编程(三)：关闭TCP连接时为什么会TIME_WAIT、CLOSE_WAIT》

《不为人知的网络编程(四)：深入研究分析TCP的异常关闭》

《不为人知的网络编程(五)：UDP的连接性和负载均衡》

《不为人知的网络编程(六)：深入地理解UDP协议并用好它》

《网络编程懒人入门(一)：快速理解网络通信协议（上篇）》

《网络编程懒人入门(二)：快速理解网络通信协议（下篇）》

《网络编程懒人入门(三)：快速理解TCP协议一篇就够》

《网络编程懒人入门(四)：快速理解TCP和UDP的差异》

《Netty干货分享：京东京麦的生产级TCP网关技术实践总结》

>>更多同类文章 ……

[2] NIO异步网络编程资料：

《Java新一代网络编程模型AIO原理及Linux系统AIO介绍》

《有关“为何选择Netty”的11个疑问及解答》

《开源NIO框架八卦——到底是先有MINA还是先有Netty?》

《选Netty还是Mina：深入研究与对比（一）》

《选Netty还是Mina：深入研究与对比（二）》

《NIO框架入门(一)：服务端基于Netty4的UDP双向通信Demo演示》

《NIO框架入门(二)：服务端基于MINA2的UDP双向通信Demo演示》

《NIO框架入门(三)：iOS与MINA2、Netty4的跨平台UDP双向通信实战》

《NIO框架入门(四)：Android与MINA2、Netty4的跨平台UDP双向通信实战》

《Netty 4.x学习（一）：ByteBuf详解》

《Netty 4.x学习（二）：Channel和Pipeline详解》

《Netty 4.x学习（三）：线程模型详解》

《Apache Mina框架高级篇（一）：IoFilter详解》

《Apache Mina框架高级篇（二）：IoHandler详解》

《MINA2 线程原理总结（含简单测试实例）》

《Apache MINA2.0 开发指南（中文版）[附件下载]》

《MINA、Netty的源代码（在线阅读版）已整理发布》

《解决MINA数据传输中TCP的粘包、缺包问题（有源码）》

《解决Mina中多个同类型Filter实例共存的问题》

《实践总结：Netty3.x升级Netty4.x遇到的那些坑（线程篇）》

《实践总结：Netty3.x VS Netty4.x的线程模型》

《详解Netty的安全性：原理介绍、代码演示（上篇）》

《详解Netty的安全性：原理介绍、代码演示（下篇）》

《详解Netty的优雅退出机制和原理》

《NIO框架详解：Netty的高性能之道》

《Twitter：如何使用Netty 4来减少JVM的GC开销（译文）》

《绝对干货：基于Netty实现海量接入的推送服务技术要点》

《Netty干货分享：京东京麦的生产级TCP网关技术实践总结》

>>更多同类文章 ……

[3] 有关IM/推送的通信格式、协议的选择：

《简述传输层协议TCP和UDP的区别》

《为什么QQ用的是UDP协议而不是TCP协议？》

《移动端即时通讯协议选择：UDP还是TCP？》

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

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

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

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

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

《理论联系实际：一套典型的IM通信协议设计详解》

《58到家实时消息系统的协议设计等技术实践分享》

《详解如何在NodeJS中使用Google的Protobuf》

>>更多同类文章 ……

[4] 有关IM/推送的心跳保活处理：

《应用保活终极总结(一)：Android6.0以下的双进程守护保活实践》

《应用保活终极总结(二)：Android6.0及以上的保活实践(进程防杀篇)》

《应用保活终极总结(三)：Android6.0及以上的保活实践(被杀复活篇)》

《Android进程保活详解：一篇文章解决你的所有疑问》

《Android端消息推送总结：实现原理、心跳保活、遇到的问题等》

《深入的聊聊Android消息推送这件小事》

《为何基于TCP协议的移动端IM仍然需要心跳保活机制？》

《微信团队原创分享：Android版微信后台保活实战分享(进程保活篇)》

《微信团队原创分享：Android版微信后台保活实战分享(网络保活篇)》

《移动端IM实践：实现Android版微信的智能心跳机制》

《移动端IM实践：WhatsApp、Line、微信的心跳策略分析》

>>更多同类文章 ……

[5] 有关WEB端即时通讯开发：

《新手入门贴：史上最全Web端即时通讯技术原理详解》

《Web端即时通讯技术盘点：短轮询、Comet、Websocket、SSE》

《SSE技术详解：一种全新的HTML5服务器推送事件技术》

《Comet技术详解：基于HTTP长连接的Web端实时通信技术》

《新手快速入门：WebSocket简明教程》

《WebSocket详解（一）：初步认识WebSocket技术》

《WebSocket详解（二）：技术原理、代码演示和应用案例》

《WebSocket详解（三）：深入WebSocket通信协议细节》

《socket.io实现消息推送的一点实践及思路》

《LinkedIn的Web端即时通讯实践：实现单机几十万条长连接》

《Web端即时通讯技术的发展与WebSocket、Socket.io的技术实践》

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

《开源框架Pomelo实践：搭建Web端高性能分布式IM聊天服务器》

《使用WebSocket和SSE技术实现Web端消息推送》

《详解Web端通信方式的演进：从Ajax、JSONP 到 SSE、Websocket》

>>更多同类文章 ……

[6] 有关IM架构设计：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>更多同类文章 ……

[7] 有关IM安全的文章：

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

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

《即时通讯安全篇（三）：常用加解密算法与通讯安全讲解》

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

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

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

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

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

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

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

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

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

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

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

>>更多同类文章 ……

[8] 有关实时音视频开发：

《专访微信视频技术负责人：微信实时视频聊天技术的演进》

《即时通讯音视频开发（一）：视频编解码之理论概述》

《即时通讯音视频开发（二）：视频编解码之数字视频介绍》

《即时通讯音视频开发（三）：视频编解码之编码基础》

《即时通讯音视频开发（四）：视频编解码之预测技术介绍》

《即时通讯音视频开发（五）：认识主流视频编码技术H.264》

《即时通讯音视频开发（六）：如何开始音频编解码技术的学习》

《即时通讯音视频开发（七）：音频基础及编码原理入门》

《即时通讯音视频开发（八）：常见的实时语音通讯编码标准》

《即时通讯音视频开发（九）：实时语音通讯的回音及回音消除�概述》

《即时通讯音视频开发（十）：实时语音通讯的回音消除�技术详解》

《即时通讯音视频开发（十一）：实时语音通讯丢包补偿技术详解》

《即时通讯音视频开发（十二）：多人实时音视频聊天架构探讨》

《即时通讯音视频开发（十三）：实时视频编码H.264的特点与优势》

《即时通讯音视频开发（十四）：实时音视频数据传输协议介绍》

《即时通讯音视频开发（十五）：聊聊P2P与实时音视频的应用情况》

《即时通讯音视频开发（十六）：移动端实时音视频开发的几个建议》

《即时通讯音视频开发（十七）：视频编码H.264、VP8的前世今生》

《实时语音聊天中的音频处理与编码压缩技术简述》

《网易视频云技术分享：音频处理与压缩技术快速入门》

《学习RFC3550：RTP/RTCP实时传输协议基础知识》

《简述开源实时音视频技术WebRTC的优缺点》

《良心分享：WebRTC 零基础开发者教程（中文）》

《开源实时音视频技术WebRTC中RTP/RTCP数据传输协议的应用》

《基于RTMP数据传输协议的实时流媒体技术研究（论文全文）》

《声网架构师谈实时音视频云的实现难点(视频采访)》

《浅谈开发实时视频直播平台的技术要点》

《还在靠“喂喂喂”测试实时语音通话质量？本文教你科学的评测方法！》

《实现延迟低于500毫秒的1080P实时音视频直播的实践分享》

《移动端实时视频直播技术实践：如何做到实时秒开、流畅不卡》

《如何用最简单的方法测试你的实时音视频方案》

《技术揭秘：支持百万级粉丝互动的Facebook实时视频直播》

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

《移动端实时音视频直播技术详解（一）：开篇》

《移动端实时音视频直播技术详解（二）：采集》

《移动端实时音视频直播技术详解（三）：处理》

《移动端实时音视频直播技术详解（四）：编码和封装》

《移动端实时音视频直播技术详解（五）：推流和传输》

《移动端实时音视频直播技术详解（六）：延迟优化》

《理论联系实际：实现一个简单地基于HTML5的实时视频直播》

《IM实时音视频聊天时的回声消除技术详解》

《浅谈实时音视频直播中直接影响用户体验的几项关键技术指标》

《如何优化传输机制来实现实时音视频的超低延迟？》

《首次披露：快手是如何做到百万观众同场看直播仍能秒开且不卡顿的？》

《实时通信RTC技术栈之：视频编解码》

《开源实时音视频技术WebRTC在Windows下的简明编译教程》

《Android直播入门实践：动手搭建一套简单的直播系统》

>>更多同类文章 ……

[9] IM开发综合文章：

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

《移动端IM开发需要面对的技术问题》

《开发IM是自己设计协议用字节流好还是字符流好？》

《请问有人知道语音留言聊天的主流实现方式吗？》

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

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

《如何保证IM实时消息的“时序性”与“一致性”？》

《一个低成本确保IM消息时序的方法探讨》

《IM单聊和群聊中的在线状态同步应该用“推”还是“拉”？》

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

《谈谈移动端 IM 开发中登录请求的优化》

《移动端IM登录时拉取数据如何作到省流量？》

《浅谈移动端IM的多点登陆和消息漫游原理》

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

《通俗易懂：基于集群的移动端IM接入层负载均衡方案分享》

《微信对网络影响的技术试验及分析（论文全文）》

《即时通讯系统的原理、技术和应用（技术论文）》

《开源IM工程“蘑菇街TeamTalk”的现状：一场有始无终的开源秀》

《QQ音乐团队分享：Android中的图片压缩技术详解（上篇）》

《QQ音乐团队分享：Android中的图片压缩技术详解（下篇）》

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

《腾讯原创分享(二)：如何大幅压缩移动网络下APP的流量消耗（上篇）》

《腾讯原创分享(二)：如何大幅压缩移动网络下APP的流量消耗（下篇）》

《如约而至：微信自用的移动端IM网络层跨平台组件库Mars已正式开源》

《基于社交网络的Yelp是如何实现海量用户图片的无损压缩的？》

>>更多同类文章 ……

[10] 开源移动端IM技术框架资料：

《开源移动端IM技术框架MobileIMSDK：快速入门》

《开源移动端IM技术框架MobileIMSDK：常见问题解答》

《开源移动端IM技术框架MobileIMSDK：压力测试报告》

>>更多同类文章 ……

[11] 有关推送技术的文章：

《iOS的推送服务APNs详解：设计思路、技术原理及缺陷等》

《信鸽团队原创：一起走过 iOS10 上消息推送(APNS)的坑》

《Android端消息推送总结：实现原理、心跳保活、遇到的问题等》

《扫盲贴：认识MQTT通信协议》

《一个基于MQTT通信协议的完整Android推送Demo》

《IBM技术经理访谈：MQTT协议的制定历程、发展现状等》

《求教android消息推送：GCM、XMPP、MQTT三种方案的优劣》

《移动端实时消息推送技术浅析》

《扫盲贴：浅谈iOS和Android后台实时消息推送的原理和区别》

《绝对干货：基于Netty实现海量接入的推送服务技术要点》

《移动端IM实践：谷歌消息推送服务(GCM)研究（来自微信）》

《为何微信、QQ这样的IM工具不使用GCM服务推送消息？》

《极光推送系统大规模高并发架构的技术实践分享》

《从HTTP到MQTT：一个基于位置服务的APP数据通信实践概述》

《魅族2500万长连接的实时消息推送架构的技术实践分享》

《专访魅族架构师：海量长连接的实时消息推送系统的心得体会》

《深入的聊聊Android消息推送这件小事》

《基于WebSocket实现Hybrid移动应用的消息推送实践(含代码示例)》

《一个基于长连接的安全可扩展的订阅/推送服务实现思路》

《实践分享：如何构建一套高可用的移动端消息推送系统？》

《Go语言构建千万级在线的高并发消息推送系统实践(来自360公司)》

《腾讯信鸽技术分享：百亿级实时消息推送的实战经验》

《百万在线的美拍直播弹幕系统的实时推送技术实践之路》

>>更多同类文章 ……

[12] 更多即时通讯技术好文分类：

http://www.52im.net/forum.php?mod=collection&op=all

（本文同步发布于：http://www.52im.net/thread-1243-1-1.html）