CN101416066A - 改进传输协议性能的系统和方法 - Google Patents

Abstract

公开了改进传输协议性能的系统和方法。一种示例性方法包括：在第一状态下，非线性地增大拥塞窗；响应于在所述第一状态下该拥塞窗超过阈值，转变到第二状态；以及在该第二状态下，线性地增大该拥塞窗。

Description

改进传输协议性能的系统和方法

相关申请的交叉引用

本申请要求在2006年2月7日提交的美国临时申请No.60/765,787的权益，该临时申请由此通过援引的方式纳入本文。

技术领域

本公开内容涉及通信协议，更具体地，涉及传输层协议。

背景技术

称为传输控制协议(TCP)的传输协议，作为用于通过互联网进行可靠数据传输的事实上的传输协议，在过去二十年中执行良好。尽管TCP所使用的算法被设计来促进在互联网上的稳定性、可靠性和公平性，但是同样是这些算法导致在沿着在通信系统之间的端对端路径存在某些状况的情况下使TCP性能降低。这些特性，包括大带宽、大时延和/或明显的丢失率，在当今互联网中正变得越加普遍。尽管TCP所使用的基本算法多年来有所改变，然而不太可能对这些算法作出重大改动，因为使用TCP的系统有着如此广泛的安装基础。因此，需要解决这些和其他问题。

附图说明

本公开内容的许多方面可以参照以下附图更好地理解。附图中的部件只要对本公开内容的原理进行了清晰图解就不必进行绘制、着重。

图1为用于改进传输协议性能的系统和方法的一个实施方案所处的环境的框图。

图2为用于改进传输协议性能的系统和方法的另一实施方案所处的环境的框图。

图3为用于改进图1所示的传输协议160的性能的逻辑的框图。

图4为示出了由用于改进图1和3中的传输协议160的性能的逻辑所进行的包处理的数据流图。

图5为示出了由图3中的连接终止器350所进行的对所接收的确认的处理的流程图。

图6为示出了由图3中的连接终止器350所进行的对TCP包的处理的流程图。

图7为示出了由图3中的磁芯存储器370所进行的对扩展传输数据、控制或确认包的处理的流程图。

图8为示出了由图3中的虚拟连接管理器380所进行的对所接收的包的处理的流程图。

图9为图3中的逻辑160的一些实施方案所使用的流控制机制的流程图。

图10为由图3中的逻辑160的一些实施方案所使用的拥塞控制机制的状态图。

图11为可用于实现在此公开的改进传输协议的性能的系统和方法的一种通用计算机的框图。

发明内容

公开了改进传输协议性能的系统和方法。一种示例性方法包括：在第一状态下，非线性地增大拥塞窗；响应于在所述第一状态下该拥塞窗超过阈值，转变到第二状态；以及在该第二状态下，线性地增大该拥塞窗。

具体实施方式

图1是用于改进传输协议的性能的系统和方法的一个实施方案所处的环境的方框图。端点设备110使用传输层(第四层)协议120，并且通过网络130相互通信。尽管本公开内容讨论将TCP作为示例性传输层协议，然而本领域普通技术人员应认知到，在此公开的用于改进传输协议的性能的原理也适用于其他传输层协议。路由器140传输通过网络130的通信业务，网络130可涉及诸如网际协议(IP)之类的网络层(第三层)协议的使用。尽管在此使用了术语“路由器”，但是本领域普通技术人员将认知到，路由器140可改为采用第三层交换机的形式。

网络设备150(逻辑上)位于端点110和路由器140之间。每个网络设备150包括用于改进传输协议160的性能的逻辑，其允许网络设备150使用扩展传输协议165与对等网络设备150通信。因此，一对端点110通过一对网络设备150彼此通信。尽管网络设备150在图1中显示于端点110和路由器140之间，但是此为逻辑表示而非物理表示，仅仅表明包通过网络设备150。如下文将阐释的，网络设备150的一些实施方案实际上并非内联地放置在端点110和路由器140之间，而是以与路由器140断开的离线设备的形式运行。

网络设备150的一些实施方案包括端点网络接口170和对等网络接口175，其中，端点网络接口170通过链路180耦接到端点110，对等网络接口175通过链路185耦接到路由器140。网络设备150的一些实施方案包括耦接到路由器140的单一网络接口。单一接口实施方案可“离线”而非“内联”地使用，如下文所述。

在一些实施方案中，网络130中的链路表现出与通向端点110的链路不同的性能特性。例如，通向端点110的链路可提供相对高速的有线连接(例如，100Mbit以太网)，而网络130中的链路可提供较低速的有线或无线连接(例如，T1、WiFi)。扩展传输协议165针对在网络设备150之间的链路的性能特性进行设计。

