CN105991689B

CN105991689B - Http报文处理方法及系统、http客户端及服务器

Info

Publication number: CN105991689B
Application number: CN201510056362.7A
Authority: CN
Inventors: 闵庆欢
Original assignee: Alibaba Group Holding Ltd
Current assignee: Taobao China Software Co Ltd
Priority date: 2015-02-03
Filing date: 2015-02-03
Publication date: 2020-02-28
Anticipated expiration: 2035-02-03
Also published as: CN105991689A

Abstract

一种HTTP报文处理方法及系统、HTTP客户端及服务器；该方法包括：HTTP客户端构造包含用于标识支持服务端推模式的Expect头部字段的HTTP请求报文，并发送该HTTP请求报文；在与该HTTP请求报文相对应的长连接断开前，HTTP客户端重复执行如下处理：通过所述长连接接收HTTP响应报文；接收到包含用于标识支持服务端推模式的Expect头部字段的HTTP请求报文后，在与该HTTP请求报文相对应的长连接断开前，HTTP服务器重复执行如下处理：当前有数据需要推送时，在HTTP响应报文中标识该数据的长度，并将该数据包含在该HTTP响应报文中，通过所述长连接发送该HTTP响应报文。

Description

HTTP报文处理方法及系统、HTTP客户端及服务器

技术领域

本申请涉及通信领域，尤其涉及一种HTTP(HyperText Transfer Protocol，超文本传送协议)报文处理方法及系统、HTTP客户端及服务器。

背景技术

HTTP是基于TCP/IP(Transfer Control Protocol/Internet Protocol，传输控制协议/互联网协议)之上的一个应用层协议。该协议是一种典型的请求/响应(Request/Response)协议，其特点是无状态且需要HTTP客户端发起请求(Request)，HTTP服务器才能进行响应(Response)，这意味着HTTP服务器无法主动向HTTP客户端推送信息。

图1是现有技术中标准的HTTP报文交互流程示意图，如图1所示，该报文交互流程包括：

步骤S100：HTTP客户端(简称客户端)向HTTP服务器(简称服务器)发送第1个HTTP请求报文(简称请求报文，记作Request1)。

步骤S102：接收到Request1后，服务器向客户端返回第1个HTTP响应报文(简称响应报文，记作Response1)。

步骤S104：接收到Response1后，客户端向服务器发送第2个请求报文(记作Request2)。

步骤S106：接收到Request2后，服务器向客户端返回第2个响应报文。

之后可以重复执行上述步骤。

从以上流程可知，服务器发送的响应报文与客户端发送的请求报文一一对应。即，在没有接收到客户端发送的请求报文之前，服务器无法向客户端发送响应报文，且接收到一个请求报文，服务器只能发送一个响应报文。

目前有很多应用需要HTTP服务器提供服务端推送服务，例如：监控系统、即时报价系统、游戏、协同文档、进度条等应用，都需要HTTP服务器能实时地将更新的信息推送到HTTP客户端，而无须HTTP客户端发出请求。

为了满足对服务端推送服务的应用需求，现有技术中较为流行的解决方案为Comet(彗星)技术，Comet技术包括两种实现方式：长轮询(long-polling)方式和基于iframe的流方式。

图2是现有技术中采用长轮询方式实现Comet技术的方法的方法流程图。

长轮询(long-polling)与轮询之间的主要区别在于从HTTP服务器接收到HTTP请求报文到发送HTTP响应报文之间的时间间隔。长轮询通常将连接保持一段较长的时间，通常是数秒钟，也可能是一分钟甚至更长，当HTTP服务器上发生某个事件时，HTTP响应报文被发送，相应的连接随即被断开，长轮询立即重新开始。

如图2所示，该方法包括：

步骤S200：HTTP客户端(简称客户端)打开一个长连接，并向HTTP服务器(简称服务器)发送HTTP请求报文(简称请求报文)。

步骤S202：接收到客户端发送的请求报文后，服务器阻塞该请求报文，直到有数据需要发送或超时(由服务器设定连接超时时间)才向客户端返回HTTP响应报文(简称响应报文)，并断开对应的长连接；

上述响应报文中可以包含需要发送给客户端的数据。

步骤S204：接收到响应报文后，客户端中的响应处理函数会对响应报文中包含的数据进行处理，处理完成后重新打开一个长连接，并向服务器发送请求报文。

