本文由转转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）[优化] 加好友成功后将成功通知保存至离线消息和消息记录。

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

► 相关链接：

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

一、技术准备

您是否已对Web端即时通讯技术有所了解？

• 1）新手入门贴：史上最全Web端即时通讯技术原理详解
• 2）Web端即时通讯技术盘点：短轮询、Comet、Websocket、SSE

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

• 1）新手快速入门：WebSocket简明教程
• 2）WebSocket详解（一）：初步认识WebSocket技术
• 3）WebSocket从入门到精通，半小时就够！
• 4）从零理解WebSocket的通信原理、协议格式、安全性

WebSocket标准文档、API手册：

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

二、开发工具准备

1）WebStorm：

（JackJiang 使用的版本号如上图所示，建议你也使用此版或较新版本）

2）一站式下载地址：WebStorm官方下载地址点此进入。

三、工程文件用途说明

3.1文件概览

纯原生JS实现，无任何重框架依赖：

MobileIMSDK-H5端SDK本身只是JS文件源码的集合，本工程中自带的前端Demo的目的只是为了方便随时测试MobileIMSDK-H5端的SDK代码而已，在此工程中的使用也仅仅只涉及了一个主Demo页面而已。

工程目录说明：

3.2详细说明

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

四、主要 API 接口

4.1主要 API 接口概览

如下图所示：所有 SDK 接口均由/mobileimsdk/mobileimsdk-client-sdk.js 提供。，接口设计跟MobileIMSDK 的APP版一样，均为高内聚和低侵入的回调方式传入SDK处理逻辑，无需（也不建议）开发者直接修改sdk级代码。

▲ 图上为浏览器端SDK的对外接口文件位置

▲ 图上为浏览器SDK为开发者提供的回调接口

▲ 图上浏览器端SDK的对外接口文件全图

4.2主要 API 接口用途说明

1）IMSDK.isLogined()：

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

2）IMSDK.isOnline()：

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

3）IMSDK.getLoginInfo()：

• 用途：返回登陆时提交的登陆信息（用户名、密码/token等）。
• 说明 ：格式形如：{loginUserId:'',loginToken:''}，此返回值的内容由调用登陆函数 loginImpl()时传入的内容决定。字段定义详见：PLoginInfo
• 返回值：{boolean}，true表示网络连接正常，否则表示已掉线，本字段只在this._logined=true时有意义（如果都没有登陆到IM服务器，怎么存在在线或掉线的概念呢）。

4）IMSDK.sendData(p, fnSucess, fnFail, fnComplete)：

• 用途：向某人发送一条消息。
• 参数p：{Protocal} 要发送的消息协议包对象，Protocal详情请见“/module/mb_constants.js”下的createCommonData函数说明。
• 返回值：{int} 0表示成功，否则表示错误码，错码详见“/module/mb_constants.js”下的MBErrorCode对象属性说明。

5）IMSDK.disconnectSocket()：

• 用途：客户端主动断开客户端socket连接。
• 说明 ：当开发者登陆IM后，需要退出登陆时，调用本函数就对了，本函数相当于登陆函数 loginImpl()的逆操作。

6）IMSDK.setDebugCoreEnable(enable)：

• 用途：是否开启MobileIMSDK-H5端核心算法层的log输入，方便开发者调试。
• 参数enable ：{boolean} true表示开启log输出，否则不输出，开发者不调用本函数的话系统默认是false（即不输出log）。

7）IMSDK.setDebugSDKEnable(enable)：

• 用途：是否开启MobileIMSDK-H5端框架层的log输入，方便开发者调试。
• 参数enable ：{boolean} true表示开启log输出，否则不输出，开发者不调用本函数的话系统默认是false（即不输出log）。

8）IMSDK.setDebugPingPongEnable(enable)：

• 用途：是否开启MobileIMSDK-H5端框架层的底层网络WebSocket心跳包的log输出，方便开发者调试。
• 参数enable ：{boolean} true表示开启log输出，否则不输出，开发者不调用本函数的话系统默认是false（即不输出log）。
• 注意：必须 setDebugEnable(true) 且 setDebugPingPongEnable(true) 时，心跳log才会真正输出，方便控制。
• 返回值：true表示开启log输出，否则不输出，开发者不调用本函数的话系统默认是false（即不输出log）。

9）IMSDK.loginImpl(varloginInfo, wsUrl)：

• 用途：登陆/连接MobileIMSDK服务器时调用的方法。
• 说明 ：登陆/连接MobileIMSDK服务器由本函数发起
• 参数varloginInfo：{PLoginInfo} 必填项，登陆要提交给Websocket服务器的认证信息，不可为空，对象字段定义见：PLoginInfo
• 参数wsUrl：{string} 必填项：要连接的Websocket服务器地址，不可为空，形如：wss://yousite.net:3000/websocket。

10）IMSDK.callback_onIMLog(message, toConsole)：

• 用途：由开发者设置的回调方法：用于debug的log输出。
• 推荐用法 ：开发者可在此回调中按照自已的意图打印MobileIMSDK微信小程序端框架中的log，方便调试时使用。
• 参数1： {String}：必填项，字符串类型，表示log内容。
• 参数2： {boolean}：选填项，true表示输出到console，否则默认方式(由开发者设置的回调决定)。

