前言

• 在13年11月中旬時(shí)，因?yàn)榛A(chǔ)組件組人手緊張，Leo安排我和春哥去廣州輪崗支援。剛到廣州的時(shí)候，Ray讓我和春哥對(duì)Line和WhatsApp的心跳機(jī)制進(jìn)行分析。我和春哥抓包測試了差不多兩個(gè)多禮拜，在我們基本上摸清了Line和WhatsApp的心跳機(jī)制后，Ray才告訴我們真正的任務(wù)——對(duì)微信的固定心跳進(jìn)行優(yōu)化，并告訴我們這不是一件容易的事情。于是我和春哥開始構(gòu)思第一個(gè)方案，我們開始想用統(tǒng)計(jì)的方法來解決問題，當(dāng)我們拿著第一個(gè)方案和Ray討論時(shí)，發(fā)現(xiàn)不能優(yōu)雅應(yīng)對(duì)Ray的所有提問：1、測試環(huán)境的準(zhǔn)確性，失敗到底是因?yàn)榫W(wǎng)絡(luò)的特性導(dǎo)致還是因?yàn)橛脩舢?dāng)前的環(huán)境變化導(dǎo)致的暫時(shí)失敗。2、臨界值界定，如果方案選中的心跳值是臨界值，我們?cè)撛趺崔k。Ray和組件組同事在網(wǎng)絡(luò)方面有極其豐富的經(jīng)驗(yàn)，雖然他沒有給我們指出明確的方向，但提出的問題幫助我們更快的補(bǔ)齊需要面對(duì)的核心問題。這兩個(gè)問題讓我和春哥意識(shí)到如果能很好的解決，就可以給出一個(gè)比較好的心跳方案。第一個(gè)問題我和春哥開始就意識(shí)到，第二個(gè)問題我們確實(shí)在一開始時(shí)疏忽了。但直接解決這兩個(gè)問題確實(shí)不容易，這著實(shí)讓我和春哥迷茫了幾天，有兩三天在紡園我都沒怎么睡著，因?yàn)橄氩坏礁玫姆椒?。直到有一天思路發(fā)生了一些轉(zhuǎn)變，既然最優(yōu)解比較復(fù)雜，為什么不繞過去，使用有損服務(wù)理念找次優(yōu)解呢。讓復(fù)雜的事情簡單化，好了，想到這里突然有一種撥開云霧的感覺。
• 思路對(duì)了，方案就可以做到簡單并且可靠，大家可以看到最終的方案是比較簡單的，并且效果還挺好的。在方案描述之前大概講一下減低問題復(fù)雜度的方法：
  a）延遲心跳測試法：這是測試結(jié)果準(zhǔn)確的前提保障，我們認(rèn)為長連接建立后連續(xù)三次成功的短心跳就可以很大程度的保證下一次心跳環(huán)境是正常的。
  b）成功一次認(rèn)定，失敗連續(xù)累積認(rèn)定：成功是絕對(duì)的，連續(xù)失敗多次才可能是失敗。
  c）臨界值避免：我們使用比計(jì)算出的心跳稍微小一點(diǎn)的值做為穩(wěn)定心跳避免臨界值。
  d）動(dòng)態(tài)調(diào)整：即使在一次完整的智能心跳計(jì)算過程中，我們沒有找到最好的值，我們還有機(jī)會(huì)來進(jìn)行校正。
