網(wǎng)絡(luò)優(yōu)化一直是移動(dòng)互聯(lián)網(wǎng)時(shí)代的熱議話題，弱網(wǎng)識(shí)別作為弱網(wǎng)優(yōu)化的第一步，受到的關(guān)注和討論也是最多的。本文從設(shè)計(jì)、開發(fā)、落地詳盡的分享了攜程在弱網(wǎng)識(shí)別方面的實(shí)踐經(jīng)驗(yàn)，如果你也有類似需求，這篇文章會(huì)是一個(gè)不錯(cuò)的實(shí)操指南。

一、背景

二、技術(shù)方案

2.1 數(shù)據(jù)采集

2.2 數(shù)據(jù)處理

2.3 結(jié)果輸出

三、落地效果

四、未來展望

一、背景

自從2010年攜程推出”無線戰(zhàn)略“，并發(fā)布移動(dòng)端APP以來，無線研發(fā)團(tuán)隊(duì)對于客戶端網(wǎng)絡(luò)性能的優(yōu)化就一直沒有停止過。經(jīng)過這十幾年持續(xù)不斷的優(yōu)化，目前攜程的端到端網(wǎng)絡(luò)性能已經(jīng)處于一個(gè)相當(dāng)不錯(cuò)的水平，大盤數(shù)據(jù)趨于穩(wěn)定，優(yōu)化也隨之進(jìn)入 ”深水區(qū)“，提升難度巨大。

結(jié)合線上的一系列客訴反饋，我們發(fā)現(xiàn)即使大盤的數(shù)據(jù)再優(yōu)秀，用戶網(wǎng)絡(luò)表現(xiàn)不佳的個(gè)例case仍然層出不窮，排查后大部分被我們歸因到"弱網(wǎng)”。這部分“弱網(wǎng)”長尾數(shù)據(jù)相比大盤均值仍有巨大的提升空間，如果可以針對性優(yōu)化的話，對于提升整體用戶體驗(yàn)和減少客訴都有非常明確的價(jià)值。

既然要優(yōu)化“弱網(wǎng)”，那第一步一定是建立相應(yīng)的“弱網(wǎng)識(shí)別模型”，準(zhǔn)確識(shí)別出弱網(wǎng)場景，本文即探討攜程在弱網(wǎng)識(shí)別方面的技術(shù)探索，包含技術(shù)選型細(xì)節(jié)和關(guān)鍵的路徑思考，歡迎溝通交流。

二、技術(shù)方案

攜程弱網(wǎng)識(shí)別模型的整個(gè)工作流程由數(shù)據(jù)采集、數(shù)據(jù)處理、結(jié)果輸出三部分組成，接下來我們順著流程來逐個(gè)剖析相關(guān)細(xì)節(jié)。

2.1 數(shù)據(jù)采集

2.1.1 可以客觀反映網(wǎng)絡(luò)質(zhì)量的指標(biāo)有哪些

說到可以客觀反映網(wǎng)絡(luò)質(zhì)量的指標(biāo)，業(yè)內(nèi)定義清晰且獲得公認(rèn)的有如下這些：

• HttpRTT：Http請求一次網(wǎng)絡(luò)往返的耗時(shí)，具體口徑是客戶端從開始發(fā)送RequestHeader到收到ResponseHeader第一個(gè)字節(jié)的時(shí)間差
• TransportRTT：網(wǎng)絡(luò)通道上一次數(shù)據(jù)往返的耗時(shí)，具體口徑是客戶端從開始發(fā)送數(shù)據(jù)到收到服務(wù)端返回?cái)?shù)據(jù)第一個(gè)字節(jié)的時(shí)間差，要減去服務(wù)處理的耗時(shí)
• ThroughPut：網(wǎng)絡(luò)吞吐量，是指定位時(shí)間內(nèi)網(wǎng)絡(luò)通道上下行的數(shù)據(jù)量，具體口徑是單位位時(shí)間內(nèi)上行或者下行的數(shù)據(jù)量除以單位時(shí)間，由于上行數(shù)據(jù)量受到業(yè)務(wù)因素的影響較大，我們一般僅關(guān)注下行
• BandwidthDelayProduct：帶寬時(shí)延乘積，顧名思義是指網(wǎng)絡(luò)帶寬乘以網(wǎng)絡(luò)時(shí)延的結(jié)果，即當(dāng)前網(wǎng)絡(luò)通道里正在傳輸?shù)臄?shù)據(jù)總量，是一個(gè)復(fù)合指標(biāo)，可以客觀反映當(dāng)前網(wǎng)絡(luò)承載數(shù)據(jù)的能力，計(jì)算方式是 ThroughPut * TransportRTT
• SignalStrength：信號強(qiáng)度，移動(dòng)互聯(lián)網(wǎng)時(shí)代，設(shè)備依靠Wifi或者蜂窩數(shù)據(jù)接入互聯(lián)網(wǎng)，信號強(qiáng)度會(huì)影響用戶的網(wǎng)絡(luò)表現(xiàn)
• NetworkSuccessRate：網(wǎng)絡(luò)成功率，剔除業(yè)務(wù)影響的純網(wǎng)絡(luò)行為成功率，與網(wǎng)絡(luò)質(zhì)量呈正相關(guān)，包含建聯(lián)成功率、傳輸成功率等

2.1.2 攜程選擇了哪些指標(biāo)作為模型輸入？為什么