11）IMSDK.callback_onIMData(p, options)：

• 用途：由开发者设置的回调方法：用于收到聊天消息时在UI上展现出来（事件通知于收到IM消息时）。
• 推荐用法：开发者可在此回调中处理收到的各种IM消息。
• 参数1： {Protocal}：详情请见“/module/mb_constants.js”下的Protocal类定义)。

12）IMSDK.callback_onIMAfterLoginSucess()：

• 用途：由开发者设置的回调方法：客户端的登陆请求被服务端成功认证完成后的回调（事件通知于 登陆/认证 成功后）。
• 推荐用法 ：开发者可在此回调中进行登陆IM服务器成功后的处理。

13）IMSDK.callback_onIMAfterLoginFailed(isReconnect)：

• 用途：由开发者设置的回调方法：客户端的登陆请求被服务端认证失败后的回调（事件通知于 登陆/认证 失败后）。
• 说明 ：登陆/认证失败的原因可能是用户名、密码等不正确等，但具体逻辑由服务端的 callBack_checkAuthToken回调函数去处理。
• 推荐用法：开发者可在此回调中提示用户登陆IM服务器失败。。
• 参数1： {boolean}：true表示是掉线重连后的认证失败（在登陆其间可能用户的密码信息等发生了变更），否则表示首次登陆时的认证失败。

14）IMSDK.callback_onIMReconnectSucess()：

• 用途：由开发者设置的回调方法：掉线重连成功后的回调（事件通知于掉线重连成功后）。
• 推荐用法 ：开发者可在此回调中处理掉线重连成功后的界面状态更新等，比如设置将界面上的“离线”文字更新成“在线”。

15）IMSDK.callback_onIMDisconnected()：

• 用途：由开发者设置的回调方法：网络连接已断开时的回调（事件通知于与服务器的网络断开后）。
• 推荐用法 ：开发者可在此回调中处理掉线时的界面状态更新等，比如设置将界面上的“在线”文字更新成“离线”。

16）IMSDK.callback_onIMPing()：

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

17）IMSDK.callback_onIMPong()：

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

18）IMSDK.callback_onIMShowAlert(alertContent)：

• 用途：由开发者设置的回调方法：框架层的一些提示信息显示回调（本回调并非MobileIMSDK-H5端核心逻辑，开发者可以不需要实现！）。
• 说明 ：开发者不设置的情况下，框架默认将调用wx.showModal()显示提示信息，否则将使用开发者设置的回调——目的主要是给开发者自定义这种信息的UI显示，提升UI体验，别无它用】。
• 参数1：{String}：必填项，文本类型，表示提示内容。

19）IMSDK.callback_onIMKickout(kickoutInfo)：

• 用途：由开发者设置的回调方法：收到服务端的“踢出”指令（本回调并非MobileIMSDK-H5端核心逻辑，开发者可以不需要实现！）。
• 参数1 ：{PKickoutInfo}：非空，详见：PKickoutInfo

20）IMSDK.callback_onMessagesLost(lostMessages)：

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

21）IMSDK.callback_onMessagesBeReceived(theFingerPrint)：

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

五、前端开发指南

5.1如何引入SDK文件到您的前端工程中？

很简单：只需要将第2节中提到的SDK所有JS文件复制到您的Uniapp工程下即可。

SDK内容见下图：

5.2如何在代码中调用SDK？

第一步：在你的网页中引用SDK的js文件（具体例子详见Demo中的index.html文件）

第二步：直接在你的JS文件中编写回调配置代码（具体例子详见Demo中的index.js文件）

第三步：在你的JS文件中调用IM的登陆方法即可（具体例子详见Demo中的index.js文件）

注意：上图中登录连接的IP地址请设置为您的MobileIMSDK服务器地址哦。

六、Demo运行方法（在WebStorm中直接预览）

6.1重要说明

特别说明：MobileIMSDK的H5端（包括Demo在内），全部是静态的HTML+JS资源，可以通过WebStorm自带的HTML页面预览功能，直接自动加载到电脑的浏览器中运行和预览。

6.2预览方法

1）在Demo中的index.html文件中，移动鼠标，会在右上角出现如下图所示的浮出菜单：

2）点击右上角浮出菜单上相应的浏览器就可以自动预览了（这里以我电脑上已安装的Edge浏览器为例）：

七、Demo运行方法（在Web服务器中部署并访问）

7.1重要说明

特别说明：MobileIMSDK的H5端（包括Demo在内），全部是静态的HTML+JS资源，对于服务端是没有任何依赖的，只需要保证浏览器端能加载到即可，可以把它们放置在Tomcat、Apache、IIS、Nginx等等传统Web服务器中即可，无需任何动态运行环境。

7.2安装Tomcat

提示：以下Demo的部署，以Java程序员最常用和Tomcat为例（Apache、IIS、Nginx等依此类推）。

Tomcat的安装就没什么好说的，直接官网下载对应的版本即可：https://tomcat.apache.org/download-90.cgi。

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

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

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

