原文出處：?bang
一般開發(fā)一個(gè) APP，會(huì)直接調(diào)用系統(tǒng)提供的網(wǎng)絡(luò)請(qǐng)求接口去服務(wù)端請(qǐng)求數(shù)據(jù)，再針對(duì)返回的數(shù)據(jù)進(jìn)行一些處理摹闽，或者使用AFNetworking/OKHttp這樣的網(wǎng)絡(luò)庫，管理好請(qǐng)求線程和隊(duì)列，再自動(dòng)做一些數(shù)據(jù)解析丹鸿，就結(jié)束了。
但對(duì)于一些大型 APP棚品，還會(huì)想針對(duì)網(wǎng)絡(luò)的一些問題進(jìn)行進(jìn)一步優(yōu)化靠欢，包括：
速度：網(wǎng)絡(luò)請(qǐng)求的速度怎樣能進(jìn)一步提升？
弱網(wǎng)：移動(dòng)端網(wǎng)絡(luò)環(huán)境隨時(shí)變化铜跑，經(jīng)常出現(xiàn)網(wǎng)絡(luò)連接很不穩(wěn)定可用性差的情況门怪，怎樣在這種情況下最大限度最快地成功請(qǐng)求？
安全：怎樣防止被第三方竊聽/篡改或冒充锅纺，防止運(yùn)營商劫持掷空，同時(shí)又不影響性能？
對(duì)基于瀏覽器的前端開發(fā)來說囤锉，網(wǎng)絡(luò)這塊能做的事情很少坦弟，但對(duì)于客戶端 APP 來說，整個(gè)網(wǎng)絡(luò)請(qǐng)求過程是自由控制的官地，可以做很多事情减拭，很多大型 APP 都針對(duì)這三個(gè)問題做了很多網(wǎng)絡(luò)層的優(yōu)化，一些新的網(wǎng)絡(luò)層協(xié)議像 HTTP2 / QUIC 也是在這些方面進(jìn)行了不少優(yōu)化区丑，在這里邊學(xué)習(xí)邊整理拧粪，大致列舉一下常見的做法。
速度
正常一條網(wǎng)絡(luò)請(qǐng)求需要經(jīng)過的流程是這樣：
DNS 解析沧侥，請(qǐng)求DNS服務(wù)器可霎，獲取域名對(duì)應(yīng)的 IP 地址。
與服務(wù)端建立連接宴杀，包括 tcp 三次握手癣朗，安全協(xié)議同步流程。
連接建立完成旺罢，發(fā)送和接收數(shù)據(jù)旷余，解碼數(shù)據(jù)绢记。
這里有明顯的三個(gè)優(yōu)化點(diǎn)：
直接使用 IP 地址，去除 DNS 解析步驟正卧。
不要每次請(qǐng)求都重新建立連接蠢熄，復(fù)用連接或一直使用同一條連接(長連接)。
壓縮數(shù)據(jù)炉旷，減小傳輸?shù)臄?shù)據(jù)大小签孔。
逐條來看能做什么。
1.DNS
DNS 完整的解析流程很長窘行，會(huì)先從本地系統(tǒng)緩存取饥追，若沒有就到最近的 DNS 服務(wù)器取，若沒有再到主域名服務(wù)器取罐盔，每一層都有緩存但绕，但為了域名解析的實(shí)時(shí)性，每一層緩存都有過期時(shí)間惶看，這種 DNS 解析機(jī)制有幾個(gè)缺點(diǎn)：
緩存時(shí)間設(shè)置得長壁熄，域名更新不及時(shí)，設(shè)置得短碳竟，大量 DNS 解析請(qǐng)求影響請(qǐng)求速度。
域名劫持狸臣，容易被中間人攻擊莹桅，或被運(yùn)營商劫持，把域名解析到第三方 IP 地址烛亦，據(jù)統(tǒng)計(jì)劫持率會(huì)達(dá)到7%诈泼。
DNS 解析過程不受控制，無法保證解析到最快的IP
一次請(qǐng)求只能解析一個(gè)域名煤禽。
為了解決這些問題铐达，就有了 HTTPDNS，原理很簡(jiǎn)單檬果，就是自己做域名解析的工作瓮孙，通過 HTTP 請(qǐng)求后臺(tái)去拿到域名對(duì)應(yīng)的 IP 地址，直接解決上述所有問題：
域名解析與請(qǐng)求分離选脊，所有請(qǐng)求都直接用IP地址杭抠，無需 DNS 解析，APP 定時(shí)請(qǐng)求 HTTPDNS 服務(wù)器更新IP地址即可恳啥。
通過簽名等方式偏灿，保證 HTTPDNS 請(qǐng)求的安全，避免被劫持钝的。
DNS 解析由自己控制翁垂，可以確保根據(jù)用戶所在地返回就近的 IP 地址铆遭，或根據(jù)客戶端測(cè)速結(jié)果使用速度最快的 IP。
一次請(qǐng)求可以解析多個(gè)域名沿猜。
其余細(xì)節(jié)就不多說了枚荣，HTTPDNS 優(yōu)點(diǎn)這么多，幾乎成為中大型 APP 的標(biāo)配邢疙。至此解決了第一個(gè)問題 — DNS 解析耗時(shí)的問題棍弄，順便把一部分安全問題 — DNS 劫持也解決了。
2.連接
第二個(gè)問題疟游，連接建立耗時(shí)的問題呼畸，這里主要的優(yōu)化思路是復(fù)用連接，不用每次請(qǐng)求都重新建立連接颁虐，如何更有效率地復(fù)用連接蛮原，可以說是網(wǎng)絡(luò)請(qǐng)求速度優(yōu)化里最主要的點(diǎn)了，并且這里的優(yōu)化仍在演進(jìn)過程中另绩，值得了解下儒陨。
keep-alive
HTTP 協(xié)議里有個(gè) keep-alive，HTTP1.1默認(rèn)開啟笋籽，一定程度上緩解了每次請(qǐng)求都要進(jìn)行TCP三次握手建立連接的耗時(shí)蹦漠。原理是請(qǐng)求完成后不立即釋放連接，而是放入連接池中车海，若這時(shí)有另一個(gè)請(qǐng)求要發(fā)出笛园，請(qǐng)求的域名和端口是一樣的，就直接拿出連接池中的連接進(jìn)行發(fā)送和接收數(shù)據(jù)侍芝，少了建立連接的耗時(shí)研铆。
實(shí)際上現(xiàn)在無論是客戶端還是瀏覽器都默認(rèn)開啟了keep-alive，對(duì)同個(gè)域名不會(huì)再有每發(fā)一個(gè)請(qǐng)求就進(jìn)行一次建連的情況州叠，純短連接已經(jīng)不存在了棵红。但有個(gè)問題，就是這個(gè) keep-alive 的連接一次只能發(fā)送接收一個(gè)請(qǐng)求咧栗，在上一個(gè)請(qǐng)求處理完成之前逆甜，無法接受新的請(qǐng)求。若同時(shí)發(fā)起多個(gè)請(qǐng)求致板，就有兩種情況：
若串行發(fā)送請(qǐng)求忆绰，可以一直復(fù)用一個(gè)連接，但速度很慢可岂，每個(gè)請(qǐng)求都要等待上個(gè)請(qǐng)求完成再進(jìn)行發(fā)送错敢。
若并行發(fā)送這些請(qǐng)求，那么首次每個(gè)請(qǐng)求都要進(jìn)行tcp三次握手建立新的連接，雖然第二次可以復(fù)用連接池里這堆連接稚茅，但若連接池里保持的連接過多纸淮，對(duì)服務(wù)端資源產(chǎn)生較大浪費(fèi)，若限制了保持的連接數(shù)亚享，并行請(qǐng)求里超出的連接仍每次要建連咽块。
對(duì)這個(gè)問題，新一代協(xié)議 HTTP2 提出了多路復(fù)用去解決欺税。
多路復(fù)用
HTTP2 的多路復(fù)用機(jī)制一樣是復(fù)用連接侈沪，但它復(fù)用的這條連接支持同時(shí)處理多條請(qǐng)求，所有請(qǐng)求都可以并發(fā)在這條連接上進(jìn)行晚凿，也就解決了上面說的并發(fā)請(qǐng)求需要建立多條連接帶來的問題亭罪，網(wǎng)絡(luò)上有張圖可以較形象地表現(xiàn)這個(gè)過程：
HTTP1.1的協(xié)議里，在一個(gè)連接里傳送數(shù)據(jù)都是串行順序傳送的歼秽，必須等上一個(gè)請(qǐng)求全部處理完后应役，下一個(gè)請(qǐng)求才能進(jìn)行處理，導(dǎo)致這些請(qǐng)求期間這條連接并不是滿帶寬傳輸?shù)脑锟辏词故荋TTP1.1的pipelining可以同時(shí)發(fā)送多個(gè)request箩祥，但response仍是按請(qǐng)求的順序串行返回，只要其中一個(gè)請(qǐng)求的response稍微大一點(diǎn)或發(fā)生錯(cuò)誤肆氓，就會(huì)阻塞住后面的請(qǐng)求袍祖。
HTTP2 這里的多路復(fù)用協(xié)議解決了這些問題，它把在連接里傳輸?shù)臄?shù)據(jù)都封裝成一個(gè)個(gè)stream谢揪，每個(gè)stream都有標(biāo)識(shí)蕉陋，stream的發(fā)送和接收可以是亂序的，不依賴順序键耕，也就不會(huì)有阻塞的問題，接收端可以根據(jù)stream的標(biāo)識(shí)去區(qū)分屬于哪個(gè)請(qǐng)求柑营，再進(jìn)行數(shù)據(jù)拼接屈雄，得到最終數(shù)據(jù)。
解釋下多路復(fù)用這個(gè)詞官套，多路可以認(rèn)為是多個(gè)連接酒奶，多個(gè)操作，復(fù)用就是字面上的意思奶赔，復(fù)用一條連接或一個(gè)線程惋嚎。HTTP2這里是連接的多路復(fù)用，網(wǎng)絡(luò)相關(guān)的還有一個(gè)I/O的多路復(fù)用(select/epoll)站刑，指通過事件驅(qū)動(dòng)的方式讓多個(gè)網(wǎng)絡(luò)請(qǐng)求返回的數(shù)據(jù)在同一條線程里完成讀寫另伍。
客戶端來說，iOS9 以上 NSURLSession 原生支持 HTTP2，只要服務(wù)端也支持就可以直接使用摆尝，Android 的 okhttp3 以上也支持了 HTTP2温艇，國內(nèi)一些大型 APP 會(huì)自建網(wǎng)絡(luò)層，支持 HTTP2 的多路復(fù)用堕汞，避免系統(tǒng)的限制以及根據(jù)自身業(yè)務(wù)需要增加一些特性勺爱，例如微信的開源網(wǎng)絡(luò)庫?mars，做到一條長連接處理微信上的大部分請(qǐng)求讯检，多路復(fù)用的特性上基本跟 HTTP2 一致琐鲁。
TCP隊(duì)頭阻塞
HTTP2 的多路復(fù)用看起來是完美的解決方案，但還有個(gè)問題人灼，就是隊(duì)頭阻塞围段，這是受限于 TCP 協(xié)議，TCP 協(xié)議為了保證數(shù)據(jù)的可靠性挡毅，若傳輸過程中一個(gè) TCP 包丟失蒜撮，會(huì)等待這個(gè)包重傳后，才會(huì)處理后續(xù)的包跪呈。HTTP2的多路復(fù)用讓所有請(qǐng)求都在同一條連接進(jìn)行段磨，中間有一個(gè)包丟失，就會(huì)阻塞等待重傳耗绿，所有請(qǐng)求也就被阻塞了苹支。
對(duì)于這個(gè)問題不改變 TCP 協(xié)議就無法優(yōu)化，但 TCP 協(xié)議依賴操作系統(tǒng)實(shí)現(xiàn)以及部分硬件的定制误阻，改進(jìn)緩慢债蜜，于是 GOOGLE 提出 QUIC 協(xié)議，相當(dāng)于在 UDP 協(xié)議之上再定義一套可靠傳輸協(xié)議究反，解決 TCP 的一些缺陷寻定，包括隊(duì)頭阻塞。具體解決原理網(wǎng)上資料較多精耐，可以看看狼速。
QUIC 處于起步階段，少有客戶端接入卦停，QUIC 協(xié)議相對(duì)于 HTTP2 最大的優(yōu)勢(shì)是對(duì)TCP隊(duì)頭阻塞的解決向胡，其他的像安全握手 0RTT / 證書壓縮等優(yōu)化 TLS1.3 已跟進(jìn)，可以用于 HTTP2惊完，并不是獨(dú)有特性僵芹。TCP 隊(duì)頭阻塞在 HTTP2 上對(duì)性能的影響有多大，在速度上 QUIC 能帶來多大提升待研究小槐。
3.數(shù)據(jù)
第三個(gè)問題拇派，傳輸數(shù)據(jù)大小的問題。數(shù)據(jù)對(duì)請(qǐng)求速度的影響分兩方面，一是壓縮率攀痊，二是解壓序列化反序列化的速度桐腌。目前最流行的兩種數(shù)據(jù)格式是 json 和 protobuf，json 是字符串苟径，protobuf 是二進(jìn)制案站，即使用各種壓縮算法壓縮后，protobuf 仍會(huì)比 json 小棘街，數(shù)據(jù)量上 protobuf 有優(yōu)勢(shì)蟆盐，序列化速度 protobuf 也有一些優(yōu)勢(shì)，這兩者的對(duì)比就不細(xì)說了遭殉。
壓縮算法多種多樣石挂，也在不斷演進(jìn)，最新出的 Brotli 和Z-standard實(shí)現(xiàn)了更高的壓縮率险污，Z-standard?可以根據(jù)業(yè)務(wù)數(shù)據(jù)樣本訓(xùn)練出適合的字典痹愚，進(jìn)一步提高壓縮率，目前壓縮率表現(xiàn)最好的算法蛔糯。
除了傳輸?shù)?body 數(shù)據(jù)拯腮，每個(gè)請(qǐng)求 HTTP 協(xié)議頭的數(shù)據(jù)也是不可忽視，HTTP2 里對(duì) HTTP 協(xié)議頭也進(jìn)行了壓縮蚁飒，HTTP 頭大多是重復(fù)數(shù)據(jù)动壤，固定的字段如 method 可以用靜態(tài)字典，不固定但多個(gè)請(qǐng)求重復(fù)的字段例如 cookie 用動(dòng)態(tài)字典淮逻，可以達(dá)到非常高的壓縮率琼懊，這里有詳細(xì)介紹。
通過 HTTPDNS爬早，連接多路復(fù)用哼丈，更好的數(shù)據(jù)壓縮算法，可以把網(wǎng)絡(luò)請(qǐng)求的速度優(yōu)化到較不錯(cuò)的程度了筛严，接下來再看看弱網(wǎng)和安全上可以做的事情醉旦。
弱網(wǎng)
手機(jī)無線網(wǎng)絡(luò)環(huán)境不穩(wěn)定，針對(duì)弱網(wǎng)的優(yōu)化脑漫，微信有較多實(shí)踐和分享髓抑，包括：
提升連接成功率
復(fù)合連接咙崎，建立連接時(shí)优幸，階梯式并發(fā)連接，其中一條連通后其他連接都關(guān)閉褪猛。這個(gè)方案結(jié)合串行和并發(fā)的優(yōu)勢(shì)网杆，提高弱網(wǎng)下的連接成功率，同時(shí)又不會(huì)增加服務(wù)器資源消耗：
制定最合適的超時(shí)時(shí)間
對(duì)總讀寫超時(shí)(從請(qǐng)求到響應(yīng)的超時(shí))、首包超時(shí)碳却、包包超時(shí)(兩個(gè)數(shù)據(jù)段之間的超時(shí))時(shí)間制定不同的計(jì)算方案队秩，加快對(duì)超時(shí)的判斷，減少等待時(shí)間昼浦，盡早重試馍资。這里的超時(shí)時(shí)間還可以根據(jù)網(wǎng)絡(luò)狀態(tài)動(dòng)態(tài)設(shè)定。
調(diào)優(yōu)TCP參數(shù)关噪，使用TCP優(yōu)化算法鸟蟹。
對(duì)服務(wù)端的TCP協(xié)議參數(shù)進(jìn)行調(diào)優(yōu)，以及開啟各種優(yōu)化算法使兔，使得適合業(yè)務(wù)特性和移動(dòng)端網(wǎng)絡(luò)環(huán)境建钥，包括RTO初始值，混合慢啟動(dòng)虐沥，TLP熊经，F(xiàn)-RTO等。
針對(duì)弱網(wǎng)的這些細(xì)致優(yōu)化未成為標(biāo)準(zhǔn)欲险，系統(tǒng)網(wǎng)絡(luò)庫沒有內(nèi)置镐依，不過前兩個(gè)客戶端優(yōu)化微信的開源網(wǎng)絡(luò)庫 mars 有實(shí)現(xiàn)，若有需要可以使用盯荤。
安全
標(biāo)準(zhǔn)協(xié)議 TLS 保證了網(wǎng)絡(luò)傳輸?shù)陌踩雎穑吧硎?SSL，不斷在演進(jìn)秋秤，目前最新是 TLS1.3宏粤。常見的 HTTPS 就是 HTTP 協(xié)議加上 TLS 安全協(xié)議。
安全協(xié)議概括性地說解決兩個(gè)問題：1.保證安全 2. 降低加密成本
在保證安全上：
使用加密算法組合對(duì)傳輸數(shù)據(jù)加密灼卢，避免被竊聽和篡改绍哎。
認(rèn)證對(duì)方身份，避免被第三方冒充鞋真。
加密算法保持靈活可更新崇堰，防止定死算法被破解后無法更換，禁用已被破解的算法涩咖。
降低加密成本上：
用對(duì)稱加密算法加密傳輸數(shù)據(jù)海诲，解決非對(duì)稱加密算法的性能低以及長度限制問題。
緩存安全協(xié)議握手后的密鑰等數(shù)據(jù)檩互，加快第二次建連的速度特幔。
加快握手過程：2RTT-> 0RTT。加快握手的思路闸昨，就是原本客戶端和服務(wù)端需要協(xié)商使用什么算法后才能加密發(fā)送數(shù)據(jù)蚯斯，變成通過內(nèi)置的公鑰和默認(rèn)的算法薄风，在握手的同時(shí)就把數(shù)據(jù)發(fā)出去，也就是不需要等待握手就開始發(fā)送數(shù)據(jù)拍嵌，達(dá)到0RTT遭赂。
這些點(diǎn)涉及的細(xì)節(jié)非常多，對(duì) TLS 的介紹有一篇雄文横辆，說得很詳細(xì)撇他，在此推薦。
目前基本主流都支持 TLS1.2狈蚤，iOS 網(wǎng)絡(luò)庫默認(rèn)使用 TLS1.2逆粹，Android4.4 以上支持 1.2。TLS1.3 iOS 還處于測(cè)試階段炫惩，Android 未查到消息僻弹。對(duì)于普通 APP，只要正確配置證書他嚷，TLS1.2 已經(jīng)能保證傳輸安全蹋绽，只是在建連速度上會(huì)有所損耗，有一些大型 APP 像微信就自行實(shí)現(xiàn)了 TLS1.3 的部分協(xié)議筋蓖，早一步全平臺(tái)支持卸耘。
最后
網(wǎng)絡(luò)優(yōu)化這個(gè)話題非常龐大，本文只是在學(xué)習(xí)過程中從優(yōu)化思路上列舉了目前業(yè)界常見的優(yōu)化點(diǎn)粘咖，還有很多細(xì)節(jié)很多更深入的優(yōu)化沒涉及到蚣抗，網(wǎng)絡(luò)層實(shí)踐開發(fā)經(jīng)驗(yàn)不足，若有錯(cuò)誤歡迎指出瓮下。