對于網(wǎng)絡(luò)質(zhì)量識(shí)別，業(yè)內(nèi)做的比較早的是Google的NQE（Network Quality Estimator），國內(nèi)大多數(shù)網(wǎng)絡(luò)質(zhì)量識(shí)別方案也都參考了Google NQE，NQE中識(shí)別模型的輸入主要是HttpRTT、TransportRTT、DownstreamThroughput這三個(gè)指標(biāo)。

對于HttpRTT、TransportRTT，在應(yīng)用層和傳輸層都有很多方式可以采集到，且口徑清晰，所以這兩個(gè)指標(biāo)被我們納入采集范圍。

對于DownstreamThroughput，我們實(shí)踐過程中發(fā)現(xiàn)，該指標(biāo)受到用戶行為的影響很大，當(dāng)用戶集中操作大量發(fā)送網(wǎng)絡(luò)請求的時(shí)候，該指標(biāo)就偏高，當(dāng)用戶停止操作閱讀數(shù)據(jù)時(shí)，該指標(biāo)就會(huì)偏低甚至長時(shí)間得不到更新，考慮到指標(biāo)的波動(dòng)性，我們不將此指標(biāo)納入采集范圍。

既然DownstreamThroughput被排除在外，那由他參與計(jì)算的BandwidthDelayProduct也被我們排除。

SignalStrength信號強(qiáng)度由于iOS無法準(zhǔn)確獲取，考慮到多端一致性，也被我們Pass。

NetworkSuccessRate網(wǎng)絡(luò)成功率這個(gè)指標(biāo)，可能很少被其他方案提及到，我們提出這個(gè)指標(biāo)并將他納入采集范圍的主要原因是，基于RTT的網(wǎng)絡(luò)識(shí)別模型，在遇到網(wǎng)絡(luò)波動(dòng)導(dǎo)致的用戶大面積請求失敗時(shí)，無法獲取到有效的RTT值，導(dǎo)致識(shí)別的準(zhǔn)確性和實(shí)時(shí)性都收到影響，引入網(wǎng)絡(luò)成功率可以很好的彌補(bǔ)這個(gè)缺陷，最終線上生產(chǎn)環(huán)境驗(yàn)證也證明了該指標(biāo)的必要性。

最終，攜程的網(wǎng)絡(luò)質(zhì)量識(shí)別模型采集HttpRTT、TransportRTT、NetworkSuccessRate作為輸入指標(biāo)。

2.1.3 輸入的網(wǎng)絡(luò)指標(biāo)如何采集

攜程的網(wǎng)絡(luò)請求，主要有Tcp代理通道、Quic代理通道、Http通道三種網(wǎng)絡(luò)通道。對于上述提到了三個(gè)輸入指標(biāo)，我們從如下網(wǎng)絡(luò)行為中進(jìn)行數(shù)據(jù)采集：

• TransportRTT：通道心跳耗時(shí)、Tcp通道建聯(lián)耗時(shí)、Http通道建聯(lián)耗時(shí)（Tips：建聯(lián)耗時(shí)不涉及業(yè)務(wù)處理，近似于純網(wǎng)絡(luò)傳輸耗時(shí)，所以我們把他作為TransportRTT；Quic建聯(lián)約等于Tls握手耗時(shí)，且存在0RTT等特性干擾，所以不采用）
• HttpRTT：標(biāo)準(zhǔn)Http請求的responseHeader開始接收時(shí)間減去RequestHeader的開始發(fā)送時(shí)間、自定義網(wǎng)絡(luò)通道請求的開始接收時(shí)間減去開始發(fā)送時(shí)間
• NetworkSuccessRate：Tcp建聯(lián)成功狀態(tài)、Quic建聯(lián)成功狀態(tài)、心跳成功狀態(tài)、Http請求是否完整接收到Response

對于自定義的Tcp、Quic代理通道，按照上述口徑在網(wǎng)絡(luò)通道相關(guān)狀態(tài)回調(diào)內(nèi)統(tǒng)計(jì)數(shù)據(jù)即可，自定義實(shí)現(xiàn)參考價(jià)值不大，這里就不過多贅述。

對于標(biāo)準(zhǔn)的Http請求，我們可以通過獲取系統(tǒng)網(wǎng)絡(luò)框架返回的Metric信息或者監(jiān)聽請求的狀態(tài)流轉(zhuǎn)來獲取網(wǎng)絡(luò)指標(biāo)。

對于iOS，iOS 10之后NSURLSession支持通過NSURLSessionTaskDelegate的協(xié)議方法URLSession:task:didFinishCollectingMetrics:獲取到請求的Metric信息，詳細(xì)信息見附錄1，單次請求的Metric定義如下圖：

• TransportRTT = connectEnd - connectStart - secureConnectionEnd + secureConnectionStart；建聯(lián)耗時(shí)要減去Tls的耗時(shí)，連接復(fù)用時(shí)，相關(guān)字段為空值，不納入計(jì)算
• HttpRTT = responseStart - requestStart
• NetworkSuccessStatus = responseEnd 且沒有傳輸錯(cuò)誤；網(wǎng)絡(luò)成功率只關(guān)心傳輸是否成功，不需要關(guān)注Response的http狀態(tài)碼

對于Android，系統(tǒng)網(wǎng)絡(luò)框架OkHttp支持添加EventListener來獲取Http請求的狀態(tài)流轉(zhuǎn)信息，可以在各狀態(tài)回調(diào)內(nèi)記錄時(shí)間戳來計(jì)算RTT，詳細(xì)信息見附錄2，單次請求的Events定義如下圖：