在网络设备150的一些实施方案中，扩展传输协议165不同于端点110所使用的传输协议120：在端点110和其对应网络设备150之间使用的协议为原始传输协议120；在对等网络设备150之间使用的协议为扩展传输协议165。在这类实施方案中，网络设备150用作端点110的传输代理。在一些代理实施方案中，端点110未察觉到端点110正在使用不同的传输协议，在这种情况下，网络设备150为端点110的透明传输代理。如下文更详细论述的，网络设备150通过以这种方式对由TCP端点发送的包响应而保持透明性，即使得端点意识到仅该代理而非实际的接收器为另一通信端点。

在下文中，当涉及由扩展传输协议165使用的包时，将使用术语“扩展传输包”。本领域普通技术人员应该认知到，这种协议通常包括携带数据的包(数据包)、确认数据的包(确认包)和用于构建拆卸连接的控制包。因此，在此将涉及到“扩展传输数据包”和“扩展传输确认包”以及“扩展传输控制包”。这些包对应于但不同于原始传输协议。例如，TCP数据包和扩展传输数据包均携带数据，但是TCP数据包源自于或被传输到TCP端点110，而扩展传输数据包在传输代理同位体150之间传输。在一些实施方案中，通过将尾部字段添加到原始传输协议包来形成扩展传输包。例如，通过附加“扩展传输数据”的“协议类型”字段，使TCP数据包转换成扩展传输数据包，而通过附加“扩展传输控制”的“协议类型”字段，使TCP控制包转换成扩展传输控制包。这可以被认为是一种封装形式，但具有对端点透明的优点。在一些情况下，扩展传输包被单独传送而不封装。在这些情况下，在IP头部中的协议类型字段可被设置成指示扩展传输协议存在的特定值。也就是说，扩展传输协议165是通过IP层，或网络层，按照TCP或UDP那样的协议类型来浏览的。

本领域普通技术人员应该认知到，用于改进传输协议160的性能的逻辑可采用多种不同方式。一个实施例在独立设备150中实现逻辑160，该独立设备150位于TCP通信端设备和访问路由器140之间。逻辑160的另一例示在端点110内，例如作为位于TCP和核心协议栈的IP层之间的核心驱动器。作为又一实施例，用于改进传输协议160的性能的逻辑能够替换TCP作为在端点110的协议栈中的传输层。尽管在此仅论述了独立网络设备150，但是旨在所有这样的例示均落在本公开内容的范围内。

图2为用于改进传输协议的性能的系统和方法的另一实施方案所处的环境的方框图。在该环境中，一对端点110可包括位于同位体间的多个连接210、220和230。这些连接(210-230)中的每一个均经过改进的网络设备150A和150B。在该实施方案中，网络设备150针对网络设备150之间的连接分支，逐个连接地决定是使用扩展传输协议165还是使用原始传输协议120。在图2的实施例中，连接210和220将扩展传输协议165用于中间分支，而连接230使用原始传输协议120。

在一些实施方案中，用户(例如系统管理员)决定哪些连接将使用哪种传输协议，并且相应地配置网络设备150。几个配置实施例为：所有来自特定端点110的连接使用扩展传输协议165；无来自特定端点110的连接使用扩展传输协议165；那些由特定头部字段组合识别的来自特定端点110的连接使用扩展传输协议165；那些不由特定头部字段组合识别的来自特定端点110的连接不使用扩展传输协议165。本领域普通技术人员应该认知到，这些仅为例子，并且许多其他用于确定哪些连接使用扩展传输协议165的技术是可能的。

图3为用于改进来自图1的传输协议160的性能的逻辑的方框图。连接管理器310构建通向网络中其他网络设备150的连接，并且维持关于其他网络设备150的一般状态信息。连接管理器310可通过配置数据库(本地或集中式)，或通过动态学习过程，或通过任何其他本领域普通技术人员已知的合适机制，发现其他网络设备150的存在和地址。

一旦发现对等设备150，则连接管理器310监测对等设备150的失效。如果发现失效，则连接管理器310向用于改进传输协议160的性能的逻辑中的其他部件通报失效。每个部件响应于同位体失效采取合适的行为。在一些实施方案中，同位体失效的识别通过在对等网络设备150之间的心跳信号来实现。连接管理器部件310传输其设备150的心跳信号，还监测其他对等设备150的心跳。于是，没有心跳表示对等设备150失效。

配置和监测管理器320允许对网络设备150的运行进行调整。配置和监测管理器320还监测网络设备150的性能特性。在一些实施方案中，配置和监测管理器320还监测流经设备150的端点通信业务的性能特性。

通信业务分类器330对进入网络设备150的网络通信业务进行分类。分类基于由在输入打包体(incoming packer)上的头部形成的N元组。在一些实施方案中，N元组为包含发送器IP地址、目标IP地址、发送器TCP端口和目标TCP端口的4元组。通信业务分类器330还执行包的深层检查，以识别特别的连接控制包(例如SYN、ACK、FIN等等)。通信业务分类器330然后通知这些控制包的其他逻辑部件。

