CN103051559A - 数据流接收处理方法和装置 - Google Patents

Abstract

本发明实施例提供一种数据流接收处理方法和装置，该方法包括：接收发送方发送的单向数据流；若判断获知用于缓存所述单向数据流的接收窗口的当前容量达到预设门限，则向共享接收窗口池申请共享窗口用于与所述接收窗口共同缓存所述单向数据；所述共享接收窗口池为预先设置的、固定用于提供对应的缓存资源作为所述共享窗口的缓存资源池。本发明实施例提供的数据流接收处理方法，通过在接收单向数据流的接收窗口的当前容量小于预设门限时，向预先设定的共享接收窗口池申请共享窗口，以与原始的接收窗口一起共同缓存单向数据，从而增大了接收窗口的大小，提高数据的传输效率。

Description

数据流接收处理方法和装置

技术领域

本发明实施例涉及通信技术，尤其涉及一种数据流接收处理方法和装置。

背景技术

传输控制协议（Transmission Control Protocol，简称TCP）是一种面向连接的传输层通信协议。为了保证TCP层传输的数据的可靠性，TCP采用了非常复杂的机制，包括确认（Acknowledgement，简称ACK），字节编号，流量控制，拥塞控制等。在网络传输中，发送端在发送完数据后常常会因为流量控制而停止数据传输，等待接收端更新接收窗口。这使网络带宽的使用造成了极大浪费，TCP的传输效率也不高，特别在接收端并发下载多个文件的时候，流量控制的等待时间会持续恶化，造成整个连接的吞吐量低下。因此，发送端和接收端的传输速率匹配成为制约TCP传输效率的主要因素。

现有技术中，为解决这种问题，常在TCP连接的接收窗口不足时，动态申请一段内存作为接收端的新增窗口，这样，发送端可发送更多的数据给接收端处理，而接收端也可在这段时间内将原窗口的数据交付到上层的应用程序。这种方法，使发送端不用停止数据传输来等待接收端更新接收缓存中的数据，在一定程度上提高了TCP传输的效率，加大了网络的吞吐量。

但是，上述这种方法在接收窗口不足时，都要临时地向操作系统动态申请缓存，耗费了大量时间在内存申请上，延长了向发送端返回确认的时间，且频繁的申请释放，造成大量的内存碎片，容易造成系统不稳定，在多个并发TCP连接都出现接收窗口不足的情况下，这种情况会加速恶化。

发明内容

本发明实施例提供一种数据流接收处理方法和装置，以解决现有技术中TCP传输存在的问题。

第一方面，本发明实施例提供一种数据流接收处理方法，包括：

接收发送方发送的单向数据流；

若判断获知用于缓存所述单向数据流的接收窗口的当前容量达到预设门限，则向共享接收窗口池申请共享窗口用于与所述接收窗口共同缓存所述单向数据；所述共享接收窗口池为预先设置的、固定用于提供对应的缓存资源作为所述共享窗口的缓存资源池。

在第一方面的第一种可能的实现方式中，所述预设门限为零。

在第一方面的第二种可能的实现方式中，还包括：

多次向所述共享接收窗口池申请所述共享窗口，申请的次数不超过预设次数。

根据第一方面、第一方面的第一种可能的实现方式的任意一种，在第三种可能的实现方式中，还包括：

向所述发送方返回确认消息，并携带所述共享窗口与所述当前接收窗口容量和的信息。

根据第一方面、第一方面的第一种至第二种可能的实现方式的任意一种，在第四种可能的实现方式中，所述共享接收窗口池的容量为所述接收窗口原始容量的256倍。

根据第一方面、第一方面的第一种至第二种可能的实现方式的任意一种，在第五种可能的实现方式中，还包括：

成功接收到所述单向数据流后，释放所述共享窗口的缓存资源。

第二方面，本发明实施例提供一种数据流接收处理装置，包括：

接收模块，用于接收发送方发送的单向数据流；

处理模块，用于若判断获知用于缓存所述单向数据流的接收窗口的当前容量达到预设门限，则向共享接收窗口池申请共享窗口用于与所述接收窗口共同缓存所述单向数据；所述共享接收窗口池为预先设置的、固定用于提供对应的缓存资源作为所述共享窗口的缓存资源池。

