本文由腾讯技术团队原创分享于鹅厂黑板报，下文有排版优化。

1、写在前面

直至现在，「微信鸿蒙版」这五个字，依然被赋予着太多意义。

这是一款产品，也不仅仅是一款产品。开发它的本质，是让两个高速前进，相互影响的复杂系统，彼此磨合和熟悉，像是执行一场空中加油任务。

不管外界如何评价和鞭策，这款产品本身，依然需要研发团队一个键一个键敲出来，从内核，到架构，到内测，到公测，再到一轮一轮的 debug，他们要在不到一年的时间里，走完微信14 年的路。

回顾鹅厂所做过的产品里，也许从未有过一款，被如此放在放大镜下凝视。每一次上架，每一个 bug，乃至于每一个里程碑，几乎都预定当天热搜。

站在正式版发布的1 月 9 日，或许这一切都可以风轻云淡地说：the show must go on。但这过去的 295 天里，他们的经历，我们认为值得记录下来，分享给关心微信鸿蒙版的用户朋友们。

技术交流：

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

- 开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）

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

2、2024年3月，集结

鹅厂指派了从塞班（Symbian）时期就负责微信开发工作的团队，来主导微信鸿蒙版。从塞班到智能手表、车机、Linux PC 端的微信，这个团队在内部素以擅长攻克不同环境、不同语言的开发工作著称。

同样很重要的一点是，得益于智能手表端微信的研发工作，微信和华为的两个团队是老相识，这也让双方的对接更加顺畅紧密起来。从三月贯穿到四月，两边通过拉通会、分享会学习鸿蒙系统研发框架，不定时组织技术专题讨论。

双方都很清楚，这不是一场三天两夜就能解决的小规模战斗，而是旷日持久的兵团级战役。兵马未动，粮草先行，敲下第一行代码之前，还有许许多多的工作需要准备。

3、2024年4月，基建

万丈高楼平地起，基建是最重要的第一步。

搞基建，“三通一平”（通电/通路/通水/土地平整）是基本要求，进取一些，可以做到“五通一平”（加入通讯/排污），再进一步，还有“七通一平”（加入通气/有线电视），乃至于“十通一平”（加入宽带/铁路/暖气）。通得越多，越有利于后期扩展和长远发展。

经过塞班、手机、手表等各种终端上的长期打磨，这个团队积累了一套名为Alita（阿丽塔）的跨平台内核。这也为鸿蒙版微信的基建打下了基础。这个阶段的重中之重是，快速熟悉鸿蒙系统，移植基础库，让 Alita 内核能够在鸿蒙系统上运行起来，和华为一边沟通、一边验证推进。

4、2024年5月，架构

接下来考验的是架构能力。开发团队需要设计好鸿蒙微信客户端的架构、编写好各模块文档，支撑各业务进场后能够高效开发。

这一步的难点，在于充分预判到业务之间的复杂解耦，既要降低各业务之间的依赖性，又要提高整体的稳定性，还要留出高可扩展性，属于典型的“我全都要”难题。

这就好比从零开始建设一座城市，要预估到这座百年之后超级都市的人口规模、交通状况、人居需求、产业结构、商业发展等因素，以及提前平衡这些因素之间的关系，需要具备极大的前瞻视角。

技术团队继续摇人，招聘也快马加鞭推进。TAPD（腾讯敏捷产品研发平台）流程图里，他们的首个目标是做出一个基础版本，保证用户能实现收发消息、语音通话等最基础、也是最重要的功能。

5、2024年6月，磨合

进入了真正的手搓环节。flutter（跨平台应用程序开发框架）、liteapp（专为移动端设计的跨平台开发框架）等，都是这个阶段的关键工作。

为了这桌“年夜饭”，技术小哥们一边在厨房切菜烧饭，一边去客厅招呼各方沏茶倒水，让支付和VoIP（语音通话技术）等基础能力陆续凑上一桌。

除了内外部密切的技术沟通，微信和华为团队对彼此的技术标准保持了互相尊重。以相册选图发送功能为例，在 Android 系统上，选图需要获取整个相册权限，也就是说应用可以访问用户的所有照片。在鸿蒙上的选图功能，为了保障用户隐私，微信采用的是 Picker 控件的方式，相册照片的展示和选择逻辑都由 Picker 控件提供，微信只能读取到用户勾选的照片。

6、第一个里程碑：bug 如约而至

赶在6月21日前，团队做好了第一个内部体验版本，包含收发消息、通话功能。和2011年1月21日发布的 iOS和安卓版的微信1.0版本相比，多了语音消息发送。

你可能会不以为然：大动干戈这么久，就整了个这毛坯房？

其实这里蕴含的开发思路，是验证最小可用的原则，本质上是对第一阶段研究鸿蒙语言和系统的成果验收。重要的是把基本功练好，才能为后续的开枝散叶打好底子。

但即便是如此普通的版本，也出了个闪退型 bug，最后查出来是系统的底层 API 问题：同样的代码逻辑，在 iOS 和安卓上能用，但在鸿蒙上行不通。两边团队为此绞尽脑汁，交了两个星期的学费，最后还是靠着某位技术小哥灵光一现想到的。

这个 bug也像是一场结业考试，经此一役，开发进入了快节奏。

微信集合了众多产品功能，各功能间又有复杂的交互和依赖关系，比如小程序的开发就涉及到与支付功能的打通，而支付能力又需要与基础会话功能打通。在完成基建的前提下，基础、支付、小程序……能进场的业务模块都陆续进了场。一个共同的目标是——10月8号鸿蒙公测那天，做出一个新版本。这个版本，将新增微信支付、朋友圈等功能。

7、2024年10月8日：喜欢您来

10月8日，微信鸿蒙原生版开启内测邀请，尝鲜版本包含基础社交通讯音视频通话、朋友圈、微信支付的二维码收/付款等功能。

内测开启，意味着微信和其他所有适配原生鸿蒙的第三方App一样，从内测到应用尝鲜再到公测，走上了鸿蒙系统第三方软件开发的三部曲。

为什么要限量内测而不是一口气开放下载呢？

在全新的平台上，要支撑海量用户、高并发通讯需求，同时涉及支付、小程序、视频等多个大功能模块，还要满足极高频使用下的稳定性，是很大的挑战。

所以，用内测 → 找bug → 修bug → 加大内测的方式，是一个更符合软件开发规律的方式。

经历了4天紧张的测试和debug，包括微信支付在内的多个功能经过严格测试流程后，合入大版本，10 月 12 日，微信鸿蒙原生版正式开始公测。

8、2024年10月～11 月：这都能遇到灰产啊啊啊

公测放量过程中，有一次实际登陆人数不到放量总数的十分之一？某平台上竟然有人公然售卖测试名额？

一系列插曲打破了原定的放量节奏，双方共同排查后发现，原来有人把安装包拿去二手平台牟利。应用商店完善机制后，把漏洞补上。

安装包都能拿来卖，也堪称是国产软件开发史上浓墨重彩的一笔。

微信鸿蒙版在尝鲜专区上线了2万测试名额，但后台显示，登录数据一直较低，我们和华为一同复盘发现，因为有人用脚本去抢名额，触发了应用商店的安全机制，同时扰乱了应用商店的计数逻辑，导致大概90% 的放量被拦截，最终实际下载的用户只有 10%左右。

又是浓墨重彩的一笔......

如何让用户尽可能体验到微信测试版本？

在基本保障尝鲜专区不断档的情况下，11 月 6 日，双方紧急协商，华为将微信鸿蒙版的测试名额大幅扩容，微信再次邀请扩容后的用户分批有序参与内测，共同完善新版本的各种体验。

在不断收集用户反馈、历经数次迭代后，目前的版本已经可以使用视频号、聊天引用、发文件等功能，所有鸿蒙用户也都可以直接下载，更多功能在持续上线。

9、2025年1月9日：不止是微信

吸收了广大用户的反馈和多轮debug后，鸿蒙版微信顺利结束公测，1月9日正式版本上线。你除了能稳定下载和使用微信外，还可以用到 QQ、腾讯视频、腾讯新闻、QQ 音乐等App。

自今年起，腾讯20多款产品通过敏捷开发，实现鸿蒙系统的适配工作，更多腾讯的产品适配也在路上。

一个发生在2024年10月29日的插曲，某种程度上，可以反映微信鸿蒙版开发团队的工作情形和协作流程：

19:20，项目组微信支付团队发现，即将要上架的最新尝鲜版的微信，小部分用户转账入口出现bug，点击后无反应。

20:15，客服团队同步后台客诉情况。

20:57，微信支付团队初步定位，有问题的代码是今日合入导致的，疑似是LiteApp（跨端的框架，微信转账是鸿蒙第一个使用这个框架的功能）的问题。

