百度App网络深度优化：DNS 和连接优化

b1gc8v

作者｜蔡锐（百度 App 资深工程师） 编辑｜覃云 网络优化是客户端几大技术方向中公认的一个深度行业，百度 App 亦不例外，今天，咱们在这儿向大众介绍百度 App 网络深度优化的实践经验，内容重点包含 DNS 优化和连接优化，期盼对大众在网络方向的学习和实践有所帮忙。 1、DNS 优化

百度起家于搜索，全部机构的网络架构和安排都是基于标准的 internet 协议，日前已然是全栈 HTTPS，来到移动互联网时代后，总的基本架构不变，但在客户端上必须做非常多优化工作。

DNS（Domain Name System），它的功效是按照域名查出 IP 位置，它是 HTTP 协议的前提，仅有将域名正确的解析成 IP 位置后，后面的 HTTP 流程才可进行，因此通常做网络优化会首选优化 DNS。

1. 背景

DNS 优化核心必须处理的问题有两点：

【1】因为 DNS 劫持或故障导致的服务不可用，从而影响用户体验，影响机构的收入。

【2】因为 DNS 调度不准确引起的性能退化，从而影响用户体验。

百度 App 承载着亿级流量，每年都会遇到运营商 DNS 劫持或运营商 DNS 故障，整体影响非常欠好，因此 DNS 优化刻不容缓，经过下图会更直观的认识运营商劫持或故障的原理。

运营商劫持或故障的原理 2.HTTPDNS

既然咱们面临这么严峻的问题，那样咱们怎样优化 DNS 呢？答案便是 HTTPDNS。

大部分标准 DNS 都是基于 UDP 与 DNS 服务器交互的，HTTPDNS 则是利用 HTTP 协议与 DNS 服务器交互，绕开了运营商的 Local DNS 服务，有效防止了域名劫持，加强域名解析效率，下图是 HTTPDNS 的原理。

HTTPDNS 原理

百度 App HTTPDNS 端上的实现是基于百度 SYS 团队的 HTTPDNS 服务，下图介绍了 HTTPDNS 的服务端安排结构。

HTTPDNS 安排结构

HTTPDNS 服务是基于 BGP 接入的，BGP 英文 Border Gateway Protocol，即边界网关协议，是一种在自治系统之间动态的交换路由信息的路由协议，BGP 可以按照当前用户的运营商路由到百度服务点的对应集群上，针对第三方域名，服务点会经过百度安排在运营商的 CDN 节点向其他域名权威 DNS 发起查找，查找这个运营商下域名的最优 IP。

百度 App 独立实现了端的 HTTPDNS SDK，下图介绍了端 HTTPDNS 的整体架构。

端 HTTPDNS 的整体架构 DNS 接口层

DNS 接口层处理的问题是屏蔽底层的细节，对外供给简单整洁的 API，降低运用者的上手成本，加强研发效率。

DNS 策略层

DNS 策略层经过多种策略的组合，使 HTTPDNS 服务在性能，稳定性，可用性上均保持较高的水准，下面讲解下每一个策略设计的初衷和详细实现。

容灾策略

这是一个非常关键的策略，重点处理 HTTPDNS 服务可用性的问题，实践证明，这个策略帮忙百度 App 在反常状况下挽救回非常多流量。

【1】当 HTTPDNS 服务不可用并且本地亦无缓存或缓存失效的时候，会触发降级策略，降级成运营商的 localDNS 方法，虽然存在运营商事故或劫持的危害，但保证了 DNS 服务的可用性。

【2】当 HTTPDNS 服务和 localDNS 服务双双不可用的状况下，会触发 backup 策略，运用端上的 backup IP。

什么是 backup IP？backup IP 是多组按照域名归类的 IP 列表，可云端动态更新，方便后续运维朋友调节服务端的节点 IP，不是所有域名都有对应的 backup IP 列表，日前百度 App 只能保准核心域名的可用性。