步骤S206：在步骤S202之后，如果有新的数据产生，服务器保存该数据，直到再次接收到客户端发送的请求报文后，通过向客户端发送响应报文将该数据返回给客户端。

图3是现有技术中采用基于iframe的流方式实现Comet技术的方法的方法流程图。

基于iframe的流方式需要使用HTTP长连接，实际实现时在浏览器页面中嵌入一个iframe元素(内联框架)，然后使用这个iframe请求一个特定的URL(Uniform ResourceLocator，统一资源定位符)，并通过这个页面的加载不断的从服务器抓回数据，从服务端抓回的数据大多是对页面当前JS(JavaScript)函数的引用和操作。Iframe中HTTP头的Transfer-Encoding(传输编码)属性为chunked(分块)，这意味着服务端并不知道要发送给客户端多少数据，也就隐式意味着该连接的长度为无限。

如图3所示，该方法包括：

步骤S300：HTTP客户端(简称客户端)打开一个长连接，并向HTTP服务器(简称服务器)发送HTTP请求报文(简称请求报文)。

步骤S302：当有数据产生时，服务器使用HTTP 1.1规范中规定的chunked(分块)编码方式回传第一部分数据；

通常，一个chunked编码段放在一个TCP包中发送。

步骤S304：当再有数据产生时，服务器使用chunked编码方式回传第二部分数据。

服务器重复上述步骤，直至长连接超时断开，或者客户端或服务器主动断开长连接。

图4是现有技术中基于HTTP 2.0的服务端推送方法的方法流程图。如图4所示，该方法包括：

步骤S400：HTTP 2.0客户端(简称客户端)打开一个连接，并向HTTP2.0服务器(简称服务器)发送作为请求报文的HEADERS(报头)帧，以创建一个新的流(Stream)；

上述HEADERS帧中包含流的流标识符stream_id，例如：stream_id＝1；以下将stream_id＝1的流记作Stream₁；

上述HEADERS帧还包含method(方法)字段：“:method＝GET”，用于标识该帧的具体请求类型。

步骤S402：接收到客户端发送的HEADERS帧后，服务器在Stream₁上向客户端发送作为请求报文的PUSH_PROMISE(推送承诺)帧；

上述PUSH_PROMISE帧中包含Promised-Stream-ID标记，例如：

“Promised-Stream-ID＝2”；

该标记用于标识服务器准备使用的流的流标识符stream_id＝2，以下将stream_id＝2的流记作Stream₂；

上述PUSH_PROMISE帧还包含method(方法)字段：“:method＝GET”，用于标识该帧的具体请求类型。

步骤S404：服务器在Stream₂上向客户端发送作为响应报文的HEADERS帧；

上述HEADERS帧中包含状态(status)字段，例如：“:status＝200”，用于标识响应状态；

此外，HEADERS帧中还包含内容类型(content-type)字段，例如：“content-type＝image/png”，用于标识后续帧中携带的数据的数据类型。

此外，HEADERS帧中还包含内容长度(content-length)字段，例如：“content-length＝123”，用于标识后续帧中携带的数据的长度。

步骤S406：服务器在Stream₂上向客户端发送DATA(数据)帧，用于向客户端传输数据，如果数据传输完毕，则用END_STREAM(流结束)标记关闭Stream₂。

步骤S408：服务器在Stream₁上向客户端发送作为响应报文的HEADERS帧；

此外，HEADERS帧中还包含内容类型(content-type)字段，例如：“content-type＝text/html”，用于标识后续帧中携带的数据的数据类型。

此外，HEADERS帧中还包含内容长度(content-length)字段，例如：“content-length＝33”，用于标识后续帧中携带的数据的长度。

步骤S406：服务器在Stream₁上向客户端发送DATA(数据)帧，数据传输完毕后用END_STREAM标记关闭Stream₁。

综上所述，对于comet技术，无论是采用长轮询方式实现，还是采用基于iframe的流方式实现，其逻辑过程仍然是客户端请求、服务端响应的拉(pull)模式，非真正意义上的服务端推(push)模式，仅仅是为了用户感受模拟服务端推送的实现方案。

此外，采用长轮询方式实现comet技术采用的是延时的服务端响应，即，服务器接收到客户端主动发起的请求后，以非常慢的响应方式返回响应，这样，服务器就可以使用同一个连接把在这个期间内需要更新的数据主动发送给客户端，从而让客户端以为数据是服务器主动推送过来的。也就是说，该方式本质上仍然是利用了HTTP的请求/响应的拉模式，且客户端在每次接收和处理数据后都需要重新发起新的连接请求，造成了网络资源和客户端和服务器处理资源的浪费。

