面对日益简单的技术世界，App 在开发、上线和运维阶段所遭逢的问题也越来越多。这些不拘一格的问题可能来自整个链路的任意环节，而不仅仅是代码层面。

对于开发者来说，排查伎俩曾经不再局限于构建代码过程中的调试，往往须要裁减排查办法，从多种路径对问题进行剖析和定位。这篇文章会和大家分享 mPaaS 开发者的一例小程序网络性能问题排查之旅。

问题背景

“笑联科技”反馈基于 mPaaS 开发的 App 中，其集成的小程序拜访客户自建的 Web API 存在连贯慢的性能问题。问题复现视频如下：

▶播放问题复现视频

从问题复现的状况看，关上小程序后，页面数据的加载有一个“漫长”的期待过程。

和开发者沟通后理解到，页面初始化所必须的局部数据是通过自有的 Web API 获取到的，数据返回慢会导致页面加载的期待。另外开发者也提到，这个问题存在地域性和偶发性，既局部地区的局部用户在一段时间内会被这个问题重大困扰。

问题剖析与排查

如前文所述，数据是通过 Web API 获取的，天然咱们心愿通过内部伎俩去确认这个 Web API 自身是否存在性能问题。

然而，通过浏览器或 Postman 等工具去拜访该 Web API，均无奈复现问题，后端的响应都是毫秒级。然而因为开发者提到该问题存在地域性和偶发性，因而无奈间接排除局部起因。

因为咱们并不是 App 的间接开发者，对于这类问题，一种惯例的伎俩是抓取 HTTP 报文来察看和了解 App 背地的行为特色。比拟侥幸的是，咱们的测试用 iOS 手机能够复现问题，通过 Charles 抓取 App 报文，咱们有如下发现：

Web API 的地址为：https://api.xiaolianhb.com/；

当 Charles 开启 SSL Decryption 时（中间人解密 HTTPS Body 模式），问题无奈复现。

当 Charles 敞开 SSL Decryption 时，问题能够复现，数据加载显著存在一个 3s 的期待状况。

上述景象 2 和 3 强烈暗示问题可能和 HTTPS/SSL 协定层面相干（开启 SSL Decryption 时，HTTPS 连贯由 Mac 笔记本和服务器进行；敞开 SSL Decryption 时，HTTPS 连贯由 iPhone 和服务器进行）。

对于 SSL 层面的问题，则须要抓取 TCP 报文做进一步的确认和剖析。应用 Wireshark 进行网络层抓包（根本抓包步骤：iPhone 失常接入网络；iPhone 通过数据线连贯到 Mac 上，并对手机网卡搭建一个虚构映射；Wireshark 在该映射上进行抓包；具体步骤参考这里）。

问题复现并抓取到相干报文后，首先确认问题，如下图所示：

通过上图日志能够看到，在 TLS 握手阶段，客户端在流程上提早了 3s 才把 Client Key Exchange 音讯发给服务端，而失常状况下，不应该存在如此漫长的期待状况。于此同时，开发者在 Debug 包上的前端嵌入调试也确认了相干状况，如下图所示：

接下来须要搞清楚，客户端为何在握手阶段期待了如此之久以及这 3s 期间客户端在做什么？放开网络包过滤条件后，通过浏览网络包的上下文，咱们有了进一步的发现，如下图所示：

在上图中，能够看到客户端始终尝试与一个 IP 为 243.185.187.39 的站点建设 TCP 连贯，但均遭逢失败。这里会有两个疑难：1. 这个站点是干什么的？2. 为何客户端要在 TLS 握手过程中先去连该站点？

通过同一个网络包中的 DNS 查问记录，尝试反查该 IP 对应的域名地址，发现该站域名为：a771.dscq.akamai.net：

通过公网搜寻该域名，得悉这个域名是 Let’s Encrypt（寰球最大的收费证书机构）证书的 OCSP (Online Certificate Status Protocol，用于校验证书状态) 地址，但须要进一步确认该证据。在网络包中，查看服务端返回证书帧的详细信息，确认证书的 OCSP 地址为 http://ocsp.int-x3.letsencrypt.org：

因为该 OCSP 地址和网络包中看到的不统一，本地通过 nslookup 再进一步确认：a771.dscq.akamai.net 是 ocsp.int-x3.letsencrypt.org 的一个 CNAME 地址（这种配置个别为了站点减速）:

联合上述情况和公开材料，能够确认在 3s 的期待期内，客户端尝试去连贯证书提供的 OCSP 站点地址，用意确认证书的撤消状态。仔细观察会发现，本地解析出的 IP 地址和手机端抓包看到的 IP 地址是不一样的，这里大概率是 Let’s Encryped 证书的 OCSP 地址被“净化”导致的。

到这里，咱们能够看到问题的小结为：客户端须要和 https://api.xiaolianhb.com/ 建设 HTTPS 连贯，在 TLS 握手阶段，客户端无奈连上该站点证书提供的 OCSP 地址，因而无奈确认证书的撤消状态，3s 后触发超时放行机制，客户端和站点失常建设 HTTPS 连贯，申请发送和数据返回流程得以进行。

既然 Let’s Encrypt 证书的 OCSP 域名被“净化”曾经成为事实，因而，要解决该问题，最快的解决方案是更换站点证书，保障 TLS 握手流程的顺畅。

小结

在这个案例中，咱们能够看到有些时候，问题和代码、SDK 亦或是零碎 Bug 并无间接关联，异常情况可能来自一个意想不到的中央。

回到问题症状上，更进一步的疑难是：为何桌面浏览器或网络工具受影响较小？为何 Android 手机不受影响？这些症状细节上的差别，均和不同零碎或工具对协定的实现模式相干。

开发者很难在一开始的布局阶段就能把这些细枝末节的问题都预估到，因而，呈现问题之后，深刻的问题分析配合日志解读往往是了解程序行为背地逻辑的重要伎俩。

CodeDay#5：深刻摸索支付宝终端

在过来的一年中，咱们通过与泛滥终端开发者在能力对接、需要沟通中发现，愈来愈多的研发团队面临业务需要暴发时难以找到无效的形式进行高并发撑持。

大家的问题呈现出了共性特色：如何实现动静公布？如何进一步晋升研发效率？支付宝是否有最佳实际？

因而，此次 CodeDay 咱们把焦点放在“支付宝终端”，尝试通过 4 个议题分享，率领大家理解支付宝作为一款超级 App，如何借助容器化技术实现动静公布、更新能力，并积淀出一套可复用的技术体系。

点我立刻报名

1 月 23 日，咱们广州见。

延长浏览

• 最新流动：CodeDay#5 启动报名| 带你深刻摸索支付宝终端动态化实际
• 技术干货 ：“选图预览并上传”的场景如何解？全网最全计划汇总来了
• 客户案例： 笑联 x mPaaS | 12 个模块，全面小程序化，如何打造真正的一次开发复用多端？