百度App网络深度优化系列《二》连接优化

一、前言

在系列《一》里大家了解到网络优化一般会首选优化DNS,而接下来的HTTP协议成为优化的重点,一般优化者会选择协议切换,合并请求,精简数据包大小等手段来对HTTP协议进行优化,严谨的说这都不属于网络优化的范畴。

HTTP协议的基础是连接,所以我们的系列《二》连接优化应运而生,希望对大家在网络方向的学习和实践有所帮助。

二、背景

连接优化需要解决两个核心问题

  1. 连接建立耗时较长,导致请求的总时长变长,进而影响用户体验。
  2. 在多变的网络环境下,连接建立的过程可能会失败,导致成功率下降,进而影响用户体验。

百度App承载着亿级流量,对于每一个请求都需要追求耗时短,成功率高的体验。从协议角度出发,如何才能做到这一点呢?首先我们来看下建立连接耗时的原理。

建立连接耗时的原理.jpg

从上图我们能清晰的看出

DNS Query需要1个RTT(Round-Trip Time,即往返时间),百度App都是基于HTTPDNS服务的,所以大部分会命中缓存,如果降级走了系统DNS,也会命中缓存,命中不了的由于是基于UDP协议,所以在连接耗时上没有太大的影响,线上的数据也能说明这点。
TCP要经历SYN,SYN/ACK,ACK三次握手的1.5个RTT,不过ACK和ClientHello合并了,所以就是1个RTT。
TLS(Transport Layer Security,即传输层安全性协议)需要经过握手和密钥交换2个RTT。
综上所述,DNS,TLS,TCP握手阶段用了4个RTT才到了ApplicationData阶段,也就是数据开始传输阶段。

通过上面的分析可以总结出,如果我们能尽量的将TLS和TCP的RTT减少,将会大大降低连接耗时的时间。

三、连接优化我们都能做什么

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

TLS的连接优化

TLS的连接优化,需要服务端和客户端都需要支持,共同完成优化手段,包括Session Resumption和False Start。

Session Resumption

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

Session Resumption的协议原理.jpg

通过上图可以看出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都存在时效性问题,不是永久生效,对于这两种方式大家可以查看参考资料【4】。百度App的网络协议层对这两种方式都是支持的,省去了TLS握手过程中证书下载,密钥协商交换的环节,节省了1个RTT的时间。

False Start

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

False Start的协议原理.jpg

上图很清晰的说明在TLS第一步握手成功后,客户端在发送Change Cipher Spec Finished的同时开始数据传输,服务端在TLS握手完成时直接返回应用数据。应用数据的发送实际上并未等到握手全部完成,所以称之为抢跑。

从结果看省去了1个RTT的时间。False Start有两个前提条件,一是要通过应用层协议协商ALPN(Application Layer Protocol Negotiation)握手,二是要支持前向安全的加密算法。False Start在未完成握手的情况下就发送了数据,前向安全可以提高安全性,具体协议实现,大家可以查看参考资料【3】。百度App的网络协议层对False Start是支持的。

这里说句题外话,其实TCP层有个类似的连接优化手段叫Fast Open,感兴趣的同学,可以查看参考资料【5】。

Session Resumption和False Start的区别
两者对于TLS来说都是节省一个RTT,Session Resumption在第一次握手时还是需要2个RTT,在第二次握手时才能复用减少到1个RTT。False Start是端上的行为,故每次都会减少到1个RTT。

TCP的连接优化

TCP的连接优化,我们先从连接池说起,首先让我们来认识下连接池都有哪些类型。

1.连接池

连接池的类型.jpg

上图展示了连接池的不同类型,都是大家耳熟能详的协议连接池,有低级连接池,包含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.预连接

预连接和连接重建.jpg

预连接,预先创建好的连接。它解决的场景是在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. 备用连接

备用连接和复合连接.jpg

备用连接,预备的连接。它解决的场景是正常发送一个请求当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选取机制,但也会带来服务端的高负载,所以使用的时候需要进行综合评估。

四、连接优化的最佳实践

百度App目前客户端网络架构由于历史原因还未统一,不过我们正朝着这个目标努力。

我们的中心思想是以系统网络库的API调用接口为中心,上层建立网络门面,供外部便捷调用,底层通过系统机制以AOP的方式将cronet(chromium的net模块)注入进系统网路库,达到双端网络架构统一,能力复用。

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

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

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

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

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

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

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

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

百度App的iOS网络流量目前都在cronet之上,上层我们使用iOS的URL Loading System机制将cronet stack注入进URLSession里,这样我们就可以直接使用URLSession的API进行网络的操作而且更易于系统维护,在上层封装了网络门面,供各个业务和基础模块使用。

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

五、收益
连接优化的收益主要体现在网络时延和网络成功率上,这两点收益需要结合业务来说,以百度App Feed刷新这个典型业务场景为例。

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

