推送技術原理：HTTP長連接

移動互聯網應用現狀

因為手機平台本身、電量、網絡流量的限製，移動互聯網應用在設計上跟傳統 PC 上的應用很大不一樣，需要根據手機本身的特點，儘量的節省電量和流量，同時又要儘可能的保證數據能及時到達客戶端。

為了解決數據同步的問題，在手機平台上，常用的方法有2種。一種是定時去服務器上查詢數據，也叫Polling，還有一種手機跟服務器之間維護一個 TCP 長連接，當服務器有數據時，實時推送到客戶端，也就是我們說的 Push。

從耗費的電量、流量和數據送達的及時性來說，Push 都會有明顯的優勢，但 Push 的實現和維護成本相對較高。在移動無線網絡下維護長連接，相對也有一些技術上的難度。本文試圖給大家介紹一下我們極光推送在 Android 平台上是如何維護長連接。

移動無線網絡的特點

因為 IP v4 的 IP 量有限，運營商分配給手機終端的 IP 是運營商內網的 IP，手機要連接 Internet，就需要通過運營商的網關做一個網絡地址轉換（Network Address Translation，NAT）。簡單的說運營商的網關需要維護一個外網 IP、端口到內網 IP、端口的對應關係，以確保內網的手機可以跟 Internet 的服務器通訊。

圖片源自 cisco.com.

NAT 功能由圖中的 GGSN 模塊實現。

大部分移動無線網絡運營商都在鏈路一段時間冇有數據通訊時，會淘汰 NAT 表中的對應項，造成鏈路中斷。

Android 平台上長連接的實現

為了不讓 NAT 表失效，我們需要定時的發心跳，以刷新 NAT 表項，避免被淘汰。

Android 上定時運行任務常用的方法有2種，一種方法用 Timer，另一種是AlarmManager。

Timer

Android 的 Timer 類可以用來計劃需要循環執行的任務，Timer 的問題是它需要用 WakeLock 讓 CPU 保持喚醒狀態，這樣會大量消耗手機電量，大大減短手機待機時間。這種方式不能滿足我們的需求。

AlarmManager

AlarmManager 是 Android 係統封裝的用於管理 RTC 的模塊，RTC (Real Time Clock) 是一個獨立的硬件時鐘，可以在 CPU 休眠時正常運行，在預設的時間到達時，通過中斷喚醒 CPU。

這意味著，如果我們用 AlarmManager 來定時執行任務，CPU 可以正常的休眠，隻有在需要運行任務時醒來一段很短的時間。極光推送的 Android SDK 就是基於這種技術實現的。

服務器設計

當有大量的手機終端需要與服務器維持長連接時，對服務器的設計會是一個很大的挑戰。

假設一台服務器維護10萬個長連接，當有1000萬用戶量時，需要有多達100台的服務器來維護這些用戶的長連接，這裡還不算用於做備份的服務器，這將會是一個巨大的成本問題。那就需要我們儘可能提高單台服務器接入用戶的量，也就是業界已經討論很久了的 C10K 問題。

C2000K

針對這個問題，我們專門成立了一個項目，命名為C2000K，顧名思義，我們的目標是單機維持200萬個長連接。最終我們采用了多消息循環、異步非阻塞的模型，在一台雙核、24G內存的服務器上，實現峰值維持超過300萬個長連接。