1、前言
在系列《一》里大众认识到网络优化通常会首选优化DNS，而接下来的HTTP协议作为优化的重点，通常优化者会选取协议切换，合并请求，精简数据包体积等手段来对HTTP协议进行优化，严谨的说这都不属于网络优化的范畴。
HTTP协议的基本是连接，因此咱们的系列《二》连接优化应运而生，期盼对大众在网络方向的学习和实践有所帮忙。
2、背景
连接优化需要处理两个核心问题
1. 连接创立耗时较长，引起请求的总时长变长，从而影响用户体验。
2. 在多变的网络环境下，连接创立的过程可能会失败，引起成功率下降，从而影响用户体验。
百度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减少，将会大大降低连接耗时的时间。
3、连接优化咱们都能做什么
百度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都存在时效性问题，不是永久生效，针对这两种方式大众能够查看参考资料【4】。百度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在未完成握手的状况下就发送了数据，前向安全能够加强安全性，详细协议实现，大众能够查看参考资料【3】。百度App的网络协议层对False Start是支持的。
这儿说句题外话，其实TCP层有个类似的连接优化手段叫Fast Open，感兴趣的朋友，能够查看参考资料【5】。
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选择机制，但亦会带来服务端的高负载，因此使用的时候需要进行综合评定。
4、连接优化的最佳实践
百度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（针对所有请求）。
5、收益
连接优化的收益重点表现在网络时延和网络成功率上，这两点收益需要结合业务来讲，以百度App Feed刷新这个典型业务场景为例。
Feed刷新文本请求网络时延降低16%，Feed刷新照片请求网络时延降低12%，可谓收益相当显著。
成功率方面，Feed刷新文本请求成功率提高0.29%，Feed刷新照片请求成功率提高0.23%，亦是非常不错的收益。
6、结语
连接优化是个连续性的专题，无最优仅有更优。上面介绍的百度App的有些经验和做法并不见得完美，但咱们会继续深入的优化下去，连续提高百度App的网络性能。
以上优化由百度App团队，内核团队，OP团队共建完成。最后感谢大众的辛苦阅读，期盼对你有所帮忙，后面会继续推出-百度App网络深度优化系列《三》弱网优化，敬请期待。
7、参考资料
1. https://chromium.googlesource.com/chromium/src/+/HEAD/docs/android_build_instructions.md
2. https://chromium.googlesource.com/chromium/src/+/HEAD/docs/ios/build_instructions.md
3. https://tools.ietf.org/html/rfc7918 False Start
4. https://tools.ietf.org/html/rfc5077 Session Resumption
5. https://tools.ietf.org/html/rfc7413 TCP Fast Open
原创： 蔡锐 百度App技术
拓展阅读：
百度App网络深度优化系列《一》DNS优化
发表于 2024-10-9 01:14:14