Android開發技術周報176學習記錄

標籤：-o   死迴圈   網路連接   play   rda   httpd   策略   important   tls   

Android開發技術周報176學習記錄教程當 OkHttp 遇上 Http 2.0

http://fucknmb.com/2018/04/16/%E5%BD%93OkHttp%E9%81%87%E4%B8%8AHttp-2-0/

記錄

問題：App上的菊花一直在轉消失不掉。
原因：okhttp3.4.1在http2.0下使用了被關閉的串連，導致出現無限迴圈。在http code!=200時，重連，沒有結束死迴圈導致的。
解決：在http code!=200時流為關閉的情況下，串連意外中斷觸發了這個死迴圈，避免檔案的簡單有效途徑是http code不論多少，直接關閉。

Android用戶端網路效能調優之HTTP/2協議升級

https://mp.weixin.qq.com/s/N16jX2zRT3mlaJF4ixDhMg

記錄

HTTP/2與HTTP/1.X的區別

• 二進位分幀
  在應用程式層與傳輸層之間增加一個二進位分幀層，以此達到在不改動HTTP的語義、HTTP方法、狀態代碼、URI及首部欄位的情況下，突破HTTP1.1的效能限制，改進傳輸效能，實現低延遲和高輸送量。
  在二進位分幀層上，HTTP2.0會將所有傳輸的資訊分割為更小的資訊和幀，並對它們採用二進位格式的編碼。
• 壓縮頭部
  HTTP/1.X的header由於cookie和user agent很容易膨脹，而且每次都要重複發送。
  http2.0使用HPACK演算法壓縮來減少需要傳輸的header大小，通訊雙方各自緩衝一份header fields表，既避免了重複header的傳輸，又減小了需要傳輸的包數量，從而降低了延遲。
• 多工
  用戶端和服務端可以把HTTP訊息分解為互不依賴的幀，然後亂序發送，最後再在另一端把它們重新組合起來。
  在一條串連上，可以同時發送無數個請求，並且響應可以同時返回。

Android用戶端基於HTTP/2協議之上的最佳化

• 相容HttpDns方案
  用戶端統一介面和圖片的HTTP/2網路請求適配了自研HttpDns服務，避免了電訊廠商LocalDNS解析劫持，提高了使用者解析成功率，同時也加快了伺服器解析切換的生效時間，減少了故障影響範圍。
  Android原生網路介面HttpUrlConnection不支援HTTP/2協議，用戶端網路模組可以繼承Square公司開源的網路組件OkHttp，OkHttp組建原生支援HTTP/2協議，然而在相容HttpDns服務時，需要解決如下幾個問題：
  （1）URL中host替換為HttpDns的IP後HTTP/2協議轉換：authority欄位修正
  HTTP/2協議RFC文檔中採用：authority欄位代替HTTP/1.X Header中Host欄位，Okhttp未在V3.6.0版本之前做兩個欄位之間的轉換，導致nginx伺服器取不到正確的authority欄位，無法實現請求轉寄。
  網路模組接入HttpDns將請求URL中的Host欄位替換為HttpDns下的IP,然後在Header中增加Host欄位，這樣可以保證後台nginx伺服器能正確轉寄請求。
  （2）URL中host替換為HttpDns的IP後SSL/TLS握手初期SNI欄位修正
  SNI(Server Name Indication)是為瞭解決一個伺服器使用多個網域名稱和認證的SSL/TLS擴充。工作原理就是在串連到伺服器建立SSL/TLS串連之前先發送要訪問網站的網域名稱（Hostname），這樣伺服器根據這個網域名稱返回一個合適的認證。
  由於SNI的傳遞過程是基於傳輸層（TCP）層，所以如果基於HTTP協議層的Header欄位帶Host是不能生效的，這裡對Okhttp的Sni傳遞流程做了改造，將Sni參數從應用程式層透傳到傳輸層，從而解決了Sni從現有URL中解析出來為服務端無法識別的問題。
  （3）HTTP/2長串連簡曆握手過程中網路網域名稱校正問題修正
  網域名稱校正是Https握手過程中驗證認證有效性的重要環節，目的是為了驗證服務端下憑證授權單位的合法性，如果簡單忽略掉網域名稱校正，將會給中間人可乘之機。
  Okhttp的握手過程Host是從URL中解析出的，如果URL中的Host被HostDns的IP地址替換，Https握手校正過程將會失敗，這裡也是通過對OKhttp傳輸層握手過程進行改造，透傳了正確的Host欄位，適配了HttpDns IP直連這種情境。

• 用戶端HTTP/2長串連管理最佳化
  問題：應用長期在後台後切換到前台或者手機長時間休眠後喚醒應用有載入逾時的現象。
  分析：用戶端需要保持週期性網路長串連鏈路，而Android系統版本迭代過程中隨著系統對耗電量及流量的管理越發嚴格，會在休眠或者Idle過程中在系統級關閉網路連接，未能及時通知應用程式層串連已經斷開，導致網路請求逾時，逾時請求等待時間過長，使用者體驗極差。
  改善：為了改善長串連丟失後的請求逾時情況，用戶端針對Okhttp新增Ping幀心跳機制，流程如下：
  （1）用戶端基於HTTP/2協議進行網路通訊，HTTP/2從底層實現了多工，多個請求共用一條鏈路進行請求，當用戶端處於空閑狀態時，鏈路依然保持存活。
  （2）實現固定時間間隔發送Ping幀給服務端，如果服務端能在規定時間內返回結果，則繼續下一輪心跳。
  （3）一共心跳n(n為服務端發送心跳次數)次之後，如果仍然處於idle狀態，則主動發送Goaway幀給服務端釋放串連，然後釋放本地串連。
  （4）如果在n次心跳周期內檢測到某次心跳逾時，則直接釋放本地串連，下次請求時重新發起請求。

• SSL/TLS握手過程深度最佳化
  已有的HTTPS，HTTP/2協議需要設定串連，每次新的TLS串連都需要握手，以便建立共用的加密金鑰，這個握手過程在標準TCP的握手過程之上還需要兩個額外的來回過程（共有7次握手），會在請求效率上造成時延。TLS有幾個特徵可以用來消除額外的來回，比如重用一個會話session，兩個標準會話重用機制是session IDs(RFC 5246)和session tickets(RFC 5077)，使用其中一個技術，一個用戶端可以重用之前建立的會話，這個會話是之前和伺服器進行握手成功的，這樣可以減少一次來回過程。
  例子客戶端支援TLS session tickets重用機制，session tickets是用只有服務端知道的安全祕密金鑰加密過的會話資訊，最終儲存到移動終端。移動端TLS握手時帶上session tickets資訊，只要伺服器能成功解密就可以完成快速握手。
• 使用者訪問品質監控及網路容災性最佳化
  對訪問品質的監控和容災性上做的最佳化：
  （1）考慮到線上使用者數量激增的情況下，可能導致服務端效能壓力過大，用戶端增加了線上開關控制HTTP/2協議開啟狀態；一旦出現異常，可以及時調整開關復原。
  （2）對HTTP/2開啟後增加異常埋點上報，如果有異常，能夠通過監控平台及時發現問題，並且查詢問題使用者的異常詳情。
  （3）當HTTP/2請求發生異常時，用戶端會發起降級重試機制，降級策略包含重試、協議降級、內建拔測、只能路由等策略，目的是為了增強用戶端網路容災性。
  （4）在應用內增加網路型能統計資料監控，開發及營運人員可以全面監控網路效能。

Android開發技術周報176學習記錄