21:31，进一步定位问题，发现在一些极端情况下， LiteApp的文件缓存写入被系统提示权限不足，联系华为技术团队一起定位。

21:47，支付技术团队完成最新内测版微信的修复，合入后，提交版本给测试团队。

22:32，支付技术团队复盘问题，提出后续改进措施。

22:41，微信基础技术团队向华为应用商店提审新版本内测包。

22:54，向华为应用商店提审尝鲜版。

23:30，最新尝鲜版微信通过审核，上架尝鲜专区，转账问题修复。

微信公众平台曾有一句 slogan 深入人心：再小的个体，也有自己的品牌。同样的，再小的问题，放在微信上，都会被亿量级地扩大。

我们知道，永远等不来“完美交付”这一天。灰度测试、持续迭代，让产品在和用户的互动中得到改进，是腾讯一直以来的产品理念。

感谢微信用户、鸿蒙用户始终跟我们站在一起，7x24小时反馈bug、提出优化意见。如果把新产品开发比做一场足球赛，那希望你们一直都在，做我们敏捷开发“球队”的第12人。

10、微信的其它故事

《技术往事：微信估值已超5千亿，雷军曾有机会收编张小龙及其Foxmail》

《QQ和微信凶猛成长的背后：腾讯网络基础架构的这些年》

《2017微信数据报告：日活跃用户达9亿、日发消息380亿条》

《腾讯开发微信花了多少钱？技术难度真这么大？难在哪？》

《技术往事：“QQ群”和“微信红包”是怎么来的？》

《开发往事：深度讲述2010到2015，微信一路风雨的背后》

《开发往事：微信千年不变的那张闪屏图片的由来》

《开发往事：记录微信3.0版背后的故事（距微信1.0发布9个月时）》

《一个微信实习生自述：我眼中的微信开发团队》

《为什么说即时通讯社交APP创业就是一个坑？》

《微信七年回顾：历经多少质疑和差评，才配拥有今天的强大》

《前创始团队成员分享：盘点微信的前世今生——微信成功的必然和偶然》

《即时通讯创业必读：解密微信的产品定位、创新思维、设计法则等》

《QQ现状深度剖析：你还认为QQ已经被微信打败了吗？》

《[技术脑洞] 如果把14亿中国人拉到一个微信群里技术上能实现吗？》

《QQ和微信止步不前，意味着即时通讯社交应用创业的第2春已来？》

《那些年微信开发过的鸡肋功能，及其带给我们的思考》

《读懂微信：从1.0到7.0版本，一个主流IM社交工具的进化史》

《同为IM社交产品中的王者，QQ与微信到底有什么区别》

《社交应用教父级人物的张小龙和马化腾的同与不同》

《专访马化腾：首次开谈个人经历、管理心得、技术创新、微信的诞生等》

《一文读懂微信之父张小龙：失败天才、颠覆者、独裁者、人性操控师》

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

本文由转转王棕生分享，原题“IM系列(一)：转转IM系统架构探秘”，下文进行了排版和内容优化。

1、引言

转转是二手电商平台，在这个平台上，人人可以是买家，人人也可以是卖家。转转从最初的信息模式升级为一个闭环的交易模式，IM打通了买家与卖家之间的通道。本文描述了转转IM为整个平台提供的支撑能力，给出了系统的整体架构设计，分析了系统架构的特性。

2、系列文章

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

• 转转平台IM系统架构设计与实践(一)：整体架构设计（* 本文)
• 转转平台IM系统架构设计与实践(二)：详细设计与实现（稍后发布..）

3、本文作者

王棕生：转转架构平台部高级研发工程师，负责IM系统、推送系统和分布式存储系统。

4、系统能力定义

转转IM需要提供如下的支撑能力：

1）有的用户习惯使用APP、有的用户习惯免安装的小程序；还有的用户习惯于在“58同城”APP上搜索二手；所以IM需要支持APP、小程序、M端等各种终端类型，以及由转转平台衍生出的其他垂类APP。

2）IM是转转平台中的一个独立系统，需要向平台中的其他系统（如客服系统、风控系统）提供“联系人”和“私信”等IM能力。

3）在转转平台的各种运营活动中，需要借助于IM通道将商品消息、订单消息、交易消息及活动通知等实时的发送给用户。

总之：IM为转转平台提供一个可靠和稳定的通道，为用户与用户之间、业务系统与用户之间、平台与用户之间打造一个可以即时通讯的环境。

5、系统架构概览

转转IM系统架构设计如下图所示，自上而下包括四层：用户层、入口层、逻辑层和原子存储层。

转转IM系统架构设计图：

6、系统架构之“用户层”

用户层是IM服务的调用者，用户层支撑各类业务应用，包括APP、小程序、M端、平台运营类业务系统和ZZRPC。

APP基于TCP协议与IM服务端进行消息传输，小程序和M端则是通过HTTP协议。

ZZRPC是转转平台使用Java语言自研的RPC框架，而转转IM系统是使用C++语言进行研发的，所以IM需要通过适配支持ZZRPC服务的相互调用。

7、系统架构之“入口层”

入口层是IM系统的入口网关，包括：

• 1）Entry
• 2）Http-Entry
• 3）转转自研的分布式消息中间件ZZMQ；
• 4）IMUI。

Entry：负责维护与APP之间的TCP连接，把APP发送的业务请求包向后直接转发到逻辑层进行处理。Entry逻辑较为简单，不参与具体的业务处理，这样设计的原因是为了避免Entry因业务改造升级进行模块重启，而丢失与APP之间的TCP连接，影响大量用户。

Http-Entry：是HTTP版的Entry实现，Http-Entry负责维护的是与小程序和M端之间通过HTTP协议模拟的“长连接”。

HTTP“长连接”的实现原理是：小程序发送http_request到Http-Entry，Http-Entry会hold住连接不返回、不释放；当产生了该用户的私信数据时或hold住连接超过一定时间（如15秒）时，Http-Entry则返回http_response到小程序；小程序收到http_response时需要立即再次发送http_request到Http-Entry......。

ZZMQ：是转转自研的分布式消息队列，接收平台各个运营类业务系统生产的系统消息、广播消息和推送类消息，然后由IM逻辑模块进行消费处理。ZZMQ解耦了平台业务系统和IM系统。

IMUI：用于IM系统适配ZZRPC的调用；IMUI作为ZZRPC服务的提供者，接收ZZRPC客户端的请求后，按照IM系统的内部协议格式同步访问逻辑层，再将逻辑层的操作结果按ZZRPC协议进行封装，然后返回到ZZRPC的客户端。

8、系统架构之“逻辑层”

逻辑层包括Logic和Extlogic两个模块组件：

• 1）Logic负责实现IM系统核心的和轻量级的业务逻辑，如用户登录、获取未读数、发送私信等；
• 2）非核心的和重量级的业务由Extlogic进行实现；
• 3）Logic和Extlogic两个逻辑模块通过ZZMQ进行解耦。

例如：在私信逻辑处理流程中，Logic接收私信和用户在线时的私信推送，而对于离线私信Logic则会通过ZZMQ通知Extlogic进行离线消息的召回逻辑处理。

9、系统架构之“原子存储层”

IM需要持久化存储的数据包括私信消息、系统消息和联系人等。

这些数据通过传统的关系型数据库MySQL和NewSQL数据库TiDB进行保存：

• 1）TiDB是分布式数据库，具有天然的弹性扩容特性；
• 2）MySQL通过通用的分库分表策略来应对存储和查询负载。

Das接收逻辑层对持久化数据的读写请求，将请求放入本地队列中，然后按顺序对数据库进行同步读写操作。

ZZRedis是转转自研的分布式缓存系统，负责对用户的在线信息进行缓存。

Jtransit与IMUI类似，用于适配ZZRPC服务；Jtransit作为ZZRPC服务的调用，接收逻辑层的请求后，按照ZZRPC协议格式访问平台其他系统提供的服务，获取数据后封装成IM系统的协议数据返回到逻辑层。

10、架构特性1：伸缩性

对转转IM系统架构设计，从伸缩性、高可用、可靠性、可扩展性和高性能分别进行分析。

当转转并发访问的用户量不断增加，IM系统资源紧张时，需要通过增加机器进行水平弹性扩容，主要是通过服务管理平台控制中心进行实施的。入口层、逻辑层和原子层服务之间相互调用的关系如下表所示。

Entry和Http-Entry会作为调用方调用Logic的服务，Logic和Extlogic会作为调用方调用Das的服务和Entry与Http-Entry的服务，这些服务之间的关系通过控制中心进行管理。

首先：

• 1）服务方组件与控制中心建立TCP长连接，将服务内容包括本实例ip、端口、服务接口等等注册到控制中心；
• 2）调用方组件与控制中心建立TCP长连接，从控制中心轮询服务列表；
• 3）服务方组件增加机器弹性扩容时，新的实例会注册到控制中心，进而被调用方实时拉取到。