在第二方面的第一种可能的实现方式中，所述预设门限为零。

在第二方面的第二种可能的实现方式中，所述处理模块还用于：

多次向所述共享接收窗口池申请所述共享窗口，申请的次数不超过预设次数。

根据第二方面、第二方面的第一种可能的实现方式，在第三种可能的实现方式中，还包括：

反馈模块，用于向所述发送方返回确认消息，并携带所述共享窗口与所述当前接收窗口容量和的信息。

根据第一方面、第一方面的第一种至第二种可能的实现方式的任意一种，在第四种可能的实现方式中，所述共享接收窗口池的容量为所述接收窗口原始容量的256倍。

根据第一方面、第一方面的第一种至第二种可能的实现方式的任意一种，在第五种可能的实现方式中，还包括：

释放模块，用于在成功接收到所述单向数据流后，释放所述共享窗口的缓存资源。

本发明实施例提供的数据流接收处理方法和装置，通过在接收单向数据流的接收窗口的当前容量小于预设门限时，向预先设定的共享接收窗口池申请共享窗口，以与原始的接收窗口一起共同缓存单向数据，从而增大了接收窗口的大小，提高数据的传输效率。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本发明提供的数据流接收处理方法一实施例的流程图；

图2为本发明提供的向共享接收窗口池申请共享窗口的流程图；

图3为本发明实施例提供的接收方窗口不足时的操作；

图4为本发明实施例提供的申请共享窗口的过程；

图5为本发明实施例提供的接收方归还共享窗口的过程；

图6为本发明提供的数据流接收处理装置一实施例的结构示意图；

图7为本发明提供的数据流接收处理装置又一实施例的结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

图1为本发明提供的数据流接收处理方法一实施例的流程图。本实施例的方法适用于具有并发连接的通信协议，且协议中需要通过窗口机制来进行流量控制的情况，例如可以为传输层的TCP，也可以为应用层的SPDY传输等，所接收的数据流为可靠的数据流。该方法由接收方执行。如图1所示，本实施例的方法可以包括如下步骤：

步骤101：接收发送方发送的单向数据流。

具体地，在数据传输的过程中，发送方向接收方发送单向数据流，接收方接收发送方所发送的单向数据流。

步骤102：向共享接收窗口池申请共享窗口用于与接收窗口共同缓存单向数据。

具体地，接收方接收发送方发送的单向数据流，同时，接收方若判断获知用于缓存所接收到单向数据流的接收窗口的当前容量小于预设门限时，则向共享接收窗口池申请共享窗口，然后将所申请到的共享窗口和原始的接收窗口一起用于共同缓存单向数据。其中，预设门限是由系统预先设定的，用于在接收方的接收窗口不足时，向共享接收窗口池申请共享窗口。具体地，该预定门限可以设定为0，或其他数值。

其中，共享接收窗口池为预先设置的、固定用于提供对应的缓存资源作为共享窗口的缓存资源池。该共享接收窗口池负责管理整个缓存资源的分配和回收。对于任何一条单向数据传输，在接收窗口不足的情况下都可以向共享接收窗口池申请共享窗口，以动态增加接收窗口的大小，提高数据的传输效率。

本实施例提供的数据流接收处理方法，通过在接收单向数据流的接收窗口的当前容量小于预设门限时，向预先设定的共享接收窗口池申请共享窗口，以与原始的接收窗口一起共同缓存单向数据，从而增大了接收窗口的大小，提高数据的传输效率。

在上述实施例技术方案的基础上，优选的是：预设门限为零。

具体地，该预设门限设定为0，则当用于缓存单向数据流的接收窗口的当前容量剩余为0时，接收窗口会向共享接收窗口池申请共享窗口，然后将所申请到的共享窗口用于和原始的接收窗口一起共同缓存单向数据。

上述实施例通过在接收窗口可接收数据的容量为0时，向共享接收窗口池申请共享窗口，保证了自身接收窗口的完全使用，且可使接收窗口可以有足够的容量去接收数据，保证了数据传输的效率。

