网络优化最佳实践!百度App网络深度优化系列《二》连接优化(1)

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都存在时效性问题,不是永久生效,对于这两种方式大家可以查看参考资料【4】。百度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在未完成握手的情况下就发送了数据,前向安全可以提高安全性,具体协议实现,大家可以查看参考资料【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. 连接池

连接池的类型

上图展示了连接池的不同类型,都是大家耳熟能详的协议连接池,有低级连接池,包含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选取机制,但也会带来服务端的高负载,所以使用的时候需要进行综合评估。

四、连接优化的最佳实践

百度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网络架构的位置及实践

尾声

对于很多初中级Android工程师而言,想要提升技能,往往是自己摸索成长,不成体系的学习效果低效漫长且无助。 整理的这些架构技术希望对Android开发的朋友们有所参考以及少走弯路,本文的重点是你有没有收获与成长,其余的都不重要,希望读者们能谨记这一点。

最后想要拿高薪实现技术提升薪水得到质的飞跃。最快捷的方式,就是有人可以带着你一起分析,这样学习起来最为高效,所以为了大家能够顺利进阶中高级、架构师,我特地为大家准备了一套高手学习的源码和框架视频等精品Android架构师教程,保证你学了以后保证薪资上升一个台阶。

当你有了学习线路,学习哪些内容,也知道以后的路怎么走了,理论看多了总要实践的。

进阶学习视频

附上:我们之前因为秋招收集的二十套一二线互联网公司Android面试真题 (含BAT、小米、华为、美团、滴滴)和我自己整理Android复习笔记(包含Android基础知识点、Android扩展知识点、Android源码解析、设计模式汇总、Gradle知识点、常见算法题汇总。)


《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》点击传送门,即可获取!
、Android源码解析、设计模式汇总、Gradle知识点、常见算法题汇总。)

[外链图片转存中…(img-RYhQ6MMv-1715357282937)]
《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》点击传送门,即可获取!

  • 17
    点赞
  • 15
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值