本文由融云技术团队原创分享，原题“IM 消息数据存储结构设计”，内容有修订。

1、引言

在如今的移动互联网时代，IM类产品已是我们生活中不可或缺的组成部分。像微信、钉钉、QQ等是典型的以 IM 为核心功能的社交产品。另外也有一些应用虽然IM功能不是核心，但IM能力也是其整个应用极其重要的组成部分，比如在线游戏、电商直播等应用。

在IM技术应用场景越来越广泛的前提下，对即时通讯IM技术的学习和掌握就显的越来越有必要。

在IM庞大的技术体系中，消息系统无疑是最核心的，而消息系统中，最关键的部分是消息的分发和存储，而离线消息和历史消息又是这个关键环节中不可回避的技术要点。

本文将基于IM消息系统的技术实践，分享关于离线消息和历史消息的正确理解，以及具体的技术配合和实践，希望能为你的离线消息和历史消息技术设计带来最佳实践灵感。

学习交流：

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

2、相关文章

技术相关文章：

1. 《什么是IM系统的可靠性？》
2. 《闲鱼IM的在线、离线聊天数据同步机制优化实践》
3. 《闲鱼亿级IM消息系统的可靠投递优化实践》
4. 《一套亿级用户的IM架构技术干货(下篇)：可靠性、有序性、弱网优化等》
5. 《IM消息送达保证机制实现(二)：保证离线消息的可靠投递》
6. 《我是如何解决大量离线消息导致客户端卡顿的》

融云技术团队分享的其它文章：

1. 《融云安卓端IM产品的网络链路保活技术实践》
2. 《全面揭秘亿级IM消息的可靠投递机制》
3. 《解密融云IM产品的聊天消息ID生成策略》
4. 《万人群聊消息投递方案的思考和实践》
5. 《基于WebRTC的实时音视频首帧显示时间优化实践》
6. 《融云IM技术分享：万人群聊消息投递方案的思考和实践》

3、IM消息投递的一般做法

在通常的IM消息系统中，对于实时消息、离线消息、历史消息大概都是下面这样的技术思路。

对于在线用户：消息会直接实时发送到在线的接收方，消息发送完成后，服务器端并不会对消息进行落地存储。

而对于离线的用户：服务器端会将消息存入到离线库，当用户登录后，从离线库中将离线消息拉走，然后服务器端将离线消息删除。

这样实现的缺点就是消息不持久化，导致消息无法支持消息漫游，降低了消息的可靠性。

（PS：实际上，这其实也不能算是缺点，因为一些场景下存储历史消息并不是必须的，所谓的消息漫游能力也不是必备的，比如微信。）

而在我们设计的消息系统中，服务器只要接收到了发送方发上来的消息，在转发给接收方的同时也会在离线数据库及历史消息库中进行消息的落地存储，而历史消息的落地也就能支持消息漫游等相关功能了。

4、什么是离线消息和历史消息？

关于离线消息和历史消息，在技术上，我们是这样定义。

1）离线消息：

离线消息就是用户（即接收方）在离线过程中收到的消息，这些消息大多是用户比较关心的消息，具有一定的时效性。

以我们的系统经验来说，我们的离线消息默认只保存最近七天的消息。

用户（即接收方）在下次登录后会全量获取这些离线消息，然后在客户端根据聊天会话进行离线消息的UI展示（比如显示一个未读消息气泡等）。

（PS：用户离线的可能性在技术上其实是由很多种情况组成的，比如对方不在线、对方网络断掉了、对方手机崩溃了、服务器发送时出错了等等，严格来讲——只要无法实时发送成的消息，都算“离线消息”。）

2）历史消息：

历史消息存储了用户所有的聊天消息，这些消息包括发出的消息以及接收到的消息。

在客户端获取历史消息时，通常是按照会话进行分页获取的。

以我们的系统经验来说，历史消息的存储时间我们设计默认为半年，当然这个时间可以按实际的产品运营规则来定，没有硬性规定。

5、IM消息的发送及存储流程

以下是我们系统整体的消息发送及存储流程：

 如上图所示：当用户发送聊天消息到服务器端后，首先会进入到消息系统中，消息系统会对消息进行分发以及存储。

这个过程中：对于在线的接收方，会选择直接推送消息。但是遇到接收方不在线或者是消息推送失败的情况下，也会有另外的消息获取方式，比如接收方会主动向服务器拉取未收到的消息。但是接收方何时来服务器拉取消息以及从哪里拉取是未知的，所以消息存入到离线库的意义也就在这里。

消息系统存储离线的过程中，为了不影响整个系统的更为平稳，我们使用了MQ消息队列进行IO解偶，所以聊天消息实际上是异步存入到离线库中的（通过MQ进行慢IO解偶，这其实也是惯常做法）。

在分发完消息后：消息服务会同步一份消息数据到历史消息服务中，历史消息服务同样会对消息进行落地存储。

对于新的客户端设备：会有同步消息的需求（所谓的消息漫游能力），而这也正是历史消息的主要作用。在历史消息库中，客户端是可以拉取任意会话的全量历史消息的。

6、IM离线消息、历史消息在存储逻辑上的区别

6.1 概述

通过上面的图中能清晰的看到：

• 1）离线消息我们存储介质选用的是 Redis；
• 2）历史消息我们选用的是 HBase。

对于为什么选用不同的存储介质，其实我们考虑的是离线消息和历史消息不同的业务场景和读写模式。

下面我们重点介绍一下离线消息和历史消息存储的区别。

6.2 离线消息存储模式——“扩散写”

离线消息的存储模式我们用的是扩散写。

如上图所示：每个用户都有自己单独的收件箱和发件箱：

• 1）收件箱存放的是需要向这个接收端同步的所有消息；
• 2）发件箱里存放的是发送端发出的所有消息。

以单聊为例：聊天中的两人会话中，消息会产生两次写，即发送者的发件箱和接收端的收件箱。

而在群的场景下：写入会被更加的放大（扩散），如果群里有 N 个人，那一条群消息就会被扩散写 N 次。

小结一下：

• 1）扩散写的优点是：接收端的逻辑会非常清晰简单，只需要从收件箱里读取一次即可，大大降低了同步消息所需的读的压力；
• 2）扩散写的缺点是：写入会被成指数地放大，特别是针对群这种场景。

6.3 历史消息存储模式——“扩散读”

历史消息的存储模式我们用的是扩散读。

因为历史消息中，每个会话都保存了整个会话的全量消息。在扩散读这种模式下，每个会话的消息只保存一次。

对比扩散写模式，扩散读的优点和缺点如下：

• 1）优点是：写入次数大大降低，特别是针对群消息，只需要存一次即可；
• 2）缺点是：接收端接收消息非常的复杂和低效，因为这种模式客户端想拉取到所有消息就只能每个会话同步一次，读就会被放大，而且可能会产生很多次无效的读，因为有些会话可能根本没有新消息。

6.4 小结

在 IM 这种应用场景下，通常会用到扩散写这种消息同步模型，一条消息产生一条，但是可能会被读多次，是典型的读多写少的场景。

一个优化好的IM系统，必须从设计上平衡读写压力，避免读或者写任意一个维度达到天花板。

当然扩散写这种模式也有其弊端，比如万人群，会导致一条消息，写入了一万次。

综合来讲：我们需要根据自己的业务场景做相应设计选择，以我们的IM系统为例，就是是根据了离线和历史消息的不同场景选择了写扩散和读扩散的组合模式。适合的才是最好的，没有必要死搬硬套理论。

7、IM客户端的拉取消息逻辑

7.1 离线消息拉取逻辑

对于IM客户端而言，离线消息的获取针对的是自己的整个离线消息，包括所有的会话（直白了说，就是上线时拉取此次离线过程中的所有未收取的离线消息）。

离线消息的获取是自上而下的方式（按时间序），我们的经验是一次获取 200 条（PS：如果离线消息过多，会分页多次拉取，拉取1“次”可以理解为拉取1“页”）。

在客户端拉取离线消息的信令中，需要带上当前客户端缓存的消息的最大时间戳。

通过上节的图我们应该知道，离线消息我们存储的是一个线性结构（指的是按时间顺序），Server 会根据这个时间戳向下查找离线消息。当重装或者新安装 App 时，客户端的“当前客户端缓存的消息的最大时间戳”可以传 0 上来。

Server 也会缓存客户端拉取到的最后一条消息的时间戳，然后根据业务场景，客户端类型等因素来决定从哪里开始拉取，如果没有拉取完 Server 会在拉取消息的应答中带相应的标记位，告诉客户端继续拉取，客户端循环拉取，直到所有离线消息拉完。

7.2 历史消息拉取逻辑

历史消息的获取通常针对的是单一会话。

在拉取过程中，需要向服务端提交两个参数：

• 1）对方的 ID（如果是单聊的话就是对方的 UserID，如果是群则是群组ID）；
• 2）当前会话的最前面消息的时间戳（即当前会话最老一条消息的时间戳）。

Server据这两个参数，可以定位到这个客户端的此会话，然后一次获取 20 条历史消息。

消息的拉取时序上采用的是自下而上的方式（也就是时间序逆序），即从最后面往前翻。只要有消息，客户端可以一直向前翻，手动触发获取会话的历史消息。

上面的拉取逻辑，在IM界面功能上通常对应的是下拉或点击“加载更多”，比如这样：

8、本文小结

本文主要分享了IM中有关离线消息和历史消息的正确，主要包括离线消息和历史消息的区别，以及二者在存储、分发、拉取逻辑方面的最佳践等。如对文中内容有异议，欢迎留言讨论。

9、参考资料

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

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

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

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

[5] 闲鱼亿级IM消息系统的架构演进之路

[6] 闲鱼亿级IM消息系统的可靠投递优化实践

[7] 闲鱼亿级IM消息系统的及时性优化实践

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

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

[10] 理解IM消息“可靠性”和“一致性”问题，以及解决方案探讨

[11] 零基础IM开发入门(一)：什么是IM系统？

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

本文由网易云信技术团队分享，原题“如何保障一场千万级大型直播？”，有修订和改动。

1、引言

本文以TFBOYS“日光旅行”七周年这场直播演唱会为案例，为你分享大型直播系统后端架构设计的方方面面，包括：基本架构、稳定性保障、安全性障、监控报警、应急预案等技术范畴。

案例中的这次演唱会采用了在线实时互动及演唱会现场的多场景导播切换，提供了主机位和三个艺人专属机位流，同时每个机位流实时转码四个清晰度档位，用户可以根据喜好选择自己想看的内容。这场演唱会最高同时在线人数达78.6万，打破线上付费演唱会世界记录。

学习交流：

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

- 开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK 

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

2、本文作者

费曼：网易智企服务端开发工程师。硕士毕业于华中科技大学电信系，2016年加入网易云信，热衷于大规模分布式系统和音视频相关技术，爱好文学、体育和电影。

3、架构方面

3.1 基本

 

上图是该次TFBOYS在线演唱会的直播媒体架构简图。

可以看出一场大型活动直播涵盖的技术方案点非常庞杂，本节接下来的内容我们将以推拉流链路、全局智能调度、流量精准调度以及单元化部署，对这套直播方案做一个展开介绍。

3.2 推拉流链路

 

如上图所示，直播技术架构，分为几大部分：

• 1）视频直播中心（LMS——Live Manage Service）：负责直播流的逻辑管理和操作控制，包括存储和下发实时转码、加密等媒体处理的配置信息；
• 2）实时互动直播服：由连麦互动和直播两部分组成，主播和连麦者的音视频数据在互动直播高性能服务器合成为一道流后推流到直播流媒体服务器；
• 3）直播源站服务（LSS——Live Source Service）：网易云信自建的直播流媒体服务器节点，结合全局智能调度系统，提供第一公里的最佳链路选择，同时融合支持接入多家CDN厂商；
• 4）媒体处理服务（MPS——Media Processing Service）：提供实时水印、实时转码、媒体数据加密等强大的流媒体处理能力；
• 5）融合CDN与全局智能调度（GSLB——Golabal Server Load Balancing）：提供敏捷智能的CDN调度策略和分配算法，结合全链路、端到端的流媒体控制，来达到最终端侧优良的用户体验；
• 6）客户端SDK：提供推流、拉流以及上下行的调度能力，便于用户快速接入使用网易云信平台一站式的音视频解决方案。