在上述实施例技术方案的基础上，进一步地，还包括：

多次向所述共享接收窗口池申请所述共享窗口，申请的次数不超过预设次数。

具体地，在数据传输中，单条的数据传输在接收窗口不足时可以向共享接收窗口池申请共享窗口，但这种申请并不是无限制，一般申请的次数不能超过预设的次数，该预设次数优选地可以为3次。

可选地，当接收方的接收窗口不够而向共享接收窗口池申请共享窗口时，接收方可先判断向共享接收窗口池申请共享窗口的次数是否超过3次。若超过3次，则接收方不会继续向共享接收窗口池申请共享窗口，即共享接收窗口池不会共享窗口给接收方，发送方只能等待接收方的窗口更新，在接收方有窗口接收数据的时候再发送数据；若未超过3次，则接收方向共享接收窗口池申请一段共享窗口给接收方。

在上述方案中，进一步还可以包括：向发送方返回确认消息，并携带共享窗口与当前接收窗口容量和的信息。

具体地，在接收方申请到共享窗口后，其接收窗口的大小得以动态增加，接收方向发送方发送确认消息，并携带共享窗口与当前接收窗口容量和的信息，通知发送方可以发送数据以及可以发送的数据的大小。

图2为本发明提供的向共享接收窗口池申请共享窗口的流程图。如图2所示，在图1所提供的数据流接收处理方法的流程图的基础上，步骤102具体可以包括：

步骤201：接收窗口剩余容量小于预设值。

具体地，接收方在接收窗口的剩余容量小于预设值的时候，才会向共享接收窗口池申请共享窗口。该预设值优选地可以设为0。

步骤202：判断申请次数是否超过预设次数。

具体地，在数据传输中，当接收方的接收窗口剩余容量小于预设值时，接收方需要向共享接收窗口池申请共享窗口。此时，接收方会首先判断其申请次数是否超过预设次数。该预设次数优选地可以为3次。

步骤203：若判断超过预设次数次，等待接收窗口的更新。具体地，当判断接收方向共享接收窗口池申请共享窗口的次数超过预设次数后，接收方不会继续向共享接收窗口池申请共享窗口，发送方只能等待接收方的窗口更新，在接收窗口有剩余窗口来接收数据的时候再发送数据。

步骤204：若判断未超过预设次数次，申请共享窗口。

具体地，当判断接收方向共享接收窗口池申请共享窗口的次数未超过预设次数次后，则共享接收窗口池向接收方提供共享窗口，亦即接收方申请到共享窗口。共享接收窗口池向接收方提供可共享的窗口的地址及大小。其中，共享接收窗口池向接收方提供共享窗口的大小可以为接收方原始的窗口大小。

步骤205：发送确认消息，通知发送方发送数据。

具体地，当接收方申请到共享窗口后，其接收窗口的大小得以动态增加，接收方发送确认消息给发送方，通知发送方可以发送数据。其中，接收方发送给发送方的确认消息中包含接收方目前允许发送方发送的数据量。

上述实施例通过对接收方申请共享窗口的次数进行限制，不会使单条数据传输过多地占用共享接收窗口池中的缓存，从而避免了在有多条数据传输时，部分数据传输因申请不到共享窗口而导致数据传输缓慢的问题。

在上述实施例技术方案的基础上，优选的是：共享接收窗口池的容量为接收窗口原始容量的256倍。

具体地，由于系统预先创建的共享接收窗口池可以供所有的数据传输在接收窗口不足的时候向它申请。优选地，共享接收窗口池的大小可以设为接收窗口原始容量的256倍。当接收窗口原始容量为4096Byte，共享接收窗口池中的可供多条数据传输共享的共享窗口即为1MB；当接收窗口原始容量为8192Byte，共享接收窗口池中的可供多条数据传输共享的共享窗口即为1MB。

共享接收窗口池设置为接收窗口原始容量的256倍，可方便接收方在多条数据传输的接收窗口不够用时来申请共享窗口。

在上述实施例技术方案的基础上，进一步地，还包括：

成功接收到单向数据流后，释放共享窗口的缓存资源。

