技術乾貨 | mPaaS 客戶端問題排查：漫長的 3s 等待之謎

面對日益複雜的技術世界，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 日，咱們廣州見。