[發明專利]信息推送系統及方法

有效

• 申請號: 201410495792.4
• 申請日: 2014-09-24
• 公開（公告）號: CN105516221B
• 公開（公告）日: 2018-12-14
• 發明（設計）人: 陳虓將;劉彥梅
• 申請（專利權）人: 阿里巴巴集團控股有限公司
• 主分類號: H04L29/08
• 分類號: H04L29/08
• 代理公司: 北京清亦華知識產權代理事務所(普通合伙) 11201
• 代理人: 張大威

本申請提出一種信息推送系統及方法，其中該系統包括服務器和客戶端，其之間通過SPDY協議進行通信，且具有長連接，其中客戶端用于與服務器通過長連接建立長連接數據流和普通數據流，通過長連接數據流接收服務器的推送信息包，并通過普通數據流向服務器發送業務數據請求或信息確認包，以及在接收到服務器反饋的業務數據請求對應的數據包或返回的信息確認包之后關閉對應的普通數據流；服務器用于通過長連接數據流將推送信息包發送至客戶端，并通過普通數據流向客戶端返回業務數據請求對應的業務數據包或信息確認包，并在反饋完成之后關閉對應的普通數據流。本申請實施例的系統可減少連接的管理成本、時間成本和帶寬成本，節省終端的電量。

技術領域

本申請涉及互聯網技術領域，尤其涉及一種信息推送系統及方法。

背景技術

目前，移動終端中的兩個主流操作系統(Android操作系統和IOS操作系統)都有各自的消息推送系統：分別為GCM(Google Cloud Messaging for Android，谷歌公司推出的云推送消息服務)和APNS(Apple Push Notification Service，蘋果推送通知服務)。通過這兩套消息推送系統可分別向基于Android和IOS操作系統的移動終端推送消息。但是，由于IOS的封閉性，在消息推送不成功的情況下無法確定失敗的原因，而且IOS對消息發送有各種限制，在有些場合下不能滿足業務的需求。另外，GCM和APNS分屬于不同公司，互不相通，跨平臺的消息推送存在困難。在這種情況下，搭建自有的跨平臺的消息推送系統是很多大型互聯網公司的選擇。

相關技術中，跨平臺的消息推送系統具有一個前端接入服務器，通過該服務器接入海量的用戶請求。客戶端和接入服務器之間采用TCP(Transmission Control Protocol，傳輸控制協議)協議建立長連接，應用層的協議可以采用標準協議或私有協議。其中的一種選擇就是客戶端和服務器之間通過HTTP(Hypertext transfer protocol，超文本傳輸協議)協議進行通信，以HTTP chunk的方式不斷下發消息。其實現過程如下：客戶端先發請求，服務器在接收到客戶端請求之后處理該請求并下發應答包，應答包采用HTTP chunk的格式封裝需要下發給客戶端的消息，但是，由于標準HTTP協議是單工通信，所以，為便于應答包的區分，此時客戶端通常不會通過之前建立的連接再發起新的請求。因此，HTTP chunk的工作模式存在以下缺陷：

(1)客戶端如果需要上報消息回執，則必須建立新的通道，這樣會增加TCP建立和銷毀連接的成本，同時還會增加客戶端和服務器對連接的管理成本，且導致客戶端的電量和流量的額外消耗；

(2)客戶端和服務器之間的長連接保活通過在服務器側下發HTTP chunk來實現，不能從客戶端側發起保活包，更不能做到雙向保活。

發明內容

本申請的目的旨在至少在一定程度上解決相關技術中的技術問題之一。

為此，本申請的第一個目的在于提出一種信息推送系統。該系統基于SPDY標準協議以實現單條連接內的全雙工通信，只需為客戶端維護一條連接即可完成各項工作，減少了連接的管理成本、時間成本和帶寬成本，節省了移動終端的電量。

本申請的第二個目的在于提出一種信息推送方法。