▲ 配置要连接的服务器IP（以上代码详见demo/index.js 文件）

7.4部署Demo

说“部署”有点扯蛋，因为Demo（包括SDK）在内，全是HTML静态内容，只需要直接复制到任何一种Web服务器即可。

以下是复制到Tomcat服务器网页目录后的截图：

7.5启动Tomcat

提示：本手册中仅以启Tomcat为例，Apache、IIS、Nginx等Web服务器的启动请自动百度。

运行startup.bat启动Tomcat：

7.6Demo的运行效果预览

八、Demo功能预览和说明

九、Demo运行效果实拍图

1）Demo在手机端浏览器中的真机实拍图：

2）Demo在电脑端浏览器中的真机实拍图：

十、更多Demo运行效果截图

1）Demo在PC端浏览器运行效果：

2）Demo在手机端浏览器运行效果：

3）Demo在PC端各主流浏览器的运行效果：

十一、常见问题（FAQ）

11.1为什么浏览控制台下有些log不显示？

原因是浏览器控制台下的日志级别默认进行了过滤，勾选所有日志级别，就能看到SDK的详细日志输出了。

勾选所有的日志输出级别：

然后就能看到SDK中详细的日志输出了（就像下图这样），方便调试和研究：

十二、引用资料

[1] WebSocket 标准API手册

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

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

[4] MobileIMSDK-H5端基本介绍

[5] MobileIMSDK-H5端的开发手册（* 精编PDF版）

[6] MobileIMSDK的Demo使用帮助：Server端

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

一、基本介绍

• 1）超轻量级、极少依赖；
• 2）纯JS编写、高度提炼，简单易用；
• 3）基于标准WebSocket协议，客户端兼容性好；
• 4）支持运行于iOS、Android等移动端浏览器和各种PC端浏览器；
• 5）能与 MobileIMSDK（Github托管链接）的各种APP原生代码客户端完美互通；
• 6）可应用于手机端/PC端的网页聊天应用、企业OA、Web端等即时通讯场景。

二、与MobileIMSDK的关系

MobileIMSDK-H5端 是基于标准HTML5的WebSocket协议的 MobileIMSDK配套客户端库。

以下是MobileIMSDK的通信架构图：

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

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

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

三、与MobileIMSDK-Web的关系

• 1）都是Web端即时通讯框架；
• 2）都是纯JS编写；
• 3）都可以运行在手机、pc端的浏览器或web容器内。

• 1）MobileIMSDK-Web可以兼容不支持HTML5的旧版浏览器或容器，而MobileIMSDK-H5端必须运行在当前主流的HTML5浏览器或容器；
• 2）MobileIMSDK-Web需依赖于socket.io这种第3方通信层库，而MobileIMSDK-H5端无任何额外依赖。

• 选择一：如果您的应用必须兼容旧版浏览器（包括旧版IE等）：
  那唯一的选择就是MobileIMSDK-Web，因为它存在的主要价值就是为了兼容旧版浏览器；
• 选择二：如果您的应用只需运行在现今主流的HTML5浏览器或容器：
  那么建议您优先使用MobileIMSDK的H5端，必竟直接调用标准HTML5的WebSocket API，要简洁、轻量多了，也没有第3方依赖。

四、设计目标

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

• 1）前端与通信解偶：前端UI与网络通信代码解耦，UI界面的重构、维护、改版都非常容易和优雅；
• 2）轻量级和兼容性：受益于标准WebSocket，可很好地运行于现今主流的H5浏览器上，且无需额外依赖；
• 3）核心内聚和收敛：得益于长期的提炼和经验积累，SDK核心层高度封装，开发者无需理解复杂算法即可简单上手。
• 4）纯JS轻量级实现：纯JS编写，无Angular、EmberJS、VUE等各种重量级前端框架依赖，方便对接各种既有系统；

五、技术亮点

• 1）轻量易使用：超轻量级——纯JS编写且极少依赖，高度提炼——简单易用；
• 2）兼容性很好：基于标准WebSocket，可很好地运行于现今主流的H5浏览器上，且无需额外依赖；
• 3）断网恢复能力：拥有网络状况自动检测、断网自动治愈的能力；
• 4）送达保证机制：完善的QoS消息送达保证机制（自动重传、消息去重、状态反馈等），不漏过每一条消息；
• 5）支持多种设备：支持运行于iOS、Android等移动端浏览器和各种PC端浏览器；
• 6）通信协议封装：实现了一个对上层透明的即时通讯通信协议模型；
• 7）身份认证机制：实现了简单合理的身份认证机制；
• 8）完善的log信息：在开发调试阶段，确保每一个算法关键步骤都有日志输出，让您的运行调试更为便利；
• 9）前端代码解耦：实现了UI前端代码与sdk网络通信代码解偶，防止前端代码跟IM核心代码混在一起，不利于持续升级、重用和维护；
• 10）多端协议兼容：实现了与MobileIMSDK各APP端完全兼容的协议模型；

六、文件组成

SDK代码文件概览：

SDK代码文件用途说明：

七、Demo功能预览和说明

八、Demo运行效果实拍图

1）Demo在手机端浏览器中的真机实拍图：