另外：

• 1）App通过域名连接Entry时会首先访问TGW，由TGW转发请求到Entry，所以增加Entry实例时需要在TGW进行注册；
• 2）小程序到Http-Entry的HTTP请求都是由Nginx进行中转，所以增加Http-Entry机器需要在Nginx上进行配置；
• 3）Extlogic作为ZZMQ的消费者，可以自由增加实例。

存储层扩容：

• 1）数据库MySQL通过分库和分表的方式进行扩容；
• 2）分布式数据库TiDB以及分布式缓存ZZRedis；
• 3）还有分布式消息队列ZZMQ自身具有天然的弹性伸缩特性。

11、架构特性2：高可用

1）入口层高可用：入口层Entry和Http-Entry的可用性分别由TGW和Nginx进行探活和迁移。

2）Logic高可用：Logic的可用性由入口层实例进行控制；为了保证同一用户消息的顺序性，Entry和Http-Entry会将同一个用户的请求通过哈希算法打到相同的Logic实例；若一索引号为x的Logic实例挂掉以后，Entry和Http-Entry会在重试后将请求打到索引号为(x+p)%n的Logic实例上（n为Logic实例数目，p的取值区间为[1,n) ）；注意p的取值不能固定，否则很容易将瞬时流量打到固定的Logic实例，引起雪崩效应。

3）Extlogic高可用：Extlogic负责消费消息队列ZZMQ中的消息，挂掉任意一个实例后，不影响业务的正常处理。

4）Das高可用：Das的高可用由Logic和Extlogic进行控制，原理与Logic高可用一致，在挂掉任意一个Das实例后，Logic和Extlogic会将请求打到索引号为(x+p)%n的Das实例上。

5）存储层高可用：MySQL通过一主两备模式保证其高可用，在主库挂掉以后，其中的一个备库变为主库继续对Das提供服务；分布式数据库TiDB、分布式缓存ZZRedis，分布式消息队列ZZMQ自身具有天然的高可用特性。

12、架构特性3：可靠性

程序的正确处理保证系统的可靠性，影响IM系统可靠性的因素主要是瞬时高峰导致的逻辑层Logic实例的系统资源被用光和原子层Das对数据库的访问超时。

1）Logic可靠性：逻辑层实例的系统资源被用光发生在业务的相互影响；例如瞬时大量用户登录IM系统时，Logic大部分或全部线程被调度用于处理用户登录业务，而没有足够的资源去处理私信等业务。提高Logic可靠性的方案，可以根据微服务思想对Logic按功能职责进行拆分，如拆分成Login_Logic、Msg_Logic、Contact_Logic等。

2）Das可靠性：对数据库的访问超时发生在数据库负载较高时，例如推送千万级广播系统消息时，会有大量的更新操作落到数据库上，此时数据库响应较慢或超时；因为Das对数据库的操作是同步的，所以会造成Das内部队列请求的堆积，其他业务请求也会被堆积而导致超时。提高Das可靠性的方案，可以根据业务类型在Das内部分别创建不同的请求队列，从而避免业务的相互影响。

13、架构特性4：可扩展性和高性能

1）可扩展性：转转IM系统架构的可扩展性体现在逻辑层，逻辑层Logic和Extlogic通过消息队列ZZMQ进行解耦，定制类的功能需求在Extlogic中进行实现，避免对核心业务Logic的影响。

ZZMQ除了解耦Logic和Extlogic外，还对平台的业务系统和IM系统进行解耦。

2）高性能：分析IM系统架构，入口层和逻辑层主要是计算模块，原子存储层主要是IO模块，系统的性能瓶颈集中在数据库端。提升性能方案有：通过增强机器配置、增加机器、研究和新的存储方式，如用户联系人可以通过KList引擎进行存储。

14、本文小结

转转IM为用户与用户之间、客服与用户之间、平台与用户之间打造了一个高效和可靠的通讯通道。

按微服务私信和分层模式对IM系统架构进行分布式设计，架构中每个组件模块的功能职责明确。

具体的功能职责如下：

• 1）Entry负责维护TCP连接；
• 2）Http-Entry负责维护HTTP连接；
• 3）Logic负责处理核心的轻量级业务，Logic要求服务稳定；
• 4）Extlogic负责处理非核心的重量级业务，Extlogic要求服务可扩展；
• 5）Das负责对数据库进行读写访问；
• 6）IMUI和Jtransit负责对平台的RPC框架ZZRPC进行适配；
• 7）MySQL、TiDB和ZZRedis负责持久化和缓存数据；
• 8）ZZMQ负责对平台的业务系统和IM系统，以及Logic和Extlogic之间进行解耦。

转转IM的系统架构具有伸缩性、高可用、可靠性、功能扩展性和高性能。

15、参考资料

[1] 浅谈IM系统的架构设计

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

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

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

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

[6] 蘑菇街即时通讯/IM服务器开发之架构选择

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

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

[9] 马蜂窝旅游网的IM系统架构演进之路

[10] 瓜子IM智能客服系统的数据架构设计（整理自现场演讲，有配套PPT）

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

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

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

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

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

[16] 一套十万级TPS的IM综合消息系统的架构实践与思考

[17] vivo直播系统中IM消息模块的架构实践

[18] 一套分布式IM即时通讯系统的技术选型和架构设计

[19] 微信团队分享：来看看微信十年前的IM消息收发架构，你做到了吗

[20] 携程技术分享：亿级流量的办公IM及开放平台技术实践

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

相关链接：

• ① MobileIMSDK-鸿蒙端的详细介绍
• ② MobileIMSDK-鸿蒙端的开发手册new（* 精编PDF版）

一、理论知识准备

您需要对鸿蒙Next和ArkTS开发有所了解：

• 1）HarmonyOS NEXT星河版零基础入门到实战（B站视频）
• 2）零基础快速上手HarmonyOS ArkTS开发（系列文章）
• 3）HarmonyOS 第一课（鸿蒙官方视频教程）

您需要对WebSocket技术有所了解：

• 1）新手快速入门：WebSocket 简明教程
• 2）WebSocket 详解（一）：初步认识 WebSocket 技术
• 3）WebSocket 从入门到精通，半小时就够！
• 4）从零理解 WebSocket 的通信原理、协议格式、安全性
• 5）WebSocket详解（二）：技术原理、代码演示和应用案例
• 6）WebSocket详解（三）：深入WebSocket通信协议细节
• 7）WebSocket详解（四）：刨根问底HTTP与WebSocket关系(上)
• 8）WebSocket详解（五）：刨根问底HTTP与WebSocket关系(下)
• 9）WebSocket详解（六）：刨根问底WebSocket与Socket的关系

HTML5的标准WebSocket协议文档、API手册：

• 1）WebSocket 的 API 手册
• 2）WebSocket 的标准文档

鸿蒙Next的WebSocket文档和手册：

• 1）鸿蒙Next的WebSocket官方文档

小提示：鸿蒙Next中的WebSocket API跟标准HTML5中的WebSocket接口及用法略有不同，但主要API都能一一对应，相差不大。

二、开发工具准备

1）DevEco-Studio：

（JackJiang 使用的版本号如上图所示，为了方便直接引用工程，建议你也使用此版或较新版本）

2）一站式下载地址：鸿蒙官网下载地址 点此进入。（需要注册成为开发者才能下载哟！）

3）DevEco-Studio效果预览：

三、SDK 文件用途说明

3.1文件概览

纯ArkTS实现，无任何第3方库依赖，更无本地原生代码混编：

MobileIMSDK-鸿蒙端SDK本身只是ets文件源码的集合，自带的Demo代码只是为了方便随时测试SDK代码，目的主要是用于演示SDK的API调用，Demo代码不属于SDK框架的一部分。

大致的目录说明：

3.2详细说明

SDK 各模块/文件作用说明：

四、主要API接口和用途说明

* 主要API文档地址是：http://docs.52im.net/extend/docs/api/mobileimsdk/harmony/

1）ClientCoreSDK.getInstance().loginHasInit：

• 用途：是否已经完成过首次登陆。
• 说明 ：用户一旦从自已的应用中完成登陆IM服务器后，本方法就会一直返回true（直到退出登陆IM）。
• 返回值：{boolean}，true表示已完成首次成功登陆（即已经成功登陆过IM服务端了，后面掉线时不影响此标识），否则表示尚未连接IM服务器。

2）ClientCoreSDK.getInstance().connectedToServer：

• 用途：是否在线。
• 说明 ：表示网络连接是否正常。
• 返回值：{boolean}，true表示网络连接正常，否则表示已掉线，本字段只在this._logined=true时有意义（如果都没有登陆到IM服务器，怎么存在在线或掉线的概念呢）。

3）ClientCoreSDK.getInstance().currentLoginInfo：