• TransportRTT = connectEnd - connectStart - secureConnectEnd + secureConnectStart
• HttpRTT = responseHeadersStart - requestHeadersStart
• NetworkSuccessStatus = responseBodyEnd 且沒有傳輸錯(cuò)誤

依照上述方法收集到網(wǎng)絡(luò)數(shù)據(jù)后，我們把數(shù)據(jù)封裝成對應(yīng)的結(jié)構(gòu)體，注入識(shí)別模型，攜程對于網(wǎng)絡(luò)數(shù)據(jù)結(jié)構(gòu)體的定義如下，方便大家參考：

typedef enum : int64_t {    


    NQEMetricsSourceTypeInvalid = 0,              // 0
    NQEMetricsSourceTypeTcpConnect = 1 << 0,      // 1
    NQEMetricsSourceTypeQuicConnect = 1 << 1,     // 2
    NQEMetricsSourceTypeHttpRequest = 1 << 2,     // 4
    NQEMetricsSourceTypeQuicRequest = 1 << 3,     // 8
    NQEMetricsSourceTypeHeartBeat = 1 << 4,       // 16
    ......
} NQEMetricsSourceType;


struct NQEMetrics {


    // 本次采集到的數(shù)據(jù)來源，可以是多個(gè)枚舉值的或值
    // 例如一次沒有連接復(fù)用http請求，source = TcpConnect|HttpRequest，同時(shí)存在transportRTT和httpRTT     NQEMetricsSourceType source;
    // 本次數(shù)據(jù)的成功狀態(tài)，用作成功率計(jì)算
    bool isSuccessed;
    // httpRTT，可為空
    double httpRTTInSec;
    // transportRTT，可為空
    double transportRTTInSec;
    // 數(shù)據(jù)采集時(shí)間
    double occurrenceTimeInSec;
};

2.2 數(shù)據(jù)處理

2.2.1 數(shù)據(jù)過濾和滑動(dòng)窗口

網(wǎng)絡(luò)數(shù)據(jù)采集后，注入到識(shí)別模型內(nèi)，需要一個(gè)數(shù)據(jù)結(jié)構(gòu)來承載，我們采用的是隊(duì)列。

進(jìn)入隊(duì)列前，我們需要先進(jìn)行數(shù)據(jù)過濾，篩選掉一些無效的數(shù)據(jù)，目前采用的篩選策略有如下這些：

• 單條NQEMetrics數(shù)據(jù)，在isSuccessed=true的情況下，httpRTT、transportRTT至少有一條不為空，否則為無效數(shù)據(jù)
• RTT必須大于最小閾值，用來過濾一些類似LocalHost請求的臟數(shù)據(jù)，目前采用的閾值為10ms
• RTT必須小于最大閾值，用來過濾前后臺(tái)切換進(jìn)程掛起導(dǎo)致的RTT數(shù)值偏大，目前采用的閾值為5mins

數(shù)據(jù)過濾后加入隊(duì)列，為了實(shí)時(shí)性和結(jié)果準(zhǔn)確性，我們處理數(shù)據(jù)時(shí)，會(huì)根據(jù)兩個(gè)限制邏輯來確定一個(gè)具體的滑動(dòng)窗口，只讓窗口內(nèi)的數(shù)據(jù)參與計(jì)算，具體窗口限制邏輯如下：

• 最小數(shù)量限制，當(dāng)窗口內(nèi)數(shù)據(jù)過少時(shí)，會(huì)放大單條數(shù)據(jù)的影響，導(dǎo)致結(jié)果毛刺增多，所以我們限制最小計(jì)算窗口的數(shù)據(jù)條數(shù)為5
• 最大時(shí)間限制，為了數(shù)據(jù)實(shí)時(shí)性的考慮，比較舊的數(shù)據(jù)不參與計(jì)算，目前采用的閾值為5mins

每次計(jì)算網(wǎng)絡(luò)質(zhì)量時(shí)，可以根據(jù)這兩個(gè)限制來確定計(jì)算窗口，窗口外的數(shù)據(jù)可以實(shí)時(shí)清理出隊(duì)列，減少內(nèi)存占用。

上文提到的各種閾值設(shè)置，均可通過配置系統(tǒng)更新。

2.2.2 動(dòng)態(tài)權(quán)重計(jì)算

弱網(wǎng)識(shí)別模型的原理簡單來說就是將窗口內(nèi)的一組數(shù)據(jù)經(jīng)過一系列處理后，得出一個(gè)最終值，再用這個(gè)最終值與對應(yīng)的弱網(wǎng)閾值比較來得出是否是弱網(wǎng)。

出于實(shí)時(shí)性的考慮，我們希望距離當(dāng)前時(shí)間越近的數(shù)據(jù)權(quán)重越高，所以要用到動(dòng)態(tài)權(quán)重的算法，這里我們比較推薦的是”半衰期動(dòng)態(tài)權(quán)重“和”反正切動(dòng)態(tài)權(quán)重“兩種算法。

半衰期動(dòng)態(tài)權(quán)重

半衰期顧名思義，即每經(jīng)過一個(gè)固定的時(shí)間，權(quán)重降低為之前的一半。這里衰減幅度和周期都是可以自定義的，計(jì)算公式如下：

• 每秒衰減因子 = pow(衰減幅度, 1.0 / 衰減周期)；衰減幅度為浮點(diǎn)型，取值范圍 0~1，衰減周期為整形，單位為秒
• 動(dòng)態(tài)權(quán)重 = pow(每秒衰減因子, abs(now - 數(shù)據(jù)采集時(shí)間))

