本文由得物技術(shù)厲飛雨分享削锰，原題“得物App弱網(wǎng)診斷探索之路”，下文進(jìn)行了排版和內(nèi)容優(yōu)化旺矾。
1蔑鹦、引言
隨著得物用戶規(guī)模和業(yè)務(wù)復(fù)雜度不斷提升，端上網(wǎng)絡(luò)體驗(yàn)優(yōu)化已逐步進(jìn)入深水區(qū)箕宙。為了更好地保障處于弱網(wǎng)狀態(tài)下得物App用戶的使用體驗(yàn)嚎朽，我們?cè)谝延械木W(wǎng)絡(luò)體驗(yàn)大盤、網(wǎng)絡(luò)診斷工具的基礎(chǔ)上研發(fā)了弱網(wǎng)診斷能力柬帕。該工具能夠高效實(shí)時(shí)診斷用戶真實(shí)網(wǎng)絡(luò)環(huán)境哟忍，同時(shí)給出精確網(wǎng)絡(luò)質(zhì)量分級(jí)，為后續(xù)App各業(yè)務(wù)場(chǎng)景進(jìn)行針對(duì)性優(yōu)化做好基礎(chǔ)建設(shè)保障陷寝。
本文將基于得物自研的移動(dòng)端弱網(wǎng)診斷工具的開發(fā)過(guò)程锅很，盡可能全面地為你總結(jié)和分享它的具體技術(shù)實(shí)踐，希望帶給你啟發(fā)凤跑。
* 推薦閱讀：淘寶技術(shù)團(tuán)隊(duì)分享的《淘寶移動(dòng)端統(tǒng)一網(wǎng)絡(luò)庫(kù)的架構(gòu)演進(jìn)和弱網(wǎng)優(yōu)化技術(shù)實(shí)踐》爆安，可一并閱讀。
2仔引、網(wǎng)絡(luò)性能概念
一些網(wǎng)絡(luò)性能指標(biāo)：
1）速率：指?jìng)魉蛿?shù)據(jù)的速率扔仓。速率是計(jì)算機(jī)網(wǎng)絡(luò)中最重要的性能指標(biāo)，單位是b/s(比特每秒咖耘，也寫作bps 当辐，即bit per second )。速率較高時(shí)可寫作kbps鲤看，mbps缘揪。
2）帶寬：帶寬用來(lái)表示網(wǎng)絡(luò)的通信線路傳送數(shù)據(jù)的能力，表示在單位時(shí)間內(nèi)從網(wǎng)絡(luò)中的某一點(diǎn)到另一點(diǎn)所能通過(guò)的“最高速率”义桂。
3）吞吐量（throughput）：表示在單位時(shí)間內(nèi)通過(guò)某網(wǎng)絡(luò)的數(shù)據(jù)量找筝。吞吐量常用于對(duì)網(wǎng)絡(luò)的一種測(cè)量。吞吐量受網(wǎng)絡(luò)帶寬或者速率限制慷吊。例如袖裕，對(duì)于一個(gè)100Mb/s的網(wǎng)絡(luò)，其額定速率是100Mb/s溉瓶，那么該數(shù)值是此網(wǎng)絡(luò)的吞吐量的上限急鳄，其吞吐量可能只有70Mb/s。
4）時(shí)延：指數(shù)據(jù)從網(wǎng)絡(luò)上的一端傳輸?shù)搅硪欢怂枰臅r(shí)間堰酿。
5）往返時(shí)間RTT（Round-Trip Time）：表示從發(fā)送方發(fā)送數(shù)據(jù)開始疾宏，到發(fā)送方收到接收方的確認(rèn)，總共經(jīng)歷的時(shí)間触创。
6）HttpRTT：指從客戶端請(qǐng)求的第一個(gè)字節(jié)開始發(fā)送到收到第一個(gè)數(shù)據(jù)包響應(yīng)的時(shí)間差坎藐。這個(gè)時(shí)間包含3個(gè)部分，客戶端發(fā)送數(shù)據(jù)到服務(wù)器耗時(shí)、服務(wù)器處理耗時(shí)岩馍、服務(wù)器響應(yīng)數(shù)據(jù)到客戶端耗時(shí)碉咆。
弱網(wǎng)診斷觀察的指標(biāo)（弱網(wǎng)診斷根據(jù)HttpRTT和吞吐量來(lái)觀察用戶網(wǎng)絡(luò)環(huán)境）：
1）HttpRTT：在不考慮服務(wù)器處理耗時(shí)的情況下，能夠體現(xiàn)用戶請(qǐng)求被處理的真實(shí)時(shí)延蛀恩。
2）吞吐量（throughput）：用戶的額定速率能被系統(tǒng)提供的API獲取到疫铜，然而其僅能表示設(shè)備能夠提供的最大速率（一般很大），卻不是真實(shí)速率双谆，而測(cè)量真實(shí)的吞吐量更能體現(xiàn)出用戶當(dāng)前真實(shí)網(wǎng)絡(luò)環(huán)境块攒。
3、整體架構(gòu)
本次實(shí)現(xiàn)的是被動(dòng)弱網(wǎng)診斷佃乘，也就是不主動(dòng)發(fā)起探測(cè)請(qǐng)求囱井，被動(dòng)采集App內(nèi)的全部網(wǎng)絡(luò)請(qǐng)求，再根據(jù)一定在策略計(jì)算出用戶網(wǎng)絡(luò)環(huán)境趣避。
相對(duì)于主動(dòng)探測(cè)庞呕，被動(dòng)探測(cè)不會(huì)浪費(fèi)用戶資源。
尤其是在吞吐量計(jì)算方面程帕，主動(dòng)探測(cè)不僅會(huì)消耗用戶流量住练，還可能會(huì)對(duì)正在進(jìn)行中的用戶網(wǎng)絡(luò)請(qǐng)求產(chǎn)生影響。而且當(dāng)用戶網(wǎng)絡(luò)環(huán)境不佳時(shí)愁拭，負(fù)向影響更加嚴(yán)重讲逛。
以下為被動(dòng)網(wǎng)絡(luò)診斷的整體架構(gòu)圖：
4、采集層實(shí)現(xiàn)1：HttpRTT采集
4.1概述
HttpRTT的采集比較簡(jiǎn)單岭埠，各端根據(jù)自身Http協(xié)議棧的實(shí)現(xiàn)獲取到從寫入requestHeader開始盏混，到收取responseHeader的時(shí)間差即可。
對(duì)于Android：我們通過(guò)OkHttp完成Http請(qǐng)求惜论，通過(guò)向OkHttp注冊(cè)網(wǎng)絡(luò)監(jiān)聽即可實(shí)現(xiàn)许赃。
需要說(shuō)明的是：在不修改源碼的情況下，Android無(wú)法獲取到收到第一個(gè)響應(yīng)數(shù)據(jù)包的時(shí)間馆类，只能監(jiān)聽到Header讀取完成混聊，這會(huì)有些許誤差，但實(shí)測(cè)下來(lái)可以忽略乾巧。
對(duì)于其他客戶端內(nèi)通過(guò)自行實(shí)現(xiàn)Http協(xié)議棧發(fā)起的網(wǎng)絡(luò)請(qǐng)求（如PCDN）句喜，我們通過(guò)向其注冊(cè)特定的監(jiān)聽回調(diào)，也能獲取到HttpRTT沟于。
4.2采集樣本過(guò)濾
HttpRTT包含了服務(wù)器處理時(shí)間咳胃，而當(dāng)服務(wù)器處理時(shí)間過(guò)長(zhǎng)或過(guò)低時(shí)對(duì)其他普遍意義上的Http請(qǐng)求參考價(jià)值相對(duì)較低。
因此我們需要排除這些數(shù)據(jù)：
1）localhost：如果向localHost發(fā)起請(qǐng)求社裆，且響應(yīng)的僅是緩存的數(shù)據(jù)拙绊，那么其HttpRTT時(shí)延明顯接近于0向图；
2）PUT請(qǐng)求：由于PUT請(qǐng)求傳輸?shù)臄?shù)據(jù)量一般較大泳秀，其HttpRTT明顯高于其他标沪；
3）其他明顯偏離的數(shù)據(jù)。
5嗜傅、采集層實(shí)現(xiàn)2：吞吐量（throughput）采集
5.1概述
throughput(bit/s , bps) = 單位時(shí)間內(nèi)通過(guò)的數(shù)據(jù)量(bit) / 單位時(shí)間(s)
吞吐量的采集相對(duì)要復(fù)雜得多金句，吞吐量采集目的是獲取用戶所能使用的最大的數(shù)據(jù)率（或帶寬），因而其需要在設(shè)備上恰好有大量數(shù)據(jù)正在傳輸時(shí)采集吕嘀。
對(duì)于主動(dòng)探測(cè)來(lái)說(shuō)违寞，在無(wú)其他請(qǐng)求干擾的情況下，主動(dòng)發(fā)起一個(gè)大數(shù)據(jù)量CDN下載請(qǐng)求即可快速測(cè)量出吞吐量偶房。而被動(dòng)探測(cè)則需要想辦法預(yù)測(cè)或檢測(cè)到大量數(shù)據(jù)傳輸?shù)臅r(shí)刻趁曼，并適時(shí)計(jì)算吞吐量。
5.2時(shí)間窗口
怎樣選取計(jì)算吞吐量的時(shí)間窗口是計(jì)算吞吐量準(zhǔn)確性的關(guān)鍵棕洋。
這個(gè)窗口要恰好在大量數(shù)據(jù)正在傳輸時(shí)挡闰，不能早也不能晚：
1）如果提前開啟了時(shí)間窗口，那么同樣的大小的數(shù)據(jù)通過(guò)掰盘，由于分母增大會(huì)導(dǎo)致計(jì)算出的數(shù)值偏低摄悯；
2）如果數(shù)據(jù)傳輸完成后，稍晚關(guān)閉時(shí)間窗口愧捕，那么同樣會(huì)由于分母增大而導(dǎo)致計(jì)算出的數(shù)值偏低奢驯。
我們知道Http請(qǐng)求或多或少會(huì)有上行/下行數(shù)據(jù)，但由于服務(wù)器處理耗時(shí)長(zhǎng)短的不確定性（不能算在分母里）次绘，單個(gè)Http請(qǐng)求測(cè)速時(shí)并不可靠瘪阁。
而多個(gè)Http正在并發(fā)請(qǐng)求進(jìn)行中的時(shí)候，其請(qǐng)求的流量會(huì)疊加邮偎，單個(gè)請(qǐng)求的服務(wù)器耗時(shí)會(huì)被其他Http請(qǐng)求覆蓋罗洗，此時(shí)采集吞吐量會(huì)是個(gè)好的選擇。因此钢猛，我們可以在監(jiān)聽到Http并發(fā)請(qǐng)求數(shù)量達(dá)到5個(gè)以上時(shí)采集吞吐量伙菜。
時(shí)間串口的選擇（忽略建連耗時(shí)）：
可以看出，當(dāng)并發(fā)較多時(shí)命迈，服務(wù)器耗時(shí)會(huì)被覆蓋贩绕，每個(gè)時(shí)間窗口內(nèi)存在約4個(gè)Http請(qǐng)求的響應(yīng)數(shù)據(jù)。
我們始終監(jiān)聽App內(nèi)的全部Http請(qǐng)求壶愤，當(dāng)監(jiān)控到有5個(gè)及以上的網(wǎng)絡(luò)請(qǐng)求尚未完成時(shí)淑倾，也就是Http并發(fā)5個(gè)以上，開啟時(shí)間窗口征椒；當(dāng)時(shí)間窗口已開啟且任意一個(gè)請(qǐng)求結(jié)束時(shí)娇哆，我們結(jié)束當(dāng)前時(shí)間窗口。
需要注意的是：當(dāng)我們結(jié)束一個(gè)時(shí)間窗口的時(shí)候，需要立刻檢測(cè)當(dāng)前并發(fā)是否5個(gè)以上碍讨，而不是等到新的請(qǐng)求到來(lái)時(shí)治力，這樣能避免類似上圖的采樣機(jī)會(huì)被浪費(fèi)掉，而采樣成功的樣本數(shù)越多勃黍，越有利于最終結(jié)論的準(zhǔn)確性（后面策略層會(huì)講原因）宵统。
可行性：我們的App內(nèi)能滿足5個(gè)并發(fā)以上嗎？
當(dāng)然可以覆获。通過(guò)觀察線下測(cè)試和線上數(shù)據(jù)分析马澈，我們App內(nèi)的并發(fā)數(shù)能夠滿足吞吐量采集的必要條件。舉個(gè)例子弄息，進(jìn)入商詳一次的并發(fā)量就能滿足痊班。
用戶A啟動(dòng)90秒內(nèi)Http并發(fā)數(shù)量（線上數(shù)據(jù)）：
5.3數(shù)據(jù)量
分母（單位時(shí)間）的問(wèn)題解決了，分子（單位時(shí)間內(nèi)通過(guò)的數(shù)據(jù)量）如何取值呢摹量？
思路是：
1）思路1：當(dāng)前時(shí)間窗口內(nèi)并行的Http通過(guò)的Reponse數(shù)據(jù)量辩块；
2）思路2：設(shè)備內(nèi)所傳輸?shù)臄?shù)據(jù)量；
3）思路3：當(dāng)前網(wǎng)卡傳輸?shù)臄?shù)據(jù)量荆永。
先說(shuō)思路1：這個(gè)實(shí)現(xiàn)上需要我們?cè)跁r(shí)間窗口開始時(shí)記錄全部Http請(qǐng)求已傳輸?shù)淖止?jié)數(shù)废亭，時(shí)間窗口關(guān)閉時(shí)再記錄一次，然后把當(dāng)前并行的Http請(qǐng)求時(shí)間窗口內(nèi)的數(shù)據(jù)量全部累加起來(lái)具钥。這意為著我們要時(shí)刻監(jiān)控每一個(gè)Http請(qǐng)求中每個(gè)字節(jié)的讀取豆村，成本太高了。另一方面骂删，如果有其他非Http請(qǐng)求（或者我們App之外的請(qǐng)求）也在進(jìn)行掌动，我們僅測(cè)算App內(nèi)Http請(qǐng)求的吞吐量顯然是偏低的。因此宁玫，思路1不合適粗恢。
再說(shuō)思路2：相對(duì)合適。我們要測(cè)算的就是設(shè)備的吞吐量欧瘪。因?yàn)榧词故茿pp外的流量眷射，其也會(huì)有結(jié)束的時(shí)候，總能為我們所用（除非用戶對(duì)我們App單獨(dú)做帶寬限制）佛掖。
相對(duì)于獲取設(shè)備內(nèi)的全部流量妖碉，獲取網(wǎng)卡的流量則更為合適：
1）原因1：部分系統(tǒng)已經(jīng)支持WIFI與蜂窩并行請(qǐng)求，如果當(dāng)前使用的是WIFI芥被，將App外的蜂窩流量測(cè)算進(jìn)去會(huì)導(dǎo)致偏差欧宜。
2）原因2：網(wǎng)絡(luò)切換時(shí)，處于舊網(wǎng)絡(luò)上的請(qǐng)求不會(huì)立即釋放拴魄，而新的請(qǐng)求會(huì)發(fā)生在新的網(wǎng)絡(luò)上冗茸，此時(shí)設(shè)備內(nèi)的通過(guò)的流量是多網(wǎng)卡的累積席镀。
需要注意的是系統(tǒng)API返回的是字節(jié)數(shù)（byte），而我們計(jì)算的是bit夏漱，因此計(jì)算吞吐量時(shí)需要進(jìn)行換算豪诲。
5.4臟數(shù)據(jù)過(guò)濾
前面講到“并發(fā)5個(gè)時(shí)，每個(gè)時(shí)間窗口內(nèi)可以采集到約4個(gè)Http請(qǐng)求的響應(yīng)數(shù)據(jù)”麻蹋，然而運(yùn)氣并不會(huì)始終這樣好跛溉。
窗口掛起：
如上圖所示：時(shí)間窗口1內(nèi)僅兩個(gè)有效的response焊切，時(shí)間窗口2內(nèi)僅一個(gè)有效的response扮授，其計(jì)算出的吞吐量必然是偏低的。因此专肪，臟數(shù)據(jù)過(guò)濾就顯得十分重要刹勃。
1）小數(shù)據(jù)量過(guò)濾：
時(shí)間窗口內(nèi)通過(guò)的流量小于32KB時(shí)，不會(huì)產(chǎn)生準(zhǔn)確的速率嚎尤，我們直接忽略這次采樣荔仁。要知道，一個(gè)圖片的數(shù)據(jù)量都可能會(huì)超過(guò)32KB芽死。
2）低利用率過(guò)濾：
低利用率是指由于數(shù)據(jù)需求較小乏梁，導(dǎo)致當(dāng)前速率遠(yuǎn)未達(dá)到最大吞吐率的情況。如上圖時(shí)間窗口1关贵，對(duì)于一個(gè)未被充分利用的網(wǎng)絡(luò)遇骑，我至少希望一個(gè)HttpRTT的時(shí)間內(nèi)接收到的數(shù)量大于15KB。
// 窗口是否掛起
fun isHangingWindow(bitsRx: Long, duration: Long): Boolean {
????val kCwndSizeBits = 10 * 1.5 * 1000 * 8
????val multiplier = 1
????val httpRTT = ????//由Http RTT模塊計(jì)算
????val bitsReceivedOverOneHttpRtt = bitsRx * httpRTT / duration
????return?bitsReceivedOverOneHttpRtt < kCwndSizeBits * multiplier
}
為什么是15KB 揖曾？如果TCP連接剛剛建立落萎，由于Linux系統(tǒng)的默認(rèn)設(shè)置，客戶端能夠同時(shí)發(fā)送10個(gè)數(shù)據(jù)段炭剪，每個(gè)數(shù)據(jù)段時(shí)1460字節(jié)练链，合計(jì)也就是15KB。
6奴拦、策略層實(shí)現(xiàn)
到這里媒鼓，我們已經(jīng)能采集到很多HttpRTT樣本、throughput樣本了错妖，現(xiàn)在我們要考慮下怎么將這些樣本綜成計(jì)算出一個(gè)可以代表設(shè)備普遍意義上的HttpRTT隶糕、throughput，然后再歸類出設(shè)備網(wǎng)絡(luò)類型（慢的網(wǎng)絡(luò)站玄、一般的網(wǎng)絡(luò)枚驻、快的網(wǎng)絡(luò)、很快的網(wǎng)絡(luò) ...）株旷。
6.1中位數(shù)
首選是選取什么樣的策略將眾多的HttpRTT樣本計(jì)算出最終值再登。
可選方式如下：
中位數(shù)相對(duì)于平均數(shù)等其他統(tǒng)計(jì)量來(lái)說(shuō)尔邓，更適合處理包含極端值、偏態(tài)分布或受到干擾的數(shù)據(jù)集锉矢。
6.2時(shí)間權(quán)重
用戶網(wǎng)絡(luò)質(zhì)量可能隨時(shí)間而發(fā)生變化梯嗽，最新的樣本數(shù)據(jù)更接近于當(dāng)前網(wǎng)絡(luò)環(huán)境。我們對(duì)樣本數(shù)據(jù)施加時(shí)間權(quán)重沽损，樣本數(shù)據(jù)每60秒降低一半權(quán)重灯节，那么越新的樣本權(quán)重越高。
時(shí)間權(quán)重：
60秒半衰期下不同時(shí)間差下的權(quán)重：
6.3信號(hào)強(qiáng)度權(quán)重
同樣的绵估，信號(hào)強(qiáng)度也可能會(huì)隨用戶移動(dòng)位置而發(fā)生變更炎疆，不同信號(hào)強(qiáng)度下的網(wǎng)絡(luò)質(zhì)量也會(huì)不同。
我們將用戶信號(hào)強(qiáng)度劃分為4個(gè)等級(jí)国裳，再根據(jù)信號(hào)強(qiáng)度等級(jí)的變化施加不同的權(quán)重形入。那么，樣本數(shù)據(jù)生成時(shí)的信號(hào)強(qiáng)度與當(dāng)前信號(hào)強(qiáng)度越是接近缝左，其樣本權(quán)重就越高亿遂。
信號(hào)權(quán)重：
目前僅Android且網(wǎng)絡(luò)環(huán)境為WIFI會(huì)計(jì)算信號(hào)強(qiáng)度權(quán)重。
6.4加權(quán)中位數(shù)
最終渺杉，將全部樣本以加權(quán)中位數(shù)的方式蛇数，計(jì)算HttpRTT、throughput是越。而最終權(quán)重由時(shí)間權(quán)重與信號(hào)強(qiáng)度權(quán)重結(jié)合得出耳舅。
綜合權(quán)重：
6.5計(jì)算與緩存
如圖4所示，應(yīng)用網(wǎng)絡(luò)請(qǐng)求并發(fā)量能達(dá)到20+英妓，而啟動(dòng)1分鐘內(nèi)總Http請(qǐng)求數(shù)到達(dá)了450挽放，平均每秒約8個(gè)請(qǐng)求。而我們線下實(shí)測(cè)每次計(jì)算耗時(shí)1~10ms蔓纠，樣本總數(shù)越高時(shí)耗時(shí)也越高辑畦。因此，我們要考慮下如何降低計(jì)算頻率腿倚。
1）適時(shí)計(jì)算：
調(diào)用方總是期望在請(qǐng)求API時(shí)立刻能夠拿到最新的纯出、最準(zhǔn)確的結(jié)果。
一個(gè)簡(jiǎn)單的方式是業(yè)務(wù)請(qǐng)求時(shí)將全部樣本重新計(jì)算一遍敷燎，一開始我們也確實(shí)是這么設(shè)計(jì)的暂筝，然而每次計(jì)算耗時(shí)1~10ms， 這個(gè)對(duì)調(diào)用方來(lái)說(shuō)是顯然是無(wú)法接受硬贯。
那么焕襟，我們真的需要在調(diào)用時(shí)將全部樣本重算一遍嗎？
首先來(lái)說(shuō)饭豹，只有新的計(jì)算結(jié)果和舊的計(jì)算結(jié)果有差異時(shí)鸵赖，我們才需要重新計(jì)算务漩。我們的計(jì)算策略是加權(quán)中位數(shù)，其計(jì)算來(lái)源是樣本總數(shù)它褪、樣本權(quán)重饵骨，而樣本權(quán)重受時(shí)間、信號(hào)強(qiáng)度影響茫打。
具體是：
1）對(duì)于樣本數(shù)居触、信號(hào)強(qiáng)度：其變化時(shí)必然會(huì)引起最終結(jié)果的變化；
2）對(duì)于時(shí)間老赤，通過(guò)單個(gè)請(qǐng)求的時(shí)間權(quán)重公式（圖4）轮洋，我們可以推導(dǎo)出多個(gè)樣本時(shí)，單個(gè)樣本的權(quán)重不會(huì)隨當(dāng)前時(shí)間發(fā)生變化（圖8）诗越，也就是我們無(wú)需考慮時(shí)間流逝對(duì)時(shí)間權(quán)重的計(jì)算影響砖瞧。
單個(gè)樣本的時(shí)間權(quán)重：
那么息堂，我們只需要在樣本數(shù)嚷狞、信號(hào)強(qiáng)度發(fā)生變化時(shí)重新計(jì)算，然后將計(jì)算結(jié)果緩存下來(lái)荣堰。
2）計(jì)算條件：
也并非只要有新樣本生成我們就要重新計(jì)算一遍床未，那樣計(jì)算頻率太高了。
總的來(lái)說(shuō)振坚，當(dāng)有新樣本到來(lái)時(shí)薇搁，重新計(jì)算需滿足以下任意一個(gè)條件：
1）從未計(jì)算出結(jié)果；
2）網(wǎng)絡(luò)類型發(fā)生變更渡八；
3）信號(hào)強(qiáng)度發(fā)生變更啃洋；
4）當(dāng)前時(shí)間較上次計(jì)算大于10秒；
5）Http樣本數(shù)較上次計(jì)算多出50%屎鳍；
6）throughput樣本數(shù)較上次計(jì)算多出50%宏娄。
HttpRTT樣本+throughput樣本合計(jì)增加20以上。
3）網(wǎng)絡(luò)變更監(jiān)聽：
對(duì)于HttpRTT樣本逮壁，throughput樣本，我們各保留最新的300個(gè)。當(dāng)網(wǎng)絡(luò)發(fā)生變更時(shí)我們會(huì)清除全部狗热，因?yàn)榕f的船票不能登上新船滤灯。
7、接口層實(shí)現(xiàn)
現(xiàn)在我們有了具體的HttpRTT忧饭、throughput扛伍，然而大部分業(yè)務(wù)并不需要這些數(shù)字，他們只想知道當(dāng)前網(wǎng)絡(luò)怎么樣词裤，快不快刺洒，有多快汁咏。基于此作媚，我們根據(jù)HttpRTT攘滩、throughput將用戶網(wǎng)絡(luò)劃分為5個(gè)類型，通過(guò)接口提供給上層纸泡。
這里throughput的單位是kbps漂问，如果換算成常見(jiàn)的KB/s，需要除以8女揭。
需要說(shuō)明的是：這里的TYPE_2G并不是指我們手機(jī)信號(hào)里所展示的2G蚤假，而是基于被動(dòng)探測(cè)對(duì)用戶網(wǎng)絡(luò)環(huán)境劃分的結(jié)果。
即使用戶連接的是5G網(wǎng)絡(luò)吧兔，當(dāng)其因信號(hào)不好等其他因素導(dǎo)致RTT較高或throughput較低時(shí)磷仰，也會(huì)被劃分到TYPE_2G。換句話說(shuō)境蔼，這里用TYPE_2G就是表明網(wǎng)絡(luò)很慢灶平，就和很多年前的2G一樣慢。
此外箍土，由于網(wǎng)絡(luò)類型的計(jì)算是在網(wǎng)絡(luò)請(qǐng)求完成時(shí)進(jìn)行的異步計(jì)算逢享，上層通過(guò)接口讀取的始終是緩存，所以無(wú)需考慮調(diào)用時(shí)的性能問(wèn)題吴藻。
8瞒爬、 閾值定義
網(wǎng)絡(luò)類型劃分里有4個(gè)關(guān)鍵數(shù)值：272ms、511ms沟堡、400kpbs侧但、1600kpbs，這些數(shù)組是怎么定義出來(lái)的呢航罗？
1）線下測(cè)試：
首選通過(guò)弱網(wǎng)工具判斷我們的HttpRTT禀横、throughput估算的是否準(zhǔn)確。通過(guò)Round-trip latancy(ms)?增加延遲觀察HttpRTT是否同步改變伤哺，通過(guò)限制Bandwidth(kbps)觀察throughput數(shù)值是否與之一致燕侠。
charless弱網(wǎng)模擬：
2）線上驗(yàn)證：
網(wǎng)絡(luò)監(jiān)控中攜帶當(dāng)前網(wǎng)絡(luò)類型，統(tǒng)計(jì)線上數(shù)據(jù)觀察TYPE_2G立莉、TYPE_3G绢彤、TYPE_4G網(wǎng)絡(luò)請(qǐng)求耗時(shí)表現(xiàn)。
3）反復(fù)實(shí)驗(yàn)：
通過(guò)調(diào)整關(guān)鍵參數(shù)找到最有區(qū)分度的閾值蜓耻。如緩存的樣本總數(shù)越高就表明參照了越多的老數(shù)據(jù)茫舶、時(shí)間權(quán)重半衰期越長(zhǎng)老數(shù)據(jù)的權(quán)重就越高、窗口掛起判定中multiplier越高樣本數(shù)越少結(jié)果越準(zhǔn)確……
通過(guò)實(shí)驗(yàn)數(shù)據(jù)調(diào)整我們預(yù)埋的參數(shù)刹淌，能使判定更加準(zhǔn)確饶氏。
9讥耗、性能指標(biāo)
9.1HttpRTT 數(shù)值計(jì)算
用戶B 全部網(wǎng)絡(luò)請(qǐng)求的首字節(jié)耗時(shí)與nqeHttpRTT：
上圖是線上某用戶B的首字節(jié)耗時(shí)（HttpRTT）與最終計(jì)算出的nqeHttpRTT。單次網(wǎng)絡(luò)請(qǐng)求耗時(shí)會(huì)有波動(dòng)疹启，但nqeHttpRTT維持準(zhǔn)確與穩(wěn)定古程。
注意：
1）nqeHttpRTT指最終估算出的HttpRTT；
2）為優(yōu)化顯示喊崖，圖中縱軸以xx ms為最高值挣磨，實(shí)際上部分請(qǐng)求遠(yuǎn)高于此；
3）nqeHttpRTT未伴隨Http請(qǐng)求出立刻出現(xiàn)是因?yàn)樵\斷模塊啟動(dòng)時(shí)機(jī)較晚荤懂，事實(shí)上nqeHttpRTT得計(jì)算最低只需要5個(gè)完成Head響應(yīng)的Http請(qǐng)求茁裙。
9.2吞吐量（throughput）數(shù)值
用戶B 全部網(wǎng)絡(luò)請(qǐng)求的并發(fā)數(shù)與吞吐率：
上圖是線上某用戶B的并發(fā)數(shù)與吞吐率計(jì)算結(jié)果。并發(fā)5個(gè)以上時(shí)會(huì)采集出一個(gè)以上吞吐率樣本节仿，可以看到我們App內(nèi)的并發(fā)數(shù)能夠滿足我們對(duì)吞吐率的采集需求晤锥，而估算出的吞吐率（nqeKbps）數(shù)值穩(wěn)定。
9.3準(zhǔn)確性判定
大部分調(diào)用方并不關(guān)注具體的HttpRTT廊宪，吞吐量數(shù)值矾瘾，而只關(guān)注我們劃分出的網(wǎng)絡(luò)類型。劃分網(wǎng)絡(luò)類型的準(zhǔn)確性自然是調(diào)用方關(guān)注的重點(diǎn)挤忙。
那么霜威，如何衡量我們的準(zhǔn)確性呢谈喳？換句話說(shuō)册烈，我們判斷為弱網(wǎng)，他真的是弱網(wǎng)嗎?
一個(gè)簡(jiǎn)單的方式是請(qǐng)求耗時(shí)大于500ms算作實(shí)際弱網(wǎng)婿禽，但是業(yè)務(wù)接口的耗時(shí)與CDN的耗時(shí)會(huì)有明顯差異赏僧，500ms明顯不能作為CDN耗時(shí)的弱網(wǎng)衡量標(biāo)準(zhǔn)。
如果我們以單個(gè)接口耗時(shí)500ms作為實(shí)際弱網(wǎng)呢扭倾？也會(huì)存在一些問(wèn)題淀零，比如西藏的用戶與杭州(機(jī)房在這里)的用戶在網(wǎng)絡(luò)延遲上明顯有巨大差異（物理距離決定的）。即使網(wǎng)絡(luò)極佳的西藏用戶膛壹，業(yè)務(wù)接口的耗時(shí)也會(huì)高于網(wǎng)絡(luò)一般的杭州用戶驾中。但是網(wǎng)絡(luò)極佳的西藏用戶訪問(wèn)CDN時(shí)，其耗時(shí)又要優(yōu)于杭州的網(wǎng)絡(luò)一般的用戶模聋。
如果以某省份單接口耗時(shí)大于500ms呢肩民？且不說(shuō)可能以偏概全，就目前而言链方，同一省份的IPv4和IPv6的連接的機(jī)房都可能會(huì)不一樣（有杭州持痰，也有北京）。
.....
1）目前的準(zhǔn)確性判定：
我們以實(shí)際耗時(shí)比50分位網(wǎng)絡(luò)傳播耗時(shí)慢一倍為實(shí)際弱網(wǎng)（判斷準(zhǔn)確）祟蚀，比50分位耗時(shí)小為實(shí)際正常（誤判或其他）工窍。
網(wǎng)絡(luò)耗時(shí)階段：
2）怎么定義實(shí)際弱網(wǎng)割卖？
實(shí)際弱網(wǎng)（請(qǐng)求慢）=（request耗時(shí)+response耗時(shí)）*2+服務(wù)器處理+其他=50分位總耗時(shí)+（request耗時(shí)+response耗時(shí)）
實(shí)際正常（請(qǐng)求快）=（request耗時(shí)+response耗時(shí)）+服務(wù)器處理+其他=50分位總耗時(shí)
3）怎么計(jì)算網(wǎng)絡(luò)傳播耗時(shí)？
網(wǎng)絡(luò)傳播耗時(shí)=request耗時(shí)+response耗時(shí)患雏，即數(shù)據(jù)包在網(wǎng)絡(luò)上傳輸?shù)暮臅r(shí)鹏溯。
具體是：
1）數(shù)據(jù)發(fā)送速率(kbps) = TCP窗口大小 * 8 / RTT(TCP)；
2）數(shù)據(jù)發(fā)送耗時(shí) = 數(shù)據(jù)量 * 8 / 發(fā)送速率淹仑；
3）網(wǎng)絡(luò)傳播耗時(shí) = request + response = RTT + 數(shù)據(jù)發(fā)送耗時(shí)剿涮。
以某接口為例：TCP RTT=50ms，窗口大小=16192攻人，上行字節(jié)數(shù)=4095取试，下行字節(jié)數(shù)=24807，總網(wǎng)絡(luò)耗時(shí)（50分位）=300ms怀吻。
那么：數(shù)據(jù)發(fā)送速率(bps)=16192*8/0.05=2590720(bps)瞬浓、數(shù)據(jù)發(fā)送耗時(shí)=(4095+24807)*8/3598222*1000=89ms、網(wǎng)絡(luò)傳播耗時(shí)=50+89=139ms蓬坡。
最終得出：實(shí)際弱網(wǎng)耗時(shí)（比中位數(shù)多一倍網(wǎng)絡(luò)耗時(shí)）=300+139=439ms猿棉；實(shí)際正常耗時(shí)（小于中位數(shù)）=300ms。
網(wǎng)絡(luò)發(fā)生擁塞時(shí)屑咳，我們以16192作為TCP窗口大腥蕖；以上數(shù)據(jù)全部以50分位計(jì)算兆龙。
9.4線上數(shù)據(jù)
某接口的弱網(wǎng)準(zhǔn)確率：
數(shù)據(jù)說(shuō)明：
1）判斷弱網(wǎng)：指弱網(wǎng)診斷輸出當(dāng)前網(wǎng)絡(luò)類型為弱網(wǎng)杖爽，即HttpRTT類型為2G、3G或吞吐量類型為2G紫皇；
2）判斷弱網(wǎng)-慢請(qǐng)求率：在判斷為弱網(wǎng)的前提下慰安，實(shí)際上慢請(qǐng)求的比例。慢請(qǐng)求指上文中的實(shí)際弱網(wǎng)聪铺，即高于50分位耗時(shí)+網(wǎng)絡(luò)傳播耗時(shí)化焕；
3）判斷弱網(wǎng)-快請(qǐng)求率：在判斷為弱網(wǎng)的前提下，實(shí)際上快請(qǐng)求的比例铃剔∪鼋埃快請(qǐng)求指上文中的實(shí)際正常键兜，即低于50分位耗時(shí)凤类；
4）弱網(wǎng)率：判斷弱網(wǎng)的請(qǐng)求量占總請(qǐng)求量的比例。
可以看到：判定為弱網(wǎng)的用戶占比約為0.65%蝶押，而判定弱網(wǎng)中僅有約5%的請(qǐng)求耗時(shí)是低于50分位耗時(shí)踱蠢。
某請(qǐng)求HttpRTT類型、吞吐量類型與耗時(shí)表現(xiàn)：
當(dāng)我們以具體的HttpRTT類型、吞吐率類型來(lái)區(qū)分?jǐn)?shù)據(jù)的時(shí)候茎截，更能夠清晰大看到不同分類下的數(shù)據(jù)差異苇侵。通過(guò)圖15我們可以看到：判斷的類型越差（4G>3G>2G），請(qǐng)求耗時(shí)的越高（AVG企锌、P50...）榆浓，同時(shí)慢請(qǐng)求率越高（準(zhǔn)確率），快請(qǐng)求率越低（誤判率）撕攒。
9.5不準(zhǔn)確性來(lái)源
即使我們盡力優(yōu)化策略陡鹃，但仍有一部分誤判。
其來(lái)源如下：
1）分位值判定帶來(lái)的誤差 （可以參考以上準(zhǔn)確性說(shuō)明）抖坪；
2）用戶RTT 恰好在閾值附近波動(dòng)萍鲸；
3）來(lái)自算法本身限制，中位數(shù)機(jī)制本身就決定了當(dāng)用戶網(wǎng)絡(luò)環(huán)境快速變更后無(wú)法快速響應(yīng)擦俐。比如脊阴，用戶從WIFI信號(hào)差的地方移動(dòng)到路由器附近，網(wǎng)絡(luò)質(zhì)量立即變得極好蚯瞧，此時(shí)沒(méi)有足夠數(shù)量的新樣本積累嘿期，弱網(wǎng)診斷輸出的仍是弱網(wǎng)；
4）大量請(qǐng)求異常高耗時(shí)埋合，當(dāng)用戶吞吐量一般時(shí)备徐， 用戶高并發(fā)請(qǐng)求某HOST時(shí)，存在首包耗時(shí)異常高的情況甚颂。如圖16第9秒蜜猾、26秒、26秒都存在單HOST高并發(fā)高耗時(shí)西设，而導(dǎo)致估算值較高瓣铣。（當(dāng)然，后面我們會(huì)考慮優(yōu)化并發(fā)數(shù)贷揽，但這和弱網(wǎng)診斷沒(méi)有關(guān)系）。
圖20 - 用戶C全部請(qǐng)求及HttpRTT梦碗、吞吐率：
10禽绪、應(yīng)用場(chǎng)景
1）并行Http2.0連接：我們知道HTTP/2.0 支持多路復(fù)用，可以同一個(gè)TCP連接上進(jìn)行并發(fā)的數(shù)據(jù)交換洪规，而不像HTTP/1.1需要多個(gè)TCP連接印屁。在正常網(wǎng)絡(luò)環(huán)境下能夠降低一部分延遲，然在弱網(wǎng)環(huán)境下TCP的隊(duì)頭阻塞問(wèn)題將使請(qǐng)求變得更慢斩例，那么我們?cè)谌蹙W(wǎng)時(shí)雄人，并行建連多個(gè)H2連接將能在一定程度上緩解此問(wèn)題。
2）全站加速：應(yīng)用全站加速時(shí)，客戶端會(huì)建連邊緣節(jié)點(diǎn)础钠，而不是中心業(yè)務(wù)服務(wù)器恰力，這將能降低客戶端到服務(wù)器的TCP RTT，從而響應(yīng)速度旗吁、成功率得到提升踩萎，弱網(wǎng)環(huán)境下更契合全站加速的應(yīng)用場(chǎng)景。
3）音視頻降質(zhì)：弱網(wǎng)時(shí)很钓，降低畫質(zhì)以快速加載要好于加載速度慢香府。
4）預(yù)加載優(yōu)化：當(dāng)前App內(nèi)有各式各樣的預(yù)加載，其本意是為了加速頁(yè)面訪問(wèn)速度码倦，提升用戶體驗(yàn)企孩。然而弱網(wǎng)時(shí)可能會(huì)適得其反。弱網(wǎng)時(shí)袁稽，根據(jù)網(wǎng)絡(luò)環(huán)境評(píng)級(jí)柠硕，逐步降低預(yù)加載數(shù)據(jù)，將帶寬讓給前臺(tái)網(wǎng)絡(luò)請(qǐng)求將能提升頁(yè)面加載速度运提。
11蝗柔、本文小結(jié)
通過(guò)監(jiān)聽App內(nèi)的Http請(qǐng)求，按照一定策略采集HttpRTT民泵、吞吐率樣本癣丧，以加權(quán)中位數(shù)（時(shí)間權(quán)重、信號(hào)強(qiáng)度權(quán)重）的方式綜合估算出HttpRTT栈妆、吞吐率胁编，最后根據(jù)HttpRTT、吞吐率按照一定的策略劃分出真實(shí)網(wǎng)絡(luò)類型鳞尔。
經(jīng)線上數(shù)據(jù)驗(yàn)證嬉橙，弱網(wǎng)用戶占比0.65%，而弱網(wǎng)請(qǐng)求中僅5%以下耗時(shí)低于50分位寥假，具有明顯的區(qū)分性市框。后續(xù)可應(yīng)用于網(wǎng)絡(luò)連接優(yōu)化、全站加速糕韧、音視頻降質(zhì)等多個(gè)場(chǎng)景枫振。
12、參考資料
[1]?通俗易懂-深入理解TCP協(xié)議（下）：RTT萤彩、滑動(dòng)窗口粪滤、擁塞處理
[2]?現(xiàn)代移動(dòng)端網(wǎng)絡(luò)短連接的優(yōu)化手段總結(jié)：請(qǐng)求速度、弱網(wǎng)適應(yīng)雀扶、安全保障
[3]?移動(dòng)端IM開發(fā)者必讀(一)：通俗易懂杖小，理解移動(dòng)網(wǎng)絡(luò)的“弱”和“慢”
[4]?全面了解移動(dòng)端DNS域名劫持等雜癥：原理、根源、HttpDNS解決方案等
[5]?美圖App的移動(dòng)端DNS優(yōu)化實(shí)踐：HTTPS請(qǐng)求耗時(shí)減小近半
[6]?百度APP移動(dòng)端網(wǎng)絡(luò)深度優(yōu)化實(shí)踐分享(三)：移動(dòng)端弱網(wǎng)優(yōu)化篇
[7]?愛(ài)奇藝移動(dòng)端網(wǎng)絡(luò)優(yōu)化實(shí)踐分享：網(wǎng)絡(luò)請(qǐng)求成功率優(yōu)化篇
[8]?美團(tuán)點(diǎn)評(píng)的移動(dòng)端網(wǎng)絡(luò)優(yōu)化實(shí)踐：大幅提升連接成功率予权、速度等
[9]?IM開發(fā)者的零基礎(chǔ)通信技術(shù)入門(十二)：上網(wǎng)卡頓昂勉？網(wǎng)絡(luò)掉線？一文即懂伟件！
[10]?淘寶移動(dòng)端統(tǒng)一網(wǎng)絡(luò)庫(kù)的架構(gòu)演進(jìn)和弱網(wǎng)優(yōu)化技術(shù)實(shí)踐
13硼啤、得物技術(shù)團(tuán)隊(duì)的其它文章匯總
得物從0到1自研客服IM系統(tǒng)的技術(shù)實(shí)踐之路
得物自研客服IM中收發(fā)聊天消息背后的技術(shù)邏輯和思考實(shí)現(xiàn)
得物從零構(gòu)建億級(jí)消息推送系統(tǒng)的送達(dá)穩(wěn)定性監(jiān)控體系技術(shù)實(shí)踐
