CN107615257B - 通信设备、通信方法及存储介质 - Google Patents

Abstract

一种通信设备，其通过使用与发送设备之间的逻辑连接来从所述发送设备接收内容中所包括的数据，所述通信设备包括：通知单元，其被配置为向所述发送设备通知与所述通信设备许可使用所述逻辑连接进行从所述发送设备到所述通信设备的数据发送的数据量有关的信息；接收单元，其被配置为接收响应于所述通知单元所进行的通知而从所述发送设备发送来的内容中所包括的数据；以及控制单元，其被配置为进行控制，以使得在所述内容中所包括的数据中未被所述接收单元接收到的数据量小于预定值的情况下，禁止所述通知单元所进行的通知，直到所述逻辑连接断开为止。

Description

通信设备、通信方法及存储介质

技术领域

本发明涉及一种用于使用逻辑连接的通信的通信方法。

背景技术

HTTP(超文本传输协议)是被广泛用作因特网标准技术的OSI参考模型的应用层中的协议(或通信协议)之一。作为HTTP的新版本，因特网标准化组织(IETF：因特网工程任务组)已经开发了HTTP/2标准。HTTP/2标准规定了使用HTTP消息的流控制的机制。流控制用于防止通信设备不能接收量超过接收缓冲器的容量的全部数据。过去，流控制由作为传输层中的协议的TCP(传输控制协议)功能来执行(参见专利文献1)。另一方面，根据HTTP/2的流控制通过使用作为控制帧之一的WINDOW_UPDATE(窗_更新)帧来控制数据的发送和接收。接收侧通信设备控制用于表示接收缓冲器中可存储的数据量的窗大小，并且利用WINDOW_UPDATE帧将由于接收缓冲器内的数据的处理而造成的窗大小的增加量发送至发送侧通信设备。发送侧通信设备被许可将通过WINDOW_UPDATE帧所通知的数据量重新发送至接收侧通信设备。通常，在HTTP/2通信中，每当窗大小由于通信设备所进行的DATA(数据)帧的接收处理而改变时，进行WINDOW_UPDATE帧的接收。

然而，存在如下问题：接收侧通信设备许可发送侧通信设备发送的数据量的频繁通知可能导致接收侧通信设备中的处理负荷高。

引用列表

专利文献

专利文献1：日本特开2009-71766

发明内容

本发明提供一种通信设备，其通过使用与发送设备之间的逻辑连接来从所述发送设备接收内容中所包括的数据，所述通信设备包括：通知单元，其被配置为向所述发送设备通知与所述通信设备许可使用所述逻辑连接进行从所述发送设备到所述通信设备的数据发送的数据量有关的信息；接收单元，其被配置为接收响应于所述通知单元所进行的通知而从所述发送设备发送来的所述内容中所包括的数据；以及控制单元，其被配置为进行控制，以使得：在所述内容所包括的数据中未被所述接收单元接收到的数据量小于预定值的情况下，禁止所述通知单元所进行的通知，直到所述逻辑连接断开为止。

根据以下参考附图对典型实施例的说明，本发明的其它特征将变得显而易见。

附图说明

图1示出根据典型实施例的通信系统的结构示例。

图2是示出根据典型实施例的第二通信设备20的硬件结构示例的框图。

图3是示出根据典型实施例的第二通信设备20的功能模块结构示例的框图。

图4是用于说明根据第一典型实施例的、在第二通信设备20响应于流中的最后数据接收而不发送流所用的WINDOW_UPDATE帧的情况下所要进行的系统操作的序列图。

图5是用于说明根据典型实施例的与第二通信设备20和第一通信设备10之间的HTTP通信连接有关的操作的序列图。

图6是用于说明根据第一典型实施例的、在第二通信设备20响应于连接中的最后数据接收而不发送连接所用的WINDOW_UPDATE帧的情况下所要进行的系统操作的序列图。

图7是用于说明根据第一典型实施例的第二通信设备20所进行的与WINDOW_UPDATE帧的发送判断有关的操作的流程图。

图8是用于说明根据第二典型实施例的、在第二通信设备20基于Content-Length(内容_长度)和WindowSize(窗大小)来判断WINDOW_UPDATE帧的发送的情况下所要进行的系统操作的序列图。

图9是用于说明根据第二典型实施例的第二通信设备20所进行的与WINDOW_UPDATE帧的发送判断有关的操作的流程图。

图10是用于说明根据第三典型实施例的、在第一通信设备10基于Content-Length来判断WINDOW_UPDATE帧中所要通知的数据量的情况下所要进行的系统操作的序列图。

具体实施方式

以下将参考附图说明本发明的典型实施例。应当理解，以下典型实施例不意图在限制要求保护的发明，并且根据以下典型实施例的特征的所有组合不是本发明所必需的。

第一实施例

系统结构

图1示出通信系统的结构示例。该通信系统包括通过基于IEEE 802.11的无线LAN(局域网)而连接的第一通信设备10(以下称为通信设备10)和第二通信设备20(以下称为通信设备20)。

通信设备10是用作客户端的通信设备，并且使用与通信设备20的逻辑连接(诸如后述的连接和流等)来发送或接收内容(诸如文本、图像和运动图像等)中所包括的数据。通信设备20是用作服务器的通信设备，并且使用与通信设备10之间的逻辑连接来发送或接收内容中所包括的数据。通信设备10和通信设备20的具体示例可以包括数字照相机、数字摄像机、网络照相机、打印机、数字多功能外围设备、数字电视、投影仪、蜂窝电话、智能电话、PC和服务器设备。根据通信的详情，通信设备10和通信设备20中的一个用作数据发送设备，而另一个用作数据接收设备。

例如，在通信设备10是打印机并且通信设备20是服务器设备的情况下，用户可以操作打印机的控制面板以从服务器设备所存储的图像中选择要打印的图像。在选择图像时，打印机请求服务器设备发送图像的数据，并且通过使用逻辑连接来接收并打印图像数据。在这种情况下，作为服务器设备的通信设备20用作数据发送设备，并且作为打印机的通信设备10用作数据接收设备。例如，在通信设备10是数字照相机并且通信设备20是服务器设备的情况下，用户可以从照相机所存储的图像中选择要上传至服务器设备的图像。在选择图像时，数字照相机通过使用逻辑连接来将图像数据发送至服务器设备。在这种情况下，作为数字照相机的通信设备10用作数据发送设备，并且作为服务器设备的通信设备20用作数据接收设备。

说明了根据本典型实施例在通信设备10和通信设备20之间直接建立无线LAN连接，但本发明的方面不限于此。该连接可以是经由外部无线接入点而建立的。本发明的方面不限于无线LAN通信功能，而是可以使用例如蓝牙(Bluetooth，注册商标)、ZigBee(注册商标)或RFID的无线通信功能。可选地，可以使用诸如以太网(Ethernet，注册商标)等的有线LAN通信功能或者无线LAN通信功能和有线LAN通信功能的组合。在使用有线LAN连接的情况下，可以经由诸如网络交换机和路由器等的中继装置来建立连接。根据本典型实施例，通信设备10和通信设备20通过一个LAN而连接，但是本发明的方面不限于此。可以经由例如WAN(广域网)、因特网或蜂窝电话所用的公共无线线路建立连接。

接着，将详细说明通信设备的组件。图2是示出通信设备20的硬件结构示例的框图。这里应当理解，通信设备10和通信设备20两者具有相同的结构。根据本典型实施例，通信设备10使用POST(发送)方法来将数据上传至通信设备20。因此，将主要说明执行流控制的通信设备20。通信设备20包括CPU 201、ROM 202、RAM 203、辅助存储器装置204、显示单元205、操作单元206、无线通信单元207和天线208。

一般地，CPU 201控制通信设备20。ROM 202存储不需要改变的程序和参数。RAM203临时存储例如要从辅助存储器装置204供给的程序和数据。辅助存储器装置204存储图像内容和运动图片内容的数据。显示单元205显示用户可用来操作通信设备20的GUI(图形用户界面)。操作单元206是用户可用来操作通信设备20的输入接口。无线通信单元207控制天线208以建立与通信设备10的无线LAN通信。在通信设备10和通信设备20经由外部无线接入点(未示出)而连接的情况下，无线通信单元207控制天线208以建立与无线接入点的无线LAN通信。尽管根据本典型实施例、显示单元205和操作单元206被设置在通信设备20内，但显示单元205和操作单元206至少之一可以作为单独的装置被设置到通信设备20。

