共计 5540 个字符，预计需要花费 14 分钟才能阅读完成。
（点击报名融云 2022 社交泛娱乐出海嘉年华）
8 月底，“IM 进阶实战高手课·第二讲”围绕“Web & Electron 平台即时通讯产品的技术选型”进行了具体拆解。
融云讲师巧用比喻等办法，活泼而又逻辑清晰地对 IM 场景前端技术计划进行了剖析比照，并分享了融云的最佳实际。下期聚焦 IM 全能力，就在 9 月 20 日 关注【融云寰球互联网通信云】理解更多
IM 常见业务状态及外围性能
即时通讯产品常见的业务状态有以下几种：聊天室、单群聊、超级群、实时告诉、在线播送。而底层性能就像根底整机，能够用不同的办法拼接出下层的不同业务状态。
根底性能单元模块，大略就分为三类：
最根底的是 连贯治理类 的需要，这是即时通讯业务的根底。接着是两端基于连贯的数据传输，这里咱们要关注的是前后端通信时的 数据传输协定，也就是对于数据的序列化和反序列化的过程治理。最初就是基于既有数据的查问性能，咱们次要分享前端的长久化存储技术。
即时通讯场景下，对于这三个技术点的一些技术要求各不相同。
- 连贯治理 – 继续、稳固、及时的双向网络连接
- 数据传输 – 平安、高效、易拓展的前后端数据传输协定
- 记录查问 – 前端数据长久化存储计划
网络连接计划比照
咱们通过五个指标来横向比照连贯计划，别离是：连贯速度、传输效率、即时性、安全性、兼容性。
WebSocket 是前端的首选计划 ，它也是 Web 平台上构建长连贯业务的原生技术计划。因为浏览器平安沙箱的存在，咱们不能在 Web 浏览器内间接拜访传输层协定，然而 Electron 主过程内是百无禁忌的，咱们 能够在 Electron 场景下选用 TCP。
基于 HTTP 的模仿双工协定解决方案，并不是单纯的 HTTP 协定自身，因为在长连贯业务中，短连贯个性的 HTTP 协定并不匹配需要场景。
连贯速度
连贯速度是从发动连贯到连贯建设的耗时。
TCP 的连贯须要进行三次握手，对于发动端是发两次收一次，对于应答端就是发一次收两次。
为什么要做三次握手？其实这也是一个很常见的面试题。打个比方来说，两个人要达成一次无效对话，就须要确定两个信息：一是本人的耳朵和嘴巴没有问题；二是对方的耳朵和嘴巴没有问题。只有在这个根底之上，两者之间的对话才是无效的。三次握手就是要实现这么一个能力确认过程。嘴巴 = 发送能力，耳朵 = 接管能力。
当然这个比喻也不谨严，单方语言不通时也沟通不来。这是第二个技术方向数据封装协定要解决的问题，也就是对对端用意了解问题。
WebSocket 连贯要建设在 TCP 连贯根底之上，因为 WebSocket 是一个应用层协定，也就是运维们常常说的 7 层协定，而 TCP 是一个传输层协定，是 4 层协定。
TCP 握手实现之后，通过 HTTP 报文向服务器协定提出降级申请，服务通过 HTTP response 报文来响应申请，至此 WebSocket 协商实现。比 TCP 多了两个动作，所以 WebSocket 的连贯速度是慢于 TCP 的。HTTP 是短连贯协定，连贯无奈稳固放弃，每次通信要重建连贯，所以连贯速度对它没有意义。
传输效率
咱们把传输效率定义为同一块数据在传输过程中产生的流量耗费、工夫耗费、算力耗费，以辅助横向比照不同网络协议，耗费越大，效率越低。
这里咱们次要看流量耗费和工夫耗费，算力耗费在 Web 和 Electron 简直能够忽略不计。先看一下 OSI 参考模型，TCP 是 4 层协定，WebSocekt 是 7 层协定，这些其实就是 OSI 参考模型里的层级概念。
OSI 参考模型里，数据从两个网络节点之间传递，是一个 U 型传递过程：发送端从上到下传递，每层须要在数据包中减少不同的协定头信息，以确保接收端同层能够解析；接收端从下往上传递，传递过程逐层剥离数据中的头信息，并将数据向上传递。
所以数据包从上到下的传递过程中，数据体积是一直加码的。同一段数据，间接通过 TCP 发送，流量耗费低于 WebSocket 协定。咱们看一下通过 WebSocket 协定传递数据的额定流量有哪些。
首先 WebSocket 数据传递的最小单元是数据帧。一段数据会被宰割组装为起码一个数据帧写入到 TCP 的缓冲区，如果数据比拟大，就会被分拆为多个数据帧，而后对端接管到之后再进行数据帧还原。
下图的二进制序列构造就是数据帧中的数据组成。
HTTP 是文本型协定，没有最小发送单元，或者说 HTTP 的报文数据的最小发送单元，就是 TCP 协定的最小发送单元。它不像 WebSocket 会将数据分装为 N 个数据帧，每个数据帧减少 WebSocket 头信息后再交给 TCP。它不被动宰割数据，只在数据首部减少首行和 Headers 信息，并最终把残缺报文信息写入 TCP 缓冲区，交由 TCP 去治理传输过程。
那么，HTTP 的传输效率是否就优于 WebSocket 呢？并不一定。
首先，一个 WebSocket 数据帧最多额定减少 2 – 14 个字节的头信息，然而 HTTP 协定自身的首行和 Headers 信息耗费的空间是远大于 14 字节的，这也是因为 HTTP 协定的个性导致的。它是文本型协定，一个字符起码须要一个字节的容量来存储。
其次，HTTP 协定的拓展，会额定减少报文 Headers 信息，这些信息也是字符型的，且是键值对模式。另外，HTTP 自身是短连贯，意味着服务在收到申请时首先要确认数据发送者的身份，所以报文数据中不可避免地在每次的申请中携带鉴权信息，然而长连贯协定是不须要这些额定开销的。
所以，WebSocket 的总体传输效率是优于 HTTP 的，除非待传输的数据大到了使 WebSocket 数据帧数量的头信息空间总和超过了 HTTP 报文头的水平，然而这种状况个别产生在文件上传等低频场景。大部分业务数据往来中，单次发送的数据都不会很大。
即时性
即时性是数据筹备实现，到被写入到 TCP 缓冲区可能经验哪些期待时长。
对于即时通讯场景，数据的上下行是同时在产生的，这也意味着 HTTP 的短个性很吃亏，因为上行数据会碰壁，服务器无奈通过短连贯的 HTTP 协定实现数据的被动推送。
这里咱们先遍及一下网络协议的一些根底概念，因为它跟咱们要去比拟的即时性是非亲非故。
第一类概念，是对于连贯持续性的形容。
长连贯，艰深点讲就是连贯在建设后是继续存在的，双端能够通过已存在的连贯互发数据，只有当一端被动终止连贯，连贯才会被敞开。TCP 和 WebSocket 都属于长连贯协定。（对于长连贯的更多分享，点此理解）
短连贯，是说当我须要与对端通信时建设连贯，通信结束后立刻敞开连贯。HTTP 就是一个短连贯协定。发动申请的时候建设连贯，收到响应之后连贯就会敞开。当然，也能够利用 KeepAlive 去放弃 TCP 连贯复用，不过它还是不能保障连贯不能被敞开。因为连贯的继续无效，长连贯的即时性是优于短连贯的。因为它防止了数据发送时要建设连贯的期待过程。
第二类概念，是对于字节流数据流向管制的定义。
全双工协定，是说字节流能够在连贯中双向自在流动，因为这种自在流动，所以这类协定的即时性是最好的，也通常是长连贯协定。只有缓冲区够大，就根本没有期待过程。TCP、WebSocket 都是属于全双工协定。
半双工协定，是说字节流能够在两个方向上流动，但同一时刻只能存在一个方向上的流动数据。半双工协定就像一条路上只有一个车道，对向有来车时，本方向的车就不能进车道，否则路就堵死了。HTTP 协定就是一个典型的半双工协定，它实际上是容许数据双向流动的，然而它的响应必须在申请数据接管实现之后，同一时刻不存在双向流动的字节流。半双工协定的即时性要低于全双工，因为它有对连贯的应用期待过程，当有对向的数据流时，数据要提早发送。
单工协定，就是数据只能单向流动，比方 HTTP 协定中的 SSE 性能。因为单工协定不能独立实现双向数据流动，不合乎即时通讯的需要，所以咱们就不思考了。归类来看，WebScoekt 和 TCP 的即时性根本属于同一级别的，HTTP 则比他们要弱。
当然，HTTP 独自拎进去一个申请是不能和长连贯协定比的，咱们还要看一下通过 HTTP 协定的并发多连贯申请能不能补救它本身的有余。这里，咱们再深入分析一下基于 HTTP 协定的长连贯模仿计划。咱们先想一下，基于 HTTP 协定构建的解决方案，要解决的外围问题是什么？
第一点，客户端发送数据时，期待连贯建设造成的发送提早。因为 HTTP 的短连贯性质，所以在上行数据传输过程中，须要等 TCP 连贯建设能力发送 HTTP 报文。针对这一点，就 HTTP 协定来说，目前是没有解决方案的，HTTP 的 KeepAlive 个性能够缓解，但不能彻底解决。
第二点，服务器数据无奈被动推送到端造成的上行数据提早。这也是 HTTP 的短连贯个性造成的。当服务器有上行数据时，并没有一个继续的无效连贯可能让它把数据推下去，所以只能期待客户端来被动建设连贯，顺道把上行数据带上来。咱们要介绍的计划就是围绕解决第二点开展的。市面上比拟风行的前端基于 HTTP 协定构建的解决方案，次要有三种。
Comet 局部缓解了上行提早问题。
HTTP + SSE 计划与 Comet 相似，只是把上行通道从 HTTP 申请变成了 SSE 实现。
SSE 的个性是长连贯、单工协定，它的整体成果优于 Comet，因为没有额定的连贯等待时间。它作为上行数据的通道，单工协定也齐全符合要求。能够说 HTTP + SSE 的上行即时性根本是与 WebSocekt 等同的，根本解决了上行提早问题。
Long-Pulling，定时向服务器去发送申请，以此来把上行数据带回来，根本属于惯例操作，两个外围问题，根本一个也没有解决。总结而言，HTTP + SSE > Comet > Long-Pulling
这个论断有一个前提，是抛开了兼容性的。
SSE 计划虽好，但仅限于浏览器，如果咱们想把 JS 代码复用到其余环境比方小程序，该计划就无奈实现了。目前各小程序 Runtime 对于 SSE 的反对简直是 0。
安全性
咱们看一下 OSI 参考模型，着重看一下应用层和传输层之间的局部，这里是 SSL/TLS 所处的地位，也就是咱们常说的 HTTPS 中的那个 S。
OSI 模型中定义中，会话层负责两端的会话维持、身份甄别等，表示层负责对数据的加解密。在此之上，应用层协定的安全性是等同的，HTTPS 和 WSS 协定就是平安版的 HTTP 和 WebSocket 协定。
TCP 是比 SSL/TLS 更底层的协定，所以间接经由 TCP 发送的数据是能够有更多的平安抉择的，TLS 只是备选项之一。应用 HTTPS 或 WSS 协定时，由 Runtime 提供 TLS/SSL 反对，开发者无需关注数据传输过程中的平安问题。应用 TCP 协定时，须要由开发者自行保障数据传输过程中的安全性（对接 TLS/SSL 或其余自定义平安计划）。
数据传输协定计划 & 前端长久化存储
数据传输协定计划
咱们通过 信息密度、拓展性、安全性、多端统一、兼容性 五个指标来做比照数据传输协定。除了咱们并不举荐的自研计划，罕用的数据传输协定有两种：Protocol Buffer（PB），TLV 格局二进制数据；JSON，纯文本键值对数据。
五个指标比照来看，信息密度指 A 向 B 传播信息须要耗费的流量，密度越高，耗费得越少，PB 的信息密度比 JSON 高。
传输构造上，PB 是一个 TLV 格局二进制数据序列，JSON 是纯字符串系列键值对，JSON 形容数据结构要远大于 PB 形容数据结构。
安全性与可读性相同，咱们要 读一个二进制的 PB 数据，须要晓得它序列化过程中的 PB 数据定义的构造。 咱们常说的 PB 文件定义的可读性文件，这是前后端的一个约定，基于这个文件咱们能力去序列化和反序列化这个二进制数据。而 JSON 是纯字符串，可读性良好，能够比拟直观去理解数据里的信息。
兼容性 方面，JSON 有很多原生语言库可选，PB 的兼容性在前端来看也就是 JS 对 ArrayBuffer 的反对，目前也都是反对的。
拓展性 上，单方是等同的，PB 有一个长处，因为他传输的数据不蕴含键信息，所以两端的键信息能够不同。JSON 的传输信息蕴含键信息，意味着键信息是不能够随便变更的。
多端统一与兼容性统一 ，即时通讯场景波及很多平台，多端就要去对数据做多端传输，数据的序列化和反序列化的实现的过程要保持一致，PB 跟 JSON 这方面都比拟好，JSON 是原生反对的，PB 能够应用 Google 提供的相应三方库。 总之，PB 比 JSON 更优。
前端长久化存储比照
最初是前端的可长久化存储技术：LocalStorage、IndexDB 和 Sqlite。长久化存储自身可选计划不多，须要思考 容量、兼容性、数据一致性 等方面。
- LocalStorage，最罕用的计划，容量比拟低
- IndexDB，浏览器器上惟一可用的长久化大容量存储计划
- Sqlite – Electron Only，罕用前端数据库
- Sqlite – WebAssembly，研发老本比拟高
除了 LocalStorage，其余三种容量相当。
就 数据一致性 而言，除了 Electron 主过程内应用 Sqlite，其余三种计划都不太好解决数据竞争问题，很难保证数据一致性。在 Electron 平台下，把数据库操作放到主过程去实现，当渲染过程须要操控本地数据库时，依赖 IPC 去跟主过程通信，由主过程去解决实在的数据库事务。主过程是惟一一个数据库的拜访点，因而能够妥善实现对数据竞争和数据一致性的保障。
融云的落地实际分享
通过三大项的计划比照，融云在落地的时候依照后面所分享的准则，在可用的计划下尽可能抉择最优解，比方，Electron 平台上最优解就是 TCP+Sqlite，数据封装用 PB。
Web 平台上没有 TCP+Sqlite 可用，就用 WebSocket 作为解决方案，把 HTTP 作为次优解做相应的技术落地。
小程序上，PB、WebSocket 都用不了，则采纳 HTTP 计划备选，选型用的是 Comet。
这个降级过程对于集成的开发者来说是无感的，但在业务落地过程中是须要关注的，比方音讯查问，有没有数据库就是两种利用体验。