• 當(dāng)我和春哥想出第二個(gè)簡單易行的方案后，我們心里就很有底了，去找Ray討論，Ray聽完后一次通過，然后Ray約了Harvey，給Harvey講完后，Harvey說聽起來可以，可以試試。
• 然后就開始動(dòng)手，分析競品加確定方案花了差不多兩個(gè)月。寫心跳的主要代碼，只花了一天時(shí)間，我記得那天是年會(huì)后的一天。回過頭來再看這個(gè)方案花費(fèi)的時(shí)間還是值得的，后來灰度的統(tǒng)計(jì)數(shù)據(jù)顯示，70%用戶都可以達(dá)到我們的心跳上限。
  搞完智能心跳后一段時(shí)間在廣州沒事干，我就跟Ray商量，Ray讓我去測試下WebView的性能瓶頸。然后我跟周斯基一起來做這件事，搞完了安卓客戶端WebView性能瓶頸測試后，因?yàn)閼言械睦掀乓粋€(gè)人在深圳，領(lǐng)導(dǎo)就安排我先回深圳了。春哥堅(jiān)守著把GCM部分完成后才回深圳。
• 等我們的心跳版本正式發(fā)布后，一年前我在公司km上分享了智能心跳方案，吸引不少做push的同事加入了討論，感覺這方面的交流還是很有必要的。

好了，廢話了很多，下面分享一下微信的智能心跳方案細(xì)節(jié)。

主要目標(biāo)

本方案的主要目標(biāo)是，在盡量不影響用戶收消息及時(shí)性的前提下，根據(jù)網(wǎng)絡(luò)類型自適應(yīng)的找出?；钚帕頣CP連接的盡可能大的心跳間隔，從而達(dá)到減少安卓微信因心跳引起的空中信道資源消耗，減少心跳Server的負(fù)載，以及減少部分因心跳引起的耗電。
主要方法是參考WhatsApp和Line中有價(jià)值的做法，結(jié)合影響TCP連接壽命的因素，實(shí)現(xiàn)Android微信后臺(tái)自適應(yīng)心跳算法，同時(shí)使用GCM作為輔助通道增加新消息通知的可靠性。

WhatsApp、Line、微信的Push策略分析

1. WhatsApp
   在不支持GCM的設(shè)備上，采用和微信類似的長連接+心跳策略，WIFI和手機(jī)網(wǎng)絡(luò)下的心跳間隔都為4分45秒，心跳5次后，主動(dòng)斷開連接再重連。
   在支持GCM的設(shè)備上，主要靠GCM來激活WhatsApp，WhatsApp啟動(dòng)后，會(huì)建立一個(gè)與服務(wù)器的長連接，直接通過此長連接發(fā)送Push消息，這個(gè)長連接10分鐘無消息就會(huì)主動(dòng)斷掉，且這十分鐘內(nèi)不做心跳，斷掉后WhatsApp客戶端和它的服務(wù)器不再有連接。當(dāng)有消息時(shí)候，服務(wù)器發(fā)現(xiàn)沒有長連接會(huì)發(fā)送GCM消息，手機(jī)收到GCM消息后，會(huì)重新建立長連接來收取消息，10分鐘無消息會(huì)再斷開，如此循環(huán)。
2. Line
   從測試中發(fā)現(xiàn)Line在國內(nèi)、臺(tái)灣、美國使用了不同的策略。
3. 美國（使用GCM）：
   啟動(dòng)時(shí)，會(huì)保持7分鐘心跳（CDMA2000網(wǎng)絡(luò)）維持長連接半小時(shí)，之后主動(dòng)斷開長連接。當(dāng)有消息時(shí)，服務(wù)器會(huì)發(fā)送GCM消息，Line客戶端接收到GCM消息后，重新建立長連接，并再次用心跳維持半個(gè)小時(shí)。
4. 國內(nèi)（不使用GCM）：
   在國內(nèi)，同樣帳號(hào)在相同網(wǎng)絡(luò)，不同的手機(jī)上測出了兩種策略：
   1. 長連接+心跳策略*（在Galaxy S3上使用），心跳間隔WIFI下是3分20秒，手機(jī)網(wǎng)絡(luò)是7分鐘。

   2. 輪詢策略（在紅米和Nexus S上使用），如圖2-1所示。與心跳策略的主要區(qū)別用紅色標(biāo)出，客戶端在長連接建立后也會(huì)定時(shí)發(fā)送請(qǐng)求，Server會(huì)回復(fù)并且同時(shí)關(guān)閉長連接?？蛻舳说却喸冮g隔T1后再次建立TCP連接。Line會(huì)根據(jù)手機(jī)的活躍狀態(tài)動(dòng)態(tài)調(diào)整T1，調(diào)整范圍是從最小1分到最大到2小時(shí)半。而長連接存活時(shí)間T2比較固定，在WIFI下4分鐘，手機(jī)網(wǎng)絡(luò)7分鐘。如果在T2時(shí)收到新消息會(huì)延長T2的時(shí)間。

      
      
      
      

      圖2-1 Line在國內(nèi)的輪詢策略