功能模块结构

图3是示出通信设备20的功能模块结构示例的框图。应当理解，通信设备10和通信设备20具有相同的结构。通信设备20包括控制单元301、无线LAN通信控制单元302(以下称为无线控制单元302)、显示控制单元303、操作控制单元304、存储控制单元305以及TCP/IP通信控制单元306(以下为TCP控制单元306)。通信设备20还包括HTTP通信控制单元307(以下称为HTTP控制单元307)、WINDOW_UPDATE发送判断单元308(以下称为UPDATE(更新)判断单元308)以及GOAWAY(超时)判断单元309。通信设备20还包括最终DATA帧判断单元310(以下称为最终判断单元310)、WindowSize判断单元311(以下称为Size(大小)判断单元311)以及Content-Length获取单元312(以下为Length(长度)获取单元312)。这些模块各自通过基于后述的流程图而进行的处理来实现，在ROM 202中所存储的相应程序中进行说明，解压缩到RAM 203中，并且由CPU 201来执行。例如，在作为使用CPU 201的软件处理的替代而进行硬件的处理的情况下，可以设置与如上所述的模块的处理相对应的计算单元和电路。应当理解，通信设备20不必需要所有的模块。

控制单元301控制通信设备20中所包括的功能模块。无线控制单元302控制无线通信单元207以控制与通信设备10的无线LAN通信。在通信设备10和通信设备20经由外部无线接入点而连接的情况下，无线控制单元302控制无线通信单元207以控制与无线接入点(未示出)的无线LAN通信。显示控制单元303控制显示单元205以进行通信设备20中的GUI的显示控制。操作控制单元304控制操作单元206以控制从用户向通信设备20的操作输入。存储控制单元305控制RAM 203和辅助存储器装置204以存储或删除例如处理数据、图像内容或运动图片内容的数据。

TCP控制单元306使用无线控制单元302来与通信设备10进行基于TCP/IP(因特网协议)的通信控制。根据本典型实施例，应用TCP/IP通信。然而，本发明的方面不限于此，而可以进行基于诸如UDP(用户数据报协议)等的其它协议的通信。HTTP控制单元307使用TCP控制单元306来与通信设备10进行基于HTTP/2的通信控制。HTTP控制单元307与通信设备10之间还支持基于应用TLS(传输层安全)的HTTPS(HTTP安全)的通信控制。然而，HTTP控制单元307可以进行基于其它方式(诸如SPDY等)的通信控制。

支持HTTP/2通信的通信设备与通信设备之间建立OSI参考模型的传输层中的连接(逻辑第一连接)。这样的通信设备可以进一步基于该连接来建立多个流(逻辑第二连接)，以在各流中按照独立的序列来进行通信。流建立是通过使用流所基于的连接从通信设备向另一通信设备发送用于指定所要建立的流的ID的HEADERS(头部)帧来实现的。使用该连接所要发送的消息具有所设置的流ID，由此可以识别在用于发送该消息的连接中所要使用的流。将基于HTTP/2在通信设备之间交换具有被称为帧的形式的消息。帧的具体示例可以包括包含控制信息的HEADERS帧和WINDOW_UPDATE帧以及包含内容中所包括的部分或全部数据(有效载荷数据)的DATA帧。例如，通信设备20可以使用除连接和流以外的逻辑连接来基于除HTTP/2以外的协议进行通信。

UPDATE判断单元308判断是否要发送连接用WINDOW_UPDATE帧和流用WINDOW_UPDATE帧。该判断可以使用GOAWAY判断单元309、最终判断单元310、Size判断单元311和Length获取单元312至少之一。

如果判断为发送WINDOW_UPDATE，则UPDATE判断单元308使用HTTP控制单元307来向通信设备10发送WINDOW_UPDATE帧。通信设备20使用流用WINDOW_UPDATE帧来向通信设备10通知与通信设备20许可使用流进行从通信设备10到通信设备20的数据发送的数据量有关的信息(第一信息)。连接用WINDOW_UPDATE帧可以用于通知与通信设备20许可使用基于连接的一个或多个流的进行从通信设备10到通信设备20的数据发送的数据量有关的信息(第二信息)。通信设备10响应于该通知，向通信设备20发送与上限等于如下值的量有关的有效载荷数据，其中该值是基于与WINDOW_UPDATE帧中所描述的数据量有关的参数的。例如针对基于除HTTP/2以外的协议的通信，通信设备20可以在除WINDOW_UPDATE帧以外的消息中通知与数据量有关的信息。

通信设备20使用作为如上所述的控制帧之一的WINDOW_UPDATE帧来进行流控制，其中该流控制包括管理针对连接和流的来自通信设备10的数据发送。更具体地，通信设备20管理被定义为与连接和流相对应的接收缓冲器的空闲空间的WindowSize(窗大小)。在使用流的数据接收导致接收缓冲器中的空闲空间减少的情况下，通信设备20使与流相对应的WindowSize以及与流所基于的连接相对应的WindowSize减少。通信设备20通过发送WINDOW_UPDATE帧来向通信设备10通知由于数据接收处理而造成的接收缓冲器中的空闲空间的增加量，以增加WindowSize。根据本典型实施例的接收处理是指由通信设备20从通信设备10接收到并存储在RAM 203内的接收缓冲器中的数据在通过CPU 201处理之后从接收缓冲器移除。

换句话说，与流ID为1的流有关的WindowSize是通信设备20许可通信设备10使用ID为1的流发送数据的数据量。连接用WindowSize是通信设备20许可通信设备10使用基于连接的一个或多个流发送数据的数据量。通信设备10通过使用流来将具有比流用WindowSize和连接用WindowSize小的量的有效载荷数据发送至通信设备20。然而，例如，在通信设备20的一些资源状况和通信路径的一些状况中，通信设备20许可使用逻辑连接进行从通信设备10到通信设备20的数据发送的数据量和接收缓冲器的空闲空间可以不同。

GOAWAY判断单元309判断HTTP控制单元307是否从通信设备10接收到GOAWAY帧，并且判断是否向通信设备10发送了GOAWAY帧。HTTP/2中所规定的GOAWAY帧是用于描述通信设备将不建立基于GOAWAY帧的发送所使用的连接的新流的信息。通信设备10和通信设备20可以通知：例如在基于除HTTP/2以外的协议来实现通信的情况下，通过使用除GOAWAY帧以外的消息将不会建立新流。

最终判断单元310判断由HTTP控制单元307通过使用流而从通信设备10接收到的DATA帧是否是该流中的最终DATA帧。在DATA帧的帧头部中的END_STREAM(结束_流)标志有效(值为1)的情况下，最终判断单元310判断为该DATA帧是流中的最终DATA帧。根据本典型实施例，流中的最终DATA帧是要使用该流从通信设备10发送至通信设备20的最后DATA帧。例如，通信设备20可以基于诸如HEADERS帧中所描述的信息等的除END_STREAM标志以外的信息来判断哪个帧是最终DATA帧。

Size判断单元311确定连接用WINDOW_UPDATE帧和流用WINDOW_UPDATE帧中所述的连接用WindowSize和流用WindowSize的增加量。以下将说明增加量的确定方法。

如果HTTP控制单元307接收到HEADERS帧，则Length获取单元312判断HEADERS帧的头部块片段中是否设置有Content-Length字段。如果是，则Length获取单元312从HEADERS帧获取Content-Length值。Content-Length表示在设置有Content-Length的HEADERS帧之后要发送的内容的数据量(有效载荷数据的大小)。例如在预先已知向通信设备10所请求的数据的大小的情况下，通信设备20基于除Content-Length以外的信息来判断内容的数据量。

通信序列(1)

以下将详细说明根据本典型实施例的通信设备10和通信设备20之间的通信序列。图4是用于说明根据本典型实施例的、在通信设备20响应于流中的最后数据接收而不发送流用WINDOW_UPDATE帧的情况下的系统操作的序列图。参考图4，例如处理在向通信设备10输入用于与通信设备20进行通信的用户操作的时间点开始。然而，用于开始图4中的处理的时间不局限于该时间点。

在M401中，通信设备10建立与通信设备20的连接，以实现HTTP通信连接。以下将参考图5来说明通信连接的详细序列。本典型实施例假设：与和通信设备20之间的连接有关的InitialWindowSize(初始窗大小)是作为默认值的64KB，并且与随后要建立的流有关的InitialWindowSize也是作为默认值的64KB。参考图4，“ID_0”表示与连接有关的信息。