分类之后，通信业务分类器330决定是引导包通过逻辑160中的其他部件，还是通过默认前向路径。该决定经与配置和监测管理器320协商做出(下文所述)，该管理器320维持关于协议改进优选的信息(例如，所述改进用于哪些连接，以及哪些连接使用传统协议)。

状态管理器340保持关于改进所用于的那些TCP连接的状态。状态管理器340从通信业务分类器330提供的深层检查数据获知TCP连接的构建和拆卸。在一些实施方案中，连接基于在连接控制包中的N元组被推敲(hash)或索引，这便于进行较为快速的连接查找和包识别。状态管理器340也保持关于一直持续传送/接收包的现用连接的信息以及关于被保持空闲的连接的信息。这种区分帮助实现不同TCP连接之间的公平性，并允许逻辑160使所得已经超过其公平容量份额的连接处于不利地位。

相对于端点TCP连接的源和目标，连接终止器350分别担当目标和源。因此，连接终止器350包括TCP端点的功能性，例如连接管理、包排序、拥塞控制、流控制、确认传输、确认接收处理、丢失检测和丢失恢复。连接终止器350还充当扩展传输协议165和原始传输协议120之间的适配器，从而以这些端点110可理解的形式将决定传送到TCP发送器或接收器。例如，当逻辑160做出流控制决定——“不再有数据要传输”时，连接终止器350通过零尺寸通知窗将该决定输送到TCP发送器端点110。连接终止器350还保持和管理数据缓冲器，以处理无序传输、包丢失、包重传等等。

透明度管理器360与状态管理器340一起工作，以确保在两个TCP端系统之间的协商参数(例如，最大传输单元、选择性确认特征的可用性等等)与逻辑160所要求的参数一致。如早先所述，通信业务分类器330进行深层包检测，并检查TCP控制包(例如SYN、ACK和FIN)。在这些SYN和SYN-ACK控制包中使用的参数被通告给透明度管理器360。如果原始默认参数本身与逻辑160的要求兼容，则这些参数被允许原样不变地通过。然而，当默认参数不兼容时，透明度管理器360修正连接控制包，以使用替换参数。

磁芯存储器370在对等网络设备150之间传输数据，从而实现扩展传输协议165。下文将描述扩展传输协议165的几个特征。在透明传输代理实施方案中，网络设备150基于添加到从TCP端点接收的包的尾部的添加和处理，执行其操作。因此，在两个网络设备150之间流动的包类似于由原始通信端点发送的包。由于现有的网络部件使用头部识别和处理包，所以这种创造性特征(连同上文所述的桥接功能性一起)允许扩展传输协议165对其他网络部件是透明的。

最后，虚拟连接管理器380将TCP连接映射到在对等设备150之间的多个虚拟连接，并且将这些虚拟连接聚集在一起。所聚集的虚拟连接形成端对端路径，被称为“管道(pipe)”。这种实现的实例描述于美国系列号No.11/063,284中，该美国系列号No.11/063,284标题名称为“Systems and Methods for Parallel Communication(用于并行通信的系统和方法)”，在此通过引用的方式完整并入本文。在这些实施方案中的一部分中，虚拟连接的数量可配置，并且可由逻辑160动态选择。

图3示出了包从一个部件传到另一个部件以供处理。在一些实施方案中，采用零拷贝技术，其增大存储器使用的效率。零拷贝包处理使用在内部包表示中的NumReferences字段(数量参考字段)，以追踪访问包的部件的数量。无论何时部件处理包，它都增大NumReferences字段。当部件完成处理时，它减小num_references值。这避免了当使包在部件之间通过时需要拷贝。

图4为显示通过用于改进图1和3中的传输协议160的性能的逻辑进行的包处理的数据流图。输入包的处理始于通信业务分类器330，其使用源IP地址、目标IP地址和协议头部字段来对包进行分类(410)。如果协议类型字段指示包既非TCP包亦非扩展传输包，则包被不做改动地转送到逻辑层-2桥420，其传输该包。如本领域普通技术人员应该理解的，桥接器420具有单个IP地址，并通过维持第三层(IP)地址和第二层(MAC)地址之间的映射表来连接端点网络接口170和对等网络接口175。当给定供传输的包时，桥接器420检查在包中的第三层地址，并基于地址表确定将在哪一个接口(端点网络接口170和对等网络接口175)上传输。因此，在下文的论述中，将提及传输、发送或转送包，而不指定哪一个接口。

作为桥接器运行，允许包含了用于改进传输协议160的性能的逻辑的网络设备150进行包拦截和处理，而不需要对在TCP端点110上的路由表进行改变。桥接器操作也允许网络设备150作为离线设备运行从而远离路由器140定位，而不是在TCP端点110和路由器140之间内联。

如果包被通信业务分类器330分类(410)为TCP包，则该包被提供给状态管理器340。状态管理器340确定(430)TCP包的类型。如果TCP包为连接构建包(例如SYN或SYNACK)，则状态管理器340分别创建或更新连接状态，并且将包转给透明度管理器360。如早前所述，透明度管理器360在构建期间检查连接选项——如在TCP SYN和TCP SYNACK包中所传递的，并且根据需要修正这些选项，以确保与扩展传输协议165的兼容性。然后透明度管理器360转送TCP控制包。