以衰減幅度為0.5，衰減周期為60秒為例，對應(yīng)的函數(shù)曲線如下：

橫坐標(biāo)為數(shù)據(jù)采集時(shí)間距今的時(shí)間差，縱坐標(biāo)為權(quán)重，從圖上可以清晰看到，隨著時(shí)間差增大，權(quán)重?zé)o限趨近于0。

半衰期動(dòng)態(tài)權(quán)重也是Google NQE采用的權(quán)重計(jì)算方案，Google采用的周期是每60秒降低50%，相關(guān)代碼詳見附錄3，部分核心代碼如下：

double GetWeightMultiplierPerSecond(
    const std::map<std::string, std::string>& params) {
  // Default value of the half life (in seconds) for computing time weighted
  // percentiles. Every half life, the weight of all observations reduces by
  // half. Lowering the half life would reduce the weight of older values
  // faster.
  int half_life_seconds = 60;
  int32_t variations_value = 0;
  auto it = params.find("HalfLifeSeconds");
  if (it != params.end() && base::StringToInt(it->second, &variations_value) &&
      variations_value >= 1) {
    half_life_seconds = variations_value;
  }
  DCHECK_GT(half_life_seconds, 0);
  return pow(0.5, 1.0 / half_life_seconds);
}


void ObservationBuffer::ComputeWeightedObservations(
    const base::TimeTicks& begin_timestamp,
    int32_t current_signal_strength,
    std::vector<WeightedObservation>* weighted_observations,
    double* total_weight) const {


    base::TimeDelta time_since_sample_taken = now - observation.timestamp();
    double time_weight =
        pow(weight_multiplier_per_second_, time_since_sample_taken.InSeconds());
…
}

反正切動(dòng)態(tài)權(quán)重

y=arctan(x)反正切函數(shù)在第一象限的取值范圍為0~Pi/2，我們將arctan(x)取反，向上平移Pi/2，然后除以Pi/2，函數(shù)曲線即可在第一象限隨著x增大y的取值從1趨近于0。我們還可以使用一個(gè)斜率系數(shù)來控制權(quán)重降低的趨勢快慢，公式推導(dǎo)過程如下：

動(dòng)態(tài)權(quán)重 = (Pi / 2  - arctan(abs(now - 數(shù)據(jù)采集時(shí)間) * 斜率系數(shù))) / (Pi / 2) = 1 - arctan(abs(now - 數(shù)據(jù)采集時(shí)間) * 斜率系數(shù))  / Pi * 2；斜率系數(shù)為浮點(diǎn)型，取值范圍為0~1，系數(shù)越小，權(quán)重降低的越緩慢。

以斜率系數(shù)為1/20為例，對應(yīng)的函數(shù)曲線如下：

和前文的半衰期動(dòng)態(tài)權(quán)重相同，橫坐標(biāo)為數(shù)據(jù)采集時(shí)間距今的時(shí)間差，縱坐標(biāo)為權(quán)重，隨著時(shí)間差增大，權(quán)重趨近于0，兩種動(dòng)態(tài)權(quán)重算法效果類似。

反正切動(dòng)態(tài)權(quán)重的實(shí)現(xiàn)代碼如下：

static double _nqe_getWeight(double targetTime) {
    ……
    double interval = now - targetTime;
    /// 曲率系數(shù)，數(shù)值越小權(quán)重降低的越緩慢
    double rate = 20.0 / 1;
    return 1.0 - atan(interval * rate) / M_PI_2;
}

從上圖的代碼實(shí)現(xiàn)可以看出，反正切相關(guān)的代碼實(shí)現(xiàn)要簡單很多，但是由于存在推導(dǎo)過程，所以理解起來比較困難，代碼維護(hù)成本較高（數(shù)學(xué)功底對于程序員來說也是非常重要的），大家可以酌情自行選擇。

攜程最終采用的也是半衰期動(dòng)態(tài)權(quán)重的方案，出于實(shí)時(shí)性考慮，最終線上驗(yàn)證后采用的衰減幅度為0.3，衰減幅度為60秒，供參考。

2.2.3 RTT指標(biāo)加權(quán)中值計(jì)算

在確定了單條數(shù)據(jù)的權(quán)重之后，對于RTT的數(shù)值計(jì)算，我們第一個(gè)想到的是加權(quán)平均，但是加權(quán)平均很容易收到高權(quán)重臟數(shù)據(jù)的影響，準(zhǔn)確性堪憂，所以我們改用了“加權(quán)中值”。

加權(quán)中值的計(jì)算方式是，將窗口內(nèi)的數(shù)據(jù)按照數(shù)值大小升序排列，然后從頭遍歷數(shù)據(jù)，累加權(quán)重大于等于總權(quán)重的一半時(shí)，停止遍歷，當(dāng)前遍歷到的數(shù)值即為最終的加權(quán)中值。

NQE對于TransportRTT和HttpRTT處理，也是使用的這種方式，相關(guān)代碼詳見附錄4，部分核心代碼如下：