在M402中，通信设备10向通信设备20发送用于描述HTTP请求头部信息的HEADERS帧。在该序列中，假设HTTP请求应用POST方法，并且通信设备10向通信设备20发送96KB的有效载荷数据。响应于HEADERS帧的发送，通信设备10建立流ID为1的新流。在这种情况下，与通信设备20的连接(ID_0)有关的WindowSize是64KB，并且与流1(ID_1)有关的WindowSize是64KB。这表示通信设备10被许可发送直至64KB的DATA帧。根据本典型实施例，从通信设备10向通信设备20的请求使用指定了如上所述的POST方法的HEADERS帧。在不限于此的情况下，作为代替，可以使用诸如GET(获取)方法和PUT方法等的其它HTTP请求方法以及诸如CONTINUATION(继续)等的其它帧。

在M403中，通信设备10通过使用流1(ID_1)向通信设备20发送包括全部96KB的有效载荷数据中的64KB数据的DATA帧。由于该DATA帧不是流1中的最终DATA帧，因此END_STREAM标志无效(值为0)。在通信设备20接收到DATA帧时，与通信设备20的连接(ID_0)有关的WindowSize是0KB，并且与流1(ID_1)有关的WindowSize是0KB。这是因为通信设备20由于从通信设备10接收64KB的DATA帧因而消耗了接收缓冲器。

在M404中，通信设备20进行用于接收M403中所接收到的DATA帧的处理。在M405中，通信设备20向通信设备10发送与连接(ID_0)有关的64KB的WINDOW_UPDATE帧。作为发送WINDOW_UPDATE帧的结果，与通信设备20的连接(ID_0)有关的WindowSize等于64KB，而与流1(ID_1)有关的WindowSize仍然等于0KB。在M406中，通信设备20向通信设备10发送与流1(ID_1)有关的64KB的WINDOW_UPDATE帧。作为发送WINDOW_UPDATE帧的结果，与流1(ID_1)有关的WindowSize也等于64KB。

在M407中，通信设备10响应于通信设备20利用M405和M406中从通信设备20发送来的WINDOW_UPDATE帧而许可发送的数据量的通知来进行数据发送。然后，通信设备20中的HTTP控制单元307接收数据。更具体地，通信设备10通过使用流1(ID_1)向通信设备20发送包括全部96KB的有效载荷数据中的剩余32KB的数据的DATA帧。由于该DATA帧是流1中的最终DATA帧，因此END_STREAM标志有效(值为1)。在通信设备20接收到该DATA帧时，与通信设备20的连接(ID_0)有关的WindowSize等于32KB，并且与流1(ID_1)有关的WindowSize等于32KB。

在M408中，通信设备20进行用于接收M407中所接收到的DATA帧的处理。在M409中，判断通信设备20是否发送WINDOW_UPDATE帧。在构成所接收到的内容的数据中设置了表示构成通过使用逻辑连接所要发送的最后内容的数据的信息的情况下，通信设备20进行控制以在逻辑连接断开之前不执行通知。根据本典型实施例，通信设备20在M407中所接收到的DATA帧具有有效的END_STREAM标志。据此，通信设备20判断为该DATA帧是最终DATA帧并且流1以后将不会用于接收DATA帧。因此，通信设备20判断为没有必要许可通过使用流1来将数据发送至通信设备10，并且进行控制以防止发送与流1有关的WINDOW_UPDATE帧，直到流1断开为止。

在M410中，通信设备20向通信设备10发送与连接(ID_0)有关的32KB的WINDOW_UPDATE帧。在发送WINDOW_UPDATE帧时，与通信设备20的连接(ID_0)有关的WindowSize等于64KB。

在M411中，响应于M402中接收到的HTTP请求以及M403和M407中接收到的数据，通信设备20向通信设备10发送作为HTTP响应的HEADERS帧。根据本典型实施例，HTTP响应可以具有状态码“200OK”。通信设备20通过使用流1来发送HEADERS帧。根据本典型实施例，已经说明了用于如上所述描述“200OK”的HEADERS帧，但本发明的方面不限于此。作为代替，可以使用用于描述其它状态码的HEADERS帧以及诸如PUSH_PROMISE(推送_承诺)等的其它帧。在M412中，通信设备10在连接结束时向通信设备20发送作为用于描述此后将不建立新流的信息的GOAWAY帧。在M413中，通信设备10和通信设备20终止HTTP通信连接。更具体地，TCP连接断开。

HTTP通信连接序列

图5是用于描述与通信设备20和通信设备10之间的HTTP通信连接有关的操作、且示出图4中的M401的详情的序列图。

在M501中，通信设备10建立与通信设备20的TCP连接。对于HTTPS通信，在M502中，通信设备10建立与通信设备20的TLS(传输层安全)通信连接。在要建立TLS通信连接时，还基于ALPN(应用层协议协商)来进行用于开始HTTP/2通信的协商。另一方面，在不建立HTTPS通信时，在M503中，通信设备10向通信设备20发送HTTP/2升级请求。在M504中，通信设备20向通信设备10发送HTTP/2升级应答。在M502或M504之后，在通信设备10和通信设备20之间建立HTTP/2通信。

在M505中，通信设备10向通信设备20发送用于指定客户端连接序言的PRI方法的部分。在M506中，通信设备10向通信设备20发送与客户端连接序言的SETTINGS(设置)帧相对应的部分。在M507中，通信设备20向通信设备10发送服务器连接序言。服务器连接序言可以仅包括有可能为空的SETTINGS帧。

通信序列(2)

图6是用于说明根据本典型实施例的、在通信设备20响应于连接中的最后数据接收而不发送连接用WINDOW_UPDATE帧的情况下的系统操作的序列图。参考图6，例如处理在向通信设备10输入用于与通信设备20进行通信的用户操作的时间点开始。然而，用于开始图6中的处理的时间不局限于该时间点。在图4和图6中，相同的标记指代相同的部分，并且将省略重复说明。

M601～M606中的处理与M401～M406中的处理相同。在M607中，通信设备10向通信设备20发送作为用于描述此后将不建立新流的信息的GOAWAY帧。M608和M609中的处理与M407和M408中的处理相同。

在M610中，通信设备20判断是否要发送WINDOW_UPDATE帧。更具体地，通信设备20判断M608中接收到的DATA帧是否是最终DATA帧、以及流1之后是否将不会用于接收DATA帧。基于M607中的GOAWAY帧的接收，通信设备20判断为M608中所接收到的DATA帧也是连接中的最终DATA帧。换句话说，该DATA帧是要使用该连接从通信设备10发送至通信设备20的最后DATA帧。因此，通信设备20判断为不必许可通信设备10此后使用流1来发送数据，并且进行控制以使得禁止发送与流1有关的WINDOW_UPDATE帧，直到流1断开为止。通信设备20判断为不必许可通信设备10此后使用该连接来发送数据，并且进行控制以使得禁止发送与该连接有关的WINDOW_UPDATE帧，直到该连接断开为止。M611和M612中的处理与M411和M413中的处理相同。

WINDOW_UPDATE帧的发送判断流程

图7是用于说明根据本典型实施例的通信设备20所要进行的与WINDOW_UPDATE帧的发送判断有关的操作的流程图。参考图7，例如处理可以在通信设备20从通信设备10接收到一些帧的时间点开始。然而，用于开始图7中的处理的时间不局限于该时间点。

在S701中，HTTP控制单元307判断通过使用与通信设备10之间的流是否从该通信设备10接收到作为内容中所包括的数据的DATA帧。如果已接收到DATA帧(S701为“是”)，则处理进入S702。如果没有接收到DATA帧(S701为“否”)，则处理结束。在S702中，HTTP控制单元307进行DATA帧接收处理。在S703中，HTTP控制单元307判断是否已经完成DATA帧接收处理。如果已经完成DATA帧接收处理(S703为“是”)，则处理进入S704。如果没有完成DATA帧接收处理(S703为“否”)，则处理返回至S702。

在S704中，UPDATE判断单元308判断是否要发送流用WINDOW_UPDATE帧。如果所接收到的内容中所包括的数据具有表示通过使用逻辑连接所发送的最后内容中所包括的数据的信息的设置，则UPDATE判断单元308进行控制以使得禁止通知，直到逻辑连接断开为止。根据本典型实施例，UPDATE判断单元308使用最终判断单元310来判断所接收到的DATA帧的帧头部中的END_STREAM标志是否有效(值是否为1)。如果END_STREAM标志有效(S704为“是”)，则UPDATE判断单元308判断为不发送流用WINDOW_UPDATE帧，并且处理进入S706。另一方面，如果END_STREAM标志无效(S704中为“否”)，则处理进入S705。