3.3 融合CDN与智能调度

这是一个端到端的服务，通过平台的SDK执行一个类似HTTPDNS的调度，来做到真正根据用户IP做就近的接入。

针对国内相对复杂的运营商网络环境，在直播上行方面通过BGP网络以及与相关运营商在网络接入方面的合作，能够更加精准地控制网络链路的选择。

而对于下行，也提供了播放端的SDK接入，通过端到端的调度策略就近选择合适的下行链路。

调度的准确性以及最终效果，依赖及时准确的数据支撑。

我们有一个全链路、立体的数据监控体系，一方面利用CDN上的一些实时日志，另一方面结合自建节点、客户端侧上报收集链路上探测的数据，然后整合做一个实时计算来支撑整个调度的策略。

融合CDN方案，通过调度、监控、高可用等技术和手段来解决CDN网络方面的问题。但是对于技术人员来说，就和在使用一个传统的CDN网络一样没有大的差异，这些技术细节对技术人员透明无感知。

3.4 流量精准调度

大型演唱会直播活动，尤其是正式开播时的进场阶段，突发流量峰值会非常高，这就需要实时精准的智能调度策略。

融合CDN的智能调度包含两大部分：CDN分配调度和节点调度。

节点调度：比较常见的是DNS协议解析调度和IP调度（302/HTTPDNS）。前者由于DNS协议原因，调度生效时间较慢，而后者则可以做到请求级别的调度，也就是支持任意比例的负载均衡，更加及时精准。在我们的智能调度的场景里，正常情况下会遵循IP调度，在IP调度解析失败时，客户端上会启动loacl DNS解析逻辑，两者的结合确保了调度的精准和稳定可靠。

Don't put all your eggs in one basket.

“永远不要将鸡蛋放在同一个篮子里”。

从风险管控的角度来说：大型活动保障的CDN厂商资源，通常没法通过一家CDN资源进行满足。融合CDN方案则是将多家CDN厂商进行整合与流量分配调度。

通常在一次大型直播中，多家CDN厂商提供的容量（区域带宽、最高带宽）、质量会各不相同。我们则是通过动态调整调度比例，在确保不超过最大带宽的前提下，精确化按比例分配流量，以及尽可能地确保体验。

我们设计了一套针对CDN厂商的打分算法：影响因子包含当前带宽、保底带宽、最大带宽、带宽预测、带宽质量。

算法遵循以下原则：

• 1）没超保底的带宽，比超过保底的带宽，得分更高；
• 2）没超保底的时候，剩余保底和剩余总带宽越大，得分更高；
• 3）超过保底的时候，剩余总带宽越大、质量越好，得分更高。

各CDN的分数之比决定了调度比例，CDN打分算法是在持续地迭代更新计算，最大化分配使用各家CDN的带宽，然后再分配各家CDN厂商的保障之外的资源。同时优先选择质量较好的厂家，避免单价CDN厂商超分配。

3.5 单元化部署

上面所说，在大型直播活动中，短时间大量涌入的用户请求，对以全局智能调度服务为主的相关非媒体流链路应用，也提出了更高的并发处理挑战。

除了上行的推流链路我们做了主备两个单元的部署，非媒体数据链路上的服务也采用了单元化的部署方案。

在此部署方案下，可用性做到任意单元机房故障，不影响整体可用性，即异地多活。

单元化部署遵循以下原则：

• 1）单元化的依赖也必须单元化（核心业务）；
• 2）单元化粒度为应用，非api；
• 3）单元化技术栈对应用尽量避免产生侵入性。

 

如上图所示：非单元化的业务部署在主机房，单元化的业务则部署在主机房和单元机房。

4、稳定性保障

4.1 上行链路稳定

超大型直播方案最核心的诉求就是直播稳定性，下面我们将以该次在线演唱会为案例，重点阐述一下直播的全链路稳定性架构。

上图是我们直播的媒体流链路示意简图：整体方案可以承受任何单节点、单线路、单机房网络出口的故障。

如直播源站部分：采用了多线策略收流，包含机房专线和4G背包方案，一主一备两个线路。同时每个单元的源站集群都有4层负载均衡，一台机器宕机不会影响整体可用性。LMS、LSS、MPS都是跨机房部署，所有服务模块都可配置专有资源池供使用，保证不会受其他租户影响。

整个推流链路：采用双路热流、互为主备，且部署上是互相独立的两个单元，能做到支持Rack级别的故障灾备。双路热流实现了自动主备切换，端上无需专门添加应用层的线路切换逻辑。当任何一个链路出现问题的时候，观众的直播流不会受到影响，端上平均卡顿感知时间在1s以内。

除了推流链路的整体主备单元容灾，每个单元的服务本身也会有容灾手段。比如UPS接入，可以接受30min的供电故障，比如当实时互动流出现问题时，导播台会推垫片流以保证链路数据不中断。

4.2 下行链路稳定

在访次直播活动中，全局智能调度服务会承受较大的峰值压力，在单元化部署的基础上，我们经过多轮压测和性能调优，模型上可支撑千万级用户在半分钟内全部进入直播间。

除了上述关于推流链路的高可用，下行链路也有相关的容灾策略。当GSLB智能调度服务整体不可用，在客户端SDK预埋了融合CDN的local DNS灾备逻辑与比例配置，将云端的全局智能调度fail-over到客户端的本地兜底调度，并保持大数据统计层面的各CDN厂商的流量分配均衡。

同时：客户端也会有播放体验方面的容灾策略，诸如清晰度降级、线路调整等。

5、安全性保障

除了直播全链路的稳定之外，直播安全也很重要。

该次直播活动中，为TFBOYS活动链路多环节都提供了安全保障机制（如防盗链鉴权、IP黑白名单、HTTPS等能力），以及地区、运营商等下行调度的动态限制，实现全链路安全保障。

在此基础上：此次活动采用了端到端的视频流数据加密。

直播场景的加密有几点基本要求：压缩比不变、实时性和低计算复杂度。

除此之外：在融合多cdn的方案背景下，视频流的加密必须考虑到CDN厂商的兼容性。

比如须满足以下要求：

• 1）不破坏流媒体协议格式、视频容器格式；
• 2）metadata/video/audio tag的header部分不加密；
• 3）对于avcSequenceHeader和aacSequenceHeader tag整体不加密。

具体加密算法，可以采用一些流式加密算法，这里我们不再赘述。

 

6、监控与报警

6.1 概述

一场大型直播将会有大量的计算节点参与，除了媒体数据处理与分发的各个服务器节点，还有分布在国内外的海量客户端。

我们对网络链路、服务节点、设备端的健康与质量感知，都离不开数据监控系统。

同时：我们在现有系统无法自动fail-over的故障场景下，需要人工预案介入，而后者的决策判断，也强依赖于完善的全链路数据质量监控与报警系统。

6.2 全链路监控

整个直播链路的监控包含了：

• 1）上行推流链路的流质量；
• 2）媒体流实时转码处理；
• 3）端上播放质量；
• 4）智能调度系统的可用性；
• 5）业务量水位等相关监控数据。

上行链路常见的QoS指标有：帧率、码率、RTT等，其维度包含主备线路、出口运营商、CDN厂商节点等。

端上的QoS指标则包含了：拉流成功率、首帧时长、卡顿率、httpdns缓存命中率，维度则覆盖包含CDN厂商、国家、省份、运营商、直播流、清晰度档位、客户端等。

此次直播中：内容上支持了多种机位流以及多个清晰度的转码输出流，同时通过多个CDN厂商进行分发，我们把上行链路中节点的码率、帧率，直观地通过N个指标卡集中展示在单个大盘页面上，并且通过增加预警值进行异常显示和弹窗消息告警。活动作战室现场，我们采用了多个大屏展示，非常直观地展现当前主备双推流链路的实时帧率、码率等情况，为现场地指挥保障提供了强大的数据决策支撑。

以下图为例：蓝色表示上行帧率，绿色表示正常的上行码率，红色表示码率值过低，N/A表示当前没有上行推流数据。

而在下行播放链路中，比较常用的指标就是卡顿率。

下面是我们对卡顿相关的描述：

• 1）一次卡顿：播放器持续2s发生缓冲区空，即播放器2s没有拉到流；
• 2）一分钟用户卡顿：1分钟窗口内，用户只要卡顿一次，则该用户计作卡顿用户；
• 3）一分钟用户卡顿率：1分钟窗口内，卡顿用户数/总的用户数；
• 4）一分钟用户零卡顿率：1分钟窗口内，(总的用户数 - 卡顿用户数)/总的用户数。

为什么会选择用户卡顿率这个指标，而不是使用整体的卡顿采样点/总采样数呢？

是因为：我们更想看到有多少用户没有出现过卡顿现象，这更能直观体现优质网络的整体占比。通过对各省份用户零卡顿率、用户数排行，以及各省用户卡顿率的观察，我们可以非常直观地找到卡顿严重的地区，以便重点关注，进行资源调度优化。

7、应急预案

任何一个系统，无论你号称它被设计得多么健壮，它仍然会有故障时间的存在。

硬件故障、软件bug、人为操作失误等等，这些都无可避免地存在着。他们未必是一个必须多少时间内将其彻底解决的问题，他们是我们必须认清并接受共存的一个事实。

所以：预案管理是大型直播活动保障中不可缺少的一环。

我们遵循以下的预案原则：

• 1）预案信息明确：大盘自动监控不具备二义性，确保预案信息来源正确，触发执行预案的条件明确且有数值化约束；
• 2）预案操作简洁：所有的预案操作都有有简洁明确(开关型)的操作输入；
• 3）预案操作安全：所有预案要经过充分预演，同时预演操作本身需要有明确的确认机制，以确保在正常情况下不会被误触发；
• 4）预案影响验证：明确理清预案操作的影响，QA在预演阶段需要对相关影响进行充分验证。

此次活动的前期筹备中，我们总计进行了3次直播全链路的拟真演练，以及2次联合互动现场、导播台现场的活动全流程级别的彩排，另外进行了大大小小总计数十次的各类风险预案演练。所有演练过程中发现的问题，都会进行专项解决。

风险预案这块，包含了各类资源故障、上下行链路质量、地区性网络故障、CDN异常流量水位等在内的场景应对。其中资源故障包含了机器宕机、机架整体断电、堆叠交换机宕机、机房外网出口不可用，我们均进行了风险预案演练覆盖。

下面列举几点直播解决方案中的部分预案机制：

• 1）如果因为误操作等导致非正常解密等，可在推流不中断的情况下，动态中止流加密，客户端无任何感知影响；
• 2）某家cdn在某地区运营商出现大面积故障瘫痪，该地区相应运营商线路的QoS指标会大幅度下降并触发报警，将故障cdn在该地区运营商进行黑名单处理，动态停止对其的调度，将流量调度至正常提供服务的cdn厂商；
• 3）在两路热流均正常的情况下，但是正在分发的一路出现质量问题，方案可支持手动触发主备切换，让监控数据质量更好的另一路流参与分发，客户端感知时间在1s以内；
• 4）因为一些不可抗因素，某机房出现大面积故障整体不可用，触发链路报警，此时我们会紧急将流切至另一机房，故障感知与恢复的时间在一分钟内。

8、相关文章

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

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

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

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

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

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

[7] 淘宝直播技术干货：高清、低延时的实时视频直播技术解密

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

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

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

[11] 网易云信实时视频直播在TCP数据传输层的一些优化思路

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

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

[14] 直播系统聊天技术(一)：百万在线的美拍直播弹幕系统的实时推送技术实践之路

[15] 直播系统聊天技术(二)阿里电商IM消息平台，在群聊、直播场景下的技术实践

[16] 直播系统聊天技术(三)：微信直播聊天室单房间1500万在线的消息架构演进之路

[17] 直播系统聊天技术(四)：百度直播的海量用户实时消息系统架构演进实践

[18] 直播系统聊天技术(五)：微信小游戏直播在Android端的跨进程渲染推流实践

[19] 直播系统聊天技术(六)：百万人在线的直播间实时聊天消息分发技术实践

[20] 直播系统聊天技术(七)：直播间海量聊天消息的架构设计难点实践

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

本文由小米技术团队分享，原题“小爱接入层单机百万长连接演进”，有修订。

1、引言