std::optional<int32_t> ObservationBuffer::GetPercentile(
    base::TimeTicks begin_timestamp,
    int32_t current_signal_strength,
    int percentile,
    size_t* observations_count) const {


……
  // 此處的percentile值為50，即取中值
  double desired_weight = percentile / 100.0 * total_weight;
  double cumulative_weight_seen_so_far = 0.0;
  for (const auto& weighted_observation : weighted_observations) {
    cumulative_weight_seen_so_far += weighted_observation.weight;
    if (cumulative_weight_seen_so_far >= desired_weight)
      return weighted_observation.value;
  }
  // Computation may reach here due to floating point errors. This may happen
  // if |percentile| was 100 (or close to 100), and |desired_weight| was
  // slightly larger than |total_weight| (due to floating point errors).
  // In this case, we return the highest |value| among all observations.
  // This is same as value of the last observation in the sorted vector.
  return weighted_observations.at(weighted_observations.size() - 1).value;
}

2.2.4 成功率指標(biāo)加權(quán)平均計(jì)算

對于成功率，我們的NQEMetrics結(jié)構(gòu)體內(nèi)定義了單次成功狀態(tài)isSuccessed，單條數(shù)據(jù)的加權(quán)成功率為 (NQEMetrics.isSuccessed ? 1 : 0) * weight，整體的加權(quán)成功率為加權(quán)成功率總和除以總權(quán)重。

相關(guān)代碼實(shí)現(xiàn)如下：

extern double _calculateSuccessRateByWeight(const vector<CTNQEMetrics> &metrics, uint64_t types, const shared_ptr<NQEConfig> config) {
    ……
    uint64_t totalValidCount = 0;
    double totalWeights = 0.0;
    double totalSuccessRate = 0.0;


    for (const auto& m : metrics) {
        /// 過濾需要的數(shù)據(jù)
        if ((m.source & types) == 0) {
            continue;
        }
        /// 累計(jì)總權(quán)重和總成功率
        totalValidCount++;
        totalWeights += m.weight;
        totalSuccessRate += (m.isSuccessed ? 1 : 0) * m.weight;
    }


    /// 數(shù)據(jù)不足
    if (totalValidCount < config->minValidWindowSize) {
        return NQE_INVALID_RATE_VALUE;
    }
    if (totalWeights <= 0.0) {
        return NQE_INVALID_RATE_VALUE;
    }


    return totalSuccessRate / totalWeights;
}

2.2.5 引入成功率趨勢提高實(shí)時(shí)性

網(wǎng)絡(luò)質(zhì)量識(shí)別不僅需要準(zhǔn)確，實(shí)時(shí)性也非常重要，在網(wǎng)絡(luò)質(zhì)量切換時(shí)模型識(shí)別的時(shí)間越短越好。前文已經(jīng)提到了TransportRTT、HttpRTT、NetworkSuccessRate三個(gè)核心指標(biāo)的計(jì)算，但是在線上實(shí)際驗(yàn)證的過程中，我們發(fā)現(xiàn)在網(wǎng)絡(luò)完全不可用成功率跌0后，識(shí)別模型對于網(wǎng)絡(luò)狀態(tài)的恢復(fù)感知很慢，原因是成功率的攀升需要較長的時(shí)間。

針對這個(gè)極端的case，我們引入了一個(gè)“成功率趨勢”的新指標(biāo)，來優(yōu)化模型的實(shí)時(shí)性，在成功率未達(dá)閾值當(dāng)時(shí)有明顯趨勢時(shí)，提前切換網(wǎng)絡(luò)質(zhì)量狀態(tài)。成功率趨勢是指一段時(shí)間內(nèi)成功率連續(xù)上升或者下降的幅度，浮點(diǎn)類型，取值范圍-1 ~ +1。

成功率趨勢初始值為0，計(jì)算方式如下：

1）在每次更新成功率時(shí)，計(jì)算更新前后成功率的差值

如果差值為正，則成功率向好

• 如果當(dāng)前成功率趨勢值為正，則向好趨勢持續(xù)，成功率趨勢加上當(dāng)前差值
• 如果當(dāng)前成功率趨勢值為負(fù)，則成功率趨勢由壞轉(zhuǎn)好，成功率趨勢重置為當(dāng)前差值

如果差值為負(fù)，則成功率向壞

• 如果當(dāng)前成功率趨勢值為正，則成功率趨勢由好轉(zhuǎn)壞，成功率趨勢重置為當(dāng)前差值
• 如果當(dāng)前成功率趨勢值為負(fù)，則向壞趨勢持續(xù)，成功率趨勢加上當(dāng)前差值（負(fù)值）

2）當(dāng)然還需要過濾一些毛刺數(shù)據(jù)，避免趨勢變化過頻

具體代碼實(shí)現(xiàn)如下：

void NQE::_updateSuccessRateTrend() {
    auto oldRate;
    auto newRate;


    if (oldRate < 0 || newRate < 0) {
        _successRateContinuousDiff = 0;
        return;
    }
    auto diff = newRate - oldRate;
    /// 數(shù)據(jù)錯(cuò)誤，不做處理
    if (abs(diff) > 1) {
        _successRateContinuousDiff = 0;
        return;
    }
    /// diff小于0.01，作為毛刺處理，不影響趨勢變化
    if (abs(diff) < 0.01) {
        _successRateContinuousDiff += diff;
        return;
    }
    /// 計(jì)算連續(xù)diff
    if (diff > 0 && _successRateContinuousDiff > 0) {
        _successRateContinuousDiff += diff;
    } else if (diff < 0 && _successRateContinuousDiff < 0) {
        _successRateContinuousDiff += diff;
    } else {
        _successRateContinuousDiff = diff;
    }
}