在S705中，UPDATE判断单元308判断为向通信设备10发送与DATA帧接收所使用的流有关的WINDOW_UPDATE帧。然后，UPDATE判断单元308使用HTTP控制单元307来发送流用WINDOW_UPDATE帧。因此，向通信设备10通知与通信设备20许可使用流进行从通信设备10到通信设备20的数据发送的数据量有关的信息。

在S706中，UPDATE判断单元308判断HTTP控制单元307是否接收到来自通信设备10的GOAWAY帧，并且判断是否向通信设备10发送了GOAWAY帧。这些判断使用GOAWAY判断单元309。如果HTTP控制单元307未接收到或发送GOAWAY帧(S706中为“否”)，则处理进入S708。如果HTTP控制单元307接收到或发送了GOAWAY帧(S706中为“是”)，则处理进入S707。

在S707中，UPDATE判断单元308使用HTTP控制单元307来判断是否存在任何执行中的流。表达“执行中的流”是指通信设备10和通信设备20之间建立的、并且正被或者将被通信设备20使用以接收DATA帧的流。如果不存在执行中的流(S707为“否”)，则UPDATE判断单元308判断为不发送连接用WINDOW_UPDATE帧，并且处理结束。另一方面，如果存在执行中的流(S707为“是”)，则处理进入S708。

换句话说，在通信设备20已经发送或接收到GOAWAY帧、存在基于连接的一个流、并且已经接收到该流中的最后DATA帧的情况下，通信设备20执行以下控制。换句话说，通信设备20进行控制，以使得禁止与通信设备20许可使用连接进行数据发送的数据量有关的第二信息的通知以及与通信设备20许可使用流进行数据发送的数据量有关的第一信息的通知。根据本典型实施例，GOAWAY帧是用于描述将不建立基于连接(第一连接)的新流(第二连接)的信息。第二信息的通知是通过发送连接用WINDOW_UPDATE帧来进行的，并且第一信息的通知是通过发送流用WINDOW_UPDATE帧来进行的。

在S708中，UPDATE判断单元308判断为向通信设备10发送与DATA帧接收所使用的流所基于的连接有关的WINDOW_UPDATE帧。然后，UPDATE判断单元308使用HTTP控制单元307来发送连接用WINDOW_UPDATE帧，并且处理结束。因此，向通信设备10通知与通信设备20许可使用连接进行从通信设备10到通信设备20的数据发送的数据量有关的信息。

如上所述，如果接收到流中的最终DATA帧，则根据本典型实施例的通信设备20进行控制，以使得不发送与该流有关的WINDOW_UPDATE帧，直到该流断开为止。通常，通信设备20针对一个DATA帧的接收，发送了用于连接和流的两个WINDOW_UPDATE帧。然而，在接收到流中的最终DATA帧之后，不再需要与该流有关的流控制，因此不需要流用WINDOW_UPDATE帧的发送。根据本典型实施例，与每当接收到DATA帧时发送两个WINDOW_UPDATE帧的情况相比，可以减少来自通信设备20的不必要的WINDOW_UPDATE帧的发送。因此，可以减少处理负荷。例如在通信设备20利用电池进行工作的情况下，减少的处理负荷还可以减少电池消耗。

根据本典型实施例的通信设备20在该通信设备20接收到流中的最终DATA帧的情况下判断是否已经接收到或发送了GOAWAY帧，并且判断是否存在基于连接的任何其它执行中的流。将讨论如下的情况：通信设备20已经接收到或发送了GOAWAY帧，并且没有基于连接建立其它执行中的流。在这种情况下，通信设备20不发送流用WINDOW_UPDATE帧并且也不发送连接用WINDOW_UPDATE帧。GOAWAY帧是用于描述将不基于GOAWAY帧的发送所使用的连接建立新流的信息。因此，在已经发送或接收到GOAWAY帧并且存在一个执行中的流的情况下所接收到的流中的最终DATA帧与连接中的最终DATA帧相对应。因此，通信设备20此后不必发送连接用WINDOW_UPDATE帧。通过应用本典型实施例，通信设备20可以进一步减少不必要的WINDOW_UPDATE帧的发送，因此可以减少处理负荷。

另一方面，将讨论如下的情况：通信设备20尚未发送或接收到GOAWAY帧，并且通信设备20从通信设备10接收到流中的最终DATA帧。在这种情况下，根据本典型实施例的通信设备20进行控制，以使得不发送流用WINDOW_UPDATE而发送连接用WINDOW_UPDATE。即使在接收到流中的最终DATA的情况下已经发送或接收到GOAWAY帧，如果存在另一个执行中的流，则根据本典型实施例的通信设备20也发送连接用WINDOW_UPDATE帧。如上所述，根据本典型实施例的通信设备20基于不同的基准来控制流用WINDOW_UPDATE的发送和连接用WINDOW_UPDATE的发送。因此，通信设备20可以通过减少WINDOW_UPDATE帧的发送来避免在执行中的流的流控制中发生的问题。

第二典型实施例

以下将说明根据本发明的第二典型实施例。根据第二典型实施例的通信设备20基于Content-Length值和WindowSize来判断是否要发送WINDOW_UPDATE帧。针对根据第二典型实施例的通信系统结构、功能模块结构、序列和流程图，省略对与第一典型实施例相同的部分的重复说明。

根据本典型实施例，如果HTTP控制单元307接收到DATA帧，则UPDATE判断单元308通过使用最终判断单元310和Size判断单元311来判断是否要发送WINDOW_UPDATE帧。如果最终判断单元310判断为所接收到的DATA帧的END_STREAM标志有效，则UPDATE判断单元308判断为不发送流用WINDOW_UPDATE帧。Size判断单元311判断HTTP控制单元307所管理的连接用WindowSize和流用WindowSize是否在阈值以上。如果判断为这些WindowSize在阈值以上，则UPDATE判断单元308判断为不发送WINDOW_UPDATE帧。根据本典型实施例，阈值例如为1字节。换句话说，Size判断单元311判断是否消耗了全部的WindowSize。阈值不限于1字节，而可以等于或小于可进行WINDOW_UPDATE帧中的发送的WindowSize的最大值(2^31-1)。例如，阈值可以被设置为InitialWindowSize(初始窗大小)。在这种情况下，Size判断单元311判断是否从初始状态起消耗WindowSize。例如，阈值可以被设置为通信设备20可用来进行数据接收的存储器大小。在这种情况下，Size判断单元311判断WindowSize是否达到与通信设备20的资源有关的上限。例如，以下将说明阈值为1字节的情况。

根据本典型实施例，如果HTTP控制单元307接收到HEADERS帧，则UPDATE判断单元308使用Length获取单元312和Size判断单元311来判断是否要发送WINDOW_UPDATE帧。Length获取单元312获得所接收到的HEADERS帧中设置的Content-Length的值。Size判断单元311判断HTTP控制单元307所管理的连接用WindowSize和流用WindowSize是否在Content-Length值以上。如果判断为这些WindowSize在Content-Length值以上，则UPDATE判断单元308判断为不发送WINDOW_UPDATE帧。

通信序列

以下将详细说明根据本典型实施例的通信设备10和通信设备20之间的通信序列。图8是用于说明根据第二典型实施例的、在通信设备20基于Content-Length和WindowSize来判断WINDOW_UPDATE帧的发送的情况下的系统操作的序列图。参考图8，例如处理在向通信设备10输入用于与通信设备20进行通信的用户操作的时间点开始。然而，用于开始图8中的处理的时间不局限于该时间点。在图4和图8中，相同的标记指代相同的部分，并且将省略重复说明。

M801中的处理与M401中的处理相同。在M802中，通信设备10向通信设备20发送用于描述要在流1(ID_1)中通过使用POST方法来发送32KB的有效载荷数据这一信息的HEADERS帧。根据本典型实施例，HEADERS帧包括Content-Length字段。Content-Length值表示在HEADERS帧之后要发送的有效载荷数据的大小，并且这里假设为32KB。在这种情况下，与通信设备20的连接(ID_0)有关的WindowSize等于64KB，并且与流1(ID_1)有关的WindowSize等于64KB。

