面對日益複雜的技術世界，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 連接配接，在 TLS 握手階段，用戶端無法連上該站點證書提供的 OCSP 位址，是以無法确認證書的吊銷狀态，3s 後觸發逾時放行機制，用戶端和站點正常建立 HTTPS 連接配接，請求發送和資料傳回流程得以進行。
既然 Let's Encrypt 證書的 OCSP 域名被“污染”已經成為事實，是以，要解決該問題，最快的解決方案是更換站點證書，保證 TLS 握手流程的順暢。
小結
在這個案例中，我們可以看到有些時候，問題和代碼、SDK 亦或是系統 Bug 并無直接關聯，異常情況可能來自一個意想不到的地方。
回到問題症狀上，更進一步的疑問是：為何桌面浏覽器或網絡工具受影響較小？為何 Android 手機不受影響？這些症狀細節上的差異，均和不同系統或工具對協定的實作形式相關。
開發者很難在一開始的規劃階段就能把這些細枝末節的問題都預估到，是以，出現問題之後，深入的問題剖析配合日志解讀往往是了解程式行為背後邏輯的重要手段。
CodeDay#5：深入探索支付寶終端
在過去的一年中，我們通過與衆多終端開發者在能力對接、需求溝通中發現，愈來愈多的研發團隊面臨業務需求爆發時難以找到有效的方式進行高并發支撐。
大家的問題呈現出了共性特征：如何實作動态釋出？如何進一步提升研發效率？支付寶是否有最佳實踐？
是以，此次 CodeDay 我們把焦點放在“支付寶終端”，嘗試通過 4 個議題分享，帶領大家了解支付寶作為一款超級 App，如何借助容器化技術實作動态釋出、更新能力，并沉澱出一套可複用的技術體系。
點我立即報名1 月 23 日，我們廣州見。
延伸閱讀
- 最新活動：CodeDay#5 啟動報名｜ 帶你深入探索支付寶終端動态化實踐
- 技術幹貨：“選圖預覽并上傳”的場景如何解？全網最全方案彙總來了
- 客戶案例：笑聯 x mPaaS | 12 個子產品，全面小程式化，如何打造真正的一次開發複用多端？