既然是一组 IP，便有选择问题，backup IP 选择机制是怎么样的呢？咱们的中心思想便是要在端上利用最小的代价，并且思虑服务端的负载平衡，得到相对正确或恰当的选择结果。经过运营商和地理信息，能够选取一个相对较优的 IP，但获取地理信息必须很大耗时，外加频次很高，代价很大，因此咱们选取了 RR 算法来代替上面的办法（RR 算法是 Round-Robin，轮询调度），这般客户端的代价降低到最小，服务端亦实现了负载平衡。

安全策略

【1】HTTPDNS 处理的核心问题便是安全，标准的 DNS 查找大部分是基于 UDP 的，但亦有基于 TCP 的，倘若 UDP 被封禁，就必须运用 TCP。不管是 UDP 还是 TCP，安全性都是无保证的，HTTPDNS 查找是基于标准的 HTTP 协议，为了保准安全咱们会在 HTTP 上加一层 TLS（安全传输层协议），这便是 HTTPS。

【2】处理了传输层协议的安全性后，咱们要处理下域名解析的问题，上面咱们说到 HTTPDNS 服务是基于 BGP 接入的，在端上采用 VIP 方式请求 HTTPDNS 数据（VIP 即 Virtual IP，VIP 并无与某设备存在必定的绑定关系，会跟随主备切换之类的状况出现而变换，VIP 供给的服务是对应到某一台或若干台服务器的），既然请求原始数据必须运用 IP 直连的方式，那样就摆脱了运营商 localDNS 的解析限制，这般即使运营商显现了故障或被劫持，都不会影响百度 App 的可用性。

任务调度策略

HTTPDNS 服务供给了两类 HTTP 接口，用于请求最优域名结果。第1种是多域名接口，针对区别的制品线，下发制品线配置的域名，第二种是单域名接口，只返回你要查找的那个域名结果，这般的设计和标准的 DNS 查找基本是同样的，只不外是从 UDP 协议变成为了 HTTP 协议。

【1】多域名接口会在 App 冷起步和网络切换的时候请求一次，目的是在 App 的网络环境初始化或变化的时候预先获取域名结果，这般亦会减少单域名接口的请求次数。

【2】单域名接口会在本地 cache 过期后，由用户的操作触发网络请求，从而做一次单域名请求，用户这次操作的 DNS 结果会降级成 localDNS 的结果，但在无过期的状况下，下次会返回 HTTPDNS 的结果。

IP 选择策略

IP 选择策略处理的核心问题是最优 IP 的选择，避免由于接入点的选择错误导致的跨运营商耗时。HTTPDNS 服务会将最优 IP 根据次序下发，客户端默认选择第1个，这儿无做客户端的连通性校验的原由，重点还是担心端上的性能问题，不外有容灾策略兜底，综合评定还是能够接受的。

缓存策略

大众针对 DNS 缓存并不陌生，它重点是为了提高拜访效率，操作系统，网络库等都会做 DNS 缓存。

DNS 缓存中一个要紧的概念便是 TTL（Time-To-Live），在 localDNS 中针对区别的域名，TTL 的时间是不同样的，在 HTTPDNS 中这个值由服务端动态下发，百度 App 日前所有的域名 TTL 的配置是 5 分钟，过期后倘若无新的 IP 将继续沿用老的 IP，当然亦能够选取不沿用老的 IP，而降级成 localDNS 的 IP，那样这就取决于 localDNS 针对过期 IP 的处理。

命中率策略

倘若 HTTPDNS 的命中率是 100%，在保准 HTTPDNS 服务稳定有效的前提下，咱们就能够做到防劫持，提高精细调度的能力。

【1】为了提升 HTTPDNS 的命中率，咱们选取运用多域名接口，在冷起步和网络切换的时候，批量拉取域名结果并缓存在本地，便于接下来的请求运用。

【2】为了再一次提高 HTTPDNS 的命中率，当用户操作触发网络请求，获取域名对应的 IP 时，会提前进行本地过期时间判断，时间是 60s，倘若过期，会发起单域名的请求并缓存起来，这般会连续延长域名结果的过期时间。本地过期时间与上面说到的 TTL 是客户端和服务端的双重过期时间，目的是在反常状况下能够双重保准过期时间的准确性。

基本能力层

基本能力层重点供给给 DNS 策略层所必须的基本能力，包含 IPv4/IPv6 协议栈探测的能力，数据传输的能力，缓存实现的能力，下面将讲解每种能力的详细实现