• 用途：保存登陆时提交的登陆信息（用户名、密码/token等）。
• 说明 ：格式形如：{loginUserId:'',loginToken:''}，此返回值的内容由调用登陆函数 loginImpl()时传入的内容决定。字段定义详见：http://docs.52im.net/extend/docs/api/mobileimsdk/harmony/#1697l。

4）ClientCoreSDK.getInstance().init(eventHub: common.EventHub): void：

• 用途：初始化SDK核心。
• 说明：不同于MobileIMSDK的iOS和Java客户端，本方法需要由开发者调用，以确保MobileIMSDK核心已被初始化完成。
• 本方法被调用后， #isInitialed() 将返回true，否则返回false。

5）ClientCoreSDK.getInstance().release(): void：

• 用途：保释放MobileIMSDK框架资源统一方法。
• 说明 ：本方法建议在退出登陆（或退出APP时）时调用。调用时将尝试关闭所有MobileIMSDK框架的后台守护线程并同设置核心框架init=false、loginHasInit=false、connectedToServer=false。

6）LocalDataSender.getInstance().sendLogin(loginInfo: PLoginInfo | undefined): number：

• 用途：发送登陆(连接)信息给服务端。
• 说明 ：不同于其它IM框架，本框架的登录和连接高度封装在了一个sendLogin方法中，无需单独再去connect服务器，大大简化了SDK的使用。loginInfo登陆信息各字段定义见：http://docs.52im.net/extend/docs/api/mobileimsdk/harmony/#1697。

7）LocalDataSender.getInstance().sendLoginout(): number：

• 用途：发送注销登陆信息。
• 说明：此方法的调用将被本库理解为退出库的使用，本方法将会额外调用资源释放方法 ClientCoreSDK#release() ，以保证资源释放。本方法调用后，除非再次进行登陆过程，否则核心库将处于初始未初始化状态。

8）LocalDataSender.getInstance().sendCommonDataPlain(dataContentWidthStr: string, to_user_id: string, QoS: boolean = true, fingerPrint: string = '', typeu: number = -1): number：

• 用途：向某人发送一条消息。
• 参数dataContentWidthStr：要发送的数据内容（字符串方式组织）。
• 参数to_user_id：要发送到的目标用户id。
• 参数QoS ：true表示需QoS机制支持，否则不需要。
• 参数fingerPrint：QoS机制中要用到的指纹码（即消息包唯一id），可设为null，生成方法见 Protocal.genFingerPrint()。
• 参数typeu：应用层专用字段——用于应用层存放聊天、推送等场景下的消息类型。注意：此值为-1时表示未定义。MobileIMSDK框架中，本字段为保留字段，不参与框架的核心算法，专留作应用层自行定义和使用。
• 返回值：0表示数据发出成功，否则返回的是错误码，see ErrorCode。

9）LocalDataSender.getInstance().sendCommonData(p: Protocal): number：

• 用途：通用数据协议包的发送根方法。
• 参数p：{Protocal} 要发送的消息协议包对象，Protocal详情请见“/module/mb_constants.js”下的createCommonData函数说明。
• 返回值：0表示数据发出成功，否则返回的是错误码，see ErrorCode。

10）SocketEvent.SOCKET_EVENT_ON_RECIEVE_MESSAGE事件通知：

• 用途：以便收到聊天消息时在UI上展现出来（事件通知于收到IM消息时）。
• 推荐用法 ：开发者可在此通知中处理收到的各种IM消息。
• 参数1： {Protocal}：详情请见Protocal类定义：http://docs.52im.net/extend/docs/api/mobileimsdk/harmony/#1350。

11）SocketEvent.SOCKET_EVENT_ON_LOGIN_RESPONSE事件通知：

• 用途：本地用户的登陆结果回调事件通知（此事件发生时表示客户端已登陆/连接或重连完成）。
• 推荐用法：开发者可在此事件中处理登录连接和掉线重连响应反馈。
• 参数1： {PLoginInfoResponse}：API文档详见：http://docs.52im.net/extend/docs/api/mobileimsdk/harmony/#1434。

12）SocketEvent.SOCKET_EVENT_ON_LINK_CLOSE事件通知：

• 用途：与服务端的通信断开的回调事件通知（此事件发生时表示客户端已掉线）。
• 该消息只有在客户端连接服务器成功之后网络异常中断之时触发。导致与与服务端的通信断开的原因有（但不限于）：无线网络信号不稳定、WiFi与2G/3G/4G/5G等同开情况下的网络切换、手机系统的省电策略等。
• 推荐用法 ：开发者可在此通知中处理掉线时的界面状态更新等，比如设置将界面上的“在线”文字更新成“离线”。

13）SocketEvent.SOCKET_EVENT_PING事件通知：

• 用途：本地发出心跳包后的回调通知（本回调并非MobileIMSDK-鸿蒙端核心逻辑，开发者可以不需要实现！）。
• 推荐用法 ：开发者可在此回调中处理底层网络的活动情况。

14）SocketEvent.SOCKET_EVENT_PONG事件通知：

• 用途：收到服务端的心跳包反馈的回调通知（本回调并非MobileIMSDK-鸿蒙端核心逻辑，开发者可以不需要实现！）。
• 推荐用法 ：开发者可在此回调中处理底层网络的活动情况。

15）SocketEvent.SOCKET_EVENT_KICKOUT事件通知：

• 用途：收到服务端反馈的错误信息指令（本回调并非MobileIMSDK-鸿蒙端核心逻辑，开发者可以不需要实现！）。
• 参数1：{PKickoutInfo}：非空，详见：http://docs.52im.net/extend/docs/api/mobileimsdk/harmony/#1428。

16）SocketEvent.SOCKET_EVENT_ON_ERROR_RESPONSE事件通知：

• 用途：收到服务端反馈的错误信息指令（本回调并非MobileIMSDK-鸿蒙端核心逻辑，开发者可以不需要实现！）。
• 参数1：{PErrorResponse}：非空，详见：http://docs.52im.net/extend/docs/api/mobileimsdk/harmony/#1430。

17）SocketEvent.SOCKET_EVENT_RECONNECT_ATTEMPT事件通知：

• 用途：“自动重连尝试中”事件（本回调并非MobileIMSDK-鸿蒙端核心逻辑，开发者可以不需要实现！）。
• 参数 code ：{numeric}：0：已停止，1：持续运行中，2：单次脉搏

18）SocketEvent.SOCKET_EVENT_MESSAGE_LOST事件通知：

• 用途：消息未送达的回调事件通知。
• 发生场景：比如用户刚发完消息但网络已经断掉了的情况下，表现形式如：就像手机qq或微信一样消息气泡边上会出现红色图标以示没有发送成功）。
• 建议用途：应用层可通过回调中的指纹特征码找到原消息并可以UI上将其标记为“发送失败”以便即时告之用户。
• 参数1：{Array}：由框架的QoS算法判定出来的未送达消息列表。

19）SocketEvent.SOCKET_EVENT_MESSAGE_BE_RECIEVED事件通知：

• 用途：消息已被对方收到的回调事件通知。
• 说明 ：目前，判定消息被对方收到是有两种可能：1) 对方确实是在线并且实时收到了；2) 对方不在线或者服务端转发过程中出错了，由服务端进行离线存储成功后的反馈（此种情况严格来讲不能算是“已被收到”，但对于应用层来说，离线存储了的消息原则上就是已送达了的消息：因为用户下次登陆时肯定能通过HTTP协议取到）。
• 建议用途：应用层可通过回调中的指纹特征码找到原消息并可以UI上将其标记为“发送成功”以便即时告之用户。
• 参数1：{String}：已被收到的消息的指纹特征码（唯一ID），应用层可据此ID找到原先已发的消息并可在UI是将其标记为”已送达“或”已读“以便提升用户体验。

五、如何引入SDK库文件

5.1方法一：源码形式

第一步：先将整个sdk源码module复制到您的鸿蒙工程中：

第二步：配置您的工程，确保正确引用了MobileIMSDK鸿蒙SDK的源码module：

5.2方法二：.har包形式

第一步：先将MobileIMSDK鸿蒙端SDK的.har包放入您的鸿蒙Next主module中（比如新建的libs目录下）：

第二步：配置您的工程，确保正确引用了MobileIMSDK鸿蒙SDK的.har包：

六、如何调用SDK代码

6.1第一步：设置ws/wss连接URL

设置您自已部署的MobileIMSDK服务端IP或域名的（示例详见Demo中的 IMClientManager.ets 文件）：

提示：MobileIMSDK的服务端Demo部署指南请见 http://www.52im.net/thread-63-1-1.html。

6.2第二步：初始化SDK

调用ClientCoreSDK中的init()方法进行初始化（示例详见Demo中的I MClientManager.ets 文件）：

6.3第三步：注册框架事件

