一、背景
與有線網絡通信相比，無線網絡通信受環境影響比較大（例如高層建築、用戶移動、環境噪音、相對封閉環境等等），網絡的服務質量相對來說不是非常穩定，導致用戶經常會在弱信號的網絡環境下通信。而當用戶在這種網絡環境下通信時，則存在較多的丟包、誤碼、超時、連接中斷以及難以接入網絡等情況。通信除了受環境影響以外，網絡覆蓋和室分系統不完善、鄰區漏配、導頻污染、過載控制等原因也都會產生無線呼叫掉線、服務質量下降等問題。
如何度量和模擬“弱網絡”對移動APP的開發有着重大的意義：節約測試成本、易於問題重現、加快產品上線等。一般的方法是使用“丟包率”和“網絡延時”來定義和衡量“弱網絡”[10-12]。
在無線網絡通信中，無線資源（頻率、時間、空間等）是非常稀缺的。為了滿足更多用戶的PS業務需求，移動系統會盡可能地把無線資源復用給不同的用戶。比如，當用戶在一定時間內（對於3G，一般是15秒，對於2G，可能會比較短）不再傳送數據時，移動系統會主動回收分配給該用戶的無線資源，以復用給其它用戶。當該用戶再次需要通信時，移動設備(Mobile Equipment)需要重新申請無線連接，然后才能發送數據。另外，當ME處於能夠隨時發送數據的狀態時，會消耗大量的電能。所以為了節能，ME發現在一定的時間內（一般是2~10秒）沒有數據傳送時，也會主動要求釋放無線資源。申請無線資源是非常昂貴的操作，需要比較多的信令（大約相當於發送或接收一條短消息），如果頻繁發送小數據包（比如心跳），容易導致“信令風暴”。上述的這種類似“快速休眠”特性的延時到底有多長，與ME和網絡都有關系，沒有辦法一概而論。無線網絡的延時情況可以參考圖1：
圖1 無線網絡延時[9]
需要注意的是：在實際情況下，對於GPRS/EDGE網絡出現秒級別的延時也不奇怪。
移動終端APP在通信的過程中消耗電量的情況如何，降低電能消耗的原則有[13]：
1）3G下傳輸數據消耗的電量是WIFI下的幾十倍；
2） 手機在傳輸數據的狀態下消耗的電量要遠遠高於IDLE狀態下消耗的電量；
3）降低發包頻率，盡可能地把數據包合並，然后一起發送；
ME通過無線網絡接入服務器的整個過程如下（以ME主動發起請求為例）：
A）分配無線連接，建立上下行專用的高速信道；
B） 解析接入點(APN)域名，獲取接入Internet的網關GPRS支持節點（GGSN）的IP，然后GGSN進行鑒權，以及為ME分配IP；
C）GGSN執行DNS查詢；
D）建立TCP連接；
E）接收或發送數據；
F）如果沒有數據傳輸，超過一定的時間，釋放無線連接；
G）如果沒有數據傳輸，超過一定的時間，釋放TCP連接；
在整個過程中，減少DNS的影響可能是首要的目標，移動網絡的DNS有如下特點[1]：
· 有一部分全國范圍的DNS承載了超過40%的全網用戶；
· 很多山寨機的終端local dns設置是錯誤的；
· 也包括有線網絡遇到的問題：域名劫持、DNS污染、老化和脆弱等問題；
· 現有的DNS不能把用戶調度到服務的“最優接入點”；
從以上分析可知，如何保證移動互聯網的產品提供穩定的、可預期的服務質量，具有非常大的挑戰。以下幾點原則可能會有幫助：
1） 斷線重連。這可能是最重的一個特性，因為在無線網絡中有太多的原因導致數據連接中斷了。
2） 由於創建連接是一個非常昂貴的操作，所以應盡量減少數據連接的創建次數，且在一次請求中應盡量以批量的方式執行任務。如果多次發送小數據包，應該盡量保證在2秒以內發送出去。在短時間內訪問不同服務器時，盡可能地復用無線連接。
3） 優化DNS查詢。應盡量減少DNS查詢、避免域名劫持、DNS污染，同時把用戶調度到“最優接入點”。
4） 減小數據包大小和優化包量。通過壓縮、精簡包頭、消息合並等方式，來減小數據包大小和包量。
5） 控制數據包大小不超過1500，避免分片。包括邏輯鏈路控制（Logic Link Control）分片、GGSN分片，以及IP分片。其中，當數據包大小超出GGSN所允許的最大大小時，GGSN的處理方式有以下三種：分片、丟棄和拒絕。
6）優化TCP socket參數，包括：是否關閉快速回收、初始RTO、初始擁塞窗口、socket緩存大小、Delay-ACK、Selective-ACK、TCP_CORK、擁塞算法(westwood/TLP/cubic)等。關於這些參數的優化建議可以參考[1-8, 30]。做這件事情的意義在於：由於2G/3G/4G/WIFI/公司內網等接入網絡的QoS差異很大，所以不同網絡下為了取得較好的服務質量，上述參數的取值差異可能會很大。
7） 在弱網絡的情況下，TCP協議中的ACK包是非常昂貴的，延時甚至能夠達到秒級別[14]，而TCP協議的擁塞控制、快速重傳、快速恢復等特性都非常依賴接收端反饋的ACK包。可想而知，如果發送端接收到的ACK包延時太長，會嚴重影響TCP協議的效率。但是如果發送ACK太多又會占用寶貴過多的無線資源。在移動網絡下通信，“在可靠的連接上，如何在減少ACK包的情況下，降低數據包的延時”是研究的熱點[15-28]。基本的思想：平衡冗余包和ACK包個數，達到降低延時，提高吞吐量的目的。例如SGSN和GGSN之間的通信實現：二者之間通過UDP協議通信，發送者在無新的數據包的情況下，每隔一定的時間重試已發送的包，達到最大重試次數后，則丟棄該包。
8） TCP的擁塞控制算法是以“丟包意味着網絡出現擁塞”為假設設計的，很明顯這個假設在無線網絡環境下是不合適的。但是在無線網絡環境下，在設計可靠UDP協議時是否能夠完全丟棄擁塞控制呢？[39]中提出了幾種在無線網絡環境下的TCP友好的擁塞控制算法。
9） 長連接/短連接，支持不同協議（TCP/UDP, http、二進制協議等），支持不同端口等。關於更多的建議請參考[1,14,29]。
目的
在無線網絡環境下，本文將從最優調度和優化傳輸層協議兩個方面來討論如何保證客戶端和服務器的通信成功率，以及提高通信效率。
最優調度設計
系統分解
設計一個新的DNS服務器來實現最優調度，其拓撲結構如下：
圖2DNSvr的拓撲結構
TGCP SDK的職責：
I） 用HTTP的Get/Post方法從DNSvr獲取游戲服務器和DNSvr本身的最優接入點列表。Get/Post方法的查詢參數包括uin/openid、客戶端版本號、IP列表的MD5（注意IP順序）、域名列表、VIP、ServiceID等。
II） 緩存訪問游戲服務器和DNSvr的IP列表，以及其它元數據（比如IP列表等），且以APN為主鍵[34]。
III） 滿足一定的條件下，要主動更新緩存的IP列表，例如緩存過期。
注意：這些職責也可以從TGCP SDK中分離，形成一個獨立的SDK。
Tconnd的職責：
· 路由查詢請求給活動的DNSvr；
·
DNSvr的職責：
I） 根據靜態和動態策略來決定客戶端的“最優接入點”。靜態策略：根據uin/openid、客戶端版本號或者強制規則來決定IP列表；動態策略：燈塔根據測速數據動態決定用戶的游戲服務器接入點。
II） 支持以手動或自動的方式拉黑某些IP。自動方式：由游戲服務器的接入tconnd向DNSvr上報其是否存活（需要向多個點上報，包括用公網IP上報），如果在一定時間內沒有接收到上報或者上報消息中明確所有的邏輯服務器已經掛掉，則自動拉黑相應的IP。如果業務恢復，則自動激活相應的IP。如果項目組接入TGW，對於某個IP和端口是否可用，則需要考慮進程與VIP的映射關系。
III） 在tcaplus中緩存燈塔的計算結果。此時要求DNSvr能夠根據客戶端IP判斷所屬的國家、省份、運營商和網關（可以通過訪問MIG的IP庫實現）[37]。如果緩存了燈塔的計算結果，當緩存超時后，要重新從燈塔拉取相應數據。
燈塔的職責（即哈雷項目[38]）：
根據客戶端IP和服務器接入點IP，返回最優的接入點列表，包括IP的排序，以及客戶端接入的國家、省份、運營商、APN和網關。
Tcaplus的職責：
保存游戲接入的IP列表和端口、靜態策略，或緩存燈塔的計算結果；
主要的流程
· 客戶端批量解析域名流程
1. TGCP以APN和域名列表為關鍵字查詢緩存，如果存在且沒有過期，則直接把IP返回給用戶。如果指定強制解析域名列表，則跳過此步驟；
2. TGCP用預配置或緩存的IP向DNSvr發起查詢請求，如果成功返回結果，則執行步驟3，否則，重試IP列表中的其它IP，如果都失敗，則用域名訪問DNSvr。注意：如果是結果格式不正確，則使用上次的IP重試，不要更換IP重試[14,29]。
3. DNSvr比較客戶端IP列表和當前最新的IP列表的MD5，如果相等，則告訴客戶端不需要更新本地緩存。否則，TGCP把接入游戲服務器和DNSvr的IP列表寫入本地。注意：在訪問服務器時，這些IP的優先級要高於靜態配置在客戶端的IP。
· 客戶端使用域名訪問游戲服務器流程
1. 如果本地存在有效的IP（即存在對應APN的IP列表，且沒有失效），則使用IP訪問游戲服務器。
2. 否則，發起“客戶端批量解析域名流程”后，再訪問游戲服務器。
· 游戲服務器接入tconnd主動上報狀態流程（僅供參考）
1. Tconnd周期性向DNSvr上報心跳消息，其中包含本接入點是否可用的信息。
2. DNSvr在一定的時間內沒有收到心跳消息或者相應的接入點不可用，則把相應的IP和端口拉黑，黑掉的IP不在下發給客戶端。
注意：實際部署的時候，游戲接入的Tconnd要向多個DNSvr接入tconnd上報。
· 向客戶端主動push接入點列表的流程
1. 當TGCP連接到游戲服務器接入的Tconnd時，Tconnd要向DNSvr發起請求，以校驗當前接入IP的質量和時效性。如果IP列表發生變化，Tconnd要把最新的IP列表下發給客戶端緩存起來。
2. 當TGCP下次訪問游戲服務器時，則使用最新的IP列表。
· 客戶端訪問DNSvr失敗的流程
1. 如果訪問DNSvr失敗（包括IP+域名），如果配置了本地IP，則直接用IP訪問游戲服務器，否則用域名訪問。
優化傳輸層協議設計
在原有tconnd支持的可靠UDP的基礎之上，添加以下邏輯：
· 數據壓縮；
· 數據加密；
· 合並多個數據包；
· 支持流式數據傳輸，便於控制每個UDP包的大小，也便於數據加密和壓縮；
· 可選地支持[39]中的擁塞控制算法；
· 即使沒有接收到ACK包，也需要主動重試以發送的數據包；
參考文件
[1] 一秒鍾法則，http://www.infoq.com/cn/articles/1sec-rule-from-tencent；