IPv4/IPv6 协议栈探测

百度 App 的 IPv6 改造正在如火如荼的进行中，端上在 HTTPDNS 的 IP 选择上怎样晓得日前属于哪个协议栈作为关键性问题，并且这种判断需求性能极高，由于 IP 选择的频次实在是太高了。

咱们选择的方法是 UDP Connect，那样何为 UDP Connect？大众都晓得 TCP 是面向连接的，传输数据前客户端都要调用 connect 办法经过三次握手创立连接，UDP 是面向没连接的，没需创立连接便能收发数据，然则倘若咱们调用了 UDP 的 connect 办法会出现什么呢？当咱们调用 UDP 的 connect 办法时，系统会检测其端口是不是可用，位置是不是正确，而后记录对端的 IP 位置和端口号，返回给调用者，因此 UDP Connect 不会像 TCP Connect 发起三次握手，出现网络真实损耗，UDP 客户端仅有调用 send 或 sendto 办法后才会真正发起真实网络损耗。

UDP Connect 原理

有了 UDP Connect 的基本保证，咱们在上层做了缓存机制，用来减少系统调用的损耗，机会上日前仅在冷起步和网络切换会触发探测，在同一种网络制式下探测一次基本能够保证当前网络是 IPv4 栈还是 IPv6 栈。

日前百度 App 客户端针对 IPv4/IPv6 双栈的策略是保守的，仅在 IPv6-only 的状况下运用 v6 的 IP，其余运用的都是 v4 的 IP，双栈下的方法后续必须优化，业内日前标准的做法是 happy eyeball 算法，什么叫 happy eyeball 呢？便是不会由于 IPv4 或 IPv6 的故障问题，引起用户的眼球始终在等待加载或出错，这便是 happy eyeball 名字的由来。

happy eyeball 有 v1 版本 RFC6555 和 v2 版本 RFC8305，前者是 Cisco 提出来的，后者是苹果提出来的。happy eyeball 处理的核心问题是，繁杂环境下 v4 和 v6 IP 选择的问题，它是一套整体处理方法，针对域名查找的处理，位置的排序，连接的尝试等方面均做出了规定，感兴趣的朋友能够查看：

https://tools.ietf.org/html/rfc6555

https://tools.ietf.org/html/rfc8305

2. 数据传输

数据传输重点供给网络请求的能力和数据解析的能力。

【1】网络请求失败重试的机制，获取 HTTPDNS 结果的成功率会大大影响 HTTPDNS 的命中率，因此客户端会有一个三次重试的机制，保证成功率。

【2】数据解析反常的机制，倘若获取的 HTTPDNS 的结果存在反常，将不会覆盖端上的缓存。

3. 缓存实现

缓存的实现基本能够分为磁盘缓存和内存缓存，针对 HTTPDNS 的缓存场景，咱们是选其一还是都选取呢？百度 App 选取的是内存缓存，目的是防止咱们自己的服务显现问题，运维朋友在紧急状况下切换流量，倘若做了磁盘缓存，会引起百度 App 在重启后亦可能不可用，但这种问题会引起 APP 在冷起步时期，HTTPDNS 结果未返回前，还是存在故障或劫持的危害，综合评定来看能够接受，倘若显现这种极端状况，影响的是冷起步周期的有些请求，但只要 HTTPDNS 结果返回后便会恢复正常。

3.HTTPDNS 的最佳实践

百度 App 日前客户端网络架构因为历史原由还未统一，不外咱们正朝着这个目的奋斗，下面着重介绍下 HTTPDNS 在 Android 和 iOS 网络架构中的位置及实践。

HTTPDNS 在 Android 网络架构的位置及实践百度 App 的 Android 网络流量都在 okhttp 之上，上层进行了网络门面的封装，封装内部的实现细节和对外友好的 API，供各个业务和基本模块运用，在 okhttp 上咱们扩展了 DNS 模块，运用 HTTPDNS 替换了原有的系统 DNS。

HTTPDNS 在 Android 网络架构的位置 HTTPDNS 在 iOS 网络架构的位置及实践