2）Demo在电脑端浏览器中的真机实拍图：

八、更多Demo运行效果截图

3）Demo在PC端主流浏览器的运行效果（点击可看大图 ▼）：

十、详尽开发者手册

十一、相关资料

本文由携程技术Jim分享，原题“日访问过亿，办公IM及开放式平台在携程的实践”，下文进行了排版和内容优化。

1、引言

携程内部的办公IM项目最早在2016年立项，经历了初期简单办公场景下的纯IM服务，到支持简单办公组件的IM应用，又演变为一体化办公集成平台，进而演变为目前集成IM功能的开放式企业效率平台。

本文总结了携程办公IM这些年的发展历程及未来的演进方向，并着重从高可用、高性能和可扩展的角度，探讨开放式平台的技术实现及发展方向。

2、关于作者

Jim：携程高级研发经理，关注Java & Go技术栈后端研发。目前致力于TripPal开放平台的高可用、开放化进程及核心衍生服务。

3、什么是IM

IM（Instant Message）即时消息，是一种通过网络提供实时消息传输的在线沟通技术。

在移动互联网时代，IM的使用变得越来越广泛，通过各种技术手段使得用户之间的交流成本变的极低，沟通效率和用户体验有极大的提升。而且IM的出现极大地改变了目前互联网应用的形态，多数互联网应用只要做到了一定规模，一定会有自身IM的需求，而不是单纯地仅仅依托第三方（例如微信、云信等）。

PS：关于什么是IM，您也可详读专题文章《零基础IM开发入门(一)：什么是IM系统？》。

4、 携程办公IM的发展历程

早期携程使用微软的IM软件lync和自研的纯IM软件CtripTeam来支持企业内的沟通需求，这些软件在维护性、拓展性和可用性上都或多或少存在一些缺陷。同时随着互联网的发展，也逐渐不适合日益增长的办公需求和用户体验。

2017年左右，使用基于ejabberd+erlang的自研IM服务的Cchat项目应运而生，该项目的主要目标是在采用自研IM的基础上，实现IM与办公的结合。在完善IM服务的基础上，支持了一些常规的办公场景，如电话、假单、考勤、OA等，通常采用嵌入外部页面、跳转外部地址等方式提供服务。这个改造项目奠定了携程办公IM继续发展的基础。

随着项目的深入，最初的系统交互模式及服务管理模式逐渐不适用越来越复杂的办公场景及服务治理需求。于是在2019年上马了TripPal的改造项目，在结合公司国际化战略的基础上，倾力打造小程序平台，服务号等基础服务。在梳理、优化原有服务的同时，打造了诸多衍生服务。

2020年中开始，在继续推进企业内办公一站式平台的基础上，我们需要支持更多的外部场景，实际需求促使我们向开放式平台转型，这在服务整体架构、安全性、扩展性等方面都提出了新的要求及挑战。

5、携程TripPal开放平台总体架构

5.1Gateway网关层

这一层是所有请求调用流量的入口，主要功能如下：

• 1）服务路由；
• 2）集中式限流、风控、日志监控等功能；
• 3）调用IDS (Identity Service) 验证请求的合法性。

第 3）步中验证通过后，可以将用户ID、Token等基本信息，通过 HttpHeader 的方式向后端服务透传，后端服务可以直接使用UserID，也可以再次对Token进行认证

5.2IDS (Identity Service) 服务

IDS同时支持多种不同类型的访问令牌的鉴权，同时还负责令牌的颁发，以及RBAC+模块级别的接口控权。

另外，针对开放小程序，TripPal提供两种认证方式：

1）常规的Oauth第三方模式接入：

2）另一种是基于Oauth+开放平台签名的第三方认证，对于接入方相对简单：

5.3微服务层

这一层是整个系统的业务层，具体包含三种类型的微服务：

• 1）TripPal开放平台内部系统微服务：只有在特定用户认证和权限验证通过之后，外部才能访问；
• 2）开放平台对外提供的OpenAPI：采用Oauth+RBAC的方式控制权限；
• 3）自研小程序后端服务：根据安全需要，所有使用Oauth+模块权限的第一方小程序服务端。

目前TripPal自身的核心微服务应用达到28个，提供全集团的多端（C端、B端）基础服务能力，服务全公司超过500个业务应用，在线C端用户均值超过2万，日访问量超过亿。

6、 TripPal的IM服务

目前TripPal使用完全自研的基于Java实现的类ejabberd架构，底层采用的XMPP协议进行通讯。

Tips：

XMPP全称是ExtensibleMessageing and Presence Protocol，可扩展消息与存在协议。是目前网络上开源，最灵活，应用最广泛的一种即时消息通信协议。

1999年Jeremie Miller，首先提出了Jabber，一种为实现即时消息和存在的开放技术，后续基于这个协议，开发了一个开源的服务实现jabberd。后续，IETF国际标准组织介入，成立Extensible Messageing and Presence Protocol（XMPP）工作组，并开始标准化工作。

2000年，jabberd服务器1.0版本发布，那时Jabber协议的基本特点（基于XML的流，消息，存在，联系人列表等）都被固定下来。

2004年，IETF出版了RFC 3902和RFC3921，定义了XMPP的核心功能，成为推荐标准。