成功率方面,Feed刷新文本请求成功率提升0.29%,Feed刷新图片请求成功率提升0.23%,也是非常不错的收益。

六、结语
连接优化是个持续性的话题,没有最优只有更优。上面介绍的百度App的一些经验和做法并不见得完美,但我们会继续深入的优化下去,持续提升百度App的网络性能。

以上优化由百度App团队,内核团队,OP团队共建完成。最后感谢大家的辛苦阅读,希望对你有所帮助,后面会继续推出-百度App网络深度优化系列《三》弱网优化,敬请期待。

七、参考资料
1.https://chromium.googlesource...

2.https://chromium.googlesource...

3.https://tools.ietf.org/html/r... False Start

4.https://tools.ietf.org/html/r... Session Resumption

5.https://tools.ietf.org/html/r... TCP Fast Open

https://segmentfault.com/a/1190000020806196

谷歌确认将推出新功能 对标苹果AirDrop

北京时间7月1日早间消息,据外媒报道,此前几个月中一直有传言称谷歌将为Android手机添加一个类似苹果AirDrop的新功能。如今,谷歌终于证实,他们的确将推出这个功能,其正式名称为“Nearby Share”。一些Android手机用户已经测试了该功能的beta版本。

发布于:2天以前  |  28次阅读  |  详细内容 »

老干妈回应:腾讯公司被骗了 并没有与腾讯有任何的合作

6月30日,中国裁判文书网显示,广东省深圳市南山区人民法院发布一则民事裁定书,同意原告腾讯请求查封、冻结被告老干妈公司公司名下价值人民币16240600元的财产。但6月30日下午,老干妈声明称,经核实,公司从未与腾讯或授权他人与腾讯就“老干妈”品牌签署《联合市场推广合作协议》,且从未与腾讯进行过任何商业合作。

发布于:2天以前  |  21次阅读  |  详细内容 »

移动端常见崩溃指标

崩溃分析,是将 Android 和 iOS 平台常见的 APP 崩溃问题进行归类分析,帮助企业根据崩溃指标快速发现、定位问题。

发布于:3天以前  |  52次阅读  |  详细内容 »

58同城一季度净利润16.386亿元,同比增134.7%

6月26日讯,生活服务平台58同城(NYSE:WUBA)公布了截至2020年3月31日第一季度未经审计的财务报告。财报显示,58同城第一季度实现营收25.603亿元,同比下滑15.5%;净利润16.386亿元,同比增134.7%。

发布于:6天以前  |  33次阅读  |  详细内容 »

马斯克豪宅以2900万美元出手,买家为网易CEO丁磊

6月20日早间消息,据《华尔街日报》周五援引公开记录报道,特斯拉首席执行官埃隆·马斯克(Elon Musk)以2900万美元的价格出售了他在洛杉矶Bel-Air地区的一处房屋。报道称,买家是与中国亿万富翁丁磊有联系的公司。

发布于:12天以前  |  68次阅读  |  详细内容 »

甲骨文公司泄露数十亿条网络数据记录

据外媒报道,科技巨头「甲骨文」的数据管理平台BlueKai因为在服务器上不加密码从而泄露了全球数十亿条数据记录。甲骨文发言人黛博拉·海林格(Deborah Hellinger)对媒体表示,该消息属实。

发布于:12天以前  |  58次阅读  |  详细内容 »

罗永浩:筹备脱口秀节目,正在组建团队

6月21日晚间消息,极客公园与哔哩哔哩联合举办的Rebuild2020科技全明星峰会上,罗永浩在对话中透露,自己准备在一个比较大的平台上做一档综艺节目,是一档脱口秀节目,当下正在组建团队。“做这一档节目不是为了赚钱。”罗永浩说。

发布于:12天以前  |  46次阅读  |  详细内容 »

最多阅读

简化Android的UI开发 7月以前  |  193726次阅读
Android设计与开发工作流 7月以前  |  2304次阅读
Google Enjarify:可代替dex2jar的dex反编译 1年以前  |  2294次阅读
Android多渠道打包工具:apptools 1年以前  |  1927次阅读
Android权限 - 第一篇 1年以前  |  1898次阅读
Google Java编程风格规范(中文版) 1年以前  |  1880次阅读
Stetho 1年以前  |  1813次阅读
Android UI基本技术点 1年以前  |  1806次阅读
30分钟搭建一个android的私有Maven仓库 1年以前  |  1770次阅读
2015 Google IO带来的新 Android 开发工具 1年以前  |  1710次阅读
你应该知道的布局和属性 1年以前  |  1656次阅读
听FackBook工程师讲*Custom ViewGroups* 1年以前  |  1654次阅读
MVP在Android平台上的应用 1年以前  |  1635次阅读
Gradle小知识#3:任务的顺序 1年以前  |  1631次阅读