小爱接入层是小爱云端负责设备接入的第一个服务，也是最重要的服务之一，本篇文章介绍了小米技术团队2020至2021年在这个服务上所做的一些优化和尝试，最终将单机可承载长连接数从30w提升至120w+，节省了机器30+台。

提示：什么是“小爱”？

小爱（全名“小爱同学”）是小米旗下的人工智能语音交互引擎，搭载在小米手机、小米AI音箱、小米电视等设备中，在个人移动、智能家庭、智能穿戴、智能办公、儿童娱乐、智能出行、智慧酒店、智慧学习共八大类场景中使用。

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

2、专题目录

本文是专题系列文章的第7篇，总目录如下：

1. 《长连接网关技术专题(一)：京东京麦的生产级TCP网关技术实践总结》
2. 《长连接网关技术专题(二)：知乎千万级并发的高性能长连接网关技术实践》
3. 《长连接网关技术专题(三)：手淘亿级移动端接入层网关的技术演进之路》
4. 《长连接网关技术专题(四)：爱奇艺WebSocket实时推送网关技术实践》
5. 《长连接网关技术专题(五)：喜马拉雅自研亿级API网关技术实践》
6. 《长连接网关技术专题(六)：石墨文档单机50万WebSocket长连接架构实践》
7. 《长连接网关技术专题(七)：小米小爱单机120万长连接接入层的架构演进》（* 本文）

3、什么是小爱接入层

整个小爱的架构分层如下：

接入层主要的工作在鉴权授权层和传输层，它是所有小爱设备和小爱大脑交互的第一个服务。

由上图我们知道小爱接入层的重要功能有如下几个：

• 1）安全传输和鉴权：维护设备和大脑的安全通道，保障身份认证有效和传输数据安全；
• 2）维护长连接：维持设备和大脑的长连接（Websocket等），做好连接状态存储，心跳维护等工作；
• 3）请求转发：针对每一次小爱设备的请求做好转发，保障每一次请求的稳定。

4、早期接入层的技术实现

小爱接入层最早的实现是基于Akka和Play，我们使用它们搭建了第一个版本，该版本特点如下：

• 1）基于Akka我们基本做到了初步的异步化，保障核心线程不被阻塞，性能尚可。
• 2）Play框架天然支持Websocket，因此我们在有限的人力下能够快速搭建和实现，且能够保障协议实现的标准性。

5、早期接入层的技术问题

随着小爱长连接的数量突破千万大关，针对早期的接入层方案，我们发现了一些问题。

主要的问题如下：

1）长连接数量上来后，需要维护的内存数据越来越多，JVM的GC成为不可忽略的性能瓶颈，且一旦代码写的不好有GC风险。经过之前事故分析，Akka+Play版的接入层其单实例长连接数量的上限在28w左右。

2）老版本的接入层实现比较随意，其Akka Actor之间存在非常多的状态依赖而不是基于不可变的消息传递这样使得Actor之间的通信变成了函数调用，导致代码可读性差且维护很困难，没有发挥出Akka Actor在构建并发程序的优势。

3）作为接入层服务，老版本对协议的解析是有很强的依赖的，这导致它要随着版本变动而频繁上线，其上线会引起长连接重连，随时有雪崩的风险。

4）由于依赖Play框架，我们发现其长连接打点有不准确的问题（因为拿不到底层TCP连接的数据），这个会影响我们每日巡检对服务容量的评估，且依赖其他框架在长连接数量上来后我们没有办法做更细致的优化。

6、新版接入层的设计目标

基于早期接入层技术方案的种种问题，我们打算重构接入层。

对于新版接入层我们制定的目标是：

• 1）足够稳定：上线尽可能不断连接且服务稳定；
• 2）极致性能：目标单机至少100w长连接，最好不要受GC影响；
• 3）最大限度可控：除了底层网络I/O的系统调用，其他所有代码都要是自己实现/或者内部实现的组件，这样我们有足够的自主权。

于是，我们开始了单机百万长连接的漫漫实践之路。。。

7、新版接入层的优化思路

7.1 接入层的依赖关系

接入层与外部服务的关系理清如下：

7.2 接入层的功能划分

接入层的主要功能划分如下：

• 1）WebSocket解析：收到的客户端字节流，要按照WebSocket协议要求解析出数据；
• 2）Socket状态保持：存储连接的基本状态信息；
• 3）加密解密：与客户端通讯的所有数据都是加密过的，而与后端模块之间传输是json明文的；
• 4）顺序化：同一个物理连接上，先后两个请求A、B到达服务器，后端服务中B可能先于A得到了应答，但是我们收到B不能立刻发送给客户端，必须等待A完成后，再按照A,B的顺序发给客户端；
• 5）后端消息分发：接入层后面不止对接单个服务，可能根据不同的消息转发给不同的服务；
• 6）鉴权：安全相关验证，身份验证等。

7.3 接入层的拆分思路

把之前的单一模块按照是否有状态，拆分为两个子模块。

具体如下：

• 1）前端：有状态，功能最小化，尽量少上线；
• 2）后端：无状态，功能最大化，上线可做到用户无感知。

所以，按照上面的原则，理论上我们会做出这样的功能划分，即前端很小、后端很大。示意图如下图所示。

8、新版接入层的技术实现

8.1 总览

模块拆分为前后端：

• 1）前端有状态，后端无状态；
• 2）前后端是独立进程，同机部署。

补充：前端负责建立与维护设备长连接的状态，为有状态服务；后端负责具体业务请求，为无状态服务。后端服务上线不会导致设备连接断开重连及鉴权调用，避免了长连接状态因版本升级或逻辑调整而引起的不必要抖动；

前端使用CPP实现：

• 1）Websocket协议完全自己解析：可以从Socket层面获取所有信息，任何Bug都可以处理；
• 2）更高的CPU利用率：没有任何额外JVM代价，无GC拖累性能；
• 3）更高的内存利用率：连接数量变大后与连接相关的内存开销变大，自己管理可以极端优化。

后端暂时使用Scala实现：

• 1）已实现的功能直接迁移，比重写代价要低得多；
• 2）依赖的部分外部服务（比如鉴权）有可直接利用的Scala（Java）SDK库，而没有C++版本，若用C++重写代价非常大；
• 3）全部功能无状态化改造，可以做到随时重启而用户无感知。

通讯使用ZeroMQ：

进程间通讯最高效的方式是共享内存，ZeroMQ基于共享内存实现，速度没问题。

8.2 前端实现

整体架构：

如上图所示，由四个子模块组成：

• 1）传输层：Websocket协议解析，XMD协议解析；
• 2）分发层：屏蔽传输层的差异，不管传输层使用的什么接口，在分发层转化成统一的事件投递到状态机；
• 3）状态机层：为了实现纯异步服务，使用自研的基于Actor模型的类Akka状态机框架XMFSM，这里面实现了单线程的Actor抽象；
• 4）ZeroMQ通讯层：由于ZeroMQ接口是阻塞实现，这一层通过两个线程分别负责发送和接收。

8.2.1）传输层：

WebSocket 部分使用 C++ 和 ASIO 实现 websocket-lib。小爱长连接基于WebSocket协议，因此我们自己实现了一个WebSocket长连接库。

这个长连接库的特点是：

• a. 无锁化设计，保障性能优异；
• b. 基于BOOST ASIO 开发，保障底层网络性能。

压测显示该库的性能十分优异的：

这一层同时也承担了除原始WebSocket外，其他两种通道的的收发任务。

目前传输层一共支持以下3种不同的客户端接口：

• a. websocket(tcp)：简称ws；
• b. 基于ssl的加密websocket(tcp)：简称wss；
• c. xmd(udp)：简称xmd。

8.2.2）分发层：

把不同的传输层事件转化成统一事件投递到状态机，这一层起到适配器的作用，确保无论前面的传输层使用哪种类型，到达分发层变都变成一致的事件向状态机投递。

8.2.3）状态机处理层：

主要的处理逻辑都位于这一层中，这里非常重要的一个部分是对于发送通道的封装。

对于小爱应用层协议，不同的通道处理逻辑是完全一致的，但是在处理和安全相关逻辑上每个通道又有细节差异。

比如：

• a. wss 收发不需要加解密，加解密由更前端的Nginx做了，而ws需要使用AES加密发送；
• b. wss 在鉴权成功后不需要向客户端下发challenge文本，因为wss不需要做加解密；
• c. xmd 发送的内容与其他两个不同，是基于protobuf封装的私有协议，且xmd需要处理发送失败后的逻辑，而ws/wss不用考虑发送失败的问题，由底层Tcp协议保证。

针对这种情况：我们使用C++的多态特性来处理，专门抽象了一个Channel接口，这个接口中提供的方法包含了一个请求处理的一些关键差异步骤，比如如何发送消息到客户端，如何stop连接，如何处理发送失败等等。对于3种(ws/wss/xmd)不同的发送通道，每个通道有自己的Channel实现。

客户端连接对象一创建，对应类型的具体Channel对象就立刻被实例化。这样状态机主逻辑中只实现业务层的公共逻辑即可，当在有差异逻辑调用时，直接调用Channel接口完成，这样一个简单的多态特性帮助我们分割了差异，确保代码整洁。

8.2.4）ZeroMQ 通讯层：

通过两个线程将ZeroMQ的读写操作异步化，同时负责若干私有指令的封装和解析。

8.3 后端实现

8.3.1）无状态化改造：

后端做的最重要改造之一就是将所有与连接状态相关的信息进行剔除。

整个服务以 Request（一次连接上可以传输N个Request）为核心进行各种转发和处理，每次请求与上一次请求没有任何关联。一个连接上的多次请求在后端模块被当做独立请求处理。

8.3.2）架构：

Scala 服务采用 Akka-Actor 架构实现了业务逻辑。

服务从 ZeroMQ 收到消息后，直接投递到 Dispatcher 中进行数据解析与请求处理，在 Dispatcher 中不同的请求会发送给对应的 RequestActor进行 Event 协议解析并分发给该 event 对应的业务 Actor 进行处理。最后将处理后的请求数据通过XmqActor 发送给后端 AIMS&XMQ 服务。

一个请求在后端多个 Actor 中的处理流程：

8.3.3）Dispatcher 请求分发：

前端与后端之间通过 Protobuf 进行交互，避免了Json 解析的性能消耗，同时使得协议更加规范化。

后端服务从 ZeroMQ 收到消息后，会在 DispatcherActor 中进行PB协议解析并根据不同的分类（简称CMD）进行数据处理，分类包括如下几种。

* BIND 命令：

鉴权功能，由于鉴权功能逻辑复杂，使用C++语言实现起来较为困难，目前依然放在 scala 业务层进行鉴权。该部分对设备端请求的 HTTP Headers 进行解析，提取其中的 token 进行鉴权，并将结果返回前端。

* LOGIN 命令：

设备登入，设备鉴权通过后当前连接已成功建立，此时会进行 Login 命令的执行，用于将该长连接信息发送至AIMS并记录于Varys服务中，方便后续的主动下推等功能。在 Login 过程中，服务首先将请求 Account 服务获取长连接的 uuid（用于连接过程中的路由寻址），然后将设备信息+uuid 发送至AIMS进行设备登入操作。

* LOGOUT 命令：

设备登出，设备在与服务端断开连接时需要进行 Logout 操作，用于从 Varys 服务中删除该长连接记录。

* UPDATE 与 PING 命令：

a. Update 命令，设备状态信息更新，用于更新该设备在数据库中保存的相关信息；

b. Ping 命令，连接保活，用于确认该设备处于在线连接状态。

* TEXT_MESSAGE 与 BINARY_MESSAGE：

文本消息与二进制消息，在收到文本消息或二进制消息时将根据 requestid 发送给该请求对应的RequestActor进行处理。

8.3.4）Request 请求解析：

针对收到的文本和二进制消息，DispatcherActor 会根据 requestId 将其发送给对应的RequestActor进行处理。

其中：文本消息将会被解析为Event请求，并根据其中的 namespace 和 name 将其分发给指定的业务Actor。二进制消息则会根据当前请求的业务场景被分发给对应的业务Actor。

8.4 其他优化

在完成新架构 1.0 调整过程中，我们也在不断压测长连接容量，总结几点对容量影响较大的点。

8.4.1）协议优化：