如果状态管理器340确定(430)TCP包为RST包，则状态管理器340(例如通过查阅连接哈希表)确定(440)连接是否存在。如果连接存在，则通过状态管理器340删除连接，并且TCP控制包被转送。返回到由状态管理器340进行的确定430，如果包为FIN包并且连接存在，则更新连接状态。如果FIN也已经被本地端点所接收，则连接被删除。无论何种情况，状态管理器340均请求连接终止器350发送TCP FIN包，然后转送TCP FIN包。

再次返回由状态管理器340所进行的确定430，如果TCP包为ACK或TCP数据包，则状态管理器340(例如通过查阅连接哈希表)确定连接是否存在。如果连接不存在，则状态管理器340转送TCP包。如果连接确实存在，则状态管理器340更新状态信息，将包转给连接终止器350。

在从状态管理器340接收到TCP包后，连接终止器350对TCP包进行分类(450)。如果TCP包为ACK，则连接终止器350执行如收到确认所指示的合适的内务处理，并且丢弃或销毁ACK。

现在将结合图5的流程图来描述由连接终止器350执行的内务处理。连接终止器350在块510处开始处理确认，其中所确认的包被从TCP发送缓冲器去除。接着，在块520处，更新序列中数量(in-sequencenumber)，以反映该确认。然后在块530处更新飞行中包的计数。在块540处继续进行处理，其中更新最大允许未处理包。最后，在该飞行计数小于该最大允许未处理包时在迭代循环中执行块550，其中550发送在TCP发送缓冲器中的下一包。

现在返回到图4中由连接终止器350进行的分类(450)，如果TCP包为数据而非控制包，则连接终止器350进一步处理该包。这种由连接终止器350进行的TCP数据包的处理将结合图6的流程图进行描述。

连接终止器350在块610开始处理包，将磁芯存储器部件(370)的缓冲器尺寸与阈值进行比较。如果缓冲器尺寸达到阈值，则块620发送用于下一序列中包的DUPACK。接着，包被丢弃(块630)，并且包的处理完成。如果磁芯存储器部件的缓冲器尺寸未达到阈值，则在块640继续进行处理。块640确定所接收的包是否为下一序列中包。如果不是，则在块645处所接收的包被插入到TCP接收缓冲器中，块650发送用于下一序列中包的DUPACK，并且对此包的处理完成。另一方面，如果块640确定所接收的包为下一序列中包，则在块655处继续进行处理。

块655更新连接状态。接着，在块660处，磁芯存储器部件370被请求发送该包。在块665处继续进行处理，块665确定TCP接收缓冲器是否为空。如果为空，则块670发送针对所接收的包的确认，并且对该包的处理完成。如果TCP接收缓冲器不为空，则块675通知磁芯存储器部件370，在缓冲器中的所有序列中包准备用于传输处理。接着，块680发送针对所有刚由块675处理的序列中包的确认。现在就完成了对所接收的TCP包的处理。

由逻辑160进行的TCP包的处理已经结合图4的主要数据流图以及图5和6的流程图进行了描述。现在返回到图4的主要数据流图，如果包被分类(410)为扩展传输包而非TCP包，则该包被提供给磁芯存储器370。磁芯存储器370确定(460)该包是扩展传输数据包(470)还是扩展传输控制或确认包(480)。

现在将结合图7的流程图来描述由磁芯存储器370进行的对扩展传输数据、控制或确认包的进一步处理。

由磁芯存储器370所进行的对接收到的扩展传输包的处理始于块710，其确定所接收的包是否为扩展传输数据。如果不是，则处理于块765继续(图7B)，下文将对此进行论述。如果所接收的包为扩展传输数据，则处理于块715继续，其确定所接收的数据包是否为下一序列中包。如果不是，则处理于块720继续，其中该包存储在接收缓冲器中。接着，块725发送针对下一序列中包的DUPACK。然后就完成了对扩展传输数据包的处理。

返回至块715，如果确定所接收的数据包并非下一序列中包，则块730解封装来自扩展传输数据包的TCP包，并且该TCP包在块735被转给连接终止器部件350，供进行进一步处理。在连接终止器处理之后，磁芯存储器部件的接收缓冲器在块740处被检查。如果接收缓冲器为空，则在块745处继续处理，其中发送针对所接收的扩展传输数据包的确认，并且对所接收的扩展传输数据包的处理完成。然而，如果磁芯存储器部件的接收缓冲器不为空，则块750通过将包含在接收缓冲器中的序列中扩展传输数据包内的TCP包进行解封装，来处理接收缓冲器。接着，在块755，TCP包被转给连接终止器部件350以便进一步处理。在连接终止器处理之后，块760发送针对在磁芯存储器接收缓冲器中的所有处理过的序列中包的确认，并且处理完成。