具体地，当接收方成功接收到单向数据流后，整条数据传输连接释放，同时，接收方所申请到的共享窗口中的缓存资源也同时释放，接收方向共享接收窗口池所申请的共享窗口返还给共享接收窗口池，以便在其他数据传输连接在需要的时候申请共享这段窗口。

上述实施例，通过在成功接收到单向数据流后，释放共享窗口的缓存资源，从而可使其他数据传输连接在需要的时候申请共享这段窗口。

下面用一具体实施例对本发明的数据流接收处理方法进行说明。本实施例的方法以TCP传输层为例进行说明。

TCP协议是一种基于连接的可靠的传输层协议，它在接收到数据以后会发送一个确认消息给发送方来确认当前已经连接收到了多少字节数据，并通知发送方目前接收端还剩多少窗口（简称win）来接收发送方的数据，发送方可以根据这个win值来发送数据，如果win值为0，发送方即使有发送数据也只能阻塞等待。

图3为本发明实施例提供的接收方窗口不足时的操作；图4为本发明实施例提供的申请共享窗口的过程；图5为本发明实施例提供的接收方归还共享窗口的过程。如图3、4和5所示，并同时参照图1和图2，在本实施例中，接收方接收发送方发送的单项数据流，当接收方的接收窗口被已接收的数据占满并没有剩余窗口接收新的数据的时候，会向发送方发送一个确认消息，并告知发送方自身的接收窗口没有剩余，停止发送数据。

由于共享接收窗口池可以在某条TCP连接不足的时候，为该条TCP连接的接收窗口提供可共享的窗口。当接收方的接收窗口不足时，可向共享接收窗口池申请可共享的窗口。接收方会首先判断接收方向共享接收窗口池的申请次数是否小于预设次数。优选地，该预设次数为3次。当系统判断接收方向共享接收窗口池的申请次数大于预设次数时，接收方不会继续向共享接收窗口池申请共享窗口，亦即共享接收窗口池不再向接收方提供共享窗口，发送方只能等待接收方的窗口更新，在接收窗口有剩余窗口来接收数据的时候再发送数据。

如图4所示，当系统判断接收方向共享接收窗口池的申请次数小于预设次数，共享接收窗口池向该条TCP连接共享一段窗口，且该共享的窗口大小与接收方原始的接收窗口大小一致。接收方申请到共享窗口，然后向发送方发送确认消息，告知发送方自身有窗口可以接收数据，发送方可以继续发送数据。发送方于是开始向接收方发送数据，且此时发送的数据可由接收方申请到的共享窗口和原始窗口中的空余缓存一起来接收。

如图5所示，优选地，在接收方成功接收到单向数据流后，发送方会继续向接收方发送一个结束报文，通知接收方数据发送完毕。接收方在收到结束报文后，释放共享窗口的缓存资源，并向共享接收窗口池归还所申请到的缓存窗口。共享接收窗口池收回共享给接收方窗口的缓存，以便在其他数据传输连接在需要的时候申请。

上述实施例，通过在TCP传输的接收方在接收窗口不足的时候，向共享接收窗口池申请共享窗口，且申请次数小于预设次数，并在成功接收到单向数据流后，释放共享窗口的缓存资源，可使得接收方有足够的窗口传输数据，且保证了其他数据传输连接在需要的时候申请共享窗口，有效提高了TCP传输的效率。

图6为本发明提供的数据流接收处理装置一实施例的结构示意图。本实施例的装置适用于具有并发连接的通信协议，且协议中需要通过窗口机制来进行流量控制的情况，例如可以为传输层的TCP，也可以为应用层的SPDY传输等。如图6所示，本实施例的数据流接收处理装置600可以包括接收模块610和处理模块620。

接收模块610用于接收发送方发送的单向数据流。具体地，在数据传输的过程中，发送方向接收方发送单向数据流，接收方的接收模块610接收发送方所发送的单向数据流。

处理模块620用于若判断获知用于缓存单向数据流的接收窗口的当前容量达到预设门限，则向共享接收窗口池申请共享窗口用于与接收窗口共同缓存单向数据；共享接收窗口池为预先设置的、固定用于提供对应的缓存资源作为共享窗口的缓存资源池。

