DDPush 任意门消息推送 开源免费实时信息推送服务器
在好幾年前，就已經注意到DDPush這款推送中間件，不過看近來發展也還是停留在V1.0的基礎上，不免惋惜！恰好最近正在深入研究Java Socket通信編程，也順帶再看看這款應用。官網地址：http://www.ddpush.net/
目錄
DDPush 任意門 消息推送
DDPush是什么
DDPush可以做什么
移動互聯網消息推送
IM實時消息系統核心組件
物聯網設備控制與交互
DDPush消息推送有什么優勢
開源、免費
容量高，速度快，要求低
終端設備流量少，省電
DDPush消息推送基于什么技術
DDPush消息推送 概述
IM(Instant Messaging)即時通訊系統
DDPush消息推送的思路
DDPush消息推送的策略
通用終端的支持
使用DDPush消息推送的方式
事情其實很簡單
DDPush消息推送 快速開始
第一步：下載DDPush消息推送服務器與Android安卓demo app安裝文件
第二步：運行DDPush消息推送服務器
第三步：手機安裝與運行Android安卓demo app
DDPush消息推送 一分鐘集成
第一步，繼承并實現客戶端抽象基類
繼承UDP或者TCP客戶端抽象基類
實現三個抽象函數
public boolean hasNetworkConnection()
public void trySystemSleep()
public void onPushMessage(Message message)
第二步，運行客戶端
第三步，應用服務端推送信息
Android客戶端
安卓demo apk耗電分析
48小時在線測試結果（UDP，TCP，微信）
DDPush Android UDP Demo 耗電、喚醒次數、喚醒時間詳情
DDPush Android TCP Demo 耗電、喚醒次數、喚醒時間詳情
微信 耗電、喚醒次數、喚醒時間詳情
360省電王評價
耗電小結
DDPush消息推送 網絡流量分析
終端上載流量
終端下載流量
服務器流量
小結
UDP對TCP
互聯網、移動互聯網網絡環境
智能終端電池續航能力，系統休眠
IPv4資源、端口資源
端口映射老化時間
服務端承載能力
高級應用網絡通訊要求
結論
DDPush 任意門推送 1 下載
系統要求
最新版本1.0.03 (2015-01-02發布)
二進制發布
源碼發布
歷史版本1.0.02 (2014-08-29發布, 2014-11-21更新android示例工程)
二進制發布
源碼發布
歷史版本1.0.01 (2014-08-01)
二進制發布
源碼發布
?
DDPush 任意門 消息推送
DDPush是什么
DDPush (Dimension Door Push)，任意門消息推送，是一款開源免費的單機千萬級實時消息推送服務器，使用Java語言開發，具有簡單、穩定、高性能、高容量等特點，適用于互聯網、移動互聯網、物聯網、Android、智能設備、硬件設備等各種環境。
DDPush可以做什么
移動互聯網消息推送
DDPush可實時推送信息到各種Android、Windows等手機和平板（即“透傳”），并支持雙向通信。DDPush支持自定義信息，信息的格式和內容可由開發者自行定義
IM實時消息系統核心組件
通過集成DDPush消息推送，可以開發各種IM實時消息系統，例如：聊天系統、社交App等。
物聯網設備控制與交互
DDPush消息推送可作為一個實時控制中心，控制物聯網中的各種硬件設備（硬件需支持網絡通信），與之雙向通信。
DDPush消息推送有什么優勢
開源、免費
DDPush采用Apache License Version 2.0開源協議，可放心使用，只要您保留其許可證信息。
容量高，速度快，要求低
DDPush在線部分主要采用UDP協議（同時支持TCP協議），支撐1000萬終端在線的服務器，最少只需要4G內存（不考慮變長自定義信息的情況下），單個主流雙核CPU使用率低于75%。即：一部普通PC臺式機的配置。
DDPush推送部分采取TCP協議和Java NIO非阻塞網絡技術，普通PC可支持至少數千臺應用服務器同時長連接推送信息到終端，每秒推送信息的速度在1萬條以上
終端設備流量少，省電
采用DDPush，智能手機等終端設備在線一個月（空載的情況下），只需幾百KB的上載流量，下載流量甚至可調節到為零。
DDPush提供的Android手機App示例demo，連續在線48小時耗電少于0.5 mAh（使用2G網絡GPRS連接，經360省電王測試??>>>詳情）
DDPush消息推送基于什么技術
DDPush基于自有的二進制網絡傳輸協議（基于TCP和UDP），因此客戶端可以支持各種類型的終端設備，包括各種智能手機、平板、智能設備、物聯網硬件，和各種終端操作系統（包括: Android, Windows, Linux等）。
DDPush使用Java語言開發，因此服務端可運行在各種操作系統和服務器上。
DDPush消息推送 概述
IM(Instant Messaging)即時通訊系統
IM(Instant Messaging)即時通訊系統，從1996年ICQ的出現，到國際巨頭割據的今天，已經深刻地影響了互聯網，甚至人類社會的變化。從移動互聯網時代開始，即時通訊系統更是加劇演變進化，除了iOS和Android提供全世界范圍的Push Notification Service，還形成了各種開放的云推送平臺與服務，成為巨頭廝殺圈地的戰場。在可預見的物聯網前景下，相信IM即時通訊系統將會進一步進化，成為物聯智能時代的IT基礎設施之一。
然而，到目前為止，即時通訊（包括其衍生的云推送平臺與服務）一直被賦予高難度、高投入的標簽，似乎成了強者的專屬，普通開發者和中小型IT公司的業務大都依賴現有的第三方產品或服務，先不說可能面臨高額的收費，從信息安全角度來說，把自己的客戶與業務建立在第三方服務的基礎上，也讓很多人心存顧慮。雖然業界也有各種較流行的開源實現，但其普及程度還比較低。另外，由于目前的開源實現，普遍基于較高級的應用層面（例如：XMPP），所以其實現較為復雜，普通技術人員不容易掌控和二次開發，并且越高級的應用，其通用性往往越低。
DDPush消息推送的思路
DDPush的出發點，是繞過已有的各種門檻和障礙，尋求另外一種簡單有效的方法，來嘗試折衷地實現移動互聯網、物聯網時代IM系統需求。DDPush的目的是幫助中小型應用和個人開發者，較容易地跨過IM系統的基本門檻，而不是挑戰和取代已有的業界標準和產品。DDPush，任意門推送服務器，只是另外一道門，也許能打開另外一個世界，但絕不是包含整個世界。
DDPush的思路，有點類似MQTT，重新定義了一套較簡單和低級的網絡通訊協議，來達到更小的流量、更高的效率、以及更好的通用性。而DDPush和MQTT的區別在于，DDPush更為簡單，放棄了QoS，只實現極為簡單的實時通訊需求，剩下的更多是交由應用層去控制。另外，DDPush實現并主推UDP方式，大為降低網絡通信成本和服務器承載成本，提高了容量和效率。
這個特點是DDPush與其他方案一個區別所在。DDPush認為可靠性、完整性，更多是應該由應用層去控制的，而不是網絡通信層。理由是在移動互聯網、無線物聯網的環境下，網絡本身就是非常不穩定的因素（至少在很長一段時間內都會是這樣），因此不能寄望其能完美地工作，需要應用層的保證。例如：當收到一封郵件的時候，應該是嘗試發出一個通知告訴郵箱所有者有新郵件達到，即使通知失敗了，也不影響直接登錄郵箱查看新郵件，同時也應保留再次通知的可能。設想一下，如果僅僅因為實時通知失敗了，就連新郵件都丟失的話，豈不是本末倒置？
DDPush消息推送的策略
因此，DDPush采取的策略是：不努力保證單次數據包的實時和必然到達，改為可能的多次通知直至終端主動確認，來提高“通知”的最終成功率。換句話說，DDPush犧牲部分的實時性，來換取更高的成功率，信息可能即時達到，也可能十幾分鐘后到達，甚至幾天后到達（如果終端幾天后上線的話），但一般總會到達。（當然，需要實時的時候還是可以實現的，因為DDPush的行為是可配置的，也支持TCP模式）
正因為如此，DDPush主推UDP協議，DDPush的通信協議格式就類似UDP協議，基于包的形式而不是流的形式，不依賴包的順序。不過，DDPush同時也用TCP實現了相同的協議，有需要的情況下只要打開TCP模式即可。這里需要聲明的是：UDP模式的服務器容量，是TCP的幾十倍甚至上百倍，請使用者自行權衡。
注：在設計DDPush的早期，作者也曾考慮引入部分QoS的功能，例如重發次數、重發策略等。但最后作者決定放棄大部分QoS功能，把這些問題留給應用層去控制，將更精確更實用，也能大大簡化DDPush的復雜度和提高容量與效率。畢竟，業務邏輯由應用層去控制，在線終端的數量由DDPush去保證，各司其職，應該是一種更恰當的方式。就好像郵件是否已讀，應該由郵件系統控制，而不是新郵件提醒功能去完成。
不過，DDPush并不是完全沒有QoS功能，只是采取了更簡單的，和MQTT三種QoS級別都不一樣的QoS功能：等待終端確認；外加應用層、終端實現的個性化配合手段，達到更大的自由度。
通用終端的支持
DDPush采取UDP協議的另外一個好處，是對終端設備的通用支持。對于常見操作系統（Windows、Android等）來說，網絡操作的支持完全不是問題，只是程序通用性的問題。而對于很多嵌入式Linux系統、普通硬件設備來說，要實現完整的網絡通信協議，特別是TCP這種高級應用層協議，是非常困難甚至有時候是不太可能的任務（與芯片、板卡的能力和成本有關），所以是本質的通用性問題。而對于UDP，普通硬件設備和嵌入式系統則能較好地支持，因為其復雜度、難度都低很多，各方面要求也相應降低。DDPush采用二進制網絡通信協議，而不是文本協議，這也與很多硬件設備有更多的契合點。這些特點和MQTT很類似，不過目前MQTT協議是基于TCP協議而不是UDP。
使用DDPush消息推送的方式
對于XMPP等其他方式，很多開發者習慣直接使用其來傳遞信息內容。而DDPush提倡傳遞“控制信息”，類似FTP的工作模式。即：通過DDPush來傳遞命令和控制信息，真正的內容信息建議終端使用常見的HTTP GET或者新建TCP連接的方式，連接到應用服務器（而不是DDPush服務器）獲取。這里還會涉及安全驗證、內容有效性等方面的需求，而DDPush不致力于解決類似的問題（MQTT則包括安全驗證等規則）。DDPush專注在“通知的下發和確認”方面。
事情其實很簡單
DDPush不管是協議本身，還是代碼實現，其實都是很簡單的。因此，開發者很容易進行改造和二次開發，或者按照自己的需要重新改寫。整個DDPush服務器的Java代碼量很少，目前只有200K，編譯后的二進制文件不到100k，對于大部分開發者來說要讀懂，相信并不困難。這也是DDPush希望達到的效果，讓即時通訊、推送成為家常菜，而不是滿漢全席。
DDPush消息推送 快速開始
歡迎來到DDPush快速開始，本頁面將引導您快速體驗DDPush的基本功能，請按照以下三個步驟操作：
第一步：下載DDPush消息推送服務器與Android安卓demo app安裝文件
第二步：運行DDPush消息推送服務器
第三步：安裝與運行Android安卓demo app
第一步：下載DDPush消息推送服務器與Android安卓demo app安裝文件
請點擊以下鏈接下載文件：
DDPush服務器
安卓客戶端app示例（UDP）
安卓客戶端app示例（TCP）
第二步：運行DDPush消息推送服務器
解壓DDPush消息推送服務器壓縮文件到您電腦的某個目錄（路徑不要包含中文或空格），您將看到2個目錄與4個文件。
目錄：lib, logs
文件：start.bat, start.sh, console.bat, console.sh
如果您在使用Windows操作系統，請執行start.bat文件（注：勿雙擊bat文件，請于CMD窗口中運行）；如果您使用的是Linux系統，請執行start.sh文件。這里使用Windows系統演示，執行start.bat文件。如果您看到類似以下的信息，說明DDPush服務器已經運行：
您也可以檢查logs目錄下是否有ddpush.out日志文件輸出來判斷DDPush是否在運行。此外，您還可檢查DDPush的默認端口是否正在監聽。
如果您要停止DDPush消息推送服務器，請新打開一個命令行窗口，執行命令："console.bat stop"，DDPush服務器將會停止
Linux系統下的操作與Windows類似，差別在于Linux系統下執行的是start.sh和console.sh腳本。
注意：如果您通過ftp單獨上傳sh腳本文件到Linux服務器，注意不要破壞文件格式，如出現無法運行sh腳本的情況，請嘗試使用dos2unix命令轉換文本格式，并確保sh文件權限為可執行
第三步：手機安裝與運行Android安卓demo app
請使用Android手機分別安裝第一步下載的另外兩個apk文件。您也可以使用兩臺手機分別安裝，以達到更現實的體驗效果
安裝完畢后，打開兩個app，配置服務器IP為您在第二步中運行DDPush消息推送服務器的機器IP，見下圖
?
按照上圖的示例，兩個app分別設置不同的用戶名，并把目標用戶名設置為對方，以測試互相推送信息。這里是user01和user02，各端口號采用默認值。
注意正確設置服務器IP為第二步中DDPush消息推送服務器運行機器的IP，并且手機能正常訪問網絡與該IP。
分別點擊"開始測試"按鈕后，即可通過下面的按鈕來互相發送推送信息，見下圖收到的實時推送信息示例。（若延時數分鐘后才收到推送信息亦屬正常情況，請檢查網絡是否暢通，服務器IP地址是否可達）
當然，您也可以只安裝其中一個app demo，然后自己給自己發送推送信息，只要把用戶名、目標用戶名設置為同一個字符串即可。
>>> demo app耗電嗎？
DDPush消息推送 一分鐘集成
集成使用DDPush消息推送服務器，只需要簡單繼承DDPush提供的Java客戶端基類，并實現三個簡單的函數，即可使用DDPush服務，不需要了解客戶端與服務端網絡協議交互的細節。
DDPush提供的客戶端基類，已經滿足大部分的應用場景。此外，DDPush提供的Android App客戶端示例，還實現了Android開發中的后臺長時間運行的service服務，您可以直接使用。
若DDPush提供的現成基類和示例無法滿足您的應用場景，你可以改寫或者重寫DDPush客戶端。這并不會很困難，但需要您了解DDPush自身的網絡協議。當然，這個也不會是很困難的事情。
馬上開始！
第一步，繼承并實現客戶端抽象基類
繼承UDP或者TCP客戶端抽象基類
UDP：public class MyUdpClient extends org.ddpush.im.v1.client.appuser.UDPClientBase
TCP：public class MyTcpClient extends org.ddpush.im.v1.client.appuser.TCPClientBase
實現三個抽象函數
public boolean hasNetworkConnection(){}
public void onPushMessage(org.ddpush.im.v1.client.appuser.Message msg){}
public void trySystemSleep(){}
public boolean hasNetworkConnection()
該函數主要用于智能終端，判斷當前是否有可用的網絡連接，以達到省電的目的（若無網絡連接則不嘗試網絡操作）。不同的終端檢測網絡情況的方式會不一樣，所以DDPush客戶端示例要求您的實現自行判斷網絡連接是否可用。如果是PC版軟件不需考慮省電，可簡單返回true，哪怕實際上沒有可用的網絡連接。
public void trySystemSleep()
該函數同樣主要用于智能終端，在客戶端不需要發送心跳包，并且服務端無推送信息的時候，嘗試系統休眠，達到省電的目的。PC版軟件可以直接將該函數留空，不做任何處理。Android則可能要考慮釋放WakeLock以進入系統休眠狀態。
public void onPushMessage(Message message)
該函數是客戶端處理推送信息的業務入口函數。當客戶端收到服務端的推送命令，將自動發送確認包，然后調用該函數。所以該函數內或其調用的其他函數，應該確保信息的正確處理，因為正常情況下該推送信息已經確認，極可能不會再次收到通知。
DDPush現成的客戶端基類，會在該函數返回后，再調用trySystemSleep()函數。因此該函數內不用考慮保有WakeLock等防止系統休眠的操作。
第二步，運行客戶端
UDP客戶端：
MyUdpClient myUdpClient = new MyUdpClient(uuid,1,"192.168.1.100",9966);
myUdpClient.setHeartbeatInterval(50);//50秒一次心跳，可由您動態調節
myUdpClient.start();
TCP客戶端：
MyTcpClient myTcpClient = new MyTcpClient(uuid, 1, "192.168.1.100", 9966, 5);
myTcpClient.setHeartbeatInterval(50);//50秒一次心跳
myTcpClient.start();
若網絡發生變化，客戶端會自行處理。
程序退出關閉客戶端：myUdpClient.stop()或者myTcpClient.stop()。
第三步，應用服務端推送信息
Pusher pusher = new Pusher(serverIp,port, timeoutMills);
boolean result = pusher.push0x20Message(uuid,message);
注：這個步驟一般應該是應用服務器向DDPush消息推送服務器發起，但在DDPush Android demo工程里面，為了方便直接在客戶端調用，只是為了演示如何編程。
Android客戶端
在Android App開發中，會涉及到其他特有的因素，例如service的持續運行、WakeLock的控制等，并非簡單繼承基類實現以上三個函數就能正常工作。請參考DDPush提供的Android客戶端示例App
?
安卓demo apk耗電分析
目前全世界所有智能手機的電池續航能力都是瓶頸，因此app耗電的大小是app開發者非常關注的一個點，特別是長期聯網運行的app。
DDPush提供的Android安卓App客戶端demo，一方面展示DDPush的使用，另外一個方面也提供了現成的，集成了在線服務的Android開發示例。該示例通過了一系列的長期運行測試，確保在省電省流量方面達到較好的水平。
48小時在線測試結果（UDP，TCP，微信）
以下內容展示了Android demo app在GPRS連接（2G網絡）下連續空載運行48小時后的耗電、喚醒時間統計，并與微信作比較。（使用WakeLock Detector和360省電王測試）
?
以上圖片顯示，GPRS連接（2G網絡）下連續運行48小時，DDPush的UDP demo、TCP demo和微信的喚醒次數、總喚醒時間基本持平，在20至25分鐘左右。
DDPush Android UDP Demo 耗電、喚醒次數、喚醒時間詳情
如圖所示，48小時內UDP Demo喚醒605次，喚醒時間21分16秒，耗電0.4 mAh
DDPush Android TCP Demo 耗電、喚醒次數、喚醒時間詳情
如圖所示，48小時內TCP Demo喚醒606次，喚醒時間20分18秒，耗電0.3 mAh
微信 耗電、喚醒次數、喚醒時間詳情
如圖所示，48小時內微信喚醒721次，喚醒時間25分41秒，耗電0.8 mAh
360省電王評價
如圖所示，360省電王對UDP和TCP演示app的耗電評價是"此軟件耗電極少，適合長期后臺運行，請放心使用"
注：360省電王版本為2.2.2.0001
耗電小結
綜上所述，在2G網絡GPRS連接情況下，TCP與UDP兩種方式的耗電基本沒差別，并且對手機電池的消耗較少，加上與微信的對比，證明方案可行。
DDPush消息推送 網絡流量分析
網絡流量，特別是無線電話網絡流量，有時候并不是它所應該的那么便宜。即使不考慮價格因素，更快的速度、更高的通信效率這些目標也決定了我們不能無節制地消耗流量，至少不環保。實際上，DDPush從設計的初期開始，就以盡可能少的網絡傳輸作為核心目標。
終端上載流量
根據DDPush當前的通信協議，終端上傳的一個UDP數據包，有效數據最少為21字節。加上UDP和IP包的首部長度，不會超過70字節。移動互聯網環境下，假設終端每5分鐘發送一次心跳包（這個是建議值，過于頻繁可能導致智能終端（手機）電池電量消耗過快），則一個月的上載數據量為70x12x24x30=604800字節，約合591K。這就是DDPush客戶端所消耗的上載流量（完全空載運行情況下）。
實際情況可能有些不一樣，因為當手機處于非休眠狀態的時候（智能手機大部分時間都是休眠的），我們可能希望心跳的間隔小一些，以便更及時地收到實時信息，又不至于消耗過多的電（非休眠狀態下是非常耗電的，不在乎多耗一些了）。所以，DDPush客戶端的上傳流量會比上述的591K稍多一些。
終端下載流量
DDPush終端的下載流量遠比上傳流量少（詳見協議內容和使用文檔），而且在無信息通知的情況下，DDPush服務器可通過參數配置成不下發心跳，這時將不會有下載流量產生。當然，這種情況下終端可能無法判斷自己是否在線。
服務器流量
對于服務器而言，主要的流量是入站流量，這與大部分互聯網服務恰恰相反（例如HTTP服務就是典型的入站流量小，出站流量大）。其實這也是IM系統的一個特點。根據DDPush的測試，獨享百兆帶寬出口(100m bits/second)的網絡，可支持一千萬以上終端同時在線（5分鐘一次心跳，平均每秒3.33萬個UDP心跳包，完全是DDPush的能力之內，這時UDP包的成功率將近100%）
什么？獨享百兆出口帶寬太貴了？拜托，一千萬在線客戶，您已經是土豪了，就別在乎那一點點帶寬費用了......
小結
使用DDPush消息推送，終端設備基本可以忽略DDPush客戶端自身的流量；而服務端的流量，相對其收益來說，成本將是非常低的。
?
UDP對TCP
TCP還是UDP？長連接如何實現？如何實現心跳機制？心跳的間隔如何確定？這些問題都是討論即時通訊、消息推送等類似話題時，幾乎一定被問到的問題。這里嘗試正本清源一下。
互聯網、移動互聯網網絡環境
在分析到底應該使用UDP還是TCP之前，有必要先討論一下互聯網與移動互聯網的網絡環境特點。
互聯網的網絡基礎建設，經過十幾年長期的發展，已經較為穩定和成熟，PC終端、操作系統的能力也達到了較高的水平。
而移動互聯網，由于涉及到無線電話網絡基站、2G、3G和4G技術的不斷發展，其穩定性、帶寬、資源分配等各方面雖日趨完善，但當前終究還有不少問題的存在。另外，由于移動互聯網其“移動”的本質，加上智能終端設備（智能手機、平板電腦）的發展較晚，目前還在不斷演變的情況，與互聯網相比，移動互聯網還是低速、不穩定、終端能力稍弱的情況。而且由于其“移動”本質，短時間內很難達到互聯網的質量。
所以，在互聯網的環境里面，網絡應用程序由于網絡設施、操作系統的成熟，開發使用起來比較容易，資源也較為充足。而移動互聯網還是要“斤斤計較”。
智能終端電池續航能力，系統休眠
智能終端設備的電池續航能力始終是技術瓶頸。在連續使用的情況下，絕大部分智能設備電池無法支持兩個小時以上。所以在沒有外部電源的情況，智能終端設備必須頻繁、長時間休眠，這將極大地影響兩種網絡環境下的網絡應用場景。
IPv4資源、端口資源
這個話題往往被很多人忽略，但它有著至關重要的影響。雖然大部分人都很清楚IP地址的緊缺導致的動態IP分配的必然，卻忽略了由于IP地址不足引起的端口資源不足。
由于需要動態分配IP地址（這里不僅僅指互聯網入口的IP，還包括局域網內部的IP），路由器的工作原理都是經過端口映射，把內部網絡（包括PC、手機、平板、Wifi、2G、3G、4G）IP與端口映射成外部IP（通常是公網IP）和對應的端口，并維持這個映射關系，才能正常地修改、轉發報文信息，保證內部各個ip、端口與外部的各個ip、端口的通信。
然而，單個IP地址的端口資源是有限的，理論上限是65535個端口。對于普通寬帶路由器來說，這個已經很充足了。但是！對于大型的網絡服務、網絡主干接入點等來說，如果IP資源不足，每個IP幾萬個端口的資源很快會耗盡，從而影響正常通訊。
端口映射老化時間
正因為如此，所有的路由器都會為每個端口映射關系設置老化時間，如果老化時間倒數到0，則端口映射關系失效，該端口被釋放給其他連接使用。如果端口全部耗盡，則無法再新建內部與外部的網絡連接。
端口映射老化時間，比很多人想象中的要短很多。一般的家用寬帶路由器，老化時間一般是兩三分鐘；在有線寬帶運營商接入部分，老化時間可能少于兩分鐘。在無線電話網絡運營商接入部分（例如GPRS連接），老化時間甚至不超過一分鐘！
也就是說，任何一個網絡通訊（不管是TCP或UDP），如果幾分鐘之內沒有網絡報文傳輸，其占用的IP地址端口將被路由器回收。這個時候該次通信必將終止，不管TCP還是UDP，神馬都是浮云。
更殘酷的事實是，互聯網可認為是由無數個路由器連接而成的，一個網絡通信往往需要通過n個路由器，每個路由器都會為一次通信建立自己的端口映射。只要其中一個路由器回收其端口，則整個通訊中斷。
這也是很多人疑惑為什么TCP的KeepAlive參數無法保證長連接的原因。TCP的KeepAlive默認是兩個小時（而且該參數還是TCP的可選實現，不是必然實現），在路由器端口映射老化時間的影響下，必然無法發揮其作用。實際上，該參數在單一的局域網內才可能被使用上，還要依賴具體的操作系統。
由于路由器端口映射的存在，加上智能終端頻繁、長時間的休眠，TCP長連接的實用性在移動互聯網情況下極大地打了折扣。
也因為如此，IM系統必須實現所謂的心跳包機制，以保持端口映射關系的老化時間不會減少到0而被回收，從而避免連接中斷。
服務端承載能力
不管是UDP還是TCP，最終都是應用服務端的設備去提供服務的。而TCP由于提供了安全可靠的流服務，其對計算機、網絡資源的消耗是遠遠大于UDP協議的。對于配置較好的主流服務器，配備大量的內存（數十G至上百G內存），與高速的磁盤、網卡，是能同時支持數百萬個TCP連接的。不過這里需要較專業的服務器設置，需要調整不少系統參數，再加上服務程序的配合。另外，TCP連接的建立、維持與釋放，都是需要較昂貴的計算、網絡資源的。
終端在線服務，若是一個較為簡單的服務，未必使用上TCP眾多的高級功能，但承受TCP的昂貴成本，未必值得。如果能用UDP來提供服務，單服務器的承載能力，是可以去到TCP服務的數十倍，甚至上百倍的增長。這也是為什么DNS這種并發數巨大的服務器提供UDP接口的原因。
另外，上百萬TCP連接的網絡服務，其編程的難度、程序復雜度、調試難度、服務器運維成本、網絡成本等都遠遠高于UDP。
而UDP編程，與上百萬個終端通訊的難度與成本則低很多。如果提供的網絡服務不是基于流的服務，也允許一定的失敗機率（例如P2P），則UDP往往是更適合的方式。
高級應用網絡通訊要求
不過，即時通訊系統、推送系統一方面提供終端在線服務，另外一方面也需要考慮內容信息的完整性和安全性。畢竟信息的丟失，或者通訊的被竊聽，都是難以接受的。而TCP不管在網絡層的可靠性控制，還是在應用層的安全支持（例如HTTPS），都為應用提供無法替代的強大功能和便利。
結論
綜合以上所述，其實答案也呼之欲出。
現在的即時通訊系統、推送系統，既面對移動互聯網的不確定性，又面對智能終端頻繁的系統休眠、網絡切換，還要考慮服務端的承載成本，對于在線服務而言UDP是比TCP更適合的方式。但是由于數據完整性、安全性的需要，又不應完全放棄TCP的可靠與安全。
所以，DDPush認為，更恰當的方式應該是：兩種通信協議同時使用，各有側重。UDP用于保持大量終端的在線與控制，應用與業務則通過TCP去實現。這個和FTP服務控制與數據分離，采取不同的連接，有異曲同工之處。
事實上，這個也是即時通訊巨頭QQ所采用的方式。早期的時候，QQ還是主要使用TCP協議，而后來就轉向了采用UDP的方式來保持在線，TCP的方式來上傳和下載數據。現在，UDP是QQ的默認工作方式，表現良好。相信這個也被沿用到了微信上。
簡單的考證：登錄PC版QQ，關閉多余的QQ窗口只留下主窗口，并將其最小化。幾分鐘過后，查看系統網絡連接，會發現QQ進程已不保有任何TCP連接，但有UDP網絡活動。這時在發送聊天信息，或者打開其他窗口和功能，將發現QQ進程會啟用TCP連接。
最后，需要明確指出的是：DDPush只專注在保持和控制終端在線方面，而對于具體的應用和業務，DDPush是基本不提供任何支持的。
DDPush 任意門推送 1 下載
歡迎來到DDPush任意門推送下載頁面。該頁面提供DDPush最新版本的下載鏈接，也包括舊的歷史版本。
注：Android示例工程app中使用到的ddpush相關類庫jar包，代碼實際是ddpush server中的client部分。
系統要求
Java 6.0或以上
最新版本1.0.03 (2015-01-02發布)
- 修復了app server端連續推送混合信息時，可能引起的掛起。
- 客戶端tcp超時默認設置改為300秒。
- 控制臺取消僅允許本地網絡訪問的限制，可遠程網絡連接控制臺。
- Android示例客戶端app無更新。
二進制發布
DDPush Server v1.0.03
安卓客戶端App示例（UDP）
安卓客戶端App示例（TCP）
源碼發布
DDPush Server v1.0.03
安卓客戶端App示例（UDP）
安卓客戶端App示例（TCP）
歷史版本1.0.02 (2014-08-29發布, 2014-11-21更新android示例工程)
- UDP客戶端基類UDPClientBase.java增加getLastReceivedTime()方法，記錄服務器最后UDP包時間，可用于IM系統客戶端自我判斷是否在線或超時
- 修復了TCP模式下，自定義信息長度較長時引起數據紊亂的Bug。該Bug不影響UDP模式客戶端。
- 2014-11-21更新了android示例客戶端，包括TCP和UDP兩個工程，解決了部分安卓版本“很抱歉，‘xxxx’已停止運行”的異常提示。
二進制發布
DDPush Server v1.0.02
安卓客戶端App示例（UDP）
安卓客戶端App示例（TCP）
源碼發布
DDPush Server v1.0.02
安卓客戶端App示例（UDP）
安卓客戶端App示例（TCP）
歷史版本1.0.01 (2014-08-01)
DDPush誕生了
二進制發布
DDPush Server v1.0.01
安卓客戶端App示例（UDP）
安卓客戶端App示例（TCP）
源碼發布
DDPush Server v1.0.01
安卓客戶端App示例（UDP）
安卓客戶端App示例（TCP）
?
總結
以上是生活随笔為你收集整理的DDPush 任意门消息推送 开源免费实时信息推送服务器的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Java面向对象基础呕心沥血三千字
- 下一篇： 快乐起床歌.wav