[发明专利]传输控制协议发送控制装置以及传输控制协议发送控制方法

说明书

技术领域

本发明涉及TCP(Transport Control Protocol：传输控制协议)发送控制装置以及TCP发送控制方法，特别涉及经由IP(Internet Protocol：互联网协议)网络利用TCP进行家电协同服务时的高效率的发送控制方法的改善。

背景技术

在互联网上进行基于TCP的数据播发的情况下，必须考虑延迟、抖动、分组丢失等各种因素导致的网络状况的变化/差异。另外，对于接收侧终端，也需要考虑支持从高性能终端到低性能终端的大范围的终端。至今为止的通常的TCP栈使用将PC(Personal Computer：个人计算机)设想为通信终端的发送控制参数来实现尽力服务(Best Effort)模式下的数据播发。

图1是表示以往的数据通信系统的结构的图。

在图1中，数据通信系统10包括：服务器11、接口12以及与互联网12连接的用户端13。

在图1的a.中表示的服务器11、互联网12到用户端13之间，网络(以下简写为NW)状况的变动较大，产生延迟/抖动/分组丢失。另外，无法确定每个分组的分发路径，发生分组的到达顺序的调换。

另外，图1的b.中所示的用户端13基本上是PC终端，性能较高，但差异较大。另外，接受以尽力服务前提的服务。

对于以往的数据通信系统10，必须考虑互联网上的各种NW状况和终端，因此在进行基于TCP的数据播发的情况下，使用最大公约数的设定，实现基于尽力服务的服务。

图2是表示以往的家庭网络(home network)(家庭NW)系统的结构的图。

在图2中，家庭NW系统20包括：嵌入型(built-in)的服务器21、家庭NW22以及与家庭NW22连接的多个嵌入终端23。

图2的a.表示的嵌入型的服务器21、家庭NW22到嵌入终端23之间几乎都是单跳，延迟少，也不会发生分组的调换。

另外，图2的b.中表示的嵌入终端23基本上性能较低。但是，对于AV播放等功能，要求严格。

对于预计今后普及的家庭NW中的流式传输服务(streaming service)，与互联网上的服务相比，设想的NW状况有很大不同。另外，对于与PC相比性能低的嵌入终端，要求的是作为家电产品的质量，而不是尽力服务。在通常的处理中，由于分组丢失，需要200ms以上的恢复时间，因此在进行AV流式传输的情况下，发生中断的可能性高。

作为TCP中的发送控制参数的一例，可举出与发生了分组丢失时的重发处理有关的参数。

在TCP中，在网络上丢失分组时，使用两种方法对其进行检测，尝试重发。

一种方法是：利用超时检测分组丢失、进行重发。在发送终端发送分组后，在被称为重发超时时间(RTO：Retransmission Time Out)的参数所规定的时间期间内，无法接收到来自接收终端的确认响应(ACK)的情况下，发送终端判断为分组已丢失，进行该分组的重发。在通常的TCP栈中，对于该重发超时时间设定了最小值，使用200ms以上的值。这是为了防止将在接收终端侧进行延迟ACK处理的情况下产生的延迟判断为分组丢失，而进行不必要的重发处理。

图3是表示一例以往的使用了TCP的确认响应处理动作的控制时序图。

如图3所示，在同一连接上进行双向的数据传输的情况下，有时即使TCP栈接收到分组也不会立即返回ACK，而是对输入从高层应用发送的数据等待一定的时间，尽量使用同一分组发送ACK及其数据，由此进行实现通信高效率的处理(piggyback，捎带)。由此，在接收侧可能产生直至ACK发送为止的延迟，因此，发送终端必须考虑该接收终端侧的延迟量来设定重发超时时间。

另一个分组丢失检测方法是被称为快速重发(Fast Retransmission)的机制，通过接收终端在从接收分组的序列号检测出分组丢失的情况下发送的重复确认响应(Duplicate ACK)，发送终端检测分组丢失。

图4是表示一例使用了以往的TCP的快速重发功能的重发处理动作的控制时序图。

如图4所示，在序列号3的分组在网络上丢失的情况下，接收终端在每次接收到序列号4以后的后继分组时向发送终端返回重复确认响应。通常，发送终端接收到3个重复确认响应时判断为分组已丢失，进行该分组的重发。由于在互联网上各分组经过不同的路径后有可能发生顺序的调换，为了防止将这种顺序调换与分组丢失混淆而产生不必要的重发处理，因而接收终端在接收到3个重复确认响应后才进行重发。