共计 6901 个字符，预计需要花费 18 分钟才能阅读完成。
作者 | 百度音讯中台团队
导读
在过来的十年里，挪动端技术飞速发展，挪动利用逐步成为次要的便捷拜访和应用互联网的形式，承接了越来越多的业务和性能，这也意味着对挪动端和服务器之间的通信效率和稳定性提出了更高的要求。为了实现更高效的实时通信和数据同步，长连贯逐步成为一种关键技术，通过维持客户端和服务器之间的长久连贯，实现了单方实时数据交换，防止了频繁的建连和断连开销，从而进步用户体验、服务稳定性、可靠性等方面的体现。
本文旨在探讨长连贯技术在挪动端的实际，针对百度 iOS 端在建设长连贯过程中的技术选型和整体架构逻辑将做重点开展。同时联合 IM 即时通讯案例的介绍和剖析，展现长连贯是如何在挪动应用领域为相似业务场景提供解决方案的。
本文将分为五个次要局部。首先，对长连贯技术进行概述，包含定义、与短连贯的比照以及在挪动互联网畛域的常见利用。接下来，会简略介绍百度长连贯服务，包含搭建的背景以及建成后提供的服务外围主流程。而后，将重点探讨百度 iOS 端长连贯 SDK 搭建过程中的挑战和解决方案，蕴含协定的抉择、DNS 解析优化、长连贯保活机制的设计等。紧接着，以 IM 即时通讯场景中的长连贯实际为例，展现了长连贯 SDK 是如何为业务实现申请数据转发、接管服务器被动推送等性能的。最初，对本文的次要内容做了总结，以及对长连贯在挪动端利用中将来的发展趋势和前景进行了瞻望。
全文 7193 字，预计浏览工夫 18 分钟。
01 长连贯简介
1.1 意识长连贯
长连贯，指在一个连贯上能够间断发送多个数据包，在连贯放弃期间，如果没有数据包发送，须要单方发链路检测包。
1.2 长连贯与短连贯比照
1.3 长连贯在挪动互联网畛域的利用
长连贯在挪动互联网畛域有宽泛的利用，特地是在实现实时通信和音讯推送等性能方面施展了关键作用。例如，常见的微信、QQ 这样的即时通信软件，就是通过维持客户端和服务器的长连贯，实现即时传输信息的需要。又如一些网络游戏、定位服务、新闻推送等，也会应用长连贯，实时推送新的动静或者音讯给用户。这样，无论用户在何时何地，只有连贯到互联网，就可能接管到最新的信息，极大地晋升了使用者的体验度并且使得挪动互联网更加便捷。
总的来说，对实时性、数据传输效率、频繁通信等有强需要的利用，长连贯都是一个好的抉择。
02 百度长连贯服务简介
2.1 搭建对立长连贯的背景
此前，百度挪动端都是由各业务自运维的长连贯，往往搭建和保护老本都偏高，且可复用性不大，因而打算实现一套高并发、低时延、高触达的对立长连贯组件，可能更灵便高效地反对各业务接入，可能对百度系的各 APP 独立输入长连贯服务满足各业务的诉求，从而晋升服务质量，升高资源老本。
2.2 长连贯服务主流程图
百度长连贯服务蕴含客户端的长连贯 SDK 和服务端的长连贯接入层两个局部，长连贯接入层又蕴含访问控制模块和接入模块，负责保护长连贯治理及业务数据转发。下图形容了长连贯建连及心跳保活过程，业务登录和登录后推送过程，以及最终长连贯 SDK 触发断连的过程。后文将针对 iOS 端长连贯 SDK 的具体实现解决方案，和长连贯 SDK 在百度 APP 中的业务利用落地进行更为具体的探讨。
03 百度 iOS 端搭建长连贯 SDK 的解决方案
3.1 客户端搭建长连贯的挑战点概述
客户端从 0 到 1 搭建一套残缺的长连贯 SDK，这个过程波及到多个技术点的思考，包含但不限于：连贯的创立和保护，网络协议的抉择，应用加密传输、验证数据起源等形式保障长连贯的安全性，通过数据传输格局抉择、数据压缩等形式缩小数据量进步传输效率，谬误异样解决机制等，须要开发者依据理论状况进行最优实现计划的抉择。在这之中，最外围的能够拆解为以下两个局部：
1、连贯的创立：残缺建连流程的设计，网络协议的抉择，设计时须要思考长连贯建连的成功率、时延等外围指标；
2、连贯的保护：保障建连胜利是第一步，长连贯还须要放弃保护单方连贯才可达成继续通信的目标，这包含：在长时间无数据交互的状况下，须要定期发送心跳包进行连贯的保活，以及长连贯连贯断开后须要及时进行断线重连复原连贯在线状态。
3.2 外围逻辑一：连贯的创立
长连贯建连即客户端与服务器建设连贯，是长连贯 SDK 要做的第一件事，所有业务方数据的传输（上下行）都要基于长连贯建连胜利的这个前提。长连贯建连并不是一个繁多简略的操作，而是一个分阶段进行的过程。本大节将次要探讨在设计开发长连贯建连模块之前，须要重点思考确认的几个技术点和实现计划，以及百度 iOS 端长连贯 SDK 最终实现的长连贯建连残缺过程的架构。
3.2.1 挑战①：协定的抉择
问题点：UDP 还是 TCP
对于网络编程这个话题，应用哪种数据传输层协定来实现通信是一个十分根底但始终争论不休的问题。UDP 和 TCP 各有各的利用场景，TCP 能提供牢靠的数据传输，UDP 则有更高的传输效率，此处不再赘述 TCP 与 UDP 的区别，最终抉择哪种协定实现，是一个见仁见智的问题，需联合整体利用场景、开发代价、部署和经营老本等方面综合思考。
解决方案：TCP 为主，同时小流量摸索 QUIC 的后劲
百度 iOS 端长连贯 SDK 中现有两套数据传输计划：
计划一 ：在长连贯 SDK 建设初期，依据业内成熟技术计划选型的调研后果，及开发成本、保护便捷性的思考，第一个计划是参考 CocoaAsyncSocket 框架改写的，基于 Socket 原生开发，应用 TCP 协定，反对 TLS/SSL 平安传输，并且是线程平安的，该计划较为成熟，应用便捷，建连成功率较高。目前百度 APP iOS 端中 90% 的用户流量都是走的该计划实现的长连贯逻辑。
计划二 ：个别稳固网络传输都是通过 TCP，但在网络基建自身曾经越来越欠缺的状况下，TCP 一些设计自身的问题便裸露了进去，加之 TCP 是在操作内核和两头固件中实现的，因而对 TCP 进行重大更改简直是很难的事件，相似建连过程握手耗时长、队头阻塞等问题没有失去很好地解决，让咱们开始思考一些新的可能性。长连贯 SDK 后续引入了基于 QUIC 协定实现的第二套计划。QUIC 协定是建设在 UDP 之上，并且实现了牢靠传输，相比 HTTP2+TCP+TLS 协定，QUIC 具备不少长处：缩小了 TCP 三次握手及 TLS 握手工夫，改良了拥塞管制，并且没有队头阻塞的多路复用，反对连贯迁徙等。百度 iOS 长连贯 SDK 目前通过 NWConnection 引入了 QUIC 协定的实现。QUIC 的协定尽管比拟先进，但这也意味着在工程实现方面有更多可优化的空间，目前计划二还处于小流量试验阶段，仍有很多优化工作有待后续进一步去落地。就以后放量所失去的数据来看，在长连贯建连成功率及时延指标上，QUIC 实现计划都有较好的体现。
3.2.2 挑战②：DNS 解析优化
问题点：国内挪动端网络所面临的 DNS 疑难杂症
国内各 ISP 运营商的 LocalDNS 因为域名缓存、解析转发、LocalDNS 递归进口 NAT 的起因，容易引起 DNS 被劫持造成服务不可用、DNS 调度不精确导致性能进化等问题。DNS 解析的效率和准确性，间接影响长连贯建连的品质，进而影响公司的业务。
解决方案：HTTPDNS
因而在百度 iOS 端长连贯 SDK 中，采纳以后业界比拟支流的解决方案：HTTPDNS，来代替 LocalDNS 解析。HTTPDNS 是利用 HTTP 协定与 DNS 服务器进行交互，绕开了运营商的 LocalDNS 服务，无效避免了域名劫持，进步域名解析效率。
3.2.3 残缺解决方案：百度 iOS 端长连贯建连整体流程
建连机会
在百度 APP 中，对立保护了一系列零碎事件和生命周期供各个组件监听。iOS 长连贯 SDK 依据百度 APP 的业务个性，抉择在环境搭建实现事件后触发长连贯建连，即期待 APP 启动必要数据比方首页资源等加载实现后，开始触发长连贯建连。
建连残缺过程
下图展现了长连贯 SDK 建连的四个过程：
获取 Token：
- 获取 Token 的意义：广义上 Token 指的是长连贯访问控制模块返回的 access-token，后续随长连贯登录申请上行到长连贯接入层，由接入层向长连贯访问控制模块进行鉴权用。狭义上随此次 Token 申请下发的，还有传输协定及拜访点等数据，包含但不限于：长连贯协定应用 QUIC 还是 TCP，是否优先 ipv6，连贯域名和端口，日志打点小流量开关等。
- 获取 Token 的机制：获取 Token 优先走本地缓存，当本地缓存无无效数据时，才收回网络申请，该申请是基于 NSURLSession 实现的短连贯申请；Token 在服务端和客户端均有缓存，存在过期工夫，若 Token 过期，会在下图中阶段四通过长连贯登录申请失败体现，这时会清空本地 Token 缓存并触发从新建连。
DNS 域名解析 ：如前所述，长连贯 SDK 中应用 HTTPDNS 代替 LocalDNS 来避免 DNS 劫持、进步解析效率。同时在 iOS Release 环境下，为进步 DNS 解析效率，本地建设了缓存机制，HTTPDNS 解析后果返回后会更新本地缓存，下次建连过程优先取缓存，缓存不非法才走网络申请。
建设 Socket 连贯 ：Socket 建连过程波及到传输协定的抉择，依据后面介绍，iOS 长连贯 SDK 目前是通过小流量试验的形式，10% 的用户走 QUIC 建连，90% 的用户走 TCP 建连。
长连贯登录申请 ：携带 Token 中获取的 access-token 上行申请实现鉴权，长连贯登录申请返回胜利意味着整个建连过程实现，业务层可开始失常应用长连贯进行通信，若登录返回报错，则会触发重连。
顺利完成这四个阶段后，长连贯会在该链路上继续发送心跳包进行连贯保活，在异样断连或压后盾等触发的被动断连之前，始终放弃连贯在线状态，为各个业务的数据传输提供通路。
3.3 外围逻辑二：连贯的保护
3.3.1 保护连贯的意义
上个大节介绍了长连贯连贯建设的全过程，长连贯建连胜利后，理论已处于可用状态，即各业务基于长连贯的通信曾经能够失常进行。但在此之后，放弃长连贯的可用性也是十分重要的。如果长连贯无奈很好地放弃，在连贯曾经生效的状况下服务端持续推送上行告诉而端却收不到，造成资源的节约，同时无奈及时从新建连，对业务造成损失。
3.3.2 保护长连贯的解决方案
针对可能导致长连贯断开的几种次要起因，长连贯 SDK 建设了对应的机制来保障连贯的稳定性，可总结为两点：心跳保活和断线重连。
解决方案①：心跳保活
心跳保活的定义 ：实现长连贯保活的形式通常是采纳应用层心跳，通过心跳包的超时或报错等来执行重连操作。心跳个别是指某端（通常是客户端）每隔肯定工夫向另一端（通常是服务端）发送自定义指令，以判断单方是否存活，因其依照肯定距离发送，相似于心跳，故被称为心跳保活。
百度 iOS 端长连贯 SDK 心跳保活机制 ：长连贯登陆申请胜利后，解析返回数据，若服务端下发了心跳包的间隔时间，则以服务端下发的工夫距离继续发送心跳包进行连贯保活，若没有下发心跳包间隔时间，客户端会默认 60s 间隔时间来触发心跳包的发送。具体心跳保活过程见下图。
解决方案②：断线重连
断线重连原理 ：在长连贯可能被断开的场景（压后盾重进 APP、网络状态变更等），检测长连贯的可用状态，监测到连贯不可用时，及时触发重连机制。
百度 iOS 端长连贯 SDK 断线重连机制 ：具体触发断线重连的机会见下图，iOS 长连贯 SDK 外部保护有串行队列和对立的长连贯状态监测记录，不会导致反复建连的产生。
04 长连贯在百度 APP 中的利用与实际
4.1 长连贯在百度 APP 中的业务落地
长连贯是客户端到服务端的一种全双工连贯，建连实现后，能够为业务方提供申请转发、服务端被动推送等服务。在百度 APP 中，包含在线衰弱诊疗、高考意愿填报征询、情感心理辅导等一系列实时咨询服务，发送直播弹幕、退出某大 V 粉丝群聊天、私信好友等多种用户实时沟通场景的落地，以及实现用户在线状况下云端可及时被动下发配置管制端的根底能力建设，都离不开长连贯的反对。长连贯为各个业务与本人服务端的数据交互提供了稳固便捷的形式和渠道。
下图为百度 APP 中长连贯与落地业务的构造示意图。残缺的长连贯模块包含了客户端的长连贯 SDK 和服务端的长连贯接入层两个局部，作为各个业务与本人服务端数据交换的两头渠道，解决了包含连贯建设与保活、实现各业务客户端与本人服务端的数据双向互发等逻辑。上面将重点关注长连贯在 IMSDK 实时聊天通信场景中的实际。
4.2 长连贯在 IM 即时通讯场景中的实际
4.2.1 背景介绍
IMSDK，即百度音讯中台为百度 APP 及百度系其余产品打造的具备利用内即时通讯能力的客户端 SDK，包含多种用户沟通场景：私聊、群聊、聊天室、直播弹幕等，并帮忙业务推送音讯告诉触达用户，建设 B 端和 C 端的沟通渠道。目前主性能诸如拉取会话列表、拉取音讯、发送音讯、音讯已读等均为长连贯实现。本大节将通过介绍用户发送音讯、用户收到新音讯告诉这两个 IM 及时通信中的常见场景，展现长连贯提供的数据转发和服务器被动推送能力是如何在业务场景落地的。
4.2.2 实际 1：实时聊天场景下用户发送音讯
实际场景
实时聊天场景下，用户在聊天框向本人好友发送一条音讯，音讯如果发送失败了，利用通常会在本条音讯气泡旁展现一个红叹号，这个利用场景对于互联网用户应该都十分相熟。从技术角度看，实质上是业务客户端向本人的服务器上行一个申请，服务器再将申请后果返回给客户端。这是一个典型的须要频繁点到点通信的场景，非常适合基于长连贯来实现。长连贯 SDK 对外提供了封装好的长连贯申请类，内部业务方诸如 IMSDK 在上行长连贯申请时通过创立该类的实例，将上行所需参数和数据赋值给申请实例，并设置回调闭包用于接管和解决申请回执数据和后果，最初将申请收回。业务不须要思考数据传输及转发等逻辑，长连贯会充当业务客户端和服务器之间的通路，黑盒解决这个过程。
技术难点
对于长连贯 SDK 而言，在这条通路上最重要也是比较复杂的逻辑点在于，各个业务方的上行申请和上行告诉都是并发进行的，长连贯 SDK 如何有序地治理数据流向。上行申请即写流，接管上行数据即读流，上面就读写流的治理，与申请同回执数据的匹配问题的解决方案作简要的介绍。
技术实现
长连贯 SDK 内就读写数据保护有两个队列：读队列和写队列，以及保护了一个缓存池用作申请实例和申请回执数据的匹配。业务方上行一个长连贯申请，实际上是将申请工作增加到写队列中，如果此时处于可写流状态，还会触发写流。当 socket 建连胜利当前，会取出写队列队头的工作，开始写流，写流结束会查看写队列是否为空，不为空持续取队头工作执行，直至写队列为空为止。同时 socket 建连胜利还会增加一次读工作到读队列中，并查看如果此时处于可读状态，便取出队头第一个读工作，开始读流，读流胜利后会持续增加一个读工作到读队列，循环读流操作。
读流失去的服务端上行返回数据，通过 serviceId（业务编号）+ methodId（长连贯申请办法编号）+ 申请发动的工夫戳组成惟一键值，去缓存区匹配到上行返回数据对应的申请体，通过回调的形式，将申请后果返回到调用方。该申请一旦被回调过一次，其实例将从缓存区被删除，及时开释缓存区内存，并且保障一次申请不会产生屡次回调的状况。
4.2.3 实际 2：实时聊天场景下用户收到新音讯告诉
实际场景
实时聊天场景下，用户是如何收到别的用户发送给他的新音讯告诉的呢？其实是依附服务器的上行告诉到客户端。长连贯不仅提供为业务客户端转发上行申请的能力，还提供了服务端被动推送的服务。比方在 IM 业务中，依附 IM 服务器上行新音讯告诉，来实现音讯的实时接管和拉取。这些告诉又是如何达到 IMSDK 的呢？其实它与上一大节 IMSDK 上行长连贯申请的过程相似。
技术实现
在 IMSDK 的长连贯治理类初始化阶段，会对须要接管的上行告诉办法进行注册，这里的注册实际上指的就是上行多个长连贯申请，每个申请有对应的 serviceID（业务编号）和 methodID（须要注册的告诉办法号码）。跟上一大节长连贯申请不同的点在于，这些申请在收到回执数据后不会从长连贯 SDK 申请缓存区里移除，而是会长期存在，只有读流时读到了对应 methodID 的数据，就能在申请缓存区找到对应申请，将上行数据传到 IMSDK 了。这样一来，只有长连贯在线，业务方就能实时接管到其服务器上行的告诉音讯了。
05 结语
长连贯服务的外围大抵可分为：建连过程、连贯维持过程以及数据传输过程。本文给出了搭建长连贯服务过程中面临的一些挑战和解决方案，并联合长连接功能在百度 APP 即时通讯场景下的实际，简要介绍了百度 iOS 端长连贯 SDK 的整体架构。
在挪动端，长连贯技术的利用前景非常广阔。随着 5G 和 6G 等高速移动网络的倒退，将使得挪动应用程序可能更加高效地应用长连贯技术，从而实现更加实时和高效的数据交换。这也为对实时数据交换有强需要的利用场景提供了更广大的设想空间，诸如物联网、智能家居、虚拟现实和加强事实等技术，长连贯都将在其中施展更加重要的作用。
——END——
举荐浏览：
百度 App 启动性能优化实际篇
扫光动效在挪动端利用实际
Android SDK 平安加固问题与剖析
搜寻语义模型的大规模量化实际
如何设计一个高效的分布式日志服务平台
视频与图片检索中的多模态语义匹配模型：原理、启发、利用与瞻望