返回块710，如果所接收的包并非扩展传输数据包，则在块765对该包进行进一步分类(图7B)。如果该包并非确认(例如扩展传输SYN、SYNACK、RESET或Heartbeat)，则该包在块770处被传递给连接管理器部件310，以便进一步处理。另一方面，如果包为扩展传输确认，则在块775继续进行处理。

在块775，磁芯存储器370确定所述确认是否针对线路首端(head-of-the-line)包。若否，则该包被忽略并且处理完成。若是，则块780更新下一序列中数量、飞行中包的数量以及所允许的未处理包的数量。在统计更新后，在块785处，由所接收的确认所确认的包被从接收缓冲器去除。在一些实施方案中，使用“惰性释放(lazyfree)”技术来重获缓冲器。(下文将论述惰性释放技术。)在缓冲器清除后，在块790处，虚拟连接管理器380被询问，以确定拥塞窗现在是否允许进行新的传输。如果允许，则块795传输新的扩展传输数据包，直至不再有可用的窗空间。

由磁芯存储器370的一些实施方案所执行的惰性包释放机制将所确认的包的释放延迟至包处理循环中的稍后时间。具体而言，当来自接收器的通报接收到多个包的确认到达时，发送器做标记于所确认的包的列表，并推迟这些包的实际释放到稍后的时间。然后，规定数量的包被从用于由发送器传输的每个新包的惰性缓冲器释放。这就逐步解决了多包传输中的多包存储器释放操作的开销，并且不在接收到确认后马上减缓处理。

图8为显示由虚拟连接管理器380所进行的对所接收的扩展传输包的处理的流程图。这些所接收的包，包括扩展传输数据包和扩展传输确认包，由磁芯存储器370提供给虚拟连接管理器380。由虚拟连接管理器380所进行的对所接收的扩展传输包的处理始于块805，其确定扩展传输包是数据还是确认。如果是数据，则处理在块810继续，其确定所接收的数据包是否为下一序列中包。如果不是数据，则处理在块815继续，其中所接收的数据包的序列数存储在无序列表中。接着，块820更新选择性确认(SACK)记分板，并且块825发送用于下一序列中包的DUPACK。于是就完成了对扩展传输数据包的处理。

回到块810，如果确定所接收的数据包为下一序列中包，则块830检查无序列表。如果该列表为空，则块835发送对所接收的包的确认，并且处理完成。如果该列表不为空，则块840从无序列表去除与所接收的包相对应的序列中数量。接着，在块845，发送针对所有序列中包的确认，并且对所接收的包的处理完成。

返回在块805处的对所接收的包进行的分类，如果包为扩展传输确认包，则块850确定所述确认是否针对线路首端包。若否，则包被忽略并且处理完成。若是，则块855确定磁芯存储器部件是否处于LOSSRECOVERY(丢失恢复)状态。在一个实施方案中，磁芯存储器部件状态包括NORMAL(正常)、LOSS_RECOVERY、TIMEOUT(超时)、SYN_SENT和SYN_RECVD。如本领域技术人员应理解的，这些状态可根据传输协议的选择而改变。

如果未处于丢失恢复状态，则在块860更新如下统计数字：下一序列中数量；飞行中包的数量；和所允许的未处理包的数量。在更新统计后，在块865处更新拥塞控制参数。在一个实施方案中，拥塞控制参数包括拥塞窗尺寸和阈值。于是对扩展传输确认包的处理完成。

如果块855确定磁芯存储器部件处于丢失恢复状态，则在块870继续处理，其确定所述确认是否针对进入LOSS_RECOVERY状态之时的所有未处理包。如果是，则磁芯存储器部件状态被更新为NORMAL。在块875，管道参数在块880处被更新，并且包的处理完成。如果块870确定所述确认针对的少于全部未处理包，则用于管道(虚拟端对端路径)的参数在块885处更新。在一个实施方案中，这些参数包括下一序列中数量、飞行中包的数量和所允许的未处理包的数量。所接收的包在块890处被重传，然后处理完成。

已经对实现扩展传输协议165的逻辑160的整个运行进行了描述，现在将描述该协议的几个特征。本领域普通技术人员应该理解，这些特征通常相互独立，因此扩展传输协议165的特定实施方案可包括这些特征的某种组合。与TCP不同，并不要求扩展传输协议165与其他应用程序和服务共享存储器。设备的整个存储器能够被专门用于有效连接的包缓冲。进一步，这种大型缓冲器在多个有效端对端连接之间得到灵活共享，而对于所述连接而言没有固定限额。TCP的性能在带有较大带宽时延积的网络中受到限制，原因在于对网络中最大未处理包的限制。通过消除小窗的限制并通过实现对用于有效连接的包缓冲的系统可用的整个存储空间的理想共享，扩展传输协议改进了在带有较大带宽时延积的网络中的端对端连接的性能。

