1. 程式人生 > >Android網路【轉】

Android網路【轉】

轉自:https://blog.dreamtobe.cn/2015/03/28/Android%E7%BD%91%E7%BB%9C%E5%AD%A6%E4%B9%A0%E7%AC%94%E8%AE%B0%E6%95%B4%E7%90%86/

文章整理自內部網路模組同事一些課程的分享時所做的一些筆記

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. 處理頻寬受限問題

解決問題關鍵字

  • 速度(發圖)
  • 最低失敗成本(斷點續傳)

兩點場景

  1. 接收方處理能力不足
  2. 線路內部堵塞

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. 應用層協議設計

網路協議:

  1. HTTP、TCP、FTP….

內容組織 => 網路通道 => 伺服器 => 回包

網路協議關鍵字

1. 語法(如何組織表達的內容)

1) 文字:
diyk-vxml(編解碼慢)、json

2) 二進位制(需要自描述(型別、長度)):
TLV(Tag-Length-Value)、Protobuf

3) 其他

2. 語義(表達內容(格式的設計))

需要考慮的: 可擴充套件、相容、併發、高效實時、省流量

協議內容:

1) 業務資料

2) 信令資料:
分包(octet-stuffing、octet-counting、connect-blasting)、併發處理(序列號、命令號)、相容性&拓展性(版本號,壓縮演算法、加密演算法)、精簡(嚴格按照packed所需大小)

3. 時序(先後順序)