本篇文章是對bang神的文章
進行的總結，文章中也加了的一些
自己的理解與擴充套件。
我們每次在做業務做網路請求的時候，想必每個人都思考過如何進一步優化網路請求吧，比如這三點包括：
正常一條網路請求需要經過的流程是這樣：
這裡有明顯的三個優化點：
依次來分析每個優化點我們能做什麼
1 dns
dns 完整的解析流程很長，會先從本地系統快取取，若沒有就到最近的 dns 伺服器取，若沒有再到主網域名稱伺服器取，每一層都有快取，但為了網域名稱解析的實時性，每一層快取都有過期時間，這種 dns 解析機制有幾個缺點：
為了解決這些問題，就有了 httpdns，這裡有ios版本接入文件httpdns ios客戶端接入文件 ，原理很簡單，就是自己做網域名稱解析的工作，通過 http 請求後台去拿到網域名稱對應的 ip 位址，直接解決上述所有問題：
2、通過簽名等方式，保證 httpdns 請求的安全，避免被劫持。
3、dns 解析由自己控制，可以確保根據使用者所在地返回就近的 ip 位址，或根據客戶端測速結果使用速度最快的 ip。
4、一次請求可以解析多個網域名稱。
2 連線
第二個問題，連線建立耗時的問題，這裡主要的優化思路是復用連線，不用每次請求都重新建立連線，如何更有效率地復用連線，可以說是網路請求速度優化裡最主要的點了，並且這裡的優化仍在演進過程中，值得了解下。
keep-alive
http 協議裡有個 keep-alive，http1.1預設開啟，一定程度上緩解了每次請求都要進行tcp三次握手建立連線的耗時。原理是請求完成後不立即釋放連線，而是放入連線池中，若這時有另乙個請求要發出，請求的網域名稱和埠是一樣的，就直接拿出連線池中的連線進行傳送和接收資料，少了建立連線的耗時。
**實際上現在無論是客戶端還是瀏覽器都預設開啟了keep-alive，對同個網域名稱不會再有每發乙個請求就進行一次建連的情況，純短連線已經不存在了。**但有個問題，就是這個 keep-alive 的連線一次只能傳送接收乙個請求，在上乙個請求處理完成之前，無法接受新的請求。若同時發起多個請求，就有兩種情況：
對這個問題，新一代協議 http2 提出了多路復用去解決。
多路復用
http2 的多路復用機制一樣是復用連線，但它復用的這條連線支援同時處理多條請求，所有請求都可以併發在這條連線上進行，也就解決了上面說的併發請求需要建立多條連線帶來的問題，網路上有張圖可以較形象地表現這個過程：
http1.1的協議裡，在乙個連線裡傳送資料都是序列順序傳送的，必須等上乙個請求全部處理完後，下乙個請求才能進行處理，導致這些請求期間這條連線並不是滿頻寬傳輸的，即使是http1.1的pipelining可以同時傳送多個request，但response仍是按請求的順序序列返回，只要其中乙個請求的response稍微大一點或發生錯誤，就會阻塞住後面的請求。
http2 這裡的多路復用協議解決了這些問題，它把在連線裡傳輸的資料都封裝成乙個個stream，每個stream都有標識，stream的傳送和接收可以是亂序的，不依賴順序，也就不會有阻塞的問題，接收端可以根據stream的標識去區分屬於哪個請求，再進行資料拼接，得到最終資料。
解釋下多路復用這個詞，多路可以認為是多個連線，多個操作，復用就是字面上的意思，復用一條連線或乙個執行緒。http2這裡是連線的多路復用，網路相關的還有乙個i/o的多路復用(select/epoll)，指通過事件驅動的方式讓多個網路請求返回的資料在同一條執行緒裡完成讀寫。
tcp隊頭阻塞
http2 的多路復用看起來是完美的解決方案，但還有個問題，就是隊頭阻塞，這是受限於 tcp 協議，tcp 協議為了保證資料的可靠性，若傳輸過程中乙個 tcp 包丟失，會等待這個包重傳後，才會處理後續的包。http2的多路復用讓所有請求都在同一條連線進行，中間有乙個包丟失，就會阻塞等待重傳，所有請求也就被阻塞了。
對於這個問題不改變 tcp 協議就無法優化，但 tcp 協議依賴作業系統實現以及部分硬體的定製，改進緩慢，於是google 提出 quic 協議，相當於在 udp 協議之上再定義一套可靠傳輸協議，解決 tcp 的一些缺陷，包括隊頭阻塞。quic協議雖然是基於udp，但它不但具有tcp的可靠性、擁塞控制、流量控制等，quic 協議相對於 http2 最大的優勢是對tcp隊頭阻塞的解決，另外，quic協議具有tls的安全傳輸特性，實現了tls的保密功能，同時又使用更少的rtt建立安全的會話。
3 資料
第三個問題，傳輸資料大小的問題。資料對請求速度的影響分兩方面，一是壓縮率，二是解壓序列化反序列化的速度。目前最流行的兩種資料格式是 json 和 protobuf，json 是字串，protobuf 是二進位制，即使用各種壓縮演算法壓縮後，protobuf 仍會比 json 小，資料量上 protobuf 有優勢，序列化速度 protobuf 也有一些優勢，這兩者的對比就不細說了。可以看此文章protobuf 在ios上的實踐來進一步了解protobuf
壓縮演算法多種多樣，也在不斷演進，最新出的 brotli 和z-standard實現了更高的壓縮率，z-standard 可以根據業務資料樣本訓練出適合的字典，進一步提高壓縮率，目前壓縮率表現最好的演算法。
除了傳輸的 body 資料，每個請求 http 協議頭的資料也是不可忽視，http2 裡對 http 協議頭也進行了壓縮，http 頭大多是重複資料，固定的字段如 method 可以用靜態字典，不固定但多個請求重複的字段例如 cookie 用動態字典，可以達到非常高的壓縮率，這裡有詳細介紹。
通過 httpdns，連線多路復用，更好的資料壓縮演算法，可以把網路請求的速度優化到較不錯的程度了，接下來再看看弱網和安全上可以做的事情。
標準協議 tls 保證了網路傳輸的安全，前身是 ssl，不斷在演進，目前最新是 tls1.3。常見的 https 就是 http 協議加上 tls 安全協議。
安全協議概括性地說解決兩個問題：1.保證安全 2. 降低加密成本
在保證安全上：
降低加密成本上：
這些點涉及的細節非常多，對 tls 的介紹有一篇雄文，說得很詳細，在此推薦。
移動 APP 網路優化概述
速度 網路請求的速度怎樣能進一步提公升？弱網 移動端網路環境隨時變化，經常出現網路連線很不穩定可用性差的情況，怎樣在這種情況下最大限度最快地成功請求？安全 怎樣防止被第三方竊聽 篡改或冒充，防止運營商劫持，同時又不影響效能？正常一條網路請求需要經過的流程是這樣 dns 解析，請求dns伺服器，獲取網...
bang 移動 APP 網路優化概述
速度 網路請求的速度怎樣能進一步提公升？弱網 移動端網路環境隨時變化，經常出現網路連線很不穩定可用性差的情況，怎樣在這種情況下最大限度最快地成功請求？安全 怎樣防止被第三方竊聽 篡改或冒充，防止運營商劫持，同時又不影響效能？正常一條網路請求需要經過的流程是這樣 dns 解析，請求dns伺服器，獲取網...
移動app傳統測試流程優化
本文出自天外歸雲的 在傳統的軟體測試流程中，每一期需求從開發到上線都要經歷從需求分析與評審 測試用例評審 開發 測試 發布的流程。其中測試包含了後台測試 前端web測試 客戶端測試。後台測試又包括後台 邏輯測試 介面測試 介面壓力測試等，web端測試包含了前端頁面的ui介面測試 pc與移動端瀏覽器相...