注册MobileIMSDK框架级的事件监听（示例详见Demo中的 IMClientManager.ets 文件）：

6.4第四步：调用登录方法（框架内部会自动启动connect全过程）

调用登录方法（示例详见Demo中的 LoginPage.ets 文件）：

提示：不同于其它IM框架，本框架的登录和连接高度封装在了一个sendLogin方法中，无需单独再去connect服务器，大大简化了SDK的使用。

七、Demo运行效果和功能说明

八、Demo运行方法

8.1重要说明

特别说明：MobileIMSDK的鸿蒙端工程（包括Demo代码），不依赖任何第3方库，也不存在任何Native代码混编，完全使用ArkTS、ArkUI官方标准API实现，所以你在拿到MobileIMSDK的鸿蒙端工程后直接开箱即可运行，切莫搞复杂、不要私自加戏！

8.2配置要连接的MobileIMSDK服务器IP

注意：下图中登陆连接的IP地址请设置为您自已的MobileIMSDK服务器地址哦。

友情提示： MobileIMSDK的服务端该怎么部署就不是本手册要讨论的内容了，你可以参见《即时通讯框架MobileIMSDK的Demo使用帮助：Server端》。

▲ 配置要连接的服务器IP（以上代码详见IMClientManager.ets文件）

8.3启动模拟器

注意：如果没有新建模拟器可以自已新建一个。另外也可以使用支持鸿蒙Next的真机，打开“开发者模式”并插入USB线即可使用。

▲ 点击绿色箭头，立即启动模拟器！

8.4一键运行

如下图所示，点击绿色“运行”按钮后，将自动在模拟器或真机里显示自带的Demo界面了：

8.5运行效果

1）Demo的登陆界面运行截图：

2）Demo的主界面运行截图：

3）Demo运行的同时，可以查看详细的log输出（方便调试）：

九、引用资料

[1] 鸿蒙Next官方开发资料

[2] MobileIMSDK开源框架的API文档

[3] MobileIMSDK开源IM框架源码（Github地址点此）

[4] MobileIMSDK-鸿蒙Next端发布公告

[5] MobileIMSDK-鸿蒙Next端详细介绍

[6] MobileIMSDK-鸿蒙Next端开发手册（* 精编PDF版）

[7] MobileIMSDK的Server端Demo使用帮助

一、基本介绍

MobileIMSDK-鸿蒙端是一套基于鸿蒙Next（纯血鸿蒙）系统的IM即时通讯客户端库：

• 1）超轻量级（编译后库文件仅50KB）、无任何第3方库依赖（开箱即用）；
• 2）纯ArkTS编写、无Native代码、高度提炼、简单易用；
• 3）基于鸿蒙Next标准WebSocket  API，简洁优雅；
• 4）可运行于任何支持鸿蒙Next的平台；
• 5）能与 MobileIMSDK的各种客户端完美互通；
• 6）可应用于鸿蒙Next中的消息推送、客服聊天、企业OA、IM等场景。

二、与MobileIMSDK的关系

MobileIMSDK-鸿蒙端是基于鸿蒙Next标准WebSocketAPI的 MobileIMSDK配套客户端库。

以下是MobileIMSDK的最新通信架构图：

MobileIMSDK是一套专为移动端开发的原创开源IM通信层框架：

• 1）历经10年、久经考验；
• 2）超轻量级、高度提炼，lib包50KB以内；
• 3）精心封装，一套API同时支持UDP、TCP、WebSocket三种协议（可能是全网唯一开源的）；
• 4）客户端支持iOS、Android、标准Java、H5(暂未开源)、微信小程序(暂未开源)、Uniapp(暂未开源)、鸿蒙Next(Demo工程源码)new；
• 5）服务端基于Netty，性能卓越、易于扩展；
• 6）可与姊妹工程 MobileIMSDK-Web 无缝互通实现网页端聊天或推送等；
• 7）可应用于跨设备、跨网络的聊天APP、企业OA、消息推送等各种场景。

PS：MobileIMSDK一直在持续开发和升级中，本鸿蒙客户端是MobileIMSDK工程的最新成果。

三、设计目标

直接使用鸿蒙Next的WebSocket API开撸，有以下问题和劣势：

• 1）功能有限：没有心跳保活、断线重连、消息送达保证（重传和去重）等即时通讯关键算法和逻辑；
• 2）API 简陋：在如此有限的API接口下，能逻辑清晰且健壮地实现并组合心跳保活、断线重连、消息送达保证等算法，需要相当高的技术掌控力；
• 3）逻辑耦合：经验欠缺的开发人员，会将WebSocket通信逻辑与前端ArkUI界面代码混在一起，使得UI界面的编写、维护、改版都非常困难。

针对以上问题，而MobileIMSDK-鸿蒙端库将让开发者专注于UI应用层的开发，网络通信层的专业代码交由SDK开发人员，从而解偶UI前端和通信层的逻辑耦合性，大大降低技术复杂度和应用门槛。

MobileIMSDK-鸿蒙端库的设计目标是为您的开发带来以下便利：

• 1）界面与通信解偶：UI界面与网络通信层代码解耦，UI界面的重构、维护、改版都非常容易和优雅；
• 2）轻量级和兼容性：受益于坚持使用鸿蒙Next的标准WebSocket API，简洁轻量，无需任何额外库依赖；
• 3）核心内聚和收敛：得益于长期的提炼和经验积累，SDK核心层高度封装，开发者无需理解复杂算法即可简单上手。
• 4）纯 ArkTS 实现：纯ArkTS编写，无重量级框架和库依赖（更无Native代码），可干净利落地对接各种既有系统；
• 5）跨平台运行能力：受益于鸿蒙系统的跨端特性，理论上本SDK可运行于任何支持鸿蒙Next的平台上。

四、技术亮点

• 1）超级轻量纯净：超轻量级——纯ArkTS编写且无任何第3方库依赖，编译后库文件仅50KB；
• 2）高内聚易使用：高度提炼——简单易用，所有核心类皆设计为单例——到手即用、高度容错；
• 3）跨端支持好：基于鸿蒙Next的标准WebSocket API（无Native代码依赖），理论上可很好地运行于任何支持最新鸿蒙的平台上；
• 4）断网恢复能力：拥有网络状况自动检测、断网自动治愈的能力；
• 5）送达保证机制：完善的QoS消息送达保证机制（自动重传、消息去重、状态反馈等），不漏过每一条消息；
• 6）通信协议封装：实现了一个对上层透明的即时通讯通信协议模型；
• 7）身份认证机制：实现了简单合理的身份认证机制；
• 8）完善的log信息：在开发调试阶段，确保每一个算法关键步骤都有日志输出，让您的运行调试更为便利；
• 9）界面代码解耦：实现了UI界面代码与SDK网络通信代码解偶，防止界面代码跟IM核心代码混在一起，不利于持续升级、重用和维护；
• 10）多端协议兼容：实现了与MobileIMSDK各种客户端完全兼容的协议模型。

五、文件组成

完整工程文件概览：

 

SDK代码文件用途说明：

精编注释级的源码：

六、Demo功能说明

（点击可看大图 ▲）

七、实际运行效果

1）Demo 的登陆界面运行截图（点击可看大图 ▼）：

2）Demo 的主界面运行截图（点击可看大图 ▼）：

3）Demo 运行的同时，可以查看详细的 log 输出（方便调试）：

八、详尽开发者手册

① 开发者手册（网页版）：点此进入 ◀

② 开发者手册（PDF精编版）：点此进入 ◀（* 推荐）

九、相关资料

[1] 鸿蒙Next官方开发资料

[2] MobileIMSDK开源框架的API文档

[3] MobileIMSDK开源IM框架源码（Github地址点此）

[4] MobileIMSDK-鸿蒙Next端发布公告

[5] MobileIMSDK-鸿蒙Next端开发手册（* 推荐）

本文由转转QA刘宝成分享，原题“抓包工具wireshark的使用”，下文进行了排版和内容优化。

1、引言

跟网络通信有关的应用场景下（比如Web系统、IM聊天应用、消息推送系统等），经常要用到网络抓包工具，用以验证客户端和服务器之间收发的数据包是否正确。以IM聊天系统为例，TLS/SSL加密开启到底有没有成功？加密效果怎么样？端到端加密后的聊天内容安全强度够不够？等等这些疑问，都需要通过网络抓包抓出样本来分析和验证。

Wireshark是一款开源和跨平台的抓包工具。它通过调用操作系统底层的API，直接捕获网卡上的数据包，因此捕获的数据包详细、功能强大。但Wireshark本身稍显复杂，本文将以用抓包实例，手把手带你一步步用好Wireshark，并真正理解抓到的数据包的各项含义。

2、系列文章

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

网络编程懒人入门(十五)：外行也能读懂的网络硬件设备功能原理速成