百度 App 的 iOS 网络流量都在 cronet（chromium 的 net 模块）之上，上层咱们运用 AOP 的方式将 cronet stack 注入进 URLSession 里，这般咱们就能够直接运用 URLSession 的 API 进行网络的操作况且更易于系统守护，在上层封装了网络门面，供各个业务和基本模块运用，在 cronet 内部咱们修改了 DNS 模块，除了原有的系统 DNS 规律外，还添加了 HTTPDNS 的规律。

iOS 上还有一部分流量是在原生 URLSession 上，重点是有些第三方业务无运用 cronet 但还想单独运用 HTTPDNS 的能力，因此就有了下面的 HTTPDNS 封装层，办法是在上层直接将域名替换成 IP，域名针对底层非常多机制是至关要紧的，例如 https 校验，cookie，重定向，SNI（Server Name Indication）等，因此将域名修改成为了 IP 直连后，咱们又处理了以上三种状况，保准请求的可用性。

HTTPDNS 在 iOS 网络架构的位置 4. 收益

DNS 优化的收益重点有两点，一是防止 DNS 的劫持（在出问题时显出尤为要紧），降低网络时延（在调度不准确的状况下，会增大网络的时延，降低用户的体验），这两点收益必须结合业务来讲，以百度 App Feed 业务为例，第1点上咱们取得了比很强的效果，iOS 劫持率由 0.12% 降低到 0.0002%，Android 劫持率由 0.25% 降低到 0.05%，第二点的收益不显著，原由在于 Feed 业务重点目的群体在国内，百度在国内节点布局相对丰富，服务整体质量亦较高，即使显现调度不准确的状况，差值亦不会太大，但倘若在国外状况可能会差非常多。

2、连接优化 1. 背景

连接优化必须处理两个核心问题：

连接创立耗时较长，引起请求的总时长变长，从而影响用户体验。

在多变的网络环境下，连接创立的过程可能会失败，引起成功率下降，从而影响用户体验。

百度 App 承载着亿级流量，针对每一个请求都必须追求耗时短，成功率高的体验。从协议方向出发，怎样才可做到这一点呢？首要咱们来看下创立连接耗时的原理。

创立连接耗时的原理

从上图咱们能清晰的看出：

1.DNS Query 必须 1 个 RTT（Round-Trip Time，即往返时间），百度 App 都是基于 HTTPDNS 服务的，因此大部分会命中缓存，倘若降级走了系统 DNS，亦会命中缓存，命中不了的因为是基于 UDP 协议，因此在连接耗时上无太大的影响，线上的数据亦能说明这点。

2.TCP 要经历 SYN，SYN/ACK，ACK 三次握手的 1.5 个 RTT，不外 ACK 和 ClientHello 合并了，因此便是 1 个 RTT。

3.TLS（Transport Layer Security，即传输层安全性协议）必须经过握手和密钥交换 2 个 RTT。

综上所述，DNS，TLS，TCP 握手周期用了 4 个 RTT 才到了 ApplicationData 周期，亦便是数据起始传输周期。

经过上面的分析能够总结出，倘若咱们能尽可能的将 TLS 和 TCP 的 RTT 减少，将会大大降低连接耗时的时间。

2. 连接优化咱们都能做什么？

百度 App 的优化目的分为两类，一类是 TLS 的连接优化，一类是 TCP 的连接优化。

TLS 的连接优化

TLS 的连接优化，必须服务端和客户端都必须支持，一起完成优化手段，包含 Session Resumption 和 False Start。

Session Resumption

Session Resumption 中文意思是会话复用，下图讲解了 Session Resumption 的协议原理。

Session Resumption 的协议原理

经过上图能够看出 TLS 密钥协商交换的过程无了，但详细是怎样实现的呢？包括两种方式，一种是 Sesssion Identifier，一种是 Session Ticket。

1）Session Identifier

Session Identifier 中文为会话标识符，更像咱们熟知的 session 的概念。是 TLS 握手中生成的 Session ID。服务端会将 Session ID 保留起来，客户端亦会存储 Session ID，在后续的 ClientHello 中带上它，服务端倘若能找到匹配的信息，就能够完成一次快速握手。

2）Session Ticket