具体地，接收方的接收模块610接收发送方发送的单向数据流，同时，处理模块620在判断获知用于缓存所接收到单向数据流的接收窗口的当前容量小于预设门限时，则向共享接收窗口池申请共享窗口，然后将所申请到的共享窗口和原始的接收窗口一起用于共同缓存单向数据。其中，预设门限是预先设定的，用于在接收单元的接收窗口不足时，向共享接收窗口池申请共享窗口。具体地，该预定门限可以设定为0，或其他数值，优选地，可以设定为0。共享接收窗口池负责管理整个缓存资源的分配和回收。对于任何一条单向数据传输，在接收窗口不足的情况下都可以向共享接收窗口池申请共享窗口，以动态增加接收窗口的大小，提高数据的传输效率。

本实施例提供的数据流接收处理装置，通过在接收单元接收单向数据流的接收窗口的当前容量小于预设门限时，处理模块向预先设定共享接收窗口池申请共享窗口池申请共享窗口，以与原始的接收窗口一起共同缓存单向数据，从而增大了接收窗口的大小，提高数据的传输效率。

在上述实施例技术方案的基础上，优选的是：预设门限为零。

具体地，该预设门限设定为0，则当用于缓存单向数据流的接收单元的接收窗口的当前容量剩余为0时，处理模块620会向共享接收窗口池申请共享窗口，然后将所申请到的共享窗口用于和接收模块610中的原始的接收窗口一起共同缓存单向数据。

在上述实施例技术方案的基础上，进一步地，处理模块620还用于：

多次向共享接收窗口池申请共享窗口，申请的次数不超过预设次数。

具体地，在数据传输中，单条的数据传输在接收窗口不足时，处理模块620可以向共享接收窗口池申请共享窗口，但这种申请并不是无限制，一般申请的次数不能超过预设的次数，该预设次数优选地可以为3次。

可选地，当接收模块610的接收窗口不够而需要处理模块620向共享接收窗口池申请共享窗口时，处理模块620可先判断向共享接收窗口池申请共享窗口的次数是否超过3次。若超过3次，处理模块620不会继续向共享接收窗口池申请共享窗口，即共享接收窗口池不会共享窗口给接收模块610，发送方只能等待接收模块610的窗口更新，在有窗口接收数据的时候再发送数据。若未超过3次，则处理模块620向共享接收窗口池申请一段共享窗口给接收模块610。

上述实施例中，通过处理模块在接收窗口可接收数据的容量为0时，向共享接收窗口池申请共享窗口，且对处理模块的申请次数进行限定，使接收窗口可以有足够的容量去接收数据，且不会使单条数据传输过多地占用共享接收窗口池中的共享窗口，从而避免了在有多条数据传输时，部分数据传输因申请不到共享窗口而导致数据传输缓慢的问题，保证了数据传输的效率。

图7为本发明提供的数据流接收处理装置又一实施例的结构示意图。如图7所示，在图6所示实施例的基础上，该数据流接收处理装置700中，进一步地还可以包括：反馈模块630，具体用于向发送方返回确认消息，并携带共享窗口与当前接收窗口容量和的信息。

具体地，在处理模块620申请到共享窗口后，接收模块610的接收窗口的大小得以动态增加，此时，反馈模块630向发送方发送确认消息，并携带共享窗口与当前接收窗口容量和的信息，通知发送方可以发送数据以及可以发送的数据的大小。

在上述实施例技术方案的基础上，优选地，共享接收窗口池的容量为接收窗口原始容量的256倍。

具体地，由于系统预先创建的共享接收窗口池可以供所有的数据传输在接收窗口不足的时候向它申请。优选地，可以设置共享接收窗口池的大小为接收窗口原始容量的256倍。当接收窗口原始容量为4096Byte，共享接收窗口池中的可供多条数据传输共享的共享窗口即为1MB；当接收窗口原始容量为8192Byte，共享接收窗口池中的可供多条数据传输共享的共享窗口即为1MB。共享窗口设置为接收窗口原始容量的256倍，可方便接收方在多条数据传输的接收窗口不够用时来申请共享窗口。