网络编程懒人入门(十六)：手把手教你使用网络编程抓包神器Wireshark（* 本文)

3、Wireshak的安装和基本使用

安装：直接通过官方下载对应的安装包即可 https://www.wireshark.org/download.html。

使用：

如上图所示：

• 1）左上角为几个最常用的按钮：开始捕获、停止捕获、重新捕获、捕获选项；
• 2）中间为捕获过滤器，用于过滤需要捕获的数据包；
• 3）捕获过滤器下面可以选择需要捕获的网络连接。

下图是用Wireshark捕获的数据包：

可以看到，数据包结构是与OSI的七层模型相对应的，会详细显示每层的信息。

更多Wireshak的基本用法和手册，可以详读以下两篇：

1. 理论联系实际：Wireshark抓包分析TCP 3次握手、4次挥手过程
2. 网络通讯数据抓包和分析工具 Wireshark 使用教程(中文) [附件下载]

4、快速理解Wireshak的过滤器

由于Wireshark直接捕获底层网络数据包，导致其捕获的数据包数量通常较大。为了便于筛选数据包，Wireshark提供了两种过滤器。

4.1捕获过滤器

用于设置什么样的数据包保存在捕获结果中，避免产生过大的日志文件。

需要在开始捕获之前设置，相对简单：

捕获过滤器语法如上，一般用于过滤协议、IP、端口等基本信息。

例如：

• 1）显示目的TCP端口为8080的包：tcp dst port 8080
• 2）显示来源IP地址为192.168.171.201的封包：ip src host 192.168.171.201

4.2显示过滤器

用于在捕获日志中查找数据包，可以在捕获过程中或者捕获后随时更改。

功能更加强大和复杂：

显示过滤器语法如上，比捕获过滤器更为强大，可以针对不同协议，过滤不同的字段。

例如：

• 1）源地址是192.168.171.0网段的数据包：ip.src == 192.168.171.0/24
• 2）所有的HTTP POST请求：http.request.method== "POST"
• 3）显示包含TCP SYN标志的包：tcp.flags.syn == 0×02
• 4）URL中包含baidu的http请求：http.request.uri contains "baidu"

5、用什么例子来动手学习Wireshak？

本来想借用RainbowChat 这种IM聊天中的TLS/SSL数据包来的分析来实战Wireshak，但考虑到IM通常都是私有协议，不利于理解。

因而接下来的内容将以HTTPS为例，来详细讲解如何借助Wireshak抓出的数据包（正好也顺验证之前那么多跟TLS/SSL加密有关的文章），详细理解和学习Wireshak的使用，同进加深对HTTPS协议本身的理解。

6、什么是HTTPS

SSL/TLS：SSL (Secure Sockets Layer)，最初由Netscape公司设计，后来逐渐演变为TLS(Transport Layer Security Protocol)，即“传输层安全协议”。

该协议工作在TCP层之上，应用层之下。在TCP连接完成后，进行通信双方的身份认证，并协商一些跟加密相关的工作。完成协商之后，就可以对双方发送的信息进行加密/解密了。

HTTPS：可以理解为HTTP over SSL/TLS。即在SSL/TLS协议之上运行HTTP协议，以保证通信的安全性。

更多深入的学习，可以从下面这几篇精选的资料开始：

1. 如果这样来理解HTTPS原理，一篇就够了
2. 你知道，HTTPS用的是对称加密还是非对称加密？
3. 为什么要用HTTPS？深入浅出，探密短连接的安全性
4. 一分钟理解 HTTPS 到底解决了什么问题
5. 一篇读懂HTTPS：加密原理、安全逻辑、数字证书等

7、HTTPS的SSL/TLS握手过程

SSL/TLS的握手过程主要需要解决两个问题：

• 1）证明通信双方身份的真实性；
• 2）协商后续通信过程中使用的密钥；

如下图所示：左侧是一个简单的握手流程，右侧为对应的抓包结果，我们可以对比分析一下SSL/TLS的握手过程。

1）C：ClientHello

客户端发送协议版本号、sessionid、随机数、加密算法列表、扩展字段等信息：

2）S：ServerHello

与客户端类似，不同之处在于确定了所使用的加密算法等：

3）S：Certificate

服务端向客户端发送自己的CA证书。客户端通过证书信任链查看该证书的真实性，以验证服务端的身份。其实SSL/TLS协议还支持客户端的CA证书验证，不过在实际中使用较少。

4）S：ServerKey Exchange

服务端根据之前选择的加密算法，传输密钥协商需要的参数。从之前的报文可以看到，这里选择的是EC-DH算法。

5）S：ServerHello Done

该报文表示服务端发送完成。

6）C：ClientKey Exchange

同理，客户端也要根据之前选择的加密算法，传输相应的参数。

7）C：ChangeCipher Spec

经过上述步骤，客户端和服务器双方已经完成了身份认证，并且交换了生成密钥的全部参数。双方会根据对应的算法，各自生成加密密钥，然后就可以进行加密通信了。这个报文表示切换到密文模式，后续消息都通过加密传输。

8）C：Finished

客户端表示握手完成。这里会发送一段Verify Data，是使用新生成的密钥加密后的一段信息。双方通过该信息验证加密算法、密钥是否有效。

9）S：Change Cipher Spec

10）S：Finished

服务段也会发送对应的两条消息作为回应，不再赘述。

8、解密HTTPS报文

握手完成之后，就可以查看客户端发出的HTTP请求了。但我们看到的只是一段加密后的字符串？那么如何对HTTPS报文进行解密呢？

要想解密HTTPS报文，就必须要获取到加密密钥。Chrome、Firefox等浏览器支持将访问网站时使用的密钥输出到文件中。仅需要配置环境变量SSLKEYLOGFILE 即可。

如下：

然后需要将该密钥文件导入到Wireshark中。打开编辑-首选项，选择Protocol-SSL，填写刚才设置的文件路径。

现在，就可以通过Wireshark查看HTTPS请求中的具体信息了！

9、参考资料

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

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

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

[4] 网络通讯数据抓包和分析工具 Wireshark 使用教程(中文) [附件下载]

[5] 如果这样来理解HTTPS原理，一篇就够了

[6] 你知道，HTTPS用的是对称加密还是非对称加密？

[7] 为什么要用HTTPS？深入浅出，探密短连接的安全性

[8] 一分钟理解 HTTPS 到底解决了什么问题

[9] 一篇读懂HTTPS：加密原理、安全逻辑、数字证书等

[10] IM聊天系统安全手段之通信连接层加密技术

[11] IM聊天系统安全手段之传输内容端到端加密技术

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

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

[14] 手把手教你为基于Netty的IM生成自签名SSL/TLS证书

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

为了更好地分类阅读 52im.net 总计1000多篇精编文章，我将在每周三推送新的一期技术文集，本次是第44 期。

[-1-]  微信朋友圈千亿访问量背后的技术挑战和实践总结

[链接] http://www.52im.net/thread-1569-1-1.html

[摘要] 朋友圈的数据是永远存储的，而且随着业务的快速发展，存储容量、带宽和设备的消耗大量增加，尤其重大节日带来的使用量增长，更加剧了消耗，也给运维人员的保障带来了巨大压力。

[-2-] 腾讯技术分享：腾讯是如何大幅降低带宽和网络流量的(图片压缩篇)

[链接] http://www.52im.net/thread-1559-1-1.html

[摘要] 本次文章跟大家分享如何在保障质量（指的是图片质量、音视频质量）前提下所做的带宽和网络流量压缩，进而达到运营成本的优化。

[-3-] 腾讯技术分享：腾讯是如何大幅降低带宽和网络流量的(音视频技术篇)

[链接] http://www.52im.net/thread-1560-1-1.html

[摘要] 本文接上篇《腾讯技术分享：腾讯是如何大幅降低带宽和网络流量的(图片压缩篇)》，继续腾讯公司分享如何在保障质量（指的是图片质量、音视频质量）前提下所做的带宽和网络流量压缩，进而达到运营成本的优化。

[-4-] IM全文检索技术专题(二)：微信移动端的全文检索多音字问题解决方案

[链接] http://www.52im.net/thread-1545-1-1.html

[摘要] 本文重点讲述微信安卓客户端在SQLite FTS5的基础上，多音字问题的解决方案。

[-5-] 腾讯技术分享：Android版手机QQ的缓存监控与优化实践

[链接] http://www.52im.net/thread-1524-1-1.html

[摘要] 对于Android应用来说，内存向来是比较重要的性能指标。内存占用过高，会影响应用的流畅度，甚至引发OOM，非常影响用户体验。因此，内存优化也向来是行业内的重点工作项和难点工作项。

[-6 -] 微信团队分享：iOS版微信的高性能通用key-value组件技术实践

[链接] http://www.52im.net/thread-1461-1-1.html

