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

来源:未知 浏览 426次 时间 2021-04-09 10:26

本文转载自百度应用技术一序言中的系列“i”你知道网络优化一般会是优化DNS的首选百度优化服务你知道网络优化一般会是优化DNS的首选而下一个HTTP协议则成为优化的重点一般的优化器会选择协议切换、合并请求、精简数据包的大小等。R是指对HTTP协议进行优化严格来说这些都不是网络优化的一部分。HTTP协议是基于连接的因此我们的“2”系列链接优化应运而生希望能帮助您向网络学习和实践的方向发展。2。后台连接优化需要解决两个核心问题。1。建立连接需要很长时间这会导致总的请求时间更长进而影响用户体验。2。在多变的网络环境中建立连接的过程可能会失败导致成功率下降从而影响用户体验。百度应用承载着数亿的流量。对于每一个请求都需要追求时间短、成功率高的体验。从协议的角度来看我们如何才能做到这一点?首先让我们看看建立连接的耗时原则。从上图中可以清楚地看到扩展建立连接的剩余94%耗时原则1。dnsquery需要一个rtt(round triptime)百度应用是基于httpdns服务的所以大部分都会命中缓存。如果系统DNS降级它也会命中缓存。因为它是基于UDP协议的所以对连接时间没有太大的影响。是的线上的数据也可以说明这一点。2。TCP将经历1.5次SYN、SYN/ACK和ACK握手三次的RTT但ACK和客户机hello合并所以它是一个RTT。三。TLS(传输层安全或传输层安全协议)需要两个RTT:握手和密钥交换。综上所述dns、tls、tcp握手阶段采用4个RTT到达应用数据阶段即数据传输阶段。通过以上分析我们可以得出这样的结论:如果我们能够尽可能地减少TLS和TCP的RTT那么连接时间将会大大缩短。第三百度应用的优化目标分为两类:TLS连接优化和TCP连接优化。tls连接优化tls连接优化需要服务器和客户端的支持才能完成优化方法包括会话恢复和错误启动。会话恢复会话恢复是指在中文中重新使用会话。下图说明了会话恢复的协议原则。从上图可以看出恢复会话的原则是TLS密钥协议交换过程不再可用但如何实现?有两种方法一种是SES。会话标识符一个是会话票据。1)会话标识符会话标识符是一种中文会话标识符更像是众所周知的会话概念。它是在TLS握手中生成的会话ID。服务器将保存会话ID客户机也将存储会话ID并将其带到后续客户机hello中。如果服务器能够找到匹配的信息它就可以完成快速握手。2)会话票证会话标识符存在一些缺点例如如果客户端多次请求并且不在同一台机器上则找不到匹配的信息但会话票证可以。sessionticket更像是著名的cookie概念。sessionticket使用由服务器已知的安全密钥加密的会话信息并将其保存在客户机上。客户机hello将会话通知单带到客户机上如果解密成功服务器可以快速握手。无论是会话标识符还是会话通知单都存在时间性问题而不是永久性影响。对于这两种方法您可以看到参考资料[4]。百度应用的网络协议层支持这两种方法消除了在TLS握手中证书下载和密钥协议交换的过程节省了一次RTT时间。“假启动”用中文表示“急”。下图说明了错误启动的协议原理。错误启动示意图清楚地表明在第一次成功地握手之后客户端在发送changeCipherPecFinished的同时开始数据传输当完成握手后服务器直接返回应用程序数据。事实上应用程序数据的发送不会等到握手完成后才进行所以称为rush。因此可以节省一次RTT时间。假启动有两个先决条件:一个是通过应用层协议协商ALPN(应用层协议协商)握手另一个是支持前向安全加密算法。假启动在不完成握手的情况下发送数据。前向安全可以提高安全性。具体的协议实现可以看到参考资料[3]。百度应用的网络协议层支持虚假启动。实际上TCP层有一个类似的连接优化方法叫做fastopen。感兴趣的学生可以查看资源[5]。会话恢复与错误启动的区别对于TLS它保存一个RTT。会话恢复仍然需要两个RTT进行第一次握手并且可以多路传输到一个RTT进行第二次握手。虚假启动是一种端到端的行为因此每次都减少到一个RTT。让我们从连接池开始。让我们首先了解连接池的类型。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连接池提供TCP套接字。如果采用HTTPS协议则需要SSL连接池提供SSL套接字。3)spdysession连接池依靠ssl连接池提供ssl套接字。需要说明的是虽然HTTP/2协议不强制绑定HTTPS但在实际开发中确实绑定了HTTPS。百度应用使用alpn协商http/2。4)socks连接池管理的socksocket和socks5套接字都需要依赖tcp连接池提供的tcp socket。虽然socks5支持udp但cronet网络库尚未实现。5)websocket连接池依赖于tcp连接池提供的tcpsocket。声明中没有解释wss(web socket secure)的情况。TCP连接优化是一个比较复杂的内容百度应用已经做了针对性的场景优化包括预连接、连接重构、备用连接、复合连接。2。预连接预连接和重建预连接预创建连接。它所处理的场景是在应用程序使用阶段可以获取耗时的连接。这里有四个问题和答案来解释预连接。问题1:预连接能否解决所有网络请求的预建立问题?答:答案是否预连接要求业务方对核心业务进行评估建立核心域名的预连接。问题二:由于预连接用于特定域名它们是如何配置的?答:使用域名+连接号的方式配置如https://a.baidu.com 2优化网站推广如https://a.baidu.com 2为a.baidu.com域名配置两个预连接。在这里应该解释一下在HTTP/1.x协议下网络库的实现将限制单个域名的最大连接数。不同网络库的数量不同有5个和6个但是对于HTTP/2协议连接是不同的。数字只能是一。问题3:如何建立预连接?答:网络库初始化时根据用户配置延迟5秒建立预连接主要考虑网络库冷启动对启动性能的影响。为了确保网络库的整体性能优化网站推广主要考虑网络库冷启动对启动性能的影响。为了确保网络库的整体性能预连接的总数限制为20。问题4:如何保持预连接?答:初始化网络库时除了建立预连接外还将创建一个预连接计时器。此计时器将每31秒设置一次。用户表示该值的设置取决于bfe(百度前端七层流量的统一接入系统)和bgw(百度自主开发的四层负载平衡平台百度网关)的最小超时设置。配置重建连接。三。连接重建、连接重建、连接重建。它解决了应用程序网络状态更改和IP地址更改导致连接不可用的情况。这里有三个问题和答案来解释连接重建。问题1:连接池中的所有连接是否都进行了连接重建?答:答案是肯定的。问题2:连接重建的过程是什么?答:当网络状态发生变化时第一步是从连接池中删除idlesocket。什么是idlesocket?也就是说对于未使用的空闲套接字空闲套接字的清除时间超过60秒对于已使用的空闲套接字清除时间超过90秒。重建连接的第二步是等待200 ms等待首先重建DNS。问题3:连接重建是否影响性能?答:由于性能原因重建的连接数限制为100个。4。备用连接备用连接和复合连接备用连接、备用连接。它解决了在组中没有可用连接时正常发送请求的情况(什么是组?组是管理套接字的最小单元它包括活动套接字、空闲套接字、连接任务和等待请求。这里有三个问题和答案来解释替代连接。问题1:所有请求都是备用连接吗?答:答案是肯定的。问题2:备份连接的过程是什么?答:当出现请求时连接池中没有可用的连接将启动计时器以打开备用连接。定时器的间隔时间为250毫秒与主接线竞争。如果主连接由于网络抖动或网络状态不良而失败则连接将失败。然后备用连接直接发送请求。如果主连接成功则取消备用连接。问题3:备用连接的目的是什么?答:连接池未连接时需要创建连接。在主连接中添加备用连接将大大提高创建连接的成功率从而增强用户体验。5。复合连接:复合连接即多个连接。它解决了多个IP地址的连接选择方案。这里有三个问题和答案来解释复合连接。问题1:是否所有请求都有复合连接?答:答案是肯定的。复合连接可以全局切换百度应用在这个阶段还没有打开复合连接。问题2:复合连接的过程是什么?答:众所周知DNS域名查询通常返回多个IP。我们以域名查询返回两个IP为例。1)如果结果中有IPv6地址则首选IPv6地址。这个规则遵循快乐眼球机制(参考一系列关于快乐眼球的介绍)。2)接下来两个IP将尝试按顺序建立连接如果第一个IP返回失败第二个IP将立即连接。3)如果第一个IP成功返回第二个IP将添加到连接尝试列表中所有尝试的连接都将停止。4)如果第一个IP失败第二个IP连接将立即启动。5)如果第一个IP处于挂起状态则将启动计时器。默认延迟2s将启动第二个IP的连接。如果将多个IP递归连接需要指定不同网络格式的延迟时间不同这样经验会更好。问题3:复合连接的目的是什么?答:复合连接的优点是提供最优的IP选择机制但同时也给服务器端带来了很高的负载因此在使用时需要进行综合评估。第四百度应用连接优化的最佳实践由于历史原因尚未统一其客户端网络架构但我们正朝着这个目标努力。我们的核心思想是以系统网络库的API调用接口为中心。上层建立网络门面对外方便呼叫。底层通过AOP的系统机制将cronet(chromium's net module)注入系统网络库实现两终端网络架构的统一和功能的重用。下面重点介绍了Android和iOS网络体系结构中连接优化的位置和实践。1。连接优化在安卓网络架构的位置和实践连接优化在安卓网络架构的位置百度应用安卓网络流量目前在OKHTTP上层的网络门面封装内部实现细节的封装和外部友好的API我们可以e当前正在重新配置默认为Android标准网络接口httpurlconnection其底部。系统提供的Okhtt层在P.的实现中利用URLStream协议机制将httpurlConnection的底层网络协议栈作为cronet被各种业务和基本模块所使用。连接优化的所有内容都在cronet网络库中实现。2。iOS网络架构中的连接优化定位和实践iOS网络架构中的连接优化定位百度应用的iOS网络流量目前在cronet上。上层采用IOS的URLLOAding系统机制将cronetstack注入到URLSession中直接使用URLSession API进行网络操作方便系统维护将网络封装在上层。循环外观用于每个业务和基本模块的使用。在cronet中实现了预连接(主要针对百度应用核心域)、连接重建(针对所有请求)、备用连接(针对所有请求)、复合连接(暂时不在iOS上打开)、会话恢复(针对所有请求)、假启动(针对所有请求)。第五收入连接优化的好处主要体现在网络延迟和网络成功率上。这两个好处需要与业务相结合。以百度AppFeed刷新为例。feed刷新文本请求网络延迟减少了16%feed刷新图片请求网络延迟减少了12%所以可以说好处是相当明显的。在成功率方面提要刷新文本请求的成功率提高了0.29%提要刷新图片请求的成功率提高了0.23%这也是一个很好的效益。6。结论连接的优化是一个连续的课题。没有最好的只有更好的。上面介绍的百度应用的一些经验和做法并不完美但我们将继续深入优化继续提高百度应用的网络性能。以上优化由百度应用团队、内核团队、操作团队完成。最后感谢你的努力阅读。希望对你有帮助。稍后我们将继续推出百度应用网络深度优化系列“三”弱网络优化。请期待。7。参考文献1。https://chromium.googlesource.com/chromium/src/+/head/docs/android_build_instructions.md2.https://chromium.googlesource.com/chromium/src/+/head/docs/ios/build_instructions.md3.https://tools.tf.org/html/rfc7918estart4.https://tools.tf.tf。/html/rfc5077会话恢复5.https://tools.ietf.org/html/rfc7413 tcpfastopen扩展阅读:百度应用网络深度优化系列“i”DNS优化百度开发客户端声明:本文仅代表作者本人搜狐是一个信息发布平台搜狐仅提供信息存储空间服务。阅读(0)

标签: 百度优化