TCP的性能在带有较大带宽时延积的网络中受到限制，原因在于对网络中最大未处理包的限制。通过消除小窗的限制并通过实现对用于有效连接的包缓冲的系统可用的整个存储空间的理想共享，扩展传输协议改进了在带有较大BDP的网络中的端对端连接的性能。

图9为由扩展传输协议165所使用的流控制机制的流程图。在该实施例中，端点110A为TCP发送器，端点110B为TCP接收器。端点110A发送以端点110B为目标的TCP数据消息910。网络设备150A接收TCP数据消息910，将其封装到扩展传输协议数据消息920中，并将它们发送到网络设备150B上。网络设备150B接收TCP数据消息920，将封装在其中的TCP数据消息910去除，并将TCP数据消息910发送到端点110B上。

流控制用于所述连接的所有三个分支上。最靠近端点110A的网络设备150A使用TCP流控制机制来控制端点110A的发送速率。也就是说，通过将TCP滑动窗广告和/或冻结消息930发送回端点110A，网络设备150A管理其自己端点侧的接收缓冲器。端点110A理解这些TCP流控制消息930，并如所示进行节流。

从端点110A接收TCP数据的端点110B也使用TCP流控制消息930来节流最靠近它的网络设备150B。网络设备150B如所示进行节流，该网络设备150B将来自端点一侧的流控制消息预期为TCP流控制消息930。当网络设备150B如端点110B所指示的减小数据率时，网络设备150B可能又需要节流发送网络设备150A。如果是这样，则网络设备150B将扩展传输流控制消息940发送至网络设备150A(不同于TCP流控制消息930)。这可能又导致网络设备150B中的路由器侧接收缓冲器装满，此时网络设备150B将通过发送TCP流控制消息930来节流端点110A。因此，发送端点110A的数据率能够受所述连接的所有三个分支上的流控制影响。本领域普通技术人员应该认知到，当网络设备150用尽接收缓冲器空间时，这种策略提供了一种优化的背压式机制来将在网络设备150之间的网络130上的通信业务慢下来，并且最终返回至TCP发送器端点110A。

网络设备150的一些实施方案包括附加的流控制级，执行于TCP连接级，这发生于单一TCP连接超过接收缓冲器的“公平份额”之时。在这种情况下，接收器网络设备150将针对该特定TCP连接的TCP冻结消息发送至发送器网络设备150。作为响应，发送器网络设备150节流在远程一侧上的对应的TCP连接的发送速率。

图10为图示由网络设备150的一些实施方案所执行的拥塞控制机制的状态图。算法在六种状态之间转变：SlowStart(缓慢启动)1010；CongestionAvoidance(拥塞避免)1015；Maintain(维持)1020；ProportionalDecrease(比例减小)1025；LossRecovery(丢失恢复)1030；和InitializeWindow(初始化窗)1035。扩展传输协议165始于缓慢启动状态1010。在处于缓慢启动状态1010时，在连接上的拥塞窗以非线性方式周期性增大(1040)。在一个实施方案中，如果在处于缓慢启动状态1010时拥塞窗达到阈值(1045)，则发送器转变到拥塞避免状态1015。如果情况改为通过网络130的连接的往返行程时间(如探测器所测)达到阈值(1050)，则发送器转变到维持状态1020，下文将对此进行描述。

从缓慢启动状态1010达到的拥塞避免状态1015退出于指示包丢失的事件之时(1055或1057)。拥塞避免状态1015也可退出于通过网络130的连接的往返行程时间——如探测器所测——增大至超出阈值之时(1060)。在指示包丢失的超时事件的情况下(1055)，发送器转变到初始化窗状态1035，在该状态下，拥塞窗被重置为初始值，并且发送器然后返回到缓慢启动状态1010。在指示包丢失的重传确认事件的情况下(1057)，发送器转变到比例减小状态1025，如下文所述。在往返行程时间自拥塞避免状态1015达到阈值(1060)的情况下，发送器转变到维持状态1020。

当处于维持状态1020时，拥塞窗驻留固定于上一计算值，直至发生包丢失，如超时(1065)或重传确认(1070)所指示的。在超时1065的情况下，发送器返回到缓慢启动状态1010。在重传确认1070的情况下，发送器转变到比例减小状态1025。

在比例减小状态1025下，发送器通过以一正比于丢失的包的数量的值将速率节流，对检测到拥塞丢失做出反应，然后进入丢失恢复状态1030。一旦进入丢失恢复状态1030，则拥塞窗被设置成在丢失之时的未处理包的数量减去一个与在一次往返行程时间中网络130中丢失的包的数量成比例的量。该机制确保在丢失恢复期间在丢失包之前传送新包。当处于丢失恢复状态1030时，针对每个确认发送数据(1075)。一旦针对在进入丢失恢复(1080)之时的所有未处理包进行确认，则发送器退出丢失恢复状态1030，并返回到拥塞避免状态1015。一旦超时事件指示包丢失，则拥塞窗被重置成在丢失之时(状态1035下)的原始窗尺寸，并且发送器返回到缓慢启动状态1010。

