信息推送系统及方法
【技术领域】
[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在