[摘要] 本文要分享的是iOS版微信内部正在推广和使用的一个高性能通用key-value 组件的技术实践过程，该组件在微信内部被命名为MMKV（以下简称MMKV）。

[-7-] 微信团队分享：iOS版微信是如何防止特殊字符导致的炸群、APP崩溃的？

[链接] http://www.52im.net/thread-1449-1-1.html

[摘要] 一般来说，特殊字符闪退是系统漏洞引起，只要更新系统就行。但大部分用户不愿意更新系统，而苹果也不一定第一时间解决问题。另外后台可以拦截恶意文本传递，但对于本地已下发的消息，后台没有办法让它删除。所以客户端还是要做些保护预防特殊字符闪退。

[-8-] 腾讯技术分享：Android手Q的线程死锁监控系统技术实践

[链接] http://www.52im.net/thread-1442-1-1.html

[摘要] 本文将详细介绍Android版手Q中这套线程卡死监控系统设计思路以及技术实践总结。

[-9 -]  微信团队原创分享：iOS版微信的内存监控系统技术实践

[链接] http://www.52im.net/thread-1422-1-1.html

[摘要] 二期版本以Instruments的Allocations为参考，着重四个方面优化，分别是数据收集、存储、上报及展现。

[-10-] 让互联网更快：新一代QUIC协议在腾讯的技术实践分享

[链接] http://www.52im.net/thread-1407-1-1.html

[摘要] 本文主要介绍 QUIC 协议在腾讯内部及腾讯云上的实践和性能优化，新一代的互联网协议需要大家一起努力推动，你准备好了吗？

[-11 -] iOS后台唤醒实战：微信收款到账语音提醒技术总结

[链接] http://www.52im.net/thread-1404-1-1.html

[摘要] 本文借此总结了iOS平台上的APP后台唤醒和语音合成、播放等一系列技术开发过程中遇到的坑和小技巧，希望与您分享。

[-12 -] 腾讯技术分享：社交网络图片的带宽压缩技术演进之路

[链接] http://www.52im.net/thread-1391-1-1.html

[摘要] 为了进一步降低运营带宽成本，减小用户访问流量及提升页面加载速度，社交网络 CDN运维紧跟行业图片优化趋势，创新引入WebP、SharpP、自适应分辨率、Guetzli等图像压缩技术到现网，经过三年多的多部门联合攻关，已逐渐形成一套覆盖全图片类型（JPEG、JPG、PNG、WebP、GIF）多场景的图片压缩运营体系，适用于各类型终端，每年节约外网带宽几百G。

[-13 -] 微信团队分享：视频图像的超分辨率技术原理和应用场景

[链接] http://www.52im.net/thread-1377-1-1.html

[摘要] 本文试着讲述超分辨率技术的正确打开方式，浅谈视频图像的超分辨率技术的基本概念和应用场景等问题。

[-14 -] 微信团队分享：微信每日亿次实时音视频聊天背后的技术解密

[链接] http://www.52im.net/thread-1311-1-1.html

[摘要] 本文将为大家介绍微信实时音视频聊天在不同发展阶段的各个关键视频技术环节采用的方案，同时分享在实时音视频聊天中的视频编码器研发的方法和经验。

👉52im社区本周新文：《Web端IM聊天消息该不该用浏览器本地存储？一文即懂！》，欢迎阅读！👈

我是Jack Jiang，我为自已带盐！https://github.com/JackJiang2011/MobileIMSDK/

为了更好地分类阅读 52im.net 总计1000多篇精编文章，我将在每周三推送新的一期技术文集，本次是第 43 期。

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

[链接] http://www.52im.net/thread-1236-1-1.html

[摘要] 直播弹幕指直播间的用户，礼物，评论，点赞等消息，是直播间交互的重要手段。美拍直播弹幕系统从 2015 年 11 月到现在，经过了三个阶段的演进，目前能支撑百万用户同时在线。比较好地诠释了根据项目的发展阶段进行平衡演进的过程。这三个阶段分别是快速上线、高可用保障体系建设、长连接演进。具体我将在正文中展开，请继续往下阅读。

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

[链接] http://www.52im.net/thread-3252-1-1.html

[摘要] 本文来自淘宝消息业务团队的技术实践分享，分析了电商IM消息平台在非传统IM应用场景下的高发并、强互动群聊和直播业务中的技术特点，总结并分享了在这些场景下实现大量多对多实时消息分发投递的一些架构方面的设计实践。

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

[链接] http://www.52im.net/thread-3376-1-1.html

[摘要] 本文将回顾微信直播聊天室单房间海量用户同时在线的消息组件技术设计和架构演进，希望能为你的直播聊天互动中的实时聊天消息架构设计带来启发。

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

[链接] http://www.52im.net/thread-3515-1-1.html

[摘要] 本文主要分享的是百度直播的消息系统的架构设计实践和演进过程。

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

[链接] http://www.52im.net/thread-3594-1-1.html

[摘要] 微信小游戏出于性能和安全等一系列考虑，运行在一个独立的进程中，在该环境中不会初始化视频号直播相关的模块。这就意味着小游戏的音视频数据必须跨进程传输到主进程进行推流，给我们实现小游戏直播带来了一系列挑战。

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

[链接] http://www.52im.net/thread-3799-1-1.html

[摘要] 本文将基于融云在直播技术实践的背景，分享了单直播间百万用户在线量的实时消息分发的技术经验总结，希望带给你启发。

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

[链接] http://www.52im.net/thread-3835-1-1.html

[摘要] 本文将主要从高可用、弹性扩缩容、用户管理、消息分发、客户端优化等角度，分享直播间海量聊天消息的架构设计技术难点的实践经验。

[-8-] 视频直播技术干货(十一)：超低延时视频直播技术的演进之路

[链接] http://www.52im.net/thread-4587-1-1.html

[摘要] 本文将带您了解超低延时视频直播技术的优化和演进历程。

[-9 -]  视频直播技术干货(十二)：从入门到放弃，快速学习Android端直播技术

[链接] http://www.52im.net/thread-4714-1-1.html

[摘要] 本文详细介绍了Android端直播技术的全貌，涵盖了从实时音视频采集、编码、传输到解码与播放的各个环节。文章还探讨了直播中音视频同步、编解码器选择、传输协议以及直播延迟优化等关键问题。希望本文能为你提供有关Andriod端直播技术的深入理解和实践指导。

[-10-] 海量实时消息的视频直播系统架构演进之路(视频+PPT)[附件下载]

[链接] http://www.52im.net/thread-1562-1-1.html

[摘要] 本次主要分享的是融云视频直播互动平台的实时消息可靠性的设计方案,支撑无上限消息并发的架构演进,单机吞吐性能的优化历程。

[-11 -] YY直播在移动弱网环境下的深度优化实践分享(视频+PPT)[附件下载]

[链接] http://www.52im.net/thread-1379-1-1.html

[摘要] 本次分享介绍了 YY 直播针对质量较差网络（简称弱网）的环境，基于数据分析，在客户端和云端所采取的一系列技术手段。 同时，就如何改善上下行网络环境，也给出自己的一些解决方案。

[-12 -] 从0到1：万人在线的实时音视频直播技术实践分享(视频+PPT) [附件下载]

[链接] http://www.52im.net/thread-213-1-1.html

[摘要] 本次分享由“跟谁学”CTO带来，介绍跟谁学的团队是怎样在很短的时间内，构建了一个支持万人实时音视频直播的在线教室。

[-13 -] 在线音视频直播室服务端架构最佳实践(视频+PPT) [附件下载]

[链接] http://www.52im.net/thread-196-1-1.html

[摘要] 本期演讲嘉宾将为大家带来金山视频云在社交直播场景的支撑技术架构和优化方案。

👉52im社区本周新文：《Wasm在即时通讯IM场景下的Web端应用性能提升初探》，欢迎阅读！👈

我是Jack Jiang，我为自已带盐！https://github.com/JackJiang2011/MobileIMSDK/

为了更好地分类阅读 52im.net 总计1000多篇精编文章，我将在每周三推送新的一期技术文集，本次是第42 期。

[-1-] 实时音频的混音在视频直播中的技术原理和实践总结

[链接] http://www.52im.net/thread-1904-1-1.html

[摘要] 今天，我们就来聊一聊混音技术在视频直播应用中的实现原理、方案等，及其在创新玩法中的实践应用。

[-2-] 七牛云技术分享：使用QUIC协议实现实时视频直播0卡顿！

[链接] http://www.52im.net/thread-1406-1-1.html

[摘要] 不做任何开发，就能实现弱网环境下实现实时视频直播零卡顿，听上去是不是天方夜谭？看完这篇文章你就知道，我们是如何做到的。

[-3-] 近期大热的实时直播答题系统的实现思路与技术难点分享

[链接] http://www.52im.net/thread-1369-1-1.html