5. 臺(tái)灣（不使用GCM）：
   從IBG同事win和guang提供的測試數(shù)據(jù)中看到，臺(tái)灣使用的策略跟國內(nèi)的輪詢策略類似。
6. 微信
   微信沒有使用GCM，自己維護(hù)TCP長連接，使用固定心跳。

心跳典型值

Line、WhatsApp、微信Push策略的優(yōu)點(diǎn)

1. 微信：當(dāng)前心跳間隔比競品短，所以微信在新消息提醒上會(huì)最及時(shí)。
2. 使用GCM：Line和WhatsApp使用GCM策略的最大優(yōu)點(diǎn)就是省電，以及減輕系統(tǒng)負(fù)荷（減少后臺(tái)應(yīng)用數(shù)目）。
3. Line：Line的輪詢策略，優(yōu)點(diǎn)是當(dāng)Line處于活躍狀態(tài)時(shí)，及時(shí)收消息。當(dāng)Line處于不活躍狀態(tài)時(shí)，省電。

Line、WhatsApp微信Push策略的不足

1. 微信當(dāng)前心跳頻率相對(duì)競品較大，在耗電、耗流量，占用信令通道等方面有所影響。
2. Line的輪詢策略，導(dǎo)致的問題是消息可能會(huì)延遲接收，測試發(fā)現(xiàn)最大延遲間隔到2.5小時(shí)。
3. WhatsApp和Line使用Push拉起一個(gè)定時(shí)長連接策略，缺點(diǎn)是要依賴Google的Push服務(wù)，如果Google的Push服務(wù)不穩(wěn)定，消息也會(huì)延遲接收。
4. 在國內(nèi)的移動(dòng)和聯(lián)通2G網(wǎng)絡(luò)下，由于運(yùn)營商的策略，GCM長連接頻繁斷連，WhatsApp的Push消息很不及時(shí)，體驗(yàn)非常差。

GCM研究

1. GCM特點(diǎn)

• Android2.2以下的手機(jī)不支持GCM，2.2到3.0需要安裝Google Store并設(shè)置Google帳號(hào)，4.04及以上版本不需要設(shè)置帳號(hào)也能支持。
• GCM只傳遞數(shù)據(jù)（可以傳遞小于4kb的數(shù)據(jù)），對(duì)這些數(shù)據(jù)的處理可以全部由開發(fā)者控制。
• Android應(yīng)用不需要運(yùn)行就可以接收消息(通過Android廣播)。
• GCM不保證發(fā)送的消息的順序，也不保證消息一定能夠推送到手機(jī)。

2. GCM心跳策略以及存在的問題

• 用心跳?；铋L連接，心跳間隔為WIFI下15分鐘，數(shù)據(jù)網(wǎng)絡(luò)下28分鐘。
• Google可以改變所有Android設(shè)備的心跳間隔值（目前還未改變過）。
• GCM由于心跳間隔固定，并且較長，所以在NAT aging-time設(shè)置較小的網(wǎng)絡(luò)（如聯(lián)通2G，或有些WIFI環(huán)境下）會(huì)導(dǎo)致TCP長連接在下一次心跳前被網(wǎng)關(guān)釋放。造成Push延遲接收。

3. GCM的可用性及穩(wěn)定性
   目前測試發(fā)現(xiàn)GCM在國內(nèi)可用性不高，原因有：

