本文由得物技術(shù)厲飛雨、GavinX分享，原題“得物App白屏優(yōu)化系列｜網(wǎng)絡(luò)篇”，下文進(jìn)行了排版和內(nèi)容優(yōu)化。
1、引言
圖片加載作為重中之重的App體驗(yàn)指標(biāo)，端側(cè)的白屏問題則是其中最為嚴(yán)重、也是最為常見的問題之一。想象一下如果你在瀏覽交易商品、社區(qū)帖子等核心場景下，圖片無法完成加載是多么糟糕的體驗(yàn)。
如上圖所示，通過線上白屏問題歸因，我們看到網(wǎng)絡(luò)問題導(dǎo)致比例最高，占比達(dá)81.97%。除去常見的弱網(wǎng)/無網(wǎng)等問題外，還有很多各種各樣的網(wǎng)絡(luò)環(huán)境問題我們是可以進(jìn)行優(yōu)化的，例如設(shè)備不支持IPv6，CDN節(jié)點(diǎn)異常，證書超時等。
本文將要分享的是得物技術(shù)團(tuán)隊(duì)針對移動端最常見的圖片加載導(dǎo)致的端側(cè)白屏問題，而進(jìn)行的的移動網(wǎng)絡(luò)方向的技術(shù)優(yōu)化實(shí)踐，希望能帶給你啟發(fā)。
2、網(wǎng)絡(luò)優(yōu)化和監(jiān)控概覽
網(wǎng)絡(luò)優(yōu)化與監(jiān)控體系：
3、網(wǎng)絡(luò)監(jiān)控能力
3.1概述
網(wǎng)絡(luò)異常導(dǎo)致的圖片白屏問題，往往和當(dāng)時的環(huán)境有關(guān)，例如用戶連的WIFI不支持IPv6但是DNS返回的大部分是V6的IP等，此時僅靠幾條帶有SocketTimeoutException的網(wǎng)絡(luò)日志根本無法排查出問題的根因，就如同ANR問題需要火焰圖一樣，白屏問題同樣需要一套完善的監(jiān)控體系來記錄問題現(xiàn)場的信息，從而分析問題根因。
3.2OkHttp基礎(chǔ)監(jiān)控
圖片網(wǎng)絡(luò)請求的階段信息，可以通過實(shí)現(xiàn)OkHttp自帶的EventListener來獲取，在各個階段開始和結(jié)束點(diǎn)記錄下時間戳即可。
其中需要重點(diǎn)關(guān)注connectFailed、requestFailed和responseFailed這三個失敗的回調(diào)，他們都會在失敗之后重試，并重復(fù)執(zhí)行階段開始的回調(diào)（例如connectStart)，因此針對這些需要單獨(dú)記錄好每一次失敗信息，避免被覆蓋。
例如某個圖片請求TCP建連失敗的記錄：
3.3APM流量監(jiān)控
盡管我們有專門的網(wǎng)絡(luò)診斷工具，但是考慮到網(wǎng)絡(luò)異常的滯后性，故障往往是數(shù)十秒之前引入的（例如進(jìn)電梯弱網(wǎng)），而發(fā)生問題之后才觸發(fā)的網(wǎng)絡(luò)診斷結(jié)果僅能作為參考，并不能作為最終問題歸因的證據(jù)。
因此我們需要一個更直觀的表達(dá)用戶設(shè)備網(wǎng)絡(luò)狀況的數(shù)據(jù)，那就是通過系統(tǒng)API獲取的當(dāng)前App流量消耗，在排除了一些本地socket通信產(chǎn)生的干擾之后，最近N秒之內(nèi)消耗的流量/N就可以認(rèn)為是白屏問題發(fā)生時的網(wǎng)速。
我們以3秒為間隔分段計(jì)算并取最大值來排除波動，這樣我們就得到了白屏問題發(fā)生前一段時間內(nèi)的網(wǎng)速狀態(tài)，過低的就可以判定為弱網(wǎng)/無網(wǎng)。
網(wǎng)速計(jì)算示意圖：
3.4CDN異常記錄
CDN廠商側(cè)的異常，例如服務(wù)器IP跨省，節(jié)點(diǎn)掛了等問題相對少見，在網(wǎng)絡(luò)日志中通常就表現(xiàn)為建連超時但是網(wǎng)絡(luò)正常，因此需要收集多個Host的請求記錄進(jìn)行橫向?qū)Ρ葋泶_認(rèn)是單個CDN廠商的問題。
為此我們記錄了主站接口的域名，以及所有CDN域名在最近N分鐘內(nèi)的請求統(tǒng)計(jì)，包括了正常請求、慢請求、失敗請求的數(shù)量和原因，以及失敗請求使用的具體IP。
例如圖中可以看到某CDN的請求全部都是建連失敗，而其他CDN以及我們主站域名請求均正常，那么此問題可以歸類為該CDN的單點(diǎn)問題，聯(lián)系CDN服務(wù)商剔除該IP所在節(jié)點(diǎn)即可解決問題。
3.5網(wǎng)絡(luò)庫請求緩存
常規(guī)的網(wǎng)絡(luò)監(jiān)控方案為了節(jié)省內(nèi)存，會在請求結(jié)束時將其從內(nèi)存緩存隊(duì)列中移除，而白屏問題因?yàn)槠錅笮裕挥性谄聊恢写竺娣e出現(xiàn)白圖才會被判定，此時再去查詢加載失敗的圖片網(wǎng)絡(luò)請求日志自然早已被移出隊(duì)列，因此需要單獨(dú)使用一個LRU隊(duì)列來緩存最近N條網(wǎng)絡(luò)日志，圖片庫同理。
3.6網(wǎng)絡(luò)診斷工具
在逐步解決用戶問題的過程中，我們研發(fā)了網(wǎng)絡(luò)診斷工具，實(shí)現(xiàn)了基礎(chǔ)網(wǎng)絡(luò)信息采集、Ping、TraceRoute等。
當(dāng)檢測到用戶發(fā)生白屏?xí)r自動觸發(fā)網(wǎng)絡(luò)診斷：
1）單域名診斷流程：我們會依次進(jìn)行DNS、Http、Ping（ICPM）與Ping（TCP）、TraceRoute診斷。如果是雙棧客戶端（同時返回了IPv4與IPv6），那么我們會選擇首個IPv4與首個IPv6同時進(jìn)行Ping/TraceRoute以確認(rèn)不同IP類型的聯(lián)通情況。
2）多域名診斷流程：同時對3個得物核心域名發(fā)起診斷。為了輔助判斷，當(dāng)?shù)梦锖诵挠蛎\斷失敗時，也會對一些主流三方域名稍微Ping一下。
3）診斷數(shù)據(jù)的上報：由于網(wǎng)絡(luò)診斷可能耗時10秒以上，而如此長的時間內(nèi)用戶如果退出App那我們的診斷數(shù)據(jù)可能就丟失了。因此，任意一個小階段的診斷完成時，我們就立即上報此結(jié)果，以避免此類情況的發(fā)生。
4、CDN質(zhì)量監(jiān)控
4.1概述
CDN作為整體白屏問題中重要的一環(huán)。在白屏排查過程中，經(jīng)常遇到接口正常，但CDN訪問異常的case。而多云CDN的質(zhì)量問題往往依賴于云廠商，如何衡量和監(jiān)控云廠商的CDN情況成為了關(guān)鍵，故我們自定義了端側(cè)的CDN質(zhì)量指標(biāo)體系以及配合云廠商推進(jìn)云端策略的優(yōu)化。
4.2CDN質(zhì)量大盤
在白屏監(jiān)控平臺側(cè)，我們經(jīng)常能夠發(fā)現(xiàn)用戶側(cè)的CDN單點(diǎn)問題，往往存在跨省、跨運(yùn)營商調(diào)度的情況，或者是單節(jié)點(diǎn)的高負(fù)載響應(yīng)超時。故我們基于此情況記錄了端側(cè)的本地IP&CDN遠(yuǎn)端IP，建設(shè)了CDN質(zhì)量大盤。
核心指標(biāo)如下:
依賴CDN質(zhì)量大盤，我們可以橫向、縱向?qū)Σ煌茝S商服務(wù)進(jìn)行CDN質(zhì)量評估工作，由于端側(cè)實(shí)際發(fā)起的總請求數(shù)量統(tǒng)計(jì)成本高、到CDN側(cè)的請求存在丟失等情況，我們采用了端側(cè)采樣上報、統(tǒng)計(jì)還原的思路，將得物側(cè)的整體CDN指標(biāo)大盤采樣放大比例為1 / 千分之三（當(dāng)前采樣比例）。過程指標(biāo)的確會收到采樣用戶質(zhì)量的影響，但整體CDN趨勢、各廠商CDN的橫向?qū)Ρ冗€是有很大的參考意義的。
平臺截圖展示:
如果說端側(cè)CDN指標(biāo)是對CDN質(zhì)量抽象評估的長周期指標(biāo)，那么云端監(jiān)控則是CDN質(zhì)量的精確告警的短時效指標(biāo)。
這部分就是一些較為常見的策略與手段了，如CDN節(jié)點(diǎn)撥測、CPU負(fù)載監(jiān)控、異常錯誤碼監(jiān)控等，并協(xié)同SRE團(tuán)隊(duì)將其同飛書通知打通，實(shí)現(xiàn)及時告警。
4.3.1）節(jié)點(diǎn)撥測：
CDN節(jié)點(diǎn)撥測整體指定的圖片撥測閾值當(dāng)前限制在200ms。
4.3.2）節(jié)點(diǎn)監(jiān)控：
關(guān)于到節(jié)點(diǎn)后的請求監(jiān)控，主要依賴于云廠商的監(jiān)控能力，我們也協(xié)同云廠商對核心指標(biāo)的告警閾值等進(jìn)行了調(diào)優(yōu)，核心主要為:
此處思考一個問題，如果建連請求無法抵達(dá)CDN節(jié)點(diǎn)，那么即使CDN廠商開啟了TCP級日志，也無法監(jiān)測到此異常，也就無法及時進(jìn)行調(diào)度調(diào)整。
故對于非到節(jié)點(diǎn)的建聯(lián)問題，基于TCP建連進(jìn)行監(jiān)控是很有必要的，我們基于客戶端建連的監(jiān)控?cái)?shù)據(jù)，以用戶網(wǎng)絡(luò)環(huán)境（網(wǎng)絡(luò)運(yùn)營商，地域）視角，分析建連過程是否正常，及時發(fā)現(xiàn)異常連接線路，并通過推動CDN服務(wù)商調(diào)整區(qū)域DNS返回來恢復(fù)正常。
監(jiān)控指標(biāo)如下：
建聯(lián)失敗、異常率：
建聯(lián)p50、p99耗時分布：
5、網(wǎng)絡(luò)問題優(yōu)化治理1：DNS策略優(yōu)化
5.1概述
從網(wǎng)絡(luò)監(jiān)控、白屏監(jiān)控中我們可以清楚的觀察到DNS錯誤是網(wǎng)絡(luò)階段導(dǎo)致白屏的最大因素。此外，DNS錯誤是所有網(wǎng)絡(luò)錯誤中最多的，甚至可以占比80%以上。
連續(xù)DNS錯誤導(dǎo)致白屏：
5.2LocalDNS行為
為什么DNS階段如此脆弱，是我們使用不當(dāng)，還是其本身性能如此？我們首要做的是觀察下Android平臺下LocalDNS的行為邏輯以確認(rèn)性能較差的原因。
5.2.1）按照TTL緩存：
通過不停的向系統(tǒng)進(jìn)行查詢DNS，在抓包中，我們很容易觀察到DNS的查詢邏輯。其中一個重要參數(shù)是TTL（Time to Live），這個參數(shù)表明當(dāng)前查詢結(jié)果的有效時間。比如說TTL=7，表明在7秒鐘內(nèi)當(dāng)前結(jié)果是有效的、可被緩存的，即使7秒鐘內(nèi)再次查詢，依然是此結(jié)果。
Android平臺嚴(yán)格遵守了此協(xié)議，按照TTL進(jìn)行緩存。而較短的有效時間，也意味著我們需要進(jìn)行域名查找時（冷熱啟動），大概率系統(tǒng)內(nèi)沒有緩存可用。
DNS TTL與查詢頻率：
通常TTL設(shè)置為120秒以內(nèi)，這是因?yàn)橐紤]到節(jié)點(diǎn)故障，能夠快速切換。而到端側(cè)查詢時，TTL會在0~120之間。低于120是因?yàn)槲覀儾樵兇私Y(jié)果的DNS server自身已經(jīng)緩存了一定的時間。
5.2.2）雙棧客戶端同時查詢：
雙棧客戶端上，同時發(fā)起A類（IPv4）、AAAA類（IPv4）查詢。
某運(yùn)營商5G網(wǎng)絡(luò)下DNS查詢及響應(yīng)：
當(dāng)兩類查詢都成功響應(yīng)時，Android會將兩類結(jié)果組合起來排序后返回給應(yīng)用層。無論是A類地址先返回，還是AAAA類地址先返回，Android都會將IPv6地址放在前面（劃重點(diǎn)，后面要考）。
-- app.dewu.com 的DNS查詢結(jié)果
[app.dewu.com/2405:e000:1004:1::f3ff:4b49, app.dewu.com/203.107.32.125]
可以看到電信的LocalDNS服務(wù)器并未遵守TTL時間（app.dewu.com 的 TTL為60），而是進(jìn)行了額外的緩存。這是部分運(yùn)營商為了降低客戶端的查詢頻率（降成本）而搞出的小把戲，不在我們的討論范圍內(nèi)。
5.2.3）DNS數(shù)據(jù)包錯誤與重試：
我們將DNS服務(wù)器設(shè)置為一個虛假的DNS服務(wù)器，來觀察Android平臺在DNS未返回時的重試邏輯。
DNS重試（主、備、隱藏款）：
可以看到，0秒時向主DNS服務(wù)器發(fā)起查詢，5秒向備DNS服務(wù)器發(fā)起查詢，8秒向114發(fā)起查詢。
現(xiàn)在我們想一下，在我們DNS查詢時，只要0秒的第一次查詢向主沒有正常返回（比如丟包），即使備選正常，能成功查詢到結(jié)果也是5秒鐘后的事情了，而這意味著用戶在5秒內(nèi)無法正常的請求網(wǎng)絡(luò)。然后，用戶熟練的打開設(shè)置、點(diǎn)擊用戶反饋、選擇白屏、輸入些表達(dá)欣喜的文字、提交！（嘿，來活了）
那么我們能否通過多次查詢來觸發(fā)系統(tǒng)來同時發(fā)起多個查詢請求呢？
不行。當(dāng)前Android內(nèi)有一個同步柵欄，多個線程同時查詢一個Host，只會允許一個通過。如果成功時，全部被阻攔的查詢一同返回結(jié)果；如果失敗時，再允許一個查詢。也就是說，在這5秒內(nèi)，我們只能靜靜的等著，讓用戶也等著。
主/備DNS服務(wù)器我們可以通過在設(shè)置中修改，而114這個隱藏款只出現(xiàn)在部分國產(chǎn)品牌上，不同品牌內(nèi)置的隱藏備用DNS服務(wù)器也并不相同。
5.2.4）iOS平臺的DNS行為：
眾所周知，iOS平臺下的DNS異常率遠(yuǎn)遠(yuǎn)低于Android，甚至差了一個數(shù)量級。
iOS為何如此優(yōu)秀？
- 1）較長的緩存時長：當(dāng)DNS的TTL較低時（比如3秒），iOS會忽略TTL值，直接緩存1分鐘以上；
- 2）積極的重試邏輯：只要1秒內(nèi)未收到響應(yīng)立即進(jìn)行多次重試，其中主DNS 6次，備DNS 8次。
5.3DNS優(yōu)化
通過對LocalDNS的行為分析，我們看到Android平臺下的LocalDNS查詢極其不可靠，好在我們并非只能通過LocalDNS來解析IP。任何將域名轉(zhuǎn)換為IP的手段都可以使用，比如通過http獲取、磁盤緩存等。
在LocalDNS的基礎(chǔ)上，我們增加了HttpDNS，磁盤緩存來優(yōu)化DNS問題。其中HttpDNS在第60ms異步啟動，磁盤緩存在第6秒鐘時異步啟動。三種查詢方式任意一個返回，則DNS結(jié)束。
5.3.1）HttpDNS：
我們實(shí)現(xiàn)Http進(jìn)行DNS查詢，并將其作為備用DNS使用。在LocalDNS 60ms未成功返回時，異步啟動HttpDNS進(jìn)行查詢。這將能解決LocalDNS下主DNS失敗5秒后才會進(jìn)行下一次重試的弊端。
HttpDNS的實(shí)現(xiàn)方式，我們暫時選擇接入成熟的三方HttpDNS，快速解決用戶在DNS方面的困境是主要原因之一。
當(dāng)然，也并非全部域名通過HttpDNS查詢都會有效果，比如localhost、IP地址等就需要從HttpDNS的查詢中排除。
同步柵欄：當(dāng)存在單個host的多個查詢線程時，僅允許第一個線程查詢，其他全部等待查詢結(jié)果。（類似于Android系統(tǒng)對多線程同時查詢時的處理）
5.3.2）磁盤緩存：
DNS查詢成功時，我們將查詢結(jié)果緩存到磁盤上。在LocalDNS、HttpDNS都未如期返回時，將磁盤上緩存的結(jié)果返回給應(yīng)用層。如此以來，只要?dú)v史上這個用戶查詢成功過，我們始終不會失敗在DNS階段。
需要注意的是：在磁盤上緩存IP時，需要按照網(wǎng)絡(luò)類型、運(yùn)營商進(jìn)行緩存。原因是不同網(wǎng)絡(luò)下的最佳IP往往不同，比如同一個CDN域名中國移動的CDN節(jié)點(diǎn)與中國電信的CDN節(jié)點(diǎn)會在各自的機(jī)房里。如果我們不分開存儲，那么用戶網(wǎng)絡(luò)切換后，我們磁盤緩存出的IP或許可用，但可能不是最佳（延遲更高）。
此外，我們的磁盤緩存也完全忽略了DNS TTL。原因是我們將磁盤緩存作為其他DNS查詢?nèi)渴『蟮亩档资侄问褂茫侵饕侄巍＜词筎TL過期的IP可能會存在一些問題，但也不會有更壞的結(jié)果了。
5.2.3）收益情況：
通過線上實(shí)驗(yàn)觀察到，DNS異常率降低了60%以上。
不同配置下的DNS異常率對比：
6、網(wǎng)絡(luò)問題優(yōu)化治理2：IPv6故障修復(fù)
6.1概述
前文提到對于雙棧客戶端，Android會將IPv6地址放在前面返回給應(yīng)用層。本意上，IPv4地址即將枯竭而向IPv6過渡的方式，而這恰恰是Android平臺在TCP建連階段時遇到的最大問題。
用戶A-DNS結(jié)果：
我們來看一個例子：用戶A訪問 cdn.poizon.com 是DNS共響應(yīng)了10個IPv6、10個IPv4，然而此用戶IPv6無法訪問，且給個IPv6都是建連10秒后超時，最終導(dǎo)致用戶在第100秒時才在第11個IPv4地址上成功。
RFC6555 摘要：
正如 RFC6555 摘要中描述的那樣，當(dāng)服務(wù)器的 IPv4 路徑和協(xié)議正常，但I(xiàn)Pv6 路徑和協(xié)議不工作時，相對于IPv4單棧客戶端，雙棧客戶端會經(jīng)歷顯著的連接延遲。而這個延遲通常是10秒以上（IPv6的個數(shù)和建連超時時間的乘積）。
那么如何優(yōu)化？
最簡單的方式是禁用IPv6，簡單到甚至只需要運(yùn)維動動小手即可。但是由于眾所周知的原因，我們國內(nèi)對于推動IPv6十分積極，對于IPv6的濃度動不得。
最合理的方式自然是按照RFC6555描述的那樣實(shí)現(xiàn)快樂眼球算法，但是開發(fā)成本和風(fēng)險都較大。而線上時而有類似反饋。因此我們決定分兩步走，先上線低風(fēng)險的IPv6探測&重排序解壓此困境，再實(shí)現(xiàn)快樂眼球算法。
OkHttp5.x 已支持RFC6555，但是目前尚未正式發(fā)布。且得物歷史上對源碼的修改較多，整體遷移到5.x成本較高。
6.2IPv6探測 & 重排序
此實(shí)現(xiàn)的思路是既然IPv6可能故障，那么提前探測潛在故障。通過調(diào)整即將建連的IP列表的順序來解決客戶端建連到IPv4的延遲問題。
此實(shí)現(xiàn)在DNS查詢成功之后，建連之前。因?yàn)椴簧婕靶薷腛kHttp源碼修改所以風(fēng)險可控。
1）IPv6探測：如果IP列表中同時包含IPv6&IPv4，則對第一個IPv6地址同步進(jìn)行Ping探測。如果250ms內(nèi)探測成功或曾經(jīng)探測成功，則認(rèn)為IPv6正常。
2）重排序：如果IPv6暢通，則按照IPv6優(yōu)先進(jìn)行交叉排序。如果IPv6故障，則按照IPv4優(yōu)先進(jìn)行交叉排序。
# 重排序前
[
"imagex-cdn.dewu.com\/2409:8c54:b010:b:8000:0:b00:13",
"imagex-cdn.dewu.com\/2409:8c54:b010:b:8000:0:b00:10",
"imagex-cdn.dewu.com\/183.240.183.19",
"imagex-cdn.dewu.com\/183.240.183.15"
]
# 重排序后（IPv6探測失敗）
[
"imagex-cdn.dewu.com\/183.240.183.19",
"imagex-cdn.dewu.com\/2409:8c54:b010:b:8000:0:b00:13",
"imagex-cdn.dewu.com\/183.240.183.15",
"imagex-cdn.dewu.com\/2409:8c54:b010:b:8000:0:b00:10"
]
# 重排序后（IPv6探測成功）
[
"imagex-cdn.dewu.com\/2409:8c54:b010:b:8000:0:b00:13",
"imagex-cdn.dewu.com\/183.240.183.19",
"imagex-cdn.dewu.com\/2409:8c54:b010:b:8000:0:b00:10",
"imagex-cdn.dewu.com\/183.240.183.15"
]
IPv6探測 & 重排序 流程圖：
6.3快樂眼球（HappyEyeball）
當(dāng)前DNS返回的IP地址數(shù)量超過一個時，每250ms異步啟動一個新的TCP建連，任意一個TCP建連成功，則斷開其他TCP并開始同步TLS建連。
- 1）TLS 建連成功則返回此Connection，流程結(jié)束；
- 2）TLS 建連失敗時，如果是可恢復(fù)的TLS失敗（部分SSLException），則立即重試；
- 3）如果是不可恢復(fù)失敗，則再次啟動其他TCP的競速。
核心修改點(diǎn)是原流程的建連部分。原流程中，在網(wǎng)絡(luò)線程中同步的、依次進(jìn)行TCP、TLS建連。新流程中，將TCP與TLS建連分開，競速建連TCP，TCP建連完成后建連TLS。
1）OkHttp3.x 建連流程：
注：OkHttp3.x 的nextRoute之間的循環(huán)在RetryAndFlow實(shí)現(xiàn)
2）OkHttp-HappyEyeball建連流程：
具體實(shí)現(xiàn)方式可以參考OkHttp5.x 代碼。
收益情況：自IPv6優(yōu)化上線后，再無相關(guān)IPv6相關(guān)用戶反饋。
7、CDN質(zhì)量問題治理概述
從白屏監(jiān)控大盤中可以看到，CDN的問題可能只占據(jù)1%~2%，但是不同于通用網(wǎng)絡(luò)問題，用戶憑持著其他App可以用，但是得物App為什么白屏的疑問，是極容易引起線上反饋的一種case。
故我們也是協(xié)同SRE團(tuán)隊(duì)、云廠商一起做了一些優(yōu)化手段，力爭在現(xiàn)有條件下將端側(cè)的圖片CDN質(zhì)量調(diào)整到最優(yōu)。
8、CDN質(zhì)量問題治理1：返回IP策略優(yōu)化
從網(wǎng)絡(luò)優(yōu)化來看，DNS優(yōu)化以及IPv6探測&重排序?yàn)槲覀兘鉀Q了雙棧IPv6問題、單IP不可用等問題，但CDN問題本身由于不同省份、不同區(qū)域等節(jié)點(diǎn)數(shù)量、網(wǎng)絡(luò)硬件質(zhì)量均存在差異，這部分是端側(cè)無法彌補(bǔ)的，故我們想到了優(yōu)化CDN返回IP策略的思路來規(guī)避以上問題。
返回IP優(yōu)化策略：
過程中考慮到得物IPv6濃度問題，最早期是返回了3個v4 IP、3個v6 IP的策略，但發(fā)現(xiàn)v6 IP數(shù)量變多后，由于LocalDNS天然會把v6 IP排放在v4 IP前面。此舉在沒有建連競速優(yōu)化的老版本下，會導(dǎo)致v6不通的建連時間被逐步拉長30s。故我們在盡可能保證v6濃度的情況下，將返回的v6 IP數(shù)量降低到了2個。
由于v6 IP優(yōu)先請求的情況，我們考慮優(yōu)先保證v6 IP的本省同大區(qū)覆蓋，故對v6 IP的本省的大區(qū)返回粒度會比v4 IP更細(xì)些。
跨省調(diào)度問題：
- 1）針對v4 IP本省2個大區(qū)至少返回2個IP；
- 2）針對v6 IP本省1個大區(qū)至少返回1個IP。
單ip返回、v4不返回問題：
- 1）針對v4 IP至少返回3個；
- 2）針對v6 IP至少返回2個。
9、CDN質(zhì)量問題治理2：云廠商優(yōu)化策略
為了保證圖片CDN的節(jié)點(diǎn)質(zhì)量，我們積極同CDN廠商進(jìn)行溝通協(xié)作，進(jìn)行了部分優(yōu)化嘗試。
9.1圖片專屬節(jié)點(diǎn)
將原有云廠商的圖片、視頻、文件等通用節(jié)點(diǎn)，遷移至圖片專屬的L1節(jié)點(diǎn)，最大程度保證圖片請求穩(wěn)定性和效率。
9.2H2協(xié)議棧優(yōu)化
過去發(fā)現(xiàn)請求耗時增大的一個case是H2弱網(wǎng)阻塞，在低質(zhì)量的網(wǎng)絡(luò)環(huán)境下使用HTTP/2協(xié)議時可能遇到的性能問題或阻塞問題。
云廠商均多次調(diào)整了H2協(xié)議棧的算法優(yōu)化邏輯，并對比了優(yōu)化前后的慢請求監(jiān)控情況。
觀察調(diào)整省份節(jié)點(diǎn)水平，調(diào)整后平均耗時下降15%、慢請求率下降23%左右。
請求耗時大于5000ms的優(yōu)化情況：
9.3節(jié)點(diǎn)動態(tài)剔除細(xì)化
我們針對云廠商的到端鏈路監(jiān)控以及白屏用戶反饋的潛在非到端問題，通過平臺歸因1min內(nèi)的CDN請求 & 網(wǎng)絡(luò)診斷的情況，并經(jīng)過人工確認(rèn)為CDN單通問題后，進(jìn)行節(jié)點(diǎn)剔除切換，優(yōu)先處理節(jié)點(diǎn)抖動帶來的影響面問題。
具體是：
- 1）CDN節(jié)點(diǎn)的可用性探測判斷節(jié)點(diǎn)持續(xù)抖動并最終剔除的時效在15min內(nèi)；
- 2）白屏反饋用戶的sop應(yīng)急響應(yīng)剔除時效從2~3小時降低到30min內(nèi)。
10、 CDN質(zhì)量問題治理3：CA證書問題
10.1概述
除了建連階段的問題外，TLS等證書認(rèn)證問題上也有較多的用戶反饋，同時白屏平臺也有較多類似的錯誤。
歷史為了優(yōu)化SSL耗時過長、證書認(rèn)證安全等問題，接口、圖片域名均開啟了ocsp的功能，但實(shí)際監(jiān)控發(fā)現(xiàn)部分用戶存在本地時間不對齊的情況，即超過了CA證書 ocsp校驗(yàn)的有效期（一般7天） 或者超過了域名的證書有效期（一般2年）。此類用戶會導(dǎo)致所有圖片請求均被證書攔截而無法完成請求最終引發(fā)白屏。
10.2ocsp問題
主要是：
- 1）TLS耗時開啟前后并無實(shí)際收益，對于網(wǎng)絡(luò)耗時的優(yōu)化可忽略不計(jì)；
- 2）證書的安全性問題，由于圖片域名訪問為CDN資源非接口核心信息，關(guān)閉風(fēng)險可控；
- 3）對比主流站點(diǎn)的ocsp開啟情況，主流App的圖片域名大多未開啟。
ocsp的當(dāng)前時間和下次更新時間：
故我們最終關(guān)閉了圖片域名的ocsp功能，整體請求異常數(shù)、請求耗時并無劣化且圖片ocsp的問題反饋數(shù)逐步清零。
10.3域名CA證書替換失效問題
得物目前有100+的域名，CA證書的申請對于CA機(jī)構(gòu)來說，一般在證書有效期小于30天時會進(jìn)行新證書的簽發(fā)流程，且證書有效期以申請期時間為準(zhǔn)。但過往的證書有效期更新替換后，往往會面臨時間前置的用戶無法通過CA證書校驗(yàn)，最終引起用戶白屏。
我們協(xié)同運(yùn)維側(cè)制定了較為嚴(yán)格的圖片域名證書更新時效期，并在多個主域名按此標(biāo)準(zhǔn)落地。
具體是：
- 1）證書30天到期自動告警能力，及時跟進(jìn)證書審批事項(xiàng)；
- 2）證書替換選擇在有效期提前3天，避免無規(guī)律的申請即更新的情況。
11、 本文小結(jié)
網(wǎng)絡(luò)問題作為用戶白屏的主要原因之一，如果不能及時針對性的優(yōu)化將對大量用戶產(chǎn)生困擾。
我們在以解決用戶白屏為目標(biāo)的行動中，逐步完善了客戶端網(wǎng)絡(luò)監(jiān)控、云端CDN監(jiān)控。并在此過程中完成DNS、建連、證書、運(yùn)營商調(diào)度等方面的優(yōu)化，杜絕了某些特定錯誤的發(fā)生，保障了更多用戶的網(wǎng)絡(luò)體驗(yàn)。
近期我們會繼續(xù)推出一篇介紹如何在客戶端監(jiān)控白屏問題，以及平臺如何對白屏問題自動化歸因的文章，敬請期待。
12、 參考資料
[1] 網(wǎng)絡(luò)編程懶人入門(十一)：一文讀懂什么是IPv6
[2] IPv6技術(shù)詳解：基本概念、應(yīng)用現(xiàn)狀、技術(shù)實(shí)踐（上篇）
[3] 網(wǎng)絡(luò)編程入門從未如此簡單(三)：什么是IPv6？漫畫式圖文，一篇即懂！
[4] 不為人知的網(wǎng)絡(luò)編程(九)：理論聯(lián)系實(shí)際，全方位深入理解DNS
[5] 移動端IM開發(fā)者必讀(一)：通俗易懂，理解移動網(wǎng)絡(luò)的“弱”和“慢”
[6] 淘寶移動端統(tǒng)一網(wǎng)絡(luò)庫的架構(gòu)演進(jìn)和弱網(wǎng)優(yōu)化技術(shù)實(shí)踐
[7] 得物自研移動端弱網(wǎng)診斷工具的技術(shù)實(shí)踐分享
[8] 全面了解移動端DNS域名劫持等雜癥：原理、根源、HttpDNS解決方案等
[9] 美圖App的移動端DNS優(yōu)化實(shí)踐：HTTPS請求耗時減小近半
[10] 移動端網(wǎng)絡(luò)優(yōu)化之HTTP請求的DNS優(yōu)化
[11] 百度APP移動端網(wǎng)絡(luò)深度優(yōu)化實(shí)踐分享(一)：DNS優(yōu)化篇
[12] 百度APP移動端網(wǎng)絡(luò)深度優(yōu)化實(shí)踐分享(二)：網(wǎng)絡(luò)連接優(yōu)化篇
[13] 愛奇藝移動端網(wǎng)絡(luò)優(yōu)化實(shí)踐分享：網(wǎng)絡(luò)請求成功率優(yōu)化篇
[14] 美團(tuán)點(diǎn)評的移動端網(wǎng)絡(luò)優(yōu)化實(shí)踐：大幅提升連接成功率、速度等
[15] 騰訊原創(chuàng)分享(一)：如何大幅提升移動網(wǎng)絡(luò)下手機(jī)QQ的圖片傳輸速度和成功率
[16] 騰訊原創(chuàng)分享(二)：如何大幅壓縮移動網(wǎng)絡(luò)下APP的流量消耗（上篇）
[17] iOS端移動網(wǎng)絡(luò)調(diào)優(yōu)的8條建議
[18] 腦殘式網(wǎng)絡(luò)編程入門(五)：每天都在用的Ping命令，它到底是什么？
13、 得物技術(shù)團(tuán)隊(duì)的其它文章匯總
得物從0到1自研客服IM系統(tǒng)的技術(shù)實(shí)踐之路
得物自研客服IM中收發(fā)聊天消息背后的技術(shù)邏輯和思考實(shí)現(xiàn)
得物從零構(gòu)建億級消息推送系統(tǒng)的送達(dá)穩(wěn)定性監(jiān)控體系技術(shù)實(shí)踐
得物基于Electron開發(fā)客服IM桌面端的技術(shù)實(shí)踐
得物自研移動端弱網(wǎng)診斷工具的技術(shù)實(shí)踐分享
（本文已同步發(fā)布于：http://www.52im.net/thread-4700-1-1.html）