[摘要] 我们首先分析一下直播答题和传统直播在技术上的不同，然后深度解释一下直播答题解决方案的海量并发派题和收题。

[-4-] P2P技术如何将实时视频直播带宽降低75%？

[链接] http://www.52im.net/thread-1289-1-1.html

[摘要] 那整个系统是怎么设计的？使用了哪些技术来达成目标？接下来我来重点分享一下架构设计和技术细节。

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

[链接] http://www.52im.net/thread-1254-1-1.html

[摘要] 网易云信的实时视频直播目前使用了TCP进行传输，且基于此，从编码动态适配、发送队列调整、协议优化、socket等做了全流程的优化，确保在限带宽、丢包、时延、抖动，无论单项还是复杂网络，都有非常不错的实际体验。

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

[链接] http://www.52im.net/thread-1033-1-1.html

[摘要] 快手拥有5亿注册用户，单个直播间人数峰值已经超过180万，他们针对海量用户，基于大数据技术，在首屏和流畅度优化上做了大量的探索与实践。快手直播是如何设计全链路质量监控方案、如何搭建大数据处理Pipeline 、如何解决开播跳帧、首屏卡顿优化等问题的？本文干货满满，全面解密快手直播大数据技术架构与优化实践。

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

[链接] http://www.52im.net/thread-953-1-1.html

[摘要] 这两年互联网领域的一个热门关键词就是实时音视频直播，从刚开始的游戏直播和秀场娱乐开始，实时音视频直播带来了远超传统互动的用户体验，现在实时音视频直播已逐渐深入当今主流的互联网应用形态里。我们将逐一分析和总结实时音视频直播中的这几个重要技术指标。

[-8-] 技术揭秘：支持百万级粉丝互动的Facebook实时视频直播

[链接] http://www.52im.net/thread-541-1-1.html

[摘要] 在这篇文章中，我们将粗略地看一下我们在每次发布时解决的问题，我还将向你解释我们为负载均衡和 RTMP 实现问题所选择的解决方案。

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

[链接] http://www.52im.net/thread-530-1-1.html

[摘要] 本次分享将为大家揭开移动端实时音视频直播核心技术的神秘面纱。

[-10-] 实现延迟低于500毫秒的1080P实时音视频直播的实践分享

[链接] http://www.52im.net/thread-528-1-1.html

[摘要] 实时视频直播是很多技术团队及架构师关注的问题，在实时性方面，大部分直播是准实时的——存在 1-3 秒延迟。本文由袁荣喜分享其将1080P高清实时视屏直播延迟控制在 500ms 的背后的技术挑战以及实践结论等，期待与各同行共同讨论、学习和进步。

[-11 -] 浅谈开发实时视频直播平台的技术要点

[链接] http://www.52im.net/thread-475-1-1.html

[摘要] 现在大大小小的公司，甚至个人开发者，都想开发自己的直播网站或App，本文会帮你理清，开发视频直播平台，你需要注意哪些技术要点。

[-12 -] 海量用户IM聊天室的架构设计与实践

[链接] http://www.52im.net/thread-4404-1-1.html

[摘要] 本文将分享网易云信针对海量用户IM聊天室的架构设计与应用实践，希望能带给你启发。

[-13 -] 微信团队分享：详解iOS版微信视频号直播中因帧率异常导致的功耗问题

[链接] http://www.52im.net/thread-4507-1-1.html

[摘要] 功耗优化一直是 app 性能优化中让人头疼的问题，尤其是在直播这种用户观看时长特别久的场景。怎样能在不影响主体验的前提下，进一步优化微信iOS端视频号直播的功耗占用，本文给出了一个不太一样的答案。

👉52im社区本周新文：《移动端弱网优化专题(十四)：携程APP移动网络优化实践（弱网识别篇）》，欢迎阅读！👈

我是Jack Jiang，我为自已带盐！https://github.com/JackJiang2011/MobileIMSDK/

关于MobileIMSDK

MobileIMSDK 是一套专门为移动端开发的开源IM即时通讯框架，超轻量级、高度提炼，一套API优雅支持 UDP 、TCP 、WebSocket 三种协议，支持 iOS、Android、H5、标准Java、小程序、Uniapp，服务端基于Netty编写。

工程开源地址是：

• 1）Gitee码云地址：https://gitee.com/jackjiang/MobileIMSDK
• 2）Github托管地址：https://github.com/JackJiang2011/MobileIMSDK

关于RainbowChat

► 详细产品介绍：http://www.52im.net/thread-19-1-1.html
► iOS端更新记录：http://www.52im.net/thread-2735-1-1.html
► 全部运行截图：iOS端全部运行截图 （另：Android端运行截图 点此查看）
► 在线体验下载：App Store安装地址 （另：Android端下载体验 点此查看）

RainbowChat是一套基于开源IM聊天框架 MobileIMSDK 的产品级移动端IM系统。RainbowChat源于真实运营的产品，解决了大量的屏幕适配、细节优化、机器兼容问题（可自行下载体验：专业版下载安装）。

* RainbowChat可能是市面上提供im即时通讯聊天源码的，唯一一款同时支持TCP、UDP两种通信协议的IM产品（通信层基于开源IM聊天框架 MobileIMSDK 实现）。

v9.1 版更新内容

此版更新内容（更多历史更新日志）：

• 1）[bug] 解决了与Web产品互通时，收到撤回被引用消息的指令时会崩溃的问题；
• 2）[bug] 解决了“查换用户”界面中精确查找时，输入内容时会导致底部按钮等控件显示高度被错误改变的问题；
• 3）[bug] 解决了聊天输入框中自定义表情和数字、英文混输时，表情图标会消失的问题；
• 4）[优化] 更换了位置消息中的高德地图AppKey，解决每日调用量限制问题；
• 5）[优化] 优化了首页“消息”列表中单聊类型未正确同步时的收发消息和点击后的处理逻辑；
• 6）[优化] 聊天消息自动识别电话、网址、邮箱等内容，点击自动跳转到系统功能；
• 7）[优化] 优化了首页“消息”列表中同一好友和陌生人会话不能自动合并的问题。

部分功能运行截图（更多截图点此查看）：

一、关于RainbowChat-Web

RainbowChat-Web是一套Web网页端IM系统，是RainbowChat的姊妹系统（RainbowChat是一套基于开源IM聊天框架 MobileIMSDK (Github地址)  的产品级移动端IM系统）。

关于RainbowChat

RainbowChat是一套基于开源IM聊天框架 MobileIMSDK 的产品级移动端IM系统。RainbowChat源于真实运营的产品，解决了大量的屏幕适配、细节优化、机器兼容问题（可自行下载体验：专业版下载安装）。

* RainbowChat可能是市面上提供im即时通讯聊天源码的，唯一一款同时支持TCP、UDP两种通信协议的IM产品（通信层基于开源IM聊天框架  MobileIMSDK 实现）。

► 详细产品介绍：http://www.52im.net/thread-19-1-1.html
► 版本更新记录：http://www.52im.net/thread-1217-1-1.html
► 全部运行截图：Android端、iOS端
► 在线体验下载：专业版(TCP协议)、专业版(UDP协议)      （关于 iOS 端，请：点此查看）

关于MobileIMSDK

MobileIMSDK 是一套专门为移动端开发的开源IM即时通讯框架，超轻量级、高度提炼，一套API优雅支持UDP 、TCP 、WebSocket 三种协议，支持iOS、Android、H5、小程序、Uniapp、标准Java平台，服务端基于Netty编写。

工程开源地址：

• 1）Gitee码云地址：https://gitee.com/jackjiang/MobileIMSDK
• 2）Github托管地址：https://github.com/JackJiang2011/MobileIMSDK

v11.7 版更新内容

此版更新内容（更多历史更新日志）：

（1）Android端主要更新内容：

• 1）[优化] 优化了首页“消息”列表中单聊类型未正确同步时的收发消息和点击后的处理逻辑；
• 2）[优化] 优化了首页“消息”列表中同一好友和陌生人会话不能自动合并的问题；

（2）服务端主要更新内容：

• 1）[优化] 大幅提升群聊性能（改进离线消息存储方式等：异步提交、批量处理）；
• 2）[优化] 升级了mysql驱动至最新版8.4.0；
• 3）[优化] 优化了离线消息处理性能（异步化、无锁队列、批量处理、事务合并）；
• 4）[优化] 优化了聊天记录处理性能（异步化、无锁队列、批量处理、事务合并）；
• 5）[优化] 优化了“接口1008-26-8”，使得与Web产品联合部署明web前端按时间戳加载的消息不与客户端发生重复；
• 6）[优化] 修改了离线消息、聊天记录异步定时器实现，使之运行更健壮；
• 7）[优化] 加好友成功后将成功通知保存至离线消息和消息记录。

部分功能运行截图（更多截图点此查看）：