• Android很多被手機(jī)廠商定制化，廠商可能會(huì)去掉GCM服務(wù)。
• Android2.2到3.0之間需要安裝Google Store并設(shè)置Google帳號(hào)。
• 由于國內(nèi)2G和移動(dòng)3G的NAT超時(shí)時(shí)間都小于GCM心跳時(shí)間(28分鐘)，TCP長連接必然無法?；?，每次都要等28分鐘心跳失敗重連后才能收到Push。
• 某些運(yùn)營商可能限制了5228端口，移動(dòng)3G/2G下，發(fā)現(xiàn)幾乎無法連接上GCM服務(wù)器，也就無法獲得GCM通知，WhatsApp放后臺(tái)10分鐘后，經(jīng)常很長時(shí)間都收不到Push消息。
  在美國3G網(wǎng)絡(luò)下抓包的24小時(shí)，GCM的連接極其穩(wěn)定，24小時(shí)內(nèi)GCM長連接未曾斷過，在臺(tái)灣3G網(wǎng)絡(luò)下抓包14個(gè)小時(shí)，GCM連接也只斷過一次。WhatsApp用戶在此類地區(qū)網(wǎng)絡(luò)下客戶端可以獲得很及時(shí)的Push通知。
  在中國電信3G下抓包，大部分時(shí)間GCM連接都比較穩(wěn)定，只會(huì)因?yàn)榕紶柕腄HCP造成斷連現(xiàn)象，由于頻率很低(平均數(shù)小時(shí)才發(fā)生一次)，對(duì)Push體驗(yàn)的影響不大。

4. GCM Server類型
   GCM提供兩種Server模型：

• HTTP Server : 使用同步接口發(fā)送HTTP請(qǐng)求，一次請(qǐng)求可以發(fā)給最多1000個(gè)設(shè)備。
• XMPP Server :使用異步接口發(fā)送請(qǐng)求，只支持對(duì)單個(gè)設(shè)備（或同一個(gè)用戶的多個(gè)關(guān)聯(lián)設(shè)備發(fā)送），發(fā)送請(qǐng)求并發(fā)數(shù)須小于1000，支持設(shè)備到云端Server發(fā)送數(shù)據(jù)。需要Google將我們的發(fā)送Server加入白名單。

微信可能的改進(jìn)點(diǎn)探討

微信Push的優(yōu)化主要有幾個(gè)優(yōu)化點(diǎn)：

• 公共Push通道
• 使用GCM Push作為輔助通道
• 自適應(yīng)心跳間隔優(yōu)化

1. 公共Push通道
   由于GCM在國內(nèi)的可靠性很低，現(xiàn)在國內(nèi)Android上的Push基本上是各自為政，很多軟件都自己實(shí)現(xiàn)Push。導(dǎo)致手機(jī)被經(jīng)常性的喚醒，耗電耗流量嚴(yán)重。
   市面上已經(jīng)有很多第三方的公共推送服務(wù)，大家可以選擇一個(gè)適合自己應(yīng)用的推送服務(wù)。騰訊也有信鴿和維納斯組件，大家在選擇方案的時(shí)候可以對(duì)比下。
   最終因?yàn)槲覀儑鴥?nèi)外使用一套方案，并且是輔助公道，所以我們選擇使用GCM。
2. 使用GCM Push作為輔助通道
   * 當(dāng)前使用GCM的成本不大，可以使用GCM作為輔助通道來增加新消息的及時(shí)性。
   * 使用GCM作為輔助通道，在支持GCM的設(shè)備上微信上傳自己的注冊(cè)GCM ID給微信Server。
   * 微信Server在發(fā)現(xiàn)長連接失效的情況下，可以使用GCM 作為輔助通道通知客戶端有新消息，客戶端收到push通知后做一次sync。
   * 只利用GCM來激活微信，不傳遞消息的具體數(shù)據(jù)，要控制給同一設(shè)備發(fā)送GCM通知的時(shí)間間隔(如五分鐘)。