在M803中，通信设备10通过使用流1(ID_1)向通信设备20发送32KB的DATA帧。该DATA帧是流1中的最终DATA帧，因此END_STREAM标志有效(值为1)。在通信设备20接收到DATA帧时，与通信设备20的连接(ID_0)有关的WindowSize等于32KB，并且与流1(ID_1)有关的WindowSize等于32KB。在M804中，通信设备20对M803中接收到的DATA帧执行接收处理。

在M805中，通信设备20判断是否要发送WINDOW_UPDATE帧。由于M803中接收到的DATA帧的END_STREAM标志有效，因而通信设备20判断为DATA帧是最终DATA帧，并且此后将不会使用流1来接收DATA帧。因此，通信设备20进行控制，以使得禁止与流1(ID_1)有关的WINDOW_UPDATE帧的发送。由于连接用WindowSize在预定阈值以上，因此通信设备20进行控制，以使得禁止用于增加连接用WindowSize的连接用WINDOW_UPDATE帧的发送。根据本典型实施例，阈值为1字节。在M806中，通信设备20通过使用流1(ID_1)向通信设备10发送用于将“200OK”描述为HTTP响应头部信息的HEADERS帧。

在M807中，通信设备10向通信设备20发送用于描述要在流3(ID_3)中通过使用POST方法来发送16KB的有效载荷数据这一信息的HEADERS帧。此时，与通信设备20的连接(ID_0)有关的WindowSize等于32KB，并且与流3(ID_3)有关的WindowSize等于64KB。在M808中，通信设备10通过使用流3(ID_3)向通信设备20发送16KB的DATA帧。由于该DATA帧是流3中的最终DATA帧，因此END_STREAM标志有效(值为1)。在通信设备20接收到DATA帧时，与通信设备20的连接(ID_0)有关的WindowSize等于16KB，并且与流3(ID_3)有关的WindowSize等于48KB。

在M809中，通信设备20对M808中接收到的DATA帧进行接收处理。在M810中，通信设备20判断是否要发送WINDOW_UPDATE帧。由于M808中接收到的DATA帧的END_STREAM标志有效，因而通信设备20判断为DATA帧是最终DATA帧，并且此后将不会使用流3来接收DATA帧。因此，通信设备20进行控制，以使得禁止与流3(ID_3)有关的WINDOW_UPDATE帧的发送。由于连接用WindowSize在阈值(1字节)以上，因此通信设备20进行控制，以使得禁止用于增加连接用WindowSize的连接用WINDOW_UPDATE帧的发送。

在M811中，通信设备20通过使用流3(ID_3)向通信设备10发送用于将“200OK”描述为HTTP响应头部信息的HEADERS帧。在M812中，通信设备10向通信设备20发送用于描述要在流5(ID_5)中通过使用POST方法来发送32KB的有效载荷数据这一信息的HEADERS帧。此时，与通信设备20的连接(ID_0)有关的WindowSize等于16KB，并且与流5(ID_5)有关的WindowSize等于64KB。

在M813中，通信设备20判断是否要发送WINDOW_UPDATE帧。通信设备20进行控制，以使得在另一通信方所发送的内容的数据量小于该通信设备20许可使用逻辑连接进行数据发送的数据量的情况下禁止通知。根据本典型实施例，通信设备20在M812中所接收到的HEADERS帧中的Content-Length的值等于32KB，并且连接(ID_0)的WindowSize大于16KB。据此，通信设备20判断为需要增加连接用WindowSize以接收全部的有效载荷数据。通信设备20进行控制，以使得立即发送与连接(ID_0)有关的WINDOW_UPDATE帧。另一方面，由于作为Content-Length值的32KB小于作为流5(ID_5)的WindowSize值的64KB，因此通信设备20判断为流用WindowSize是充足的。因此，通信设备20进行控制，以使得禁止与流5(ID_5)有关的WINDOW_UPDATE帧的发送。

在M814中，通信设备20向通信设备10发送与连接(ID_0)有关的48KB的WINDOW_UPDATE帧。因此，与通信设备20的连接(ID_0)有关的WindowSize等于64KB，使得通信设备10可以通过进行一个DATA帧发送来发送全部32KB的有效载荷数据。在M815中，通信设备10通过使用流5(ID_5)向通信设备20发送32KB的DATA帧。由于该DATA帧是流5中的最终DATA帧，因此END_STREAM标志有效(值为1)。在通信设备20接收到该DATA帧时，与通信设备20的连接(ID_0)有关的WindowSize等于32KB，并且与流5(ID_5)有关的WindowSize等于32KB。在M816中，通信设备20对M815中接收到的DATA帧进行接收处理。

在M817中，通信设备20判断是否要发送WINDOW_UPDATE帧。由于M815中接收到的DATA帧的END_STREAM标志有效，因而通信设备20判断为该DATA帧是最终DATA帧，并且此后将不会使用流5来接收DATA帧。因此，通信设备20进行控制，以使得禁止与流5(ID_5)有关的WINDOW_UPDATE帧的发送。由于连接用WindowSize在阈值(1字节)以上，因此通信设备20进行控制，以使得禁止用于增加连接用WindowSize的连接用WINDOW_UPDATE帧的发送。在M818中，通信设备20通过使用流5(ID_5)向通信设备10发送用于将“200OK”描述为HTTP响应头部信息的HEADERS帧。M819和M820中的处理与M412和M413中的处理相同。

WINDOW_UPDATE帧的发送判断流程

图9是用于说明根据本典型实施例的通信设备20所要进行的与WINDOW_UPDATE帧的发送判断有关的操作的流程图。参考图9，例如处理在通信设备20从通信设备10接收一些帧的时间点开始。然而，用于开始图9中的处理的时间不局限于该时间点。在图7和图9中，相同的标记指代相同的部分，并且将省略重复说明。

在S901中，HTTP控制单元307判断通过使用HTTP通信中的流是否已经从通信设备10接收到DATA帧。如果已接收到DATA帧(S901为“是”)，则处理进入S902。如果没有接收到DATA帧(S901为“否”)，则处理进入S911。S902～S904中的处理与S702～S704中的处理相同。在S904中，如果END_STREAM标志有效(S904中为“是”)，则处理进入S907。如果END_STREAM标志无效(S904为“否”)，则处理进入S905。

在S905中，UPDATE判断单元308使用Size判断单元311来判断与接收DATA帧所使用的流有关的WindowSize是否在预定阈值以上。根据本典型实施例，阈值为1字节。换句话说，Size判断单元311判断流用WindowSize是否大于0字节。如果流用WindowSize在阈值以上(S905为“是”)，则UPDATE判断单元308判断为不发送流用WINDOW_UPDATE帧。然后处理进入S907。另一方面，如果流用WindowSize小于阈值(S905中为“否”)，则处理进入S906。

S906～S908中的处理与S705～S707中的处理相同。在S907中，如果HTTP控制单元307未接收到或发送GOAWAY帧(S907中为“否”)，则处理进入S909。如果HTTP控制单元307接收到或发送了GOAWAY帧(S907中为“是”)，则处理进入S908。在S908中，如果存在执行中的流(S908为“是”)，则处理进入S909。如果不存在执行中的流(S908为“否”)，则处理结束。

在S909中，与S905相同，UPDATE判断单元308使用Size判断单元311来判断连接用WindowSize是否在阈值(1字节)以上(即，连接用WindowSize是否大于0字节)。如果连接用WindowSize在阈值以上(S909为“是”)，则UPDATE判断单元308判断为不发送连接用WINDOW_UPDATE帧。然后处理结束。另一方面，如果连接用WindowSize小于阈值(S909中为“否”)，则处理进入S910。S910中的处理与S708中的处理相同。

在S911中，HTTP控制单元307判断通过使用HTTP通信中的流是否已经从通信设备10接收到HEADERS帧。如果已接收到HEADERS帧(S911为“是”)，则处理进入S912。如果没有接收到HEADERS帧(S911为“否”)，则处理结束。在S912中，Length获取单元312判断HTTP控制单元307所接收到的HEADERS帧的头部块片段是否包括Content-Length字段。如果包括Content-Length字段(S912为“是”)，则处理进入S913。如果不包括Content-Length字段(S912为“否”)，则处理结束。在S913中，Length获取单元312从HTTP控制单元307所接收到的HEADERS帧的头部块片段中获得Content-Length的值。