在網(wǎng)絡(luò)成功率和成功率趨勢的加持下，我們的識(shí)別模型實(shí)時(shí)性大幅度提升。我們控制相同請求頻率和請求數(shù)據(jù)量，線下模擬弱網(wǎng)切換進(jìn)行測試，測試結(jié)果如下：

• 單RTT識(shí)別模型，網(wǎng)絡(luò)質(zhì)量切換后識(shí)別較慢，且存在連續(xù)切換場景識(shí)別不出弱網(wǎng)的情況
• RTT+成功率模型，切換識(shí)別速度較單RTT模型提升約50%，成功率跌0后的Bad切Good識(shí)別明顯較慢
• RTT+成功率+成功率趨勢模型，切換識(shí)別速度較單RTT模型提升約70%，Bad切Good識(shí)別速度明顯提升

所以，最終攜程弱網(wǎng)識(shí)別模型計(jì)算的指標(biāo)有TransportRTT、HttpRTT、NetworkSuccessRate、SuccessRateTrend（成功率趨勢）四個(gè)。

2.3 結(jié)果輸出

2.3.1 網(wǎng)絡(luò)質(zhì)量定義

識(shí)別模型對外輸出的是一個(gè)網(wǎng)絡(luò)質(zhì)量的枚舉值，Google NQE對于網(wǎng)絡(luò)質(zhì)量的定義如下，源碼詳見附錄5：

enum EffectiveConnectionType {
  // Effective connection type reported when the network quality is unknown.
  EFFECTIVE_CONNECTION_TYPE_UNKNOWN = 0,


  // Effective connection type reported when the Internet is unreachable
  // because the device does not have a connection (as reported by underlying
  // platform APIs). Note that due to rare but  potential bugs in the platform
  // APIs, it is possible that effective connection type is reported as
  // EFFECTIVE_CONNECTION_TYPE_OFFLINE. Callers must use caution when using
  // acting on this.
  EFFECTIVE_CONNECTION_TYPE_OFFLINE,


  // Effective connection type reported when the network has the quality of a
  // poor 2G connection.
  EFFECTIVE_CONNECTION_TYPE_SLOW_2G,


  // Effective connection type reported when the network has the quality of a
  // faster 2G connection.
  EFFECTIVE_CONNECTION_TYPE_2G,


  // Effective connection type reported when the network has the quality of a 3G
  // connection.
  EFFECTIVE_CONNECTION_TYPE_3G,


  // Effective connection type reported when the network has the quality of a 4G
  // connection.
  EFFECTIVE_CONNECTION_TYPE_4G,


  // Last value of the effective connection type. This value is unused.
  EFFECTIVE_CONNECTION_TYPE_LAST,
};

Google枚舉定義的最大問題是理解成本比較高，其他開發(fā)同學(xué)看到這個(gè)所謂的“3G”、“4G”，他依然不知道網(wǎng)絡(luò)是好是壞，是不是他認(rèn)為的“弱網(wǎng)”。

所以我們在定義接口的時(shí)候，對于枚舉的設(shè)計(jì)考慮最多的就是理解成本，結(jié)合開發(fā)同學(xué)最想知道的“是不是弱網(wǎng)”，我們的接口定義如下：

typedef enum : int64_t {
    /// 未知狀態(tài)，初始狀態(tài)或者無有效計(jì)算窗口時(shí)會(huì)進(jìn)入此狀態(tài)
    NetworkQualityTypeUnknown = 0,
    /// 離線狀態(tài)，網(wǎng)絡(luò)不可用
    NetworkQualityTypeOffline = 1,
    /// 弱網(wǎng)狀態(tài)
    NetworkQualityTypeBad = 2,
    /// 正常網(wǎng)絡(luò)狀態(tài)
    NetworkQualityTypeGood = 3
} NetworkQualityType;

這樣是不是看起來簡單明了多了，我們接下來就講講怎么計(jì)算得出這幾個(gè)枚舉的結(jié)果。

2.3.2 網(wǎng)絡(luò)質(zhì)量計(jì)算方式

NetworkQualityTypeUnknown 是在初始化或者網(wǎng)絡(luò)切換后的一段時(shí)間內(nèi)，數(shù)據(jù)不足無法得出網(wǎng)絡(luò)質(zhì)量，會(huì)進(jìn)入此狀態(tài)。

NetworkQualityTypeOffline 的觸發(fā)條件很單一，就是操作系統(tǒng)識(shí)別到無網(wǎng)絡(luò)連接，具體的獲取方式由各平臺(tái)自行實(shí)現(xiàn)，例如iOS可以通過Reachability獲取，官方Demo詳見附錄6。

NetworkQualityTypeBad 也就是我們最核心的“弱網(wǎng)”狀態(tài)，計(jì)算方式是上文提到的TransportRTT、HttpRTT兩個(gè)指標(biāo)任一指標(biāo)觸發(fā)弱網(wǎng)閾值，或者NetworkSuccessRate和SuccessRateTrend同時(shí)滿足弱網(wǎng)閾值。

NetworkQualityTypeGood 是指正常的網(wǎng)絡(luò)質(zhì)量狀態(tài)，上述三種網(wǎng)絡(luò)質(zhì)量類型講完后，這個(gè)類型就簡單了，即非上述三種情況的場景，歸類到Good，這也是設(shè)計(jì)上占比最高的網(wǎng)絡(luò)質(zhì)量類型。

識(shí)別模型的運(yùn)轉(zhuǎn)流程如下：