3. 自適應(yīng)心跳間隔優(yōu)化
   1. 影響TCP連接壽命的因素
      在Android下，不管是GCM，還是微信，都是通過TCP長連接來進(jìn)行Push消息的，TCP長連接存活，消息Push就及時(shí)，所以要對(duì)影響TCP連接壽命的因素進(jìn)行研究。
      • NAT超時(shí)
        大部分移動(dòng)無線網(wǎng)絡(luò)運(yùn)營商都在鏈路一段時(shí)間沒有數(shù)據(jù)通訊時(shí)，會(huì)淘汰 NAT 表中的對(duì)應(yīng)項(xiàng)，造成鏈路中斷（NAT超時(shí)的更多描述見附錄6.1）。NAT超時(shí)是影響TCP連接壽命的一個(gè)重要因素(尤其是國內(nèi))，所以客戶端自動(dòng)測算NAT超時(shí)時(shí)間，來動(dòng)態(tài)調(diào)整心跳間隔，是一個(gè)重要的優(yōu)化點(diǎn)。
      • DHCP的租期（lease time）
        目前測試發(fā)現(xiàn)安卓系統(tǒng)對(duì)DHCP的處理有Bug，DHCP租期到了不會(huì)主動(dòng)續(xù)約并且會(huì)繼續(xù)使用過期IP，這個(gè)問題會(huì)造成TCP長連接偶然的斷連。（租期問題的具體描述見附錄6.2）。
      • 網(wǎng)絡(luò)狀態(tài)變化
        手機(jī)網(wǎng)絡(luò)和WIFI網(wǎng)絡(luò)切換、網(wǎng)絡(luò)斷開和連上等情況有網(wǎng)絡(luò)狀態(tài)的變化，也會(huì)使長連接變?yōu)闊o效連接，需要監(jiān)聽響應(yīng)的網(wǎng)絡(luò)狀態(tài)變化事件，重新建立Push長連接。
   2. 心跳范圍選擇
      • 前后臺(tái)區(qū)分處理：
        為了保證微信收消息及時(shí)性的體驗(yàn)，當(dāng)微信處于前臺(tái)活躍狀態(tài)時(shí)，使用固定心跳。
        微信進(jìn)入后臺(tái)（或者前臺(tái)關(guān)屏）時(shí)，先用幾次最小心跳維持長鏈接。然后進(jìn)入后臺(tái)自適應(yīng)心跳計(jì)算。這樣做的目的是盡量選擇用戶不活躍的時(shí)間段，來減少心跳計(jì)算可能產(chǎn)生的消息不及時(shí)收取影響。
      • 后臺(tái)自適應(yīng)心跳選擇區(qū)間：
        可根據(jù)自身產(chǎn)品的特點(diǎn)選擇合適的心跳范圍。

   3. 狀態(tài)轉(zhuǎn)換圖

      
      
   4. 自適應(yīng)心跳算法描述
      • 按網(wǎng)絡(luò)類型區(qū)分計(jì)算：
        因?yàn)槊總€(gè)網(wǎng)絡(luò)的NAT時(shí)間可能不一致。所以需要區(qū)分計(jì)算，數(shù)據(jù)網(wǎng)絡(luò)按subType做關(guān)鍵字，WIFI按WIFI名做關(guān)鍵字。
        對(duì)穩(wěn)定的網(wǎng)絡(luò)，因?yàn)镹AT老化時(shí)間的存在，在自適應(yīng)計(jì)算態(tài)的時(shí)候，暫設(shè)計(jì)以下步驟在當(dāng)前心跳區(qū)間逼近出最大可用的心跳。
      • 變量說明：
        [MinHeart，MaxHeart]——心跳可選區(qū)間。
        successHeart——當(dāng)前成功心跳，初始為MinHeart
        curHeart——當(dāng)前心跳初始值為successHeart
        heartStep——心跳增加步長
        successStep——穩(wěn)定期后的探測步長

      • 最大值探測步驟：

        
        
        
        

        圖4-1 自適應(yīng)心跳計(jì)算流程
        自適應(yīng)心跳計(jì)算流程如圖4-1所示，經(jīng)過該流程，會(huì)找到必然使心跳失敗的curHeart（或者M(jìn)axHeart），為了保險(xiǎn)起見，我們選擇比前一個(gè)成功值稍微小一點(diǎn)的值作為后臺(tái)穩(wěn)定期的心跳間隔。
        影響手機(jī)網(wǎng)絡(luò)測試的因素太多，為了盡量保證測試結(jié)果的可靠性，我們使用延遲心跳測試法。在我們重新建立TCP連接后，先使用 短心跳連續(xù)成功三次，我們才認(rèn)為網(wǎng)絡(luò)相對(duì)穩(wěn)定，可以使用curHeart進(jìn)行一次心跳測試。圖4-2顯示了一次有效心跳測試過程。圖4-3顯示了在沒有達(dá)到穩(wěn)定網(wǎng)絡(luò)環(huán)境時(shí)，我們會(huì)一直使用固定短心跳直到滿足三次連續(xù)短心跳成功。
        使用延遲心跳測試的好處是，可以剔除偶然失敗，和網(wǎng)絡(luò)變化較大的情況（如地鐵），使測試結(jié)果相對(duì)可靠（五次延遲測試確定結(jié)論）。同時(shí)在網(wǎng)絡(luò)波動(dòng)較大的情況，使用短心跳，保證收取消息相對(duì)及時(shí)。

      • 運(yùn)行時(shí)的動(dòng)態(tài)調(diào)整策略(已經(jīng)按測算心跳穩(wěn)定值后)
        NAT超時(shí)值算出來后，在維持心跳的過程中的策略

      • 無網(wǎng)絡(luò)、網(wǎng)絡(luò)時(shí)好時(shí)壞、偶然失敗、NAT超時(shí)變?。涸诤笈_(tái)穩(wěn)定期發(fā)生心跳發(fā)生失敗后，我們使用延遲心跳測試法測試五次。如果有一次成功，則保持當(dāng)前心跳值不變；如果五次測試全失敗，重新計(jì)算合理心跳值。該過程如圖4-4所示，有一點(diǎn)需要注意，每個(gè)新建的長連接需要先用短心跳成功維持3次后才用successHeart進(jìn)行心跳。

        
        
        
        

        圖4-2 后臺(tái)穩(wěn)定態(tài)動(dòng)態(tài)調(diào)整心跳策略

      • NAT超時(shí)變大：以周為周期，每周三將后臺(tái)穩(wěn)定態(tài)調(diào)至自適應(yīng)計(jì)算態(tài)，使用心跳延遲法往后探測心跳間隔。
      • successHeart是NAT超時(shí)臨界值：因?yàn)槲覀儸F(xiàn)在選擇的是一個(gè)比successHeart稍小的值作為穩(wěn)定值，所以在計(jì)算過程中可以避開臨界值。當(dāng)運(yùn)營商在我們后臺(tái)穩(wěn)定期將NAT超時(shí)調(diào)整為我們當(dāng)前計(jì)算值，那么由于我們每周會(huì)去向下探索，所以下一周探測時(shí)也可以及時(shí)調(diào)整正確。
   5. 冗余Sync和心跳
      在用戶的一些主動(dòng)操作以及聯(lián)網(wǎng)狀態(tài)改變時(shí)，增加冗余Sync和心跳，確保及時(shí)收到消息。
      • 當(dāng)用戶點(diǎn)亮屏幕的時(shí)候，做一次心跳。
      • 當(dāng)微信切換到前臺(tái)時(shí)，做一次Sync。
      • 聯(lián)網(wǎng)時(shí)重建信令TCP，做一次Sync