在S914中，UPDATE判断单元308判断S913中获得的Content-Length的值是否大于连接用WindowSize。对于该判断，使用Size判断单元311和Length获取单元312。如果Content-Length的值大于连接用WindowSize(S914为“是”)，则UPDATE判断单元308判断为发送连接用WINDOW_UPDATE帧。然后处理进入S915。另一方面，如果Content-Length的值在连接用WindowSize以下(S914为“否”)，则UPDATE判断单元308判断为不发送连接用WINDOW_UPDATE帧。处理进入S917。

在S915中，UPDATE判断单元308使用Size判断单元311来确定WINDOW_UPDATE帧中所要设置的连接用WindowSize的增加量。根据本典型实施例的UPDATE判断单元308确定增加量，以使得通过从InitialWindowSize中减去接收缓冲器中所存储的DATA帧的总大小所获取的值与WindowSize可以相等。然而，UPDATE判断单元308可进行设置，以使得WindowSize可以大于InitialWindowSize。在S916中，UPDATE判断单元308使用HTTP控制单元307来向通信设备10发送连接用WINDOW_UPDATE帧。

在S917中，UPDATE判断单元308判断是否要发送流用WINDOW_UPDATE帧。UPDATE判断单元308进行控制，以使得在另一通信方所发送的内容的数据量小于该通信设备20许可使用逻辑连接进行数据发送的数据量的情况下禁止通知。根据本典型实施例，UPDATE判断单元308判断S913中获得的Content-Length的值是否大于与接收HEADERS帧所使用的流有关的WindowSize。对于该判断，使用Size判断单元311和Length获取单元312。如果Content-Length的值大于流用WindowSize(S917为“是”)，则UPDATE判断单元308判断为发送流用WINDOW_UPDATE帧。然后处理进入S918。另一方面，如果Content-Length的值在流用WindowSize以下(S917为“否”)，则UPDATE判断单元308判断为不发送流用WINDOW_UPDATE帧。处理结束。

在S918中，UPDATE判断单元308使用Size判断单元311来确定WINDOW_UPDATE帧中所要设置的流用WindowSize的增加量。增加量的确定方法和S915中的针对连接用WindowSize的增加量的确定方法相同。在S919中，UPDATE判断单元308使用HTTP控制单元307来向通信设备10发送流用WINDOW_UPDATE帧。然后处理结束。

如上所述，在连接用WindowSize在阈值以上的情况下，根据本典型实施例的通信设备20不发送连接用WINDOW_UPDATE帧。如果流用WindowSize在阈值以上，则通信设备20不发送流用WINDOW_UPDATE帧。因此，与每当接收到DATA帧时发送WINDOW_UPDATE帧的情况相比，可以减少来自通信设备20的WINDOW_UPDATE帧的发送。因此，可以减少处理负荷。

另一方面，如果连接用WindowSize小于HEADERS帧中所描述的Content-Length的值，则通信设备20发送连接用WINDOW_UPDATE帧。如果与接收HEADERS帧所使用的流有关的WindowSize小于Content-Length的值，则通信设备20发送与该流有关的WINDOW_UPDATE帧。

以下将讨论不进行发送的情况(更具体地，例如讨论在图8的M814中将不发送WINDOW_UPDATE帧的情况)。在这种情况下，由于通信设备20中的连接用WindowSize等于16KB，因此通信设备10首先发送包括全部32KB的有效载荷数据中的16KB的数据的DATA帧。由于连接用WindowSize等于0KB且因此小于阈值，因而已经接收到DATA帧的通信设备20向通信设备10发送连接用WINDOW_UPDATE帧。响应于此，通信设备10发送包括剩余16KB数据的DATA帧。

另一方面，根据本典型实施例，如上所述，在接收到HEADERS帧之后且接收到DATA帧之前，通信设备20在M814中向通信设备10发送连接用WINDOW_UPDATE帧。因此，通信设备10可以在M815中以一个DATA帧发送全部32KB的有效载荷数据，使得与发送两个16KB的DATA帧的情况相比，可以减少传输延迟。这可以提高从通信设备10向通信设备20的DATA帧的发送吞吐量。

如果连接用WindowSize小于Content-Length的值但是在InitialWindowSize以上，则通信设备20可以不发送连接用WINDOW_UPDATE帧。这可以与例如不消耗连接用WindowSize的情况相对应，这是因为根据本典型实施例，WindowSize的最大值等于InitialWindowSize。因此，不需要连接用WINDOW_UPDATE帧的发送。因此，通信设备20可以进一步减少WINDOW_UPDATE帧的不必要发送，因此可以减少处理负荷。

根据本典型实施例，主要说明了通信设备20每当接收到HEADERS帧或DATA帧时判断是否要发送流用WINDOW_UPDATE帧的示例，但本发明的方面不限于此。在另一通信方所要发送的内容的数据量小于通信设备20许可使用逻辑连接发送数据的数据量的情况下，通信设备20可以进行控制以使得禁止与许可的数据量有关的通知，直到逻辑连接断开为止。更具体地，例如，通信设备20可以判断所接收到的HEADERS帧中描述的Content-Length的值是否小于与接收所用的流有关的WindowSize。如果Content-Length的值在流用WindowSize以下，则通信设备20可以在不发送流用WINDOW_UPDATE帧的情况下接收在HEADERS帧之后所发送的全部有效载荷数据。因此，UPDATE判断单元308可以进行控制，以使得禁止流用WINDOW_UPDATE帧的发送，直到流断开为止。这可以消除每当接收到DATA帧时通信设备20每次都要进行的WINDOW_UPDATE的发送判断的必要性，这样可以进一步减少处理负荷。

通信设备20基于未接收到的数据量来判断是否要发送WINDOW_UPDATE帧。如果通过使用逻辑连接从通信设备10接收到的内容所包括的数据中尚未被接收的数据量小于预定值，则通信设备20进行控制以使得禁止通知，直到逻辑连接断开为止。更具体地，HTTP控制单元307对通过使用流从通信设备10发送来的有效载荷数据中尚未被接收的数据量进行管理。这是通过从Content-Length的值减去所接收到的DATA帧的大小所获取的。如果尚未被接收的数据量小于预定值，则UPDATE判断单元308进行控制以使得禁止流用WINDOW_UPDATE帧的发送，直到流断开为止。例如该预定值可以等于流用WindowSize或者可以是1字节。因此，通信设备20可以检测出在与通信设备10的通信中不需要WINDOW_UPDATE帧的发送，并且减少此后的WINDOW_UPDATE帧的发送，这样可以减少处理负荷。

例如，将讨论预定值等于流用WindowSize的情况。如果在WINDOW_UPDATE帧和DATA帧的发送和接收中未被接收的数据量小于的流用WindowSize，则通信设备20进行控制以使得禁止此后的流用WINDOW_UPDATE帧的发送。在这种情况下，如果Content-Length的值小于流用WindowSize，则通信设备20进行控制以使得禁止接收到HEADERS帧以后的流用WINDOW_UPDATE帧的发送。例如在预定值等于1字节的情况下，通信设备20进行控制，以使得禁止接收到最终数据帧之后的WINDOW_UPDATE帧的发送。

第三典型实施例

将说明根据本发明的第三典型实施例。根据第三典型实施例，作为客户端设备的通信设备10进行如参考图9所述的处理，而作为服务器设备的通信设备20发送WINDOW_UPDATE帧以进行流控制。针对第三典型实施例的通信系统结构、功能模块结构、序列和流程图，将省略与第一典型实施例或第二典型实施例之间的共同部分的重复说明。

通信序列

以下将详细说明根据本典型实施例的通信设备10和通信设备20之间的通信序列。图10是用于说明根据本典型实施例的、在通信设备10基于Content-Length来判断要利用WINDOW_UPDATE帧进行通知的数据量的情况下所要进行的系统操作的序列图。参考图10，例如处理在向通信设备10输入用于与通信设备20进行通信的用户操作的时间点开始。然而，用于开始图10中的处理的时间不局限于该时间点。在图4或8和图10中，相同的标记指代相同的部分，并且将省略重复说明。

M1001中的处理与M401中的处理相同。在M1002中，通信设备10向通信设备20发送用于描述在流1(ID_1)中通过使用GET方法来请求利用URL_1所指定的数据这一信息的HEADERS帧。在M1003中，通信设备20向通信设备10发送用于描述在流1(ID_1)中响应于请求而发送利用URL_1所指定的100KB有效载荷数据这一信息的HEADERS帧。根据本典型实施例，HEADERS帧包含作为状态码的“200OK”。HEADERS帧还包含Content-Length字段，其中该Content-Length字段具有100KB的有效载荷数据大小作为Content-Length的值。在这种情况下，与通信设备10的连接(ID_0)有关的WindowSize等于64KB，并且与流1(ID_1)有关的WindowSize等于64KB。

