1.前言
为用户提供更加晦涩的App应用体验是咱们的指标。作为电商类App，社区+交易相干业务强依赖图片、视频、文件等动态资源。因为这些动态资源部署在CDN上，因而本文统称为“CDN资源”。
尽管部署到CDN服务后晋升了CDN资源的申请性能，但只能算是初始阶段，App端仍然存在资源加载慢、卡顿等体验问题，离预期还有肯定间隔，须要进一步优化。因而，2021年下半年咱们对CDN资源的网络申请性能进行了重点优化，获得了显著的成果，本文在此进行一个阶段性总结。
2.内容介绍
本文次要介绍得物 CDN 资源申请实现均匀耗时 iOS 端升高18%+， Android 端升高10%+ 的优化思路及优化实践经验。整体按监控数据分析，优化方向调研，优化方案设计，推动优化落地，优化成果反馈的流程执行，达到逐渐优化的成果。本文次要讲4个优化方向，包含：CDN部署调整，TLS1.3降级，OCSP Stapling开启，Http2.0降级。上面就来具体介绍下每个优化方向具体如何确定的，优化的计划，以及优化成果。
3.优化案例
3.1 CDN部署调整
3.1.1 什么是CDN服务？
可能有的同学对CDN还不太熟悉，咱们先简略介绍下CDN的概念及原理。CDN（Content Delivery Network）指内容散发网络，由散布在不同地区的边缘服务器节点组成的分布式网络，负责缓存源站动态资源并就近分发给用户，达到升高动态资源申请耗时，升高源站服务器压力的目标。
CDN服务的劣势：就近接入，资源缓存，升高回源，智能选路，高效传输，智能压缩，平安，高性能等个性（摘自阿里云CDN文档介绍）。简略来说就是就近接入，资源缓存，高效回源这3大个性。
动态资源部署到CDN服务后，拜访链路从申请源站变为就近接入CDN边缘节点，大大缩短了网络拜访链路，升高了CDN资源的申请耗时。如广东用户原来申请CDN资源须要拜访杭州源站，当初能够间接拜访广东省内的CDN边缘节点获取CDN资源。
CDN边缘节点如果有以后申请的CDN资源缓存，则间接将缓存返回给客户端；如果没有缓存，则通过CDN服务零碎外部策略实现高效回源，资源获取后返回到CDN边缘节点并缓存，再返回给客户端。
下图能够直观的展现出部署到CDN服务前后用户申请动态资源的变动
（注：图片来自网络）
3.1.2 从地区维度剖析CDN资源申请耗时监控数据
理解了CDN的原理后，咱们就晓得，CDN服务成果是和地区强相干的。对不同地区的用户来说，该地区是否部署了CDN服务器节点，部署了多少台CDN服务器节点来承载流量间接影响着该地区用户CDN资源申请的耗时长短。因而，思考先从CDN按地区部署的角度对CDN资源申请监控数据进行剖析。
咱们重点剖析均匀耗时大于等于500ms的省份，其中广东省作为一线省份，网络基础设施应该比较完善，为什么均匀耗时在500ms以上？
初步揣测：可能是CDN服务器节点部署不合理，未在广东省部署或在广东省部署较少，广东用户无奈就近接入CDN服务，跨域拜访导致CDN资源申请耗时较长。
3.1.3 阿里云CDN部署状况调研
咱们将这个揣测反馈给阿里云客服，让其核实服务于得物的CDN边缘节点在各省份的散布状况以及广东省CDN边缘节点的部署状况。
排查后果：未部署广东、北京，并且湖南、四川、江苏、吉林部署节点偏少。
调研论断：这些地区的用户存在跨域申请CDN资源的问题，导致申请均匀耗时较长。
3.1.4 CDN部署优化计划
问题起因定位后，解决方案比较简单，正当调整CDN边缘节点部署：
1.新增广东、北京本省节点；
2.新增湖南、四川、吉林、江苏本省节点，替换外省冗余节点。
3.1.5 CDN 部署优化成果
CDN域名cdn.poizon.com 优化前后数据：
均匀耗时
- iOS：429ms -> 331ms，升高98ms
- Android：386ms -> 348ms，升高38ms
3.2 TLS1.3降级
一次残缺的Https网络申请蕴含7个阶段：申请筹备、 DNS 解析、TCP建连、SSL握手、Request阶段、服务端解决阶段、Response阶段
为了更具体的剖析得物CDN资源申请性能数据，咱们在App端将每次申请各阶段的耗时进行了独自埋点采样上报，CDN网络监控平台提供了按网络申请阶段聚合量化的性能指标。因而，对网络申请各阶段的监控数据进行剖析，看是否有可优化的阶段。
3.2.1 从 网络 申请阶段维度剖析 CDN 资源申请耗时 监控 数据
网络申请阶段耗时详情如下图
从图中能够看到，SSL阶段均匀耗时127ms+，占累积耗时25%以上。SSL阶段耗时对整体耗时影响较大，因而思考对SSL阶段性能优化。
对于Https申请，SSL阶段次要是进行密钥协商，保证数据加密传输的。目前得物CDN资源申请应用的是TLS1.2协定，而最新的TLS1.3协定也曾经比拟成熟，是否能够通过降级TLS1.3协定来实现对SSL阶段性能优化的目标呢？
3.2.2 TLS1.3协定调研
TLS1.3协定有哪些劣势？与TLS1.2协定的区别？
TLS（Transport Layer Security Protocol）是传输层平安协定，TLS1.2协定2008年公布，TLS1.3协定2018年公布。
TLS1.2协定目前应用最宽泛，从2008年公布到当初13年多的工夫里被发现了一些毛病：
1.性能较差：握手过程须要2个RTT；
2.安全性较低：应用了不平安的加密算法，如SHA1，RC4，CBC等加密算法。
TLS1.3协定则是基于TLS1.2进行了大量优化，包含：
1.性能优化：引入了新的密钥协商机制PSK，握手过程仅需1RTT，比TLS1.2协定升高50%+；
2.安全性进步：废除了TLS1.2协定中泛滥不平安及老旧的加密算法，不再应用DSA证书，ServerHello之后的握手信息都进行了加密等。
友商应用TLS1.3的状况调研
调研友商的CDN资源申请TLS协定，友商App应用的TLS1.3协定，验证了TLS1.3协定的可行性。
通过Chrome浏览器加载友商的图片，在DevTools窗口的Security面板能够看到应用的是TLS1.3协定。
客户端双端TLS1.3兼容性调研
双端支流机型已反对TLS1.3，且不反对TLS1.3的机型阿里云CDN服务也做了兼容，会依据客户端应用的TLS协定版本主动匹配应用对应的TLS协定。
线下测试：应用Debug包在线下环境别离应用TLS1.3协定与TLS1.2协定申请CDN资源，均申请失常。
3.2.3 TLS1.3降级优化计划
TLS1.3相比TLS1.2能够将SSL阶段耗时升高50%+，因而采纳降级TLS1.3协定的形式实现对CDN资源申请SSL阶段耗时的优化，具体优化计划能够参考之前公布的一篇文章《得物网络优化-TLS1.3降级最佳实际》https://mp.weixin.qq.com/s/C0...
3.2.4 TLS1.3降级优化成果
CDN cdn.poizon.com降级TLS1.3后，双端均匀耗时、TLS耗时均有明显降低，优化前后数据：
均匀耗时
- iOS：281ms -> 237ms，升高44ms
- Android：307ms -> 269ms，升高38ms
SSL阶段耗时
- iOS：210ms -> 137ms，升高73ms
- Android：83ms -> 71ms，升高12ms
3.3 OCSP Stapling开启
TLS1.3降级后，CDN资源申请性能晋升了不少，但双端SSL阶段耗时仍然有优化空间，因而持续调研SSL阶段的优化计划。通过调研后发现SSL阶段证书替换须要应用OCSP协定验证SSL证书的有效性。那什么是OCSP协定呢？OCSP协定是否会对SSL阶段性能造成影响？
3.3.1 什么是OCSP协定？
OCSP（Online Certificate Status Protocol）是在线证书状态协定，用于验证SSL证书的有效性，确保SSL证书未被撤消或过期。CA服务器提供了在线查问证书状态的接口，客户端能够在SSL阶段实时向CA服务器发动一次证书状态查问申请，CA服务器会回复证书的状态信息（如“无效”，“过期”等）。
因为客户端在期待查问后果前是阻塞的，OCSP查问过程耗时长短就影响了SSL阶段耗时。
执行OCSP协定的一次申请过程如下图
从图中能够看到，客户端会多出一次OCSP的查问过程。为了解决OCSP协定对性能的影响，OCSP Stapling协定应运而生，上面介绍下OCSP Stapling协定。
3.3.2 什么是OCSP Stapling协定？相比OCSP做了什么优化？
OCSP Stapling是将证书状态的查问过程从客户端迁徙到服务端，由服务端低频执行OCSP协定申请CA服务器查问证书状态并将查问后果缓存起来，服务端在客户端申请SSL阶段时将证书查问后果返回给客户端。
执行OCSP Stapling协定的一次申请过程如下图
从图中能够看到，执行OCSP Stapling协定后客户端能够节俭一次OCSP查问过程。
3.3.3 OCSP Stapling开启优化调研
友商应用OCSP Stapling的状况调研
调研友商的CDN资源申请OCSP Stapling应用状况，友商的CDN服务已开启OCSP Stapling，验证了OCSP Stapling的可行性。
友商的CDN服务是否OCSP Stapling失效的验证办法：
步骤1：查问友商CDN域名（如：cdn.xxx.com）的IP，能够应用dig命令
dig cdn.xxx.com
步骤2：通过openssl命令查看友商CDN域名OCSP Stapling状态
openssl s_client -connect 步骤1查到的ip:443 -servername cdn.xxx.com -status
后果1：OCSP Stapling失效图片如下：
能够看到OCSP Response Status：successful（0x0），代表OCSP Stapling已失效
后果2：OCSP Stapling未失效图片如下：
能够看到OCSP Response：no response sent，代表OCSP Stapling未失效
客户端双端OCSP Stapling兼容性调研
iOS：零碎默认反对OCSP Stapling
Android：暂不反对OCSP过程
阿里云CDN兼容性：
与阿里云客服已确认阿里云CDN服务反对OCSP Stapling性能。如果客户端零碎反对OCSP Stapling性能，则开启后OCSP Stapling性能失效；如果客户端零碎不反对，仍然反对应用OCSP形式失常申请。
线下测试：应用Debug包在线下环境别离开启OCSP Stapling与敞开OCSP Stapling申请CDN资源，均申请失常。次要笼罩这些方面：
1.重复验证：包含重复开启/敞开，App冷/热启动，App切前后端等操作链路；
2.业务主链路回归：笼罩社区首页、社区详情页、视频、交易首页、商品详情页、订单详情页等外围页面；
3.兼容性测试：笼罩App最近版本，支流机型、支流零碎等。
3.3.4 OCSP Stapling开启优化计划
通过操作阿里云CDN控制台开启OCSP Stapling性能来实现SSL阶段耗时进一步优化。
变更执行：凌晨2点在阿里云CDN控制台操作开启OCSP Stapling
验证计划：如上文形容友商调研办法，应用openssl命令查看CDN域名cdn.poizon.com OCSP Stapling状态是否失效
监控计划：
1.网络监控平台：监控申请异样率、申请耗时等指标是否有异样稳定状况；
2.阿里云CDN-实时监控：分钟级2xx,3xx,4xx,5xx状态码是否有异样稳定状况。
3.3.5 OCSP Stapling开启优化成果
CDN cdn.poizon.com开启阿里云OCSP Stapling后iOS端耗时升高显著，Android端变动不大（Android：暂不反对OCSP过程，因而OCSP Stapling优化对Android暂无作用），优化前后数据：
均匀耗时（仅建连）
iOS：565ms ->484ms，升高81ms
Android：401ms -> 360ms，升高41ms
SSL阶段耗时
iOS：97ms -> 87ms，升高10ms
Android：79ms -> 70ms，升高9ms
3.4 HTTP2.0降级
3.4.1 从Http协定版本维度进行监控数据分析
查看CDN域名cdn.poizon.com 2021.11.30号单日监控数据，发现双端同时存在Http2.0、Http1.1两种协定版本的申请，因而从Http一些版本的维度进行监控数据分析。
查看双端Http2.0与Http1.1占比
iOS：Http2.0占比51.98%，Http1.1占比48.01%
Android：Http2.0占比76.46%，Http1.1占比23.53%
能够看到双端都存在20%以上的Http1.1流量。
查看双端Http2.0与Http1.1各自的TCP复用率
iOS：Http2.0 TCP复用率9217%，Http1.1 TCP复用率396%
Android：Http2.0 TCP复用率2397%，Http1.1 TCP复用率681%
发现双端Http2.0的TCP复用率比Http1.1的TCP复用率高出几倍， iOS 端差不多高一个量级
注：TCP复用率 = TCP连贯复用次数 / TCP建连胜利次数
因为TCP每次从新建连都须要通过DNS解析、TCP三次握手、SSL四次握手阶段的耗时，而TCP连贯复用时则节俭了这三个阶段的耗时，复用TCP连贯的CDN资源申请耗时更短。也就是说TCP复用率越高，CDN资源申请的均匀耗时越短。
讲到这里，可能很多同学就提出了疑难，为什么Http2.0的TCP复用率能够达到这么高呢？上面咱们简略介绍下Http2.0协定。
3.4.2 什么是Http2.0协定
Http2.0有哪些劣势？相比Http1.1的区别是什么？
Http1.1协定仍是应用最宽泛的Http协定，但其存在的痛点也家喻户晓，包含：
1.申请拥塞：并发的每个申请都须要一个TCP连贯，并且最多6个，超过则会拥塞期待；
2.头部冗余：不反对头部压缩，且每次申请都会反复传递头部，造成带宽节约并影响性能；
3.单向传输：仅反对客户端向服务端发送，不反对服务端被动向客户端发送；
4.明文传输：反对Http形式申请，数据明文传输，存在平安危险；
5.优先级受限：同一个TCP连贯上仅反对串行发送，不反对高优先级申请率先发送，影响性能。
Http2.0协定是对http1.1协定的拓展和优化，引入了帧的概念，在应用层与传输层之间增加了二进制分帧层，针对性的提出了几点新个性：
1.多路复用：解决Http1.1申请拥塞的痛点，并发的多个申请反对在同一个TCP连贯上进行传输，每个申请都会被拆分成一个个的帧，帧头信息会保留对应的申请信息，以二进制模式传输到对端后会依据帧头信息将申请数据进行重组；
2.头部压缩：解决Http1.1头部冗余的痛点，一方面应用HPACK算法对头部进行压缩减小传输体积，另一方面在双端保护Headers表，对已传输过的头部仅需携带对应key，防止反复传输；
3.服务端推送：解决Http1.1单向传输的痛点，容许服务端向客户端被动推送数据，如html申请时，服务端会被动向客户端推送相干的css，js文件，防止客户端屡次申请，升高整体RT耗时；
4.二进制传输：解决Http1.1明文传输的痛点，数据被封装成帧，帧再以二进制模式进行传输；
5.反对优先级：解决Http1.1优先级受限的痛点，新建的流应用报文帧设置优先级，已创立的流应用优先级帧类型设置优先级，在资源无限的状况下应用优先级抉择Stream流进行传输；
友商应用Http2.0状况调研
调研友商的CDN资源申请Http协定版本，友商App都应用的Http2.0协定，验证了Http2.0协定的可行性。
与TLS1.3协定友商调研办法相似，通过Chrome浏览器加载友商的图片，在DevTools窗口的Network面板能够看到应用的是h2协定。
3.4.3 Http2.0降级优化计划
对CDN域名cdn.poizon.com Http1.1协定版本申请的CDN边缘节点的IP剖析后发现非阿里云CDN，与运维同学确认后得悉CDN域名cdn.poizon.com切了40%流量在七牛云CDN，应用的Http1.1协定。
能够采纳将这部分七牛云的流量进行Http2.0降级来晋升CDN资源申请性能，执行线上变更将流量切回阿里云CDN（已开启Http2.0协定）。
3.4.4 Http2.0降级优化成果
CDN域名cdn.poizon.com流量切回阿里云后，https1.1流量已转为https2.0，https2.0流量占比双端均95%+，优化前后数据：
均匀耗时
- iOS 248ms -> 221ms，升高27ms
- Android 350ms -> 329ms，升高21ms
TCP复用率
- iOS：841% -> 5127%，升高4286%
- Android：1441% -> 2160%，升高719%
4.小结
以上4个优化方向能够让你以较少的人力投入取得比较显著的CDN资源申请性能晋升，但因波及到线上变更，要留神做好线下回归测试，线上变更、验证、监控、还原计划。
最初，感激运维，测试及相干参加同学在CDN资源申请优化过程中的帮助。
文/Aix
关注得物技术，做最潮技术人！