而采用基于iframe的流方式实现comet技术，本质上是采用了HTTP 1.1规范中规定的chunked编码传输模式。服务器每次产生的数据均以chunked编码方式封装，通过一个TCP包发送，从TCP的层面上看是一个客户端请求包后续带来了若干个服务器的响应包，但从应用层上看，仍然是一个HTTP请求报文对应了一个HTTP响应报文，只不过这个HTTP响应报文被分装到了多个TCP包中发送，仍然不是真正的服务端推模式；而且采用基于iframe的流方式时需要使用iframe标记，即需要浏览器实现内联框架，某些浏览器，例如IE(Internet Explorer，互联网浏览器)对内联框架没有很好地支持。

采用HTTP 2.0的服务端推送方法需要使用流(stream)，并且在发起服务端推送时需要发起新的流。因此对于仅支持HTTP 1.1的客户端、服务器程序而言，需要进行大规模升级才能实现服务端推送的功能，成本很高。

发明内容

本申请的目的在于提供一种HTTP报文处理方法及系统、HTTP客户端及服务器。

为了达到上述目的，本申请公开了一种HTTP报文处理方法，该方法包括：

接收到包含用于标识支持服务端推模式的Expect头部字段的HTTP请求报文后，在与该HTTP请求报文相对应的长连接断开前，HTTP服务器重复执行如下处理：

当前有数据需要推送时，在HTTP响应报文中标识该数据的长度，并将该数据包含在该HTTP响应报文中，通过所述长连接发送该HTTP响应报文。

此外，所述用于标识支持服务端推模式的Expect头部字段中包含：用于标识支持服务端推模式的expectation-extension值。

此外，当前有数据需要推送时，在包含所述数据的HTTP响应报文中设置如下状态码：

用于标识有后续数据需要推送的状态码；或

用于标识无后续数据需要推送的状态码。

此外，接收到所述HTTP请求报文后，在与该HTTP请求报文相对应的长连接断开前，还包含如下步骤：

HTTP服务器获知无后续数据需要推送时，使用所述长连接发送HTTP响应报文，在该HTTP响应报文中设置如下状态码：用于标识无后续数据需要推送的状态码。

此外，所述用于标识有后续数据需要推送的状态码为：100continue。

本申请还公开了一种HTTP报文处理方法，该方法包括：

HTTP客户端构造包含用于标识支持服务端推模式的Expect头部字段的HTTP请求报文，并发送该HTTP请求报文；

在与该HTTP请求报文相对应的长连接断开前，HTTP客户端重复执行如下处理：

通过所述长连接接收HTTP响应报文。

此外，通过所述长连接接收到HTTP响应报文后，HTTP客户端还执行如下处理：读取并判断所述HTTP响应报文中包含的状态码：

如果所述状态码是用于标识有后续数据需要推送的状态码，则保持所述长连接的连接状态；和/或

如果所述状态码是用于标识无后续数据需要推送的状态码，则断开所述长连接。

本申请还公开了一种HTTP服务器，该服务器中包括：

服务器端接收模块，用于接收包含用于标识支持服务端推模式的Expect头部字段的HTTP请求报文；

服务器端发送模块，用于在与所述HTTP请求报文相对应的长连接断开前，重复执行如下处理：当前有数据需要推送时，在HTTP响应报文中标识该数据的长度，并将该数据包含在该HTTP响应报文中，通过所述长连接发送该HTTP响应报文。

此外，当前有数据需要推送时，所述服务器端发送模块在包含所述数据的HTTP响应报文中设置如下状态码：

用于标识有后续数据需要推送的状态码；或

用于标识无后续数据需要推送的状态码。

此外，接收到所述HTTP请求报文后，在与该HTTP请求报文相对应的长连接断开前，所述服务器端发送模块还用于：获知无后续数据需要推送时，使用所述长连接发送HTTP响应报文，在该HTTP响应报文中设置如下状态码：用于标识无后续数据需要推送的状态码。

本申请还公开了一种HTTP客户端，该客户端中包括：

客户端发送模块，用于构造包含用于标识支持服务端推模式的Expect头部字段的HTTP请求报文，并发送该HTTP请求报文；