本领域普通技术人员应该认知到，这种丢失恢复机制是一种与TCP相比较为不激进的方法。TCP被设计为使得在连接过程期间发生的任何包丢失被理解为网络拥塞的标记，并且TCP通过将连接速率节流一半来做出反应。由扩展传输协议165所使用的成比例减小机制在提供带宽可行的环境中(例如无线数据网络和私人WAN)更为合适。除了实现较为不激进的拥塞控制外，扩展传输协议165所应用的按比例减小机制能够比由TCP使用的乘法减小机制更好地处理随机包丢失。由于扩展传输协议165正比于包丢失的数而对拥塞窗进行减小，但减小了随机丢失对拥塞控制的冲击。

本领域普通技术人员还应该认知，上述拥塞窗调节可导致在退出丢失恢复状态之时该已更新的拥塞窗允许大量包传输这一情况。在扩展传输协议165的一些实施方案中，接收器网络设备150通过将新包传输的数限制在两个而将这些包传输沿将来的确认扩散，以用于每个新确认的接收。

本领域普通技术人员应该认知，在图10的拥塞算法和传统传输协议(例如TCP)所使用的之间的不同。TCP针对速率探测使用线性地增大策略：如果可用电容为C单位，并且TCP连接的当前数据率为C-X单位，则TCP将花费大约X往返行程时段来达到对于连接数据率而言理想的运行点。因此，在对网络130上的新资源的可行性做出反应，以及对由拥塞窗提前减小所导致的较低比特率运行做出反应这两方面，TCP较为缓慢。当往返行程时间较大时，TCP花费较长时间来达到理想运行点。诸如SSL交互的短暂连接可以在到达理想运行点之前完全完成数据传送。进一步，由于多个端对端连接多元化而形成已经构建的扩展传输协议连接，所以网络设备消除了针对这些端对端连接的启动探测时延。这是可能的，因为通过对端对端连接的多元化而进行的扩展传输协议连接就使端对端连接之间进行网络信息共享。这种启动时延明显改进了寿命较短的交互应用的性能。

此外，TCP具有如下趋势，即，即使在例程拥塞控制运行期间也引发丢失，因为TCP拥塞控制过程仅具有两个阶段：增大阶段和减小阶段。即使网络130中不存在外部拥塞，TCP也继续增大连接数据率，直至在网络130中引发拥塞并且发生丢失，此时，强制进入减小阶段，并且速率减半以用于拥塞控制循环的反复进行。这种不必要的循环(包括受迫减小和缓慢增大)进一步限制TCP连接的性能。

扩展传输协议165还征示一种丢失检测机制，其较之传统传输协议更为适于高速网络。取代使用较高的超前的超时来检测丢失，扩展传输协议165使用被动学习技术，其基于在丢失检测期间在适当的重要事件之时所发送的包数、所接收的包数和所发送的序列数。更具体地，发送器网络设备150在其传送的所有包上使用单调增大的序列数，称为CONG_SEQ_NUM。接收器网络设备150将确认时在所接收的包上的CONG_SEQ_NUM反映为ACK_CONG_SEQ。当ACK_CONG_SEQ大于在对应的再传送的包上的CONG_SEQ_NUM时，发送器网络设备150得出如下结论，再传送的包丢失并且采取合适行为来从这种丢失中进行恢复。如果不采用这种机制，则唯一的确定再传送的包是否丢失的途径是使用不能有效率地利用珍贵的网络带宽的超时机制。

扩展传输协议165所使用的丢失报告机制，通过容纳更大量的丢失块并组合多级选择性确认(SACK)机制，来允许比传统技术更快地报告。不同于传统TCP所使用的单一分级的SACK机制，扩展传输协议165使用多级SACK来将丢失传送到发送器网络设备150。每个SACK块具有丢失包块的启动和结束以及丢失恢复阶段的传输循环数。传输循环数通过在SACK块中的包的再传输的数来识别。发送器网络设备150给出对于针对再传输过程的最小传输循环数的优先级。

网络设备150还使用粗略的超时，来处理当没有包达到接收器之时，网络130长期关断的情况。每次由接收器对新数据包进行确认(由确认进行指示)时，重置定时器。当定时器超时时，它指示，在发送缓冲器中的线路首端包并未被成功传送由此应该被再传送。这些粗略的超时能够处理瞬时网络传输损耗，尽管上述基于CONG_SEQ_NUM的丢失检测和恢复机制仅工作于存在包到达接收器并因此触发针对发送器的确认之时。