Session Identifier 存在有些坏处端，例如客户端多次请求倘若无落在同一台设备上就没法找到匹配的信息，但 Session Ticket 能够。Session Ticket 更像咱们熟知的 cookie 的概念，Session Ticket 用仅有服务端晓得的安全密钥加密过的会话信息，保留在客户端上。客户端在 ClientHello 时带上了 Session Ticket，服务器倘若能成功解密就能够完成快速握手。

不管是 Session Identifier 还是 Session Ticket 都存在时效性问题，不是永久生效，针对这两种方式大众能够查看：

https://tools.ietf.org/html/rfc5077

百度 App 的网络协议层对这两种方式都是支持的，省去了 TLS 握手过程中证书下载，密钥协商交换的环节，节省了 1 个 RTT 的时间。

False Start

False Start 的中文意思是抢跑，下图讲解了 False Start 的协议原理。

False Start 的协议原理

上图很清晰的说明在 TLS 第1步握手成功后，客户端在发送 Change Cipher Spec Finished 的同期起始数据传输，服务端在 TLS 握手完成时直接返回复用数据。应用数据的发送实质上并未等到握手所有完成，因此叫作之为抢跑。

从结果看省去了 1 个 RTT 的时间。False Start 有两个前提要求，一是要经过应用层协议协商 ALPN（Application Layer Protocol Negotiation）握手，二是要支持前向安全的加密算法。False Start 在未完成握手的状况下就发送了数据，前向安全能够加强安全性，详细协议实现，大众能够查看：

https://tools.ietf.org/html/rfc7918

百度 App 的网络协议层对 False Start 是支持的。

这儿说句题外话，其实 TCP 层有个类似的连接优化手段叫 Fast Open，感兴趣的朋友，能够查看：

https://tools.ietf.org/html/rfc7413

Session Resumption 和 False Start 的区别

两者针对 TLS 来讲都是节省一个 RTT，Session Resumption 在第1次握手时还是必须 2 个 RTT，在第二次握手时才可复用减少到 1 个 RTT。False Start 是端上的行径，故每次都会减少到 1 个 RTT。

TCP 的连接优化

TCP 的连接优化，咱们先从连接池说起，首要让咱们来认识下连接池都有那些类型。

1. 连接池

连接池的类型

上图展示了连接池的区别类型，都是大众耳熟能详的协议连接池，有低级连接池，包括 TCP 连接池（管理 HTTP 请求的连接）和 WebSocket 连接池（管理 WebSocket 连接）。

有高级连接池，包含 HTTP 代理连接池（管理 HTTP 代理请求的连接），SpdySession 连接池（管理 SPDY 和 HTTP/2 请求的连接），SOCKS 连接池（管理 SOCKS 和 SOCKS5 代理的连接），SSL 连接池（管理 HTTPS 请求的连接）。

区别类型的连接池以组合的形式互相复用能力。

1）SSL 连接池管理的是 SSLSocket，但 SSLSocket 又依赖于 TCP 连接池供给的 TCPSocket。

2）HTTP 代理连接池倘若走 HTTP 协议，那样就必须 TCP 连接池供给 TCPSocket，倘若走 HTTPS 协议，那样就必须 SSL 连接池供给 SSLSocket。

3）SpdySession 连接池依赖 SSL 连接池供给 SSLSocket，这儿必须说明下，虽然 HTTP/2 协议无强制绑定 HTTPS，然则在实质研发中确实都是绑定 HTTPS，百度 App 运用 ALPN 来协商 HTTP/2。

4）SOCKS 连接池管理的 SOCKSSocket 和 SOCKS5Socket 都必须依赖 TCP 连接池供给的 TCPSocket，虽然 SOCKS5 支持 UDP，但 cronet 网络库暂时无实现。

5）WebSocket 连接池依赖 TCP 连接池供给的 TCPSocket，声明下这儿无说明 WSS（Web Socket Secure）的状况。

TCP 连接优化是一个比较繁杂的内容，百度 App 做了针对性场景优化，包含预连接，连接重建，备用连接，复合连接。

2. 预连接

预连接和连接重建

预连接，预先创建好的连接。它处理的场景是在 App 运用周期能够没耗时的获取连接。下面用四个问答来解释预连接。