后续在2011年，IETF出版了RFC6120和RFC 6121，更新了XMPP的核心定义，替代了之前的RFC 3920和3921。

目前XMPP协议被XMPP Standards Foundation负责管理运作，集中于在IETF定义的基础XMPP规范之上，如何开发开放的协议扩展。

IM服务端做了大量的系统性的优化，从底层的数据库调优、底层通讯服务升级，到上层消息、群、群成员等核心功能的大幅改造。

底层通讯服务由之前的erlang完整迁移至java技术栈，服务可靠性、弹性伸缩、安全性和性能获得了提升。同时对上层偏业务的服务进行了改造，极大地提升了接口响应，服务稳定性也得到了提升，为整个产品的研发提供了重要支撑。

目前这套自研的IM 3.0服务在生产环境稳定运行，整体资源消耗比2.0时期有较大下降。

7、 TripPal办公衍生服务

7.1概述

在实际的企业办公场景下，尤其是大型企业复杂组织架构和管理模式的场景下，TripPal逐渐摸索出了自己的一套行之有效且契合携程场景的办公智能应用，如搜索中台，消息卡片，智能审批中台，角色服务，工作流引擎等。

本文简单介绍其中3个服务。

7.2智能审批中台

智能审批中台在集成携程自有的审批系统的同时也集成了自研的智能审批配置服务，该服务支持用户自定义整个审批单及审批流的全部细节。

7.3角色服务

角色服务在灵活定义角色范围及基础角色的基础上，支持用户灵活调整，动态管理，且自动接入审批中台，同时打通应用对接渠道。

整个角色服务在产品定义上分为如下表4个主要概念：

7.4在线文档

在线文档服务主要提供文档的在线协作能力，支持用户同时/实时的查看、编辑、保存和分享的能力。同时结合IM实现通知和反馈等功能。

技术实现上，在线文档是采用CRDT算法实现的无冲突merge（LastWrite Wins）、多端最终一致的分布式方案，同时兼具高可用、可容错的特性，在服务器发生故障时，允许Shift至另一台机器上继续执行，即使服务端完全宕机，客户端依然能够离线工作。

8、 TripPal高可用的实践

目前TripPal部署在3个机房，分为公有云1个机房及私有云2个机房。

总体架构在应用多机房部署、数据层跨机房DRC的基础上，采用就近访问的原则进行服务访问，其中一旦发生任意2个机房全挂的情况，都能保证系统内的核心应用仍能提供服务。

其中公有云机房的一期部署方案已经完成，二期部署方案和测试计划预计于7月完成，届时可以和大家分享一下混合云方案的一些细节和历程。

9、 开放平台的未来架构及演进方向

9.1概述

开放平台主要面向两类群体，开发者和用户。

所以主要有两个方向：

1）一是便捷开发，主要围绕降低开发者门槛、较低研发成本，打通不同开发者、应用之间的壁垒，实现生态共享。

2）另一方面，针对实际用户，在提高用户体验、数据安全的同时，实现用户服务能力整合和主动发现。

9.2开发者

在这方面，目前主流开放平台已经对开发者提供了强大的支持。

主要形式分为以下3种。

1）前端信任：

前端信任的目的是通过减少或杜绝开发者后端跟开放平台OpenAPI交互的方式，来降低开发者接入门槛，减少工作量。主要的做法是通过权限控制、签名、加密等手段使得小程序能够在前端拿到可信数据。

2）低代码(Low-Code)：

由于大量的互联网业务属于简单交互或模型化交互，以此为出发点，基于构建合理模型、简单业务函数等形式，可以允许开发者通过拖拽组件、简单伪业务代码等形式提供编程入口，可以大幅度降低开发者的研发门槛和成本，打破用户和开发者界线，提高开放平台整体生态的活力。

3）ServerLess：

基于云原生的ServerLess结合低代码，开放开发者的云端编程入口，同时提供云端基础组件，允许开发者无需部署实际的后端应用服务，极大降低的开发者的运营维护门槛。

9.3用户层面

目前业界主流开放平台在对用户本身的服务能力整合和挖掘上，投入的都比较少，也没有比较成熟的实践，我们认为在这方面可以围绕两个点展开。

一方面：第三方应用治理模式向商城化的转型。常规开放平台的应用治理和推广，基本是应用方独立管理和推广，但是随着应用数量的大幅度增加，以及应用方单方面推广难度较大等原因，亟需开放平台从生态整体角度进行支持和治理。这样可以在安全性、可维护性、便捷性等维度上对应用进行正向反馈，实现开放平台应用生态的可持续性和能力共享。同时，在特定场景下，结合用户分析、大数据及AI，提高用户主动或被动的应用发现能力。

另一方面：构建符合应用间开放协议的软件联盟，打破应用壁垒，围绕服务集成、开放应用的核心原则，使得不同的互联网业务或行为在一定程度上实现数据/能力共享。一般情况下，一个复杂互联网业务通常由多个异构子业务/子应用构成，这样，通过应用拆分、开放共享等形式，在一定程度上使复杂的互联网业务更加精细化、轻量化、可扩展。