可能存在的風(fēng)險(xiǎn)及預(yù)防措施

1. DHCP租期因素

• 問題：根據(jù)目前的測試結(jié)果顯示，安卓不續(xù)約到期的IP Bug，會(huì)導(dǎo)致TCP連接在不確定的時(shí)間點(diǎn)失效，從而會(huì)導(dǎo)致一次心跳失敗。
• 預(yù)防：統(tǒng)計(jì)后臺(tái)穩(wěn)定期的心跳成功率，上報(bào)給后臺(tái)。后臺(tái)可以按地區(qū)分網(wǎng)絡(luò)監(jiān)控這個(gè)指標(biāo)的波動(dòng)，并且后臺(tái)可以根據(jù)不同的波動(dòng)，動(dòng)態(tài)調(diào)整某區(qū)域特定網(wǎng)絡(luò)下可選的心跳區(qū)間。

2. 其他影響TCP壽命的因素

• 是否有遺漏的因素？歡迎各位聯(lián)系我反饋。

附錄

1. 附錄A——NAT超時(shí)介紹

• 因?yàn)?IP v4 的 IP 量有限，運(yùn)營商分配給手機(jī)終端的 IP 是運(yùn)營商內(nèi)網(wǎng)的 IP，手機(jī)要連接Internet，就需要通過運(yùn)營商的網(wǎng)關(guān)做一個(gè)網(wǎng)絡(luò)地址轉(zhuǎn)換(Network Address Translation，NAT)。簡單的說運(yùn)營商的網(wǎng)關(guān)需要維護(hù)一個(gè)外網(wǎng) IP、端口到內(nèi)網(wǎng) IP、端口的對(duì)應(yīng)關(guān)系，以確保內(nèi)網(wǎng)的手機(jī)可以跟 Internet 的服務(wù)器通訊。

  
  
  
  

  NAT 功能由圖中的 GGSN 模塊實(shí)現(xiàn)