问题一：预连接是不是能处理所有网络请求的提前连接建立？

答：答案是不是定的，预连接必须业务方进行核心业务的评定，针对核心的域名进行预连接的创立。

问题二：预连接既然针对的是特定的域名，那样是怎样配置的呢？

答：采用域名 + 连接数的方式进行配置，例如 https://a.baidu.com|2，暗示给 a.baidu.com 这个域名配置两条预连接，这儿要说明下，在 HTTP/1.x 协议下，网络库的实现都会针对单域名有最大连接数的限制，区别网络库的个数限制不同样，有 5 个亦有 6 个，但针对 HTTP/2 协议，这个连接数就只能是 1 个。

问题三：预连接是怎样创立的？

答：在网络库初始化的时候，会按照运用者的配置延迟 5s 进行预连接的创立，重点是思虑网络库在冷起步下针对起步性能的影响，为了保准网络库的整体性能，预连接的总个数限制在 20 个。

问题四：预连接是怎样保持的？

答：在网络库初始化的时候，除了进行预连接的创立，还会创建一个预连接的按时器，这个按时器会每隔 31s，这个值的设定取决于 BFE（Baidu Front End，是七层流量的统一接入系统）和 BGW（Baidu Gate Way，百度自主开发的四层负载平衡平台）对超时的最小值设定，按照运用者的配置重新创立连接。

3. 连接重建

连接重建，将连接重新创立。它处理的场景是 App 网络状态出现变化，IP 位置变化，引起连接不可用。下面用三个问答来解释连接重建。

问题一：连接重建是否针对连接池里的所有连接？

答：答案是肯定的。

问题二：连接重建的过程是什么样的？

答：在网络状态变化的时候，第1步会清除掉连接池里的 idle socket，何为 idle socket？即空闲 socket，针对从未运用过的空闲 socket 超过 60 秒清除，针对运用过的空闲 socket 超过 90 秒清除。第二步重建连接必须等待 200ms，目的是等待 DNS 先重建完成。

问题三：连接重建针对性能有影响吗？

答：出于性能思虑，连接重建的连接个数限制是 100 个。

4. 备用连接

备用连接和复合连接

备用连接，预备的连接。它处理的场景是正常发送一个请求当 group 内没连接可用的时候（何为 group？group 是管理 socket 的最小单元，内部包括活跃 socket，空闲 socket，连接任务，等待请求）。下面用三个问答来解释备用连接。

问题一：备用连接是不是针对所有请求？

答：答案是肯定的。

问题二：备用连接的过程是什么样的？

答：当有请求来临时，连接池内没连接可用，会起步一个按时器开启备用连接，按时器的间隔时间是 250ms，与主连接进行竞争，倘若主连接由于网络抖动或网络状态欠好，引起连接失败，那样备用连接就直接发送请求。倘若主连接成功，那样备用连接就被取消掉。

问题三：备用连接的目的是什么？

答：在连接池没连接的状况下，务必是要创建连接的，在主连接之外加一个备用连接，会大大提高创建连接的成功率，从而提高用户体验。

5. 复合连接

复合连接，即多条连接。它处理的场景是为了多个 IP 位置的连接选择问题。下面用三个问答来解释复合连接。

问题一：复合连接是不是针对所有请求？

答：答案是肯定的。复合连接能够全局开关，百度 App 现周期暂时无开启复合连接。

问题二：复合连接的过程是什么样的？

答：众所周知域名 DNS 查找通常状况下会返回多个 IP，咱们以域名查找返回两个 IP 为例

1）倘若结果中存在 IPv6 的位置，那样会优先选择 IPv6 的位置，这个规则 follow HappyEyeBall 机制（可参考系列一针对 HappyEyeBall 的介绍）。

2） 接下来这两个 IP 会根据次序尝试创立连接，倘若第1个 IP 返回失败，将立即起始连接第二个 IP。

3）倘若第1个 IP 率先成功返回，那样第二个 IP 将被加入连接尝试列表并停止所有尝试连接。

4）倘若第1个 IP 失败，会立刻起始第二个 IP 的连接。