• 數(shù)據(jù)隊(duì)列在初始化和網(wǎng)絡(luò)連接狀態(tài)變化兩個(gè)時(shí)機(jī)會(huì)被重置，充值后網(wǎng)絡(luò)質(zhì)量類型進(jìn)入 NetworkQualityTypeUnknown
• 網(wǎng)絡(luò)連接狀態(tài)進(jìn)入無連接狀態(tài)時(shí)，數(shù)據(jù)隊(duì)列被清空，網(wǎng)絡(luò)質(zhì)量類型直接進(jìn)入 NetworkQualityTypeOffline，在網(wǎng)絡(luò)類型變?yōu)榭捎妙愋颓?，?shù)據(jù)隊(duì)列不接受數(shù)據(jù)注入，且不進(jìn)行計(jì)算
• 數(shù)據(jù)隊(duì)列的數(shù)據(jù)變化觸發(fā)質(zhì)量計(jì)算，出于資源開銷考慮，要限制計(jì)算的頻次，我們采用計(jì)算間隔和新增數(shù)據(jù)量兩個(gè)閾值限制，計(jì)算間隔大于60s或者新增數(shù)據(jù)量超過10條才會(huì)觸發(fā)計(jì)算；同時(shí)也暴露了對外接口，業(yè)務(wù)可按需強(qiáng)制刷新計(jì)算結(jié)果
• 關(guān)于主動(dòng)網(wǎng)絡(luò)探測，可結(jié)合自身的業(yè)務(wù)需求按需實(shí)現(xiàn)，目前攜程的APP在使用時(shí)網(wǎng)絡(luò)數(shù)據(jù)更新比較頻繁，無需補(bǔ)充主動(dòng)探測數(shù)據(jù)

2.3.3 弱網(wǎng)閾值制定

模型核心的計(jì)算邏輯，就是將加工后得到的各網(wǎng)絡(luò)指標(biāo)與對應(yīng)的弱網(wǎng)閾值進(jìn)行對比，從而獲得是否進(jìn)入弱網(wǎng)的結(jié)果，關(guān)于弱網(wǎng)閾值的制定上，我們經(jīng)歷了如下兩個(gè)階段：

第一階段，主要參考NQE EFFECTIVE_CONNECTION_TYPE_2G 的閾值定義

• HttpRTT > 1726ms
• TransportRTT > 1531ms
• 成功率按照內(nèi)部討論的預(yù)期設(shè)置為 NetworkSuccessRate < 90%
• 成功率趨勢閾值設(shè)置為 SuccessRateTrend < 0.1，即成功率連續(xù)向好增加超過10pp，即使成功率小于90%，也從Bad切換為Good，這個(gè)指標(biāo)主要是為了提升Bad切Good的速度

第二階段，我們通過線上的網(wǎng)絡(luò)質(zhì)量分布監(jiān)控，和一些具體case的分析，不斷迭代我們的閾值，我們需要制定一個(gè)識(shí)別準(zhǔn)確率的指標(biāo)來指引閾值的調(diào)整工作，達(dá)到邏輯準(zhǔn)確與自洽。

理論上，我們希望識(shí)別模型的入?yún)⑴c當(dāng)下計(jì)算出的網(wǎng)絡(luò)質(zhì)量類型所匹配，例如當(dāng)前注入NQEMetrics數(shù)據(jù)的HttpRTT <= 1726ms ，那我們預(yù)期當(dāng)前計(jì)算出的網(wǎng)絡(luò)質(zhì)量類型就是Good。但是弱網(wǎng)的決策邏輯是相對復(fù)雜的，需要考慮到各種因素，以下兩點(diǎn)會(huì)造成弱網(wǎng)狀態(tài)下的入?yún)?shù)據(jù)不一定符合弱網(wǎng)閾值定義：

1）弱網(wǎng)的計(jì)算是對過去已經(jīng)發(fā)生網(wǎng)絡(luò)行為的分析，具有一定的滯后性，所以在識(shí)別結(jié)果切換附近，必然有部分的原數(shù)據(jù)已經(jīng)滿足下一階段的網(wǎng)絡(luò)質(zhì)量定義

2）弱網(wǎng)的決策是對多個(gè)指標(biāo)的復(fù)合計(jì)算，所以在識(shí)別到弱網(wǎng)狀態(tài)時(shí)，不一定所有的指標(biāo)原數(shù)據(jù)都符合弱網(wǎng)定義，比如由HttpRTT觸發(fā)弱網(wǎng)時(shí)，當(dāng)前的TransportRTT數(shù)據(jù)可能表現(xiàn)良好

終上兩點(diǎn)原因，弱網(wǎng)分類下必然有一定的非弱網(wǎng)數(shù)據(jù)，這里的誤差數(shù)據(jù)占比與識(shí)別準(zhǔn)確率負(fù)相關(guān)，誤差數(shù)據(jù)占比越低，識(shí)別準(zhǔn)確率越高。所以想到這里，我們的模型識(shí)別準(zhǔn)確率的指標(biāo)計(jì)算口徑就有了：

• 模型弱網(wǎng)識(shí)別準(zhǔn)確性 = 100% - 弱網(wǎng)狀態(tài)下不符合弱網(wǎng)閾值定義原數(shù)據(jù)占比

有了這個(gè)指標(biāo)指引，我們在模型上線后進(jìn)行了數(shù)個(gè)版本的數(shù)據(jù)統(tǒng)計(jì)，通過各指標(biāo)閾值的微調(diào)和case by case解決異常場景，誤差數(shù)據(jù)從剛上線的15%+降低到10%以下，即模型識(shí)別準(zhǔn)確率優(yōu)化至90%以上。

