共计 7031 个字符，预计需要花费 18 分钟才能阅读完成。
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
关注得物技术，做最潮技术人！