在M1004中，通信设备10判断是否要发送WINDOW_UPDATE帧。通信设备10在M1003中接收到的HEADERS帧中的Content-Length的值等于100KB，该值大于作为连接(ID_0)的WindowSize的64KB。据此，通信设备10判断为需要增加WindowSize以接收全部的有效载荷数据。因此，通信设备10将连接用WindowSize的增加量确定为36KB，使得该连接用WindowSize可以等于比默认值(64KB)大的Content-Length的值(100KB)。通信设备10指定连接用WindowSize的增加量(36KB)并且进行控制，以使得立即发送与连接(ID_0)有关的WINDOW_UPDATE帧。同样，通信设备10指定流用WindowSize的增加量(36KB)并且进行控制，以使得立即发送与流1(ID_1)有关的WINDOW_UPDATE帧。

在M1005中，通信设备10向通信设备20发送与连接(ID_0)有关的36KB的WINDOW_UPDATE帧。在发送了WINDOW_UPDATE帧的情况下，与通信设备10的连接(ID_0)有关的WindowSize等于100KB，而与流1(ID_1)有关的WindowSize仍然等于64KB。在M1006中，通信设备10向通信设备20发送与流1(ID_1)有关的36KB的WINDOW_UPDATE帧。在发送了WINDOW_UPDATE帧时，与流1(ID_1)有关的WindowSize等于100KB。

在M1007中，通信设备20通过使用流1(ID_1)向通信设备10发送100KB的DATA帧。由于该DATA帧是流1中的最终DATA帧，因此END_STREAM标志有效(值为1)。在通信设备10接收到DATA帧时，与通信设备10的连接(ID_0)有关的WindowSize等于0KB，并且与流1(ID_1)有关的WindowSize等于0KB。在M1008中，通信设备10对M1007中接收到的DATA帧进行接收处理。

在M1009中，通信设备10判断是否要发送WINDOW_UPDATE帧。由于M1007中接收到的DATA帧的END_STREAM标志有效，因此通信设备10判断为DATA帧是最终DATA帧并且此后将不会使用流1来接收DATA帧。因此，通信设备10进行控制，以使得禁止与流1(ID_1)有关的WINDOW_UPDATE帧的发送。另一方面，由于连接用WindowSize小于阈值，因此通信设备10进行控制以使得发送连接用WINDOW_UPDATE帧。此时，通信设备10将WINDOW_UPDATE帧中要设置的连接用WindowSize的增加量设置为64KB，使得连接用WindowSize可以恢复成默认值(64KB)。然而，WindowSize的增加量的设置方法不限于此。例如，与M1004中相同，WindowSize可以大于默认值。

在M1010中，通信设备10向通信设备20发送与连接(ID_0)有关的64KB的WINDOW_UPDATE帧。在发送了WINDOW_UPDATE帧时，与通信设备10的连接(ID_0)有关的WindowSize等于64KB。

在M1011中，通信设备10向通信设备20发送用于描述要在流3(ID_3)中使用GET方法来请求利用URL_3所指定的数据这一信息的HEADERS帧。在M1012中，通信设备20向通信设备10发送用于描述在流3(ID_3)中响应于请求而发送利用URL_3所指定的32KB有效载荷数据这一信息的HEADERS帧。此时，与通信设备10的连接(ID_0)有关的WindowSize等于64KB，并且与流3(ID_3)有关的WindowSize等于64KB。

在M1013中，通信设备20通过使用流3(ID_3)向通信设备10发送32KB的DATA帧。由于该DATA帧是流3中的最终DATA帧，因此END_STREAM标志有效(值为1)。在通信设备10接收到DATA帧时，与通信设备10的连接(ID_0)有关的WindowSize等于32KB，并且与流3(ID_3)有关的WindowSize等于32KB。

在M1014中，通信设备10对M1013中接收到的DATA帧进行接收处理。在M1015中，通信设备10判断是否要发送WINDOW_UPDATE帧。通信设备10判断为M1013中所接收到的DATA帧是最终DATA帧、并且此后将不会使用流3来接收DATA帧。因此，通信设备10进行控制，以使得禁止与流3(ID_3)有关的WINDOW_UPDATE帧的发送。由于连接用WindowSize在阈值以上，因此通信设备10进行控制，以使得禁止连接用WINDOW_UPDATE帧的发送。M1016和M1017中的处理与M412和M413中的处理相同。通过传输层中的TCP控制单元306所发送的确认应答来向通信设备20通知通信设备10在M1013中对DATA帧的成功接收。

如上所述，作为HTTP客户端的根据本典型实施例的通信设备10判断是否要发送WINDOW_UPDATE帧。另一方面，根据第一典型实施例和第二典型实施例，作为HTTP服务器的通信设备20判断是否要发送WINDOW_UPDATE帧。如上所述，同样在通信设备作为客户端设备或服务器设备而工作的情况下，可以减少WINDOW_UPDATE帧的发送次数，这样可以抑制处理负荷的增加。

根据本典型实施例的通信设备10设置连接用WindowSize的增加量，以使得连接用WindowSize的值可以大于连接用InitialWindowSize。这是在Content-Length的值大于作为连接用InitialWindowSize的默认值的64KB的情况下执行的。在这种情况下，通信设备10确定连接用WindowSize的增加量，以使得连接用WindowSize的值和Content-Length的值可以相等。因此，通信设备20可以在一个DATA帧中发送大小比连接用WindowSize的默认值大的有效载荷数据。因此，与通信设备20发送各自小于InitialWindowSize的多个DATA帧的情况相比，可以减少传输延迟，这样可以提高从通信设备20向通信设备10的DATA帧发送的吞吐量。

将讨论Content-Length的值在InitialWindowSize的两倍以上的情况。在这种情况下，当WindowSize的最大值被设置为InitialWindowSize时，通信设备10进行多次连接用WINDOW_UPDATE帧的发送，直到接收到全部的有效载荷数据为止。另一方面，根据本典型实施例，在WindowSize等于Content-Length的值的情况下，通信设备10可以通过进行一次连接用WINDOW_UPDATE帧的发送来接收全部的有效载荷数据。因此，通信设备10可以减少WINDOW_UPDATE帧的发送次数，这样可以减少处理负荷。

根据本典型实施例，通信设备10进行控制，以使得连接用WindowSize和Content-Length所表示的内容的数据量可以相等。然而，本发明的方面不限于此。例如，通信设备10可以进行控制，以使得连接用WindowSize可以在内容的数据量以上。比在通信设备10控制下的内容的数据量大的连接用WindowSize可以增加下次接收HEADERS帧时无需发送WINDOW_UPDATE帧的可能性。

在作为接收缓冲器的存储器区域不足以用于Content-Length的值的情况下，通信设备10可以进行控制，以使得连接用WindowSize可以小于Content-Length的值。因此，通信设备10可以考虑到该设备的资源限制来适当地控制WindowSize，这样可以实现资源节省和处理负荷减少这两者。流用WindowSize的增加量的确定方法同样适用于连接用WindowSize。

本典型实施例可以抑制与用于通知通信设备许可发送的数据量的处理相关联的该通信设备的处理负荷的增加。

其它实施例

还可以通过读出并执行记录在存储介质(还可被更完整地称为“非暂时性计算机可读存储介质”)上的计算机可执行指令(例如，一个或多个程序)以进行本发明的上述实施例中的一个或多个的功能以及/或者包括用于进行上述实施例中的一个或多个的功能的一个或多个电路(例如，专用集成电路(ASIC))的系统或设备的计算机和通过下面的方法来实现本发明的实施例，其中，该系统或设备的计算机通过例如从存储介质读出并执行计算机可执行指令以进行上述实施例中的一个或多个的功能以及/或者控制该一个或多个电路以进行上述实施例中的一个或多个的功能来进行上述方法。该计算机可以包括一个或多个处理器(例如，中央处理单元(CPU)、微处理单元(MPU))，并且可以包括单独计算机或单独计算机处理器的网络，以读出并执行计算机可执行指令。例如可以从网络或存储介质将这些计算机可执行指令提供至计算机。该存储介质可以包括例如硬盘、随机存取存储器(RAM)、只读存储器(ROM)、分布式计算机系统的存储器、光盘(诸如致密盘(CD)、数字多功能盘(DVD)或蓝光盘(BD)^TM等)、闪速存储装置和存储卡等中的一个或多个。