9.4开放平台标准化、互通

目前国内外各大互联网公司、机构和组织都搭建了多种开放平台，用于提供各种各样的信息服务，在可以预见的未来，各个平台之间会有一个整合、标准化、互通的可能性。

那么构建标准开放协议，使得开放平台向底层沉淀的过程则至关重要。

10、 本文小结

通过实现基本IM开放平台架构，以及各种衍生服务，我们总结出了IM开放平台的一些核心能力。

主要是：

• 1）服务集成：根据不同的业务场景集成并提供相应场景下的基础服务能力；
• 2）开放应用：提供第三方接入能力；
• 3）高性能、高可用。

11、参考资料

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

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

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

[4] 从游击队到正规军(一)：马蜂窝旅游网的IM系统架构演进之路

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

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

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

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

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

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

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

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

[13] 阿里IM技术分享(三)：闲鱼亿级IM消息系统的架构演进之路

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

[15] 跟着源码学IM(十)：基于Netty，搭建高性能IM集群（含技术思路+源码）

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

[17] 直播系统聊天技术(八)：vivo直播系统中IM消息模块的架构实践

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

[19] 得物从0到1自研客服IM系统的技术实践之路

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

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

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

关于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.6 版更新内容

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

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

• 1）[bug] 解决了APP从后台恢复时，有一定几率因后台多线程操作好友数据导致的线程安全崩溃问题；
• 2）[优化] 加固了一处好友列表中根据昵称取拼音首字母的非空检查逻辑；

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

• 1）[bug] 升级了MobileIMSDK至v6.5，尝试解决极小几率下Android端会误把“自已”踢掉的问题
• 2）[bug] 解决了因Netty库版本升级导致iOS消息推送失败报错的问题：
• 3）[bug] 解决了消息撤回时，被引用消息的历史记录没有正确处理撤回逻辑；
• 4）[优化] 为“接口1008-26-7”增加了“at_me”字段的返回；
• 5）[优化] 优化了“接口1008-26-8”，使得在跟Web互通时支持按时间戳的聊天记录分页加载方案；
• 6）[优化] 为“接口1008-26-8”增加了“消息发送者昵称”内容的返回；

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

一、关于RainbowChat-Web

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

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

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

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

[摘要] 本文是《移动端实时音视频直播技术详解》系列文章之第一篇，我们将从整体介绍直播中的各个环节。

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

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

[摘要] 本文是《移动端实时音视频直播技术详解》系列文章之第二篇：我们将从整体介绍直播中的采集环节。

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

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

[摘要] 本篇是《移动端实时音视频直播技术详解》系列文章之第三篇：我们将从整体讲解常见视频处理功能：如美颜、视频水印、滤镜、连麦等。

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

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

[摘要] 本篇是是《移动端实时音视频直播技术详解》系列文章之第四篇：我们将从整体讲解编码和封装。

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

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

[摘要] 本篇是《移动端实时音视频直播技术详解》系列文章之第五篇：我们将从整体讲解推流和传输。

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

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

[摘要] 本篇是《移动端实时音视频直播技术详解》系列文章之第六篇：我们将从整体讲解延迟优化技术。

[- 7 -] 理论联系实际：实现一个简单地基于HTML5的实时视频直播

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

[摘要] 本次分享就向大家介绍一下分享一下直播的整个流程和一些技术点，并动手实现一个简单的Demo。

[- 8 -] 实时视频直播客户端技术盘点：Native、HTML5、WebRTC、微信小程序

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

[摘要] 连麦视频直播的客户端主要包括：原生 APP、浏览器 H5、浏览器 WebRTC、微信小程序。浏览器上的应用包括 H5 和 WebRTC，前者可以拉流观看，后者可以实现推流和拉流。

[- 9 -]  Android直播入门实践：动手搭建一套简单的直播系统

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

[摘要] 实时视频直播是这两年非常火的技术形态，已经渗透到教育、在线互娱等各种业务场景中。但要搭建一套实时视频直播系统，并非易事，当然相关的直播技术理论在论坛的其它文章里已经写的非常详细，本文不再展开。

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

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

[摘要] 本文由淘宝直播音视频算法团队分享，对实现高清、低延时实时视频直播技术进行了较深入的总结，希望分享给大家。

[- 11 -] 技术干货：实时视频直播首屏耗时400ms内的优化实践

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

[摘要] 直播行业的竞争越来越激烈，进过2018年这波洗牌后，已经度过了蛮荒暴力期，剩下的都是在不断追求体验。最近正好在做直播首开优化工作，实践中通过多种方案并行，已经能把首开降到500ms以下，借此机会分享出来，希望能对大家有所启发。

[- 12 -] 新浪微博技术分享：微博实时直播答题的百万高并发架构实践

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

[摘要] 本文将分享新浪微博系统开发工程师陈浩在 RTC 2018 实时互联网大会上的演讲。他分享了新浪微博直播互动答题架构设计的实战经验。其背后的百万高并发实时架构，值得借鉴并用于未来更多场景中

👉52im社区本周新文：《IM跨平台技术学习(十二)：万字长文详解QQ Linux端实时音视频背后的跨平台实践》，欢迎阅读！👈

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

