當(dāng)我們開始關(guān)注 App 的用戶體驗(yàn)后床牧，網(wǎng)絡(luò)通暢性和界面的流暢性是保證 App 好用的重要指標(biāo)荣回。近期對(duì)項(xiàng)目中的網(wǎng)絡(luò)數(shù)據(jù)進(jìn)行了簡(jiǎn)單的分析，又對(duì)業(yè)界的一些方案做了調(diào)研戈咳，故寫此文做一下知識(shí)梳理心软。
當(dāng)我們使用
App 的 時(shí)候，如經(jīng)常遇到加載失敗或者小圈轉(zhuǎn)個(gè)不停的情況著蛙，那么很可能 App
的網(wǎng)絡(luò)性能出現(xiàn)了問題删铃，急需研發(fā)同學(xué)來進(jìn)行優(yōu)化。而對(duì)于開發(fā)人員來說踏堡，定位網(wǎng)絡(luò)問題又是十分艱難猎唁，因?yàn)槌霈F(xiàn)網(wǎng)絡(luò)問題的用戶往往遙在天邊，你沒辦法進(jìn)行調(diào)試定位顷蟆。那么建立完善的網(wǎng)絡(luò)監(jiān)控體系就顯得十分重要诫隅，通過海量數(shù)據(jù)的分析來對(duì)網(wǎng)絡(luò)問題精確定位。
通過對(duì)數(shù)據(jù)的分析以及調(diào)研帐偎、用戶反饋逐纬，發(fā)現(xiàn)移動(dòng)端網(wǎng)絡(luò)常常存在如下的問題：
網(wǎng)絡(luò)成功率低，經(jīng)常請(qǐng)求失敗
用戶反饋 DNS 劫持削樊，數(shù)據(jù)被篡改豁生，出現(xiàn)廣告和請(qǐng)求超時(shí)等情況
網(wǎng)絡(luò)延遲較長(zhǎng)，且存在較多的長(zhǎng)尾數(shù)據(jù)
經(jīng)過數(shù)據(jù)分析漫贞，發(fā)現(xiàn)長(zhǎng)連的時(shí)間明顯比短連的時(shí)間少 100ms 左右（短連指的是甸箱，經(jīng)過DNS解析、 TCP 握手迅脐、 SSL 握手等一系列的過程建立連接芍殖，長(zhǎng)連指的是直接復(fù)用前者的連接通道）
網(wǎng)絡(luò)經(jīng)常出現(xiàn)抖動(dòng)，本來大部分請(qǐng)求都是 100ms 左右仪际，突然冒出來一兩千毫秒的围小，甚至有10、20秒的延遲情況
HTTP
1.1的head of blocking 情況存在树碱，一個(gè)網(wǎng)絡(luò)抖動(dòng)肯适，很容易影響后續(xù)的請(qǐng)求，導(dǎo)致一連串的延遲較高請(qǐng)求（head of
blocking：指的是在 HTTP 1.1 中成榜，如果你發(fā)出1框舔、2、3 三個(gè)網(wǎng)絡(luò)請(qǐng)求赎婚，那么 Response 的順序 2刘绣、3
要在第一個(gè)網(wǎng)絡(luò)請(qǐng)求之后）
傳輸?shù)?Payload 太大，延遲高挣输，易超時(shí)
蘋果要求HTTPS 纬凤，此時(shí)加入的 SSL 握手較耗時(shí)
針對(duì)上面一系列的問題，業(yè)界已經(jīng)有很多解決方案撩嚼，我在這里簡(jiǎn)單列舉一些
面對(duì)這樣的網(wǎng)絡(luò)停士，如何解決？
對(duì)于
DNS 劫持的情況完丽，業(yè)界的主要做法是 HTTPDNS 或者內(nèi)置 Server IP 列表恋技。客戶端直接訪問 HttpDNS
接口逻族，獲取業(yè)務(wù)在域名配置管理系統(tǒng)上配置的訪問延遲最優(yōu)的IP蜻底，獲取到IP后就直接往此IP發(fā)送業(yè)務(wù)協(xié)議請(qǐng)求，不需要使用本地運(yùn)營(yíng)商解析域名聘鳞，所以從根本避免了劫持問題薄辅，同時(shí)可以降低網(wǎng)絡(luò)延遲，提高連接成功率搁痛。而建立
Server IP 列表长搀，是在本地緩存一個(gè) IP 的映射表，此表可在App啟動(dòng)時(shí)動(dòng)態(tài)下發(fā)更新鸡典，訪問服務(wù)器時(shí)直接拿出 IP 發(fā)出請(qǐng)求源请。
傳輸?shù)?/p>
Payload 也直接影響了延遲，并且對(duì)成功率有影響彻况，對(duì)于數(shù)據(jù)的壓縮谁尸，業(yè)界很多公司已經(jīng)開始使用 ProtoBuf
協(xié)議，對(duì)于優(yōu)化的百分比我還沒有準(zhǔn)確的說數(shù)據(jù)結(jié)論纽甘，但是從大家的反饋來說良蛮，優(yōu)化效果明顯。對(duì)于數(shù)據(jù)的壓縮悍赢，還可以考慮接入 HTTP
2.0决瞳，畢竟這是一個(gè)趨勢(shì)货徙，也有較多公司已經(jīng)加入 HTTP 2.0，HTTP 2.0 通過頭部壓縮等方式也幫你減小了傳輸?shù)?Payload皮胡。
上面的問題其實(shí)很多是涉及到長(zhǎng)連與短連的問題痴颊，對(duì)這個(gè)問題有較多的問題可以考慮
域名合并：淘寶、美團(tuán)等公司公布的方案中都有提到屡贺，就是將公司原來很多域名的情況蠢棱，合并為較少的幾個(gè)域名，為什么這么做呢甩栈？HTTP 的通道復(fù)用是基于域名劃分的泻仙，如果域名只有幾個(gè)，那么多數(shù)請(qǐng)求都可以在長(zhǎng)連接通道進(jìn)行量没，這樣就可以降低延遲玉转、增加成功率。
盡早建立長(zhǎng)連接允蜈，這樣其他的業(yè)務(wù)請(qǐng)求就可以復(fù)用長(zhǎng)連接通道冤吨，加快訪問速度。對(duì)于建立連接的時(shí)機(jī)饶套，可以考慮多個(gè)方面漩蟆，比如冷啟動(dòng)，前后臺(tái)切換妓蛮、網(wǎng)絡(luò)切換等
考慮接入
HTTP2.0怠李，他們兩個(gè)都解決了 HTTP 1.1 的head of
blocking，降低了網(wǎng)絡(luò)延遲蛤克，提供了更強(qiáng)大的多路復(fù)用技術(shù)捺癞，還加入了流量控制、新的二進(jìn)制格式构挤、Server
Push髓介、請(qǐng)求優(yōu)先級(jí)和依賴等特性〗钕郑或者接入 SPDY 唐础，但是目前覺得好像直接上 HTTP 2.0 比較合適
建立多通道，比如攜程矾飞、美團(tuán)等公司都有自己TCP一膨、UDP通道，具有多域名共用通道洒沦，成功率三個(gè)九等誘人的功效豹绪。同時(shí)各大廠也對(duì)新的網(wǎng)絡(luò)協(xié)議，比如 QUIC申眼，進(jìn)行嘗試瞒津。Facebook還出一分享蝉衣，對(duì) QUIC 改進(jìn)，實(shí)現(xiàn) TLS 的 0-RTT
再者還有一些其他可以考慮的點(diǎn)
加入 CDN 加速巷蚪，動(dòng)靜資源分離
對(duì)于埋點(diǎn)的數(shù)據(jù)买乃，也可以合并請(qǐng)求，減少流量
App 網(wǎng)絡(luò)診斷
根據(jù)網(wǎng)絡(luò)情況钓辆，動(dòng)態(tài)設(shè)置超時(shí)時(shí)間等