虽然已经参考典型实施例说明了本发明，但应当理解，本发明不限于所公开的典型实施例。以下权利要求书的范围应被给予最广泛的理解，以便包含所有这样的修改以及等同结构和功能。

本申请要求2015年5月20日提交的日本专利申请2015-102822的权益，其通过引用而全文并入于此。

Claims (20)

1.一种通信设备，其通过使用与发送设备之间的逻辑连接来从所述发送设备接收内容中所包括的数据，所述通信设备包括：

通知单元，其被配置为向所述发送设备通知与所述通信设备许可使用所述逻辑连接进行从所述发送设备到所述通信设备的数据发送的数据量有关的信息；

接收单元，其被配置为接收响应于所述通知单元所进行的通知而从所述发送设备发送来的所述内容中所包括的数据；以及

控制单元，其被配置为进行控制，以使得：在所述内容所包括的数据中未被所述接收单元接收到的数据量小于预定值的情况下，禁止所述通知单元所进行的通知，直到所述逻辑连接断开为止。

2.根据权利要求1所述的通信设备，其中，所述控制单元进行控制，以使得：在所述接收单元所接收到的所述内容所包括的数据中设置了如下信息的情况下，禁止所述通知单元所进行的通知，直到所述逻辑连接断开为止，其中，该信息表示要使用所述逻辑连接从所述发送设备发送到所述通信设备的最后内容中所包括的数据。

3.根据权利要求1所述的通信设备，其中，还包括：

获得单元，其被配置为获得所述内容的数据量，

其中，所述控制单元进行控制，以使得：在所述获得单元所获得的所述内容的数据量小于所述通信设备许可使用所述逻辑连接进行数据发送的数据量的情况下，禁止所述通知单元所进行的通知，直到所述逻辑连接断开为止。

4.根据权利要求3所述的通信设备，其中，所述控制单元进行控制，以使得：在所述获得单元所获得的所述内容的数据量大于所述通信设备许可使用所述逻辑连接进行数据发送的数据量的情况下，允许所述通知单元所进行的通知，以使得所述通信设备许可使用所述逻辑连接进行数据发送的数据量能够等于或大于所述内容的数据量。

5.根据权利要求1所述的通信设备，其中，所述内容中所包括的数据是通过使用基于所述发送设备和所述通信设备之间的逻辑的第一连接建立的逻辑的第二连接而从所述发送设备发送来的，并且所述通知单元向所述发送设备通知第一信息和第二信息，其中所述第一信息与所述通信设备许可使用所述第二连接进行从所述发送设备到所述通信设备的数据发送的数据量有关，以及所述第二信息与所述通信设备许可使用基于所述第一连接的一个或多个第二连接进行从所述发送设备到所述通信设备的数据发送的数据量有关；

所述接收单元接收所述内容中所包括的数据，所接收到的数据是响应于所述通知单元所进行的所述第一信息和所述第二信息的通知而从所述发送设备发送来的；以及

所述控制单元进行控制，以使得：在所述通信设备没有发送或接收到用于描述将不建立基于所述第一连接的新第二连接的信息、并且在所述接收单元所接收到的所述内容所包括的数据中设置了表示要使用第二连接从所述发送设备发送到所述通信设备的最后内容的信息的情况下，禁止所述通知单元所进行的所述第一信息的通知并且允许所述通知单元所进行的所述第二信息的通知。

6.根据权利要求5所述的通信设备，其中，所述控制单元进行控制，以使得：在所述通信设备发送或接收到用于描述将不建立基于所述第一连接的新第二连接的信息、并且在所述接收单元所接收到的所述内容所包括的数据中设置了表示要使用第二连接从所述发送设备发送到所述通信设备的最后内容的信息的情况下，禁止所述通知单元所进行的所述第一信息和所述第二信息的通知。

7.根据权利要求3所述的通信设备，其中，所述通信设备许可使用所述逻辑连接进行数据发送的数据量等于被定义为所述通信设备的与所述逻辑连接相对应的接收缓冲器的空闲空间的窗大小。

8.根据权利要求1所述的通信设备，其中，所述通知单元向所述发送设备发送HTTP/2中所规定的WINDOW_UPDATE帧，以向所述发送设备通知与所述通信设备许可使用所述逻辑连接进行从所述发送设备到所述通信设备的数据发送的数据量有关的信息。

9.根据权利要求1所述的通信设备，其中，所述逻辑连接包括HTTP/2中所规定的流。

10.根据权利要求5所述的通信设备，其中，所述逻辑的第一连接是HTTP/2中所规定的连接，以及所述逻辑的第二连接是HTTP/2中所规定的流。

11.根据权利要求2所述的通信设备，其中，表示要使用所述逻辑连接从所述发送设备发送到所述通信设备的最后内容中所包括的数据的信息是HTTP/2中所规定的END_STREAM标志。

12.根据权利要求3所述的通信设备，其中，所述获得单元从HTTP/2所规定的Content-Length字段内设置的帧中获得所述内容的数据量，所述内容是由所述通信设备从所述发送设备接收到的。

13.根据权利要求5所述的通信设备，其中，用于描述将不建立基于所述第一连接的新第二连接的信息是HTTP/2中所规定的GOAWAY帧。

14.根据权利要求1所述的通信设备，其中，所述预定值是被定义为所述通信设备的与所述逻辑连接相对应的接收缓冲器的空闲空间的窗大小或者1字节。

15.一种通信设备，其通过使用与发送设备之间的逻辑连接来从所述发送设备接收内容中所包括的数据，所述通信设备包括：

通知单元，其被配置为向所述发送设备通知与所述通信设备许可使用所述逻辑连接进行从所述发送设备到所述通信设备的数据发送的数据量有关的信息；

接收单元，其被配置为接收响应于所述通知单元所进行的通知而从所述发送设备发送来的所述内容中所包括的数据；

判断单元，其被配置为判断所述通信设备许可使用所述逻辑连接进行数据发送的数据量是否在预定阈值以上；以及

控制单元，其被配置为进行控制，以使得：在所述判断单元判断为所述通信设备许可使用所述逻辑连接进行数据发送的数据量在所述预定阈值以上的情况下，禁止所述通知单元所进行的通知。

16.根据权利要求15所述的通信设备，其中，所述预定阈值是1字节或者HTTP/2中所规定的初始窗大小。

17.一种发送设备和通信设备之间的通信方法，所述通信方法包括：

通知步骤，用于向所述发送设备通知与数据量有关的参数；

发送步骤，用于利用所述发送设备，通过使用与所述通信设备之间的逻辑连接来向所述通信设备发送基于所述通知步骤所通知的参数的量的内容中所包括的数据；

接收步骤，用于利用所述通信设备来接收所述发送步骤中从所述发送设备发送来的所述内容中所包括的数据；以及

控制步骤，用于进行控制，以使得：在所述内容所包括的数据中未在所述接收步骤中接收到的数据量小于预定值的情况下，禁止所述通知步骤所进行的通知，直到所述逻辑连接断开为止。

18.根据权利要求17所述的通信方法，其中，所述控制步骤进行控制，以使得：在所述接收步骤所接收到的内容所包括的数据中设置了如下信息的情况下，禁止所述通知步骤所进行的通知，直到所述逻辑连接断开为止，其中该信息表示要使用所述逻辑连接从所述发送设备发送到所述通信设备的最后内容中所包括的数据。

19.根据权利要求17所述的通信方法，其中，还包括：

获得步骤，用于获得所述内容的数据量，

其中，所述控制步骤进行控制，以使得：在所述获得步骤所获得的所述内容的数据量小于被定义为所述通信设备的与所述逻辑连接相对应的接收缓冲器的空闲空间的窗大小的情况下，禁止所述通知步骤所进行的通知，直到所述逻辑连接断开为止。

20.一种存储介质，其存储用于使计算机执行发送设备和通信设备之间的通信方法的程序，所述通信方法包括：

通知步骤，用于向所述发送设备通知与所述通信设备许可使用逻辑连接进行从所述发送设备到所述通信设备的数据发送的数据量有关的信息；

接收步骤，用于接收响应于所述通知步骤所进行的通知而从所述发送设备发送来的内容中所包括的数据；以及

控制步骤，用于进行控制，以使得：在所述内容所包括的数据中未在所述接收步骤中接收到的数据量小于预定值的情况下，禁止所述通知步骤所进行的通知，直到所述逻辑连接断开为止。

Images