本文由爱奇艺技术团队分享，作者isno，原题“爱奇艺海外App的网络优化实践”，下文进行了排版和内容优化等。

1、引言

做海外市场，特别目标是面向全球的用户，网络的重要性不言而喻。试想一个移动端应用，比如即时通讯IM，聊天消息的本质就是人跟人在说话，一条消息从发送到接受需要10秒的时间，这恐怕会让用户崩溃，随之就是被无情地卸载，开拓海外市场那就是做梦了。

本次分享的文章内容，基于爱奇艺面向全球用户推出的国际版，在海外跨国网络环境复杂的前提下，针对性地做了一系列弱网优化实践，取得了不错的效果，在此总结分享我们的一些做法和优化思路，希望对你有所帮助。

总结下来，跨国弱网优化实践的几个核心就是：

• 1）能不请求网络就不请求；
• 2）请求的链接目标 0-RTT；
• 3）请求的内容越小越好。

正文内容我们将逐个技术点展开了分享。

2、系列文章

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

1. 《移动端IM开发者必读(一)：通俗易懂，理解移动网络的“弱”和“慢”》
2. 《移动端IM开发者必读(二)：史上最全移动弱网络优化方法总结》
3. 《移动端IM开发者必读(三)：爱奇艺移动端跨国弱网通信的优化实践》（* 本文）

如果您是IM开发初学者，强烈建议首先阅读《新手入门一篇就够：从零开发移动端IM》。

3、 跨国弱网样本摸底

在 App 初期版本内增加请求链路的采样。样本数足够的情况下，可以清楚你要推广的市场是怎样的环境。样本数据让我们清楚发现了各个国家、地区网络的问题，在大规模宣传和投入前，做好 App 的基础工作非常重要。

海外用户至海外数据中心的网络延迟（这是监测节点数据，用户端延迟更高）：

海外主要国家、地区移动网络情况：

在调研阶段，我们发现了以下问题比较明显，切实影响我们的运营及 App 体验。

这些问题主要是：

• 1）运营商劫持严重，DNS 劫持、HTTP 劫持；
• 2）移动端网络复杂 ，东南亚的网络基础建设还待改善；
• 3）低端 Android 机有一定的占比，数量级别影响决策；
• 4）国际网络用户端到服务器的延迟高。

在初期阶段，技术工作的核心是解决以上问题，为后续的运营做好基础建设。因为业务接口大部分为 HTTP 形式，就开始围绕 HTTPS 进行针对性改进。

一个HTTPS请求阶段分析：

一个 HTTPS 在第一请求会有 5 个 RTT：

1RTT(DNS)+ 1RTT(TCP 握手)+ 2RTT(TLS1.2)+ 1RTT(HTTP 链接)

如果以端到服务 50ms 延迟为例：

一个 HTTPS 的接口延迟 =  350ms =  50*5+ 100ms（服务端）

如果目标是一个非国内用户，打开首页需要 1.1s, 这个时间显然有点长。

下面开始进行技术改进的正文，以下是概括技术性优化的关键点：

4、基础链路的改进优化

4.1DNS 优化调整

DNS 的解析改为 HTTPDNS，DNS 的改进上线后观察初始连接请求提升 17% 的效率。

目的主要是：

• 1）解决域名劫持问题 （东南亚地区回传的数据显示有不少劫持）；
• 2）解决 LocalDNS 非就近分配问题；
• 3）结合业务可以做解析预热。

4.2传输层的优化调整

MTU 的问题 ：

• 1）Client 端和 Server 端不同的 MTU 值会导致丢包率过高。AWS 某些场景实例默认巨型帧：MTU 是 9001，但接收端默认 1500，这时候就会出现一些丢包的现象；
• 2）如果你用了多个云商服务，用 VPN 组网，IP隧道封装的数据临界 1500，又会造成丢包、包重传问题；
• 3）最严重的情况：部分网络封杀 ICMP 协议，导致 MTU 无法自动协商。

TCP 拥塞控制优化：

拥塞窗口 CongWin 是未接收到接收端确认情况下连续发送的字节数; 。CongWin 是动态调整，取决于带宽和延迟的积，比如 100MB 的带宽 100ms 的延迟环境。

时延带宽积 = 100Mbps*100ms = (100/8)*(100/1000) = 1.25MB

理论上 CongWin 窗口可以最大化到 1.25MB。CentOS 默认CongWin = 20*MSS，在 29KB 左右，离上限 1.26MB 差太多了，默认值上调TCP的启动会更快。

TCP 快速打开 (TCP Fast Open：TFO)：

TCP 的 keepalive 下依然会有链接断掉重建的情况，TFO 是针对这种情况的优化。

TFO 的原理机制：

在我们观察中开启 TFO 机制，海外业务一个 RTT 通常时间在 100ms 以上，HTTP 请求效率提升了 12% 左右。

5、应用层的改进优化

5.1HTTP 的优化

HTTP1.1 有个 keep-alive 作用是复用 TCP 链接，减少新建的消耗，对于浏览器的业务比较适用，但对于移动端这种时间分散的请求，大部分请求还是新建连接。

