CN101635665B - 管理隧道的传输信道上的数据流的传送的方法及隧道端点 - Google Patents
管理隧道的传输信道上的数据流的传送的方法及隧道端点 Download PDFInfo
- Publication number
- CN101635665B CN101635665B CN2009101401963A CN200910140196A CN101635665B CN 101635665 B CN101635665 B CN 101635665B CN 2009101401963 A CN2009101401963 A CN 2009101401963A CN 200910140196 A CN200910140196 A CN 200910140196A CN 101635665 B CN101635665 B CN 101635665B
- Authority
- CN
- China
- Prior art keywords
- tunnel
- acknowledgement
- packet
- loss
- flow
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
- 230000005540 biological transmission Effects 0.000 title claims abstract description 87
- 238000000034 method Methods 0.000 title claims abstract description 56
- 238000012545 processing Methods 0.000 claims description 13
- 238000001914 filtration Methods 0.000 claims description 9
- 238000005259 measurement Methods 0.000 claims description 6
- 230000003213 activating effect Effects 0.000 claims description 4
- 238000012795 verification Methods 0.000 claims description 4
- 208000027744 congestion Diseases 0.000 description 35
- 238000004422 calculation algorithm Methods 0.000 description 34
- 230000006854 communication Effects 0.000 description 30
- 238000004891 communication Methods 0.000 description 29
- 230000007246 mechanism Effects 0.000 description 29
- 238000012546 transfer Methods 0.000 description 20
- 230000015654 memory Effects 0.000 description 19
- 238000012937 correction Methods 0.000 description 18
- 238000012790 confirmation Methods 0.000 description 16
- 230000005641 tunneling Effects 0.000 description 14
- 230000000694 effects Effects 0.000 description 12
- 238000012360 testing method Methods 0.000 description 10
- 230000006870 function Effects 0.000 description 9
- 238000012384 transportation and delivery Methods 0.000 description 9
- 238000005538 encapsulation Methods 0.000 description 8
- 238000001514 detection method Methods 0.000 description 7
- 230000004913 activation Effects 0.000 description 6
- 230000001965 increasing effect Effects 0.000 description 6
- 230000008569 process Effects 0.000 description 6
- 230000008901 benefit Effects 0.000 description 5
- 239000000872 buffer Substances 0.000 description 5
- 238000011084 recovery Methods 0.000 description 5
- 238000010200 validation analysis Methods 0.000 description 5
- 230000006399 behavior Effects 0.000 description 4
- 230000000903 blocking effect Effects 0.000 description 4
- 238000004590 computer program Methods 0.000 description 4
- 238000010586 diagram Methods 0.000 description 4
- 238000007726 management method Methods 0.000 description 4
- 238000004458 analytical method Methods 0.000 description 3
- 239000003795 chemical substances by application Substances 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 230000003449 preventive effect Effects 0.000 description 3
- 230000009471 action Effects 0.000 description 2
- 238000013459 approach Methods 0.000 description 2
- 238000010420 art technique Methods 0.000 description 2
- 230000015572 biosynthetic process Effects 0.000 description 2
- 230000002708 enhancing effect Effects 0.000 description 2
- 238000009616 inductively coupled plasma Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000004044 response Effects 0.000 description 2
- 230000009291 secondary effect Effects 0.000 description 2
- 101100043731 Caenorhabditis elegans syx-3 gene Proteins 0.000 description 1
- 101100535673 Drosophila melanogaster Syn gene Proteins 0.000 description 1
- 101100368134 Mus musculus Syn1 gene Proteins 0.000 description 1
- 238000009825 accumulation Methods 0.000 description 1
- 239000000654 additive Substances 0.000 description 1
- 230000000996 additive effect Effects 0.000 description 1
- 238000013475 authorization Methods 0.000 description 1
- 230000007175 bidirectional communication Effects 0.000 description 1
- 230000002457 bidirectional effect Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 230000015556 catabolic process Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 230000000295 complement effect Effects 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 230000009849 deactivation Effects 0.000 description 1
- 230000003247 decreasing effect Effects 0.000 description 1
- 238000006731 degradation reaction Methods 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 230000001066 destructive effect Effects 0.000 description 1
- 230000001627 detrimental effect Effects 0.000 description 1
- 238000000605 extraction Methods 0.000 description 1
- 238000013467 fragmentation Methods 0.000 description 1
- 238000006062 fragmentation reaction Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 230000008447 perception Effects 0.000 description 1
- 230000002085 persistent effect Effects 0.000 description 1
- 238000013439 planning Methods 0.000 description 1
- 230000000717 retained effect Effects 0.000 description 1
- 239000007858 starting material Substances 0.000 description 1
- 235000010384 tocopherol Nutrition 0.000 description 1
- 238000013519 translation Methods 0.000 description 1
- 235000019731 tricalcium phosphate Nutrition 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/19—Flow control; Congestion control at layers above the network layer
- H04L47/193—Flow control; Congestion control at layers above the network layer at the transport layer, e.g. TCP related
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Mobile Radio Communication Systems (AREA)
- Communication Control (AREA)
Abstract
提出一种用于管理隧道的传输信道上的数据流的传送的方法,各流的传送是根据由数据包调度并具有确认的传输协议在所述传输信道上执行的,隧道是在分别与第一和第二子网连接的第一和第二隧道端点之间实现的,各流从发送器设备向接收器设备传送,所述发送器设备和所述接收器设备中的一个设备与第一子网连接,并且另一个与第二子网连接。所述方法通过所述第一隧道端点执行,并且,该方法包括以下步骤:检测隧道的传输信道上的数据包的损失;识别具有由于所述损失而在隧道的传输信道上被阻塞的至少一个数据包的至少一个流;对于至少一个被识别的流,产生至少一个确认并将其传送给在隧道上传送了由于所述损失而被阻塞的数据包的发送器设备。
Description
技术领域
本发明的领域是通信网络领域。
更具体而言,本发明涉及管理由主通信网络支持的隧道(tunnel)的传输信道(transport channel)上的数据流的传送的技术。
背景技术
一方面的高比特率因特网的民主化(democratization)和另一方面的具有网络连接性的消费者视听设备的出现将要创造出新形式的用户行为。这些新形式的行为无疑将伴随属于可被称为“永久链接”组的共同兴趣组(即,诸如休闲、家庭等的共同兴趣)的个体的出现。这些组将与具有相同的兴趣领域的其它个体建立几乎永久的连接,从而建立音频和/或视频通信并共享所有类型的信息(音频、视频、照片、文本等)。
虚拟专用网络(Virtual Private Network,VPN)的技术对于此需求提供了值得尝试的方案。该技术使得能够在共享同一兴趣领域并且同时使用可靠性低但不昂贵的因特网基础结构的个体之间实现实时、透明和安全的通信。
为了透明地通信并克服对于不可路由的地址的需要,VPN使用一种特定类型的被称为隧穿的封装,所述隧穿创建所谓的隧道。该操作包括利用封装协议C将A级协议(嵌入或被运送或乘客协议)封装在B级协议(传输或运送协议)中。因此,传输协议B处理乘客协议A,就好像它是有效负载数据。
以下详细描述的图3呈现出第2级VPN中的数据包封装即第2级隧道(第2级隧道意味着该乘客协议是ISO模型的第2层的协议,其中ISO模型描述由这些层中的每一个和它们的交互作用所提供的服务)中的封装的示例。
隧穿可被用于在不支持某个网络协议的网络上传输该网络协议。它还可被用于提供诸如例如私有寻址(private addressing)之类的不同类型的VPN功能。
隧穿技术现在正越来越多地被需要远程客户访问和家庭局域网(LAN)的功能使用。
在以下的描述中,仅以举例方式考虑OSI模型中的传输协议B的级别等于传输层(ISO模型中的第4级传输层)的级别的第2级或第3级隧道。很明显,本发明的上下文决不是详尽的,并且,OSI模型中的传输协议B的级别可以更低(在具有以太网载体的隧道的情况下)或更高(在某些时候以及具有HTTP载体的情况下)。
隧穿技术频繁被用于使两个LAN互连,以便创建由两个原始LAN的联合(union)形成的虚拟专用网络(VPN)。安全的VPN包含密码和验证(authentication)算法,以保证传输数据的秘密性。在图1(以下详细描述)中示出基于隧穿技术的典型的VPN配置。在该示例中,隧道端点(TEP)没有被集成到网关中。在两个隧道端点之间建立隧道,并且,向与远程LAN连接的装置发送的各数据包(也称为帧)被局域隧道端点封装然后被发送到远程隧道端点,该远程隧道端点将对其进行解封然后将其发送到远程LAN。从通过隧道互连的LAN的各装置的观点来看,它们虚拟地与同一LAN连接。由于隧道的使用对于所连接的LAN的装置是透明的,因此通过隧道在两个装置之间进行的通信被称为端对端通信。
在现有技术中,使用的主要是IP或因特网协议(第3层)或TCP(传输控制协议)/UDP(用户数据报协议)(第4层)。由于基于IP的隧穿技术不能考虑网络地址转换(NAT)机构,并且由于它们并不完全与图1的典型的隧穿配置兼容,因此以下的其余描述考虑(仅作为示例)基于第4层(传输层)即TCP或UDP的方案。
如在呈现出TCP协议的操作原理的附录中说明的那样,TCP协 议(由IETF标准RFC793定义)是基于拥塞控制和重新传送机构的ARQ(自动重复请求)类型的协议,并因此确保各数据包向其目的地的传送。
UDP协议是简单得多且快得多的协议,它不考虑帧的次序并且不管理确认。
如上所述,TCP协议被设计为灵活的,并且在包括具有高等待时间的慢链路和快链路或具有可变错误率的链路的宽范围的网络通信环境中工作。虽然TCP协议工作用于不同的环境,但是这些性能水平(特别是带宽)受所使用的各通信链路的特性的影响。在具有很长的路由时间且/或具有高错误率的环境中,TCP协议在带宽方面的性能受损。
可以使用高级的代理概念或基于RFC 3135标准的PEP(代理增强协议)类型的概念来提高基础结构的性能。RFC 3135标准描述用于改善数据流传送的不同类型的机构(以下称为PEP机构),这些机构被嵌入到服务器和客户机之间的TCP流的路由路径上的网络装置中。如后面将描述的那样,对于每个环境个别地对待PEP系统,以便因此作用于TCP流拥塞的控制。
在因特网的情况下,连接一般为“尽最大努力(best effort)”类型,即,这些连接尽一切可能将信息运送到它们的目的地,但是在执行这一点时不保证一定水平的服务质量(QoS)。因此,在VPN通信的背景下,隧道的传输层在传输容量方面经受高的波动。
在常规上,此隧道的乘客TCP流执行端对端拥塞控制,即,在确定从服务器设备(以下也称为发送器设备)向客户机设备(以下也称为接收器设备)发送数据所必须的比特率时,两个通信设备一起工作。但是,发送器设备具有在隧道中传输流的条件下可得到的信息,从发送器设备和接收器设备的观点看,此隧道是透明的。于是,通过与接收器设备建立的端对端拥塞控制获得的信息可导致由发送器设备采取的这样的决定:该决定不适于隧道上的传输条件,并且通过不必要的重新传送或可用带宽的利用不足而导致带宽消耗增大。
可以建立PEP机构,以便在给定的时间点上根据该隧道的固有限 制来影响对于来自隧道的乘客TCP流的拥塞控制。
对问题的描述
在诸如例如因特网之类的广域网(以下称为WAN)中的VPN隧道的暂时拥塞期间,使用可靠的、基于确认的通信协议的该隧道的载体(即,例如根据TCP协议的该隧道的传输信道)将进入自动重新传送。这将具有暂停在该隧道的该传输信道中运送的所有的流(即使是不直接与隧道载体的封装、数据包即嵌入数据包的损失相关的那些流)的效果。事实上,可以通过隧道的同一传输信道(即,同一通信会话)运送若干个乘客流。此外,通过构建,TCP协议保证数据包的到达次序,并且不事先将跟随该隧道的损失数据包的隧道的数据包给予接收器实体(在这种情况下为远程隧道端点)。换句话说,将不把载体的数据序号大于与隧道的损失数据包对应的号码的接收乘客数据包传送给远程LAN。仅当损失数据包已被发送器隧道端点重新传送并且被接收器隧道端点接收时,才对这些存储的数据包进行解除阻塞(unblock)。
可以看出,损失数据包的重新传送的阶段使得隧道上的往返时间或RTT成为必需,其是对数据包的经典数据/确认(DATA/ACK)传送阶段的补充。
由于因特网隧道上的RTT非常高(为LAN的10~100倍),因此很明显,该RTT非常显著地调整通过在远程客户机和服务器之间的隧道运送的连接(即,作为隧道的乘客的连接)的行为。
因此,在VPN的暂时拥塞期间,所有的乘客连接经受隧道的RTT的两倍的延迟,即,接近这些连接的重新传送超时(以下称为RTO)的临界值的延迟。
取决于WAN的波动,可以看出,在VPN隧道段上进行广播的TCP服务器遭受它们的RTO的期满,从而产生它们的传送比特率的崩溃。可以回想,这些服务器的比特率的增大直接依赖于运送到接收方所花费的时间(RTT),这是因为延迟越大则在崩溃之前恢复初始 传送比特率所花费的时间将越多。此外,不管隧道中对于损失的封装数据包的重新传送的接管情况如何,重新传送也由发送隧道的乘客流的TCP服务器进行。
总之,TCP隧道上的最小损失对于嵌入在该隧道中的TCP连接的端对端性能具有破坏性的影响。
PEP机构主要被应用于拥塞控制,以及被应用于由TCP类型的连接采用的不同的网络段上的重新传送的问题。为了克服隧道的载体(TCP传输信道)上的封装数据包(WAN数据包)的损失的上述问题,基于数据包的暂时存储或缓存的PEP机构可在它们的高速缓冲存储器中存储更多的数据。但是,这在时间上具有有限的效果。
至多,这些PEP机构可延迟由隧道承载的连接的超时现象,但这是不足够的。
因此,必须克服在暂时拥塞的TCP隧道中运送的连接的RTO超时的这个问题,并因而提出用于控制从本地LAN向远程LAN运送穿过该隧道的数字内容的TCP服务器的传送比特率的有效方法,并且,这是本发明的基本要务。
现有技术
对于不稳定环境(诸如因特网或无线链路)中的TCP性能的改善,存在两种类别的原理:端对端协议和分裂连接协议(split-connectionprotocol)。由于后一种类别的协议违反支持端对端客户机TCP连接的隧穿的固有原理,因此我们的问题不考虑该后一种类别的协议:该后一种类别的协议的原理在于,它对于异质网络(heterogeneousnetwork)的各部分具有其自身的特征连接。
大多数的端对端连接协议原理依赖于在异质型网络(典型为WAN的隧道端点或无线网络的基站)之间的基础结构设备中添加PEP(性能增强代理)型专门代理(specialized agent)。
现在将讨论使得能够克服TCP隧穿上的TCP的某些影响的两种现有技术。
在专利文献US2006/0002301 A1(INTEL CORP.US,“Transferring TCP Packets”)中描述了第一种现有技术。该专利文献涉及连接两个远程LAN的TCP隧道的情形,通过该隧道在这两个LAN的装置之间建立TCP连接。
为了当在隧道中存在损失时避免数据的双重重新传送(对应于通过隧道载体进行的一个重新传送以及通过乘客TCP流进行的另一个重新传送),提出在各隧道端点上实现PEP暂时存储机构,进一步使得能够在两个隧道端点之间交换与在任一侧有效接收的数据包有关的信息。在第一种现有技术交换中,通过组合以下的效果对LAN的装置隐藏隧道上的损失:首先,对于损失的各条数据在隧道中发生自动重新传送,第二,暂时存储器部分掩蔽该重新传送所需要的延迟。
这就消除了端对端重新传送(乘客TCP流),实现了通过隧道载体的单一重新传送的益处。可用的高速缓冲存储器因而提供在各网络段(本地LAN、WAN、远程LAN)上的对重新传送的本地管理。该机构应对以下情况时的隧道的性能问题:即,当在该隧道上存在损失时(仅以必要的重新传送有效使用隧道的带宽),以及当在远程网络上存在损失时(本地重新传送)。
但是,所提出的机构没有解决本地LAN等待远程客户机(与远程LAN连接)对其数据的确认的RTO超时的影响。
期望在如第一现有技术中所实现的那样的暂时存储区域也掩蔽WAN上在传送时间方面的损失是徒劳的。至多,运送来自(各隧道端点中的)暂时存储区域的数据包所耗费的时间的波动会加长TCP服务器对RTO的感知(在上述的专利文献中没有评述)。
在以下的IEEE文章中描述了第二现有技术:Elaoud,M.;Ramanathan,P,“TCP-SMART:a technique for improving TCPperforman ce in a spotty wide band environment”,(IEEECommunications,2000.ICC 2000;Page(s):1783-1787 vol.3;DigitalObject Identifier 10.1109/ICC.2000.853814)。
该文章描述了负责实施本地重新传送的窥探(snoop)型机构和对 重复确认或重复ACK的过滤,以便提高穿过不稳定环境(在链路经常损坏的无线链路中)的端对端TCP连接的性能。
该第二现有技术针对减少在无线链路损坏期间的服务器的RTO的期满的数量,这些损坏妨碍来自远程TCP客户机的确认到达。
无线基站处的PEP代理分析各TCP连接,并且暂时存储要在无线链路上被送出的数据。当此数据的确认从远程TCP客户机被代理接收时,从高速缓存中除去这些数据包。如果在某时间段期间没有接收到确认,或者如果接收到出错指示(重复确认或重复ACK),那么这些数据被重新传送到客户机。这是经典PEP存储机构的行为。
该第二现有技术还添加用于产生意图用于“确认窗口”或“告知窗口”字段为0的有线网络的TCP服务器的重复确认(重复ACK)的功能,以便停止从TCP传送。然后,TCP服务器处于暂停模式,对来自客户机(具有严格大于0的告知窗口字段)的新的确认悬而不决,以从该模式释放它。
该第二现有技术针对在不连续的无线链路上的通信呼叫的情形下解决与本发明相同的问题(即,针对防止TCP服务器的RTO的期满的现象),然而,该第二现有技术不适于RTT大得多的WAN环境。事实上,在无线载体的或多或少较长的物理断开期间停止服务器传送以防止缓冲器的拥塞的原理似乎在不连续的无线链路上的通信的情况下是值得的,但是在限于一个数据包的损失决不意味着该隧道的停止(此外,由于该隧道重新传送损失的数据,因此它是保持活动的)的VPN隧道的情况下是不值得的。可以回想,(建立了隧道的)WAN上的运送速度远小于处于LAN或WLAN(无线LAN)上的速度,并且WAN的容量的利用不足在运送时间方面是昂贵的。
如上所呈现的,现有技术PEP机构主要是基于暂时数据存储的原理而准备的。由于必须对至少2个RTT的持续时间存储数据,因此在(建立了该隧道的)WAN上进行传送的情形下这意味着大量的存储器资源。由于隧道的载体肯定将自动负责重新传送建立了该隧道的WAN上的杂散数据包,因此这更加损害TCP VPN隧道。由第二现有 技术提出的设备更加精巧,但不适于从因特网上的TCP隧道的传送容量得到最佳的可能的益处。
因此,现有技术没有任何以下这样的技术:即,该技术在资源方面的成本低,并使得对服务器和客户机透明(符合端对端TCP连接的上述原理)的TCP服务器能够掌握内部TCP管理控制,并适于VPN隧道中的零星损失。
本发明的目的
至少一个实施例中的本发明特别针对于克服现有技术的这些不同的缺点。
更具体而言,本发明的至少一个实施例的目标是,提供用于管理隧道的传输信道上的数据流传送的技术,通过该技术,在检测到对于该隧道的拥塞(在数据损失之后和/或在该隧道的等待时间一次增大期间,隧道进入重新传送阶段)时,能够控制对一个或更多个传送器设备(例如,TCP服务器)的传送比特率的管理,使得能够对来自这些服务器的传送流的带宽的限制最小。
本发明的至少一个实施例的目的还在于,提供一种不要求例如发送器(服务器)设备和接收器(客户机)设备的TCP/IP堆栈的任何修改的技术。
本发明的至少一个实施例的另一目标是,提供一种对于发送器(服务器)设备和接收器(客户机)设备完全透明的技术。
本发明的至少一个实施例的另一目标是,提供要求有限的存储器资源的技术。
本发明的至少一个实施例的再一目标是,提供一种实现简单并且成本低的技术。
发明内容
本发明的一个特定实施例提出一种用于管理隧道的传输信道上的数据流的传送的方法,各流的传送是根据由数据包调度并具有确认的 传输协议在所述传输信道上执行的,隧道是在分别与第一和第二子网连接的第一和第二隧道端点之间实现的,各流从发送器设备向接收器设备传送,所述发送器设备和所述接收器设备中的一个设备与第一子网连接,并且另一个与第二子网连接,所述方法通过所述第一隧道端点执行,并且,该方法包括以下步骤:
-检测隧道的传输信道上的数据包的损失;
-识别具有由于所述损失而在隧道的传输信道上被阻塞的至少一个数据包的至少一个流;
-对于至少一个被识别的流,产生至少一个确认并将其传送给在隧道上传送了由于所述损失而被阻塞的数据包的发送器设备。
因此,在该特定的实施例中,本发明依赖于一种完全具有新颖性和创造性的方法,在该方法中,施加预防性的校正(通过隧道输入隧道端点产生“假想的”确认)以防止发送器设备(服务器)的RTO的期满现象。
因此,并非如在第二现有技术中那样停止发送器设备,而是允许发送器设备相信发送的数据的运送处于控制之下,并且它们可继续传送其余的数据。
对于有效载荷数据节省了隧道的带宽:消除了隧道的乘客流的自动重新传送(而且常常以突发形式)。
该技术对于发送器设备(服务器)和接收器设备(客户机)是完全透明的。不存在对发送器设备(服务器)和接收器设备(客户机)的例如TCP/IP协议堆栈的协议堆栈的修改。
由于没有(由于PEP存储机构引起的)可能的存储器溢出,因此该技术使得有限存储器资源成为必须。
有利地,对于至少一个给定的被识别的流,所述至少一个产生的确认是对所述被识别的流中在由于所述损失而被阻塞的第一个数据包之前的数据包的确认。对于已检测到其损失的数据包所属的被识别的流,由于所述损失而被阻塞的第一个数据包被视为是在检测到该损失之后在隧道的传输信道上重新传送的数据包。
因此,对由第一隧道端点产生的确认的传送通知接收它们的发送器设备:连接仍然有效,并且对于各有关的流不存在数据包的运送延迟以外的其他特定问题。
有利地,对于至少一个给定的被识别的流,所述产生并传送至少一个确认的步骤包含以下的步骤:
-根据与传送所述给定的被识别的流的发送器设备相关联的重新传送超时的持续时间的估计,并且,根据由所述隧道端点处理由于所述损失而被阻塞的所述被识别的流的第一个数据包之前的所述数据包的处理时刻,确定发送第一确认的第一发送时刻t1;
-在所述第一发送时刻t1传送所述第一确认。
因此,使校正对于各发送器设备是特定的。事实上,它取决于有关的流的特性及其在隧道中的活动性。
有利地,所述第一发送时刻t1由t1=t0+RTO′-Δ定义,其中,
-t0是在所述第一隧道端点中处理由于所述损失而被阻塞的所述被识别的流的第一个数据包之前的所述数据包的所述处理时刻;
-RTO′是与传送所述给定的被识别的流的发送器设备相关联的重新传送超时的持续时间的所述估计;
-Δ是预定的安全裕度。
因而,第一发送时刻t1确定起来很简单。
有利地,对于至少一个给定的被识别的流,所述产生并传送至少一个确认的步骤包含以下步骤的至少一次迭代:
-确定发送新的确认的新的发送时刻t2,该新的发送时刻t2由t2=t1+RTO′-Δ定义,这里,t1对于第一次迭代是所述的第一发送时刻,或者,对于从第二次迭代开始的每次迭代,t1是在前一次迭代确定的新的发送时刻t2;
-在所述新的发送时刻t2传送所述新的确认。
因此,作为预防,对于给定的被识别的流,在第一隧道端点中寻求产生另一确认。由第一隧道端点产生的第一确认减轻隧道上的数据包的简单损失的影响,但是,必需设想隧道为了得到恢复而必须具有 大于一个RTT的持续时间的情况。
因此,可以很容易地确定每个新的发送时刻t2。同样,使校正对于各发送器设备是特定的。
有利地:RTO′=2·RTT,RTT为隧道上的往返持续时间的测量结果。
因此,计算被简化。应注意,由于隧道的RTT远大于LAN的RTT,因此,用隧道的RTT的持续时间来近似发送器设备和接收器设备之间的RTT的持续时间。
有利地,对于至少一个给定的被识别的流,在产生并传送至少一个确认的所述步骤中,仅当验证以下的第一条件时产生并传送确认:在隧道的传输信道上运送并由于所述损失而被阻塞的所述给定的被识别的流的数据包的数量大于对于所述给定的被识别的流由所述第一隧道端点产生和传送的确认的数量。
由于发送器设备不接收任何比它已发送的数据包多的确认(例如,在TCP中,仅可响应通过服务器传送的数据包通过客户机产生确认),因此该第一条件确保了发送器设备(服务器)在保证与按数据包排序并具有确认的传输协议(例如,TCP协议)的一致性的方面的透明性。
有利地,对于至少一个给定的被识别的流,在产生并传送至少一个确认的所述步骤中,仅当验证以下的第二条件时产生并传送确认:对于所述给定的被识别的流由所述第一隧道端点产生并传送的确认的数量小于或等于对于传送所述给定的被识别的流的发送器设备指示数据包损失的预定的阈值。
因此,本发明防止发送器设备(服务器)将通过第一隧道端点产生的连续确认的产生解释为数据包损失,并因此防止发送器设备重新传送被假定为损失的数据包。
根据一个有利的特征,对于至少一个给定的被识别的流,该方法包括过滤所述第一隧道端点已对其产生并传送了确认的所述给定的被识别的流的经由隧道从接收器设备到来的确认的步骤。
因此,在发送器设备(服务器)上管理通过第一隧道端点产生假 想确认而引起的二次效果,以便不干扰进行中的连接的状态机。例如,如果远程接收器设备(客户机)由于远程LAN上的轻微乱序而发出“真实的”重复确认(重复ACK),并且如果第一隧道端点已产生并发出一个或两个“假想的”重复确认,则必须过滤(即,检测并破坏)该“真实的”重复确认,使得发送器设备(服务器)不接收会导致其处于重新传送模式的第三重复确认(使得TCP发送器窗口功能下降,这是要避免的)。
在另一实施例中,本发明涉及可从通信网络下载和/或记录在计算机可读载体上和/或可由处理器执行的计算机程序产品。该计算机程序产品包含用当在计算机上执行所述程序时实现上述的方法(其不同的实施例中的一个中的方法)的程序代码指令。
在另一实施例中,本发明涉及存储计算机程序的计算机可读存储介质,该计算机程序包含可由计算机执行以便实现上述方法(其不同的实施例中的任一个中的方法)的一组指令。
在一个特定的实施例中,本发明提出一种第一隧道端点,该第一隧道端点使得能够管理隧道的传输信道上的数据流的传送,各流的传送是根据由数据包调度并具有确认的传输协议而在所述传输信道上执行的,该隧道是在分别与第一和第二子网连接的所述第一隧道端点和第二隧道端点之间实现的,各流是从发送器设备向接收器设备传送的,所述发送器设备和所述接收器设备中的一个设备与第一子网连接,并且另一个与第二子网连接。所述第一隧道端点包含:
-用于检测隧道的传输信道上的数据包的损失的装置;
-用于识别具有由于所述损失而在隧道的传输信道上被阻塞的至少一个数据包的至少一个流的装置;
-用于对于至少一个被识别的流产生至少一个确认,并将其传送给在隧道上传送了由于所述损失而被阻塞的数据包的发送器设备的装置。
有利地,对于至少一个给定的被识别的流,所述至少一个产生的确认是对所述被识别的流的由于所述损失而被阻塞的第一个数据包之 前的数据包的确认。对于已检测到其损失的数据包所属的被识别的流,由于所述损失而被阻塞的第一个数据包被视为是在检测到损失之后在隧道的传输信道上重新传送的数据包。
有利地,所述用于产生并传送至少一个确认的装置包含:
-用于对于至少一个给定的被识别的流,根据与传送所述给定的被识别的流的发送器设备相关联的重新传送超时的持续时间的估计,并且,根据由所述隧道端点处理由于所述损失而被阻塞的所述被识别的流的第一个数据包之前的所述数据包的处理时刻,确定发送第一确认的第一发送时刻t1的装置;
-用于在所述第一发送时刻t1传送所述第一确认的装置。
因此,使校正对于各发送器设备是特定的。事实上,它取决于有关的流的特性及其在隧道中的活动性。
有利地,所述第一发送时刻t1由t1=t0+RTO′-Δ定义,其中,
-t0是在所述第一隧道端点中处理由于所述损失而被阻塞的所述被识别的流的第一个数据包之前的所述数据包的所述处理时刻;
-RTO′是与传送所述给定的被识别的流的发送器设备相关联的重新传送超时的持续时间的所述估计;
-Δ是预定的安全裕度。
有利地,用于产生并传送至少一个确认的所述装置包含被激活至少一次的以下装置:
-用于对于至少一个被识别的流确定发送新的确认的新的发送时刻t2的装置,该新的发送时刻t2由t2=t1+RTO′-Δ定义,其中,t1对于第一次迭代是所述的第一发送时刻,或者,对于从第二次迭代开始的每次迭代,t1是在前一次迭代确定的新的发送时刻t2;
-用于在所述新的发送时刻t2传送所述新的确认的装置。
有利地:RTO′=2·RTT,RTT为隧道上的往返持续时间的测量结果。
有利地,所述第一隧道端点包括:
-第一验证装置,该第一验证装置用于对于至少一个给定的被识 别的流验证以下的第一条件:在隧道的传输信道上运送并由于所述损失而被阻塞的所述给定的被识别的流的数据包的数量大于对于所述给定的被识别的流由所述第一隧道端点产生和传送的确认的数量;
-用于如果所述第一验证装置做出肯定的验证则对于所述至少一个给定的被识别的流激活用于产生并传送至少一个确认的所述装置的装置。
有利地,所述第一隧道端点包括:
-第二验证装置,该第二验证装置用于对于至少一个给定的被识别的流验证以下的第二条件:对于所述给定的被识别的流由所述第一隧道端点产生并传送的确认的数量小于或等于对于传送所述给定的被识别的流的发送器设备指示数据包损失的预定的阈值;
-用于如果所述第二验证装置做出肯定的验证则对于所述至少一个给定的被识别的流激活用于产生并传送至少一个确认的所述装置的装置。
根据一个有利的特征,所述第一隧道端点包括,对于至少一个给定的被识别的流,过滤所述第一隧道端点已对其产生并传送了确认的所述给定的被识别的流的经由隧道从接收器设备到来的确认的装置。
附图说明
从通过指示性而非详尽的例子给出的以下说明和附图,本发明的实施例的其它特征和优点将显现,其中,
图1示出实现隧道的虚拟专用网络(VPN)的典型配置;
图2示出可实现本发明的方法的隧道端点的经典分层模型的示例;
图3示出运送第2级隧道数据包的以太网帧的经典格式的示例;
图4是参照在图1中描述的环境应用本发明的特定实施例的情景的示意图;
图5示出根据本发明的特定实施例的数据结构的不同表格;
图6呈现出在检测隧道的传送错误时执行的算法,该算法被包含 于本发明的校正方法的特定实施例中;
图7示出在接收来自该隧道的、对于该隧道的乘客TCP流的确认时执行的算法,该算法被包含于本发明的校正方法的特定实施例中;
图8示出用于产生确认消息并将其发送给服务器的算法,该算法被包含于本发明的校正方法的特定实施例中;
图9提供实现本发明的特定实施例的算法的隧道端点101的PEP系统的功能体系结构的示意图;
图10示出适于实现本发明的特定实施例的一般通信设备的示意性配置。
具体实施方式
在本发明的所有附图中,相同的元件和步骤由相同的附图标记表示。
图1示出通过通信网络107(例如因特网)在本地隧道端点101和远程隧道端点102之间实现隧道100的虚拟专用网络(VPN)的典型配置。该隧道100连接两个局域网:LAN A 103和LAN B 104。LAN103和104中的每一个具有高比特率因特网访问装置(能够集成防火墙的家用网关)105和106、PC型装置109和111、用于存储和分配数字媒体(音频、视频和照片类型)的服务器110和113、以及数字媒体呈现装置108和112。隧道端点可被集成到诸如数字电视机之类的视听装置中。它还可以以执行与其相关的功能的程序的形式存在于PC型装置中。
一旦隧道100被构建,连接到LAN A 103的装置108、109和110就能够与连接到LAN B 104的装置111、112和113进行通信。例如,连接到LAN A 103的客户机108可以与连接到网络LAN B 104的服务器113进行通信。
该图1示出仅具有一个隧道的简单通信网络,但是应该理解,同一隧道端点可能必须管理若干个隧道(一直到隧道端点的等同数量)以使第一LAN与若干个其它的LAN互连。此外,为了简化,附图没 有示出诸如因特网路由器之类的因特网中的基础结构装置。
参照图2,现在将描述来自装置108、109和110中的一个(与LAN A 103连接)并将进入隧道100的以太网帧的路由。为此,将使用分层模型。该分层模型描述实现该隧道100所需要的协议层。在该模型中,未表现隧道的使用以外的功能所需要的协议元素。例如,当隧道端点101被集成到UPnP装置中时与UpnP体系结构相关联的协议元素没有被示出。
隧道端点101具有以太网物理接口208,所述以太网物理接口208将来自装置108、109和110的以太网帧移交到用于路由的链路层207:对于意图用于包含隧道端点的装置的以太网帧,该路由是朝向网络层206进行的,或者,对于其它的以太网帧,该路由是朝向桥接层209进行的。桥接层209实施以太网桥的经典操作,诸如过滤以太网帧和将这些帧中继到一个或多个适当的以太网输出端口。该桥具有以太网接口207和连附到其上的模拟以太网控制器的至少一个虚拟接口210。对于由应用200实例化的每个隧道创建虚拟接口210,将必须在分别实例化的隧道上运送行进的以太网帧给予所述虚拟接口。一般地,用于由应用200表示的隧道的封装的协议执行实现每个隧道所必需的操作,其中特别是配置、过滤和封装(隧道数据包的形成)以及帧的提取的操作。
被应用200处理之后从虚拟接口210被接收的帧通过应用接口或套接层201以数据包的形式被移交给分别由SSL协议202和DTLS协议204确保的可靠的TCP传输协议203或不可靠的UDP传输协议205。
术语“可靠的传输模式”或“可靠的传输协议”被理解为指的是这样的传输模式或协议,对于该传输模式或协议,发送帧或数据包的设备在向接收器设备传送帧或数据包时获得一条信息。这种模式的主要特征是,确保帧或各条数据的传输而不是发送器设备和接收器设备之间的传送的等待时间。以下,术语“可靠的信道”将被理解为指的是,用于通过使用数据传输协议在两个子网络(也称为本地LAN)之间传输 隧道的数据的信道(该数据自身可根据确定的传输协议而采取数据包或帧的形式)。
在通过传输协议进行处理以形成隧道数据包250(图3)之后,该数据包被转到网络层126。现在可通过链路层207和物理层208在LAN上传输这样用当前的数据包形成的IP数据报。
对来自隧道100的帧的接收将遵循与以上呈现出的路径相反的隧道端点中的路径。
图3示出例如在图1的LAN A 103上运送的以太网帧(附图标记260)的经典格式的示例,该以太网帧包含:
-以太网标题字段(附图标记261);
-第一IP数据报(附图标记262)自身,其传送第2级隧道数据包(附图标记250);和
-FCS(帧检查序列)字段(附图标记263)。
隧道数据包250具有四个部分:
-传输协议标题字段251(即,本示例中的TCP或UDP字段);
-封装协议252的标题字段(即,特别是在以下的文献“IETFRFC3931,“Layer two tunneling protocol-version 3(L2TPv3)”,J.Lau and all,March 2005”和“IETF RFC2246,“The TLS ProtocolVersion 1.0”中描述的本示例中的L2TP或TLS);
-乘客协议253的标题字段(即,本示例中的以太网);最后是
-用户数据字段254,如果在从源装置运送的过程中没有发生破碎(fragmentation),那么该用户数据字段254自身包含第二完全IP数据报。
图4是参照在图1中描述的环境应用本发明的特定实施例的情景的示意图。
以下根据在隧道端点101上的定位来描述本发明的本特定实施例的算法。事实上,任何隧道端点都能够执行本发明。但是,建立本发明的算法的隧道入口隧道端点将仅仅关注于通过TCP隧道从本地LAN接收的意图用于远程LAN的TCP数据。
在图4所示的情况下,隧道端点TEP 101分析从LAN(本地LAN)103发送以便进入隧道中的、意图用于(远程)LAN 104的TCP数据以及对于该TCP数据从LAN 104接收的确认。
在该示例中,两个媒体服务器110-A和110-B位于LAN 103中,并且,这些服务器的两个客户机设备112-A和112-B位于局域网104中。为了澄清本示例的说明,应注意,数据包的索引(index)的概念与发送数据包的发送次序对应(数据包的索引i表示数据包是第i个数据包),并且不具有通信协议中的任何实际意义(与集成到各TCP数据包中的序号不同)。
对于TCP数据包将使用以下的符号:
-标注“i”的数据包410:索引为i的数据段TCP(即,对于数据序号n由LAN 103的服务器110-A和110-B中的一个发送的第i个数据包);
-标注“Ri”的数据包413:与具有相同的索引“i”的数据包410相同但是已通过相同的数据序号n被重新传送的TCP数据段;
-标注“Ai”的数据包411:对于数据序号n的数据包“i”或“Ri”的TCP确认(因此,根据TCP协议,该数据包411包含确认序号n+1);该确认411被LAN 104的客户机发出到LAN 103的服务器;
-标注“Di”的数据包412:对于数据序号n的数据包“i”或“Ri”的TCP确认(因此,根据TCP协议,该数据包411包含确认序号n+1);该确认412被TEP隧道端点101(根据本发明的机构,参见图6和8)发送到LAN 103的服务器。确认412是经典的确认(可被复制然后被服务器视为“重复ACK”)或选择性的确认SACK(在附录中详细描述这两种类型的确认)。
通过由数据包“Ai”411确认的数据包“i”410形成经典的TCP连接。
在图4的例子中,因此,隧道对于两个不同的TCP连接,从LAN103向LAN 104发送数据的数据包410,并且从LAN 104向LAN 103发送确认数据包411:
-在服务器110-A和接收器112-A之间建立的连接A(该连接A的数据包由包含上述的符号“i”、“Ri”、“Ai”和“Di”的方形表示);
-在服务器110-B和接收器112-B之间建立的连接B(该连接B的数据包由包含上述的符号“i”、“Ri”、“Ai”和“Di”的圆形表示)。
隧道端点TEP 101被认为能够利用用于知晓隧道上的传送的调度和日期的时间指示来保留在隧道上运送的数据包410和411的序号(在实际中,索引i的段410的踪迹被一直被保留,直到接收到与其对应的确认411)。此外,在隧道的载体的数据包和乘客流的数据包之间进行数据序号的关联(以下规定),以便容易地识别隧道载体的各数据包(载体数据包)的内容。
对于信息,隧道端点TEP 101管理在隧道上发送的TCP段的表格501(以下参照图5描述该表格501)。
阶段4-1:对隧道上的错误的检测
该阶段与隧道上检测错误的时间对应。例如,三个重复确认(重复ACK)420已被隧道端点TEP 102发送以指示隧道的数据包的损失。自动地,在接收到同一数据序号k的三个重复ACK之后(因此根据具有确认序号k+1的TCP协议),隧道的TCP协议层将重新传送丢失的载体数据包。同时,在隧道端点TEP 101上触发报警,以便确定由具有数据序号k的载体数据包传输的数据的性质。
在图4的示例中,具有数据序号k数据包的载体数据包与流110-A到112-A(连接A)的索引3的数据包410对应。该隧道因此进入重新传送,以运送该数据(数据包“R3”)。
然后,隧道端点TEP 101确定在远程隧道端点102的TCP协议层中被阻塞的那些数据段410:这是在连接A的索引3的数据包410之后已在隧道上被发送的局域网103的所有数据包410。
在该示例中,确定的数据包410如下:
-对于连接A,索引大于3的所有数据包;
-对于连接B,索引大于2的所有数据包(连接B的索引2先于连接A的索引3的数据包的发送)。
在接收到三个重复ACK之后,即,在隧道端点TEP 101和隧道端点TEP 102之间的一个隧道往返时间(RTT)之后,进行隧道中的错误的检测。这是为何可在图4中看到,对于由远程客户机接收的非阻塞数据包,隧道上的索引R3的数据包413的传送(损失的那条数据的重新传送)大致与对于确认411的与LAN 103相反的传送一致的原因。
因此,这意味着连接A和B的随后的序列的将来的确认将仅在服务器和客户机之间的一个往返时间之后在LAN 103上被接收(由于隧道的RTT远大于LAN 103和104中的每一个的RTT,因此这近似于隧道上的另一往返时间)。
这就是为何下一阶段4-2的目标是施加防止性校正(通过隧道端点TEP 101产生确认412)以防止服务器TCP 111-A和110-B的超时RTO的期满的现象的原因,并且,将使该校正对LAN 103的各服务器110-A和110-B特定。
阶段4-2:对于超时RTO的期满的问题施加校正
该阶段可被细分成两个步骤4-2a和4-2b:一个阶段(4-2a)用于计算用于发送确认消息412的超时,另一阶段(4-2b)在该超时时段期满时产生确认消息412的发送。
因此,对于隧道的各乘客流,该方法确定隧道端点TEP 101处理第一个阻塞数据包410的日期T0(对于与信道上的重新传送有关的流,在重新传送中,第一个阻塞数据包被视为数据包410)。
在隧道的RTT的连续测量之后,对于各流,该方法确定对确认消息412的传送进行规划的日期t1。该日期t1与(t0+2·RTT-Δ)对应,其中,Δ是若干毫秒的安全裕度。可以回想,与各服务器110-A、110-B的RTO对应的时段的持续时间基本上等于2·隧道的RTT,并且,本发明的防止性校正包含在各服务器的RTO期满之前向各服务器发送确认消息412,以将该RTO复位为零并由此防止其期满。
因此,在超时表格510(参见图5)中记录输入,该输入包含产生对于服务器110-A和110-B的确认消息412所需要的信息。
如果阻塞在隧道中持续,那么还优选确定一个或更多个第二超时时段,以确定用于向有关的服务器TCP 110-A、110-B发送其它确认消息412的一个或更多个日期t2。一旦接收到由客户机112-A、112-B发起的、来自远程LAN 104并被隧道运送的真实确认410,随后的超时周期就被消除(不存在由隧道端点TEP 101产生的确认消息412的随后的发送)。
此外,与产生的确认消息412对应的、由客户机112-A、112-B发起的真实确认411被过滤,以便不发送太多的确认消息。事实上,例如,三个重复确认(“重复ACK”)的累积会导致服务器通过分析断定在网络中出现了错误,这是要避免的。
现在参照图5,呈现出数据结构的各种表格550、501、510和520。各数据流由其源IP地址、其源TCP端口以及其目的地IP地址及其目的地TCP端口表征。必须注意,由于TCP通信是双向通信,因此同一TCP会话可运送两个数据流。以下通过非详尽的示例描述各表格。
表格550是隧道端点上的活动流的表格。术语“活动流”在这里被理解为是指与建立的未关闭的TCP会话相关的流。该表格550包含:
-字段551,该字段551对于每个流代表被分配给该流的唯一标识符,并用作相对于流的其它数据结构的参考;
-字段552和554,其分别表示TCP会话的源和目的地IP地址;
-字段553和555,其分别表示TCP会话的源和目的地端口;
-字段556,其与由连接支持的确认消息的类型对应。例如,经典类型的确认(ACK)或选择型确认(SACK)。
表格501表示在隧道上传送的、与表格550的各活动流的TCP数据包410有关的各条数据。在该表格中,对于在隧道上被传送并且还没有被确认的乘客流的每个TCP数据包,存在一个输入。该表格501包含:
-字段502,其表示由隧道端点101处理TCP段/数据包的日期t0,诸如例如在隧道中发送TCP段/数据包的日期(近似地,当忽略封装数据包410所需要的时间时,可以用通过隧道端点接收来自本地 LAN的数据包410的日期标识该值);
-字段503,其表示流标识符551;
-字段504,其表示乘客流数据包的数据序号n,即对于有关的流551、来自LAN的、由隧道端点101接收的TCP数据序号(TCP数据包410,即,乘客段);
-字段505,其表示隧道的载体的载体数据包的数据序号k,即运送以504表示的乘客段(TCP数据包410)的数据包的载体(载体数据包)的TCP数据序号。
表格510表示用于随后产生确认消息412的超时值存储表格。在该表格中,对于每个规划的传送,存在一个输入。该表格510包含:
-字段512,其表示必须产生确认消息412的期满的日期(例如,t1);
-字段513,其表示流标识符551;
-字段514,其表示对于同一流标识符(字段503(表格501)和551(表格550)),确认记录在表格501(字段504)中的数据序号“n”(n=j-1)的确认序号“j”。因此,根据TCP协议,字段514包含确认序号“j”(表示确实已接收到数据序号“j-1”并且等待数据序号“j”)。
表格520是用于为对于各流产生的确认消息412进行计数的表格。该表格520包含:
-字段522,其表示流标识符513;
-字段523,其表示确认序号514。在实际中,表格520对于每个流513仅保持与所产生的最后的确认412对应的一个条目(起初对于之前的段产生的确认412不再具有任何重要性,这是因为它们确认更小的数据序号,并且,当前的所产生的最后的确认根据TCP协议的调度的确认协议固有地确认所有之前的段);
-字段524,其表示对于有关的流522的上述确认序号523,由隧道端点产生的确认消息412的数量;
-字段525,其表示对于有关的流522的上述确认序号523,通过隧道由隧道端点接收并来自远程客户机112-A或112-B的确认消息 411的数量。
图6示出在检测在隧道端点TEP(例如101)上实现的隧道的传送错误时执行的算法,该算法被包含于本发明的校正方法的特定实施例中。
隧道端点TEP 101监管穿过隧道的活动连接的数据流。
优选地,在管理隧道100上的乘客TCP流的路由的隧道端点TEP的情境下进行描述,即,隧道端点TEP 101能够识别将在隧道中行进的、其输入端口上的TCP流。例如,可合理地考虑两种类型的TCP流:与主要的(且特别持久的)传送对应的那些TCP流以及控制流(少数往返消息)。因此,本发明的特定实施例仅考虑第一种类型的TCP流:这使得能够实现可从中受益的流的带宽的分配。可例如通过隧道端点TEP接收诸如UPnP、QoS或SBM询问之类的业务QoS询问或与在其中一个LAN中上活动的任何其它QoS协议有关的询问的质量,检测这些流。关于流的优先级询问使得能够知晓这些流的性质:在IEEE802.1Q标准中,优先级4~6分别与流式传送、视频传送和音频传送对应。这些QoS询问顺序地携带对TCP流的识别所需要的所有参考(源和目的地地址、端口、协议)。很显然,在提出的示例中,仅考虑TCP传送协议流。
此外,在对打开TCP连接(具有SYN标记的TCP数据包,参见附录)进行检测时,应用协议的更深的分析提供传送特性的知识:例如,携带http应用协议(253)的TCP流包含表示所请求的媒体的类型的信息(对于具有MIME型“video/mpeg”的视频为http GET消息)。作为非详尽的示例给出这些示例。
在本发明的一个特定实施例中,被视为这样的情况:其中,在没有隧道端点TEP 101的任何管理控制的情况下在隧道中运送以上指定的没有被识别的任何其它TCP流。这具有这样的优点:为非常重要的流保持隧道端点TEP 101的可用处理器和存储器资源。很显然,在一个变型例中,本发明的方法适用于穿过隧道的所有TCP流。
在另一特定实施例中,由各TCP连接使用的确认的类型也被确 定。SACK扩展(符合文件RFC2018)在TCP消息中使用两个任选的字段。第一字段是当启动连接时在TCP SYN段中生效或不生效的“SACK容许”激活选项,其表示随后使用SACK机构的可能性。第二选项是SACK选项,如果当建立TCP连接时被授权,则该SACK选项在对于选择性确认的传送期间生效。
在新TCP连接的各打开/关闭时定期更新流的表格550(参见图5)。此外,表格501(参见图5)在参照图1描述的环境情境中管理例如由TCP客户机-服务器对(110-A和112-A)接收的数据段和确认。
本发明的目的不是对填写表格550的方式要求权利。存在针对此目的的若干个现有技术。
对于所考虑的流,隧道端点TEP 101保持(表格501)穿过隧道端点TEP 101的数据(DATA)的数据段(数据包)的TCP序号。这意味着,在任何时间,隧道端点TEP 101均知晓在隧道中被发送并且没有被确认的数据包的数量(飞行尺寸(flightsize))。
此外,隧道端点获得对隧道的TCP信道开放的网络连接器或套接层的特性(例如,通过使用使得能够使其知晓隧道中的错误的API“Unix Socket Interface”)。API意味着“应用编程界面”。
优选地,为了填写表格501,由隧道端点TEP 101使用修改的TCP协议堆栈。或者是协议堆栈直接在通过隧道端点TEP 101的路由功能接收用于在隧道上发送乘客流的数据的命令期间更新表格501,或者是反过来对于通过API“Unix Socket Interface”发送数据的命令指示隧道的TCP数据序号的一条附加信息,并且,由隧道端点TEP自身来更新表格501。
当在隧道中检测到错误时,API“Unix Socket Interface”能够警告本发明的算法,特别是能够重新激活图6的步骤600。应注意,隧道TCP自身管理损失数据包的重新传送。
步骤601包含从表格501以及从隧道的TCP载体的损失数据包的数据序号(标识符505)的知识确定有关的乘客流(标识符503)和通过TCP载体的损失数据包传输的运送的数据包410的数据序号(号码 504)。
在步骤602中,再次基于表格501,对于在隧道上运送的各其它流,本发明确定在步骤601中确定的数据包410之后发送的第一个数据序号。其为这样的数据序号,将对所述数据序号应用产生朝向它们的相对TCP服务器的本发明的消息的原理。
在步骤603中,可对以上指定的那些合格的乘客TCP流中的乘客TCP流进行选择性调度,并且,对于步骤604和605的执行,仅逐一地考虑所选择的流。如果不是,那么对于步骤604和605的执行,逐一地考虑所有先前确定的流。
几个选项对于调度是可能的:
-较慢的开始阶段中的TCP流(参见附录)被认为具有优先级,这是由于它们的拥塞窗口在限制(SSTHRESH)先验未知的该阶段中更加明显地增加;
-优选地,本发明避免TCP流在稳定化的阶段(这是拥塞避免阶段,参见附录)中经受小窗口尺寸。窗口的小型化将具有效果,但仅是一点点效果;
-可以使用由客户机发送的设备窗口(或告知窗口,参见附录)的值以知晓提出用于增加比特率的最宽裕度的流;
-被认为具有优先级的流是已在非常接近在601确定的乘客流的时间跨度中已发送数据(即,已在隧道上经受重新传送)的那些流。应注意,在601确定的流是将被应用本发明的校正算法的第一个流。
步骤604被用于确定朝向TCP服务器发送根据本发明产生的确认消息412的第一发送日期t1(第一超时)。
在步骤605中,在规划派遣表格510中规划确认消息412的发送。
我们会注意确定第一传送日期t1的特定方面。如参照图8的步骤807详细描述的那样,随后可能规划第二传送日期t2(第二超时)。
对于应用步骤604和605的隧道的各乘客流,确认消息412的第一传送日期t1大大取决于隧道的RTT的连续测量的值(所有的乘客流共用的参数)以及隧道端点101处理所考虑的乘客流的第一个阻塞 数据包的日期t0(对每个流有一个特有的日期t0)。因此,使第一超时的激活对于每个流是特定的,并与流的激活协调,以尽可能具有最小的侵扰性。
可以回想,对于确认消息412的产生(图8的算法的激活)进行规划的第一传送日期t1被获得如下:t1=t0+2·RTT-Δ,其中,Δ是若干毫秒的安全裕度(例如,隧道RTT的10%)。
图7示出在例如隧道端点TEP(101)中实现的、接收来自该隧道的、对于该隧道的乘客TCP流的确认时执行的算法,该算法被包含于本发明的校正方法的特定实施例中。
在步骤700中,隧道端点TEP 101被警告从乘客连接接收TCP确认消息(例如,关于图4,在由服务器110-A派遣段410之后来自客户机112-A的确认411)。
在步骤701中,在接收到与通过隧道发送的一个或更多个段数据序号(数据包)410对应的来自客户机112-A的确认411之后,对于该确认411进行分析。该确认411也可以是经典的确认(符合文件RFC793)或是SACK型(符合文件RFC2018)。在两种情况下,对于有关的流,在表格501中确定输入,所述输入的数据序号504具有小于或等于在确认411中指示的确认序号的值。然后,从表格501消除这样确定的所有条目。即使确认411是SACK型,并且表示对于某些序号发生了传送错误,也考虑由SACK型消息报告的确认序号;这意味着直到该(最大)确认序号的所有数据包410已被局域网上的隧道端点TEP 102传送,但显然具有损失。
在步骤702中,在表格510中进行搜索,所述搜索表示是否对于有关的流遵循了本发明的校正过程(即,是否已执行图6的步骤605)。在确定具有字段513的该表格的条目与运送确认411的当前连接的标识符对应的情况下,则属于遵循了本发明的校正过程的情况。
如果检验702是否定的,那么操作直接转到步骤705。如果检验702是肯定的,则在步骤703中提炼搜索,验证确认411的确认序号与所应用的校正措施具有一个比率。如果存在与由确认411确认的序 列对应的还满足字段准则514的表格510的条目,那么执行步骤704。如果采取SACK选项,那么必须相当平等地在确认411的确认的序列的SACK消息列表中(肯定的确认与不使用SACK选项的经典情况对应)或在错误序列的(SACK消息的)列表中包含字段514(在这种情况下,一段已损失并且必须通知服务器)。
步骤704包含擦除在超时的列表510中规划的条目,以便停止检测到隧道上的损失之后的校正测量。然后,操作转到步骤705。
步骤705的检验被用于求证是否过去对当前的乘客流采取了校正措施,以便不使产生确认消息412之后的该TCP连接不稳定(对于产生,参照图8)。进行搜索以求证是否在用于对由本发明产生的确认消息412进行计数的表格520中识别该流。
如果检验705是否定的,那么不对将在LAN 103上正常发送的确认411执行过滤(步骤708)。
如果检验705是肯定的,那么执行步骤706的检验,以求证确认411是否确认已在LAN 103上对其产生确认412的段。
如果检验706的结果是否定的,那么进行检查(步骤707的检验),以求证确认消息411是否确认比由记录在表格520中的确认序号确认的数据序号大的数据序号。换句话说,进行检查,以求证确认411是否确认包括表格520中所考虑的数据段的若干个数据段410。如果检验707的结果是肯定的,那么表格520中的当前输入被消除(步骤711),并且,将在LAN 103上正常发送确认411(步骤708)。如果步骤707是否定的,那么操作直接转到步骤708。
如果检验706的结果是肯定的,那么当前确认411正好与由本发明产生的确认412对应(参见图8)。确认411的接收的统计数据被更新(在步骤709中使字段525递增),并且进行检查以求证是否可以在LAN 103上没有问题地中继当前确认411(步骤710的检验)。
因此,只要它还没有接收到比产生的确认412更多的确认411(检验710是否定的),确认411就被破坏(用步骤712的过滤)。如果接收到更多的确认411(检验710的结果是肯定的),那么意味着本 发明已在TCP服务器110将接收的确认的数量上恢复平衡,并且,可以采取消除由产生“假想的”确认412引起的二次效果的措施:本发明转到以上已描述的步骤711。
优选地(在图7中没有示出),如果确认411为SACK型确认,则对于在确认411中参照的数据序列中的每一个,本发明以迭代的方式前进到上述的其余步骤705~708(确认为主动的或不为主动的)。
图8呈现出在隧道端点TEP(例如101)上实现的在表示用于产生确认消息412并将其发送给本地TCP服务器的第一日期t1(参见图6的步骤604和605)的超时期满时执行的算法,该算法被包含于本发明的校正方法的特定实施例中。
在步骤801中,确定需要确认412产生动作的编程表510的条目。
对于每个确定的条目(步骤802的检验),执行步骤803~809的序列。
在步骤803中,从不同的表格找回对于产生确认消息412所需要的参数:
-表格510表示有关的流(字段513)和必须对其产生确认412的确认序号(字段514);
-从流513的标识符和表格550开始,字段552~555使得能够形成消息的IP头部,并且,字段556表示所支持的确认的类型。作为默认情况,可以恒定地使用根据标准RFC793的经典类型,但是,当服务器支持时,推荐优选使用SACK支持。
步骤804创建确认消息412(根据现有技术)并将其发送到局域网103上。
然后,可从表格510消除当前条目(步骤805),并且,在表格520中将确认消息产生统计数据412递增(步骤806)。如果需要的话,在表格510中创建新的条目,其中字段524为1并且字段525为0。
作为预防措施,尽量随后创建确认消息412的新的产生是重要的。事实上,步骤804的这种产生克服隧道中的简单损失,但是希望设想隧道花费多于一个的RTT来进行恢复的情况。因此,步骤807的检验 验证新产生确认消息412的可能性,并且,步骤808然后计算对于在LAN 103上发送新的确认消息412所推荐的日期t2。
首先,进行检查,以求证是否可以通过组合以下的两个条件产生消息:
条件1:N必须大于或等于1
N=Nb_packet_410-Nb_packet_412;其中:
“Nb_packet_410”是在隧道上运送的数据包410的数量(比由表格520的当前条目的字段523的确认序号确认的数据序号大的数据序号),因此在表格501中被参照;并且,
“Nb_packet_412”是所产生的确认数据包412的数量(表格520的当前条目的字段524的值)。
换句话说,条件1也可被表示如下:
Nb_packet_410>Nb_packet_412。
条件2:“Nb_packet_412”必须小于等于3。
事实上,如果要产生多于3个的相同的确认消息412,那么这些相同的确认消息的第四个确认消息会被视为第三个重复确认消息(“重复ACK”),并且服务器会将其解释为传送错误(这是要避免的)。
如果上述的两个条件没有得到验证,那么对于当前条目完成该过程(返回到步骤802)。
如果上述的两个条件得到验证,那么实现步骤808。为确认消息412的产生而规划的新日期t2被获得如下:
t2=current_data+2·RTT-Δ
其中,Δ是若干毫秒的安全裕度(例如,隧道RTT的10%),并且,“current_data”是前一确认产生日期412(即t1)。
一旦发送日期t2被确定,就在步骤809中规划新的发送操作。
与第一发送日期t1类似,对于应用步骤808和809的隧道的各乘客流,用于发送确认消息412的第二日期t2严重取决于隧道的RTT的连续测量的值(所有的乘客流共用的参数)以及日期t1(为每个流所特定)。因此,使第二超时的激活(确定t2)对于每个流是特定的, 并使其与该流的活动性协调,以尽可能不具有侵扰性。
很显然,对于由本发明的算法选择的流、对于服务器110-A、110B和客户机112-A、112-B之间的TCP连接的任何传送(检测到TCPSYN-END消息,参见附录)停止自动地停止图8的算法的建立。为此,(在图中没有示出),只要TCP连接一停止,表格550、501、510和520就摆脱参照关闭的TCP连接的条目。
图9提供实现本发明的算法的隧道端点101的PEP系统的功能体系结构的示意图。
隧道端点TEP 101主要通过具有LAN 103的两个通信端口即输入端口910和输出端口920形成。在实际中,这两个端口具有相同的以太网型双向物理接口(根据图10的网络端1020)。
这两个端口连接到隧道的TCP信道930,所述TCP信道930连接两个LAN 103和104,并且通过具有封装隧道帧中的乘客流的任务的多路复用器931和具有对由隧道的TCP载体运送的帧进行解封的任务的解多路复用器932进行通信。
在以太网帧从LAN 103到达时,流选择器TCP 911负责应用参照图6的步骤600详细描述的选择措施。
如果进入的帧与未选择的TCP流有关,那么该以太网帧被提供给多路复用器931,以便被封装且在隧道中被发送。
如果进入的帧与所选择的TCP流有关,那么代理912分析运送的TCP段的类型(DATA或ACK)并更新表格550和501的统计数据。
在发生来自隧道的控制器940的传送错误报警时,用于产生确认消息412的PEP系统913实现在图6中描述的算法。该PEP系统913内部的超时机构(表格510)的设定将在适当的时刻重新激活图8的算法的过程。
相反,在从隧道接收到帧时,解多路复用器932将原始以太网帧给予流开关933。流开关933然后负责检查以证实该帧是否涉及TCP连接。如果该检查是肯定的,那么它负责检查以证实该TCP连接是否被监视(搜索与TCP流选择器911相同的准则)。如果情况不是如此, 那么通过输出接口模块936在局域网103上传送以太网帧。
否则,它被传送给负责更新连接的统计数据的模块934(图7的算法的步骤701)。模块935然后执行图7的算法,特别是用过滤掉(消除)消息411的能力的算法。将通过输出接口模块936在LAN 103上发送不与已对其传送确认消息412的确认消息411对应的任何以太网帧。模块935还将所接收的确认消息411的超时机构的激活/禁用通知给PEP系统913(如参照图7,描述的那样)。
图10示出适于实现本发明的技术的特定实施例的一般通信设备1000的示意性配置。例如,上面参照图1提到的隧道端点101或102与一般设备1000相同。
该一般设备1000尤其可与连接到图形卡并向一般设备1000传递多媒体信息的用于存储图像、视频或声音的任何装置连接。
该一般设备1000具有连接有以下部件的通信总线1002:
-中央处理单元1003(例如,标记为CPU的微处理器);
-标记为ROM的只读存储器1004,其能够包含上述的一个或多个软件程序;
-随机存取存储器1006(标记为RAM的高速缓冲存储器),其包含适于记录在上述的一个或多个软件程序的执行过程中创建和修改的变量和参数的寄存器;
-通信接口1018,其与例如(在图1的情况下)LAN 103/104和因特网107的至少两个分布式通信网络1020链接,该接口能够用这些网络传送和接收数据。
该一般设备1000还具有(但这是任选的):
-屏幕1008,其用于观察数据和/或用作与网络管理员的图形用户界面,该网络管理员可通过使用键盘1010或诸如例如鼠标1011或光笔的指示装置之类的任何其它装置与根据本发明的一个或多个程序交互作用;
-硬盘驱动器1012,其能够包含上述的程序;
-外部盘驱动器1014,其使得能够读取USB存储棒。
通信总线1002使得能够在包括在一般设备1000中或与该设备连接的不同装置之间实现通信和相互协作性。更一般地,通过通信总1002,中央处理单元1003可直接地或通过另一一般设备将指令传送到包含在该一般设备1000中的任何设备。
以上提到的、使得一般设备1000能够实现根据本发明的一个实施例的方法(用于管理PEP机构的方法)的各程序的可执行代码可被存储在例如硬盘驱动器1012、只读存储器1004或USB棒1016的非易失性存储器中。
中央处理单元1003控制并指导根据本发明的一个实施例的一个或多个程序(用于管理PEP机构的方法)的软件代码的指令或部分的执行。当设备被加电时,存储在上述的非易失性存储器(1012、1004或1016)中的一个或多个程序被传送到随机存取存储器1006,该随机存取存储器1006于是将包含本发明的一个或多个程序的可执行代码,以及所述一个或多个程序被传送到寄存器以记忆实现本发明的方法的该实施例所需要的变量和参数。
必须注意,包含根据本发明的设备的通信装置也可以是被编程的设备。该设备于是包含例如硬件接线到专用集成电路(ASIC)中的一个或多个计算机程序的代码。
附录:关于TCP协议的提醒
TCP协议(由RFC793标准定义的传送控制协议)是为了根据主要的速度和质量准则在因特网上提供数据传送而创建的ARQ型协议。使用至少两个机构来管理到达接收器的过剩通信量:第一个机构使用缓冲接收存储器,第二个机构建立流的控制。
TCP协议被用于可靠地传送数据,尽管它使用不包含数据报传递控制的IP协议。事实上,TCP协议具有接收确认系统,也称为确认系统或ACK,该接收确认系统被客户机(也称为客户机设备或接收机)和服务器(也称为服务器设备或发送机)使用以确保数据的有效相互 接收。当发送数据段(也称为数据的数据包)时,次序号(也称为数据序号)与该数据段相关联。在接收到数据段时,接收机将返回标记ACK为1的数据段(为了报告这是接收的确认),其伴随等于所接收的段的数据序号加1的接收号码(也称为确认序号)的确认。事实上,确认序号与等待的下一段的数据序号(而并非所接收的最后一段的数据序号)相对应。
由于通过数据传送和对接收的确认所实施的通信处理基于数据次序号(或序号),因此发送机和接收机(分别为服务器和客户机)必须知晓其它机器的初始次序号(称为初始序号或ISN)。
建立连接
以三个阶段建立TCP连接:
-在第一阶段中,客户机发送包含SYN标记(或SYN消息)的数据段以报告它是具有其初始数据序号(1SN=x)的同步段。
-在第二阶段中,服务器接收来自客户机的同步段,然后向其发送对接收的确认,即包含其自身的序号(ISN=y)的、标记ACK为1并且标记SYN为1的数据段,但是,它还必须确认前一数据包,它用包含客户机的初始序号加1(ack=x+1)的接收号码(确认序号)的确认来完成这一点。
-在第三阶段中,客户机向服务器发送对接收的确认,即,由于不再是同步段因此其是标记ACK为1并且标记SYN为0的段。其次序号(数据序号)加1(seq=x+1),并且,确认接收号码(确认序号)表示服务器的初始序号(数据序号)加1(ack=y+1)。
一旦完成称为“三次握手”的该阶段,两个应用就能够交换保证建立连接的字节。
流控制在预期的接收方的级上管理诸如存储器和进程之类的资源的分配。一般地,与流控制相符,目的地对由向目的地发送数据的所有的源实现的传送吞吐率设定限制。源和目的地通过交换包含询问和对接收的确认的消息来协调数据的传送。在源开始发送数据包之前,它向要获得开始传送的许可的目的地发送请求。响应该询问,目的地 发送这样的消息,所述消息包含源在没有附加的授权的情况下可向目的地传送的数据包的数量的标识。该数量一般被称为“窗口尺寸”。然后,源向目的地发送授权的数据包的数量,并等待目的地验证它们的接收。在目的地成功接收到数据包之后,它向源发送返回消息,所述返回消息包含接收确认(确认),所述接收确认指示已成功接收数据包,并且在一些情况下允许源发送另一数据包。因此,网络上的从源向目的地行进的数据包的数量决不超过授权的窗口尺寸。
以下,应注意TCP窗口的不同名称:
-TCP窗口:在建立连接期间生效的初始值,该初始值是在连接的整个持续过程中容许的最大值;
-拥塞窗口(CWND):在寻址到客户机的TCP数据包中从服务器发送的当前窗口的值;
-确认窗口(确认窗口或告知窗口):在ACK TCP数据包中向服务器发送的窗口的值,该值表示客户机的一部分上的存储器占用;
-滑动窗口:服务器内部的窗口的值,该值使其能够知晓自从最后的确认TCP段到达起要传送的数据的条数。
大的TCP窗口尺寸鼓励发送。如果所接收的数据的条数比窗口所指示的大,那么窗口外数据被拒绝。该损失导致大量的重新传送并且不必要地对网络和TCP带来过重的负担。使用小尺寸窗口通过添加对于往返时间或RTT的某些附加延迟而破坏吞吐率,但是这样做限制由于重新传送导致的网络的过载。非常小的窗口的打开还通过增大头部相对于数据的权重降低性能。
甚至在建立了这些机构的情况下,在繁忙的网络中,若干个源也同时在网络中向多于一个的目的地发送流。如果在非常短的时间段中太多的这种流聚集在单一的路由器上,那么该路由器的缓冲存储器中的有限容量使得该流的量不能被处理,并且,该路由器将拒绝或破坏数据包的一部分。当出现这种情况时,认为网络是拥塞的。当出现这种情况时,网络中的传送显著放慢,并且网络的吞吐率下降。由于网络的某些资源专用于重新传送,因此,当网络承受过重的负担时,发 生拥塞传播和整个网络阻塞的风险很大。
TCP MSS(最大段尺寸)字段的值表示本地系统可接受的每个IP数据报的TCP数据的最大量。当发送时,IP数据报可被分成若干个数据包。在理论上,该值可达到值65495。但是,这种大的值从不被实施。一般地,终端系统使用MTU接口(外出接口最大传送单元),从中扣除值40作为其TCP MSS字段值。例如,用于以太网协议的TCP MSS字段值为1460(1500-40=1460)。
使TCP MSS字段的值进入被用于建立连接的、作为包含信号SYN的数据包的数据包中。各方发送其自身的TCP MSS字段值。不要求各方使用相同TCP MSS字段值,但是,各方不能发送比远程站授权的数据更多的数据。以TCP头部选项的最大段尺寸(MSS)发送TCP MSS字段的值。
应注意,连接接口的缓冲存储器的尺寸的缺省值随实现而大大不同。对于TCP接收和发送缓冲存储器,从Berkeley得到的较早的实现指示4Kb的缺省值,而更新的系统实现更大的值(例如,达64Kb)。例如,在Windows XP(注册商标)中,接收时的窗口尺寸的当前值根据当建立TCP连接时协商的最大段尺寸(MSS)的对增量而得到自动调整。
流的控制
TCP协议使用几种算法来管理其拥塞,更具体而言,使用慢开始和拥塞避免算法。这些算法中的每一个通过操作限制在给定的时间点运送的未确认的字节的数量的拥塞窗口(CWND),管理服务器的发送吞吐率。通过接收确认的速度来确定对于给定的拥塞窗口值的可能的TCP吞吐率。在发送一条数据之后接收确认所花的时间称为TCP往返时间(RTT)。
当开始连接时,为了尽可能快地获得带宽的值,建立慢开始算法以迅速增大拥塞窗口(CWND)。服务器维持可变SSTHRESH(稳态阈值),以便区分这两个阶段。当发送器推断存在段的损失时,它将该信息作为网络过载的隐含信号进行处理,并迅速减小拥塞窗口。 在大致推断了拥塞阈值SSTHRESH之后,TCP建立更慢地增大拥塞窗口的值的拥塞避免算法,以便占有可用的附加带宽。
在慢开始阶段期间(当开始连接时或在已超过超时之后),起动器以1MSS的CWND窗口设定操作开始,并且在确认的每个接收之后,CWND增加1*MSS。拥塞窗口CWND在每个RTT大致加倍(指数增长)。在拥塞避免阶段(拥塞避免)期间,CWND的增大限于1*MSS乘以RTT(加性增长)。
在存在长的传播时间的因特网中,性能的下降是显著的。这防止传送窗口迅速发送新的段(确认确定传送窗口的尺寸的增大,并且它们在长的时间段之后到达)。
拥塞和重复确认(重复ACK)的检测
对于TCP连接,如果服务器装置接收到具有相同的确认序号的若干个ACK,那么使用的术语是“重复确认”(或重复ACK)。于是,服务器重新传送与规定的数据序号对应的数据段。在发送数据段之后确定的时间段期间,即使在服务器未接收到其它的ACK(具有另一确认序号)的情况下,服务器未接收到重复ACK,服务器也重新传送该未确认的数据段。
一般地,在无序地接收到数据段时(即,当它接收具有比期望的数据序号大的数据序号的数据段时),TCP客户机发出重复确认或重复ACK。重复ACK的目的是通知服务器数据段被无序接收,并告诉它所期望的数据序号。重复ACK的突发是传送路径上的损失数据段和/或数据段的重新调度的结果。
快重新传送和快恢复算法
对于对由重复ACK的接收识别的数据包损失的快速检测和反应,TCP协议使用在IEFT RFC2581因特网标准中描述的快重新传送算法(机制)。快重新传送算法将三个重复ACK的到达(事实上是四个相同的确认或ACK,且没有表示假定的问题已回到正常的任何其它确认)视为已损失数据段的指示。如果接收到少于三个的重复ACK,那么认为是这样的情况:它是已解决的数据包的解调度的简短问题,并 且其后跟随对有关的数据段的确认。在接收到这三个重复ACK时,服务器将不等待其RTO的期满或重新传送超时,而重新传送丢失的数据段。
然后,启动快恢复算法以管理新数据的传送,直到非重复ACK的接收。由于TCP客户机仅在另一数据段到达时才可发送重复ACK,因此,这意味着,尽管如此,一个数据段(但不是所预期的数据段)仍然被接收并且不再使用网络中的任何资源。因此,在网络上总是存在一些活动性,并且TCP服务器可继续传送新的数据段(在拥塞窗口CWND减小的情况下继续传送)。
在TCP服务器上联合建立上述的两个算法(快重新传送算法和快恢复算法)如下:
1.在接收到第三个重复ACK时,值SSTHRESH被修改以不超过以下的最大值:
SSTHRESH=max(FlightSize/2,2*MSS)
其中,
-值“FlightSize”(飞行尺寸)给出服务器还没有从客户机接收确认的运送中的数据包的估计;
-值MSS指示本地系统可在传送路径上接受的每个IP数据报的TCP数据的最大量。
2.被认为损失的段的重新传送和在(SSTHRESH+3*MSS)时的拥塞窗口的更新。这以已在网络上出去并且被客户机正确接收的段(3)的数量增大拥塞窗口。
3.对于由服务器接收的每个新的重复ACK,拥塞窗口CWND增大1*MSS。
4.如果允许传送数据段的话,则以拥塞窗口CWND的新值且以由客户机表示的确认窗口(“告知窗口”)的值传送数据段。
5.在接收到确认客户机在重新传送的起点接收到数据段的下一ACK时,拥塞窗口CWND减小到在步骤1中计算的值SSTHRESH。该ACK消息当然已在重新传送之后的1个RTT之前达到(或者,如果问题的原因为数据段向客户机的无序传递,那么甚至更早)。从而, 由于TCP比特率下降到当发生损失时施行的比特率的一半,因此存在拥塞避免的阶段。
最普遍的TCP选项
选择性确认(SACK)
SACK选项是用于实现选择性重新传送的策略的TCP协议选项[RFC2018]。该选项针对为损失的恢复提供更深入的信息。事实上,累积的主动的ACK给予有限的信息,并且,TCP源了解每个RTT仅存在一个数据包损失。SACK扩展给予超出该限制的TCP协议手段。
只要接收器(客户机)一觉察到TCP流的次序破坏,就实现SACK机构。然后,接收器向发送器发送回选择性确认(选择性ACK),所述选择性确认(选择性ACK)包含依次接收的最后的字节数(TCP实体的常规ACK字段)和被用于表示在当前的窗口中观察的最后的次序破坏的位置的正确接收的邻近字节范围的列表。
选择性确认[根据RFC2018]被用于克服每个窗口若干段的损失,而不需要对每个损失执行一个或更多个往返。
“有限传送”算法
如上所述,在接收到三个重复ACK之后执行对于给定的段的重新传送。如果对于以下的段存在其它的损失,那么它将在接收到最后的邻近的序号的情况下在接收到正确的ACK之前采取又一个RTT。要认识到识别的段已损失,需要三个另外的重复ACK。
取决于当前的CWND窗口,可能发生这样的情况:不允许服务器发送用于产生所有必需的重复ACK的足够数量的数据段。
RTO因此将期满,并且服务器将进入慢开始模式。
标准RFC3042(Enhancing TCP’s Loss Recovery Using LimitedTransmit,通过使用有限传送增强TCP的损失恢复)目的是减少这些超时的数量。有限传送算法因此推荐服务器对于所接收的最后两个重复ACK中的每一个发送数据段。该方法增大客户机将能够发送通知错误所需要的三个重复ACK的概率。
可以以与SACK机构结合或分开的方式使用有限传送机构。
Claims (18)
1.一种用于管理隧道的传输信道上的数据流的传送的方法,各流的传送是根据以数据包调度并具有确认的传输协议在所述传输信道上执行的,隧道是在分别与第一和第二子网连接的第一和第二隧道端点之间实现的,各流从发送器设备向接收器设备传送,所述发送器设备和所述接收器设备中的一个设备与第一子网连接,并且另一个与第二子网连接,所述方法通过所述第一隧道端点执行,并且,该方法包括以下步骤:
-检测隧道的传输信道上的数据包的损失;
-识别具有由于所述损失而在隧道的传输信道上被阻塞的至少一个数据包的至少一个流;
-对于至少一个被识别的流,产生至少一个确认并将其传送给在隧道上传送了由于所述损失而被阻塞的数据包的发送器设备,所述至少一个确认是对所述被识别的流的数据包的确认,所述发送器设备在接收到所述至少一个确认时复位其重新传送超时RTO。
2.根据权利要求1的方法,其中,对于至少一个给定的被识别的流,所述至少一个产生的确认是对所述被识别的流中在由于所述损失而被阻塞的第一个数据包之前的数据包的确认,并且其中,对于已检测到其损失的数据包所属的被识别的流,由于所述损失而被阻塞的第一个数据包被视为是在检测到该损失之后在隧道的传输信道上重新传送的数据包。
3.根据权利要求1的方法,其中,对于至少一个给定的被识别的流,产生并传送至少一个确认的所述步骤包含以下的步骤:
-根据与传送所述给定的被识别的流的发送器设备相关联的重新传送超时的持续时间的估计,并且,根据由所述第一隧道端点处理由于所述损失而被阻塞的所述被识别的流的第一个数据包之前的数据包的处理时刻,确定发送第一确认的第一发送时刻t1;
-在所述第一发送时刻t1传送所述第一确认。
4.根据权利要求3的方法,其中,所述第一发送时刻t1由t1=t0+RTO′-Δ定义,其中,
-t0是在所述第一隧道端点中处理由于所述损失而被阻塞的所述被识别的流的第一个数据包之前的数据包的所述处理时刻;
-RTO′是与传送所述给定的被识别的流的发送器设备相关联的重新传送超时的持续时间的所述估计;
-Δ是预定的安全裕度。
5.根据权利要求4的方法,其中,对于至少一个给定的被识别的流,产生并传送至少一个确认的所述步骤包含以下步骤的至少一次迭代:
-确定发送新的确认的新的发送时刻t2,该新的发送时刻t2由t2=t1+RTO′-Δ定义,其中,t1对于第一次迭代是所述的第一发送时刻,或者,对于从第二次迭代开始的每次迭代,t1是在前一次迭代确定的新的发送时刻t2;
-在所述新的发送时刻t2传送所述新的确认。
6.根据权利要求4的方法,其中:RTO′=2·RTT,RTT为隧道上的往返持续时间的测量结果。
7.根据权利要求1的方法,其中,对于至少一个给定的被识别的流,在产生并传送至少一个确认的所述步骤中,仅当以下的第一条件得到验证时产生并传送确认:在隧道的传输信道上运送并由于所述损失而被阻塞的所述给定的被识别的流的数据包的数量大于对于所述给定的被识别的流由所述第一隧道端点产生和传送的确认的数量。
8.根据权利要求1的方法,其中,对于至少一个给定的被识别的流,在产生并传送至少一个确认的所述步骤中,仅当以下的第二条件得到验证时产生并传送确认:对于所述给定的被识别的流由所述第一隧道端点产生并传送的确认的数量小于或等于对于传送所述给定的被识别的流的发送器设备指示数据包损失的预定的阈值。
9.根据权利要求1的方法,其中,对于至少一个给定的被识别的流,该方法包括过滤所述第一隧道端点已对其产生并传送了确认的所述给定的被识别的流的经由隧道从接收器设备到来的确认的步骤。
10.一种第一隧道端点,该第一隧道端点使得能够管理隧道的传输信道上的数据流的传送,各流的传送是根据以数据包调度并具有确认的传输协议而在所述传输信道上执行的,该隧道是在分别与第一和第二子网连接的所述第一隧道端点和第二隧道端点之间实现的,各流是从发送器设备向接收器设备传送的,所述发送器设备和所述接收器设备中的一个设备与第一子网连接,并且另一个与第二子网连接,其中,所述第一隧道端点包含:
-用于检测隧道的传输信道上的数据包的损失的装置;
-用于识别具有由于所述损失而在隧道的传输信道上被阻塞的至少一个数据包的至少一个流的装置;
-用于对于至少一个被识别的流产生至少一个确认,并将其传送给在隧道上传送了由于所述损失而被阻塞的数据包的发送器设备的装置,所述至少一个确认是对所述被识别的流的数据包的确认,所述发送器设备在接收到所述至少一个确认时复位其重新传送超时RTO。
11.根据权利要求10的第一隧道端点,其中,对于至少一个给定的被识别的流,所述至少一个产生的确认是对所述被识别的流的由于所述损失而被阻塞的第一个数据包之前的数据包的确认,
并且其中,对于已检测到其损失的数据包所属的被识别的流,由于所述损失而被阻塞的第一个数据包被视为是在检测到损失之后在隧道的传输信道上重新传送的数据包。
12.根据权利要求10的第一隧道端点,其中,用于产生并传送至少一个确认的所述装置包含:
-用于对于至少一个给定的被识别的流,根据与传送所述给定的被识别的流的发送器设备相关联的重新传送超时的持续时间的估计,并且,根据由所述第一隧道端点处理由于所述损失而被阻塞的所述被识别的流的第一个数据包之前的数据包的处理时刻,确定发送第一确认的第一发送时刻t1的装置;
-用于在所述第一发送时刻t1传送所述第一确认的装置。
13.根据权利要求12的第一隧道端点,其中,所述第一发送时刻t1由t1=t0+RTO′-Δ定义,其中:
-t0是在所述第一隧道端点中处理由于所述损失而被阻塞的所述被识别的流的第一个数据包之前的数据包的所述处理时刻;
-RTO′是与传送所述给定的被识别的流的发送器设备相关联的重新传送超时的持续时间的所述估计;
-Δ是预定的安全裕度。
14.根据权利要求13的第一隧道端点,其中,用于产生并传送至少一个确认的所述装置包含被激活至少一次的以下装置:
-用于对于至少一个被识别的流确定发送新的确认的新的发送时刻t2的装置,该新的发送时刻t2由t2=t1+RTO′-Δ定义,其中,t1对于第一次迭代是所述的第一发送时刻,或者,对于从第二次迭代开始的每次迭代,t1是在前一次迭代确定的新的发送时刻t2;
-用于在所述新的发送时刻t2传送所述新的确认的装置。
15.根据权利要求13的第一隧道端点,其中,RTO′=2·RTT,RTT为隧道上的往返持续时间的测量结果。
16.根据权利要求10的第一隧道端点,还包括:
-第一验证装置,该第一验证装置用于对于至少一个给定的被识别的流验证以下的第一条件:在隧道的传输信道上运送并由于所述损失而被阻塞的所述给定的被识别的流的数据包的数量大于对于所述给定的被识别的流由所述第一隧道端点产生和传送的确认的数量;
-用于如果所述第一验证装置做出肯定的验证则对于所述至少一个给定的被识别的流激活用于产生并传送至少一个确认的所述装置的装置。
17.根据权利要求10的第一隧道端点,还包括:
-第二验证装置,该第二验证装置用于对于至少一个给定的被识别的流验证以下的第二条件:对于所述给定的被识别的流由所述第一隧道端点产生并传送的确认的数量小于或等于对于传送所述给定的被识别的流的发送器设备指示数据包损失的预定的阈值;
-用于如果所述第二验证装置做出肯定的验证则对于所述至少一个给定的被识别的流激活用于产生并传送至少一个确认的所述装置的装置。
18.根据权利要求10的第一隧道端点,还包括对于至少一个给定的被识别的流,过滤所述第一隧道端点已对其产生并传送了确认的所述给定的被识别的流的经由隧道从接收器设备到来的确认的装置。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
FR0854784 | 2008-07-11 | ||
FR0854784A FR2933834A1 (fr) | 2008-07-11 | 2008-07-11 | Procede de gestion d'une transmission de flux de donnees sur un canal de transport d'un tunnel, tete de tunnel, produit programme d'ordinateur et moyen de stockage correspondants. |
Publications (2)
Publication Number | Publication Date |
---|---|
CN101635665A CN101635665A (zh) | 2010-01-27 |
CN101635665B true CN101635665B (zh) | 2012-03-21 |
Family
ID=40030273
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2009101401963A Expired - Fee Related CN101635665B (zh) | 2008-07-11 | 2009-07-10 | 管理隧道的传输信道上的数据流的传送的方法及隧道端点 |
Country Status (7)
Country | Link |
---|---|
US (1) | US8072898B2 (zh) |
EP (1) | EP2144403B1 (zh) |
JP (1) | JP5005003B2 (zh) |
CN (1) | CN101635665B (zh) |
AT (1) | ATE507636T1 (zh) |
DE (1) | DE602009001149D1 (zh) |
FR (1) | FR2933834A1 (zh) |
Families Citing this family (22)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP4692355B2 (ja) * | 2006-03-30 | 2011-06-01 | ブラザー工業株式会社 | 情報通信システム、情報通信方法、情報通信システムに含まれるノード装置および情報処理プログラム |
WO2009055722A1 (en) * | 2007-10-24 | 2009-04-30 | Jonathan Peter Deutsch | Various methods and apparatuses for accessing networked devices without accessible addresses via virtual ip addresses |
FR2939993B1 (fr) * | 2008-12-12 | 2010-12-17 | Canon Kk | Procede de transmission d'un flux de donnees multi-canal sur un tunnel multi-transport, produit programme d'ordinateur, moyen de stockage et tetes de tunnel correspondantes |
US10033779B2 (en) * | 2009-07-08 | 2018-07-24 | Dejero Labs Inc. | Multipath data streaming over multiple wireless networks |
US9756468B2 (en) | 2009-07-08 | 2017-09-05 | Dejero Labs Inc. | System and method for providing data services on vehicles |
US10117055B2 (en) | 2009-07-08 | 2018-10-30 | Dejero Labs Inc. | System and method for providing data services on vehicles |
US8625622B2 (en) * | 2009-12-25 | 2014-01-07 | Cisco Technology, Inc. | Increasing transmission rate to a remote device in response to attributing information loss as not being a result of network congestion |
KR101413295B1 (ko) * | 2010-11-04 | 2014-06-30 | 한국전자통신연구원 | 확장성과 적응성을 가지는 dds 구조 및 dds를 구성하는 노드 |
KR101741003B1 (ko) * | 2011-01-28 | 2017-05-30 | 삼성전자주식회사 | 중복된 애크를 이용한 통신 방법 |
JP5963540B2 (ja) * | 2012-05-30 | 2016-08-03 | キヤノン株式会社 | 情報処理装置、プログラム及び制御方法 |
US20150046558A1 (en) * | 2013-03-15 | 2015-02-12 | Google Inc. | System and method for choosing lowest latency path |
EP3021555B1 (en) | 2013-07-12 | 2018-09-12 | Huawei Technologies Co., Ltd. | Message processing method and device |
US20150095196A1 (en) * | 2013-09-30 | 2015-04-02 | Jewel Burks | Method for Identifying Replacement Parts and Extracting Features Via a Sequence of Images |
WO2015068457A1 (ja) * | 2013-11-06 | 2015-05-14 | 日本電気株式会社 | 移動通信システム、ゲートウェイ装置、コアネットワーク装置、通信方法 |
US9936406B2 (en) | 2013-11-08 | 2018-04-03 | Telefonaktiebolaget Lm Ericsson (Publ) | Handling of transport conditions |
JP6099773B2 (ja) * | 2014-01-28 | 2017-03-22 | 三菱電機株式会社 | 衛星通信システム、ゲートウェイ、通信網制御局及び衛星通信方法 |
JP5970489B2 (ja) * | 2014-01-30 | 2016-08-17 | 株式会社Nttドコモ | 移動通信システム及び移動局装置 |
US9742587B2 (en) * | 2015-07-29 | 2017-08-22 | Oracle International Corporation | Negative acknowledgment of tunneled encapsulated media |
US10805420B2 (en) * | 2017-11-29 | 2020-10-13 | Forcepoint Llc | Proxy-less wide area network acceleration |
CN108833063B (zh) * | 2018-08-29 | 2021-04-27 | 新华三技术有限公司 | 一种报文重传方法及装置 |
CN112585910B (zh) * | 2020-09-15 | 2022-03-08 | 香港应用科技研究院有限公司 | 在广域网中建立安全、低延迟、优化路径的方法和装置 |
US11743193B2 (en) | 2021-11-01 | 2023-08-29 | Seagate Technology Llc | Sliding window protocol for communication among more than two participants |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030172264A1 (en) * | 2002-01-28 | 2003-09-11 | Hughes Electronics | Method and system for providing security in performance enhanced network |
US20060002301A1 (en) * | 2001-04-04 | 2006-01-05 | Changwen Liu | Transferring transmission control protocol packets |
CN1956353A (zh) * | 2005-10-28 | 2007-05-02 | 华为技术有限公司 | 基于隧道进行流管理的方法和无线接入中转系统 |
CN101064662A (zh) * | 2006-04-26 | 2007-10-31 | 阿尔卡特朗讯 | 用于标准化网络的互通的方法和架构 |
Family Cites Families (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP3727198B2 (ja) | 1999-07-21 | 2005-12-14 | 沖電気工業株式会社 | ゲートウェイ装置 |
US6208620B1 (en) * | 1999-08-02 | 2001-03-27 | Nortel Networks Corporation | TCP-aware agent sublayer (TAS) for robust TCP over wireless |
US7213077B2 (en) * | 2000-07-21 | 2007-05-01 | Hughes Network Systems, Inc. | Method and system for providing buffer management in a performance enhancing proxy architecture |
US7089312B2 (en) * | 2001-09-20 | 2006-08-08 | Intel Corporation | System and method for reducing retransmissions due to tunneled TCP-in-TCP communication in a network |
EP1333642B1 (en) * | 2002-01-28 | 2008-08-20 | Hughes Network Systems, LLC | Method and system for integrating performance enhancing functions in a virtual private network (VPN) |
US20030219022A1 (en) * | 2002-01-28 | 2003-11-27 | Hughes Electronics | Method and system for utilizing virtual private network (VPN) connections in a performance enhanced network |
US7656799B2 (en) * | 2003-07-29 | 2010-02-02 | Citrix Systems, Inc. | Flow control system architecture |
FR2863127A1 (fr) * | 2003-12-02 | 2005-06-03 | Canon Kk | Procedes et dispositifs pour la delivrance asynchrone de donnees numeriques |
JP4998687B2 (ja) | 2006-09-21 | 2012-08-15 | 日本電気株式会社 | 通信システム、トンネリング装置、通信方法、およびプログラム |
US7760642B2 (en) * | 2007-03-12 | 2010-07-20 | Citrix Systems, Inc. | Systems and methods for providing quality of service precedence in TCP congestion control |
FR2919778A1 (fr) * | 2007-07-30 | 2009-02-06 | Canon Kk | Procede de transmission de paquets de donnees dans un tunnel, produit programme d'ordinateur, moyen de stockage et tete de tunnel correspondants |
FR2926939A1 (fr) * | 2008-01-30 | 2009-07-31 | Canon Kk | Procede de transmission de donnees avec anticipation des acquittements, dispositif d'entree, produit programme d'ordinateur et moyen de stockage correspondants |
-
2008
- 2008-07-11 FR FR0854784A patent/FR2933834A1/fr not_active Withdrawn
-
2009
- 2009-06-19 US US12/488,402 patent/US8072898B2/en not_active Expired - Fee Related
- 2009-06-30 EP EP09164124A patent/EP2144403B1/en active Active
- 2009-06-30 DE DE602009001149T patent/DE602009001149D1/de active Active
- 2009-06-30 AT AT09164124T patent/ATE507636T1/de not_active IP Right Cessation
- 2009-07-08 JP JP2009162185A patent/JP5005003B2/ja not_active Expired - Fee Related
- 2009-07-10 CN CN2009101401963A patent/CN101635665B/zh not_active Expired - Fee Related
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060002301A1 (en) * | 2001-04-04 | 2006-01-05 | Changwen Liu | Transferring transmission control protocol packets |
US20030172264A1 (en) * | 2002-01-28 | 2003-09-11 | Hughes Electronics | Method and system for providing security in performance enhanced network |
CN1956353A (zh) * | 2005-10-28 | 2007-05-02 | 华为技术有限公司 | 基于隧道进行流管理的方法和无线接入中转系统 |
CN101064662A (zh) * | 2006-04-26 | 2007-10-31 | 阿尔卡特朗讯 | 用于标准化网络的互通的方法和架构 |
Also Published As
Publication number | Publication date |
---|---|
US20100008245A1 (en) | 2010-01-14 |
JP5005003B2 (ja) | 2012-08-22 |
FR2933834A1 (fr) | 2010-01-15 |
CN101635665A (zh) | 2010-01-27 |
DE602009001149D1 (de) | 2011-06-09 |
EP2144403A1 (en) | 2010-01-13 |
US8072898B2 (en) | 2011-12-06 |
JP2010022001A (ja) | 2010-01-28 |
ATE507636T1 (de) | 2011-05-15 |
EP2144403B1 (en) | 2011-04-27 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101635665B (zh) | 管理隧道的传输信道上的数据流的传送的方法及隧道端点 | |
US8169911B2 (en) | Method for transmitting a data stream with anticipation of acknowledgments, correspondence input device and computer-readable storage medium | |
US8462624B2 (en) | Congestion management over lossy network connections | |
Fairhurst et al. | Advice to link designers on link Automatic Repeat reQuest (ARQ) | |
US6757248B1 (en) | Performance enhancement of transmission control protocol (TCP) for wireless network applications | |
US8717900B2 (en) | Mechanisms to improve the transmission control protocol performance in wireless networks | |
US6621799B1 (en) | Semi-reliable data transport | |
JP2007534194A (ja) | パケットを再配列する際のtcp性能の改善 | |
WO2001097446A2 (en) | Enhancement of explicit congestion notification (ecn) for wireless network applications | |
US20090316719A1 (en) | Method for managing mechanisms to enhance transmission of data streams in a tunnel, corresponding computer program product, storage medium and tunnel end-point | |
US20110141904A1 (en) | Method and apparatus for transmitting packets of a two-way passenger data stream | |
US11671377B2 (en) | System and method for reducing bandwidth usage of a network | |
US7480301B2 (en) | Method, system and article for improved TCP performance during retransmission in response to selective acknowledgement | |
Peng et al. | Cross‐layer enhancement of TCP split‐connections over satellites links | |
Henderson | TCP performance over satellite channels | |
CN113424578B (zh) | 一种传输控制协议加速方法和装置 | |
Fairhurst et al. | RFC3366: Advice to link designers on link automatic repeat request (ARQ) | |
Fairhurst et al. | Link ARQ Issues for IP Traffic, IETF RFC 3366 (BCP62) | |
Callegari et al. | A Friendliness Study of TCP Linux Variants | |
Wood et al. | STATUS OF THIS MEMO |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20120321 Termination date: 20160710 |
|
CF01 | Termination of patent right due to non-payment of annual fee |