客户端接收模块，用于在与该HTTP请求报文相对应的长连接断开前，重复执行如下处理：通过所述长连接接收HTTP响应报文。

此外，通过所述长连接接收到HTTP响应报文后，所述客户端接收模块还执行如下处理：读取并判断所述HTTP响应报文中包含的状态码：

本申请还公开了一种HTTP报文处理系统，该系统中包括：HTTP服务器，HTTP客户端；其中：

HTTP服务器中包括：

HTTP客户端中包括：

与现有技术相比，本申请可以获得包括以下技术效果：

1、无需客户端发起轮询，在客户端没有发送请求报文的情况下即可发送响应报文，实现服务端推送，减少了请求报文的数量，且减少了客户端和服务器之间重新建立连接的次数，即节省了网络资源以及客户端及服务器的处理资源；

2、无需依赖浏览器对内联框架(iframe)的支持，在协议层面实现了服务端推送，扩大了服务端推送的应用范围；

3、无需对客户端和服务器进行大规模升级，将协议从HTTP 1.1升级到HTTP 2.0，降低了服务端推送的实施成本，且在实现服务端推送时无需建立新的HTTP流，节省了客户端和服务器的处理资源；

4、无需解决请求/响应报文的同步问题即可实现应用层广播，降低了应用层广播的实施难度，扩大了应用层广播的应用范围。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有技术效果。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是现有技术中标准的HTTP报文交互流程示意图；

图2是现有技术中采用长轮询方式实现Comet技术的方法的方法流程图；

图3是现有技术中采用基于iframe的流方式实现Comet技术的方法的方法流程图；

图4是现有技术中基于HTTP 2.0的服务端推送方法的方法流程图；

图5是本申请实施例的一种HTTP报文处理方法的方法流程图；

图6是本申请实施例的另一种HTTP报文处理方法的方法流程图；

图7是本申请实施例的另一种HTTP报文处理方法的方法流程图；

图8是本申请实施例的另一种HTTP报文处理方法的方法流程图；

图9是本申请实施例的另一种HTTP报文处理方法的方法流程图；

图10是本申请实施例的另一种HTTP报文处理方法的方法流程图；

图11是本申请实施例的HTTP服务器的结构图；

图12是本申请实施例的HTTP客户端的结构图；

图13是本申请实施例的HTTP报文处理系统的结构图。

具体实施方式

以下将配合附图及实施例来详细说明本申请的实施方式，藉此对本申请如何应用技术手段来解决技术问题并达成技术功效的实现过程能充分理解并据以实施。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

实施例描述

下面以一实施例对本申请方法的实现作进一步说明。如图5所示，为本申请实施例的一种HTTP报文处理方法的方法流程图；本流程中描述了HTTP客户端构造HTTP请求报文并发送的过程；该方法包括：

步骤S500：HTTP客户端构造包含用于标识其支持服务端推模式的Expect头部字段(简称Expect字段)的HTTP请求报文，并发送该HTTP请求报文；

HTTP1.1(RFC 2616)中对Expect字段的定义如下：

Expect＝"Expect"":"1#expectation

expectation＝"100-continue"|expectation-extension

expectation-extension＝token["＝"(token|quoted-string)

*expect-params]

expect-params＝"；"token["＝"(token|quoted-string)]

本步骤中根据HTTP 1.1的标准要求对Expect字段进行扩展，新增一种场景定义，即新增一种Expect字段的字段值用于标识客户端支持服务端推模式。

本步骤中使用Expect字段的扩展字段值，即expectation-extension值来标识客户端支持服务端推模式。例如：令expectation-extension＝"broadcast"，用于标识客户端支持服务端推模式，从而区别于现有的HTTP客户端使用的Expect字段值(100-continue)。经过上述扩展后，请求报文的头部可以包含如下字段：

Expect:"broadcast"

需要注意的是，"broadcast"只是用于标识HTTP客户端支持服务端推模式的Expect字段的扩展字段值的一种示例。本领域技术人员可以理解，将Expect字段设置成其它与现有技术中的Expect字段值不同的值同样可以达到相同的效果。例如，可以将Expect字段的扩展字段值设置为"serverpush"，同样可以实现本发明。

步骤S502：在与上述HTTP请求报文相对应的长连接断开前，HTTP客户端重复执行如下处理：

通过该长连接接收HTTP响应报文。

下面以第二实施例对本申请方法的实现作进一步说明。如图6所示，为本申请实施例的另一种HTTP报文处理方法的方法流程图；本流程中描述了HTTP服务器构造HTTP响应报文并发送的过程；该方法包括：