HTTP1.1 的串行机制有头部阻塞的问题。

5.2SSL 层优化

尽量升级到 TLS1.3（微信的TLS1.3实践：《微信新一代通信安全解决方案：基于TLS1.3的MMTLS详解》），利用 Pre-shared Key 机制，开启 ssl_early_data 可以进一步优化 “0-RTT ”，如果无法升级 TLS 版本，优化密钥算法为 ECDHE，运算速度快，握手的消息往返由 2-RTT 减少到 1-RTT，能达到与 TLS1.3 类似的效果。

TLS 版本的区别：

TLS1.3 经过优化后，一个 HTTP 请求由之前的 4 个 RTT 减少为 3 个 RTT。

5.3升级 HTTP2.0

几个重要的改进点：

• 1）分帧传输；
• 2）多路复用；
• 3）头部压缩。

多路复用：

在 HTTP/2 中，两个非常重要的概念：帧（frame）和流（stream）。帧代表着最小的数据单位，每个帧会标识出该帧属于哪个流，流也就是多个帧组成的数据流。多路复用，就是在一个 TCP 连接中可以存在多条流。这些改进可以避免 HTTP 队头阻塞问题，提高传输性能。

头部压缩：

开发人员如果不注意对 header 内容的控制，会造成 header 内容失控的现象，客户端极容易存储一个非常大的 Cookie。

HTTP2 的分帧传输机制：

5.4边缘节点动态加速

这个是非常有效的方式。

尽可能离用户最近，利用边缘节点对路由、链路进行优化，提高动态服务的效率。相较于直连模式，使用动态加速后，P90 的接口延迟效率提升了 60%。

爱奇艺海外动态加速的效果提升（请求时间为秒）：

5.5启用兜底机制

对于失败的请求，启用兜底的协议 QUIC 或者 kcp。

客户端的失败率在 3% 左右，对这部分请求使用 UDP 协议兜底尝试，在我们的观察成功率提升了 45%。

6、传输内容的优化

6.1应用 Brotli

因为预置了字典，在同等级别的压缩率下，对比 gzip 至少提升了 17% 的压缩比，接口平均的 Content-Size 由 30KB，降至 18KB。

6.2接口由 JSON 改为 Google Protobuf

应用 Protobuf 的重要原因是解析效率比 JSON 至少高四五倍，在节点深度和数据量大的情况下更明显。

但注意 Protobuf 内部的 varint 压缩，只对小于 128 的数字进行可变长压缩。实际效果不大，生产环境如果数据量大，外层的压缩如 gzip 不可少。

PS：关于Protobuf的资料，可以进一步阅读《IM通讯协议专题学习》。

6.3图片格式升级为 WebP

在应用 WebP 的同时，降低海报图片的质量，实践看海报的 quality 设置为 85% 肉眼难以分辨，相对同质量的 JPEG 或者 PNG ，可以最大减小 45% 的体积。

应用效果明显。App 打开首页图片的加载提升肉眼可见。

7、业务层面的优化改进

7.1减少不必要请求：

一些通用内容，如导航、频道，通常由运营人员主动更新。

如下图：增加一个启动阶段请求的接口，里面放入内容更新的时间戳，与本地 cache 的时间戳有差异，则异步请求更新。

 

7.2区别用户网络，适应不同的策略

具体作法是：

• 1）对于视频，非 WiFi 默认启播码率为 360P；
• 2）对于海报，后端接口提供两种质量的 Url，WiFi 高质，4G 低质。

7.3更多的业务优化

增加请求重试、调整 HTTP 的超时时间，请求缓存等等  这些可以根据业务的需求进行调整。

8、本文小结

爱奇艺海外版APP经过一系列细节优化，用户体验持续上升。用户接口延迟、客户端失败率、视频播放成功率一系列的关键指标得到很大的改善。这也助力爱奇艺在东南亚多个国家的应用市场排名升至 TOP 1。

另外 App 优化、Server 延迟优化、产品体验的改进，这一系列只有相辅相成才可以最大化提升用户体验。

9、参考资料

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

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

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

[4] 现代移动端网络短连接的优化手段总结：请求速度、弱网适应、安全保障

[5] 全面了解移动端DNS域名劫持等杂症：技术原理、问题根源、解决方案等

[6] 美图App的移动端DNS优化实践：HTTPS请求耗时减小近半

[7] 百度APP移动端网络深度优化实践分享(一)：DNS优化篇

[8] 百度APP移动端网络深度优化实践分享(二)：网络连接优化篇

[9] 百度APP移动端网络深度优化实践分享(三)：移动端弱网优化篇

[10] 爱奇艺移动端网络优化实践分享：网络请求成功率优化篇

[11] 美团点评的移动端网络优化实践：大幅提升连接成功率、速度等

[12] 淘宝移动端统一网络库的架构演进和弱网优化技术实践

[13] 谈谈移动端 IM 开发中登录请求的优化

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

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

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

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

[18] IM开发者的零基础通信技术入门(十二)：上网卡顿？网络掉线？一文即懂！

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

[20] IM通讯协议专题学习(一)：Protobuf从入门到精通，一篇就够！

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

一、关于RainbowChat-Web

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