a. JSON替换为Protobuf: 早期的前后端通信使用的是 json 文本协议，后来发现 json 序列化、反序列化这部分对CPU的占用较大，改为了 protobuf 协议后，CPU占用率明显下降。

b. JSON支持部分解析：业务层的协议是基于json的，没有办法直接替换，我们通过"部分解析json"的方式，只解析很小的 header 部分拿到 namespace 和 name，然后将大部分直接转发的消息转发出去，只将少量 json 消息进行完整反序列化成对象。此种优化后CPU占用下降10%。

8.4.2）延长心跳时间：

在第一次测试20w连接时，我们发现在前后端收发的消息中，一种用来保持用户在线状态的心跳PING消息占了总消息量的75%，收发这个消息耗费了大量CPU。因此我们延长心跳时间也起到了降低CPU消耗的目的。

8.4.3）自研内网通讯库：

为了提高与后端服务通信的性能，我们使用自研的TCP通讯库，该库是基于Boost ASIO开发的一个纯异步的多线程TCP网络库，其卓越的性能帮助我们将连接数提升到120w+。

9、未来规划

经过新版架构1.0版的优化，验证了我们的拆分方向是正确的，因为预设的目标已经达到：

• 1）单机承载的连接数 28w => 120w+（普通服务端机器 16G内存 40核 峰值请求QPS过万），接入层下线节省了50%+的机器成本；
• 2）后端可以做到无损上线。

再重新审视下我们的理想目标，以这个为方向，我们就有了2.0版的雏形：

具体就是：

• 1）后端模块使用C++重写，进一步提高性能和稳定性。同时将后端模块中无法使用C++重写的部分，作为独立服务模块运维，后端模块通过网络库调用；
• 2）前端模块中非必要功能尝试迁移到后端，让前端功能更少，更稳定；
• 3）如果改造后，前端与后端处理能力差异较大，考虑到ZeroMQ实际是性能过剩的，可以考虑使用网络库替换掉ZeroMQ，这样前后端可以从1:1单机部署变为1:N多机部署，更好的利用机器资源。

2.0版目标是：经过以上改造后，期望单前端模块可以达到200w+的连接处理能力。

10、参考资料

[1] 上一个10年，著名的C10K并发连接问题

[2] 下一个10年，是时候考虑C10M并发问题了

[3] 一文读懂高性能网络编程中的线程模型

[4] 深入操作系统，一文读懂进程、线程、协程

[5] Protobuf通信协议详解：代码演示、详细原理介绍等

[6] WebSocket从入门到精通，半小时就够！

[7] 如何让你的WebSocket断网重连更快速？

[8] 从100到1000万高并发的架构演进之路

学习交流：

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

本文由阿里闲鱼技术团队书闲分享，原题“如何有效缩短闲鱼消息处理时长”，有修订和改动。

1、引言

闲鱼技术团队围绕IM这个技术范畴，已经分享了好几篇实践性总结文章，本篇将要分享的是闲鱼IM系统中在线和离线聊天消息数据的同步机制上所遇到的一些问题，以及实践性的解决方案。

学习交流：

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

- 开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK 

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

2、系列文章

本文是系列文章的第7篇，总目录如下：

1. 《阿里IM技术分享(一)：企业级IM王者——钉钉在后端架构上的过人之处》
2. 《阿里IM技术分享(二)：闲鱼IM基于Flutter的移动端跨端改造实践》
3. 《阿里IM技术分享(三)：闲鱼亿级IM消息系统的架构演进之路》
4. 《阿里IM技术分享(四)：闲鱼亿级IM消息系统的可靠投递优化实践》
5. 《阿里IM技术分享(五)：闲鱼亿级IM消息系统的及时性优化实践》
6. 《阿里IM技术分享(六)：闲鱼亿级IM消息系统的离线推送到达率优化》
7. 《阿里IM技术分享(七)：闲鱼IM的在线、离线聊天数据同步机制优化实践》（* 本文）

3、问题背景

随着用户数的快速增长，闲鱼IM系统也迎来了前所未有的挑战。

历经多年的业务迭代，客户端侧IM的代码已经因为多年的迭代层次结构不足够清晰，之前一些隐藏起来的聊天数据同步问题，也随着用户数的增大而被放大。

这里面的具体流程在于：后台需要同步到用户端侧的数据包，后台会根据数据包的业务类型划分成不同的数据域，数据包在对应域里面存在唯一且连续的编号，每一个数据包发送到端侧并且被成功消费后，端侧会记录当前每一个数据域已经同步过的版本编号，下一次数据同步就以本地数据域的编号开始，不断的同步到客户端。

当然用户不会一直在线等待消息，所以之前端侧采用了推拉结合的方式保证数据的同步。

具体就是：

• 1）客户端在线时：使用ACCS实时的将最新的数据内容推送到客户端（ACCS是淘宝无线向开发者提供全双工、低延时、高安全的通道服务）；
• 2）客户端从离线状态启动后：根据本地的数据域编号，拉取不在线时候的数据差；
• 3）当数据获取出现黑洞时：触发数据同步拉取（“黑洞”即指数据包Version不连续的状态）。

4、问题分析

当前的聊天数据同步策略确实是可以基本保障IM的数据同步的，但是也伴随着一些隐含的问题。

这些隐含的问题主要有：

• 1）短时间密集数据推送时，会快速的触发多次数据域同步。域同步回来的数据如果存在问题，又会触发新一轮的同步，造成网络资源的浪费。冗余数据包/无效的数据内容会占用有效内容的处理资源，又对CPU和内存资源造成浪费；
• 2）数据域中的数据包客户端是否正常消费，服务端侧无感知，只能被动地根据当前数据域信息返回数据；
• 3）数据收取/消息数据体解析/存储落库逻辑拆分不够清晰，无法针对性的对某一层的代码拆分替换进行ABTest。

针对上述问题，我们对闲鱼IM进行了分层改造——即抽离数据同步层。这样优化，除了希望以后这个数据的同步内容可以用在IM之外，也希望随着稳定性的增加，赋能其他的业务场景。

接下来的内容，我们重点来看下解决客户端侧闲鱼IM聊天数据同步问题的一些实践思路。

5、优化思路

5.1 分层拆分

对于服务端来说：业务侧产出数据包后，会拼接上当前的数据域信息，然后通过数据同步层将数据推送到端侧。

对于客户端来说：接收到数据包后，会根据当前的数据域信息，来确定需要消费数据包的业务方，确保数据包在数据域内完整连续后，将数据体脱壳后交于业务侧消费，并且应答消费的状况。

数据同步层的抽取：把数据同步中的加壳、脱壳、校验、重试流程封装到一起，可以让上层业务只需要关心自己需要监听的数据域信息，然后当这些数据域更新数据的时候，可以获取到这些数据进行消费，而不再需要关心数据包是否完整。

这样做的话：

• 1）业务侧只需要关心业务侧对接的协议；
• 2）数据侧只需要关心数据侧包装的协议；
• 3）网络层负责真实的数据传输。

整体的架构原理如下：

总结一下就是：

• 1）对齐数据层数据传输协议、描述当前数据包体数据域信息；
• 2）将消息的处理/合并/落库抽离成数据消费者；
• 3）上下楼依赖抽象化，去除对于具体实现的依赖。

5.2 数据层结构模型

基于对于数据模型剥离和对当下遇见问题的解决方案规整，将数据同步层拆分为下图这样的架构。

具体的实施思路就是：

• 1）App启动时建立ACCS长链接服务，保证推推送信道链接，并且根据当前本地数据域信息触发一次数据拉取；
• 2）数据消费者注册消费者信息和需要监听的数据域信息，这里是一对多的关系；
• 3）新的数据抵达端侧后，将数据包放到指定的数据域的缓冲池，批量数据归纳结束后，重新出发数据的读取；
• 4）根据当前数据域优先级弹出最高优的数据包，判断数据域版本是否符合消费者要求，符合则将数据包脱壳后丢给消费者消费，不符合则根据上一次正确的数据包的域信息触发增量的数据域同步拉取；
• 5）触发数据域同步拉取时，block数据读取，此时通过ACCS触达的数据依旧会在继续归纳到指定的数据域队列中，等待数据域同步拉取结果，将数据包进行排序、去重，合并到对应的数据域队列中。然后重新激活数据读取；
• 6）数据包体被消费者正确消费后，更新域信息并且通过上行信道告知服务端已经正确处理的数据域信息。

* 数据域同步协议：

Region中携带的数据不必过多，但需将数据包的内容描述清楚，具体是：

• 1）目标用户的ID，用以确定目标数据包是否正确；
• 2）数据域ID和优先级信息；
• 3）当前数据包的域优先级版本。

* 排序策略：

针对于域数据归纳，无论是在写入数据的时候进行排序还是在读取的时候进行查找都需要进行一次排序的操作，时间复杂度最优也是O(logn)级别的。

在实际coding中发现由于在一个数据域里面，数据包的Version信息是连续唯一并且不存在断层的，上一个稳定消费的数据体的Version信息自增就是下一个数据包的Version，所以这里采用了以Versio为主键的Map存储，既降低了时间复杂度，也使得唯一标识的数据包后抵达端侧的包内容可以覆盖之前的包内容。

6、新的问题及解决策略

6.1 多数据来源和唯一数据消费的平衡

每当产生一条针对于当前用户的数据包：

• 1）如果当前ACCS长链接存在，就会通过ACCS将数据包推送到客户端；
• 2）如果App切换到后台一段时间，或者直接被杀死，ACCS链接断开，那么只能通过离线推送到用户的通知面板。

所以：每当App切换到活跃状态，都需要根据当前本地存储的数据域信息从后台触发一次数据同步。

数据包触达到客户端侧的来源主要是ACCS长链接的推送和域同步时的拉取，但是数据包的消费是根据数据域的监听划分的唯一消费者，也就是同一时间内只能消费一个数据包。

在压力测试中：当后台短时间内密集的将数据包通过ACCS推送到端侧时，端侧接收到的数据包并不有序，不连续的数据包域版本又会触发新的数据域同步，导致同样的一份数据包会通过两个不同的渠道多次的触达到端侧，浪费了不必要的流量。

当数据域同步时：这个时间节点产生的新数据包也会推送到端侧，数据体有效，并且需要被正确的消费。

针对上述这些问题的解决策略：

即在数据消费和数据获取中间装载一个数据中间层，当触发数据域同步的时候block数据的读取并且ACCS推送下来的数据包会被存放在一个数据的中转站里面，当数据域同步拉取的数据回来后，对数据进行合并后再重启数据读取流程。

6.2 数据域优先级

需要推送到客户端侧的数据包，根据业务的不同优先级也有不同的划分。

用户和用户的聊天产生的数据包会比运营类的消息的数据包优先级要高一些，所以要当多优先级的数据包快速的抵达端侧时，高优先级数据域的数据包需要被优先消费，而数据域的优先级也是需要动态调整，需要不断变换的优先级策略。

针对这个问题的解决策略：

不同的数据域，产生不同的数据队列，高优队列里面的数据包会被优先读取消费。

每一个数据包体中带回的数据域信息，都可以标注当前的数据域优先级，当数据域优先级发生变化的时候，调整数据包消费优先级策略。

7、优化后的效果

除去结构上分层梳理，使得数据同步层和依赖的服务内容可便捷解耦/每一个环节可插拔之外，数据同步中对于消息消费时长/流量节省，压力测试场景下优化效果更加明显。

在“500ms内100条全乱序数据包推送”压力测试场景下：

• 1）消息处理时长（接收-上屏）缩短 31%；
• 2）流量损耗（最终拉取到端侧数据包累积大小）降低35%。

8、后续的优化计划

8.1 数据同步层能力提升

数据同步侧的目标，既要保证数据包完整的到达端侧，又要在保证稳定性的前提下尽可能的减少数据的拉取，使得每一次数据的获取都有效。

后续数据同步层会着手于有效数据率和到达率进行更进一步的优化。

针对不同的场景，动态智能调整数据同步的优先级策略。

阻塞式长链接推送，保证同一时间只存在推模式或者拉模式，进一步减少冗余数据包的推送。

8.2 IM端侧整体架构升级

升级数据同步层策略主要还是要提升IM的能力，将数据同步分层后，接下来就是将消息的处理流程化，对每一个流程都可监控可回溯，提升IM数据包的正确解析存储和落库率。