步骤S600：接收到包含用于标识支持服务端推模式的Expect头部字段的HTTP请求报文后，在与该HTTP请求报文相对应的长连接断开前，HTTP服务器重复执行如下处理：

下面以第三实施例对本申请方法的实现作进一步说明。如图7所示，为本申请实施例的另一种HTTP报文处理方法的方法流程图；本流程中描述了HTTP客户端和HTTP服务器之间实现服务端推送的报文交互过程；该方法包括：

步骤S700：HTTP客户端(简称客户端)构造包含用于标识其支持服务端推模式的Expect字段(可以称为：推模式Expect字段)的HTTP请求报文(简称请求报文)，并将该请求报文发送至HTTP服务器(简称服务器)；

例如，上述请求报文中包含如下头部字段：

Expect:"broadcast"

此外，上述请求报文可以是：GET请求报文，POST请求报文，HEAD请求报文等。

例如，采用GET请求时，请求报文中可以包含如下行：

GET http://172.16.0.1:8083/index.html HTTP/1.1\r\n

Host:172.16.0.1:8083\r\n

Expect:broadcast

Accept:*/*\r\n

User-Agent:TheProxy/1.1.2\r\n

其中，第1行为请求行(request line)，其中包含了请求方法(GET)，请求的URL(Uniform Resource Locator，统一资源定位符)，协议版本信息。

后续各行分别为不同的报文头字段，各报文头字段由字段名称及相应的字段值构成。例如，用于标识所请求的主机的Host字段，用于标识客户端可识别的内容类型的Accept字段，用于标识浏览器类型的User-Agent字段，以及用于标识支持服务端推模式的Expect字段。

与HTTP 1.0不同，HTTP 1.1在默认情况下所有的连接都将被保持，即默认情况下所有的连接都是长连接，无需在报文头部用字段“Connection:Keep-Alive”显示地标识对应的连接是长连接。

步骤S702：接收到包含推模式Expect字段的请求报文后，服务器识别出该字段，当有数据需要推送时，使用HTTP响应报文(简称响应报文)中的Content-Length字段标识推送数据的长度，并将推送数据包含在该响应报文的响应主体中，向客户端发送该响应报文；

此外，服务器可以在上述响应报文中使用状态码100continue，用于标识服务端推送服务未结束(即用于标识有后续数据需要推送)，需要客户端保持服务端推送服务。当然，除了使用100continue以外，也可以使用其它的状态码来标识服务端推送服务未结束(即有后续数据需要推送)。

例如，HTTP响应报文可以包含如下各行：

HTTP/1.1 100continue\r\n

Cache-Control:public\r\n

Date:Sat,31 Aug 2014 00:24:08 GMT\r\n

Content-Length:21\r\n

\r\n

Push-Data-from-Server

其中，第1行为状态行(status line)，其中包含了协议版本信息，以及状态码(100continue)；

后续第2～4行分别为不同的报文头字段。例如，用于标识缓存策略的Cache-Control字段，用于标识日期时间的Date字段，以及用于标识数据长度的Content-Length字段。

第5行为空行，在该空行之后为响应报文的响应主体，其中包含推送数据(“Push-Data-from-Server”)。

除了用于标识服务端推送服务未结束(即有后续数据需要推送)的状态码以外，服务器还可以使用其它状态码来标识服务端推送服务结束(即无后续数据需要推送，包括服务端推送服务正常结束和服务端推送服务异常结束)，例如：

(1)用于标识服务端推送服务正常结束的状态码，例如，200OK

如果没有后续数据需要推送，但当前还有数据需要推送，则可以在长连接断开前将该数据包含在响应报文中，并使用200OK作为响应报文的状态码，将响应报文发送给客户端。

(2)用于标识服务端推送服务异常结束的状态码，例如，404 Not Found

当服务器发生异常，或生成推送数据的应用发生异常，但当前还有数据需要推送，则可以在长连接断开前将该数据包含在响应报文中，并使用404 Not Found(表明请求资源不存在)作为响应报文的状态码，将响应报文发送给客户端。

除了404 Not Found以外，上述用于标识服务端推送服务异常结束的状态码还可以是：用于标识服务器发生不可预期的错误的状态码500 Internal Server Error，或用于标识服务器当前不能处理客户端的请求的状态码503 Server Unavailable等。

步骤S704：接收到服务器发送的响应报文后，客户端提取并处理响应主体中包含的推送数据；

此外，客户端可以根据响应报文中的状态码100continue获知推送服务未结束，后续仍将继续进行数据的推送，因此继续保持当前的长连接的连接状态，等待服务器后续发送的数据推送报文。

此后，当服务器再次有数据需要推送时，服务器和客户端重复执行步骤S702和S704，直至长连接断开。

步骤S706：断开客户端和服务器之间的长连接；

长连接断开通常发生在以下两种情况下：

1、服务器结束当前的服务端推送服务；

服务器可以在两种情况下结束当前的服务端推送服务：

(1)服务端推送服务正常结束

当没有后续数据需要推送时，服务器可以向客户端返回包含用于标识服务端推送服务正常结束的状态码的响应报文。

上述用于标识服务端推送服务正常结束的状态码可以是：200OK。

(2)服务端推送服务异常结束

当服务器发生异常，或生成推送数据的应用发生异常时，服务器可以向客户端返回包含用于标识服务端推送服务异常结束的状态码的HTTP响应报文。

上述用于标识服务端推送服务异常结束的状态码可以是：用于标识请求资源不存在的状态码404 Not Found，或用于标识服务器发生不可预期的错误的状态码500Internal Server Error，或用于标识服务器当前不能处理客户端的请求的状态码503Server Unavailable等。

服务端推送服务结束后，客户端和服务器都可以主动断开对应的长连接。

2、长连接超时

根据HTTP 1.1的规定，通常长连接的超时时间由客户端和服务器设置，选择两者中的最小值。不同的服务器可能会设置不同的默认连接超时时间。例如：在Apache HTTPServer(一种HTTP服务器软件)2.0版本中默认的连接超时时间是15秒，而2.2版本中默认的连接超时时间是5秒。

当长连接超时时，服务器会主动断开当前的长连接。

长连接断开后，客户端可以根据应用层业务要求，再次执行步骤S700，或者终止服务端推送服务的接收；

例如，如果先前的服务端推送服务是正常结束(接收到包含200OK状态码的响应报文)，客户端可以不再发起新的长连接，终止服务端推送服务的接收；如果先前的服务端推送服务是异常结束(接收到包含404 Not Found状态码的响应报文)，客户端可以在等待预先设定的时间后再次执行步骤S700；如果先前的服务端推送服务是由于长连接超时结束，客户端可以立即执行步骤S700。

下面以第四实施例对本申请方法的实现作进一步说明。如图8所示，为本申请实施例的另一种HTTP报文处理方法的方法流程图；本流程中将对HTTP客户端请求及接收服务端推送服务的过程进行详细描述；该方法包括：

步骤S800：HTTP客户端(简称客户端)构造包含用于标识其支持服务端推模式的Expect字段的HTTP请求报文(简称请求报文)；

例如，在请求报文中设置如下Expect字段：Expect:"broadcast"。

步骤S802：客户端发送上述请求报文，并在本地将该请求报文对应的长连接的状态标识为推模式状态；

客户端可以在本地使用变量来进行上述状态的标识，例如将变量bPush的值设置为1(TRUE)表示对应的长连接的状态为推模式状态。

步骤S804：客户端接收HTTP服务器(简称服务器)发送的HTTP响应报文(简称响应报文)。

步骤S806：客户端判断当前的长连接是否为推模式状态；如果不是推模式状态，则执行现有的HTTP 1.1的相应处理流程，即依照HTTP 1.1规范的规定将与上述响应报文对应的报文主体发送给服务器；如果是推模式状态，则执行下一步。

步骤S808：解析接收到的响应报文的状态码：

如果状态码是用于标识推送服务未结束(即有后续数据需要推送)的状态码，例如，100continue，则执行下一步；

如果状态码是用于标识服务端推送服务结束(即无后续数据需要推送)的状态码：例如，200OK，或404 Not Found，则跳转至步骤S814；

如果状态码为其它状态码，则执行现有的HTTP 1.1的相应处理流程，即按照HTTP1.1规范解析当前的状态码，并交由上层应用程序处理，跳转至步骤S814。

步骤S810：解析响应报文主体中包含的推送数据，将推送数据交由上层应用程序处理，并且保持该长连接的连接状态。

步骤S812：判断长连接是否已超时，如果未超时，则跳转至步骤S804；如果已超时，则执行下一步。

步骤S814：断开当前的长连接，本流程结束。

下面以第五实施例对本申请方法的实现作进一步说明。如图9所示，为本申请实施例的另一种HTTP报文处理方法的方法流程图；本流程中将对HTTP服务器向HTTP客户端提供服务端推送服务的方法进行详细描述；该方法包括：

步骤S900：HTTP服务器(简称服务器)接收HTTP客户端(简称客户端)发送的HTTP请求报文(简称请求报文)。

步骤S902：判断接收到的请求报文的头部是否包含用于标识客户端支持服务端推模式的Expect字段(例如，Expect:"broadcast")：

如果包含，则执行下一步；

否则，执行HTTP 1.1现有规范所规定的处理流程，并跳转至步骤S900。

步骤S904：服务器在本地将当前的长连接的状态标识为推模式状态，并保持当前的长连接的连接状态；

服务器可以在本地使用变量来进行上述状态的标识，例如将变量bPush的值设置为1(TRUE)表示当前的长连接的状态为推模式状态。

步骤S906：服务器获取上层应用程序生成的数据，并计算数据长度L。

步骤S908：判断当前的长连接是否为推模式状态：

如果是，则执行下一步；

步骤S910：判断是否会有后续数据需要推送：如果是，则执行下一步；否则，跳转至步骤S914；

生成推送数据的上层应用程序可以通过变量来标识是否还会生成新的数据。

步骤S912：构造HTTP响应报文(简称响应报文)，将该响应报文的状态码设置为用于标识推送服务未结束的状态码，例如，100continue，将该响应报文的Content-Length字段值设置为L，发送该响应报文，跳转至步骤S916。

步骤S914：构造响应报文，将该响应报文的状态码设置为用于标识服务端推送服务结束(即无后续数据需要推送)的状态码，例如，200OK，或404 Not Found，将该响应报文的Content-Length字段值设置为L，发送该报文。

步骤S916：判断当前长连接是否已超时：如果未超时，则跳转至步骤S906；如果已超时，则执行下一步。

步骤S918：断开当前长连接，本流程结束。

下面以第六实施例对本申请方法的实现作进一步说明。如图10所示，为本申请实施例的另一种HTTP报文处理方法的方法流程图；本流程中描述了利用本发明的服务端推送方法实现应用层广播的具体方法；该方法包括：

步骤S1000：HTTP服务器(简称服务器)获取上层应用程序生成的需要进行广播的数据，并计算数据长度L。

步骤S1002：服务器构造HTTP响应报文(简称响应报文)，将该响应报文的状态码设置为用于标识推送服务未结束的状态码，例如，100continue，将该响应报文的Content-Length字段值设置为L。

步骤S1004：服务器获取当前已标识为推模式状态的所有长连接，即获取所有包含推模式Expect字段(例如，包含“Expect:"broadcast"”)的请求报文所对应的当前未断开的长连接；

在本实施例中，Expect:"broadcast"字段除了用于标识客户端支持推模式外，还可以用于标识其有能力处理广播数据。

步骤S1006：HTTP服务器依次通过上述各长连接发送上述HTTP响应报文。

由上可知，由于现有网络架构下的组播/广播是基于IP层面实现的业务，即需要通过定义一组组播/广播IP地址，服务器将组播/广播包的目的IP地址设置为该IP地址，由中间路由器复制组播/广播包实现组播/广播业务。但是在应用层，如果采用现有的请求/响应模式，需要解决请求/响应报文的同步问题，很难实现应用层广播/组播。而采用本发明的服务端推送技术，HTTP服务器可以以广播的方式将信息/数据主动推送到与其已经建立长连接的所有HTTP客户端，实现了应用层广播/组播业务。

下面以另一实施例对本申请装置的实现作进一步说明。如图11所示，为本申请实施例的HTTP服务器的结构图，所述HTTP服务器包括：服务器端接收模块1100、服务器端发送模块1102；其中：

用于标识有后续数据需要推送的状态码；或

用于标识无后续数据需要推送的状态码。

所述用于标识支持服务端推模式的Expect头部字段中包含：用于标识支持服务端推模式的expectation-extension值。

所述用于标识有后续数据需要推送的状态码为：100continue。

所述HTTP服务器与前述的方法流程描述对应，更具体的描述请参考上述方法流程的叙述，不再一一赘述。

下面以另一实施例对本申请装置的实现作进一步说明。如图12所示，为本申请实施例的HTTP客户端的结构图，所述HTTP客户端包括：客户端发送模块1200、客户端接收模块1202；其中：

所述用于标识有后续数据需要推送的状态码为：100continue。

所述HTTP客户端与前述的方法流程描述对应，更具体的描述请参考上述方法流程的叙述，不再一一赘述。

下面以另一实施例对本申请系统的实现作进一步说明。如图13所示，为本申请实施例的HTTP报文处理系统的结构图，所述HTTP报文处理系统包括：HTTP客户端130，HTTP服务器132；其中：

HTTP客户端中包括：客户端发送模块1200，客户端接收模块1202；

HTTP服务器中包括：服务器端接收模块1100、服务器端发送模块1102；

所述系统与前述的方法流程描述对应，更具体的描述请参考上述方法流程的叙述，不再一一赘述。

上述说明示出并描述了本申请的若干优选实施例，但如前所述，应当理解本申请并非局限于本文所披露的形式，不应看作是对其他实施例的排除，而可用于各种其他组合、修改和环境，并能够在本文所述发明构想范围内，通过上述教导或相关领域的技术或知识进行改动。而本领域人员所进行的改动和变化不脱离本申请的精神和范围，则都应在本申请所附权利要求的保护范围内。

Claims

1.一种HTTP报文处理方法，其特征在于，该方法包括：

当前有数据需要推送时，在包含所述数据的HTTP响应报文中设置如下状态码：用于标识有后续数据需要推送的状态码；或用于标识无后续数据需要推送的状态码，在HTTP响应报文中标识该数据的长度，并将该数据包含在该HTTP响应报文中，通过所述长连接发送该HTTP响应报文。

2.根据权利要求1所述的方法，其特征在于，

3.根据权利要求1所述的方法，其特征在于，接收到所述HTTP请求报文后，在与该HTTP请求报文相对应的长连接断开前，还包含如下步骤：

4.根据权利要求1所述的方法，其特征在于，

所述用于标识有后续数据需要推送的状态码为：100continue。

5.一种HTTP报文处理方法，其特征在于，该方法包括：

通过所述长连接接收HTTP响应报文；

通过所述长连接接收到HTTP响应报文后，HTTP客户端还执行如下处理：读取并判断所述HTTP响应报文中包含的状态码：

6.根据权利要求5所述的方法，其特征在于，

7.根据权利要求5所述的方法，其特征在于，

所述用于标识有后续数据需要推送的状态码为：100continue。

8.一种HTTP服务器，其特征在于，该服务器中包括：

服务器端发送模块，用于在与所述HTTP请求报文相对应的长连接断开前，重复执行如下处理：当前有数据需要推送时，在包含所述数据的HTTP响应报文中设置如下状态码：用于标识有后续数据需要推送的状态码；或用于标识无后续数据需要推送的状态码，在HTTP响应报文中标识该数据的长度，并将该数据包含在该HTTP响应报文中，通过所述长连接发送该HTTP响应报文。

9.根据权利要求8所述的服务器，其特征在于，

10.根据权利要求8所述的服务器，其特征在于，

接收到所述HTTP请求报文后，在与该HTTP请求报文相对应的长连接断开前，所述服务器端发送模块还用于：获知无后续数据需要推送时，使用所述长连接发送HTTP响应报文，在该HTTP响应报文中设置如下状态码：用于标识无后续数据需要推送的状态码。

11.根据权利要求8所述的服务器，其特征在于，

所述用于标识有后续数据需要推送的状态码为：100continue。

12.一种HTTP客户端，其特征在于，该客户端中包括：

客户端接收模块，用于在与该HTTP请求报文相对应的长连接断开前，重复执行如下处理：通过所述长连接接收HTTP响应报文；

所述客户端接收模块在通过所述长连接接收到HTTP响应报文后，还执行如下处理：读取并判断所述HTTP响应报文中包含的状态码：如果所述状态码是用于标识有后续数据需要推送的状态码，则保持所述长连接的连接状态；和/或如果所述状态码是用于标识无后续数据需要推送的状态码，则断开所述长连接。

13.根据权利要求12所述的客户端，其特征在于，

14.根据权利要求12所述的客户端，其特征在于，

所述用于标识有后续数据需要推送的状态码为：100continue。

15.一种HTTP报文处理系统，其特征在于，该系统中包括：

如权利要求8所述的HTTP服务器，以及如权利要求12所述的HTTP客户端。