• 大部分移動(dòng)無線網(wǎng)絡(luò)運(yùn)營商都在鏈路一段時(shí)間沒有數(shù)據(jù)通訊時(shí)，會(huì)淘汰 NAT 表中的對(duì)應(yīng)項(xiàng)，造成鏈路中斷。下表列出一些已測試過的網(wǎng)絡(luò)的NAT超時(shí)時(shí)間(更多數(shù)據(jù)由于測試條件所限沒有測到)：

長連接心跳間隔必須要小于NAT超時(shí)時(shí)間(aging-time)，如果超過aging-time不做心跳，TCP長連接鏈路就會(huì)中斷，Server就無法發(fā)送Push給手機(jī)，只能等到客戶端下次心跳失敗后，重建連接才能取到消息。

2. 附錄B——安卓DHCP的租期（lease time）問題
目前測試發(fā)現(xiàn)安卓系統(tǒng)對(duì)DHCP的處理有Bug：

• DHCP租期到了不會(huì)主動(dòng)續(xù)約并且會(huì)繼續(xù)使用過期IP，詳細(xì)描述見傳送門。這個(gè)問題導(dǎo)致的問題表象是，在超過租期的某個(gè)時(shí)間點(diǎn)（沒有規(guī)律）會(huì)導(dǎo)致IP過期，老的TCP連接不能正常收發(fā)數(shù)據(jù)。并且系統(tǒng)沒有網(wǎng)絡(luò)變化事件，只有等應(yīng)用判斷主動(dòng)建立新的TCP連接才引起安卓設(shè)備重新向DHCP Server申請(qǐng)IP租用。
• 未到租期的一半時(shí)間，安卓設(shè)備重新向DHCP Server申請(qǐng)IP租用。從目前測試結(jié)果來看，這種現(xiàn)象恢復(fù)的比較快。
• 移動(dòng)2G/3G，聯(lián)通2G沒有抓到DHCP。
• 美國3G下抓取24小時(shí)，沒有抓到DHCP。