细化一下就是：

• 1）在数据来源侧剥离开后，后续对IM的整改也会逐步的将消息的处理分层剥离；
• 2）消息处理关键节点的流程式上报、建立完整的监控体系，让问题发现先于用户舆情；
• 3）消息完整性的动态自检，最小化数据补偿补全。

9、参考资料

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

[2] IM群聊消息如此复杂，如何保证不丢不重？

[3] 一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践

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

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

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

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

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

[9] 新手入门一篇就够：从零开发移动端IM

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

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

[12] 零基础IM开发入门(四)：什么是IM系统的消息时序一致性？

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

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

本文由作者小林coding分享，来自公号“小林coding”，有修订和改动。

1、引言

说到TCP协议，对于从事即时通讯/IM这方面应用的开发者们来说，再熟悉不过了。随着对TCP理解的越来越深入，很多曾今碰到过但没时间深入探究的TCP技术概念或疑问，现在是时候回头来恶补一下了。

本篇文章，我们就从系统层面深入地探讨一个有趣的TCP技术问题：拔掉网线后，再插上，原本的这条TCP连接还在吗？或者说它还“好”吗？

可能有的人会说：网线都被拔掉了，那说明物理层（也叫实体层）被断开了（关于网络协议分层模型请见《快速理解网络通信协议（上篇）》），那在物理层之上的传输层理应也会断开，所以原本的 TCP 连接就不会存在的了。就好像我们拨打有线电话的时候，如果某一方的电话线被拔了，那么本次通话就彻底断了。

答案真的是这样吗？可能并非你理解的这样哦，一起跟随笔者来深入探讨一下。

学习交流：

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

- 开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK 

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

2、系列文章

本文是系列文章中的第14篇，本系列文章的大纲如下：

• 《不为人知的网络编程(一)：浅析TCP协议中的疑难杂症(上篇)》
• 《不为人知的网络编程(二)：浅析TCP协议中的疑难杂症(下篇)》
• 《不为人知的网络编程(三)：关闭TCP连接时为什么会TIME_WAIT、CLOSE_WAIT》
• 《不为人知的网络编程(四)：深入研究分析TCP的异常关闭》
• 《不为人知的网络编程(五)：UDP的连接性和负载均衡》
• 《不为人知的网络编程(六)：深入地理解UDP协议并用好它》
• 《不为人知的网络编程(七)：如何让不可靠的UDP变的可靠？》
• 《不为人知的网络编程(八)：从数据传输层深度解密HTTP》
• 《不为人知的网络编程(九)：理论联系实际，全方位深入理解DNS》
• 《不为人知的网络编程(十)：深入操作系统，从内核理解网络包的接收过程(Linux篇)》
• 《不为人知的网络编程(十一)：从底层入手，深度分析TCP连接耗时的秘密》
• 《不为人知的网络编程(十二)：彻底搞懂TCP协议层的KeepAlive保活机制》
• 《不为人知的网络编程(十三)：深入操作系统，彻底搞懂127.0.0.1本机网络通信》
• 《不为人知的网络编程(十四)：拔掉网线再插上，TCP连接还在吗？一文即懂！》（* 本文）

3、比较笼统的答案

3.1 答案

引言里我们说到：有人认为，网线都被拔掉了，那说明物理层被断开，那么物理层之上的传输层肯定也会断开，所以原来的 TCP 连接自然也就不存在了。（PS：计算机网络分层详解请见《史上最通俗计算机网络分层详解》）

上面这个逻辑是有问题的。

问题在于：错误的认为拔掉网线这个动作会影响传输层，事实上并不会影响！

实际上：TCP 连接在 Linux 内核中是一个名为 struct socket 的结构体，该结构体的内容包含 TCP 连接的状态等信息。

所以：当拔掉网线的时候，操作系统并不会变更该结构体的任何内容，所以 TCP 连接的状态也不会发生改变。

3.2 实验验证一下

我做了个小实验：我用 ssh 终端连接了我的云服务器，然后我通过断开 wifi 的方式来模拟拔掉网线的场景，此时查看 TCP 连接的状态没有发生变化，还是处于 ESTABLISHED 状态（如下图所示）。

通过上面实验结果可以验证我的结论：拔掉网线这个动作并不会影响 TCP 连接的状态。

不过，这个答案还是有点笼统。实际上，我们应该在更具体的场景中来看待这个问题，答案才更准确一些。

这个具体场景就是：

• 1）当拔掉网线后，有数据传输时；
• 2）当拔掉网线后，没有数据传输时。

针对上面这两种具体的场景，我来更具体地来分析一下。我们继续往下阅读。

4、具体场景1：拔掉网线后，有数据传输时

4.1 数据传输过程中，恰好又把网线插回去了

如果是客户端被拔掉网线后，服务端向客户端发送的数据报文会得不到任何的响应，在等待一定时长后，服务端就会触发TCP协议的超时重传机制（详见：《TCP/IP详解 - 第21章·TCP的超时与重传》），然而此时重传并不能得到响应的数据报文。

如果在服务端重传报文的过程中，客户端恰好把网线插回去了，由于拔掉网线并不会改变客户端的 TCP 连接状态，并且还是处于 ESTABLISHED 状态，所以这时客户端是可以正常接收服务端发来的数据报文的，然后客户端就会回 ACK 响应报文。

此时：客户端和服务端的 TCP 连接将依然存在且工作状态不会受到影响，给应用层的感觉就像什么事情都没有发生。。。

4.2 数据传输过程中，网线一直没有插回去

上面这种情况下，如果在服务端TCP协议重传报文的过程中，客户端一直没有将网线插回去，那么服务端超时重传报文的次数达到一定阈值后，内核就会判定出该 TCP 有问题。然后就会通过 Socket 接口告诉应用程序该 TCP 连接出问题了，于是服务端的 TCP 连接就会断开。

接下来，如果客户端再插回网线，如果客户端向服务端发送了数据，由于服务端已经没有与客户端匹配的 TCP 连接信息了，因此服务端内核就会回复 RST 报文，客户端收到后就会释放该 TCP 连接。

此时：客户端和服务端的 TCP 连接已经明确被断开，原本的这个连接也就不存在了。

4.3 刨根问底：TCP数据报文到底重传几次？

本着知其然更应知其所以然的精神，我们来刨根问底一下：TCP 的数据报文到底有重传几次呢？

在 Linux 系统中，提供了一个叫 tcp_retries2 配置项，默认值是 15（如下图所示）。

如上图所示：这个内核参数是控制 TCP 连接建立的情况下，超时重传的最大次数。

不过 tcp_retries2 设置了 15 次，并不代表 TCP 超时重传了 15 次才会通知应用程序终止该 TCP 连接，内核还会基于“最大超时时间”来判定。

每一轮的超时时间都是倍数增长的，比如第一次触发超时重传是在 2s 后，第二次则是在 4s 后，第三次则是 8s 后，以此类推。

内核会根据 tcp_retries2 设置的值，计算出一个最大超时时间。

在重传报文且一直没有收到对方响应的情况时，先达到“最大重传次数”或者“最大超时时间”这两个的其中一个条件后，就会停止重传，然后就会断开 TCP 连接。

PS：有关TCP超时重传机制的详细情况，可以阅读《浅析TCP协议中的疑难杂症(下篇)》。

5、具体场景2：拔掉网线后，有数据传输时

5.1 场景分析

针对拔掉网线后，没有数据传输的场景，还得具体看看是否开启了 TCP KeepAlive 机制 （详见《彻底搞懂TCP协议层的KeepAlive保活机制》）。

1）如果没有开启 TCP KeepAlive 机制：

在客户端拔掉网线后，并且双方都没有进行数据传输，那么客户端和服务端的 TCP 连接将会一直保持存在。

2）如果开启了 TCP KeepAlive 机制：

在客户端拔掉网线后，即使双方都没有进行数据传输，在持续一段时间后，TCP 就会发送KeepAlive探测报文。

根据KeepAlive探测报文响应情况，会有以下两种可能：

• 1）如果对端正常工作：当探测报文被对端收到并正常响应， TCP 保活时间将被重置，等待下一个 TCP 保活时间的到来；
• 2）如果对端主机崩溃或对端由于其他原因导致报文不可达：当探测报文发送给对端后，石沉大海、没有响应，连续几次，达到保活探测次数后，TCP 会报告该连接已经死亡。

所以：TCP 保活机制可以在双方没有数据交互的情况，通过TCP KeepAlive 机制的探测报文，来确定对方的 TCP 连接是否存活。

5.2 刨根问底：TCP KeepAlive 机制具体是什么样的？

TCP KeepAlive 机制的原理是这样的：

定义一个时间段，在这个时间段内，如果没有任何连接相关的活动，TCP 保活机制会开始作用，每隔一个时间间隔，发送一个探测报文。该探测报文包含的数据非常少，如果连续几个探测报文都没有得到响应，则认为当前的 TCP 连接已经死亡，系统内核将错误信息通知给上层应用程序。

在 Linux 内核可以有对应的参数可以设置保活时间、保活探测的次数、保活探测的时间间隔。

以下是 Linux 中的默认值：

net.ipv4.tcp_keepalive_time=7200

net.ipv4.tcp_keepalive_intvl=75 

net.ipv4.tcp_keepalive_probes=9

解释一下：

• 1）tcp_keepalive_time=7200：表示保活时间是 7200 秒（2小时），也就 2 小时内如果没有任何连接相关的活动，则会启动保活机制；
• 2）tcp_keepalive_intvl=75：表示每次检测间隔 75 秒；
• 3）tcp_keepalive_probes=9：表示检测 9 次无响应，认为对方是不可达的，从而中断本次的连接。

也就是说在 Linux 系统中，最少需要经过 2 小时 11 分 15 秒才可以发现一个“死亡”连接。

计算公式是：

注意：应用程序若想使用 TCP 保活机制需要通过 socket 接口设置 SO_KEEPALIVE 选项才能够生效，如果没有设置，那么就无法使用 TCP 保活机制。

PS：关于TCP协议的KeepAlive 机制详见《彻底搞懂TCP协议层的KeepAlive保活机制》、《一文读懂即时通讯应用中的网络心跳包机制：作用、原理、实现思路等》。

5.3 刨根问底：TCP KeepAlive 机制的探测时间也太长了吧？

没错，确实有点长。

TCP KeepAlive  机制是 TCP 层（内核态） 实现的，它是给所有基于 TCP 传输协议的程序一个兜底的方案。

实际上：我们通常在应用层自己实现一套探测机制，可以在较短的时间内，探测到对方是否存活。

比如：一般Web 服务器都会提供 keepalive_timeout 参数，用来指定 HTTP 长连接的超时时间。如果设置了 HTTP 长连接的超时时间是 60 秒，Web 服务软件就会启动一个定时器，如果客户端在完后一个 HTTP 请求后，在 60 秒内都没有再发起新的请求，定时器的时间一到，就会触发回调函数来释放该连接。

再比如：IM、消息推送系统里的心跳机制，通过应用层的心跳机制（由客户端发出，服务端回复响应包），来灵活控制和探测长连接的健康度。

《为何基于TCP协议的移动端IM仍然需要心跳保活机制？》这篇文章解释了IM这类应用中应用层心跳保活的必要性，有兴趣可以读一读。

如果对应用层心跳的具体应用没什么概念，可以看看微信的这两篇文章：

1. 《微信团队原创分享：Android版微信后台保活实战分享(网络保活篇)》
2. 《移动端IM实践：实现Android版微信的智能心跳机制》

下面有几个针对im这类应用的心跳实现代码，可以具体感受学习一下：

1. 《正确理解IM长连接的心跳及重连机制，并动手实现（有完整IM源码）》
2. 《一种Android端IM智能心跳算法的设计与实现探讨（含样例代码）》
3. 《自已开发IM有那么难吗？手把手教你自撸一个Andriod版简易IM (有源码)》
4. 《手把手教你用Netty实现网络通信程序的心跳机制、断线重连机制》

6、本文小结

下面简单总结一下文中的内容，本文开头的问题并不是简单一句话能够准确说清楚的，需要分情况对待。

也就是：客户端拔掉网线后，并不会直接影响 TCP 的连接状态。所以拔掉网线后，TCP 连接是否还会存在，关键要看拔掉网线之后，有没有进行数据传输。

