百度App网络深度优化 DNS 和连接优化
搜集优化是客户端几大本领目标中公认的一个深度范围百度 App 也不不同南京seo优化培训百度 App 也不不同即日咱们在此地向大师引睹百度 App 搜集深度优化的试验体味实质重要包括 DNS 优化和对接优化憧憬闭于大师在搜集目标的进修和试验有所帮帮。
一、DNS 优化
百度发迹于搜寻所有公司的搜集架媾和安置都是基于尺度的 internet 协议姑且已经是全栈 HTTPS光临挪动互联网时期后总的前提架构不变然而在客户端上须要干许多优化处事。
DNS（Domain Name System）它的效率是依据域名查出 IP 地方它是 HTTP 协议的前提惟有将域名精确的领会成 IP 地方后反面的 HTTP 过程本领进行所以普遍干搜集优化会首选优化 DNS。
1. 背景
DNS 优化核心须要处理的问题有二点：
【1】因为 DNS 威胁大概妨害形成的效劳不可用从而效率用户体验效率公司的收入。
展开结余96%【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 IPVIP 并不与某设备存留必定的绑定闭系会随同主备切换之类的情景爆发而变幻VIP 供给的效劳是闭于应到某一台大概若搞台效劳器的）既然乞求本始数据须要运用 IP 直连的办法那么便摆脱了经经商 localDNS 的领会节制如许纵然经经商展示了妨害大概者被威胁都不会效率百度 App 的可用性。
责任安排战术
HTTPDNS 效劳供给了二类 HTTP 接口用于乞求最优域名截止。第一种是多域名接口针闭于不共的产品线下发产品线摆设的域名第二种是单域名接口只返回你要查问的谁人域名截止如许的安排和尺度的 DNS 查问基础是普遍的只然而是从 UDP 协议形成了 HTTP 协议。
【1】多域名接口会在 App 冷开用和搜集切换的时间乞求一次手段是在 App 的搜集情况初始化大概者变革的时间预先获得域名截止如许也会缩小单域名接口的乞求次数。
【2】单域名接口会在本地 cache 降伍后由用户的安排触发搜集乞求从而干一次单域名乞求用户这次安排的 DNS 截止会左迁成 localDNS 的截止然而在不降伍的情景下下次会返回 HTTPDNS 的截止。
IP 采用战术
IP 采用战术处理的核心问题是最优 IP 的采用制止因为接入点的采用缺点形成的跨经经商耗时。HTTPDNS 效劳会将最优 IP 依照程序下发客户端默认采用第一个此地不作客户端的连通性校验的缘故重要仍旧担忧端上的本能问题然而有容灾战术兜底综合评价仍旧不妨接收的。
缓存战术
大师闭于于 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 采用的问题它是一套完全处理筹备闭于于域名查问的处置地方的排序对接的试验等方面均干出了决定感风趣的共学不妨察瞅：
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 交易为例第一点上咱们博得了比较大的效验iOS 威胁率由 0.12% 降矮到 0.0002%Android 威胁率由 0.25% 降矮到 0.05%第二点的收益不明显缘故在于 Feed 交易重要手段普遍在海内百度在海内节点安置相闭于丰厚效劳完全品质也较高纵然展示安排不精确的情景差值也不会太大然而假如在海外情景大概会差许多。
二、对接优化
1. 背景
对接优化须要处理二个核心问题：
百度 App 承载着亿级流量闭于于每一个乞求都须要商量耗时短成功率高的体验。从协议角度出发何如样本领干到这一点呢？开始咱们来瞅下树立对接耗时的本理。
树立对接耗时的本理
从上图咱们能领会的瞅出：
1.DNS Query 须要 1 个 RTT（Round-Trip Time即来往日间）百度 App 都是基于 HTTPDNS 效劳的所以时势部会掷中缓存假如左迁走了体系 DNS也会掷中缓存掷中不了的因为是基于 UDP 协议所以在对接耗时上不太大的效率线上的数据也能证明这点。
2.TCP 要体验 SYNSYN/ACKACK 三次握手的 1.5 个 RTT然而 ACK 和 ClientHello 兼并了所以即是 1 个 RTT。
3.TLS（Transport Layer Security即传输层宁靖性协议）须要经过握手和密钥调换 2 个 RTT。
综上所述DNSTLSTCP 握手阶段用了 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 第一步握手成功后客户端在发送 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 来说都是俭朴一个 RTTSession Resumption 在第一次握手时仍旧须要 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 地方变革引导对接不可用。底下用三个问答来解释对接沉建。
问题一：对接沉建是否针闭于对接池里的十脚对接？
答：答案是确定的。
问题二：对接沉建的过程是什么样的？
答：在搜集状况变革的时间第一步会驱撤除对接池里的 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 会依照程序试验树立对接假如第一个 IP 返回波折将登时发端对接第二个 IP。
3）假如第一个 IP 率先成功返回那么第二个 IP 将被介入对接试验列表并中止十脚试验对接。
4）假如第一个 IP 波折会登时发端第二个 IP 的对接。
5）假如第一个 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%也是格外不错的收益。
三、结语
DNS 优化和对接优化是个持续性的话题不最优惟有更优。上头引睹的百度 App 的一些体味和干法并不睹得完备然而咱们会持续深刻的优化下去持续提高百度 App 的搜集本能。
以上优化由百度 App 团队内核团队OP 团队共建完成。结果感动大师的劳累观赏憧憬闭于你有所帮帮。
参照材料