Android網路【轉】
文章整理自內部網路模組同事一些課程的分享時所做的一些筆記
I. 無線網路的影響
1) 無線網路物理影響:
- 丟包多
- 頻寬受限
2) 無線網路第三方影響:
- 第三方運營商中間做手腳
II. 解決不穩定手段–TCP
TCP在行動網路中的缺陷
不是基於行動網路優化的
最優網路的關鍵點
- 超時
- 重試
- 間隔設計
TCP自帶可靠性保障
-
序號 確認
-
檢驗和(但不可靠)
可以保證每個包是對的,10G左右的檔案就會出現錯誤(檢驗和的錯誤(幾種不通過的檢驗和達到一個對的/第三方運營商做手腳)) -
超時重傳(TCP中最重要與複雜的問題)
傳送每個報文都有計時器保障在計時器的時間裡 是否有答覆(無答覆重發) (3s/6s/12s/24s/48s/96s 32^n)
重發:*無網路感知,網路斷開會無限重發,所以需要做超時
處理
ps: 網路有可能出現雪崩(網路資源供不應求(所以TCP是
指數退避
的機制BLG))
針對關鍵點策略
-
Connect超時
(ios TCP: 6s前 重試: 每次間隔1s) -
首包超時
發一個數據出去,伺服器的答覆時間,來確定是否網路有問題ps: 微信是 (資料長度/估計速度(根據網路型別估算) + 伺服器處理時間(Wechat Server(10s))) 相關於 (並行處理的係數(競爭任務數*係數))
-
分包超時
解決網路偶斷的問題
wechat : GPRS: 10s、 Wifi: 8s -
讀寫超時
(微信 64k回包)(2g 10k/s 6s伺服器處理時間,要30s)
通過首包超時
與分包超時
減少 TCP重試間隔 來加快讀寫ps: 微信是 首包超時 + 接收資料長度/估算速度
-
重試次數
兩次(因為第一次失敗可能是偶然,第二次偶然失敗概率很低(那就很有可能必然失敗)) -
重試間隔
第一次重試快重試(間隔小),第二重試慢重試(間隔大) -
任務超時
統一的返回時間,無論以上任何因素的表現如何,任務超時時間統一。
III. 處理頻寬受限問題
解決問題關鍵字
- 速度(發圖)
- 最低失敗成本(斷點續傳)
兩點場景
- 接收方處理能力不足
- 線路內部堵塞
TCP自帶的解決方案
-
滑動視窗協議
傳送視窗長度 計算: Min[rwnd(接收端視窗)(TCP中的一個欄位從伺服器帶回來), cwnd(擁塞埠(通過探測獲得))] -
慢開始和擁塞避免
避免演算法 -
快重傳
最高速因數
-
減少send呼叫次數
-
寫滿TCP傳送buffer(填滿傳送視窗)
-
控制好資料處理執行緒(提高處理能力來提高速度)(接收方策略)(接收方每次讀一次資料,接收視窗就會變大,(Android寫磁碟效率低,秒級))
-
單socket vs 多 socket
IV. 長連結需要注意
DNS特點:
-
不可靠
運營商劫持、運營商控制超時控制(域名解析更新)、可用資訊、批量解釋的優化。
ps: 微信是自建DNS伺服器
長連結
為什麼需要心跳:
-
保證連線有效(防止中間與微信後臺 資源回收)
-
TCP在鏈路層上需要傳送資料的時候,才會得到信令
ps: 微信心跳時間: 5min
信令風暴
心跳等導致頻繁的請求信令。(目前在國內是移動渠道比較多)
資源回收情況:
-
3/4G網路
國內情況:移動之前是5min,目前10min。
國外情況: google是10min/28min -
智慧心跳
自己探測處理移動在5min、10min、15min。
聯通與電信都在: 10min
V. 應用層協議設計
網路協議:
- HTTP、TCP、FTP….
內容組織 => 網路通道 => 伺服器 => 回包
網路協議關鍵字
1. 語法(如何組織表達的內容)
1) 文字:diy
、k-v
、xml
(編解碼慢)、json
2) 二進位制(需要自描述(型別、長度)):TLV
(Tag-Length-Value)、Protobuf
3) 其他
2. 語義(表達內容(格式的設計))
需要考慮的: 可擴充套件、相容、併發、高效實時、省流量
協議內容:
1) 業務資料
2) 信令資料:
分包(octet-stuffing、octet-counting、connect-blasting)、併發處理(序列號、命令號)、相容性&拓展性(版本號,壓縮演算法、加密演算法)、精簡(嚴格按照packed所需大小)
3. 時序(先後順序)