信息推送系統及方法
【技術領域】
[0001]本申請涉及互聯網技術領域，尤其涉及一種信息推送系統及方法。
【背景技術】
[0002]目前，移動終端中的兩個主流操作系統(Android操作系統和1S操作系統)都有各自的消息推送系統:分別為GCM(Google Cloud Messaging for Android,谷歌公司推出的云推送消息服務)和APNS (Apple Push Notificat1n Service,蘋果推送通知服務)。通過這兩套消息推送系統可分別向基于Android和1S操作系統的移動終端推送消息。但是，由于1S的封閉性，在消息推送不成功的情況下無法確定失敗的原因，而且1S對消息發送有各種限制，在有些場合下不能滿足業務的需求。另外，GCM和APNS分屬于不同公司，互不相通，跨平臺的消息推送存在困難。在這種情況下，搭建自有的跨平臺的消息推送系統是很多大型互聯網公司的選擇。
[0003]相關技術中，跨平臺的消息推送系統具有一個前端接入服務器，通過該服務器接入海量的用戶請求。客戶端和接入服務器之間采用TCP (Transmiss1n Control Protocol,傳輸控制協議)協議建立長連接，應用層的協議可以采用標準協議或私有協議。其中的一種選擇就是客戶端和服務器之間通過HTTP (Hypertext transfer protocol,超文本傳輸協議)協議進行通信，以HTTP chunk的方式不斷下發消息。其實現過程如下:客戶端先發請求，服務器在接收到客戶端請求之后處理該請求并下發應答包，應答包采用HTTP chunk的格式封裝需要下發給客戶端的消息，但是，由于標準HTTP協議是單工通信，所以，為便于應答包的區分，此時客戶端通常不會通過之前建立的連接再發起新的請求。因此，HTTP chunk的工作模式存在以下缺陷:
[0004](I)客戶端如果需要上報消息回執，則必須建立新的通道，這樣會增加TCP建立和銷毀連接的成本，同時還會增加客戶端和服務器對連接的管理成本，且導致客戶端的電量和流量的額外消耗；
[0005](2)客戶端和服務器之間的長連接保活通過在服務器側下發HTTP chunk來實現，不能從客戶端側發起保活包，更不能做到雙向保活。
【發明內容】
[0006]本申請的目的旨在至少在一定程度上解決相關技術中的技術問題之一。
[0007]為此，本申請的第一個目的在于提出一種信息推送系統。該系統基于SPDY標準協議以實現單條連接內的全雙工通信，只需為客戶端維護一條連接即可完成各項工作，減少了連接的管理成本、時間成本和帶寬成本，節省了移動終端的電量。
[0008]本申請的第二個目的在于提出一種信息推送方法。
[0009]為達上述目的，本申請第一方面實施例提出的信息推送系統，包括服務器和客戶端，其中，所述服務器和所述客戶端之間通過SPDY協議進行通信，且所述服務器和所述客戶端之間具有長連接，其中，所述客戶端，用于與所述服務器通過所述長連接建立長連接數據流和至少一個普通數據流，其中，所述客戶端通過所述長連接數據流接收所述服務器的推送信息包，并通過所述至少一個普通數據流向所述服務器發送業務數據請求或信息確認包，以及在接收到所述服務器反饋的所述業務數據請求對應的數據包或返回的信息確認包之后關閉對應的普通數據流；以及所述服務器，用于通過所述長連接數據流將所述推送信息包發送至所述客戶端，并通過所述至少一個普通數據流向所述客戶端返回所述業務數據請求對應的業務數據包或信息確認包，以及在反饋所述業務數據包或信息確認包之后關閉對應的普通數據流。
[0010]本申請實施例的信息推送系統，基于SPDY標準協議以實現單條連接內的全雙工通信，即客戶端允許在一條連接上并行發起多個子請求，服務器不必按照子請求的順序返回應答，并且由于客戶端和服務器通過SPDY協議建立長連接之后，即可通過SPDY長連接數據流在服務器側不斷下發消息，又可在客戶端側發起新的請求，因此采用SPDY協議之后信息推送、數據上報和業務請求可以同時進行，只需為客戶端維護一條連接即可完成各項工作，減少了連接的管理成本、時間成本和帶寬成本，節省了移動終端的電量。
[0011]為達上述目的，本申請第二方面實施例提出的信息推送方法，服務器和客戶端之間通過SPDY協議進行通信，且所述服務器和所述客戶端之間具有長連接，所述包括:所述客戶端與所述服務器通過所述長連接建立長連接數據流和至少一個普通數據流，其中，所述客戶端通過所述長連接數據流接收所述服務器的推送信息包，并通過所述至少一個普通數據流向所述服務器發送業務數據請求或信息確認包；所述服務器通過所述長連接數據流將所述推送信息包發送至所述客戶端，并通過所述至少一個普通數據流向所述客戶端返回所述業務數據請求對應的業務數據包或信息確認包；以及所述客戶端在接收到所述服務器反饋的所述業務數據請求對應的數據包或返回的信息確認包之后關閉對應的普通數據流，以及所述服務器在反饋所述業務數據包或信息確認包之后關閉對應的普通數據流。
[0012]本申請實施例的信息推送方法，基于SPDY標準協議以實現單條連接內的全雙工通信，即客戶端允許在一條連接上并行發起多個子請求，服務器不必按照子請求的順序返回應答，并且由于客戶端和服務器通過SPDY協議建立長連接之后，即可通過SPDY長連接數據流在服務器側不斷下發消息，又可在客戶端側發起新的請求，因此采用SPDY協議之后信息推送、數據上報和業務請求可以同時進行，只需為客戶端維護一條連接即可完成各項工作，減少了連接的管理成本、時間成本和帶寬成本，節省了移動終端的電量。
[0013]本申請附加的方面和優點將在下面的描述中部分給出，部分將從下面的描述中變得明顯，或通過本申請的實踐了解到。
【附圖說明】
[0014]本申請上述的和/或附加的方面和優點從下面結合附圖對實施例的描述中將變得明顯和容易理解，其中:
[0015]圖1是根據本申請一個實施例的信息推送系統的結構示意圖；
[0016]圖2是根據本申請實施例的信息推送系統中的客戶端和服務器之間的交互圖；以及
[0017]圖3是根據本申請一個實施例的信息推送方法的流程圖。
【具體實施方式】
[0018]下面詳細描述本申請的實施例,所述實施例的示例在附圖中示出，其中自始至終相同或類似的標號表示相同或類似的元件或具有相同或類似功能的元件。下面通過參考附圖描述的實施例是示例性的，旨在用于解釋本申請，而不能理解為對本申請的限制。
[0019]下面參考附圖描述根據本申請實施例的信息推送系統及方法。
[0020]圖1是根據本申請一個實施例的信息推送系統的結構示意圖。如圖1所示，該信息推送系統可以包括服務器100和客戶端200。需要說明的是，在本申請的實施例中，服務器100和客戶端200之間通過SPDY協議進行通信，且服務器和客戶端之間具有長連接。其中，SPDY協議是Google (谷歌)公司開發的基于傳輸控制協議(TCP)的應用層協議，SPDY協議類似于HTTP，但旨在縮短網頁的加載時間和提高安全性，SPDY協議通過壓縮、多路復用和優先級來縮短加載時間。
[0021]具體地，客戶端200可用于與服務器100通過長連接建立長連接數據流(長連接stream)和至少一個普通數據流(普通stream)，其中，客戶端200可通過長連接數據流接收服務器100的推送信息包，并通過至少一個普通數據流向服務器100發送業務數據請求或信息確認包，以及在接收到服務器100反饋的業務數據請求對應的數據包或返回的信息確認包之后關閉對應的普通數據流。其中，在本申請的實施例中，長連接可以是TCP長連接。此外，在本申請的實施例中，至少一個可理解為“一個”或“一個以上”。
[0022]也就是說，在本申請的實施例中，在客戶端200與服務器100建立長連接數據流和至少一個普通數據流之前，客戶端200可先與服務器100建立一條TCP長連接。其中，長連接數據流(長連接stream)可理解為是客戶端200與服務器100在TCP長連接的基礎上建立的具有消息下發功能的流，并在長連接數據流建立完成之后，服務器100可在向客戶端200返回的應答包中通過非關閉標識位，以告知客戶端200不關閉該長連接數據流，即長連接數據流在連接存活的生命周期內不會被關閉。普通數據流(普通stream)可理解為是客戶端200與服務器100在TCP長連接的基礎上建立的具有發送業務數據請求、或信息確認包等功能的普通的流，在客戶端200和服務器100在使用完普通數據流之后，可通過關閉標識位關閉相應的流，即普通數據流在請求交互完成后會被正常關閉。其中，流可以理解是一個雙向字節流穿過一個SPDY會話中的虛擬通道。
[0023]其中，在本申請的實施例中，長連接數據流和至少一個普通數據流各自分別具有標識，在客戶端200和服務器100之間傳輸的數據包中具有數據包所屬長連接數據流或至少一個普通數據流所對應的標識。舉例而言，以長連接數據流為例，長連接數據流中具有標識為“id= 1”，則在客戶端200和服務器100之間傳輸的數據包中具有標識“id= 1”，其表示該數據包所屬于標識為“id = I”的長連接數據流。
[0024]服務器100可用于通過長連接數據流將推送信息包發送至客戶端200，并通過至少一個普通數據流向客戶端200返回業務數據請求對應的業務數據包或信息確認包，以及在反饋業務數據包或信息確認包之后關閉對應的普通數據流。
[0025]舉例而言，如圖2所示，首先，客戶端200可向服務器100建立一條TCP長連接。之后客戶端200可在該TCP長連接的基礎上向服務器100發送握手請求“syn_stream(id =I) ”，請求建立用于服務器100下發消息的長連接數據流(長連接stream)。服務器100在