1）有数据传输的情况：

在客户端拔掉网线后：如果服务端发送了数据报文，那么在服务端重传次数没有达到最大值之前，客户端恰好插回网线的话，那么双方原本的 TCP 连接还是能存在并正常工作，就好像什么事情都没有发生。

在客户端拔掉网线后：如果服务端发送了数据报文，在客户端插回网线之前，服务端重传次数达到了最大值时，服务端就会断开 TCP 连接。等到客户端插回网线后，向服务端发送了数据，因为服务端已经断开了与客户端相同四元组的 TCP 连接，所以就会回 RST 报文，客户端收到后就会断开 TCP 连接。至此， 双方的 TCP 连接都断开了。

2）没有数据传输的情况：

• a. 如果双方都没有开启 TCP keepalive 机制，那么在客户端拔掉网线后，如果客户端一直不插回网线，那么客户端和服务端的 TCP 连接状态将会一直保持存在；
• b. 如果双方都开启了 TCP keepalive 机制，那么在客户端拔掉网线后，如果客户端一直不插回网线，TCP keepalive 机制会探测到对方的 TCP 连接没有存活，于是就会断开 TCP 连接。而如果在 TCP 探测期间，客户端插回了网线，那么双方原本的 TCP 连接还是能正常存在。

除了客户端拔掉网线的场景，还有客户端“宕机和杀死进程”的两种场景。

第一个场景：客户端宕机这件事跟拔掉网线是一样无法被服务端的感知的，所以如果在没有数据传输，并且没有开启 TCP keepalive 机制时，，服务端的 TCP 连接将会一直处于 ESTABLISHED 连接状态，直到服务端重启进程。

所以：我们可以得知一个点——在没有使用 TCP 保活机制，且双方不传输数据的情况下，一方的 TCP 连接处在 ESTABLISHED 状态时，并不代表另一方的 TCP 连接还一定是正常的。

第二个场景：杀死客户端的进程后，客户端的内核就会向服务端发送 FIN 报文，与客户端进行四次挥手（见《跟着动画来学TCP三次握手和四次挥手》）。

所以：即使没有开启 TCP KeepAlive，且双方也没有数据交互的情况下，如果其中一方的进程发生了崩溃，这个过程操作系统是可以感知的到的，于是就会发送 FIN 报文给对方，然后与对方进行 TCP 四次挥手。

7、参考资料

[1] TCP/IP详解 - 第21章·TCP的超时与重传

[2] 通俗易懂-深入理解TCP协议（上）：理论基础

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

[4] 脑残式网络编程入门(一)：跟着动画来学TCP三次握手和四次挥手

[5] 脑残式网络编程入门(七)：面视必备，史上最通俗计算机网络分层详解

[6] 技术大牛陈硕的分享：由浅入深，网络编程学习经验干货总结

[7] 网络编程入门从未如此简单(二)：假如你来设计TCP协议，会怎么做？

[8] 不为人知的网络编程(十)：深入操作系统，从内核理解网络包的接收过程(Linux篇)

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

[10] 一文读懂即时通讯应用中的网络心跳包机制：作用、原理、实现思路等

[11] Web端即时通讯实践干货：如何让你的WebSocket断网重连更快速？

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

本文由融云技术团队原创分享，有修订和改动。

1、引言

在视频直播场景中，弹幕交互、与主播的聊天、各种业务指令等等，组成了普通用户与主播之间的互动方式。

从技术的角度来看，这些实时互动手段，底层逻辑都是实时聊天消息或指令的分发，技术架构类比于IM应用的话，那就相当于IM聊天室功能。

本系列文章的上篇《百万人在线的直播间实时聊天消息分发技术实践》主要分享的是消息分发和丢弃策略。本文将主要从高可用、弹性扩缩容、用户管理、消息分发、客户端优化等角度，分享直播间海量聊天消息的架构设计技术难点的实践经验。

学习交流：

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

- 开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK 

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

2、系列文章

本文是系列文章中的第7篇：

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

《直播系统聊天技术(二)：阿里电商IM消息平台，在群聊、直播场景下的技术实践》

《直播系统聊天技术(三)：微信直播聊天室单房间1500万在线的消息架构演进之路》

《直播系统聊天技术(四)：百度直播的海量用户实时消息系统架构演进实践》

《直播系统聊天技术(五)：微信小游戏直播在Android端的跨进程渲染推流实践》

《直播系统聊天技术(六)：百万人在线的直播间实时聊天消息分发技术实践》

《直播系统聊天技术(七)：直播间海量聊天消息的架构设计难点实践》（* 本文）

3、直播间的主要功能和技术特征

如今的视频直播间早已不单纯是视频流媒体技术问题，它还包含了用户可感知的多类型消息发送和管理、用户管理等任务。在万物皆可直播的当下，超大型直播场景屡见不鲜，甚至出现了人数无上限的场景，面对如此海量实时消息和指令的并发挑战，带来的技术难度已非常规手段所能解决。

我们先来归纳一下如今的典型视频直播间，相较于传统直播间所包含的主要功能特征、技术特征等。

丰富的消息类型和进阶功能：

• 1）可发送文字、语音、图片等传统聊天功能；
• 2）可实现点赞、礼物等非传统聊天功能的消息类型；
• 3）可管理内容安全，包括敏感词设置，聊天内容反垃圾处理等。

聊天管理功能：

• 1）用户管理：包括创建、加入、销毁、禁言、查询、封禁（踢人）等；
• 2）用户白名单：白名单用户处于被保护状态不会被自动踢出，且发送消息优先级别最高；
• 3）消息管理：包括消息优先级、消息分发控制等；
• 4）实时统计及消息路由等能力。

人数上限和行为特征：

• 1）人数没有上限：一些大型直播场景，如春晚、国庆大阅兵等，直播间累计观看动辄上千万人次，同时观看人数也可达数百万；
• 2）用户进退行为：用户进出直播间非常频繁，高热度直播间的人员进出秒并发可能上万，这对服务支撑用户上下线以及用户管理的能力提出了非常大的挑战。

海量消息并发：

• 1）消息并发量大：直播聊天室人数没有明显上限，带来了海量并发消息的问题（一个百万人数的聊天室，消息的上行已是巨量，消息分发量更是几何级上升）；
• 2）消息实时性高：如果服务器只做消息的消峰处理，峰值消息的堆积会造成整体消息延时增大。

针对上述第 2） 点，延时的累积效应会导致消息与直播视频流在时间线上产生偏差，进而影响用户观看直播时互动的实时性。所以，服务器的海量消息快速分发能力十分重要。

4、直播间聊天室的架构设计

高可用系统需要支持服务故障自动转移、服务精准熔断降级、服务治理、服务限流、服务可回滚、服务自动扩容 / 缩容等能力。

以服务高可用为目标的直播间聊天室系统架构如下：

如上图所示，系统架构主要分三层：

• 1）连接层：主要管理服务跟客户端的长链接；
• 2）存储层：当前使用的是 Redis，作为二级缓存，主要存储聊天室的信息（比如人员列表、黑白名单、封禁列表等，服务更新或重启时，可以从 Redis 中加载出聊天室的备份信息）；
• 3）业务层：这是整个聊天室的核心，为了实现跨机房容灾，将服务部署在多个可用区，并根据能力和职责，将其分为聊天室服务和消息服务。

聊天室服务和消息服务的具体职责：

• 1）聊天室服务：主要负责处理管理类请求，比如聊天室人员的进出、封禁 / 禁言、上行消息处理审核等；
• 2）消息服务：主要缓存本节点需要处理的用户信息以及消息队列信息，并负责聊天室消息的分发。

在海量用户高并发场景下，消息分发能力将决定着系统的性能。以一个百万级用户量的直播间聊天室为例，一条上行消息对应的是百万倍的分发。这种情况下，海量消息的分发，依靠单台服务器是无法实现的。

我们的优化思路是：将一个聊天室的人员分拆到不同的消息服务上，在聊天室服务收到消息后向消息服务扩散，再由消息服务分发给用户。

以百万在线的直播间聊天室为例：假设聊天室消息服务共 200 台，那平均每台消息服务管理 5000 人左右，每台消息服务在分发消息时只需要给落在本台服务器上的用户分发即可。

服务落点的选择逻辑：

• 1）在聊天室服务中：聊天室的上行信令是依据聊天室 ID 使用一致性哈希算法来选择节点的；
• 2）在消息服务中：依据用户 ID 使用一致性哈希算法来决定用户具体落在哪个消息服务。

一致性哈希选择的落点相对固定，可以将聊天室的行为汇聚到一个节点上，极大提升服务的缓存命中率。

聊天室人员进出、黑 / 白名单设置以及消息发送时的判断等处理直接访问内存即可，无须每次都访问第三方缓存，从而提高了聊天室的响应速度和分发速度。

最后：Zookeeper 在架构中主要用来做服务发现，各服务实例均注册到 Zookeeper。

5、直播间聊天室的扩缩容能力

5.1 概述

随着直播这种形式被越来越多人接受，直播间聊天室面对人数激增致使服务器压力逐步增大的情况越来越多。所以，在服务压力逐步增大 / 减少的过程中能否进行平滑的扩 / 缩容非常重要。

在服务的自动扩缩容方面，业内提供的方案大体一致：即通过压力测试了解单台服务器的瓶颈点 → 通过对业务数据的监控来判断是否需要进行扩缩 → 触发设定的条件后报警并自动进行扩缩容。

鉴于直播间聊天室的强业务性，具体执行中应该保证在扩缩容中整体聊天室业务不受影响。

5.2 聊天室服务扩缩容

聊天室服务在进行扩缩容时，我们通过 Redis 来加载成员列表、封禁 / 黑白名单等信息。

需要注意的是：在聊天室进行自动销毁时，需先判断当前聊天室是否应该是本节点的。如果不是，跳过销毁逻辑，避免 Redis 中的数据因为销毁逻辑而丢失。

聊天室服务扩缩容方案细节如下图所示：

5.3 消息服务扩缩容

消息服务在进行扩缩容时，大部分成员需要按照一致性哈希的原则路由到新的消息服务节点上。这个过程会打破当前的人员平衡，并做一次整体的人员转移。

1）在扩容时：我们根据聊天室的活跃程度逐步转移人员。