扩展传输协议165的又一特征通过使用不同于传统传输协议的序列数来增大可靠性。接收器网络设备150使用在该确认中的NXT_SEQ_NUM域来将接收器缓冲器在接收器网络设备150处的状态通信至发送器网络设备150。NXT_SEQ_NUM为线路首端包在接收器的无序缓冲器中的序列数。发送器使用NXT_SEQ_NUM值来确定所接收的确认为“真局部确认”还是“假局部确认”。真局部确认确认接收所有小于NXT_SEQ_NUM的包，尽管在丢失之时并非所有包都在待处理。假局部确认并不确认接收小于NXT_SEQ_NUM的所有包，尽管它确认由接收器预期的下一循序包。通过使用NXT_SEQ_NUM域来在真和假局部确认之间进行区分，发送器网络设备150即使在丢失恢复期间也增大网络130的利用。

在扩展传输协议165和传统传输协议(例如TCP)之间的又一区别在于，扩展传输协议165的一些实施例实施方案在广告(滑动)窗尺寸或拥塞窗尺寸方面没有限制。扩展传输协议165的其他实施例实施方案具有限制。这些示例实施方案中的一些所具有的限制比传统协议所使用的限制大得多。

图11为根据用于改进传输协议性能的系统和方法的网络设备150的硬件框图。网络设备150包含多个数据通信领域众所周知的部件，包括处理器1110、本地网络接口1120、远程本地接口1130、存储器1140、和非易失性存储装置1150。非易失性存储装置的实施例例如包括硬盘、闪存RAM、闪存ROM、EEPROM等等。这些部件能够通过总线1160耦接。存储器1140包含来自图1的用于改进传输协议的性能的逻辑。

网络设备150被示为带有两个网络接口。本地网络接口1120与端点110通信，远程本地接口1130与路由器140通信。本领域普通技术人员应该理解，网络接口可为不同类型，支持不同的媒介和速度等等。图11中忽略了本领域技术人员公知的多个传统部件，对于阐释网络设备150的运行而言这些公知传统部件并非必要。

在流程图中的任何过程描述或块应被理解为代表了模块、段、或者包含用于执行在过程中的特定逻辑功能或步骤的一个或多个可执行指令的代码部分。如软件开发领域的普通技术人员所理解的，替换性实施方案可包含在本公开内容的范围内。在这些替换性实施方案中，功能可从所示或所讨论的之中无序执行，包括大致同步或逆序，这取决于所包含的功能。

在此所公开的系统和方法可实施于任意计算机可读的介质中，由指令执行系统、装置或设备所使用或与它们结合。这类指令执行系统包括任意基于计算机的系统、包含处理器的系统、或其他能够给予并自执行来自指令执行系统的指令的系统。在本公开内容的上下文中，“计算机可读介质”可为任意可包含、存储、通信、传播或传送由指令执行系统所使用或者与其结合的程序的装置。计算机可读介质可为，例如但不限于，基于电子、磁、光、电磁、红外或半导体技术的系统或传播介质。

使用电子技术的计算机可读的特定实例将包括(但不限于)如下：具有一个或多个线路的电(电子)连接；随机访问存储器(RAM)；只读存储器(ROM)；可擦可编程只读存储器(EPROM或闪存)。使用磁技术的特定实例包括(但不限于)便携式计算机磁盘。使用光技术的特定实例包括(但不限于)光纤和便携式光盘只读存储器(CD-ROM)。

上文描述已经被展示用于例示和描述的目的。它并不意在将本公开内容囊括或限制于所公开的精确形式。根据上述教示可以进行明显的改造或变化。然而，所讨论的实施方式被选择和描述为，例示本公开内容的原理及其实际应用，从而使本领域技术人员能够以多种不同实施方式(包括适于所理解的特定使用的各种改造)来使用本公开内容。当在合理合法地授权的范围内进行解释时，所有这类改造和变化均落在由所附权利要求书所确定的本公开内容的范围内。

Claims (5)

1.一种控制在第一设备和对等第二设备之间的网络中的拥塞的方法，所述方法包括步骤：

在第一状态下，非线性地增大拥塞窗；

响应于在所述第一状态下所述拥塞窗超过阈值，转变到第二状态；以及

在所述第二状态下，线性地增大所述拥塞窗。

2.根据权利要求1所述的方法，进一步包括步骤：

一旦接收到指示多个包丢失的重传确认，就转变到第三状态；以及

在所述第三状态下，与丢失的包的数量成比例地减小所述拥塞窗。

3.根据权利要求1所述的方法，进一步包括步骤：

传输第一系列的包，每个包包括增大的序列数；

接收第二系列的包，每个包包括确认的序列数；以及

如果所述确认的序列数中的一个大于所述第一系列的包中的对应包的增大的序列数，则指示包丢失。

4.根据权利要求1所述的方法，进一步包括步骤：

传输包含开始序列数、结束序列数和传输循环数的选择性确认。

5.根据权利要求1所述的方法，进一步包括步骤：

检测包丢失；

一旦检测到包丢失，则记录在丢失检测到之时未确认的包的数量；

接收包含在对等接收器的无序缓冲器中的下一包的序列数的确认；以及

确定所接收的序列数是否指示对在丢失检测到之时未确认的所有包的确认。

Images