5）倘若第1个 IP 处在 pending 状态，那样会起步一个按时器，默认延迟 2s 会发起第二个 IP 的连接，倘若是多个 IP 将会递归连接，必须尤其说明下，区别的网络制式延迟时间会不同样，这般体验亦会更好。

问题三：复合连接的目的是什么？

答：复合连接的好处是供给最优的 IP 选择机制，但亦会带来服务端的高负载，因此运用的时候必须进行综合评定。

3. 连接优化的最佳实践

百度 App 日前客户端网络架构因为历史原由还未统一，不外咱们正朝着这个目的奋斗。

咱们的中心思想是以系统网络库的 API 调用接口为中心，上层创立网络门面，供外边方便调用，底层经过系统机制以 AOP 的方式将 cronet（chromium 的 net 模块）注入进系统网路库，达到双端网络架构统一，能力复用。

下面着重介绍下连接优化在 Android 和 iOS 网络架构中的位置及实践。

1. 连接优化在 Android 网络架构的位置及实践

连接优化在 Android 网络架构的位置

百度 App 的 Android 网络流量日前都在 okhttp 之上，上层进行了网络门面的封装，封装内部的实现细节和对外友好的 API，日前咱们正在进行重构，默认采用 Android 标准的网络接口 HttpURLConnection，它的底层由系统供给的 okhttp 的实现。

订制方面利用 URL Stream Protocol 机制将 HttpURLConnection 底层网络协议栈接管为 cronet，供各个业务和基本模块运用，连接优化的所有内容在 cronet 网络库内部实现。

2. 连接优化在 iOS 网络架构的位置及实践

连接优化在 iOS 网络架构的位置

百度 App 的 iOS 网络流量日前都在 cronet 之上，上层咱们运用 iOS 的 URL Loading System 机制将 cronet stack 注入进 URLSession 里，这般咱们就能够直接运用 URLSession 的 API 进行网络的操作况且更易于系统守护，在上层封装了网络门面，供各个业务和基本模块运用。

在 cronet 内部实现了预连接（重点针对百度 App 的几个核心域名进行预连和保活），连接重建（针对所有请求），备用连接（针对所有请求），复合连接（iOS 上暂时无开启），Session Resumption（针对所有请求），False Start（针对所有请求）。

4. 收益

连接优化的收益重点表现在网络时延和网络成功率上，这两点收益必须结合业务来讲，以百度 App Feed 刷新这个典型业务场景为例。

Feed 刷新文本请求网络时延降低 16%，Feed 刷新照片请求网络时延降低 12%，可谓收益相当显著。

成功率方面，Feed 刷新文本请求成功率提高 0.29%，Feed 刷新照片请求成功率提高 0.23%，亦是非常不错的收益。

3、结语

DNS 优化和连接优化是个连续性的专题，无最优仅有更优。上面介绍的百度 App 的有些经验和做法并不见得完美，但咱们会继续深入的优化下去，连续提高百度 App 的网络性能。

以上优化由百度 App 团队，内核团队，OP 团队共建完成。最后感谢大众的辛苦阅读，期盼对你有所帮忙。

参考资料

https://tools.ietf.org/html/rfc7858

https://tools.ietf.org/html/rfc6555

https://tools.ietf.org/html/rfc8305

https://tools.ietf.org/html/rfc7918

https://tools.ietf.org/html/rfc5077

https://tools.ietf.org/html/rfc7413

作者简介

蔡锐，9 年移动客户端研发经验，在百度先后主导过订制 ROM 行业、多屏互动行业、Hybrid 跨平台行业等多个技术行业的研发，日前担任百度 App 的客户端资深工程师，参与基本技术的科研，专攻动态化和网络优化方向。

 活动举荐

GMTC 全球大前端技术大会上，咱们邀请到了来自 Google、BAT、美团、京东、滴滴、字节跳动等 60+ 一线技术专家与你共话前端哪些事，涵盖小程序、Flutter、前端安全、工程化、性能优化等 20+ 热点技术，不可错失。欢迎点击“阅读原文”认识详情。

听听海

“NB”（牛×的缩写，表示叹为观止）‌

张露zhang

“BS”（鄙视的缩写）‌

j8typz

seo常来的论坛，希望我的网站快点收录。