2）在有消息时：[消息服务会遍历缓存在本节点上的所有用户进行消息的通知拉取，在此过程中判断此用户是否属于这台节点（如果不是，将此用户同步加入到属于他的节点）。

3）在拉消息时：用户在拉取消息时，如果本机缓存列表中没有该用户，消息服务会向聊天室服务发送请求确认此用户是否在聊天室中（如果在则同步加入到消息服务，不在则直接丢掉）。

4）在缩容时：消息服务会从公共 Redis 获得全部成员，并根据落点计算将本节点用户筛选出来并放入用户管理列表中。

6、海量用户的上下线和管理

聊天室服务：管理了所有人员的进出，人员的列表变动也会异步存入 Redis 中。

消息服务：则维护属于自己的聊天室人员，用户在主动加入和退出房间时，需要根据一致性哈希算出落点后同步给对应的消息服务。

聊天室获得消息后：聊天室服务广播给所有聊天室消息服务，由消息服务进行消息的通知拉取。消息服务会检测用户的消息拉取情况，在聊天室活跃的情况下，30s 内人员没有进行拉取或者累计 30 条消息没有拉取，消息服务会判断当前用户已经离线，然后踢出此人，并且同步给聊天室服务对此成员做下线处理。

7、海量聊天消息的分发策略

直播间聊天室服务的消息分发及拉取方案如下图：

7.1 消息通知的拉取

在上图中：用户 A 在聊天室中发送一条消息，首先由聊天室服务处理，聊天室服务将消息同步到各消息服务节点，消息服务向本节点缓存的所有成员下发通知拉取（图中服务器向用户 B 和用户 Z 下发了通知）。

在消息分发过程中，server 做了通知合并。

通知拉取的详细流程为：

• 1）客户端成功加入聊天，将所有成员加入到待通知队列中（如已存在则更新通知消息时间）；
• 2）下发线程，轮训获取待通知队列；
• 3）向队列中用户下发通知拉取。

通过这个流程可保障下发线程一轮只会向同一用户发送一个通知拉取（即多个消息会合并为一个通知拉取），有效提升了服务端性能且降低了客户端与服务端的网络消耗。

7.2 消息的拉取

用户的消息拉取流程如下图：

 

如上图所示，用户 B 收到通知后向服务端发送拉取消息请求，该请求最终将由消息节点 1 进行处理，消息节点 1 将根据客户端传递的最后一条消息时间戳，从消息队列中返回消息列表（参考下图 ）。

客户端拉取消息示例：

用户端本地最大时间为 1585224100000，从 server 端可以拉取到比这个数大的两条消息。

7.3 消息控速

服务器应对海量消息时，需要做消息的控速处理。

这是因为：在直播间聊天室中，大量用户在同一时段发送的海量消息，一般情况下内容基本相同。如果将所有消息全部分发给客户端，客户端很可能出现卡顿、消息延迟等问题，严重影响用户体验。

所以服务器对消息的上下行都做了限速处理。

消息控速原理：

具体的限速控制策略如下：

• 1）服务器上行限速控制（丢弃）策略：针对单个聊天室的消息上行的限速控制，我们默认为 200 条 / 秒，可根据业务需要调整。达到限速后发送的消息将在聊天室服务丢弃，不再向各消息服务节点同步；
• 2）服务器下行限速（丢弃）策略：服务端的下行限速控制，主要是根据消息环形队列的长度进行控制，达到最大值后最“老”的消息将被淘汰丢弃。

每次下发通知拉取后服务端将该用户标记为拉取中，用户实际拉取消息后移除该标记。

如果产生新消息时用户有拉取中标记：

• 1）距设置标记时间在 2 秒内，则不会下发通知（降低客户端压力，丢弃通知未丢弃消息）；
• 2）超过 2 秒则继续下发通知（连续多次通知未拉取则触发用户踢出策略，不在此赘述）。

因此：消息是否被丢弃取决于客户端拉取速度（受客户端性能、网络影响）,客户端及时拉取消息则没有被丢弃的消息。

8、直播间聊天室的消息优先级

消息控速的核心是对消息的取舍，这就需要对消息做优先级划分。

划分逻辑大致如下：

• 1）白名单消息：这类消息最为重要，级别最高，一般系统类通知或者管理类信息会设置为白名单消息；
• 2）高优先级消息：仅次于白名单消息，没有特殊设置过的消息都为高优先级；
• 3）低优先级消息：最低优先级的消息，这类消息大多是一些文字类消息。

具体如何划分，应该是可以开放出方便的接口进行设置的。

服务器对三种消息执行不同的限速策略，在高并发时，低优先级消息被丢弃的概率最大。

服务器将三种消息分别存储在三个消息桶中：客户端在拉取消息时按照白名单消息 ＞ 高优先级消息 ＞ 低优先级消息的顺序拉取。

9、客户端针对大量消息的接收和渲染优化

9.1 消息的接收优化

在消息同步机制方面，如果直播间聊天室每收到一条消息都直接下发到客户端，无疑会给客户端带来极大性能挑战。特别是在每秒几千或上万条消息的并发场景下，持续的消息处理会占用客户端有限的资源，影响用户其它方面的互动。

考虑到以上问题，为聊天室单独设计了通知拉取机制，由服务端进行一系列分频限速聚合等控制后，再通知客户端拉取。

具体分为以下几步：

• 1）客户端成功加入聊天室；
• 2）服务端下发通知拉取信令；
• 3）客户端根据本地存储的消息最大时间戳，去服务端拉取消息。

这里需要注意的是：首次加入直播间聊天室时，本地并没有有效时间戳，此时会传 0 给服务拉取最近 50 条消息并存库。后续再次拉取时才会传递数据库里存储的消息的最大时间戳，进行差量拉取。

客户端拉取到消息后：会进行排重处理，然后将排重后的数据上抛业务层，以避免上层重复显示。

另外：直播间聊天室中的消息即时性较强，直播结束或用户退出聊天室后，之前拉取的消息大部分不需要再次查看，因此在用户退出聊天室时，会清除数据库中该聊天室的所有消息，以节约存储空间。

9.2 消息的渲染优化

在消息渲染方面，客户端也通过一系列优化保证在直播间聊天室大量消息刷屏的场景下仍有不俗的表现。

以Andriod端为例，具体的措施有：

• 1）采用 MVVM 机制：将业务处理和 UI 刷新严格区分。每收到一条消息，都在 ViewModel 的子线程将所有业务处理好，并将页面刷新需要的数据准备完毕后，才通知页面刷新；
• 2）降低主线程负担：精确使用 LiveData 的 setValue() 和 postValue() 方法：已经在主线程的事件通过  setValue() 方式通知 View 刷新，以避免过多的 postValue() 造成主线程负担过重；
• 3）减少非必要刷新：比如在消息列表滑动时，并不需要将接收到的新消息刷新出来，仅进行提示即可；
• 4）识别数据的更新：通过谷歌的数据对比工具 DiffUtil 识别数据是否有更新，仅更新有变更的部分数据；
• 5）控制全局刷新次数：尽量通过局部刷新进行 UI 更新。

通过以上机制：从压测结果看，在中端手机上，直播间聊天室中每秒 400 条消息时，消息列表仍然表现流畅，没有卡顿。

10、针对传统聊天消息外的自定义属性优化

10.1 概述

在直播间聊天室场景中，除了传统的聊天消息收发以外，业务层经常需要有自己的一些业务属性，如在语音直播聊天室场景中的主播麦位信息、角色管理等，还有狼人杀等卡牌类游戏场景中记录用户的角色和牌局状态等。

相对于传统聊天消息，自定义属性有必达和时效的要求，比如麦位、角色等信息需要实时同步给聊天室的所有成员，然后客户端再根据自定义属性刷新本地的业务。

10.2 自定义属性的存储

自定义属性是以 key 和 value 的形式进行传递和存储的。自定义属性的操作行为主要有两种：即设置和删除。

服务器存储自定义属性也分两部分：

• 1）全量的自定义属性集合；
• 2）自定义属性集合变更记录。

自定义属性存储结构如下图所示：

针对这两份数据，应该提供两种查询接口，分别是查询全量数据和查询增量数据。这两种接口的组合应用可以极大提升聊天室服务的属性查询响应和自定义分发能力。

10.3 自定义属性的拉取

内存中的全量数据，主要给从未拉取过自定义属性的成员使用。刚进入聊天室的成员，直接拉取全量自定义属性数据然后展示即可。

对于已经拉取过全量数据的成员来说，若每次都拉取全量数据，客户端想获得本次的修改内容，就需要比对客户端的全量自定义属性与服务器端的全量自定义属性，无论比对行为放在哪一端，都会增加一定的计算压力。

所以：为了实现增量数据的同步，构建一份属性变更记录集合十分必要。这样：大部分成员在收到自定义属性有变更来拉取时，都可以获得增量数据。

属性变更记录采用的是一个有序的 map 集合：key 为变更时间戳，value 里存着变更的类型以及自定义属性内容，这个有序的 map 提供了这段时间内所有的自定义属性的动作。

自定义属性的分发逻辑与消息一致：均为通知拉取。即客户端在收到自定义属性变更拉取的通知后，带着自己本地最大自定义属性的时间戳来拉取。比如：如果客户端传的时间戳为 4，则会拉取到时间戳为 5 和时间戳为 6 的两条记录。客户端拉取到增量内容后在本地进行回放，然后对自己本地的自定义属性进行修改和渲染。

11、多人群聊参考资料

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

[2] IM群聊消息如此复杂，如何保证不丢不重？

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

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

[5] 关于IM即时通讯群聊消息的乱序问题讨论

[6] IM群聊消息的已读回执功能该怎么实现？

[7] IM群聊消息究竟是存1份(即扩散读)还是存多份(即扩散写)？

[8] 一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践

[9] IM群聊机制，除了循环去发消息还有什么方式？如何优化？

[10] 网易云信技术分享：IM中的万人群聊技术方案实践总结

[11] 阿里钉钉技术分享：企业级IM王者——钉钉在后端架构上的过人之处

[12] IM群聊消息的已读未读功能在存储空间方面的实现思路探讨

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

[14] 融云IM技术分享：万人群聊消息投递方案的思考和实践

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

本文由cxuan分享，原题“原来这才是 Socket”，有修订。

1、引言

本系列文章前面那些主要讲解的是计算机网络的理论基础，但对于即时通讯IM这方面的应用层开发者来说，跟计算机网络打道的其实是各种API接口。

本篇文章就来聊一下网络应用程序员最熟悉的Socket这个东西，抛开生涩的计算机网络理论，从应用层的角度来理解到底什么是Socket。

对于 Socket 的认识，本文将从以下几个方面着手介绍：

• 1）Socket 是什么；
• 2）Socket 是如何创建的；
• 3）Socket 是如何连接的；
• 4）Socket 是如何收发数据的；
• 5）Socket 是如何断开连接的；
• 6）Socket 套接字的删除等。

特别说明：本文中提到的“Socket”、“网络套接字”、“套接字”，如无特殊指明，指的都是同一个东西哦。

 

学习交流：

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

- 开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK 

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

2、Socket 是什么

一个数据包经由应用程序产生，进入到协议栈中进行各种报文头的包装，然后操作系统调用网卡驱动程序指挥硬件，把数据发送到对端主机。

整个过程的大体的图示如下：

我们大家知道，协议栈其实是位于操作系统中的一些协议的堆叠，这些协议包括 TCP、UDP、ARP、ICMP、IP等。

通常某个协议的设计都是为了解决特定问题的，比如：

• 1）TCP 的设计就负责安全可靠的传输数据；
• 2）UDP 设计就是报文小，传输效率高；
• 3）ARP 的设计是能够通过 IP 地址查询物理（Mac）地址；
• 4）ICMP 的设计目的是返回错误报文给主机；
• 5）IP 设计的目的是为了实现大规模主机的互联互通。

应用程序比如浏览器、电子邮件、文件传输服务器等产生的数据，会通过传输层协议进行传输。而应用程序是不会和传输层直接建立联系的，而是有一个能够连接应用层和传输层之间的套件，这个套件就是 Socket。

在上面这幅图中，应用程序包含 Socket 和解析器，解析器的作用就是向 DNS 服务器发起查询，查询目标 IP 地址（关于DNS请见《理论联系实际，全方位深入理解DNS》）。

应用程序的下面：就是操作系统内部，操作系统内部包括协议栈，协议栈是一系列协议的堆叠。

操作系统下面：就是网卡驱动程序，网卡驱动程序负责控制网卡硬件，驱动程序驱动网卡硬件完成收发工作。

在操作系统内部有一块用于存放控制信息的存储空间，这块存储空间记录了用于控制通信的控制信息。其实这些控制信息就是 Socket 的实体，或者说存放控制信息的内存空间就是Socket的实体。

这里大家有可能不太清楚所以然，所以我用了一下 netstat 命令来给大伙看一下Socket是啥玩意。

我们在 Windows 的命令提示符中输入：

netstat-ano

# netstat 用于显示Socket内容 , -ano 是可选选项

# a 不仅显示正在通信的Socket，还显示包括尚未开始通信等状态的所有Socket

# n 显示 IP 地址和端口号

# o 显示Socket的程序 PID

我的计算机会出现下面结果：

如上图所示：

• 1）每一行都相当于一个Socket；
• 2）每一列也被称为一个元组。

所以，一个Socket就是五元组：

• 1）协议；
• 2）本地地址；
• 3）外部地址；
• 4）状态；
• 5）PID。

PS：有的时候也被叫做四元组，四元组不包括协议。

我们来解读一下上图中的数据，比如图中的第一行：

1）它的协议就是 TCP，本地地址和远程地址都是 0.0.0.0（这表示通信还没有开始，IP 地址暂时还未确定）。

2）而本地端口已知是 135，但是远程端口还未知，此时的状态是 LISTENING（LISTENING 表示应用程序已经打开，正在等待与远程主机建立连接。关于各种状态之间的转换，大家可以阅读《通俗易懂-深入理解TCP协议（上）：理论基础》）。

3）最后一个元组是 PID，即进程标识符，PID 就像我们的身份证号码，能够精确定位唯一的进程。

3、Socket 是如何创建的

通过上节的讲解，现在你可能对 Socket 有了一个基本的认识，先喝口水，休息一下，让我们继续探究 Socket。

现在我有个问题，Socket 是如何创建的呢？

Socket 是和应用程序一起创建的。

应用程序中有一个 socket 组件，在应用程序启动时，会调用 socket 申请创建Socket，协议栈会根据应用程序的申请创建Socket：首先分配一个Socket所需的内存空间，这一步相当于是为控制信息准备一个容器，但只有容器并没有实际作用，所以你还需要向容器中放入控制信息；如果你不申请创建Socket所需要的内存空间，你创建的控制信息也没有地方存放，所以分配内存空间，放入控制信息缺一不可。至此Socket的创建就已经完成了。

Socket创建完成后，会返回一个Socket描述符给应用程序，这个描述符相当于是区分不同Socket的号码牌。根据这个描述符，应用程序在委托协议栈收发数据时就需要提供这个描述符。

4、Socket 是如何连接的

Socket创建完成后，最终还是为数据收发服务的。但是，在数据收发之前，还需要进行一步“连接”（术语就是 connect），建立连接有一整套过程。

这个“连接”并不是真实的连接（用一根水管插在两个电脑之间？不是你想的这样。。。）。

实际上这个“连接”是应用程序通过 TCP/IP 协议标准从一个主机通过网络介质传输到另一个主机的过程。

Socket刚刚创建完成后，还没有数据，也不知道通信对象。

在这种状态下：即使你让客户端应用程序委托协议栈发送数据，它也不知道发送到哪里。所以浏览器需要根据网址来查询服务器的 IP 地址（做这项工作的协议是 DNS），查询到目标主机后，再把目标主机的 IP 告诉协议栈。至此，客户端这边就准备好了。

在服务器上：与客户端一样也需要创建Socket，但是同样的它也不知道通信对象是谁，所以我们需要让客户端向服务器告知客户端的必要信息：IP 地址和端口号。

现在通信双方建立连接的必要信息已经具备，可以开始“连接”过程了。

首先：客户端应用程序需要调用 Socket 库中的 connect 方法，提供 socket 描述符和服务器 IP 地址、端口号。

以下是connect的伪码调用：

connect(<描述符>、<服务器IP地址和端口号>)

这些信息会传递给协议栈中的 TCP 模块，TCP 模块会对请求报文进行封装，再传递给 IP 模块，进行 IP 报文头的封装，然后传递给物理层，进行帧头封装。

之后通过网络介质传递给服务器，服务器上会对帧头、IP 模块、TCP 模块的报文头进行解析，从而找到对应的Socket。

Socket收到请求后，会写入相应的信息，并且把状态改为正在连接。

请求过程完成后：服务器的 TCP 模块会返回响应，这个过程和客户端是一样的（如果大家不太清楚报文头的封装过程，可以阅读《快速理解TCP协议一篇就够》）。

在一个完整的请求和响应过程中，控制信息起到非常关键的作用：

• 1）SYN 就是同步的缩写，客户端会首先发送 SYN 数据包，请求服务端建立连接；
• 2）ACK 就是相应的意思，它是对发送 SYN 数据包的响应；
• 3）FIN 是终止的意思，它表示客户端/服务器想要终止连接。

由于网络环境的复杂多变，经常会存在数据包丢失的情况，所以双方通信时需要相互确认对方的数据包是否已经到达，而判断的标准就是 ACK 的值。

上面的文字不够生动，动画可以更好的说明这个过程：

▲ 上图引用自《跟着动画来学TCP三次握手和四次挥手》

（PS：这个“连接”的详细理论知识，可以阅读《理论经典：TCP协议的3次握手与4次挥手过程详解》、《跟着动画来学TCP三次握手和四次挥手》，这里不再赘述。）

当所有建立连接的报文都能够正常收发之后，此时套接字就已经进入可收发状态了，此时可以认为用一根管理把两个套接字连接了起来。当然，实际上并不存在这个管子。建立连接之后，协议栈的连接操作就结束了，也就是说 connect 已经执行完毕，控制流程被交回给应用程序。

另外：如果你对Socket代码更熟悉的话，可以先读读这篇《手把手教你写基于TCP的Socket长连接》。

5、Socket 是如何收发数据的

当控制流程上节中的连接过程回到应用程序之后，接下来就会直接进入数据收发阶段。

数据收发操作是从应用程序调用 write 将要发送的数据交给协议栈开始的，协议栈收到数据之后执行发送操作。

协议栈不会关心应用程序传输过来的是什么数据，因为这些数据最终都会转换为二进制序列，协议栈在收到数据之后并不会马上把数据发送出去，而是会将数据放在发送缓冲区，再等待应用程序发送下一条数据。

为什么收到数据包不会直接发送出去，而是放在缓冲区中呢？

因为只要一旦收到数据就会发送，就有可能发送大量的小数据包，导致网络效率下降（所以协议栈需要将数据积攒到一定数量才能将其发送出去）。

至于协议栈会向缓冲区放多少数据，这个不同版本和种类的操作系统有不同的说法。

不过，所有的操作系统都会遵循下面这几个标准：

1）第一个判断要素：是每个网络包能够容纳的数据长度，判断的标准是 MTU，它表示的是一个网络包的最大长度。最大长度包含头部，所以如果单论数据区的话，就会用 MTU - 包头长度，由此的出来的最大数据长度被称为 MSS。

2）另一个判断标准：是时间，当应用程序产生的数据比较少，协议栈向缓冲区放置数据效率不高时，如果每次都等到 MSS 再发送的话，可能因为等待时间太长造成延迟。在这种情况下，即使数据长度没有到达 MSS，也应该把数据发送出去。

但协议栈并没有告诉我们怎样平衡这两个因素，如果数据长度优先，那么效率有可能比较低；如果时间优先，那又会降低网络的效率。

经过了一段时间。。。。。。

假设我们使用的是长度有限法则：此时缓冲区已满，协议栈要发送数据了，协议栈刚要把数据发送出去，却发现无法一次性传输这么大数据量（相对的）的数据，那怎么办呢？

在这种情况下，发送缓冲区中的数据就会超过 MSS 的长度，发送缓冲区中的数据会以 MSS 大小为一个数据包进行拆分，拆分出来的每块数据都会加上 TCP，IP，以太网头部，然后被放进单独的网络包中。

TCP 模块在拆分数据时，会计算出网络包偏移量，这个偏移量就是相对于数据从头开始计算的第几个字节，并将算好的字节数写在 TCP 头部，TCP 模块还会生成一个网络包的序号（SYN），这个序号是唯一的，这个序号就是用来让服务器进行确认的。

服务器会对客户端发送过来的数据包进行确认，确认无误之后，服务器会生成一个序号和确认号（ACK）并一起发送给客户端，客户端确认之后再发送确认号给服务器。

我们来看一下实际的工作过程：

首先：客户端在连接时需要计算出序号初始值，并将这个值发送给服务器。

接下来：服务器通过这个初始值计算出确认号并返回给客户端（初始值在通信过程中有可能会丢弃，因此当服务器收到初始值后需要返回确认号用于确认）。

同时：服务器也需要计算出从服务器到客户端方向的序号初始值，并将这个值发送给客户端。然后，客户端也需要根据服务器发来的初始值计算出确认号发送给服务器。

至此：连接建立完成，接下来就可以进入数据收发阶段了。

数据收发阶段中，通信双方可以同时发送请求和响应，双方也可以同时对请求进行确认。

请求 - 确认机制非常强大：通过这一机制，我们可以确认接收方有没有收到某个包，如果没有收到则重新发送，这样一来，但凡网络中出现的任何错误，我们都可以即使发现并补救。

上面的文字不够生动，动画可以更好的理解请求 - 确认机制：

▲ 上图引用自《跟着动画来学TCP三次握手和四次挥手》

网卡、集线器、路由器（见《史上最通俗的集线器、交换机、路由器功能原理入门》）都没有错误补救机制，一旦检测到错误就会直接丢弃数据包，应用程序也没有这种机制，起作用的只是 TCP/IP 模块。

由于网络环境复杂多变，所以数据包会存在丢失情况，因此发送序号和确认号也存在一定规则，TCP 会通过窗口管理确认号，我们这篇文章不再赘述，大家可以阅读《通俗易懂-深入理解TCP协议（下）：RTT、滑动窗口、拥塞处理》来寻找答案。

PS：另一篇《我们在读写Socket时，究竟在读写什么？》中用动画详细说明了这个过程，有兴趣可以读一读。

6、Socket 是如何断开连接的

当通信双方不再需要收发数据时，需要断开连接。不同的应用程序断开连接的时机不同。

以 Web 为例：浏览器向 Web 服务器发送请求消息，Web 服务器再返回响应消息，这时收发数据就全部结束了，服务器可能会首先发起断开响应，当然客户端也有可能会首先发起（谁先断开连接是应用程序做出的判断），与协议栈无关。

无论哪一方发起断开连接的请求，都会调用 Socket 库的 close 程序。

我们以服务器断开连接为例：服务器发起断开连接请求，协议栈会生成断开连接的 TCP 头部，其实就是设置 FIN 位，然后委托 IP 模块向客户端发送数据，与此同时，服务器的Socket会记录下断开连接的相关信息。

收到服务器发来 FIN 请求后：客户端协议栈会将Socket标记为断开连接状态，然后，客户端会向服务器返回一个确认号，这是断开连接的第一步，在这一步之后，应用程序还会调用 read 来读取数据。等到服务器数据发送完成后，协议栈会通知客户端应用程序数据已经接收完毕。

只要收到服务器返回的所有数据，客户端就会调用 close 程序来结束收发操作，这时客户端会生成一个 FIN 发送给服务器，一段时间后服务器返回 ACK 号。至此，客户端和服务器的通信就结束了。

上面的文字不够生动，动画可以更好的说明这个过程：

▲ 上图引用自《跟着动画来学TCP三次握手和四次挥手》

PS：断开连接的详细理论知识，可以阅读《理论经典：TCP协议的3次握手与4次挥手过程详解》、《跟着动画来学TCP三次握手和四次挥手》，这里不再赘述。

7、Socket的删除

上述通信过程完成后，用来通信的Socket就不再会使用了，此时我们就可以删除这个Socket了。

不过，这时候Socket不会马上删除，而是等过一段时间再删除。

等待这段时间是为了防止误操作，最常见的误操作就是客户端返回的确认号丢失，至于等待多长时间，和数据包重传的方式有关，这里我们就深入展开讨论了。

关于Socket操作的全过程，如果从系统的角度来看，可能会更深入一些，建议可以深入阅读张彦飞的《深入操作系统，从内核理解网络包的接收过程(Linux篇)》一文。

8、系列文章

本文是系列文章中的第14篇，本系列文章的大纲如下：

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

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

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

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

[5] 网络编程懒人入门(五)：快速理解为什么说UDP有时比TCP更有优势

[6] 网络编程懒人入门(六)：史上最通俗的集线器、交换机、路由器功能原理入门

[7] 网络编程懒人入门(七)：深入浅出，全面理解HTTP协议

[8] 网络编程懒人入门(八)：手把手教你写基于TCP的Socket长连接

[9] 网络编程懒人入门(九)：通俗讲解，有了IP地址，为何还要用MAC地址？

[10] 网络编程懒人入门(十)：一泡尿的时间，快速读懂QUIC协议

[11] 网络编程懒人入门(十一)：一文读懂什么是IPv6

[12] 网络编程懒人入门(十二)：快速读懂Http/3协议，一篇就够！

[13] 网络编程懒人入门(十三)：一泡尿的时间，快速搞懂TCP和UDP的区别

[14] 网络编程懒人入门(十四)：到底什么是Socket？一文即懂！（* 本文)

9、参考资料

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

[2] TCP/IP详解 - 第18章·TCP连接的建立与终止

[3] TCP/IP详解 - 第21章·TCP的超时与重传

[4] 快速理解网络通信协议（上篇）

[5] 快速理解网络通信协议（下篇）

[6] 面视必备，史上最通俗计算机网络分层详解

[7] 假如你来设计网络，会怎么做？

[8] 假如你来设计TCP协议，会怎么做？

[10] 浅析TCP协议中的疑难杂症(下篇)

[11] 关闭TCP连接时为什么会TIME_WAIT、CLOSE_WAIT

[12] 从底层入手，深度分析TCP连接耗时的秘密

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