長連接

短連接是指通訊雙方有數據交互時，就建立一個連接，數據發送完成後，則斷開此連接，即每次連接只完成一項業務的發送。

長連接多用於操作頻繁，點對點的通訊，而且連接數不能太多情況。每個TCP連接都需要三步握手，這需要時間，如果每個操作都是短連接，再操作的話那麼處理速度會降低很多，所以每個操作完後都不斷開，下次處理時直接發送數據包就OK了，不用建立TCP連接。例如：數據庫的連接用長連接，如果用短連接頻繁的通信會造成socket錯誤，而且頻繁的socket 創建也是對資源的浪費。

而像WEB網站的http服務一般都用短鏈接，因為長連接對於服務端來説會耗費一定的資源，而像WEB網站這麼頻繁的成千上萬甚至上億客户端的連接用短連接會更省一些資源，如果用長連接，而且同時有成千上萬的用户，如果每個用户都佔用一個連接的話，那可想而知吧。所以併發量大，但每個用户無需頻繁操作情況下需用短連好。

總之，長連接和短連接的選擇要視情況而定。

手機推送服務的原理很簡單，就是通過建立一條手機與服務器的連接鏈路，當有消息需要發送到手機時，通過此鏈路發送即可。 推送服務的使用流程雖然略有差別但是大致都和IOS的APNS相似

1、首先是應用程序註冊消息推送。

2、 IOS跟APNS Server要deviceToken。應用程序接受deviceToken。

3、應用程序將deviceToken發送給PUSH服務端程序。

4、 服務端程序向APNS服務發送消息。

5、APNS服務將消息發送給iPhone應用程序

推送方案的公認評價採取4s標準：1.Safe(安全) 2. Stable（穩定） 3.Save（省電省流量省成本） 4.Slim（體積小）

推送方案應支持透傳及各種加密方案，保障信息傳遞安全。

推送方案的ID系統應該獨立於已有的網站或服務的ID系統，這樣保障用户在不同手機上登錄後的信息投遞準確性，避免因為取消綁定事件失敗因網絡傳輸而造成的信息誤投送。

穩定包括兩個部分一個是服務器端的穩定性，一個是手機端的穩定性。

服務端穩定性，因為使用長連接方案，對服務器的開銷和要求很大，推送方案對服務器開發要求很高，海量線程連接下的服務器穩定性是非常具有挑戰性的。一般的評判標準包括：

- 同時在線時峯值 （一般按照百萬併發連接時服務器穩定性評測）

- 高併發時消息平均延遲時間（一般按照1分鐘處理1百萬條信息評測）

- 服務穩定性 （一般要求全年99.9%以上可用，有備份，有負載均衡等）

鑑於服務器穩定的開發難度很大，小團隊不建議自己開發，建議使用穩定的第三方推送方案，如個推，蝴蝶等。

手機端的穩定性，主要是因為中國的複雜網絡狀況及手機型號適配情況造成手機長時間穩定聯網較困難，所以穩定性非常重要，一般的評判標準包括：

- 每日聯網23.5小時以上用户比例 （表徵聯網穩定性）

- 消息發送後9小時內收到率 （表徵到達率）

一般來説，推送方案要做網絡的分運營商，分省，分機型適配，自己開發工作量較大

3.Save（節省）

省電應注意CPU休眠，一般用服務縮短待機時間百分比評判

省流量應注意協議的修改和冗餘數據包的處理，一般用空載待機月流量評判

省成本應考慮單服務器承載同時連接數，可承載同時連接數越多成本越低，業內 頂尖水平為個推的單服務器50萬連接

4.Slim（體積小）

推送服務應該體積儘量小，不影響主程序的大小和複雜度，一般以小於300K為宜。