在上述实施例技术方案的基础上，进一步地，该装置还包括：

释放模块640，用于在成功接收到单向数据流后，释放共享窗口的缓存资源。

具体地，当接收方成功接收到单向数据流后，整条数据传输连接释放，同时，释放模块640释放处理模块620所申请到的共享窗口中的缓存资源，接收方将向共享接收窗口池所申请的共享窗口返还给共享接收窗口池，以便在其他数据传输连接在需要的时候申请共享这段窗口。

上述实施例，通过在成功接收到单向数据流后，释放模块释放共享窗口的缓存资源，从而可使其他数据传输连接在需要的时候申请共享这段窗口。

本实施例提供的装置，可以是TCP传输层的装置，也可以是SPDY应用层的装置。该装置为本发明实施例提供的数据流接收处理方法的执行装置，其执行数据流接收处理方法的过程可参见图1至图5所示的实施例中的相关描述，在此不再赘述。

本发明另一个实施例提供一种数据流接收处理装置，包括处理器和存储器，所述处理器用于接收发送方发送的单向数据流，若判断获知用于缓存所述单向数据流的接收窗口的当前容量达到预设门限，则向共享接收窗口池申请共享窗口用于与所述接收窗口共同缓存所述单向数据；所述共享接收窗口池为预先设置的、固定用于提供对应的缓存资源作为所述共享窗口的缓存资源池。所述存储器用于存储共享接收窗口池。

在本发明所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）或处理器（processor）执行本发明各个实施例所述方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器（Read-Only Memory，ROM）、随机存取存储器（Random Access Memory，RAM）、磁碟或者光盘等各种可以存储程序代码的介质。

本领域技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。上述描述的装置的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。

Claims (12)

1.一种数据流接收处理方法，其特征在于，包括：

接收发送方发送的单向数据流；

若判断获知用于缓存所述单向数据流的接收窗口的当前容量达到预设门限，则向共享接收窗口池申请共享窗口用于与所述接收窗口共同缓存所述单向数据；所述共享接收窗口池为预先设置的、固定用于提供对应的缓存资源作为所述共享窗口的缓存资源池。

2.根据权利要求1所述的方法，其特征在于，所述预设门限为零。

3.根据权利要求1所述的方法，其特征在于，还包括：

多次向所述共享接收窗口池申请所述共享窗口，申请的次数不超过预设次数。

4.根据权利要求1或2所述的方法，其特征在于，还包括：

向所述发送方返回确认消息，并携带所述共享窗口与所述当前接收窗口容量和的信息。

5.根据权利要求1或2或3所述的方法，其特征在于，所述共享接收窗口池的容量为所述接收窗口原始容量的256倍。

6.根据权利要求1或2或3所述的方法，其特征在于，还包括：

成功接收到所述单向数据流后，释放所述共享窗口的缓存资源。

7.一种数据流接收处理装置，其特征在于，包括：

接收模块，用于接收发送方发送的单向数据流；

处理模块，用于若判断获知用于缓存所述单向数据流的接收窗口的当前容量达到预设门限，则向共享接收窗口池申请共享窗口用于与所述接收窗口共同缓存所述单向数据；所述共享接收窗口池为预先设置的、固定用于提供对应的缓存资源作为所述共享窗口的缓存资源池。

8.根据权利要求7所述的装置，其特征在于，所述预设门限为零。

9.根据权利要求7所述的装置，其特征在于，所述处理模块还用于：

多次向所述共享接收窗口池申请所述共享窗口，申请的次数不超过预设次数。

10.根据权利要求7或8所述的装置，其特征在于，还包括：

反馈模块，用于向所述发送方返回确认消息，并携带所述共享窗口与所述当前接收窗口容量和的信息。

11.根据权利要求7或8或9所述的装置，其特征在于，所述共享接收窗口池的容量为所述接收窗口原始容量的256倍。

12.根据权利要求7或8或9所述的装置，其特征在于，还包括：

释放模块，用于在成功接收到所述单向数据流后，释放所述共享窗口的缓存资源。

Images