最終攜程90%準(zhǔn)確率的模型對應(yīng)的弱網(wǎng)閾值如下（不同業(yè)務(wù)場景的網(wǎng)絡(luò)請求差別較大，僅供大家參考）：

• HttpRTT > 1220ms；這個(gè)值是線上HttpRTT的TP98值，與弱網(wǎng)占比相近
• TransportRTT > 520ms；同線上TP98值
• NetworkSuccessRate < 90%
• SuccessRateTrend < 0.2；之前的0.1導(dǎo)致模型的結(jié)果切換過于頻繁，最終調(diào)整到了0.2

Tips：對于類似攜程這種自定義的弱網(wǎng)識(shí)別模型，弱網(wǎng)標(biāo)準(zhǔn)也是考慮業(yè)務(wù)現(xiàn)狀的定制標(biāo)準(zhǔn)，所以不需要太多和外部的弱網(wǎng)標(biāo)準(zhǔn)對齊，重點(diǎn)是自洽和符合業(yè)務(wù)預(yù)期。

三、落地效果

考慮到識(shí)別模型要支持多平臺(tái)（iOS、Android、Harmony等），所以我們在一開始實(shí)現(xiàn)方案時(shí)就采用了C++作為開發(fā)語言，天然支持了多平臺(tái)，各平臺(tái)只需要實(shí)現(xiàn)上層數(shù)據(jù)采集和注入模型的少量邏輯即可完成模型的接入。相同的代碼實(shí)現(xiàn)和弱網(wǎng)標(biāo)準(zhǔn)，也方便我們在不同的平臺(tái)間直接對標(biāo)數(shù)據(jù)，發(fā)現(xiàn)各平臺(tái)的問題針對性優(yōu)化。

目前攜程的網(wǎng)絡(luò)質(zhì)量識(shí)別模型，已經(jīng)在iOS、Android平臺(tái)完成接入并大面積投產(chǎn)，網(wǎng)絡(luò)質(zhì)量數(shù)據(jù)與集團(tuán)的APM監(jiān)控平臺(tái)打通，形成了攜程官方統(tǒng)一的網(wǎng)絡(luò)質(zhì)量標(biāo)準(zhǔn)，在網(wǎng)絡(luò)排障、框架網(wǎng)絡(luò)優(yōu)化、業(yè)務(wù)網(wǎng)絡(luò)優(yōu)化等多種場景下扮演重要角色，弱網(wǎng)優(yōu)化相關(guān)的內(nèi)容我們會(huì)在后面相關(guān)的專題內(nèi)繼續(xù)分享，此處不再贅述。

最終網(wǎng)絡(luò)質(zhì)量相關(guān)的分布數(shù)據(jù)如下（數(shù)據(jù)為實(shí)驗(yàn)采集，不代表攜程真實(shí)業(yè)務(wù)情況，僅參考）：

網(wǎng)絡(luò)質(zhì)量分布：

各網(wǎng)絡(luò)質(zhì)量下對應(yīng)的請求性能數(shù)據(jù)：

四、未來展望

網(wǎng)絡(luò)質(zhì)量識(shí)別模型的完成只是我們網(wǎng)絡(luò)優(yōu)化的開始，后續(xù)還有很多的工作需要我們繼續(xù)努力，未來一段時(shí)間我們會(huì)從以下幾個(gè)方面繼續(xù)推進(jìn)：

1）持續(xù)推進(jìn)各平臺(tái)、各獨(dú)立APP的網(wǎng)絡(luò)質(zhì)量識(shí)別模型接入，完成攜程終端全平臺(tái)的網(wǎng)絡(luò)質(zhì)量模型覆蓋

2）做好識(shí)別模型的防劣化工作，解決各業(yè)務(wù)場景的bad case，堅(jiān)守現(xiàn)階段識(shí)別準(zhǔn)確率和實(shí)時(shí)性的標(biāo)準(zhǔn)水位

3）推出攜程內(nèi)部的“網(wǎng)絡(luò)性能白皮書”，從APP、系統(tǒng)平臺(tái)、網(wǎng)絡(luò)質(zhì)量、成功率、全鏈路耗時(shí)等各維度解析公司內(nèi)部各業(yè)務(wù)線的網(wǎng)絡(luò)表現(xiàn)，形成內(nèi)部的網(wǎng)絡(luò)性能數(shù)據(jù)基線，為業(yè)務(wù)優(yōu)化提供參考

4）借助現(xiàn)有的弱網(wǎng)標(biāo)準(zhǔn)和識(shí)別能力，從網(wǎng)絡(luò)框架側(cè)和業(yè)務(wù)側(cè)兩個(gè)不同的角度進(jìn)行弱網(wǎng)優(yōu)化，提高整體網(wǎng)絡(luò)表現(xiàn)；當(dāng)下海外市場是業(yè)務(wù)發(fā)力的重點(diǎn)，海外場景的網(wǎng)絡(luò)表現(xiàn)也明顯弱于國內(nèi)，我們會(huì)針對海外場景從弱網(wǎng)的角度進(jìn)行重點(diǎn)優(yōu)化。

攜程目前已經(jīng)針對弱網(wǎng)場景推出了一系列優(yōu)化策略，部分策略已經(jīng)取得非常不錯(cuò)的收益，后續(xù)我們會(huì)繼續(xù)推進(jìn)，也會(huì)持續(xù)分享輸出。