CN101112063A

CN101112063A - 能够支持保证实际无拥塞服务的网络的即刻可用实施方案:外部因特网NextGenTCP(方波形式)TCP友好SAN

Info

Publication number: CN101112063A
Application number: CNA200580047331XA
Authority: CN
Inventors: 唐鲍勃
Original assignee: Individual
Current assignee: Individual
Priority date: 2004-11-29
Filing date: 2005-11-29
Publication date: 2008-01-23
Also published as: GB0426176D0; ZA200704965B

Abstract

针对基于能够支持保证实际无拥塞服务的网络的外部因特网的即刻可用实施方案提供了对TCP/IP协议和其它敏感协议和有关网络的交换机/路由器配置进行简单修改的各种技术，而不要求使用现存的QoS/MPLS技术，且不要求所述网络内的交换机/路由器软件的任何一者被修改或促进实现端到端性能结果，且不要求在所述网络内的每一和每个节点间链路处提供无限带宽。

Description

能够支持保证实际无拥塞服务的网络的即刻可用实施方案:外部因特网NextGenTCP(方波形式)TCP友好SAN

【注意：本发明参考由同一发明者发明的在前申请的相关公开PCT申请案WO2005053265全文，参考(且/或将尚未包含在本申请案中的段落并入本文中)以下在前申请的申请案的全文：2005年3月8日的GB0504782.4和2205年5月9日的GB0509444.6，和2005年6月15日的GB0512221.3，和2005年10月12日的GB0520706.3，并主张其优先权。】

技术领域

本发明是关于一种用于改进TCP和/或类TCP协议和/或其它协议的方法。

背景技术

目前，用于促进因特网上的多媒体/语音/传真/实时IP应用以确保服务品质的RSVP/QoS/TAG切换等的实施方案受到实施复杂性的不利影响。另外，存在许多厂商的实施方案，例如使用数据包中的服务字段的类型(Type of Service field indata packet，ToS)、基于TAG的、源IP地址、MPLS等；在数据包可被转发之前，在所通过的每一QoS能力路由器处，数据包需要由交换机/路由器针对上述厂商的实施字段进行检验(因此需要被缓冲/排队)。设想在以最大传输速率运载QoS数据包的兆兆位链路中，路由器将因此需要检验(且缓冲/排队)每个到达的数据包，并花费CPU处理时间来检验上述各个字段中的任一者(例如单单要对照其进行检查的QoS优先权源IP地址表本身便可能达到几万)。因此，在重QoS数据包负载下，不能实现路由器制造商的指定通过量能力(用于转发正常数据包)，且一些QoS包将遭受严重的延迟或被丢弃，即使总数据包负载并未超出链路带宽或路由器制造商的指定数据包正常通过量能力。同时，缺乏能共同操作的标准意味着一些IP技术所承诺的对这些QoS增值服务的支持能力尚未完全实现。

发明内容

本文描述在因特网/私有因特网区段/WAN/LAN上具有更好或类似端到端接收质量的用以保证多媒体/语音/传真/实时等应用的服务品质，而不要求数据包所通过的交换机/路由器需要RSVP/标签切换/QoS能力的方法，以确保比所述技术的QoS实施方案的现存状态更好的服务保证。另外，数据包将不必需要出于检验现存QoS厂商的实施方案字段中的任一者的目的而缓冲/排队，因此避免了上文所提及的可能的丢弃或延迟情况，在甚至以链路带宽的全传输速率来转发这些有保证服务数据包时，促进了交换机/路由器制造商的指定全通过量能力。

修改现存TCP/IP堆栈以获得比现存的RTO超时时TCP/IP同时乘法速率减小和包重传机制更好的拥塞恢复/避免/预防，且/或允许保证实际无拥塞服务TCP/IP能力，且/或进一步经修改，以使得现存同时乘法速率减小超时和包重传超时，即通常所说的RTO超时，被分解成具有不同速率减小超时和包重传超时值的单独过程。

修改TCP/IP堆栈使得：

同时RTO速率减小和RTO超时时包重传事件采取具有RTO超时的特定源-目的地TCP流的包/数据单元转发和包重传中的完整“暂停”的形式，但允许针对“暂停/延长暂停”周期期间的每一完整暂停间隔而将特定TCP流(其可为RTO包/数据单元)的1个或经界定数目的包/数据单元向前转发。

针对源-目的节点对的同时RTO速率减小和包重传间隔(其中在“暂停”有效之前，对所发送的对应包/数据单元的应答仍尚未从接收TCP/IP堆栈的目的地接收回来)设定为：

(A)网络中的源与目的节点对之间的未拥塞RTT*乘数(network*multiplicant)(其总是大于1)，或源与目的节点对之间的未拥塞RTT加上足以容纳由……引入的延迟的时间间隔

或

(B)具有最大未拥塞RTT的网络中的最远源-目的节点对之间的未拥塞RTT*乘数(其总是大于1)，或具有最大未拥塞RTT的网络中的最远源-目的节点对之间的未拥塞RTT(网络中的最远源-目的节点对具有最大未拥塞RTT加上足以容纳由各种组件引入的可变延迟的间隔)

或

(C)根据某一所设计算法(例如总是大于1的*乘数)从历史RTT值动态地导出，或加上足以容纳由各种组件等引入的可变延迟引入的延迟的时间间隔，

或

(D)任何用户提供的值，例如针对视听感觉容许度的200ms或例如针对http网页下载感觉容许度的4秒等。注意，对于世界上的最远源-目的节点对之间的时间关键性视听流来说，未拥塞的RTT可为约250ms，在此情况下，这样长距离的时间关键性流的RTO设定值将高于通常的视听容许度周期且需要被允许(如在当今经由卫星的越洋移动呼叫品质的情况下)。

在上文的(A)或(B)或(C)或(D)中的RTO间隔值最高不超过实时视听的感觉容许度界限(例如200ms)的情况下，可实现保证实际无拥塞服务的网络性能。

注意，仅允许在整个完整的暂停间隔或每一连续的完整暂停间隔期间转发1个或界定数目的包/数据单元的上述对“暂停”的TCP/IP修改(代替或取代现存耦合的同时RTO速率减小和包重传)在因特网/因特网的子集/WAN/LAN上，与现存的RTO时TCP/IP同时乘法速率减小机制相比，可增强更快且更好的拥塞恢复/避免/防止，或甚至允许保证实际无拥塞服务的能力：还注意，现存TCP/IP堆栈的经耦合的同时RTO速率减小和包重传可被分解成具有不同速度减小超时和包重传超时值的单独过程。

还注意，前面段落的TCP/IP修改可由初始少数用户来增量地实施，且可能不一定对经修改的“暂停”TCP采用者具有任何显著的不利性能影响，另外，使用经修改的“暂停”TCP/IP发送的包/数据单元将极少被沿路由路径的交换机/路由器丢弃，且可被精细调节/设置使其永远不会丢弃包/数据单元。随着修改变得被多数人或普遍地采纳，现存因特网将实现保证实际无拥塞服务能力，且/或沿路由路径的交换机/路由器不会由于拥塞缓冲溢出而丢弃包。

举例来说，在网络/因特网子集/私有因特网/WAN/LAN中的所有交换机/路由器各自均具有/或设置成具有缓冲区大小的最小s秒均等物(即s秒*所有前面的输入链路的物理带宽的总和)，且起始发送器源TCP/IP堆栈的RTO超时或经分解的速率减小超时间隔被设定为相同的s秒或更少(其可在视听容许度或http容许度周期内)的情况下，从源的经修改的TCP/IP发送的任一包/数据单元均将永远不会由于介入的交换机/路由器处的拥塞缓冲溢出而被丢弃，且在最差情况下，所有均将在等于s秒*所通过的节点数目或以秒计的所有介入节点的缓冲区大小均等物的总和(其中的较大者(优选此为或可能设置为在所需的界定容许度周期内))的时间周期内到达。因此介入节点的交换机/路由器缓冲区大小均至少等于或大于起始发送器源/源的经修改的TCP/IP堆栈的等效RTO超时或经分解的速率减小超时间隔设定值将是很好的作法。当合计的介入节点的累积缓冲延迟等于或大于起始发送器源TCP/IP堆栈的RTO超时间隔或经分解的速率减小(此处以“暂停”的形式)超时间隔，起始发送器源TCP/IP堆栈将RTO超时或经分解速率减小超时，且此RTO超时或经分解速率减小超时间隔值/s可被设定/设置成在所需的界定感觉容许度间隔内。

在任何暂停周期/间隔期间所发送的单个或界定数目的包/数据单元将要进一步被排除或不被允许导致任何RTO“暂停”或经分解速率减小“暂停”事件(即使它们的对应应答随后在RTO超时或经分解速率减小超时之后较晚返回)的情况下，上述情况尤其如此。在此情况下，在最坏拥塞情况下，起始发送器源TCP/IP堆栈将在相等持续时间中的每一者期间在“暂停”与正常包传输阶段之间交替，→即在最坏情况下，起始发送器源TCP/IP堆栈将仅“减半”其传输速率，在“暂停”期间，其几乎不发送任何东西，但一旦暂停停止而重新开始，其便根据滑动窗口机制所允许的全速率来发送。

另外，在因特网/因特网子集/WAN/LAN上的所有或多数TCP/IP堆栈均这样被修改且具有设定为在所需的界定感觉容许度周期内的共同值(例如t毫秒(其中t＝网络中的最远源-目的节点对的未拥塞RTT*m乘数))的RTO超时或经分解速率减小超时间隔的情况下，在因特网/因特网子集/WAN/LAN内发送的所有的包均应到达目的地，同时经历沿路由路径的仅s*节点数目或(t-未拥塞的RTT)+t(其中较小者)总累积缓冲延迟。

这有利地与现存TCP/IP堆栈的RFC实施方案形成对比，现存TCP/IP堆栈的RFC实施方案不能保证包永远不被丢弃且进一步不可能保证所发送的所有包均在某一有用的界定容许度周期内到达。在“暂停”期间，介入路径的拥塞由此“暂停”帮助清除，且在此“暂停”期间发送的单个或较小的界定数目的包有用地探测介入路径以确定拥塞是持续还是已停止，以供经修改的TCP/IP堆栈相应地作出反应。

具体实施方式

下一代TCP：进一步改进和修改

外部因特网节点(其还可应用于内部网络节点)

应用于有保证服务因特网子集/WAN/LAN的相同经分解“暂停”/传输速率递减和实际包重传超时机制(ACK超时和包重传超时)可类似地应用于外部内部云(Internal cloud)/外部WAN/外部LAN上的外部节点。此处，使用未拥塞的RTTest(即，目前为止接收到的对应返回ACK的最新最小时间周期的变量)，代替有保证服务因特网子集/WAN/LAN内的已知未拥塞RTT值：

根据接收到的ACK(其可为所发送的通常的数据包或ICMP探测器或HDP探测器的ACK)，更新待接收的ACK的最新最小时间周期的变量(自对应包的SENT TIME起)，此未拥塞RTTest充当源与目的地之间的未拥塞的RTT值(更好是实际上已知的源与外部因特网节点之间的未拥塞RTT)的最新近估计。可了解到地球上的最远未拥塞RTT为(例如)400ms，因此可利用最大未拥塞RTTest为(例如)400ms的事实(但应注意两端均为(例如)较小56K调制解调器带宽且例如1500字节的较大包被传送的情况，因为1500字节的包花费约250ms来完全退出或进入调制解调器，因此，优选地还获得包实际上完全完成退出调制解调器的时间，以相应地调节未拥塞RTTest值)。

如果任何包的RTT(从其ACK导出)*a＞未拥塞RTTest(其中a为总是大于1的被乘数)，那么“暂停”被触发(但在“暂停”或延长的“暂停”间隔/s期间，允许1个或许多个数据包通过，或仅允许探测包通过)，或速率减小到现存速率的某一百分比(例如95％)(其可(例如)经由通信量修整技术或递减拥塞窗口大小等来实施)，和/或仅仅在随后的ACK时不递增经修改的TCP的窗口大小/拥塞窗口大小，只要最新近/随后接收到的ACK的RTT*a继续大于未拥塞RTTest或在基于所设计算法导出的界定时间周期中大于未拥塞RTTest，或上述任一者的组合。

直接针对TCP堆栈的速率递减实施方案是不重要的，但针对监视软件/IP转发模块/代理TCP等，可经由现存速率修正/速率调节技术来实施，或实施为针对监视软件/IP转发模块/代理TCP内的每一TCP流的另一窗口大小/拥塞窗口大小机制(和/或此机制的中止操作)，所述机制简单地反映特定TCP流的最新近有效窗口大小值，但当/只要特定流的最新近接收到的ACK的RTT*a继续＞未拥塞RTTest(而不是在/只要最新近接收到的ACK的RTT*a继续＞未拥塞RTTest的时间期间)便不镜像/停止镜像最新近有效窗口大小值(即此机制的启动操作)，此特定流的监视软件的窗口大小/拥塞窗口大小值(即窗口大小/所通告的窗口大小/拥塞窗口大小值中的较小者)将减小到所述流的最新近镜像的导出/计算出的当前有效窗口大小的m％(例如95％)(注意上述操作可视情况被延迟t秒，例如1秒或基于一些所设计的算法)

【注意：当在监视软件上实施时，发送器TCP拥塞窗口大小不可在缺少窗口TCP堆栈源代码的情况下在窗口平台上直接获得，因此需要从网络导出，因此可导出发送器TCP源的当前有效窗口大小(有效窗口大小＝min(窗口大小、拥塞窗口大小、接收器通告的窗口大小)。在导出/近似的当前发送器TCP源的当前有效窗口大小/拥塞窗口大小值方面存在各种现存技术方法状态。举例来说，我们可(然而)假定当未使连接溢出时，发送器TCP源的拥塞窗口大小为当前发送速率*未拥塞RTTest(即通过在监视其SENT TIME和其返回ACK TIME的每一RTT中拾取一个“特异”包来计算出的当前发送速率，当前发送速率＝(在SENT TIME与反回ACK TIME之间的在途中的字节的数目)/(返回ACK TIME-SENT TIME))，我们可假定发送器TCP源的当前拥塞窗口大小等于在途中的字节的数目。

另一实例可类似地也通过在RTT间隔内监视由监视软件转发的总字节来导出发送器TCP源的当前有效窗口大小/当前拥塞窗口大小】

在监视软件处，百分比速率递减可视情况不需要取决于如上文中那样导出/估计当前有效窗口大小，监视软件可替代地实现“暂停”(和/或允许一个或许多个包在此暂停间隔期间被转发)：

如果周期性隔开的暂停间隔在(例如)1秒内总计为P*I(I为以秒计的周期性隔开的暂停间隔)，那么实际上拥塞窗口＝(1-(p*I))/目前通过量的1秒(当前有效窗口大小*当前RTT)。

因此为了实现5％的速率递减，(P*I)应等于0.05。

此“暂停”间隔甚至可能不需要周期性地均匀间隔开，和/或每一“暂停”间隔甚至可能不需要具有相同的暂停持续时间。

实例：在距“暂停/s”时传递时间总计少5％的情况下，源-目的地的带宽延迟产物现将减小到现存值的0.95。这是因为现在在(例如)1秒内将存在少5％数目的非重叠RTT间隔来传输用于上述每一非重叠RTT间隔的至多达总有效窗口大小中所传送的数据字节的数据量。应优选将“暂停”间隔持续时间设定为至少等效于未拥塞RTTest的最小值，但可根据需要使其更小：VoIP传输中的实例每20ms(假定比未拥塞RTTest小得多)发送一个经采样的包，我们可使(例如)1秒内的50ms的单个“暂停”间隔持续时间(即，实现等效于5％有效窗口大小递减的速率递减)成为(例如)1秒内的5个均匀隔开的周期性“暂停”，此处的“暂停”中的每一者均具有持续时间10ms(以便不在时间关键性VoIP包转发中引入长延迟)；或(例如)1秒内的10个均匀隔开的周期性“暂停”，此处的“暂停”中的每一者均具有持续时间5ms，等等。

另外，发送器TCP源代码可完全利用“暂停”方法来类似地实施当前有效窗口大小设定，从而完全代替对拥塞窗口大小设定的需要：在这些经修改的TCP中，当前有效窗口大小在任何时间均将为【min(窗口大小、接收器通告的窗口大小)*((1-p*I))/1秒)】。

(当持续接收到的ACK流的RTT*a继续＞未拥塞RTTest时，不重复地递减：但另外，如果最新近接收到的ACK的流RTT*b(b总是＞a)(其例如对应于自最新近的速率递减起所发送的包)现在＞未拥塞RTTest，那么监视软件的窗口大小/拥塞窗口大小值现在可进一步视情况重复地减小到已减小到监视软件的窗口大小/拥塞窗口大小值的L％/m％的目前值的例如90/95％(L％或m％){b表示与a相比更严重的拥塞等级，或甚至包丢弃。a和b中的任一者或两者可为如此以使得它们非常有可能表示/包丢弃事件。监视软件可视情况将上述操作延迟t秒，例如1秒，使得所有的现存未经修改的TCP均将在速率递减方面同步}

和/或当某些条件成立时，例如，只要流的最新近/随后接收到的ACK的RTT*a继续＞未拥塞，就基于某一所设计的演算法而不在某周期中递增窗口大小/拥塞窗口大小。

当使用监视软件时，TCP当然继续进行其自己的慢启动/拥塞避免/耦合的RTO等。监视软件可预测/检测TCP RTO事件，例如，在非常长的周期(例如1秒等)之后还未接收到所发送区段的ACK时或根据流的发送速率突然减半等预测/检测。监视软件可进一步选择将其镜像的窗口大小/拥塞窗口大小值递减到现存的(例如)90％(n％)，且/或仅仅在基于某一所设计的演算法而导出的某一时间周期中不针对特定流递增其自己的有效窗口大小/拥塞窗口大小(例如只要最新近/随后接收到的ACK的RTT*a继续＞未拥塞RTTest)。

监视软件还可另外实施其自己的包重传超时，这要求监视软件总是保留具有动态窗口长度的所发送的包的副本和与TCP中类似的重传软件模块，因此监视软件可更快地执行上述段落的功能，而不需要等待TCP RTO指示。监视软件因此可视情况(例如)通过欺骗性发送ACK到TCP来防止迟到的ACK导致TCP处的RTO，并经由所产生的/经欺骗发送到TCP的ACK来控制/协调TCP，例如，将具有为0的经通告的接收器窗口大小的欺骗性发送的ACK设定为“暂停”TCP持续一段时间或某一所需值，以递减TCP的有效窗口大小，重复应答数目字段值＝最新发送的序列号(Seq No)值的ACK，以导致TCP减半有效窗口大小而不必要导致实际包重传等。监视软件可视情况将以上操作延迟t秒(例如1秒)，以便所有的现存未经修改的TCP均将在各种速率递减方面同步。

可设计各种不同演算法/不同演算法的组合来代替上文所说明/概述的那些算法。本技术的各种现存状态方法或组成方法可进一步结合在本文所述的方法或组成方法中的任一者内作为改进。

此处的经修改的TCP(或甚至基于UDP/经修改的UDP的经修改的RTP等)流不需要减半速率，因为它们在拥塞(在缓冲事件期间)时不需要递增速率而导致包丢弃，且传输速率中的(例如)10％/5％递减确保新的流不会不足(任何其它现存的无修改的TCP流将确保50％递减，但它们总是将努力递增速率从而再次导致包丢弃)。随着时间的过去，新的流将占据其应有份额。这还很好地保持了现存所建立流的低等待时间等(适合VoIP/多媒体)，并反映了现存传统PSTN呼叫允许进度表。

此处经修改的TCP/基于UDP的经修改的RTP/经修改的UDP保留链路带宽中它们所建立的份额，或它们所建立的份额中的大部分，但不导致进一步的额外拥塞/包丢弃。

TCP指数增加到门槛值，在门槛值之后在拥塞避免期间线性增加，滑动窗口/拥塞窗口机制等，确保瓶颈链路的拥塞发生是逐步的，因此经修改的TCP和现存未经修改的TCP可相应地反应以消除拥塞。此处经修改的TCP/基于UDP的经修改的RTP/经修改的UDP甚至可使用充足额外通信量的快速突发(例如在拥塞等级接近包丢弃时)，以确保通过特定拥塞链路的所有或选择性的现存流获得包丢弃通知，以减小传输速率：现存未经修改的TCP将减半其速率，并花费较长时间来重新回到先前的导致拥塞的传输速率，而经修改的TCP将保留它们沿链路建立的所有带宽份额中的大部分。

鼓励在公众因特网上逐渐增多地采用此简单的分解TCP修改方案将是最有帮助的。经修改的发送器TCP源将实现更高的通过量，在瓶颈链路的拥塞导致丢弃(或仅在物理传输错误导致包丢弃)时保留其建立的瓶颈链路的带宽份额，同时保存流之间的公平性(比较现存TCP，其在单个包丢弃时失去其所建立的带宽的一半)，且它们自己不会导致任何包丢弃。此经修改的发送器源TCP克服了在高带宽长等待时间网络中由仅单个包丢弃导致的现存TCP速率恢复问题。

如果发送器TCP源的通信量源自外部因特网节点/WAN/LAN，并假定外部起始通信量具有时间戳记(允许接收器TCP导出从源到目的地的路径传输时间或单向传输延迟)，那么上述经修改的发送器源TCP方法可适合于充当基于接收器的方法：

起始源的时间戳记不需要准确地与接收器同步。此处，接收器可忽略源系统时钟的时间戳记漂移。在接收器处导出OTTest(从源到目的地的接收到的包的单向传输等待时间的最当前更新估计，其为目前为止导出的最低值，等效于接收到包时的当前接收器系统时间-接收到的包的发送器时间戳记)。在随后接收到的包中观察到的OTT中的任何递增均将指示沿路径的拥塞的愚钝开始(即沿所述路径的至少一个前向链路现被100％完全利用，且包开始沿路径被缓冲)，现将表示发送器TCP源现应触发经修改的速率递减或“暂停”机制。接收器可将此用信号通知给发送器TCP源：

在适当的“暂停”或适当的“周期性”暂停之后回复到同一原始通告的窗口大小之前，在适当的周期中在返回的ACK中将通告的窗口大小设定为零。

将通告的窗口大小设定为发送器TCP源的当前导出的/估计的有效窗口大小的适当递减的值(有效窗口大小＝min(窗口大小、拥塞窗口大小、接收器窗口大小)，例如设定为发送器TCP源的当前导出的/估计的有效窗口大小的95％。此处，发送器TCP源将不针对在每一RTT内接收到的ACK而连续地递增有效窗口大小，只要经修改的接收器TCP保持用相同的所通告的递减的当前导出/估计的有效窗口大小进行应答(ACKing)。然而，如果返回的ACK的通告的接收器窗口大小现在随后改变，那么它们的递增不会导致任何包丢弃，因为经修改的接收器TCP将确保发送器TCP源将在沿路径的拥塞的下一愚钝开始时最终递减其有效窗口大小。其它可能的技术包含接收器TCP重复应答(接连的3个DUP ACK，以触发使发送器TCP源乘法拥塞窗口减小的减半)。

在初始TCP连接建立阶段期间，经修改的接收器TCP将与发送器TCP源协商以具有时间戳记选项。此基于接收器的经修改的TCP/经修改的监视软件不需要发送器TCP被修改。

当发送器和接收器TCP两者与时间戳记选项一起均被修改时，将允许两个方向上更精确了解OTT/OTT变化(两个经修改的TCP/经修改的监视软件均可在它们的方向上将对OTT的了解传递给彼此，因此经修改的TCP/经修改的软件监视器现可使用OTT而不是RTT来提供更好的控制，例如，如果所发送区段的OTT不指示拥塞，但返回的ACK的OTT指示拥塞，那么不需要速率递减/“暂停”，即使它们的RTT(如在早前的基于RTT的方法中所使用)已超时。当仅在发送器处实施时，与时间戳记选项一起使用的基于RTT的经修改TCP将允许发送器类似地拥有返回的ACK的OTTest和/或OTT变化以类似地提供更好的控制。

应注意，如果经修改的TCP技术在越洋海底电缆/卫星链路/WAN链路的两端处实施，那么将增加TCP的传输媒介的带宽利用和通过量，实际上类似使物理链路的物理带宽加倍。

所属领域的技术人员可作各种修改和改变，但将在原理的范围内。

设定UDP优先权

应注意，即使在UDP通信量未利用超过100％的前向链路带宽的情况下，在因特网/因特网子集/WAN/LAN内的每一节点处给予UDP高于TCP等的优先权仍将导致UDP丢弃，这是由于节点的输入队列的先前存在的TCP缓冲包＝＞UDP包的缓冲延迟或甚至UDP包丢弃：

1.需要升级/修改路由器/交换机软件以将所有的UDP包放置在节点的输入队列缓冲器前端(和/或将来自UDP输入队列的UDP包优先放置在输出队列前端，使其优先权高于TCP包，即使TCP包已经在输出队列处排队时)，从而将所有的TCP包均推向队列的结尾(因此所有的TCP包均将在任一UDP包在输入和/或输出队列处被丢弃之前被丢弃)。

2.升级路由器/交换机软件以允许产生单独的UDP输入队列(其可能非常小)和TCP输入队列，在输出队列中UDP队列被调度到TCP包前面。且/或实施UDP高优先权输出队列，和低优先权TCP输出队列。

仅仅UDP通信量便可能超过链路的物理带宽，可能使UDP发送源减小传输速率，即分辨率质量，和/或使路由器/交换机节点对所有的UDP流执行此分辨率降低过程(例如仅发送所述流的交替的包并废弃其它交替UDP包，或将两个(或若干个)(例如)VoIP UDP包的数据组合成具有相同尺寸但具有较低分辨率质量的一个包)。

节点可通过保证用于各个UDP/TCP等流的前向链路带宽的最小比例来确保TCP非完全不足(non-complete starvation)。

带宽估计

进一步修改包含(且可结合之前描述的未拥塞RTT/RTTest/RTTbase/OTTest/OTTbase/接收器OTTest方法一起使用，因此允许有足够的时间用于下面的技术，其可能需要一些时间来提供输出结果，以补充上述方法)：

1.使用类似pipechar、pipechar、traceroute、pathchar、pchar、pathload、bprobe、cprobe、netest、chirp…的方法和类似技术来确定每一所通过的节点的前向链路的带宽、利用、通过量、队列长度、遭遇的延迟等，以在遭遇某些情况(例如前向链路利用接近100％)时(根据所设计的一些优化算法)在从出于速率减小的目的而设计的算法导出的适当间隔中“暂停”，以便“暂停”/速率减小，使得不形成任何队列/不缓冲任何包(即先占缓冲延迟，因此所通过的所有节点均不引入任何缓冲延迟)。

例如当特定链路处的利用(其可包含所有UDP、ICMP、TCP)接近(例如)95％时，针对接收到的ACK，可仅不再递增窗口大小，且仅如果/在随后包被丢弃时递减(例如)仅10％(以允许新的流在特定链路处不完全缺乏带宽)，和/或也许其后不递增每一ACK的窗口大小。如果沿路径的特定链路处的链路利用率低于(例如)95％(或指定百分比)，如果包由于物理传输误差的缘故(即，不由于缓冲区过度填充而拥塞的缘故)而丢弃，那么不需要停止递减窗口大小【解决高带宽长RTT TCP速率恢复问题】。鼓励在公众因特网上逐渐增多地采用此简单的分解TCP修改方案将是最有帮助的。新的流(UDP、ICMP、TCP)和/或现存的未经修改的TCP/基于UDP的RTP/UDP现应总是具有至少5％的非不足有保证带宽以增长，因为当链路利用超过(例如)95％时，经修改的基于UDP的TCP/RTP可(例如)均不递增传输速率。且如果/当随后链路丢弃包时，那么经修改的TCP/基于UDP的RTP/UDP将使窗口大小/传输速率递减(例如)10％(或在以由发送源即时传输媒体允许的无限制速率传输周期y之前，周期性地暂停间隔x，使得(例如)x/(x+y)＝0.1，即等效于(例如)10％的滑动窗口或拥塞窗口大小递减/速率递减)。暂停间隔x，而不是滑动窗口/拥塞窗口大小递减/速率递减，将提供早期清除节点处的拥塞缓冲的最快可能，并帮助使沿路径的节点处的缓冲延迟保持非常小。

此处，缓冲区大小要求根本不是要考虑的非常相关的因素。可总是可信服地将所有通信量保持在可用物理带宽的100％内/不超过可用物理带宽的100％(经受非常突然的突发时可能需要被缓冲)。

对于VoIP/多媒体(例如利用基于UDP的RTP/UDP)，或通过同一路径/路径的相同部分的总VoIP/多媒体，在链路开始超过(例如)95％或甚至接近100％时，源VoIP/多媒体现可能以(例如)某一百分比(例如分辨率质量的一半)来传输，并等待直到其它通信量的增长现使链路利用率返回到多达(例如)95％/100％，以在现在突然突发回到全分辨率质量传输且/或加上额外分辨率(例如)200％或更多(以额外冗余消除编码等)，以导致即时突然突发和丢弃缓冲包，从而触发其它TCP流(经修改或未经修改)减小速率(在现存RFC TCP实施方案中通常在1秒内)，且当其它流(例如TCP)现递减速率时，接着立即回复回到100％原始传输质量(或视链路的带宽/VoIP/多媒体所利用的带宽的比例/节点处的缓冲区大小等而定，甚至也许继续尽可能多地抓取保持在200％分辨率质量传输下所需的带宽)＝＞确保VoIP/多媒体的最小可能缓冲延迟。

也许VoIP/多媒体甚至可以更高分辨率传输质量(例如正常所需分辨率的200％，以冗余消除编码等)开始。

这对所有流均有用，因为其确保针对所有的流，均确保所通过节点处的尽可能少的缓冲延迟周期。可进一步升级路由器软件以允许经授权请求丢弃流的包(例如，来自每一TCP流的1个包向发送器表示速率递减)，且/或在检测到(例如)95％/100％的链路利用率时进行此项工作。

上述方法可结合现存(例如)RIP/BGP路由器表更新包…和/或类似技术一起使用，以确保所有节点处的最小或无缓冲延迟，经升级的路由器软件进行链路偏好路由表更新以先占(例如)特定前向链路的超过95％/100％…且/或贯穿网络而不是仅邻近路由器来传播此(但将需要增强以允许更频繁的实时速度更新)。

另一下一代网络设计可为使路由器用信号通知邻近路由器特定前向链路的(例如)95％/100％利用率(100％利用率将指示包缓冲的即将发生)，和/或其它配置细节，例如链路的原始带宽/排队策略/缓冲区大小等，以使邻近路由器不增加到达此路由器/或仅此前向链路的现存发送速率，且/或在周期y中继续无限制发送速率之前(y事实上仅受路由器之间的链路带宽限制)，对通过所通知的路由器链路的所述流进行根据某些百分比的每流速率递减/速率修正，所述百分比是基于视经更新的信息或甚至某一对应的“暂停”间隔x而定的所设计的算法。在“速率递减”/“暂停”期间需要缓冲的任何TCP流的包在任何一个时间均将仅为至多窗口大小，且RTP/UDP流可类似地被缓冲＝＞现在甚至可能可信服地取消任何源拥塞避免、TCP速率限制机制！路由器还可将返回到发送器TCP源的ACK中的所通告的窗口大小字段在某一持续时间或周期性地某一持续时间中修改/设定为零(导致“暂停”或周期性“暂停”)，或甚至将所通告的窗口字段值修改/设定为发送器TCP源的经导出/经估计的当前有效窗口大小的某一递减百分比(因此实现源通信量的速率限制)。因特网/因特网子集/WAN/LAN上的交换机/路由器仅需要保存所有流的源-目的地址和/或端口以及其最新Seq编号和/或ACK编号字段(和/或沿链路的每流前向速率，沿链路的当前导出的/估计的每流有效窗口大小等)的表，以使路由器能够经由“纯ACK”和/或“捎带ACK”和/或“复制包”等产生通告的窗口大小更新(例如经由在“暂停”之前，在回复到现存接收器窗口大小值之前，经由连续通告的接收器窗口大小0来通知源TCP“暂停”某一周期，或基于导出的/估计的当前源TCP有效窗口大小，经由通告的接收器窗口大小的递减值来减小速率)。邻近路由器将对预定沿所通知路由器的链路而到下一路由器的包进行减小/通信量修正，邻近的已知某些包IP地址预定为从路由表条目、RIP/BGP更新、MIB交换等沿所通知的下一路由器的链路进行路由。举例来说，在通知路由器前面的邻近路由器处已周期性地暂停的流(经由周期性“暂停”来控制速率)现将进一步增加所影响的流的“暂停”间隔长度且/或增加周期内的“暂停”的数目。在(例如)从所设计的算法导出的某一经界定周期时，例如当通知路由器现更新邻近路由器，从而指示链路利用率已回落到低于某一百分比(例如低于95％)时，周期性暂停可停止或在频率/个别暂停间隔方面减缓。

RED/ECN机制可经修改以证实此功能性，即代替监视经缓冲的包且选择性地丢弃包/通知发送器，RED/ECN可将策略基于链路利用率，例如当利用率接近某些百分比(例如95％等)时。

上述瓶颈链路利用率估计、可用瓶颈带宽估计、瓶颈通过量估计、瓶颈链路带宽容量估计技术可进一步结合到基于未拥塞RTT/RTTest/RTTbase/接收器OTTest方法的早前描述的速率递减/“暂停”方法中：此处将有充分的时间供瓶颈链路利用率估计、可用瓶颈带宽估计、瓶颈通过量估计、瓶颈链路带宽容量估计技术使用以为足够好的准确性而进行导出/估计，以进一步增强基于未拥塞RTT/RTTest/RTTbase/接收器OTTest方法的早前所述的速率递减/“暂停”方法。补充/提供路径的拓扑/配置的各种进一步技术可包含SNMP/RMON/IPMON/RIP/BGP等。

2.周期性探测器可呈窗口更新探测器(以查询接收器窗口大小，尽管接收器尚未通告0窗口大小)或类似探测包…的形式，或使用实际数据包作为周期性探测器(在可用于传输时)等，或到具有未使用端口编号的目的地的UDP(以使返回消息目的端口不可到达)，且/或加上来自所有节点的时间戳记选项。

或类似地到具有未使用端口编号的目的地的TCP(TCP包可TCP同步到未使用的端口编号)。

各种注意

【注意：如果暂停的间隔在(例如)1秒内总计p*I，那么实际上拥塞窗口＝(p*I)/目前通过量的1秒(当前有效窗口大小*当前RTT)】。

在检测到拥塞时，时间关键性应用可发送突发以导致包丢弃，或接收器根据时间戳记而检测到拥塞以导致或通知服务器便利地导致也许呈较大探测器的形式的突发

除RTTest技术以外，可使用带宽est技术结合：(例如)接收器处理器延迟、原始带宽、可用带宽、缓冲区大小、缓冲拥塞等级、链路利用率来改进外部因特网节点。

基于接收器的OTTest不需要部署GPS同步，仅需要未拥塞OTTest或未拥塞OTTbase或已知未拥塞OTT和OTT监视器变化！！！

基于发送器和/或接收器的原始带宽和通过量估计＝＞链路利用率

使用时间戳记(发送器和回应器)，因此发送器可屏蔽接收器处理延迟变化。

当暂停时，经修改的TCP/经修改的监视软件可视情况立即产生并发送(尽管“暂停”)不携带数据有效负载的纯ACK，其对应于具有来自现需要被缓冲的主机源TCP的设定有ACK标志的每一新到达的数据片段(即捎带ACK区段或纯ACK，忽略不ACK任何东西的正常数据区段)。在此暂停间隔/延长暂停间隔期间所有产生的纯ACK(其被立即发送)均可具有其Seq编号字段值，其被设定为与第一个被缓冲的数据区段的Seq编号相同的Seq编号减1(其可为设定有或未设定有ACK标志的正常数据区段，或纯ACK区段)。如果新到达的区段为纯ACK，那么仍然缓冲它们，且产生/发送对应于此新到达并且现在被缓冲的纯ACK的纯ACK！此时，在其它缓冲数据区段之前转发此新到达的纯ACK可导致接收TCP现接收具有Seq编号的包，所述Seq编号大于其下一预期Seq编号，其应与上次发送的应答编号相同。一旦所产生的纯ACK被发送，对应的现被缓冲的纯ACK现在便可视情况被从所述缓冲区去除且废弃，因为没有必要发送重复的纯ACK。纯ACK可代替地在此暂停/延长暂停间隔周期内被产生且对应于所有缓冲包中具有最大应答编号的缓冲区段。

经修改的TCP/经修改的监视软件可视情况使具有URGENT/PSH标志等的区段即使在“暂停”/延长“暂停”期间也立即被转发。

还可导出实际速率＝自区段的SENT TIME起所传输的字节/ACK超时。保存含有Seq No、ACK超时、此区段中字节数的事件条目列表。或设定实际速率＝自区段的SENT TIME起所传输的字节/(此特定ACK超时区段的SENT TIME-列表上的最后未应答的区段的SENT TIME)，如果列表上没有最后区段，SENT TIME＝此ACK超时区段+ACK超时周期。或使用基于在ACK超时周期内在前面所发送的区段的实际速率。(也许还可导出实际速率＝在RTT或ACK超时周期内的接收到的Ack，即对应于所有那些经应答的区段的总字节)。

接收器基础可更加准确地在任一方向上单独地区分拥塞损失和物理传输错误，和检测速率、OTT和OTTbase、拥塞的开始。更好的发送器接收具有关于接收器何时首先接收所述包和/或接收器何时最后接触发送回到发送器(例如IPMP)的包(和/或ACK)的时间戳记的ACK。

注意，还可导出通过量＝窗口*MSS/RTT字节/秒。

用于组播的经修改的TCP技术实施方案需要在路由器的组播模块处的实施方案/分级协调。

一旦发送器和/或接收器已识别彼此的存在，例如经由唯一端口编号建立，监视软件便可更好地协调＝＞监视软件可接着切换到适当的模式/模式操作的组合。

如果在外部节点上发送/接收，那么可能不想要“暂停”，但如果例如在因特网上的递增采用变成大规模采用(也许为用户可选择选项)时启用此优选“暂停”方案，则可为优选的！

起初可探测路径的可用带宽和/或原始带宽容量(对应于瓶颈)，接着开始TCP窗口大小，使得(例如)95％的可用带宽或(例如)95％的容量立即被利用。

如果RTT继续＜ACK超时，那么可更快地递增窗口大小，例如^*1/cwnd等。

注意，出于所述目的，可基于所设计的演算法，从类似于来自历史RTT的现存RTO估计算法的返回实时RTT，来动态地导出ACK超时(和/或实际包重传超时值)值。

在RFC中，DUP ACK不应被延迟，此处我们通过已立即针对每一经缓冲的ACK包发送所产生的纯ACK或仅它们的最高ACK No来遵循此要求。

为了避免可能给出RTT的错误估计的重新路由路径的问题，可采用逐跳RTT估计和带宽探测。通过使用用于实际实施的主动联网技术，在包含路由器的邻近节点之间执行每部分对话(per-section dialogue)。

注意：在RPC中，除在接收应用消耗新的数据时更新所提供的窗口之外，TCP接收器针对每一输入区段不得产生一个以上ACK。

可视DIFF(RTT，未拥塞RTT/RTTest)而定，来减小窗口大小/增加“暂停”周期。可视沿路径所经历的缓冲延迟的大小(例如OTT-OTTest(或OTT-已知未拥塞OTT)，或RTT-RTTest(或RTT-已知未拥塞RTT))而定来调节百分比速率递减/“暂停”间隔长度。

当经修改的接收器TCP接收到经修改的发送器TCP针对“暂停”时发送器的经缓冲的ACK包而产生的纯ACK(或甚至任何和所有ACK)时，经修改的接收器可视情况/尤其产生具有设定为最后ACK编号-1的Seq编号的1个字节，即产生返回ACK，因此经修改的发送器TCP知道被明确地接收(在此情况下，可能需要确保每个和每一经缓冲的包均个别地产生纯ACK，而不是仅产生最大Seq编号ACK)：发送器TCP可推断1字节数据产生的纯ACK是否不是在“包复制ACK”中由接收器返回(尽管复制的包不被传递到接收器处的应用)＝＞接着相应地反应(例如可为反向路径拥塞/拥塞损失/传输错误，或转发，在此情况下，可能需要再次发送所产生的1字节数据纯ACK等。

两端处的监视软件，或仅发送器或仅接收器：使用接收器的最新Seq No(复制包)或最新Seq No和1字节数据或甚至最新远端的ACK No-1来应答ACK(以去除RTO的主原因，即丢失ACK。丢失的数据区段通常被DUP ACK-＞快速重传)。

基于接收器：如果未证实ACK被接收，那么重新发送ACK。发送DUP ACK(快速重传)以在自从原始区段SENT TIME开始(例如)1秒之前再次到达，以防止导致TCP重新进入缓慢启动的RTO，其中CWND＝1。可将接收器窗口大小动态地调节为在前面的RTT间隔期间估计的发送器的最大实际传输窗口大小的％(对应于实际速率，可假定此实际传输窗口大小等效于传送中的总包数)。

用于TCP的未来RFC应具有一个额外应答ACK字段(应答ACK控制反馈循环)，这完成了控制循环(即现存TCP并不了解RTO是由于前向链路上的数据区段损失还是返回链路上的其对应ACK损失引起)，改进两个TCP对事件状态的了解。或监视软件可经由具有Seq No(复制区段)的ACK等来执行此对ACK的应答。

在两端具有监视软件的情况下，接收器可协调以在两个方向上向其它接收器传递单向传输时间。基于接收器的监视软件可从在SYNC连接建立时所请求的时间戳记选项导出外部因特网节点的OWD(单向延迟)。基于发送器的监视软件可经由IPMP，NTP来估计距远端接收器的OWD，而经由时间戳记选项来估计接收器到发送器OWD。在两端均具有合作监视软件的情况下，可在两个方向上建立OWD＝＞连同ACK应答循环，这允许区别由于发送方向上的包丢弃或返回方向上的ACK损失或物理传输错误而导致的包损失。

Owd需要时间戳记来导出，或ipmp/icmp探测器/ntp等。在两端处具有监视软件的情况下，当接收到且当返回应答区段Seq No时仅对区段加上时间戳记(所有这2个时间戳记值，与事件列表中保存的区段seq no SENT TIME的发送监视器记录相联系，且Seq No的ACK的到达时间提供所有OWD，端处理延迟等。

已知例如海底电缆、WAN链路的两个方向上的OWD，和/或已知时间戳记漂移/准确性和/或已知交换机/路由器/拥塞/未拥塞操作环境下的端主机处理等待时间限制，将改进性能。

仅关于具有给出两个方向上的OWD的准备发送、接收、返回时间戳记的包的ICMP在wan/lan/小因特网子集中在两个方向上通过与tcp/udp相同的路径。用于tcp/udp的RFC应允许这些时间戳记。周期性icmp探测可补充被动tcp rtt测量。IPMP提供类似的时间戳记能力，并与所发送的TCP区段通过相同的路径，且可用作所发送的探测包，其具有与流TCP IP地址相同的IP地址，但具有不同的端口地址。如果两端均实施经修改的TCP/经修改的监视软件，那么周期性探测包可采取建立在两个端的具有与流/TCP IP地址相同的IP地址但具有不同端口地址的经修改的TCP/监视软件之间的单独独立TCP或UDP或IPMP连接的形式，且两个端的经修改的TCP/监视软件现可包含具有Seq编号的区段首先到达时的时间和/或具有同一Seq编号的区段被ACK并返回时的时间的时间戳记，从而允许两个端的OWD测量。

实施TCP修改以在外部因特网上工作

在源发送器或接收器之任一者(或两者)驻留在外部因特网上的情况下，源发送器与接收器之间的数据包通信可能经历不受我们控制的拥塞包丢弃：例如，从外部因特网站的http网页下载/ftp。应注意，这里的方法使我们的修改/发明扩展到同样可应用于源发送器或接收器之一(或两者)驻留在外部因特网上的情况，但也可应用于两者均驻留在因特网子集/WAN/LAN/私有因特网内的情况，如描述主体中各种早先描述的方法。

上述拥塞包丢弃的影响将触发RTO包重传超时和相伴的返回“慢速起动”，接着在源发送器TCP处CWND被设定为1区段大小，对于每个RTT/TCP拥塞窗口大小的源发送器TCP传输速率，CWND爬升回到(例如)1K*区段大小将需要CWND从初始“慢速起动”约10次指数增加(2^10＝1K)，即，源发送器将需要从接收器接收10个连续成功的无中断ACK(无拥塞丢弃)，其中在RTT为200ms时将需要10*300ms＝3秒来爬升回到达到1K*区段大小的CWND。一旦CWND达到SSThresh值，CWND现将对于每个RTT线性增加，而不是在“慢速起动”期间对于每个ACK指数增加。参见RFC2001，http://www.faqs.org/rfcs/rfc2001.html。

正是在拥塞包丢弃时RTO包重传超时的开始和相伴的重新进入“慢速起动”(CWND设定为1区段)导致了端到端传送性能的最大退化。因此有利的是，修改源发送器TCP以更快地反应，以产生DUP ACK来触发在远程源发送器TCP处的具有...的快速重传。

在现在多数TCP中通常实施DUP ACK快速重传/恢复算法的同时，发送器源TCP现将仅在两种情形下RTO包重传超时与相伴地重新进入“慢速起动”：

(A)发送器源TCP向接收器发送全都不会到达而丢失/丢弃的数据包(一个单一包或包的连续区块)，因此接收器TCP将无法知道这些包是否已实际发送以产生用于这些未到达的下一期待序列号包的DUP ACK。应注意，如果这些发送的包的连续区块的稍后部分的任一者在这些包的早些部分中的某些已丢弃的情况下仍到达，那么接收器TCP将仍可产生对发送器源TCP的DUP ACK，以触发仅替代地使CWND减半的快速重传/恢复，因此避免了发送器源TCP的RTO包重传超时事件，这一事件将导致发送器源TCP重新进入CWND为1区段的“慢速起动”。应注意，现有的RFC规定了在任何环境下默认的RTO超时最低最小限度为1秒，因此如果对这些重传的包的随后应答在例如最小1秒的RTO超时内返回到发送器源TCP，那么触发快速重传/恢复的DUP ACK将避免即将发生的正常RTO包重传超时事件。

(B)由接收器产生的回到发送器源TCP的应答丢失/丢弃，因此不会回到发送器源TCP，因此发送器源TCP现将RTO超时而重新进入CWND为1区段大小的“慢速起动”。

可通过修改发送器源TCP来防止上述情形(A)，使得例如如果直接在后的发送数据包的应答在直接在前的发送数据包的应答(已被接收)的(例如)300ms(或用户输入值，或可能基于RTTest(min)和/或OTTest(min)等的演算法导出值，这里选择300ms为实例，其大于延迟应答最大周期200ms)之后未被接收回，或者在从直接在后的发送数据包的发送时间起经过(例如)300ms+最新RTTest的时间(其中较晚者)(即，我们现在可非常安全地假定直接在后的发送数据包丢失/丢弃，或其来自接收器的回到发送器源TCP的应答丢失/丢弃)，那么[下文中称为演算法A](除了所有发送的数据区段/数据包均已被应答，即最新发送的“最大”有效SeqNo＝最新接收的“最大”有效ACKNo)，即发送器TCP现应替代地正常继续，而不受“经过的时间间隔”事件影响)发送器源TCP现应立即进入“连续暂停”状态，但允许在此“连续暂停”状态期间经过的每一(例如)150ms(或用户输入值，或可能基于RTTest(min)和/或OTTest(min)等的演算法导出值)期间(例如)仅一个常规数据包和/或若干纯ACK包的传输，直到下次从接收器TCP接收到回应答包/常规数据包(因此表示往返行程路径现没有完全拥塞，即在任一方向上没有丢弃每个包)，由此，“连续暂停”立即停止如先前回复到触发“连续暂停”的初始经过的300ms那样回复到相同的传输速率/CWND大小。

可以以下方式的各种不同组合来不同地改动算法A的部分：

1.替代在初始经过的300ms后进入“连续暂停”，发送器源TCP仅将其CWND减少到x％(例如，95％、90％、50％...，其可为用户输入或基于某些经设计的演算法)和/或

2.替代在初始经过的300ms后进入“连续暂停”，发送器源TCP仅在“暂停间隔”中“暂停”，所述暂停间隔可为用户输入或从某些经设计的演算法导出(例如，100ms的暂停间隔将等于上文步骤1将CWND减少到90％)，而不用改变CWND大小，

和/或

3.除了上文步骤1和2，替代在初始经过的300ms后进入“连续暂停”，仅立即在“初始暂停间隔”中“暂停”，所述初始暂停间隔可为用户输入或从某种演算法导出(例如500ms)，以确保沿着由从发送器源TCP到接收器TCP的包通过的路由器/交换机节点建立的所有累积的经缓冲包延迟将被此(例如)500ms的量清除，从而减少后续发送的包所经历的缓冲等待时间。

和/或

4.除了上文的演算法A或步骤1、2和3，在包发送速率限于如演算法A中“连续暂停”或“暂停间隔”或“初始暂停间隔”期间的每(例如)150ms经过时期1个常规数据包和/或若干纯ACK包的情况下，发送器源TCP现替代地以“连续暂停”或“暂停间隔”或“初始暂停间隔”期间的新CWND大小所允许的速率进行传输，或者不传输任何包。

和/或

5.除了上文的演算法A或步骤1、2、3和4，在直到接着从接收器TCP接收到应答包(因此表示往返行程路径现没有完全拥塞，即在任一方向上没有丢弃每个包)，由此，“连续暂停”或“暂停间隔”或“初始暂停间隔”立即停止如先前回复到触发“连续暂停”的初始经过的(例如)300ms那样回复到相同的传输速率/CWND大小的情况下，这里发送器源TCP恢复如由新CWND大小所限制的可应用的传输速率。

上文有用组合的仅一个实例是“初始暂停”(例如)500ms以清除缓冲延迟，从而在此(例如)500ms期间不发送任何包，或者在此(例如)500ms期间允许每(例如)150ms中传输1个常规数据包和/或若干纯ACK包；随后是现在经过(例如)500ms后的“暂停间隔”，在此“暂停间隔”期间不发送任何包，或者在此例如100ms的“暂停间隔”期间允许每(例如)50ms传输1个常规数据包和/或若干纯ACK包；接着从接收器TCP接收到应答包后，立即停止“暂停间隔”，从而回复到初始经过的(例如)300ms事件之前的相同传输速率/CWND大小，或回复到由新的CWND大小限制的新传输速率。应注意，初始(例如)500ms的推导的合适选择将有助于例如VoIP/多媒体的其它时间关键性包不经历严重的缓冲延迟。时间戳记选项可使得在发送器源TCP决策中利用OTTest信息，SACK选项如果被使用会减少DUP ACK事件的发生。

可如上所述进一步修改发送器源TCP，以取消无论包损失是由于拥塞丢弃还是物理传输错误等而在任何环境下重新进入“慢速起动”的需要，即，现可使TCP(例如)将传输速率/CWND维持于在RTO包重传超时或DUP ACK快速重传之前的传输速率/CWND的(例如)90％(或等效的100ms的“暂停间隔”，而不用改变CWND)，而不是重新进入RTO“慢速起动”、快速重传速率减半等。这也可应用于描述主体中描述的先前方法/子组成方法中的任一种。这里经进一步修改的TCP因此可快得多地对拥塞丢弃做出反应，(例如)包含“初始暂停间隔”以清除累积缓冲延迟(与现有RFC的1秒的最小RTO默认最低限度相对照)。

可进一步修改/改动上述演算法A本身和/或其各种经修改的组合，但仍将属于本文揭示的原理范围。作为许多实例中的一个实例，在经修改的监视软件/经修改的代理TCP/经修改的IP转发器等内而不是直接在TCP堆栈本身内实施修改的情况下，经修改的监视软件/经修改的代理TCP/经修改的IP转发器等可保留当前窗口中可传输的数据区段/数据包的副本，并(例如)在经修改的监视软件/经修改的代理TCP/经修改的IP转发器等意识到特定数据区段/数据包未被返回应答且TCP将很快执行RTO超时时执行实际的3DUP ACK快速重传和RTO实际包重传(而不是TCP现在简单地将不实施任何快速重传和RTO重传)，以接着针对特定的“快迟(soon late)”的数据区段/数据包“欺骗性发送”特定的应答，且在此处执行实际的数据区段/数据包重传，且在接收到快速重传DUP ACK时不将其转发给TCP，而是在此处执行快速重传(因此，此经修改端的TCP将从不减少其CWND/传输速率，所述速率接着可停留在最大TCP窗口大小传输速率，然而此处的“暂停”周期将调节发送器的实际有效传输速率，即，通过限制每一秒内无限制TCP传输可用的时间片)。

非常常见的是仅在用户本地主机PC上安装经修改的TCP，且例如http网络服务器/ftp服务器/多媒体流服务器的远程发送器源TCP尚未实施上述经修改的TCP。因此经修改的本地主机PC的TCP此处将需要充当基于接收器的经修改TCP，即，远程地影响远程发送器源TCP。本地主机TCP可影响远程发送器源TCP拥塞控制/避免机制的某些方式是经由向远程发送器源TCP发送接收器窗口大小更新、向远程发送器源TCP发送DUP ACK以进行快速重传/恢复，从而避免远程发送器源TCP等处的RTO包传输超时。

这里描述了在监视软件中实施的非常简化的基于接收器的经修改TCP的概述(其可经进一步修改/改动，且也可直接在TCP本身内而不是监视软件内实施)：

1.无论何时从远程发送器接收到TCP包，检查源地址和端口是否已经在每个流TCP的表中，如果不在，就产生具有各种参数的新的每流TCP TCB：(不需要维持所有截获的包的较早的序列号/时间发送表条目)最新的包接收本地系统时间(从远程发送器接收，纯ACK或常规数据包)、最新的接收器包的通告的窗口大小(由本地MSTCP发送到远程发送器)、最新的接收器包的ACK号，即期待来自远程发送器的下一期待序列号(由本地MSTCP发送到远程发送器，需要每流传入和传出包检查，且我们现应能够在FIN/FIN ACK时立即移除每流TCP表条目，而不只是等待通常的120秒的不活动状态)等。

(可选)一旦Sync/Sync ACK完成，就将远程发送器的CWND立即设定为(例如)8K。这优选地通过(例如)其中(例如)ACKNo＝远程发送器的初始序列号+1的15个紧接的DUP ACK来完成，分割ACK可能不能很好的起作用，因为某些TCP替代地仅使CWND增加已应答的字节的数目，且最有利情况下的ACK(Optimistic ACK)特性在所有TCP中可能不同。

应注意：替代地我们将等待从远程发送器接收的第一个数据包，来接着产生(例如)15个DUP ACK，其中ACKNo设定为来自远程发送器的相同的刚接收的序列号，(以仅1个字节的不必要重传为代价)，或者使用分割ACK。

TCP使用三向信号交换程序来建立连接。由起始侧发送设定有SYN标志和序列号字段中有所提议的初始序列号(seq＝X)的区段来建立连接。远程终端接着返回设定有SYN和ACK标志的区段，其中将序列号字段设定为针对相反方向的其自有的分配值(seq＝Y)并将应答字段设定为X+1(ack＝X+1)。一旦接收到此区段，起始侧记录Y，并返回仅设定有ACK标志和应答字段为Y+1的区段。

2.如果300ms期满而没有接收到下一个包，那么：

我们只需要在软件内检测没有在前一最后接收到的包的300ms内到达的下一期待Seq No，以产生ACK号被设定为未到达的下一期待Seq No的3个DUPACK，且同时在3个DUP ACK内传递1800个字节的窗口更新(等于发送器的“暂停”+1个包)：不断地每次如果(例如)100ms经过而没有接收到返回的ACK，那么就发送递增1800个字节的1800个字节的相同3个DUP ACK窗口更新，但如果接着接收到任何纯ACK或任何常规数据包，那么就每100ms重复发送恢复先前窗口大小的通常(并非3个DUP ACK)相同的单一窗口更新(ACKNo字段设定为从本地MSTCP发送到远端的“记录的”“最新”“最大的”ACKNo，或-1)，直到接着从远程终端再次接收到任何ACK或常规数据包为止，接着在上文步骤2的最开始处重复上述(例如)300ms期满检测循环。

应注意，这里我们也可发送3个DUP ACK来代替单一窗口更新包，但在又2个100ms经过之后，单一窗口更新ACK包将具有总共3个DUP ACK窗口更新包，当然这里替代方案也可为任何窗口更新包，例如DUP SeqNo窗口更新包等等。

这确保避免会导致即将发生的远程MSTCP RTO超时重新进入慢速起动的情形A，从而通过DUP ACK快速重传/恢复事件来替换即将发生的RTO。如果确实没有任何发送的包，那么我们不必要地发送ACK号＝下一期待序列号的3个DUPACK是无关紧要的。

通过不断在每100ms中发送相同的3个DUP ACK，直到从远程终端接收到下一ACK或数据包为止(即，瓶颈现在不丢弃每个远程发送包)来解决情形B：由此，我们不断在每100ms中发送单一窗口大小的恢复包，直到接收到任何下一个包(即，即使在最坏情况下所有窗口恢复包被丢弃，300ms之后过程也将重复，从而再次确保窗口“暂停”之后进行窗口恢复尝试)。

应注意：我们连续地递增通告的接收器窗口大小，因为远程终端可能已用完较早可用的接收器通告窗口大小，但发送的包被丢弃而从未到达接收器。通过确保远程终端从不由于正常RTO而重新进入慢速起动(即，CWND＝1)，我们已实现非常大的网页下载时间减少。应注意快速重传不会导致慢速起动，3个DUP ACK仅使远程终端的现有CWND减半。

可使上述算法进一步简化而不需要发送接收器窗口大小更新来“暂停”另一端的TCP，简化如下：

1.无论何时从远程发送器接收到TCP包，检查源地址和端口是否已经在每流TCP的表中，如果不在，就产生具有各种参数的新的每流TCP TCB：(不需要维持所有截获的包的较早的序列号/时间发送表条目)最新的包接收本地系统时间(从远程发送器接收，纯ACK或常规数据包)、最新的接收器包的ACK号，即期待来自远程发送器的下一期待序列号(由本地MSTCP发送到远程发送器，需要每流传入和传出包检查，且我们现应能够在FIN/FIN ACK时立即移除每流TCP表条目，而不只是等待通常的120秒的不活动状态)等。

(可选)一旦Sync/Sync ACK完成，就将远程发送器的CWND立即设定为(例如)8K。这优选地通过(例如)其中ACKNo＝远程发送器的初始SeqNo+1的15个紧接的DUP ACK来完成，分割ACK可能不能很好的起作用，因为某些TCP替代地仅使CWND递增已应答的字节的数目，且最有利情况下的ACK特性在所有TCP中可能不同。

应注意：替代地我们将等待从远程发送器接收的第一个数据包，来接着产生(例如)15个DUP ACK，其中ACKNo设定为来自远程发送器的相同的刚接收的序列号(以仅1个字节的不必要重传为代价)，或者使用分割ACK。

2.如果300ms期满而没有接收到下一个包，那么：

我们只需要在软件内检测没有在前一最后接收到的包的例如300ms内到达的下一期待Seq No，以产生ACK号被设定为未到达的下一期待Seq No的3个DUP ACK：不断地每次如果(例如)100ms经过而没有接收到任何纯ACK或常规数据包，那么就发送相同3个DUP ACK窗口更新，但如果接着接收到任何ACK或任何常规数据包，那么接着在上文步骤2的最开始处重复上述(例如)300ms期满检测循环。

这确保避免了会导致即将发生的远程MSTCP RTO超时重新进入慢速起动的情形A，从而通过DUP ACK快速重传/恢复事件来替换即将发生的RTO。如果确实没有任何发送的包，那么我们不必要地发送ACK号＝下一期待序列号的3个DUP ACK是无关紧要的。

通过不断在每100ms中发送相同的3个DUP ACK，直到从远程终端接收到下一ACK或数据包为止(即，瓶颈现在不丢弃每个远程发送包)来解决情形B：由此，我们不断在每100ms中发送单一窗口大小恢复包，直到接收到任何下一个包(即，即使在最坏情况下所有窗口恢复包被丢弃，300ms之后过程也将重复，从而再次确保窗口“暂停”之后进行窗口恢复尝试)。

上述非常简化的演算法是从这里的各种其它类似演算法导出：

1.基于接收器的目的是使没有实施修改的远程发送器源TCP表现得尽可能类似于“镜像”的基于发送器(但存在某些需要解决的微小差别，例如基于接收器无法知道发送器源TCP是否已经传输未到达的下一期待序列号数据区段等)：当常规数据包的ACK迟到时，基于发送器“暂停”，但允许每个暂停间隔转发1个常规数据包以作为探测器，当MSTCP超时重传时(由序列号小于等于记录的最后发送的序列号来检测)，那么在ACK超时时间间隔中向MSTCP“欺骗性发送”ACK，以使CWND达到RTO之前的先前级别。我们现首先建立了简化的骨架型式，随后进行增强。

2.使用序列号/发送时间主事件列表和重传事件列表，常规数据包探测方法是足够直接的。需要通过修改截获的SYNC/SYNC ACK包和/或PC注册设定来确保SYNC/SYNC ACK期间协商的时间戳记选项。

3.当到达的OTTest＞当前记录的OTTest(min)+300ms时，此信号拥塞缓冲延迟(OTTest(min)是从远程发送器到我们的无拥塞OTT的最新最佳估计)＝＞1800字节的发送窗口更新，以允许接收1个常规1500字节以太网包，且还接收若干小的纯ACK。

4.如果经过OTTest(min)而没有接收到常规的数据包或纯ACK，就不断发送递增1800字节的1800字节的相同窗口更新，其中到达的OTTest＞当前记录的OTTest(min)+300ms，(因此对于经过的每一OTTest(min)，远程终端可转发单一新的常规数据包作为探测器)。如果在任何时间按时到达的OTTest＝＜当前记录的OTTest(min)+300ms，那么立即发送恢复先前接收器窗口大小的窗口更新，即远程终端现恢复先前的常规发送速率。

(应注意：此尝试通过调节速率来防止包丢弃，使得远程终端不需要再次慢速起动，但在外部因特网中实际上没有很好地工作！因此上文第4段应由下文第4段代替，下文第4段仅着重于在包损失事件发生时尽可能快地恢复远程发送速率，即，如果我们可在检测到重传的包时类似于基于发送器“欺骗”而立即恢复远程发送速率，那么我们就不再关注包丢弃是否导致远程终端处的慢速起动。)

4.只要到达的序列号＞下一期待序列号，且现在经过300ms而没有接收的失去的间隙序列号包(即，现在可安全地假定间隙包已经丢失，且远程发送器现在将以RFC的1秒最小最高限度的期满时即将进行的慢速起动来重传)就检测到远程发送器包“即将发生的”重传，＝＝＞但我们的MSTCP将已经在接收到3个无序序列号包时自身产生3 DUP ACK，从而导致远程终端快速重传而不会再次进入慢速起动(如果远程发送器恰好仅有2个无序序列号要传输和没有序列号要传输，那么这不会使过程中断，因为我们可直接允许远程终端慢速起动，因为远程终端此时不发送许多东西。)＝＝＞我们只需要检测没有在前一接收到的包的300ms内到达的下一期待序列号，以产生ACK号被设定为未到达的期待序列号的3个DUPACK。

(应注意，SACK可有用于减少DUP ACK的发生，分割ACK、DUP ACK、最有利情况ACK有用于类似于基于发送器的“ACK欺骗”而恢复远程发送速率，参见http://www-2.cs.cmu.edu/～kgao/course/network.pdf和http://www-2.cs.cmu.edu/～kgao/course/network.pdf和Google搜索术语“ACKspoofing”)

这里附加用于基于接收器的方法的一种算法(仅为实例)：

1.子网用户输入，仅监视到达/来自规定子网的TCP流。

2.将以不同方式监视涉及外部源/目的地的TCP流。

2.1外部源(即，定制的TCP充当基于接收器的流控制器)

在连接建立期间针对这些流选择时间戳记选项(可修改Sync包？或可能需要设定PC注册以便上文第1、2段中的所有流也具有时间戳记？Window server 2003仅在由远程TCP起始的情况下允许时间戳记选项！？)

针对远程发送器TSVal检查此TCP的传入包，将此记录为针对接收到的第一个包的OTTest(max)还有OTTest(min)(当前接收器系统时间-TSVal)。OTTest代表单向行程时间估计，即，目前为止观察到的最大与最小OTT。根据接收到的每个后续包更新OTTest(max)和OTTest(min)。

如果传入的包的OTTest-OTTest(min)＞例如100ms(用户输入参数)，那么远程发送器应“暂停”，定制的TCP产生(例如)50个字节的1字节无用(或无数据)区段(不必为0，以允许远程发送器TCP回答/纯ACK)窗口大小通告包，其中序列号被设定为接收器的上次发送的序列号或上次接收到的ACK号-1(在接收器没有向远程发送器发送任何数据区段因此没有接收器的上次发送序列号的情况下)。

接收器继续发送相同的所产生的窗口通告包(但序列号或上次接收到的ACK号-1可能已改变)，直到存在接收到的对这些“复制的包窗口更新”包中一者的回答确认，因此表示在发送器处已接收到这些窗口更新包中的至少一者且其回答确认现已到达(可能在任一方向上丢失)，且其OTTest-OTTest(min)一定＜例如100ms(直到没有拥塞为止，我们不停止“暂停”)。

也可在任何其它包(例如，常规数据包)在OTTest(min)+100ms内到达时停止“暂停”。其中接收器发送相同的窗口更新包但窗口大小字段被设定为紧接在“暂停”之前的值(在实现(例如)50个字节的通告之前记录此值)。

2.2远程目的地(即，定制的TCP充当基于发送器)。

时间戳记不是必要的，但有用于了解返回的单向延迟，以更好地确定RTT＜超时的起因(可能由反向路径拥塞造成)

在MSTCP发起序列号＜上次发送的序列号的包时(包丢弃重传)，MSTCP将再次进入慢速起动：定制的TCP现在将在例如100ms的周期中针对由MSTCP发起的每个包而欺骗性发送ACK回到MSTCP的。这将使拥塞窗口回到例如TCP窗口大小。任何后续转发的经缓冲包丢弃可经由接收器的所接收3 DUP ACK而快速重传(由此，定制的TCP可再次欺骗性返回ACK)。

我们的算法：

1.无论何时接收到TCP包，检查源地址和端口是否已经在每流TCP的表中，如果不在，就产生具有各种参数的新的每流TCP TCB：(不需要维持所有截获的包得较早的序列号/时间发送表条目)

最新的包接收本地系统时间(纯ACK或常规数据包)、最新的接收器包的通告的窗口大小、最新的接收器包的ACK号，即下一期待序列号(需要每流传入和传出包检查，且我们现应能够在FIN/FIN ACK时立即移除每流TCP表条目，而不只是等待120秒)。

2.如果300ms期满而没有接收到下一个包，那么：

我们只需要在软件内检测没有在前一最后接收到的包的300ms内到达的下一期待序列号，以产生ACK号被设定为未到达的下一期待序列号的3个DUPACK，且同时在3个DUP ACK内传递1800个字节的窗口更新(等于发送器的“暂停”+1个包)：这里我们应期待所述3个DUP ACK再次被远程终端返回应答，不断地每次如果(例如)100ms经过而没有接收到返回的ACK，那么就发送递增1800个字节的1800个字节的相同3个DUP ACK窗口更新，但如果接着接收到任何返回的ACK或任何常规数据包(不管OTT时间是多少)，那么就发送恢复前一窗口大小的3个DUP ACK窗口更新。

这确保避免了会导致即将发生的远程MSTCP RTO超时重新进入慢速起动的情形A，从而通过DUP ACK快速重传/恢复事件来替换即将发生的RTO。如果确实没有任何发送的包，那么实际上我们不必要地发送ACK号＝下一期待序列号的3个DUP ACK是无关紧要的。

通过不断在每100ms中发送相同的3个DUP ACK，直到接收到“应答所述ACK”或接收到下一常规数据包为止(即，瓶颈现在不丢弃每个远程发送包)来解决情形B：由此，我们不断在每100ms中发送恢复通告窗口大小的3个DUPACK，直到接收到“应答所述ACK”。

作为对发送针对下一期待序列号区段的3个DUP ACK的替代，我们可将3个DUP ACK中的ACK号字段替代设定为下一期待序列号-1(以仅重传1个额外字节为代价)，在此情况下我们肯定需要使用轮流的下一期待序列号-100、-99、-98...-1来设定序列号字段。

但是参见http://www.cs.rutgers.edu/～muthu/wtcp.pdf，其中建议在此情况下TCP从当前拥塞窗口中的最低未应答包或第一未发送包开始进行重传。

希望这接近于一种规范，软件将保持“被动通过(passive passthru)”而不改变任何接收的和发送的包。远程MSTCP现在将从不RTO而重新进入慢速起动。

对于单个PC共享软件，我们不需要任何探测器或时间戳记特征(第2段)：窗口更新可简单地每100ms重复(而不是第4段中的3*OTTest(min))，直到接收到任何纯ACK或常规数据包(接收时间无关紧要)。这里，当我们的流丢弃包时，我们知道穿过相同瓶颈(丢弃包的地方)的其他流的MSTCP将与我们自己的MSTCP在大约同时RTO速率＝＞我们可以安全地恢复远程发送器的CWND。

1.目标是使远程终端表现为尽可能地类似“镜像”的基于发送器：当常规数据包的ACK迟到时，基于发送器“暂停”，但允许在每个暂停间隔中转发1个常规数据包以作为探测器，当MSTCP超时重传时(由序列号小于等于记录的上次发送的序列号来检测)，那么在ACK超时时间间隔中向MSTCP“欺骗性发送”ACK，以使CWND达到RTO之前的先前级别。我们现在应该首先建立简化的镜像的骨架式基于接收器型式，随后进行增强(例如，SACK间隙包特征可为有用的)。

2.使用序列号/发送时间主事件列表和重传事件列表，常规数据包探测器方法是足够直接的。需要通过修改截获的SYNC/SYNC ACK包和/或PC注册设定来确保在SYNC/SYNC ACK期间协商的时间戳记选项。

[简化演算法中不再需要

3.当到达的OTTest＞当前记录的OTTest(min)+300ms时，此信号拥塞缓冲延迟(OTTest(min)是从远程发送器到我们的无拥塞OTT的最新最佳估计)＝＞1800字节的发送窗口更新，以允许接收1个常规1500字节以太网包，且还接收若干小的纯ACK。]

[简化演算法中不再需要

4.如果OTTest(min)经过而没有接收到常规的数据包或纯ACK，则不断发送递增1800字节的1800字节相同窗口更新，其中到达的OTTest＞当前记录的OTTest(min)+300ms，(因此对于经过的每一OTTest(min)，远程终端可转发单一新的常规数据包作为探测器)。如果在任何时间按时到达的OTTest＝＜当前记录的OTTest(min)+300ms，那么立即发送恢复先前接收器窗口大小的窗口更新，即远程终端现恢复先前的常规发送速率。]

(应注意：此尝试通过调节速率来防止包丢弃，使得远程终端不需要再次慢速起动，但在外部因特网中实际上没有很好地工作！很难知道就在包丢弃前的OTTest，因此上文第4段应由下文第4段代替，下文第4段仅着重于在包损失事件发生时尽可能快地恢复远程发送速率，即，如果我们可在检测到重传的包时类似于基于发送器“欺骗”而立即恢复远程发送速率，那么我们就不再关注包丢弃是否导致远程终端处的慢速起动。)

4.只要到达的序列号＞下一期待序列号，且现在经过300ms而没有接收的失去的间隙序列号包(即，现在可安全地假定间隙包已经丢失，且远程发送器现在将以RFC的1秒最小最高限度的期满时即将进行的慢速起动来重传)就检测到远程发送器包“即将发生的”重传，＝＝＞但我们的MSTCP将已经在接收到3个无序序列号包时本身产生3个DUP ACK，从而导致远程终端快速重传而会/不会再次进入慢速起动(如果远程发送器恰好仅有2个无序序列号要传输和没有序列号要传输，那么这不会使过程中断，因为我们可简单地允许远程终端慢速起动，因为远程终端此时没有发送许多东西。)＝＝＞我们只需要在软件内检测没有在前一接收到的包的300ms内到达的下一期待序列号，以产生ACK号被设定为未到达的下一期待序列号的3个DUP ACK，且同时在3个DUP ACK内传递1800个字节的窗口更新(等于发送器的“暂停”+1个包)：这里我们应期待所述3个DUP ACK再次被远程终端返回应答，不断地每次如果(例如)3*OTTest(min)经过而没有接收到返回的ACK，那么就发送递增1800个字节的1800个字节的相同3个DUPACK窗口更新，但如果接着接收到任何ACK或任何常规数据包(不管OTT时间如何)，那么就发送恢复先前窗口大小的3个DUP ACK窗口更新

(这里我们仅提前检测包丢弃来更新接收器窗口大小，等于基于发送器的“暂停”+1个包)。

5.导致远程终端快速重传的实际的DUP ACK全部由MSTCP本身处理。软件仅需要检测截获的MSTCP的2个额外的DUP ACK(总共3个，如果包含较早的常规应答)，接着通过分割ACK/DUP ACK/最有利情况下的ACK技术立即恢复远程CWND，所述技术参见

http://arstechnica.com/reviews/2q00/networking/networking-3.html和http://www.usenix.org/events/usits99/summaries/

(这里，在MSTCP发送2个额外的DUP ACK时，我们类似于基于发送器的“欺骗”ACK而进行操作。)

应注意：通过不断在每100ms中发送相同的3个DUP ACK，直到接收到“应答所述ACK”或接收到下一常规数据包为止(即，瓶颈现在不丢弃每个远程发送包)来解决情形B：由此，我们不断在每100ms中发送恢复通告窗口大小的3个DUP ACK，直到接收到“应答所述ACK”。

仅在以下情况下：

MSTCP总是应答任何无序ACK(即，应答尚未发送的区段的ACK)，否则将需要在3个DUP ACK中包含序列号字段，其中ACK号字段全部设定成相同的下一期待序列号(应注意，在RFC中，DUP序列号包总是获得应答！？)：

我们可希望使用先前讨论的轮流方法，其使用DUP ACK中的100个先前序列号字段(即，“已记录的”下一期待ACK-100)，其中ACK号字段全部设定成相同的下一期待序列号)，使得DUP ACK每一者现在将具有不同的序列号字段，所述序列号字段被设定成已记录的下一期待序列号-100中的任一者(不会有两个DUP ACK具有相同的序列号。

应注意：也假定尚未发送的区段的3个DUP ACK不会不必要地触发远程MSTCP将CWND减半和将SSTHRESH设定成1/2当前CWND(包可能已发送但是被丢弃(在此情况下一定进行使CWND减半的快速重传)，或者尚未发送(在此情况下，可进行或可能不进行不必要地使CWND减半的快速重传))，否则，会产生轻微的不必要的性能损害。

使用包间到达(inter-packets-arrivals)延迟作为拥塞指示的方法

在任何方法、主体描述中先前所述的子组成方法中，拥塞或包丢弃指示现在可替代地由经修改的TCP/经修改的监视软件/经修改的代理/经修改的端口转发器……等通过观察包间到达之间的延迟来检测/推断，例如，特定而言，当直接连续包之间的“经过的时间间隔”超过从自远程发送源TCP或远程接收器TCP接收上一个包(纯ACK或常规数据包……等)以来的特定用户输入间隔(或从一些可基于RTTest、OTTest、RTTest(min)、OTTest(min)……等的演算法导出)时。这里应注意，TCP连接是对称的，每一端能够同时发送并接收，且一端的发送数据区段/数据包和来自另一端的其对应的返回回应ACK[下文称为子流A]可与另一端的独立发送的数据区段/数据包和来自另一端的其独立的对应返回回应ACK[下文称为子流B]相混合：经修改的TCP/经修改的监视软件/经修改的代理/经修改的端口转发器……等当观察上述包间到达之间的延迟时应完全独立地“辨别”且单独观察子流A和/或子流B的包间到达-＞使得当一端(即，子流A)的发送数据区段/数据包沿到另一端的前进路径被丢弃，藉此其对应的返回回应ACK将不会沿返回路径从另一端返回时，独立地，另一端(即，子流B)的沿返回路径到达的发送数据区段/数据包(如果存在)现在不会导致这一端错误地假定独立子流A的“经过的时间间隔”尚未期满。一端上的经修改的TCP/经修改的监视软件/经修改的代理/经修改的端口转发器……等当充当发送器时将仅观察其自己的子流A的对应返回回应ACK流以发现用于“经过的时间间隔”期满的包间到达延迟，从而忽略另一端的独立子流的发送区段/包。一端上的经修改的TCP/经修改的监视软件/经修改的代理/经修改的端口转发器……等当充当接收器时将仅观察另一端的自己的子流B的传入区段/包以发现用于“经过的时间间隔”期满的包间到达延迟，从而忽略这一端的自己的独立子流A的(如果存在)对应到达返回回应ACK流。所述任务应足够简单：一端当充当基于发送器时将仅需要监视其自己的发送包的对应的传入返回回应ACK以发现用于“经过的时间间隔”期满的“包间间隔”延迟，而当充当基于接收器时将仅需要监视另一端的发送数据区段/数据包：另外，在来自另一端(其“包间间隔”延迟现在已“经过的时间间隔”期满)的这一端的独立子流的发送包的对应返回回应ACK的“经过的时间间隔”期满之前，如果另一端的独立子流的发送包继续到达，这将提供从另一端到这一端的单向路径为“开启”和从这一端到另一端的单向路径为“关闭”的额外的明确指示/明确推断，以相应地做出反应。这具有以下优点：能够(例如)指定大大小于RTTest或OTTest或RTTest(min)或OTTest(min)……等的“经过的时间间隔”，通过能够检测/推断拥塞和/或包丢弃和/或物理传输错误事件而允许实现更快速的回应时间(在因特网上甚至非拥塞RTT、OTT等也可达到几百毫秒和不可被断言，或其最大边界不可提前被断言，而上述自从上次接收包以来的经过的时间间隔可被选择为小到(例如)50ms，而不是几百毫秒)。

在(例如)ftps/http网站下载期间，在未由RTO包重传超时重新进入慢速起动(其中CWND经重新设定成1或区段大小)中断时，继续传输常规数据包。假定由包通过的路径的最低带宽链路在这里为发送源TCP的第一英里的(例如)500Kbs DSL，那么供单个包从发送源完全离开到DSL传输媒体上的传输时间延迟在这里将不是重要因素，对于具有大的1500字节的以太网大小的包来说，为较小的(例如)24ms(1500*8/500000＝24ms)。而对于最后一英里的56Kbs的调制解调器拨号连接来说，典型的500字节的包的传输延迟时间将会是大约71ms(500*8/56000＝71ms)。在如今的因特网上，沿由包通过的路径的最低可能带宽链路在最坏情况下为56Kbs。默认的包大小通常为大约500字节，其通常由TCP在建立连接期间协商得出。“包间到达”方法(和/或“同步”包方法，见稍后的段落)可以基于假定沿路径56Kbs最低带宽链路和经协商的最大包大小的“经过的时间间隔”值设置和“同步”间隔值设置而开始，接着继续监视常规数据包之间(或发送的实际数据包的ACK之间)的接收包间到达间隔的实际所观察最新最小值，以动态调整“经过的时间间隔”值设置和“同步”间隔值设置，例如，如果最新最小“包间到达”间隔现在仅为20ms，那么“经过的时间间隔”值现在将被设定成(例如)80ms，且“同步”间隔值现在将被设定成(例如)40ms……等或基于所设计的算法导出的值。当继续从发送源TCP发送数据包且在接收器TCP处接收数据包时，包间间隔应显示上述相同的包间到达间隔，分别集中在大约24ms或71ms并加上间隔总量，所述间隔总量是因为在沿所通过路径(其中节点使用存储和转发切换，而不是会放弃在每一节点处遇到的单个包传输时间延迟的切入切换，与存储和转发相对照)的每一节点处遇到的单个包传输时间延迟，即使所通过的链路引入多种延迟和/或缓冲延迟也是如此，因为这将均一地影响数据包且它们将仍然到达接收器处(分别以大约24ms或71ms而间隔开)，假定缓冲延迟当然不会非常突然地立即从先前包添加附加的(例如)200ms到下一包(即，额外缓冲延迟将继续逐渐被添加到每一后续包)且沿路径没有包丢弃/丢失，如果如此，那么可能添加“无穷大”延迟到从直接在前的发送包丢弃/丢失的这个后续包(我们可通过观察包间延迟现在突然超过特定值(例如，100ms)，即，从上一次包被接收以来现在已达100ms(即，现已经过100ms而未接收到紧接的后续包，亦即具有正确的下一期待序列号的包)来检测/推断这个拥塞和/或包丢失和/或物理传输错误事件：然而，即使可在这个100ms内接收其它后续包且仅没有接收到这个特定直接后续包，我们也可(如果需要)类似地将这个情况视为“间隙”拥塞和/或包丢弃和/或物理传输错误事件，且以类似或稍微不同的方式处理)。

因为在沿所通过的路径(其中节点使用存储和转发切换，而不是会放弃在每一节点处遇到的单个包传输时间延迟的切入切换，与存储和转发相对照)的每一节点处遇到的单个包传输时间延迟的总间隔量可从几毫秒(如果沿所通过的路径的节点具有高带宽容量链路)(即使实施存储和转发切换，而不实施切入切换)变化到几十或甚至几百毫秒(如果所通过的链路具有低带宽容量)。例如，第一英里具有500Kbs，传送到10Mbs的下一链路上，接着下一链路为100Mbs，接着下一链路为10Mbs，且最后接收器的最后英里链路为500Kbs DSL，那么由单个1500字节大小的包在转发链路(其中节点都实施存储和转发切换，与切入切换相对照，此处假定在所通过的每一节点处的没有拥塞缓冲延迟)的每一连续阶段遇到的总传输完成时间延迟将为大约24ms+1.2ms+0.12ms+1.2ms+24ms＝50.52ms，即，当最终在目的地接收时，直接连续包之间的包间到达间隔将集中在50.52ms左右。而在第一英里调制解调器链路具有56Kbs，下一链路为10Mbs，接着下一链路为100Mbs，接着下一链路为10Mbs，且最后接收器的最后一英里调制解调器链路为56Kbs，那么单个500字节大小的包在转发链路(其中所有节点实施存储和转发切换，与切入切换相对照，假定此处在所通过的每一节点处没有拥塞缓冲延迟)的每一连续阶段遇到的总传输完成时间延迟将为大约71ms+0.4ms+0.04ms+0.4ms+71ms＝142.84ms，即，当最终在目的地接收时，直接连续包之间的包间到达间隔将集中在50.52ms左右。由在所通过的节点处遇到的累积拥塞缓冲延迟造成的任何拥塞缓冲延迟增加包最终从源到达目的地的实际花费的时间且可引起迟很多的发送包(即，对于所参考的较早发送的包来说并非紧接着的连续的下一包，例如，间隔几秒或几十秒)将比较早的所参考发送包实际到达目的地接收器多花费(例如)300ms，但是因为在任何两个直接连续的下一发送包与前一发送包之间，由直接连续的下一包与其直接在前的发送包相比较所遇到的“额外的”增加的累积拥塞缓冲延迟可仅为(例如)3ms，即，比上述(例如)300ms(如在相隔若干秒的两个远的发送包之间)少几个数量级(此处假定拥塞级别渐增，相同的推理可类似地应用于拥塞级别渐减的情况下)。这个“附加的”额外拥塞缓冲延迟在直接连续的下一包与其直接在前的发送包之间将较小，将仅在直接连续的下一包与其直接在前的对应包之间逐渐增加。然而，在任何随后成对的直接连续的下一包与其直接在前的对应包之间的这个可能的额外的小拥塞缓冲延迟量(即使小且被均匀地抵消，其中拥塞级别经稳定/均匀地在其它随后成对的直接相邻的稍后发送对之间平滑化)应/将在当没有从发送器源TCP接收到其后/直接下一包时选择/导出经过时间周期值时被考虑在内，以检测/推断拥塞和/或封包丢弃和/或物理传输错误事件。然而，在极少情况下，拥塞级别可(并非不可能)在(例如，100ms)的短周期内突然产生(例如)200ms的缓冲延迟(诸如，当传入链路为100Mbs且传出链路仅为10Mbs……等时)，在所述情况下，我们在这里可方便地包含用来获取经过的时间间隔的情形，以除了检测/推断拥塞和/或包丢弃和/或物理传输错误事件外，还检测/推断这个极少的突然拥塞缓冲延迟事件。应注意，在任何稍后进一步发送的成对的直接连续的下一包与其直接在前的对应包之间，这种突然极少拥塞级别产生现在将不再引起“经过的时间间隔”期满，因为，当突然的拥塞产生在其它随后的进一步发送的成对的直接相邻的稍后发送对之间稳定/均匀地平滑化时就被均匀地抵消。

应注意，TCP连接为全双工，即，连接两端的每一者可同时充当发送器源TCP和接收器TCP来发送并接收。即使仅连接的一端进行常规数据包的几乎所有发送或所有发送(例如，ftp文件下载/http网页下载……等)，接收端TCP也将总是回应于所接收的常规数据包将应答发送回进行常规数据包的几乎所有发送或所有发送的端TCP。因此，前述段落中概述的“经过的时间间隔”方法类似地可应用于进行常规数据包的几乎所有发送或所有发送的端TCP，因为当“经过的时间间隔”期满而没有从接收下载的另一端TCP接收到纯ACK包和/或捎带确认ACK包时，进行常规数据包的几乎所有发送或所有发送的端TCP现在可推断拥塞和/或包丢弃和/或物理传输错误和/或“极少的”极突然的拥塞级别产生事件的检测，且相应地反应。然而，这里当接收器端TCP实施延迟的应答(每隔一包或在200ms期满(其中先发生者)时产生ACK)，且这个延迟ACK选择被针对特定每流TCP连接启动时，在所选择或算法导出的“经过的时间间隔”值的设置中，应考虑包含由延迟的ACK机制引入的可能的额外200ms的延迟，例如，在延迟的ACK情况中，“经过的时间间隔”应加上200ms，或者选择性地，替代添加200ms到“经过的时间间隔”，而替代地将这个遇到的最坏情况200ms的延迟事件包含到“经过的时间间隔”期满时便可推断/检测的各种事件中。这个事件将是罕见的，且在(例如)在发送器源TCP发送包到接收器端TCP中存在不流畅时发生，因此将不会因为最坏情况延迟ACK情形而对通过量性能产生太多影响。

当“经过的时间间隔”期满而没有接收下一包时检测/推断上述事件后(应注意，在这里，我们甚至不需要任何信息，可选地也不需要使用RTT、OTT……等，和也不需要基于历史TRR值(替代其，实际包重传超时可(例如)在满足特定用户输入值或从基于(例如)历史包间到达间隔值的算法导出值……等时被触发)的RTO计算，所述需求(对于现有需求而言是多余的)可视情况从经修改的TCP移除)，然后，经修改的TCP/经修改的软件监视器/经修改的代理/经修改的IP转发器/经修改的防火墙……等可利用在主体描述中的较早方法/子组成方法中所述的现有的与CWND减小/速率减小同时的耦合的实际包重传，和/或无相伴的实际包重传的仅经修改的经分解CWND减小/速率减小，和/或伴有或未伴有CWND减小/速率减小的多种经修改“暂停”方法……等继续进行。一旦上述过程在“包间间隔”延迟的“经过的时间间隔”期满时被触发，当随后到达包从发送源TCP的相同子流紧接着到达时，现在可立即或视情况在某界定间隔后终止被触发的过程，且CWND大小/速率限制被视情况恢复到在“经过的时间间隔”期满之前的先前值，且/或视情况正在进行的“暂停”被“解除暂停”，……等。这个包的到达现在表明从发送器源TCP到接收器TCP的路径现在并非丢弃全部包的完全拥塞状况：我们可视情况进一步需要这个到达的包(如果常规数据必须就是具有正确的下一期待序列号的下一期待包，且/或如果纯ACK包应使其序列号字段＝从发送器源TCP接收到接收器TCP的上次接收的有效序列号(或从接收器TCP发送到发送器源TCP的最新最大有效应答号-1))。

类似地，通过使另一端TCP进行在主体描述中的较早方法/子组成方法中所述的现有的与CWND减小/速率减小同时的耦合的实际包重传，和/或无相伴的实际包重传的仅经修改的经分解CWND减小/速率减小，和/或伴有或未伴有CWND减小/速率减小的多种经修改“暂停”方法……等，经修改的TCP/经修改的软件监视器/经修改的代理/经修改的IP转发器/经修改的防火墙……等可视情况且/或进一步也接着继续进行。或者，仅通过使另一端TCP(不使本地TCP进行此！所述特征将是有用的，例如，当为现有的未经修改的标准TCP的另一端TCP进行常规数据包的几乎所有或所有发送时)进行在主体描述中的较早方法/子组成方法中所述的现有的与CWND减小/速率减小同时的耦合的实际包重传，和/或无相伴的实际包重传的仅经修改的经分解CWND减小/速率减小，和/或伴有或未伴有CWND减小/速率减小的多种经修改“暂停”方法……等，经修改的TCP/经修改的软件监视器/经修改的代理/经修改的IP转发器/经修改的防火墙……等可视情况且/或进一步也接着继续进行。一旦上述过程在“经过的时间间隔”期满时被触发，当到达包从另一端TCP的相同子流到达时，现在可立即或视情况在某界定间隔后终止上述被触发的过程，且CWND大小/速率限制被视情况恢复到在“经过的时间间隔”期满之前的先前值，且/或视情况正在进行的“暂停”被“解除暂停”，……等。不能容易地直接通过一些协议命令来使另一端TCP(如果另一端TCP为现有未经修改的TCP或尚未经特别修改来允许所述机制)对于远程TCP/远程应用/远程过程而改变另一端TCP的内部CWND大小/传输速率。然而，很容易使另一端TCP(即使另一端TCP为现有未经修改的TCP或尚未经特别修改来允许所述机制)“暂停”和/或“解除暂停”和/或“暂停但是允许传输界定的最大数目的字节/包”……等(如在主体描述中的较早方法/子组成方法中所述的)，例如，发送“0”字节和/或“1600字节”……等的接收器窗口大小更新包来导致另一端TCP处的多种“暂停”，发送在“触发”事件之前的先前大小的接收器窗口大小更新包来“解除暂停”/恢复另一端TCP的正常操作……等(也参见关于实施TCP修改来在外部因特网上工作的上文段落)。

独立地且/或视情况，除了前述各种方法(例如，“经过的时间间隔”方法)外，现有或上文描述的TCP/监视软件/TCP代理/IP转发器/防火墙……等可经修改/进一步经修改来确保TCP连接的两个经修改端的每一者自动产生“同步”数据包到另一经修改端(或仅TCP连接的一个经修改端自动产生“同步”数据包到另一未经修改或经修改端)，从而确保在需要时在至少每个“同步”间隔周期(例如，“经过的时间间隔”选择值的一半，或供单一包完全离开到传输媒体上的包的通过路径的最低带宽链路的传输时间延迟*乘数(其中较大者)：应注意，这里的“经过的时间间隔”值应总是大于上述“同步”值)中总是存在1个包朝向另一端的经修改TCP发送，例如，只要“同步”间隔期满而没有相同子流的任一单个包被发送向另一端的TCP，便产生“同步”包且发送到另一端的TCP。因此，如果两个端经修改且每一者发送“同步”包到另一经修改端，那么当子流的“经过的时间间隔”期满且没有从另一端的TCP接收到来自相同子流的任何类型的包(包含子流产生的“同步”包类型)时，两个经修改端的每一端的TCP将立即知道/推断/检测出从另一端到本地端TCP的单向路径正遇到拥塞和/或包丢弃和/或物理传输错误和/或极少的极突然拥塞级别产生事件(但是这里不包含罕见的200ms延迟ACK事件：另外，如果两个端中仅一者经修改且(例如)以超出正常窗口范围的DUP序列号包的形式发送“同步”包到另一未经修改端的TCP(其引出从另一未经修改端的TCP返回的返回回应ACK)，那么本地经修改端的TCP将仅能够立即知道/推断/检测出本地经修改端TCP与另一未经修改端TCP之间的转发或返回路径中的任一者(但是不明确地知道哪一者)正遇到拥塞和/或包丢弃和/或物理传输错误和/或极少的极突然拥塞级别产生事件(但是这里不包含罕见200ms延迟ACK事件))。这个额外的从一端到另一端和/或从另一端到这一端的单向路径的明确检测/明确推断(为明确的“开启”或明确的“关闭”)此时将可用于更好地相应做出反应。这可或可不实际应用，注意，如果返回单向路径碰巧是“关闭”的，无法知道前向的单向路径是“开启”还是“关闭”。也应注意，任何已丢失/丢弃但是没有使(实际到达的包的)包间到达延迟的“经过的时间周期”期满(例如，由于其它较迟的无序物理到达包在“经过的时间间隔”内到达)的失去“间隙”包将通常通过平常的3个DUP ACK快速重传机制来处理：或者，包间到达延迟“经过的时间间隔”机制可替代地严格地强调任何失去的“间隙”包应在未在其直接按次序发送的先前包(如由包的序列号定序……等)的到达时间的“经过的时间间隔”内被接收到时触发“经过的超时”期满。

当子流的包间到达延迟的“经过的时间间隔”期满且没有出现来自相同子流的任何类型的包(但是不包含子流的产生的“同步”包类型，或(在可应用的情况下)子流的对应返回回应ACK)时，本地端经修改TCP可立即触发且导致本地端的经修改TCP(且/或视情况也“远程地”导致另一端的TCP)进行在主体描述中的较早方法/子组成方法中所述的现有的与CWND减小/速率减小同时的耦合的实际包重传，和/或无相伴的实际包重传的仅经修改的经分解CWND减小/速率减小，和/或伴有或未伴有CWND减小/速率减小的多种经修改“暂停”方法……等，或者仅在自从从另一端的经修改TCP接收到来自相同子流的任何类型的上次/最新包(但是不包含子流的产生的“同步”包类型，或(可在应用的情况下)子流的对应返回回应ACK)以来的另一特定周期(例如，250ms)(用户输入值或基于包含诸如RTTest、OTTest、RTTest(min)、OTTest(max)……等因素的算法的某一导出值)已经过去之后进行此(且在这个(例如)250ms时间期间不会接收来自相同子流的任何类型的随后新的介入的到达包(但是不包含子流的产生的“同步”包类型，或(在可应用的情况下)子流的对应返回回应ACK))……等，且/或已发送整个当前有效窗口中可传送的相同子流的包，且所有包都没有得到返回的应答时进行此。

在两个端都实施“包间到达”方法和“同步”包方法的情况下，发送到另一经修改端的TCP的“同步”包可简单地呈所产生的具有与特定每流TCP连接相同的源IP地址端口号和相同的目的IP地址端口号以及具有唯一地识别如“同步”包之类的包的适当识别的包形式：诸如数据字段部分中的特定固定长度唯一识别或插入的“填充”字段部分，例如含有源IP地址端口号和/或目的IP地址端口号，而不需要引出另一进行接收的经修改端的TCP来产生返回回应ACK……等。如果仅所述端中的一者被修改且另一端未被修改(但是即使在两个都被修改的情况下也可应用)，那么当由经修改端向另一未经修改端发送“同步”包时，所述“同步”包将需要呈引出来自进行接收的未经修改端的返回回应ACK的包的形式，例如具有与特定每流TCP连接相同的源IP地址端口号和相同的目的IP地址端口号以及不在窗口内的复制序列号字段值的包，其引出来自进行接收的未经修改端的返回回应ACK(诸如发送(例如)不在窗口内的无序序列号包，所述进行接收的TCP总是产生“不操作”返回ACK，见因特网新闻组题目“应答无序包”http://groups-beta.google.com/group/comp.protocols.tcp-ip 1Phil Karn，1988年3月2日，2CERF，1988年3月2日……，和Google搜索术语“ACKing ACK”，也注意，发送单个DUP ACK将不会引起快速重传。或者，诸如发送(例如)无序ACK，见Google搜索术语“out of order ACK”、“eliciting ACK”、“UDPSequenceNumber ACK”、“ACK foe unsent data”、“unexpected ACK”……等)。引出的来自另一未经修改端的返回回应ACK将简单地使ACK字段值经设定成待由另一未经修改端从经修改端接收的下一期待序列号，当接收到这个返回回应ACK时，经修改端将仅放弃并忽略这个返回回应ACK，因为下一期待序列号数据区段尚未发送。在极少的“千载难逢”情形(这个下一期待序列号数据区段实际上仅在接收返回回应ACK之前的时刻被发送)中，经修改端现在将仅在接收3个返回回应DUP ACK(所有DUP ACK具有相同的ACK号)时和之后进行“不必要地”快速重传，这也同样非常不可能发生，因为数据区段实际上就在接收初始返回回应ACK之前的时刻发送的，且/或随后发送的数据区段现在将递增另一未经修改端的下一期待序列号，从而使得下一返回回应ACK现在载运不同的较大的已增加的ACK号字段值。

上述段落主要描述两个端的TCP实施“同步”包发送到另一端的TCP的情形。这使得只要“经过的时间间隔”期满而没有从另一端的TCP接收到相同子流的任何包(包含产生的相同子流的“同步”包)，每一端的TCP便能够明确地确认/明确地推断从另一端的TCP到本地端的TCP的单向路径发生拥塞和/或包丢弃和/或物理传输错误和/或极少的极突然拥塞级别产生(但是200ms延迟ACK机制现在将不是原因，因为这里实施“同步”包机制)。更多完整组合情形包含以下情形(假定两端的经修改TCP进一步包含“同步”包方法)：

1.当在本地端的经修改TCP处“经过的时间间隔”期满而没有从另一端的经修改TCP接收到相同子流的任何包(包含两个子流的所产生的“同步”包类型)-＞明确知道/明确推断从另一端的经修改TCP到本地端的经修改TCP的单向路径是“关闭”的-＞本地端的经修改TCP现在应立即相应地做出反应且/或使另一端的经修改TCP相应地做出反应。

2.当从另一端的经修改TCP到本地端的经修改TCP的单向路径是“开启”的，即，从另一端的经修改TCP接收到连续包(和/或“同步”包)而没有造成“经过的时间间隔”期满时，且如果没有在某准则(诸如分解速率递减超时、耦合RTO包重传超时、引起“暂停”的分解ACK超时等)内从另一端的经修改TCP接收到期待的应答(对于由本地端的经修改TCP发送的数据包)，那么在明确知道/明确推断出从本地端的经修改TCP到另一端的经修改TCP的单向路径是“关闭”的同时，本地端的经修改TCP现在应立即相应地反应且/或使另一端的经修改TCP相应地反应。

在仅TCP连接的一端实施“同步”包方法的情况下，在此情形中可通过以下方式修改前述方法：使实施“同步”包方法的端的经修改TCP发送“同步”包到另一端的未经修改TCP，所述包呈传统地引出来自另一端的未经修改TCP的应答回应的包形式(诸如发送出(例如)不在窗口内的无序序列号包，所述进行接收的TCP总是产生“不操作”的返回ACK，见因特网新闻组题目“应答无序包”http://groups-beta.google.com/group/comp.protocols.tcp-ip 1Phil Karn，1988年3月2日，2 CERF，1988年3月2日……，和Google搜索术语“ACKing ACK”，也注意，发送单个DUP ACK将不会引起快速重传。或者，诸如发送出(例如)无序ACK，见Google搜索术语“out of order ACK”、“eliciting an ACK”、“UDPSequence No ACK”、“ACK for unsent data”、“unexpected ACK”……等)。

“同步”包方法应确保可存在至少一“包”在小于“经过的时间间隔”值的间隔(诸如，“经过的时间间隔”的一半……等)中从本地端经修改TCP发送到另一端的TCP(不管经修改与否)。在两个端实施“同步”包方法的情况下，两个经修改TCP协议可优选地(例如)在TCP连接阶段或紧跟其后的时间段中允许检测彼此的存在、同步间隔参数的一致性……等。但是这里在没有在“经过的时间间隔”期限内从另一端的未经修改TCP接收到任何包时，本地端的经修改TCP仅可明确地推断单向路径中的任一者为“关闭”的(而不能明确推断从本地端的经修改TCP到另一端的未经修改TCP或从另一端的未修改TCP到本地端的经修改TCP的单向路径中的哪一者是“关闭”的)(与当两个端经修改且实施“同步”包技术时相对照)。

在较早的主体描述中所说明的各种方法/子组成方法可被修改成使用“经过的时间间隔”方法和/或“同步”包方法，(例如)而不是使用在ACK超时时的分解速率递减(即，不是监视所发送序列号段的在(例如)未拥塞RTT*乘数内没有接收到的应答来相应地做出反应，而监视所接收的任何下一包的“经过的时间间隔”)。这允许比可能大得多的未拥塞RTT*乘数快得多的反应时间(“经过的时间间隔”)。

在选择了时间戳记选项的情况下，这将使得两个单向路径等待时间(即，可导出OTTest和OTTest(min)……等，而不仅仅是RTTest和RTTest(min)……等)能够更好地相应做出反应。SACK选项将使得能够较少地不必要重传已经无序接收的包。“同步”包和/或较早周期性探测器包方法可(在需要时)以在目的IP地址和端口、源IP地址未改变但源端口现在被指派不同的未使用端口号的每TCP流之间建立的新的TCP连接形式被独立发送。

应注意：在每一每流TCP内的“包间到达”和/或(视情况)“同步”包方法可在某准则/时间被满足时操作以稳定在每流TCP中，诸如仅在初始Sync/SyncACK之后，和/或仅在从另一端的TCP(经修改或未经修改)接收到少量(n)个连续包之后，和/或仅在从另一端的TCP接收到少量(m)个连续包(所有包都在彼此的直接在前的包的“经过的时间间隔”内到达)之后。当“同步”间隔期满要求发送“同步”包时，本地端的经修改TCP可替代地重新发送/重传尚未经应答的先前已发送的常规数据包(代替纯“同步”包)到另一端的TCP(其也可引出从另一端的TCP返回的应答回应)。

应注意：这里的方法扩展了我们的修改/发明，使得也可在源发送器或接收器中的任一者(或两者)驻留在外部因特网的情况下应用，但是也可在两者驻留在因特网子集/WAN/LAN/私有因特网内的情况下应用，如在描述主体中的各种上文描述方法中。

可在描述主体中的各种上文描述的经修改TCP/经修改监视软件/经修改TCP转发器/经修改IP转发器/经修改防火墙中提供用户接口，以允许各种TCP调整/注册参数的用户输入(例如，初始ssthresh，初始RTT、MTU、MSS、延迟ACK选项、SACK选项、时间戳记选项……等)、私有LAN/WAN子网IP地址(使得与所述子网内的源和目的地两者的包通信量可被确定为“内部通信量”(与到/来自外部因特网的通信量相对照))和所述子网地址的每一者之间的ACK超时和/或“经过的时间间隔”和/或“暂停间隔”和/或“同步”间隔(为了更好的性能，而不是仅使用(例如)如等于在整个子网内的最远节点对之间的最大未拥塞RTT*乘数的最大ACK超时值)的用户输入，共同TCP端口(因此可不同地处理到/来自所述共同端口的包通信量)和/或额外使用的TCP端口和/或将被排除在所述特殊处理之外的源或目的地端口中的任一者(例如，一些多媒体流使用具有特定端口号的TCP，而不是UDP)的用户输入……等。

这里为在主体描述中所描述的方法/子组成方法和/或包间到达方法和/或“同步”包方法的组合的多种可能性中在某些情形下的一些实例例子(仅概述)(在仅TCP连接的一端经修改的情况下，如果两端都经修改，那么这将很明显使得在两端检测到彼此的修改的存在之后使任务容易得多)：

1.本地端经修改TCP充当到外部因特网的发送器源，且直接修改TCP堆栈。

发生“触发”事件(诸如300ms“经过时间间隔”、3个DUP ACK、RTO实际包重传超时……等)时，除了其它可能性外，这将仅要求TCP本身仅“暂停”一经界定的暂停间隔(或甚至根本不暂停)，和/或允许在暂停期间传输少量包以充当探测器，接着再继续(或无暂停地继续)，而不改变CWND/速率限制或将CWND/速率限制减少x％(例如，5％、10％、50％……等)。

应注意，如果在(例如)300ms的“包间到达”期满时实施“暂停”，那么基于发送器的修改在这里具有以下优点：可知道(例如)300ms的“包间到达”期满是否仅因为本地端发送器没有要传输到另一端的数据包因而无需不必要地“暂停”且/或不必要地做出相应反应(与以下情况做对照：当本地端充当接收器时，其将无法知道(例如)300ms的“包间到达”期满是因为“触发”事件还是仅因为另一端的发送器暂时没有其它的数据包要传输)。

包间到达方法可替代“未拥塞RTT*乘数”方法用作触发事件以相应地反应，另外，如果结合了“同步”包方法(这里仅从本地端经修改发送源TCP产生，但是引出来自另一端的未经修改的TCP的回应(如返回ACK))和/或时间戳记选项，那么将能够明确检测/明确推断哪一方向的链路明确地“关闭”或明确地“开启”。

2.本地端经修改TCP充当到外部因特网的发送器源，且不直接修改TCP堆栈。

这里，经修改软件监视器/经修改TCP代理/经修改防火墙……等将需要代替TCP堆栈本身来执行所述任务。发生“触发”事件(诸如300ms“经过时间间隔”、3个DUP ACK、RTO实际包重传超时……等)时，除了其它可能性外，这将仅要求经修改软件监视器/经修改TCP代理/经修改防火墙……等仅在一经界定的暂停间隔中“暂停”所截获的TCP包转发，和/或允许在暂停期间传输少量包以充当探测器，接着当再继续时，(例如)“欺骗性发送”针对所有到达的被截获的传出TCP包的固定数量的ACK(以便快速恢复TCP的CWND/速率限制，其可能(例如)已在重新进入“慢速起动”时被重设到1个区段大小)，且/或通过保持窗口中可传输的数据的实际副本，从而通过不转发所述DUP纯ACK到TCP和/或在转发到TCP之前在重计算校验和中移除捎带确认DUP ACK包中的ACK位来抑制所有快速重传DUP ACK包，而甚至(例如)在经修改软件监视器/经修改TCP代理/经修改防火墙……等(而不是TCP本身，其现在将不会被要求重传任何发送包)内处理所有快速重传3个DUP ACK/RTO超时实际包重传，且/或就在TCP将具有RTO超时……等之前“欺骗性发送”到TCP的ACK……等。这里应注意，如果在(例如)300ms的“包间到达”期满时实施“暂停”，那么基于发送器的修改在这里具有以下优点：可知道(例如)300ms的“包间到达”期满是否仅因为本地端发送器没有要传输到另一端的数据包因而将无需不必要地“暂停”且/或不必要地做出相应反应(与本地端充当接收器的情况相对照，其将无法知道(例如)300ms的“包间到达”期满是因为“触发”事件还是仅因为另一端的发送器暂时没有其它的数据包要传输)。

包间到达方法可替代“未拥塞RTT*乘数”方法用作触发事件以相应地反应，另外，如果结合了“同步”包方法(这里仅从本地端经修改软件产生，但是引出来自另一端的未经修改的TCP的回应(如返回ACK))和/或时间戳记选项，那么将能够明确检测/明确推断哪一方向的链路明确地“关闭”或明确地“开启”。

3.本地端经修改TCP充当外部因特网发送器源的接收器，且直接修改TCP堆栈。

包间到达方法可替代“未拥塞RTT*乘数”方法用作触发事件以相应地反应，另外，如果结合了“同步”包方法(这里仅从本地端经修改接收器TCP产生，但是引出来自另一端的未经修改的TCP的回应(如返回ACK))和/或时间戳记选项，那么将能够明确检测/明确推断哪一方向的链路明确地“关闭”或明确地“开启”。其它技术(诸如分割ACK/DUP ACK/最有利情况下的ACK)可用于递增另一端的未经修改发送源TCP的CWND/传输速率(只要需要)，且窗口大小更新包技术可用于使另一端的未经修改的发送源TCP“暂停”……等。

4.本地端经修改TCP充当外部因特网发送器源的接收器，且不直接修改TCP堆栈。

这里，经修改软件监视器/经修改TCP代理/经修改防火墙……等将需要代替TCP堆栈本身而执行所述任务。发生“触发”事件(诸如特定子流的300ms“经过时间间隔”)时，除了其它可能性外，这将仅要求经修改软件监视器/经修改TCP代理/经修改防火墙……等仅远程地使另一端的发送器TCP在一经界定的暂停间隔中“暂停”特定子流的的包转发，和/或允许在暂停期间传输少量包以充当探测器，接着当再继续时，(例如)快速发送固定数目的DUP ACK到另一端的发送器TCP(以快速恢复另一端的TCP的CWND/速率限制，其可能(例如)已在重新进入“慢速起动”时被重设到1个区段大小)。包间到达方法可替代“未拥塞RTT*乘数”方法用作触发事件以相应地反应，另外，如果结合了“同步”包方法(这里仅从本地端经修改接收器TCP产生，但是引出来自另一端的未经修改TCP的回应(如返回ACK))和/或时间戳记选项，那么将能够明确检测/明确推断哪一方向的链路明确地“关闭”或明确地“开启”。其它技术(诸如分割ACK/DUP ACK/最有利情况下的ACK)可用于递增另一端的未经修改的发送源TCP的CWND/传输速率(只要需要)，且窗口大小更新包技术可用于使另一端的未经修改的发送源TCP“暂停”……等。

TCP连接是对称的，即，本地端能够同时发送并接收数据(即使根本不在发送真实数据也总是存在发往另一端的所产生的返回ACK)，本地端的经修改TCP/经修改监视软件/经修改TCP代理/经修改防火墙……等当然可同时充当基于发送器和基于接收器。另外，在两端都经修改的情况下，每一端可再次同时充当基于发送器和基于接收器，并一起工作；但是优选地和/或替代地，一旦两端检测到彼此的修改的存在，其可对于每一工作约定仅充当基于发送器，或对于每一工作仅充当基于接收器，或仅一端将充当基于接收器和基于发送器两者，同时另一端的经修改操作被禁用。检测彼此的修改状态的许多可能方式的实例是(例如)将在“填充字段”或固定长度数据部分内具有特殊唯一长度识别模式的包发送到另一端。

可从描述主体中所揭示的各种方法和/或子组成方法的组合导出的实例方法

(为了能够量测且/或估计各种单向行程时间OTT、OTTest和估计的未拥塞OTTest(min)……等，将需要在TCP连接建立SYNC/SYNC ACK阶段期间协商得到时间戳记选项。通过发送器从返回的对应ACK的多种时间戳记字段值导出特定发送区段/包的从发送源到接收器的单向行程时间OTT。明显地，在发送源或接收器可获得OTT、OTTest、OTTest(min)值时将允许更好且更有效的传输控制，因为RTT、RTTest、RTTest(min)本质上包含由前向路径和返回路径不对称性引入的不确定要素。)

(A)在诸如LAN/WAN/私有因特网的私有网络中的对最新未拥塞RTTest(min)和/或最新未拥塞OTTest(min)……等进行基于发送器监视，以检测包开始被缓冲且/或包丢失的开始

在私有网络中，实现有保证服务能力所需进行的全部操作是使在私有网络中的每个PC/服务器……等(或仅大量的通信量繁重的源)安装上文所述的经修改TCP升级或监视软件……等中的任一者(或常驻在PC/服务器……等上的应用软件直接在应用程序内(例如，直接在RTSP流应用程序内)实施所述修改)。

如果在私有网络内预先知道每个子网间的未拥塞RTT值或未拥塞OTT值(应注意，未拥塞RTT值或未拥塞OTT值可因不同大小的数据包而变化，尤其在媒体链路具有低带宽(如ISDN)的情况下会变化，大多数TCP包大小在TCP连接建立阶段期间被预协商得到：通常所协商得到的最大区段大小MSS值为大约800字节、1500字节……等)，那么当(例如)特定源-目的地流的未拥塞RTT或未拥塞OTT时间周期+指定时间周期B经过，而没有接收到对于特定发送包的对应ACK时，经修改TCP升级或监视软件……等中的每一者在这里可简单的减小个别的每TCP流的传输速率(通过“暂停”周期，或通过CWND窗口大小百分比递减……等)。时间周期B在这里对应于由包在沿所通过路径的各种节点处被缓冲时所引入并经历的总的包缓冲延迟累积：在这里将这个值设定为(例如)20ms的小周期，这将确保其它实时关键VoIP/视频会议HDP包享受非常好的有保证服务级别，因为UDP包在这里将不太可能沿所通过的各种节点遇到比20ms大得多的累积的总缓冲延迟。在这里设定B＝0将确保TCP流将总是试图立即避免包缓冲延迟的任何开始，从而保持网络无缓冲延迟，或当缓冲延迟确实偶然发生时，在偶然的间隔期间仅有极小的缓冲延迟。可将TCP速率递减百分比设定成各种固定值或用算法导出各种动态值，例如，(B ms+(例如)T ms)/1000ms，且如果B＝50ms且T＝50ms，速率递减百分比在这里将为10％，即，TCP传输速率现在将减小到现有传输速率的90％-＞现在可看到，此后，瓶颈链路的通过量级别现在将稳定维持在瓶颈链路的带宽容量的90％左右，假定其后通过瓶颈链路的流现在不会进一步递增或递减其传输速率。TCP速率递减百分比算法导出值的其它可能的非排他性实例可简单地为(例如)B ms/每TCP流的未拥塞RTT值，且在B＝50ms，未拥塞RTT＝400ms时，速率递减百分比在这里将为12.5％。较早加上时间周期T ms/也可在此时加上时间周期T ms，使得在较大的速率递减百分比的情况下，通过瓶颈链路的流(其传输速率递增，这在TCP中是常见的)现在将花费更长的时间来再次到达100％的链路通过量级别或更大的链路通过量级别而接着需要缓冲，因而这将对其它实时关键有保证服务UDP包产生轻微的影响。

经修改TCP升级或监视软件……等(只要需要)可通过CWND百分比递减和/或通过以此方式的“暂停”……等来实现每TCP流的速率调节，以在各种指定“触发事件”(例如，遇到的B ms的累积的总缓冲延迟……等)之后达成所需的理想瓶颈链路通过量(例如，随后导致100％、99％、95％、85％……等瓶颈链路带宽利用率，而不是现在的伴有包缓冲延迟的超过100％的利用率级别)。可进一步设计各种算法和策略和程序来用各种不同方式处理各种“触发事件”。

在这里应注意，经修改TCP升级或监视软件……等不一定需要预先知道在私有网络内的各种子网之间的子网间未拥塞RTT或子网间未拥塞OTT。在这里，替代地，经修改TCP升级或监视软件……等可追踪个别的每TCP流的当前最新观察的最小RTT值或当前最新观察的最小OTT值，且认为它动态地等效于所述个别的每TCP流的未拥塞RTT或未拥塞OTT。这些RTTest(min)或OTTest(min)的常识性下限和上限：例如，可将其最大上限设定成私有网络内的已知的最远位置对的RTTmax值……等。

(A1)在诸如LAN/WAN/私有因特网的私有网络中对最新未拥塞RTTest(min)和/或最新未拥塞OTTest(min)……等进行基于接收器监视，以检测包开始被缓冲且/或包丢失的开始

(根据早先的基于接收器的方法/子组成方法和在本文段落及描述主体的各个部分中描述的各种方法/子组成方法，可直截了当地实现这一目的，其使用远程ACK分割/多个DUP ACK/最有利情况下的ACK和各种大小的窗口大小更新来引起“暂停”，并通过复制包方法引出“不操作”ACK回应，使用3个DUP ACK以触发快速重传以预防RTO重传……等)

(B)在诸如LAN/WAN/私有因特网的私有网络和/或外部因特网中对最新未拥塞RTTest(min)和/或最新未拥塞OTTest(min)……等进行基于发送器监视，以检测包开始被缓冲且/或包丢失的开始

外部因特网中会有不像在私有网络中一样受到控制的其它现有未经修改的TCP流。将需要进一步修改上述(A)中的实例以考虑到这一点。

在这里需要进一步修改通过CWND百分比递减和/或“暂停”……等来引起速率递减的“触发事件”，例如，在回落到(例如)100％/99％/95％/85％……等之后在指定的或动态算法导出的s秒中不递增，如果瓶颈链路的通过量利用率随后再次返回到100％或更多(从而导致在上述s秒内包缓冲延迟开始)，那么允许传输速率再次开始递增/增长，直到发生“触发事件”(其可为包丢弃/超过缓冲延迟门槛值……等)为止，否则在s秒经过后开始允许传输速率递增/增长。可进一步设计各种算法和策略和程序来用各种不同方式处理各种“触发事件”。

在这里在外部因特网上，不容易预先知道新建立的每TCP流的未拥塞RTT和/或未拥塞OTT，因此当前最新观察的RTTest(min)或OTTest(min)将替代地提供未拥塞RTT和/或OTT值的动态估计等效值。

现有标准TCP强调竞争TCP流的公平份额和友好性，但是在完全利用可用带宽以获得最大通过量过程中的低效率在重新获得先前建立的传输速率/通过量所需的很长周期中显露无遗，所述很长周期出现在甚至仅单个包丢弃RTO超时之后或3个DUP ACK快速重传(尤其是在具有高带宽和长RTT等待时间的长距离粗管道上)之后(其主要因为在慢速起动的指数CWND增长期间达到SsthreshCWND大小之后，在拥塞避免模式中的现有TCP保守线性CWND递增)。经修改的TCP的新的改良准则现在应包含高度利用可用带宽和/或可用缓冲器以获得最大TCP通过量，而不仅仅是低效率的缓慢而非常友好的公平共享。此处的在发生各种“触发”事件时“暂停”和/或减少CWND的经修改TCP的非常快速反应时间(不是现有RFC的用于动态导出RTO值的默认最小下限值1秒)将最小化包丢弃百分比，上文描述的“继续暂停”将进一步非常灵活地减小传输速率递减大小，即从(例如)每RTT 64千字节到仅仅每(例如)300ms 40字节。

可用许多种不同方式使此处的经修改TCP在选择CWND递增大小(和/或等效的“暂停”间隔、“继续暂停”间隔设置(例如)变为更小值)方面更为激进。可将CWND递增(例如)每所接收ACK和/或每RTT的MSS的一指定整数倍或动态导出的整数倍，而不是现有RFC的每所接收ACK和/或每RTT的1MSS，Ssthresh值可初始化成指定值和/或永久固定到非常大的值，诸如与在TCP连接阶段期间协商得到的最大窗口大小相同……等。当在发生“触发事件”后实现速率递减(诸如包丢弃/耦合/分解RTO超时、3个DUP ACK快速重传、ACK在严格设定的指定间隔外返回时分解的速率递减……等)时，经修改TCP将努力以一方式递减速率，使得确保瓶颈链路利用率将维持在高通过量上，例如，100％/99％/95％/85％……或甚至维持在各种高于100％的拥塞缓冲延迟级别等上(假定通过路径的所有TCP全部是经修改TCP)。

作为各种许多可能性中的说明，经修改TCP(发送器或接收器，或者所述两者)在这里将预先知道未拥塞源-接收器-源RTT或未拥塞源-接收器OTT值，或上述的动态最佳估计RTTest(min)/OTTest(min)等效值：当所通过的所有链路的每一者没超过它们各自的100％的可用带宽(即，在所通过的节点的任一者处没发生包缓冲)时，从(例如)返回ACK导出的RTT或OTT或RTTest(min)或OTTest(min)值现在将与真实的实际未拥塞RTT或未拥塞OTT值一样(具有非常小的由节点处理延迟/源或接收器主机处理延迟……等引入的随机变化量，下文称为V ms：这个值V ms变化量通常将比其他较早描述的系统参数(如指定的或动态导出的Bms……等)小某个数量级)。如果V ms出乎意料地在极少情况下短暂地变得非常大，例如窗口OS不是实时OS……，那么这可替代地“例外地”以与由遇到的节点缓冲延迟的发生/引入/引起一样的方式处理)。只要从(例如)返回ACK导出的RTT或OTT或RTTest(min)或OTTest(min)值继续显示没有沿所通过的路径遇到的缓冲延迟，那么经修改TCP可如现有RFC中一样继续保守地允许传输速率的递增/增长，或更激进地递增/增长。在超过所指示/从返回ACK导出的某级别缓冲延迟时，即[(返回RTT或OTT)-(RTTest(min)或OTTest(min))]的以毫秒计的值现在将指示在沿所通过路径的各种节点处遇到的累积的总的缓冲延迟(下文称为C ms)。例如，在超过C的20ms/50ms/100ms……等值时，经修改TCP现在可(例如)减小传输速率，使得此后的瓶颈链路利用率将维持在(例如)100％/99％/95％/85％……等处，假定通过瓶颈链路的所有TCP全部都是经修改TCP(现在知道了每TCP流的实际未拥塞RTT或未拥塞OTT的最新估计等效值，和值C，现在就可确定所需CWND递减百分比和/或“暂停”间隔或适当的所需“暂停”的序列以达成所需的理想端结果)。经修改TCP现在可如(例如)较早所述而例如在一周期s秒(指定的或动态算法导出的)中停止TCP流的任何进一步速率递增/增长，接着如较早所述或另外设计的各种不同方式相应地回应。这个特定实例除了具有达成现有RFC的友好公平共享外的效果外，还具有达成高利用率通过量的效果，且还有助于使所通过的路径的累积缓冲延迟维持在与C值相关的低级别；在没有其它强支配性未经修改TCP流的情况下，经修改TCP流在这里将/可开始允许在s秒内速率递增/增长，接着与所有其它未经修改TCP流一起最终引起包丢弃事件：于是未经修改TCP流将重新进入“慢速起动”，从而花费非常长的时间来重新获得先前达成的传输速率，而经修改TCP流可重新获得先前达成的传输速率/通过量的任意的高比例(解决现有的尤其与长RTT长距离粗管道相关联的回应问题)。在经修改TCP速率递减以达成(例如)随后的95％瓶颈链路利用率的情况下，新的TCP流(和/或其它新的UDP流……等)将总是能够立即利用多达5％的可用瓶颈链路带宽来开始流速率递增/增长，而不会引入沿路由路径的包缓冲延迟，另外瓶颈链路将能够立即容纳X毫秒的新的额外的突然瞬时通信量猛增(等于可用带宽)，而不丢弃包(大多数因特网节点通常具有300ms到500ms之间的等效缓冲大小)：这与保留现有流的已建立通过量同时允许逐渐的受控的新的额外流增长的普通的常识一致。

或者经修改TCP可总是允许如现有RFC的线性增长一样保守地速率递增/增长，或更激进地速率递增/增长(而不是检测到C ms的累积的总缓冲延迟时减小等)，且仅在包丢弃事件发生时减小：这个将仅对最大化TCP流的通过量有利且对其它实时关键性UDP流不利。但是通过简单地为UDP包优先转发等保留可用物理带宽的有保证最小百分比，所通过的节点可容易地确保实时关键性UDP包的非常好的有保证服务性能。

网站服务器/服务器群可有利地实施上述经修改TCP实施方案。典型的网站常常经优化以具有大约30千字节到60千字节的高速下载(对于连续的未被包丢弃……等中断的以大约5千字节/秒下载的模拟56K调制解调器来说，这将仍然花费大约6秒到12秒)。就在SYNC/SYNC ACK/ACK TCP连接建立阶段之后，发送源服务器的经修改TCP将具有每TCP流的未拥塞RTT或未拥塞OTT的最初的首次估计，其形式是当前最新观察的最小源-接收器-源RTTest(min)或源-接收器OTTest(min)值(不管其是否代表实际未拥塞RTT或未拥塞OTT值)。发送源服务器的经修改TCP现在可视情况立即开始发送最初的数据区段/包，立即以具有W个区段(例如，协商的最大区段大小MSS为大约1600字节，且W＝20)的CWND窗口大小起动，所有60千字节的内容由客户端网页浏览器接收到将仅花费2*RTT(假定传输中没有包丢弃或被破坏，且沿路径的最小链路带宽是最终用户的最后一英里500千比特/秒的宽带)。在W＝64的情况下，客户端网页浏览器完全下载60千字节的网站内容可仅花费1RTT或1OTT(典型的因特网RTT通常为大约几十到几百毫秒，包含由沿路径的缓冲引入的延迟)。如果沿路径的最小链路带宽是最终用户的最后一英里56千比特/秒的模拟调制解调器拨号连接，那么上述时间周期将为至少6秒或12秒，因为最后一英里链路上的传输仅可为最大5千字节/秒左右(假定30千字节或60千字节的区段/包在通过拨号连接传输到最终用户的网页浏览器之前，首先在最终用户的最后一英里ISP(AOL网页代理服务器)处被缓冲)。即使在极坏情况下，初始的20或64MSS CWND窗口中可传送的区段/包也将立即引起缓冲溢出，因此在任何瓶颈链路处丢弃所述区段/包，经修改TCP在这里可以上文描述/简要说明地方式非常快地进行相应反应(大大快于现有RFC的1秒最小值的最小下限默认反应时间)，例如，速率递减以确保随后瓶颈链路利用率/通过量的某些级别(而不是现有RFC的速率减半和因此的延长的带宽利用周期)，和/或更受控的激进的随后速率递增/增长，和/或更受控的缓冲延迟级别拥塞避免(例如，在允许速率递增/增长之前等待s秒……等，而不是现有RFC的“等待包丢弃”的唯一方案)……等。

应注意，如果需要以监视软件/代理TCP……等的形式实施经修改TCP或用于网站服务器的经修改TCP(例如，不直接接触主机TCP堆栈源代码来进行修改)，这将实质上简单地要求常驻在发送源服务器处的监视软件/TCP代理(在需要时)“欺骗性发送ACK”到常驻的发送源服务器的TCP堆栈，以受控地更激进地递增CWND窗口大小/传输速率，且/或(在需要时)欺骗性发送零或小的接收器窗口大小更新包到常驻的发送源服务器的TCP堆栈以临时性地停止传输或递减传输速率，且/或(对于监视软件来说)在向前转发所截获的TCP起始包过程中，通过“暂停”/“继续暂停”(且/或在每一暂停间隔中允许转发1个或少量包)实现等效传输速率递减，且/或保持一个完整窗口中可传送的由常驻主机的TCP堆栈发送的所有实际数据区段/包以接着执行所有耦合或分解RTO重传/3个DUP ACK快速重传，从而免去常驻主机TCP堆栈的所有所述职责，且/或当监视软件确实“欺骗性发送ACK”到常驻主机TCP堆栈以实现受控的更激进的速率递增/增长时和/或当利用ACK分割/多个DUP ACK/最有利情况下的ACK技术来进行此时，保持在多个完整窗口中可发送的由常驻主机的TCP堆栈发送的所有实际数据区段/包，因而允许常驻主机TCP堆栈在单个RTT内产生在多个完整窗口中可发送的区段/包，和/或检查来自网络的传入的返回ACK包和/或检查其RTT/OTT以相应地反应，包含在向前转发到常驻主机TCP堆栈之前是否修改各种字段(ACK号、序列号、时间戳记值、各种标志、通告窗口大小……等)还是甚至放弃，和/或……等，如描述主体中的各种上文方法/子组成方法中所述。

这里应注意监视软件/TCP代理……等甚至可利用上述技术、方法和子组成方法的组合来将常驻主机的有效传输窗口和/或CWND保持为永久固定在某所需大小或甚至总是在最大协商窗口大小，从而仅通过“暂停”/“继续暂停”且/或允许在每一暂停间隔期间转发单个包或少量固定数目的包以充当“探测器”来控制传输速率。

(就在SYNC/SYNC ACK/ACK TCP连接建立阶段之后，发送源服务器的经修改TCP现在可替代地立即开始发送最初的数据区段/包，立即以现有RFC的慢速起动的1MSS区段大小的CWND窗口起动，但是这现在可花费许多RTT来完成内容转移，大约几十秒到数分钟，如最终用户的典型的平时常见的经历。)

(B1)在诸如LAN/WAN/私有因特网的私有网络和/或外部因特网中对最新未拥塞RTTest(min)和/或最新未拥塞OTTest(min)……等的基于接收器监视，以检测包开始被缓冲且/或包丢失的开始

(根据早先的基于接收器的方法/子组成方法和在本文段落及描述主体的各个部分中描述的各种方法/子组成方法，可直截了当地实现这一目的，其使用远程ACK分割/多个DUP ACK/最有利情况下的ACK和/或各种大小的窗口大小更新来引起“暂停”，和/或通过复制包方法引出“不操作”ACK回应，和/或使用3个DUP ACK以触发快速重传以预防RTO重传……等。参见关于实施TCP修改以在外部因特网上工作的上文段落)

作为一实例，利用在TCP连接建立阶段期间协商的时间戳记选项，接收器经修改TCP或监视软件现在可导出等效于到达包的实际未拥塞单向行程时间的源-接收器路径的估计，即，当前最新观察的OTTest(min)。可通过使到达包的OTT减去OTTest(min)而导出由任何到达包遇到的累积的总缓冲延迟(如果有的话)(忽略由节点的包处理/转发时间波动所引入的任何通常非常小的随机变化量)。优选地利用选择性应答选项且禁用延迟的应答选项(例如，通过主机PC的TCP/IP注册条目设置，但是这些并非严格要求)。现在拥有了未拥塞源-接收器路径的实际未拥塞OTT的估计等效值和缓冲延迟级别后，经修改TCP或监视软件现在可以视需要相应地反应(远程地使发送源TCP“暂停”和/或“继续暂停”(其中每暂停间隔允许转发单个包)，和/或“解除暂停”，和/或通过分割ACK/多个DUPACK/最有利情况下的ACK而递增CWND大小，和/或通过早期的3个DUP ACK快速重传而预防RTO超时，和/或……等)，以达成最大带宽利用率/指定的通过量标准，同时保留友好的公平共享。

上面这个实例可进一步经简化以便根本不需要使用时间戳记选项(即，根本不需要导出或利用到达OTT值或OTTest(min)值或导出的累积的总遭遇缓冲延迟值)：接收器经修改TCP或监视软件可替代地非常简单地在自从最近上一接收的直接在前的包的到达时间以来的规定的W毫秒(例如，250ms)间隔中等待下一包到达，且如果下一包不在W毫秒内到达，那么认为它是“触发事件”(最可能地，以后的包被缓冲溢出而拥塞丢弃)，接着立即视需要相应地反应(远程地使发送源TCP“暂停”和/或“继续暂停”(其中每暂停间隔允许转发单个包)，和/或“解除暂停”，和/或通过分割ACK/多个DUP ACK/最有利情况下的ACK而递增CWND大小，和/或通过早期的3个DUP ACK快速重传来预防RTO超时，和/或……等)，以达成最大带宽利用率/指定的通过量标准，同时保留友好的公平共享(但是比上面那个实例更激进)。在这里应注意，如果一包在3个不同节点A/B/C的每一者处遇到3个缓冲延迟(例如，具有300ms)，且随后在沿路径的另一节点D(具有(例如)等效于400ms的缓冲容量)处被缓冲溢出而拥塞丢弃，且在发送源TCP处的(例如)250ms的“暂停”现在将不仅将节点D处的缓冲拥塞级别减少到仅150ms，而且类似地将节点A/B/C的每一者处的缓冲拥塞级别各自减少到仅50ms。而450ms的指定或算法导出的“暂停”间隔值将当然完全清除节点A/B/C/D中的每一节点处的所有缓冲区(即，所有节点现在完全没拥塞，根本没有包被缓冲)。然而了解OTT和OTTest(min)和导出的累积遇到的缓冲拥塞延迟的前面那个实例可取决于对上述值的了解而利用更精细的控制级别来相应地反应，与此进一步简化的实例相对照，所述简化实例仅可主要在缓冲溢出包丢弃事件之后做出反应(注意，甚至当所通过的所有节点处的所有缓冲区(假定每一者具有等效于400ms的缓冲容量)一致地稳定递增到非常接近但还没溢出时，在直接在前的接收包后面的包将仍然在其直接在前的包的(例如)50ms/100ms/200ms/250ms……等内到达)。

优选地，追踪从上一接收包(具有任何长度)以来到达的具有长度L＝1到协商的最大区段大小MSS的下一包的当前最新最小观察的经过间隔E(L)，这向我们提供了具有长度L的单个包沿路径完全离开到最低带宽链路传输媒体(例如，通常最终用户最后一英里56Kbs拨号连接或500Kbs宽带，参见描述主体中的第192到195页)的传输时间延迟的了解/估计等效值。预期传输时间延迟E(L)与包的长度L成线性比例。我们现在可指定W毫秒，使得经修改TCP或监视软件将仅在(例如)W毫秒+具有最大协商区段大小MSS长度的包的E(L)经过而没有包到达时“触发”事件来相应地反应，或仅在(例如)W毫秒(如果假定已在导出/指定W的值时考虑到具有最大协商区段大小MSS长度的包的E(L))时相应地反应。

作为许多实例中的另一进一步简化实例，这里概述在利用包间到达间隔技术的监视软件中实施的非常简单的基于接收器的经修改TCP(其可进一步经修改/调适，且也可直接在TCP本身内实施，而不是在监视软件中实施)，从而在外部因特网上产生更好的性能，例如，快得多的网页下载、ftp下载……等：

1.无论何时从远程发送器接收到TCP包，检查源地址和端口是否已经在每流TCP的表中，如果不在，就产生具有各种参数的新的每流TCP TCB：(不需要维持所有截获的包的较早的序列号/时间发送表条目)

最新的包接收本地系统时间(从远程发送器接收，纯ACK或常规数据包)、最新的接收器包的通告的窗口大小(由本地MSTCP发送到远程发送器)、最新的接收器包的ACK号，即期待来自远程发送器的下一期待序列号(由本地MSTCP发送到远程发送器，需要每流传入和传出包检查，且我们现应能够在FIN/FIN ACK时立即移除每流TCP表条目，而不只是等待通常的120秒的不活动状态)……等。

(可选)一旦Sync/Sync ACK完成，就立即将远程发送器的CWND设定为(例如)用户指定的或动态算法导出的64千字节，例如，也可取决于最终用户的最后一英里链路的带宽容量而设定成成比例的较小或较大大小。当设定成(例如)64K(除非选择窗口缩放选项，其为通常默认的协商的最大窗口大小，这将使得与通常的经历的几十秒相比较，远程外部因特网网站的内容能够在仅单个RTT内被下载)时。这优选地通过(例如)其中(例如)ACKNo＝远程发送器的初始序列号+1的15个紧接的DUP ACK来完成，分割ACK可能不能很好的起作用，因为某些TCP替代地仅使CWND递增已应答的字节的数目，且最有利情况下的ACK特性在所有TCP中可能不同。

应注意：替代地我们将等待从远程发送器接收的第一个数据包，接着产生(例如)15个DUP ACK，其中ACKNo设定为与刚从远程发送器接收的序列号相同的序列号(以仅1个字节的不必要重传为代价)，或者使用分割ACK。

2.如果(例如)300ms(用户指定或动态算法导出的)期满而没有接收到下一个包，那么：

＝＝＞我们只需要在软件内检测没有在前一最后接收到的包的300ms内到达的下一期待序列号，以产生ACK号被设定为未到达的下一期待序列号的3个DUPACK，且同时在3个DUP ACK内传递(例如)1800个字节的窗口更新(等于发送器的“暂停”+1个包)：不断地每次如果(例如)100ms经过而没有接收到任何纯ACK或常规数据包，那么就发送每次递增1800个字节的1800个字节的3个DUP ACK窗口更新，但如果接着接收到任何ACK或任何常规数据包，那么就每100ms重复发送恢复前一窗口大小的通常的(并非3个DUP ACK)相同的单一窗口更新(ACKNo字段设定为从本地MSTCP发送到远程终端的记录的“最新最大的”ACK号，或-1)，直到接着从远程终端再次接收到任何ACK或常规数据包为止，接着在上文步骤2的开始处重复上述(例如)300ms期满检测循环(我们可视情况在再次循环之前，在此时首先利用分割ACK/固定数目的DUP ACK/最有利情况下的ACK技术来设定发送源CWND大小(例如)到经协商的最大窗口大小64千字节/32千字节或(例如)将发送源CWND大小递增16个DUPACK……等)。

应注意，这里我们也可发送3个DUP ACK来代替单一窗口更新包，但在另外2个100ms经过之后，单一窗口更新ACK包将具有总共3个DUP ACK窗口更新包，当然这里替代方案也可为任何窗口更新包，例如DUP SeqNo窗口更新包……等等。

关于可利用的一些子组成技术的各种附注：

在TCP连接建立之后的第一个接收包时起动SYNC/SYNC ACK，如果目前观察到的RTT-当前最新记录的RTTest(min)或目前观察到的OTT-当前最新记录的OTTest(min)大于合理的累积总缓冲延迟(例如，由在源包产生中的临时性延长停止/间隙引起)，那么忽略所述事件且不引起“触发事件”

通过CWND大小百分比减小进行传输速率递减，例如[(目前观察到的RTT-当前最新记录的RTTest(min)或目前观察到的OTT-当前最新记录的OTTest(min))+T ms]/目前观察到的RTT或OTT，但是在这里应注意，T＝0ms暗示引起随后的瓶颈链路通过量达可用带宽的100％，且/或将暂停间隔设定成[(目前观察到的RTT-当前最新记录的RTTest(min)或目前观察到的OTT-当前最新记录的OTTest(min))+T ms]

在内部私有网络的子网地址与外部网络之间进行区别以促动对应的适当方法/演算法。

包间到达技术可经调适以供使用，“同步包”技术也是同样。

可结合使用带宽/链路探测技术(例如，pathchar/pipechar/pathchirp……等)以导出对所通过的路径/节点/链路的更精细的了解，以更好地相应做出反应。

用户输入外部因特网连接速度以允许最大窗口大小协商，例如拨号到5千字节，但是ISP可缓冲甚至64千字节/秒，且以(例如)5千字节每秒的速度转发到用户的56Kbs拨号连接，这(例如)在所通过路径引入很长的(例如若干秒)RTT或OTT时非常便利。

“暂停”/减小CWND的非常快速反应时间使包丢弃百分比最小，“继续暂停”进一步非常灵活地减小传输速率递减大小，即从(例如)每RTT 64千字节到每(例如)300ms仅40字节。

TCP本质上对高RTT流不公平，我们(例如)利用包间到达间隔技术来消除此。

拖延若干ACK，即在向前转发到发送源的过程中将其稍微延迟，目的是为了减小发送源TCP的传输速率/通过量

通过一直能够维持接近100％的瓶颈链路带宽容量利用率/通过量(甚至在缓冲溢出拥塞包丢弃和/或物理传输错误包丢弃之后)，经修改TCP允许大约使好的通过量/瓶颈带宽利用率与对链路带宽容量的利用极其不足的现有RFC的TCP(从现有RFC的TCP的AIMD加法增加乘法减少的锯齿状利用率/通过量曲线可非常显见)相比加倍。

另外的附注和另外的方法

包间到达间隔(例如300ms)技术可视情况仅在接收/发送少于完整有效窗口中可发送的包的包时起作用：否则300ms肯定经过而不接收到新的包，例如当OTT或RTT大于(例如)300ms时(对于到达发送器的返回ACK来说)：也可希望检查最新接收的序列号-最新发送的ACK号以查看是否(例如)大于还是小于还是等于当前有效窗口大小

也可希望视情况在SYNC/SYNC ACK/ACK之后(或在1或2个最初接收的常规数据包之后……)不断地在每(例如)500ms中发送3+DupNum个DUP ACK，使得远程服务器不超时设定CWND和/或SSthresh到1或2个MSS。如果(例如)发送的第一常规数据包的返回ACK-发送的SYNC ACK的返回ACK RTT＞C ms(例如，100ms)，那么发送器TCP可希望或可不希望在初始64千字节的数据包传送期间利用算法(因为所通过路径的拥塞级别的极突然的增加)。

精确说明：

首先设定注册条目，优选地启用SACK且禁用延迟回应

命令行输入参数：

WaitTimeStamp(ms)-经过的包间到达间隔，用以推断“网络拥塞丢弃”

PauseTimeStamp(ms)-“拥塞”时的远程服务器暂停间隔

DupNum-在3个DUP ACK快速重传阶段期间，远程服务器将针对所接收的每一额外的DUP ACK进一步增加CWND大小，我们使用这个技术来发送大量(DupNum)的DUP ACK以使CWND上升

Offse-0或1，不是非常确定DUP ACK中的ACKNo字段在仅设定为记录的最新更新的dwACKNumber(即，接收器MSTCP发送到远程服务器的ACKNo的最新最大值)时是否工作，还是仅在减少1字节之后工作

1.用于处理传出的TCP包(从我们的MSTCP到远程主机的包)的程序

为这个包的TCP连接创建新的条目(必要时)。

必须记录一些变量：

dwACKNumber(如果ACK标志被用信号发送)-TCP标头的ACK字段

dwSEQNumber-TCP标头的序列号字段

dwTCPState-这个TCB变量供自用以按需要控制TCP连接状态，

监视SYNC/SYNC ACK/ACK以将dwMaxRcvWindowSize记录在序列SYN/ACK中的第三ACK包中：仅在检测到从我们的接收器MSTCP发送到远程服务器的SYNC时建立每流TCP(否则不建立)。

甚至在接收到第一数据包之前(假定这用于递增远程服务器的CWND)，一在TCP连接SYNC/SYNC ACK/ACK中发送ACK回应包，接着产生3+DupNum个DUP ACK，其中ACK号＝dwACKNumber-Offset(dwAckNumber是TCP连接SYNC/SYNC ACK/ACK序列中的第三ACK回应包的ACK号)&dwMaxRcvWindowSize&dwSEQNumber字段值。不断在每个WaitTimeStamp间隔中发送3+DupNum个DUP ACK直到第一数据包到达为止(***应注意：在程序流中，仅在第一数据包到达之后启动步骤3，步骤2实际上总是当即有效的)。

2.监视传入包以发现来自远程发送器TCP的FIN或RST和来自本地MSTCP的RST＝＞接着立即终止TCP流，否则在16秒总的不活动状态(即，没有任何类型的传入/传出包)之后终止而不管任何正在进行过程/或循环活动。

3.检查TCP流的程序。(注意，即使在发送3+DupNum个DUP ACK和/或窗口更新包循环的中间，ACKNo和SeqNo必须总是反映瞬时最新发送的“最大”ACKNo(因为“最大”所以忽略较小ACKNo的MSTCP重传)和来自本地接收器的MSTCP的最新发送的“最大”SeqNo)

如果连接建立且WaitTimeStamp毫秒期满而针对任何TCP流没有接收到从远程主机到我们的MSTCP的下一包，那么快速连续地逐个发送3个DUP ACK+DupNum个DUP ACK以通告0字节的窗口大小和ACK号＝最新更新的dwACKNumber(以上记录的)减去Offset&dwSEQNumber字段值。

不断在每100ms中发送上述3+DupNum个DUP ACK，直到从远程主机再次接收到任何ACK或常规数据包为止，或现在PauseTimeStamp毫秒经过而没有接收到下一个包(其中先发生者)(注意：3+DupNum个DUP ACK的所有即将发生但仍未发送的部分现在应在下一个包或PauseTimeStamp经过时立即停止)，随后重复地不断在每50ms间隔中发送大小＝dwMaxRcvWindowSize的单一纯窗口大小更新(其中AckNo字段设定为dwACKNumber-OFFSET，不是DUP ACK等和dwSEQNumber字段值)，直到下一正常数据包(不是纯ACK)从远程主机再次到达，由此，在此之后我们在上述步骤3的开始处再次循环(即，再次等待WaitTimeStamp而没有接收到来自远程主机的包以“暂停”远程服务器等)。

宽带网络(甚至基于国际骨干输送网络)具有非常低的损失率，非常低的拥塞。

Http(端口80签名)流应被允许在例如1个RTT中发送例如64千字节的完整内容。即使SYNC/SYNC ACK/ACK阶段遇到重传(RFC默认1秒)，这也将仅鼓励使用初始64千字节的CWND，因为沿着瓶颈链路的流现在可能速率减半，可能希望间隔开(速率调速在每R ms中发送1个包，使得64千字节在1秒上均匀间隔开而发送)，因此从返回ACK间到达经过间隔(例如100或300ms等)(如果发送的SeqNo和相应返回ACK被预期且在经过的间隔之后未到达，那么应使用无延迟应答，且可针对延迟应答(如果使用)进行调节)，以随后在RTT+(例如100ms或300ms)而不是RFC默认的1秒内针对“检测到的”触发事件(通常为包丢弃)“立即暂停”＝＝＞如果可能被丢弃就不会不必要地发送包！64千字节初始CWND将是好的选择，其较好地适应最后一英里56K和宽带媒体物理线路速率。

此外从记录的返回ACK间到达间隔的最小值等，可有用地明确导出最后一英里媒体物理线路速率(56K、宽带等)。

接收器也可希望在每当检测到本地MSTCP主动发送包(其中ACKNo字段＝＜来自远程TCP的最新记录的最大接收SeqNo(即例如接收到的SeqNo中的“间隙”等))时，或当从远程TCP超时重传(例如返回ACK或发送的3+DupNum DUPACK丢失等)进行接收时，发送3+Dup Num DUP ACK(其中ACKNo字段设定为最新最大记录的所发送传出ACKNo)以使远程CWND再次上升(远程CWND现在超时之后下降回到1或2MSS)。

现有TCP拥塞控制的一种新方法为：

1.例如在使用窗口缩放选项(例如64K+窗口缩放比例)的TCP连接协商期间，发送器TCPWindowSize和接收器TCPWindowSize经由缩放因数0-14而初始化为“任意”的大值，如(例如)2^30(1十亿字节)。(缩放因数0＝不需要设定缩放选项，见RFC1323)

2.接收器TCP(或接收器监视软件等)在SYNC/SYNC ACK时用(例如)4千字节/16千字节/64千字节/或W1千字节等的窗口大小进行ACK，在接收到4千字节/16千字节/64千字节/或任何规定数目的W1或W1千字节的部分时接着将通告接收器窗口大小增加到W2千字节，例如N2*(4千字节/16千字节/64千字节/或W1千字节等)，其中N2为例如1.5/2.0/3.5/5.0等的分数或算法导出的部分且W3、W4......Wn等也是如此，直到数据通信完成(总数小于2^30，即1十亿字节)。

应注意基于接收器的监视软件等可修改截获的接收器MSTCP传出包，从而修改通告接收器窗口大小(在将经修改的包转发到远程发送器TCP之前)，因此实现仅基于连续递增的通告接收器窗口大小的新TCP拥塞控制方法。

和/或

发送器TCP(或发送器监视软件等)在SYNC时用例如4千字节/16千字节/64千字节/或W1千字节等的窗口大小进行SYNC ACK，在接收到应答4千字节/16千字节/64千字节/或任何规定数目的W1或W1千字节的部分的返回ACK时接着将发送器窗口大小增加到W2千字节，例如N2*(4千字节/16千字节/64千字节/或W1千字节等)，其中N2为例如1.5/2.0/3.5/5.0等的分数或算法导出的部分且W3、W4......Wn等也是如此，直到数据通信完成(总数小于2^30，即1十亿字节，如果超过就可能将窗口大小绕回，类似于在例如SeqNo绕回中，或建立新的TCP连接继续等)。

应注意基于发送器的监视软件等可修改来自远程接收器的截获传入包从而修改通告接收器窗口大小(在将经修改的包转发到发送器TCP之前)，因此实现仅基于连续递增的通告接收器窗口大小的新TCP拥塞控制方法。

还应注意TCP可为对称的，一端既可为发送器也可为接收器，即，上述方法因而需要被定向实施。

所述方法将允许任意的较精细的更灵活的更多种的对包传输的控制/调速，同时(如果需要)保留(或提供类似相应机制)所有其它现有TCP错误控制/拥塞控制机制，如缓慢起动/拥塞控制线性增加/3 DUP ACK快速重传/超时等，例如代替早先的发送3+DupNum个DUP ACK(或分割ACK或最有利情况下的SACK技术等)以使CWND上升的方法(具有例如对初始快速重传的SSThresh值的相伴损害、使用最有利情况下的ACK时的端对端TCP语义等)，可更好地实现相同目的和更多目的(例如，使通告窗口大小值递增例如3+DupNum个DUP ACK等而没有伴随的缺点)。

发送器的CWND应初始化为期望的初始值4千字节/16千字节/64千字节或W千字节等，或接收器可在各个时间例如发送3+DupNum个DUP ACK或一系列此类DUP ACK或最有利情况下的ACK等以在最初使CWND上升(现有的RFC2414/3390已经允许4千字节的初始CWND值，在此情况下不需要使CWND上升)。目前因特网上的现有服务器已经将SSThresh值设定为任意的大值(例如等于TCP窗口大小值)，这将实现CWND值的快速指数上升，然而在没有较大SSThresh值设定的情况下，接收器可发送较大数目的例如3+DupNum个DUP ACK以促使CWND的线性上升(例如，1000个DUP ACK＝40千字节＝320千比特，其可全部以宽带在1秒下发送，以使CWND上升到1兆字节(假定SMSS为1千字节)或使CWND上升到16兆字节(如果缩放窗口因数为16))。应注意，缩放窗口因数例如为16时，最小窗口大小递增分辨率将为16字节，即不可能递增(例如)5/8/15等字节。通过连续递增的通告接收器窗口大小方法，接收器可对发送器的包注入速率进行“速率限制”，而不需要发送器以均匀间隔/均匀延迟的包间间隔来发出包。应注意，可能在没有窗口缩放因数的情况下充分地利用此方法(例如，没有缩放选项情况下TCP窗口大小为例如64千字节)，因为可允许的发送窗口随着接收到的每个返回ACK而增大，即接收器可利用对网络条件触发事件的了解(和/或对例如接收到的最新有效SeqNo/发送的最新有效ACKNo等的了解)来连续递增/递减/调节通告的接收器窗口大小，以例如连续调节rwnd，因此当经由“触发事件”检测到拥塞的网络时调节发送器有效窗口大小，其为例如4/16/32/40千字节的rwnd值，为min(cwnd，rwnd，swnd)，且当检测到网络无拥塞/正被利用时将rwnd增大到例如48/56/64千字节，且因此调节发送器有效窗口大小。应注意，可以单独地或与例如“暂停”方法的任何其它方法组合使用此方法。注意：同步包方法可承载经连续调节的rwnd值。

为了仅在接收器上实施所述方法而在远程服务器上没有任何修改(对于初始CWND、SSThresh值设定)，接收器可选择在启动所述方法之前等待(例如)许多秒或许多RTT或许多包经过/被接收(没有介入的发送器RTO超时和/或接收器快速重传请求：如果此情况发生，接收器可选择甚至在发送器的即将发生的RTO超时等之前直接启动所述方法，从而避免发送器RTO超时)，因此CWND已充分大且因此任何快速重传请求将保持充分高的SStresh(等于在3 DUP ACK快速重传请求之前已在处理中的所有包之后的CWND/2)。在需要时，或在整个内容通常小于64千字节的http网站访问中有利时，接收器可在SYNC/SYNCACK/ACK之后或在接收到的1个或2个常规数据包之后接着立即通过最有利情况下的ACK(其中ACKNo＝最新接收的有效SeqNo+例如4/16/32/64千字节等，这将不影响SSThresh值)而使CWND上升，同时与相同的远程IP号和相同的端口号和相同的源IP号但不同的规定端口号建立并行TCP连接，其中紧接在SYNC/SYNC ACK/ACK之后或紧接在接收到1个或2个常规数据包之后，视情况用3+DupNum个DUP ACK使发送器的CWND上升，使得发送器CWND现在＝例如4/16/32/64千字节等(或仅当原始TCP的初始数据包没有全部成功接收到时上升)：如果原始连接全部成功接收到(例如4/16/32/64千字节)，那么第二TCP连接现在可经由RST重设而立即中止，否则(或与原始TCP同时)可从第二TCP连接获得任何失去的最初4/16/32/64千字节的包/区段(例如，由经修改软件转发到原始TCP接收器网络接口...经修改软件在需要时也可记录在最初4/16/32/64字节接收期间的原始TCP连接中的两个方向上的所有的包流(例如，认证包，如果存在)，且在最初4/16/32/64千字节接收期间将完全相同的序列脚本注入第二并行TCP连接)。应注意，即使这里CWND初始化为例如最大64千字节，接收器也可通过根据事件来发送初始为2/4/8千字节的rwnd和递增/调节rwnd(例如窗口更新包或常规数据包)来对发送器注入速率进行调速，例如以2/4/8千字节等开始。

注意：通过等待(例如)接收第一个常规数据包(或更多...，或甚至直接恰好在接收到来自发送器TCP的SYNC ACK之后)，接着通过例如3+DupNum个DUP ACK，其中ACKNo字段设定为接收到的最大最新有效SeqNo而不是通常的最大最新有效SeqNo-1，而使发送器CWND上升(即在TCP会话中拖延应答最大的接收到的一个字节，或视情况)且接着利用连续递增的通告的接收器窗口大小方法(连同两个端上的充分大的窗口缩放)，我们现在已成功使两端的TCP传输速率依据总控制和保留的TCP语义，且通过“暂停方法”，两端的TCP现在可仅经受“暂停”拥塞控制(即CWND)而以完全线速度进行传输，两端的TCP窗口大小、SSThresh值等在TCP流稳定之后的某个时间点处无需起到进一步作用....然而优选地使用连续递增rwnd，其从适当较小的值开始增加，直到例如完全可允许的物理线路速度或当前rwnd大小所允许的传输速度(流现在变为“稳定”...)。

明显地，发送器最大传输速率取决于min(swnd，cwnd，rwnd)-未经应答的发送区段(或如果这里swnd始终固定于相同的初始协商的窗口大小，那么未经应答的发送区段减小swnd且经应答的区段递增swnd)，且连续的递增/递减/调节RWND方法将在rwnd更新中考虑此情况。

还应注意现在可通过仅调节rwnd(远程服务器的cwnd、Ssthresh值、swnd现在一直可维持在任意的大或极大的值)来对远程服务器TCP传输速率进行调速，基于接收器的软件可经由rwnd窗口更新的值的动态选择来对远程发送器的传输速率进行动态调速，因此可将目的地是远程服务器TCP的所有截获的接收器MSTCP产生的包中的所有rwnd字段值修改为所需的rwnd值以对发送器传输速率进行调速(这将需要包校验和重新计算修改)。

基于接收器的软件/TCP(也可实施为基于发送器的软件/TCP修改)可有利地监视来自时间戳记字段的到达OTT值，而OTT值保持与较小允许的变化量(例如由于发送器OS/堆栈CPU处理时间的较小变化量)内的最新OTTest(min)相同(或与现有已知的实际无拥塞OTT相同)，基于接收器的软件/TCP记下达到的最新最大rwnd＝＝＞这给出目前为止达到的最大rwnd值，其间通过路径的包不会遇到任何缓冲延迟或累积缓冲延迟(最多具有上述相同较小允许变化量)(和/或加上额外的允许累积缓冲延迟的B ms，例如0ms/50ms/100ms等)＝＝＞随后每当包被拥塞丢弃时，基于接收器的软件可有利地/最优地将rwnd更新值(截获包中的经修改rwnd字段值)设定为如上述所界定的此最新最大的所记录的rwnd值＝＝＞即，在拥塞丢弃事件和/或快速重传事件等时，接收器继续维持发送器传输速率的速度，使得速率可维持在由流在无拥塞通过路径条件下达到的历史最高速率，因此维持非常理想的高链路带宽利用率。此外，接收器软件/TCP可连续递增rwnd(无论模仿缓慢起动的指数rwnd增长和/或拥塞避免线性增长)，只要到达的OTT值不超过最新(或实际无拥塞OTT)OTTest(min)便可(即，沿着路径没有缓冲延迟)，且/或如果到达的OTT超过Ottest(min)，则视需要向下递减，进一步当到达的OTT值随后超过最新(或已知的实际无拥塞OTT)OTTest(min)例如规定的10ms/50ms/100ms...等(例如由于其它未修改现有TCP流即使在包开始经缓冲时也递增其速率或由于UDP通信量)时，基于接收器的软件/TCP现在可选择允许再次递增rwnd...

应注意，如果沿着路径的所有TCP流(其也可方便地将其带宽的最小有保证部分指派给TCP流且将某一部分指派给UDP等)是在上面的段落中提到的此类经修改的TCP，此类TCP将一直不会导致需要任何缓冲＝＝＞从而一直维持几乎完全无拥塞/无缓冲路径。为了确保公平共享，从而当预先存在的经修改TCP已经共同达到对所通过的链路的全部带宽的完全利用时允许新建立的经修改TCP增长，可允许新建立的TCP增长其传输速率或rwnd或cwnd，直到不大于OTTest(min)或RTTest(min)中例如100ms额外延迟或其已知的实际值，且在经历例如大于100ms额外延迟时，所有经修改TCP将全部将其传输速率或rwnd或cwnd等减少某个百分比，例如10％/15％/25％...等(这有利于预先存在的建立的流，而且也允许新建立的TCP开始获得其传输速率增长)。应注意这里将没有拥塞丢弃，只要所通过的所有节点具有大于相当于(例如)100ms的缓冲区便可。另一方案将为允许连续的传输速率或rwnd或cwnd...等增长，直到包开始被缓冲为止(由最新OTT或RTT的OTTest(min)或RTTest(min)中的额外延迟指示)，随之其传输速率或rwnd或cwnd将向回递减一个步长(因此，在100％利用率水平周围振荡地向前递增和向回递减)。

还应注意，上述各种方案可类似地容易地实施为基于发送器的TCP。

简单地(例如)允许传输速率或rwnd或cwnd增长直到拥塞丢弃事件为止(随之，经修改的TCP回复到其在总的无拥塞条件下的最大达到的传输速率或rwnd或cwnd大小或其百分比，或在拥塞丢弃发生等时，回复到当前传输速率或rwnd或cwnd大小的百分比)可实现与当前RFC标准TCP流的良好共存。在结合了“暂停”方法的情况下，也可从恰好在检测到拥塞丢弃之前的最新OTT或RTT值和OTTest(min)或RTTest(min)或已知的无拥塞实际OTT或RTT值导出“暂停”间隔：例如如果恰好在拥塞丢弃事件之前的最新OTT为700ms且OTTest(min)为200ms，那么现在可将“所需”暂停间隔设定为例如500ms(700ms-200ms)以恰好完全清除所有节点的缓冲包，或在需要时设定为甚至更长(例如600ms)或更短(例如400ms)。

在若干可能性中，实例性的基于接收器的实施方案(应注意基于发送器的将为类似的但更简单)将仅为使接收器请求窗口缩放选项，例如缩放到256兆字节的最大值(最大可能缩放到1十亿字节，即2^14*64千字节或将通常未缩放的16位窗口大小左移14次，这里最大256兆字节将为窗口缩放因数12，即2^12*64千字节或将通常未缩放的16位窗口大小左移：参见Google搜索术语“window scalesize”，http://rdweb.cns.vt.edu/public/notes/win2k-tcpip.htm，http://support.microsoft.com/default.aspx？scid＝kb；en-us；199947，http://www.netperf.org/netperf/training/netperf-talk/0207.html，http://www.ncsa.uiuc.edu/People/vwelch/net perf/tcp windo ws.html，http://www.monkey.org/openbsd/archive/bugs/0007/msg0002 2.html，http://www.freesoft.Org/CIE/RFC/1072/4.htm，http://www.freesoft.Org/CIE/RFC/1323/5.htm，http://www.networksorcery.com/enp/protocol/tcp/option003.htm，http://www.ehsco.com/reading/19990628ncwl.html，Google群组搜索术语“windowscale size”，http://rdweb.cns.vt.edu/public/notes/win2k-tcpip.htm)给出4千字节接收器窗口大小的最小可能分辨率(4千字节正好对应于实验性RFC初始CWND值)：

1.远程服务器可相应选择缩放的发送器窗口大小，然而其也可能简单地允许接收器缩放但选择不对其自有的发送器窗口大小进行缩放：这是没有很大关系的(即使此协商的窗口大小对于例如56K/500Kbs等的最后一英里和/或第一英里物理带宽来说太大)。

注意：如果发送器具有与接收器类似的窗口缩放因数，那么这可实现对此方法的非常简单的现成使用，而不需要任何新的软件或修改的TCP，例如通过简单地将接收器PC的TCPWindowSize注册值设定为例如1和例如2^4的缩放因数(最小窗口大小分辨率现在为约4千字节)，因此发送器的有效传输窗口将一直限于约4千字节，因为接收器现在将一直将其rwnd设定为最多4千字节(而通过在接收器PC的注册设定或应用程序网络接口缓冲设定中将TCPWindowSize注册值设定为2且缩放因数为14，这给出约16千字节*2即32千字节的分辨率)。

2.接收器接着在需要时修改所有截获的传出包，从而确保其接收器窗口大小字段中的每一者一直不会超过一个合适上限值，针对56K接收器最后一英里拨号连接为例如16千字节，或针对500kbs接收器最后一英里DSL为例如96千字节等。

此种简单而非常精致的布置现在将在整个TCP会话中确保发送器CWND的极快指数增长，例如，总是仅需要最多6个RTT时间而不是需要(例如)约64个RTT时间来达到64K的CWND(应注意发送器的初始SSThresh值被非常大地设定为与缩放接收器窗口大小相同的值)，但在所有时间的发送器最大有效传输速率将限于接收到的经修改接收器窗口大小上限值＝＝＞发送器在所有时间的发送速率总是不大于由接收器窗口大小上限允许的速率，并且由发送器的滑动窗口大小和通过返回ACK的“自定时”特性进一步控制(应注意，返回ACK的速率反映最小瓶颈链路可用带宽，其通常在第一或最后一英里的媒体链路处)。沿着路径的缓冲延迟的开始将减慢发送器的BDP通过量，而受限的拥塞包丢弃将导致接收器请求3 DUP ACK快速重传，其中发送器的现在减半的CWND和SSThresh值将很可能一直继续保持远远大于接收器窗口大小上限值，而持续的拥塞包丢弃将促使发送器使RTO重传超时，其中发送器的CWND现在将以例如4 MSS再次缓慢起动，但再次迅速地指数增长＝＝＞可看到所有此类TCP流的发送器CWND现在可限于但也几乎一直维持在接近其接收器窗口大小上限处....

3.视需要，接收器通过缓慢增加传出包的接收器窗口大小字段来对发送器将包注入网络的速率调速，例如紧接在TCP建立之后，接收器可在例如1秒中每(例如)62.5ms就发送均匀间隔和计时的以4千字节开始、然后8千字节、然后12千字节...然后64千字节的例如16个纯窗口更新包的系列(而不是立即通告64千字节上限窗口大小，这将导致包突发)，因此确保没有来自发送器的突然的较大包突发(应注意，在此窗口大小更新系列期间的返回ACK(如果存在)将增加可能的包注入速率，然而接收器可视需要考虑此情况而减小窗口更新大小值)。接收器可视需要在任意适当时间修改传出包的接收器窗口大小字段值。类似地可考虑所发送的最新传出的返回ACK值等而一直以任何期望方式的递增/递减/调节来实现此类窗口大小更新/修改。这对于紧接在TCP连接建立之后以最快的优化方式获取http网站内容来说可为有用的(即随后对发送器调速从而以接收器最后一英里物理最大可能线路速率进行发送：应注意促使发送器在一个RTT中立即突发所有(例如)64千字节内容可能起反作用...)

4.进一步视需要，这可与“暂停”方法和/或“包间到达”方法和/或先前段落中描述的各种方法等一起实施。例如，在这里无拥塞RTT/OTT为(例如)50ms的情况下，“暂停”方法可在这里规定超时周期，其为两个端之间的无拥塞RTT/OTT(或最新估计的无拥塞RTT/OTT)值加上(例如)200ms的缓冲延迟，和超时时的“暂停间隔”，例如150ms-＞这里的瓶颈链路带宽可总是被恒定地100％利用，因为这里“暂停”方法试图总是将所占用的累积通过路径的缓冲区保持在较小的缓冲区占用范围内，即瓶颈链路可一直被100％利用。

因此，应注意到，这里发送器的CWND机制对于在某个阶段实现拥塞控制目的的要求来说是冗余的(除了例如包间到达方法加上3+DupNum个DUP ACK以在拥塞触发事件时快速递增CWND尺寸从而避免RTO超时事件的其它组成方法等没有被结合的情况，在此情况下因此CWND将继续仅起到在每个初始阶段指数和/或线性增长以达到极大值期间的网络可用带宽探测器的作用，即使连接的最大传输速率一直限于(例如)接收器以缩放移位格式通告的相对极小的rwnd值(例如接收器TCP现仅通告4而不是通告64K的rwnd值)，如果所利用的最大缩放因数为14，就表示rwnd值4左移12个位置(即相同于64K)：应注意，即使两个端现在允许/协商得到极大的最大缩放窗口大小，接收器TCP也将仅能够通告其通常物理当前最新可用最大接收器窗口大小，(例如)如果其物理最大可能接收器窗口缓冲资源为16K，那么由接收器TCP产生的在所有包中的通告的接收窗口大小字段值将一直仅展示最大可能值1(假定的所利用的最大缩放因数为14))，随后甚至在3 DUP ACK快速重传/恢复时CWND和/或SSThresh值减半后，与rwnd相比，减半的CWND和/或Ssthresh值仍保持非常大：在网络保持无拥塞时，发送器可恰当地保持以仅由滑动窗口中的可用区段/字节(取决于返回ACK的自定时特性)和/或rwnd或cwnd大小限定的最大速率进行传输，在3 DUP ACK快速重传请求时，发送器的最大传输速率现在将仅由滑动窗口中的可用区段/字节限制(滑动窗口中的可用区段/字节现在将被适当减少某个比例/数目的仍未被应答的所发送的处理中包，但这里尽管CWND和SSThresh值均被减半，其也没有任何影响，因为减半的CWND和SStresh仍将比RWND或SWND大得多)，因此实际上传输速率现在被适当地按比例减小，在RTO超时时(通常在RFC的1秒的最小下限时间周期之后)，由将CWND重开始为1或若干SMSS所控制的发送器传输速率现在减少到最小值，但实际上可几乎一直保持在RTO超时之前的相同传输速率，因为这里发送器将通常在RTO超时之前发送极大部分或整个有效窗口下可发送的区段/字节，因此许多串行的RTO超时立即传输将由于随后仍未被应答的所发送区段/包的系列所导致而快速连续跟随，且有效滑动窗口内所有经发送未被应答的区段中此类“拥塞丢弃”包的比例/数目的大小(即使全部都拥塞丢弃)在例如1秒RTO超时事件之后将不减小发送器的传输速率，但发送器将在RTO超时之前的例如1秒周期期间停止任何传输＝＝＞将清除所有介入节点中的这/这些特定的每个修改TCP流的缓冲包的例如1秒的等效量(或其它流缓冲包的等效量)且还很可能被清除多数其它未修改现有TCP流缓冲包的例如1秒等效量(或其它流缓冲包的等效量)，因为(例如)1秒等效量远远超过节点的通常缓冲等效容量200ms-500ms，且某些其它TCP流(无论是否经修改)可在大于RFC的1秒最小值的时间较迟超时(如果其RTT通常很大)，从而帮助确保全部清除所有所通过节点的缓冲包(因为所有流将RTO超时，即使某些流可能会稍晚超时)[注意：这同义于1秒的较大“暂停”间隔]。

此方法在最简单时仅要求用户设定其本地PC的TCP注册参数以利用较大窗口缩放因数(例如缩放因数12)，而可将16位通常TCPWindowSize值按需要设定为或大或小的值，例如1字节到64千字节：用户PC缩放因数为12，即最大可能缩放窗口大小值为256兆字节且用户PC TCPWindowSize值仅为1，且远程服务器协商缩放因数为例如12且远程服务器TCPWindowSize为例如64千字节时，在任意时间的远程服务器最大传输速率将不超过每RTT 4千字节(1*2^12)的用户PC缩放窗口大小(假定中间软件(如果存在)不会截取从用户PC传出的包的rwnd字段值和将其修改为大于4千字节)。应注意，通常将远程服务器的Ssthresh值初始化为与在TCP连接建立期间协商的rwnd值相同。为了在发送器处实施此方法，远程服务器仅要求远程服务器的TCP堆栈将其SStresh值固定为任意极大值(例如“无穷大”)并利用用于TCP连接协商的窗口缩放选项(和/或将其CWND值固定为其最大达到的增长通过量，即，CWND可例如从初始RFC值(1SMSS)连续递增，而从不会递减)。

已注意到，利用经修改的TCP可增加通过量并减少较大的文件ftp传送完成时间，例如对于在租用线/DSL上的数据存储站点备份应用等。这是因为以现有的TCP，发送器总是增加其传输速率，即CWND单调增加，直到包由于拥塞而丢弃为止，此时，发送器TCP将其传输速率大幅减小，即将CWND重设为例如1SMSS，且开始向其恰在RTO超时之前(或恰在接收到3个DUP ACK快速重传请求之前，随之发送器传输速率(即CWND)减半)达到的传输速率或达到的CWND大小的极长的缓慢爬升。假定如果TCP流未启用的3 DUP ACK快速重传机制，那么这里流的传输速率或通过量或CWND曲线将展示众所周知的“锯齿”图案，其重复地缓慢线性爬升到最大值接着突然降回到接近“0”，即显而易见地，多达一半的链路物理可用带宽没有被利用而浪费，而经修改的TCP流将展现出具有接近恒定100％的链路物理可用带宽利用率的传输速率或通过量或CWND曲线，即可能直至将未修改TCP流的通过量加倍/将传送完成时间减半。在启用3 DUP ACK快速重传机制时，TCP流的曲线将展示突然下降到先前传输速率水平的一半与接近“0”的混合，因此经修改的TCP流与未修改TCP流相比将展示多33％-100％中的某个百分比的通过量-＞可能直至实现链路的“明显”物理带宽的即时加倍，其中链路可为租用线/洲际海底光缆/卫星/无线链路等。

简言之，以上段落的“较大发送器缩放窗口大小”方法(即使任一端处的连接确实没有对此类大缩放窗口大小的实际需要)可由PC用户直接利用而甚至不需要任何软件或对现有标准TCP的修改：用户可手动设定其PC的TCP系统参数从而实现较大缩放发送器窗口大小(例如，TCPWindowSize和/或maxglobalTCPWindowSize，在Window 2000中将TCPWindowSize设定为大于64千字节将自动启用窗口缩放因数)、TCP1323opt1或3(1是启用窗口缩放因数，但没有时间戳记选项，3是具有时间戳记选项)、1与2^14之间的窗口缩放因数值。接收器TCP应允许发送器TCP协商窗口缩放选项，但接收器TCP自有的接收最大窗口大小优选地应保持相对较小，以便恰好能够完全利用被IP包通过的路径的“瓶颈链路带宽容量”(这里的瓶颈链路通常是发送器的第一英里媒体(例如DSL)或接收器的第一英里(例如租用线))：例如假定两个端之间的无拥塞RTT为(例如)100ms且一直恒定保持在(例如)100ms值，且瓶颈链路带宽容量为2mbs，这里接收器最大窗口大小应保持/设定为相对小的恰好(例如)25.6千字节(这确保在任意时间的发送器TCP的“有效窗口大小”不会超过25.6千字节，因而在任意时间都不会以高于2mbs的速率进行传输，即使发送器TCP的CWND可增长而快速达到/远超过接收器的最大窗口大小(例如)25.6千字节且随后始终维持在由其极大的经缩放最大窗口大小值允许的极大值，这确保导致快速重传的包损失/恶化事件现在在几乎任意时间都不会导致发送器TCP的减半的CWND大小或减半的Sstresh值下降到接收器最大窗口大小(例如)25.6千字节以下。而在导致RTO超时重传(同时发送器CWND大小重设为例如1SMSS)(非常少见)的包损失事件之后，发送器TCP的CWND可在仅5*(例如)100ms RTT(即仅在500ms中)中极快地重新达到和超过接收器的最大窗口大小(例如25.6千字节)。这里传输速率曲线/瞬时吞吐速率曲线(如使用Ethereal的IO曲线通信量显示分析工具http://ethereal.com可见)将展现几乎恒定接近于100％的链路带宽利用率，即，这里曲线将类似于“方波信号形式”，与现有标准TCP相比其顶部平坦平台更接近于100％的链路利用率水平，现有标准TCP几乎总是展现“锯齿”形式，其锯齿谷底处的平台远远偏离100％的链路利用率水平。

然而，在现实的公共因特网中，两个端之间的RTT的数量级可随着时间而变化(例如，从数十毫秒到200ms)，除非载体的IP传输服务级别协议的有保证RTT/带宽保证了端到端连接的RTT，因此其经由(例如)接收器最大窗口大小等将发送器的传输速率“调节”为瓶颈链路带宽容量，当公共因特网上的此类RTT加长时，在此类时间期间将经历通过量和/或“处理量(goodput)”的数量级降低：这里最好将接收器的最大窗口大小设定为大得多的值以能够适应此类加长的公共因特网RTT情形，例如，如果现在将发送器最大窗口大小设定为(例如)8*较早的(例如)25.6千字节，那么端到端通过量和/或“处理量”可在任何时间维持接近于100％的瓶颈链路带宽容量，假定RTT没有加长到大于两个端之间无拥塞RTT的8倍。

应注意，当发送器TCP的CWND稳定且不增加时(例如，当CWND已达到最大发送器窗口大小值时)，正是ACK自定时特征调节发送器TCP可传输多少(TCP滑动窗口)，即根据到达的返回ACK的速率，且此返回ACK的最大速率又受限于所通过的路径的瓶颈链路带宽容量，即沿着瓶颈链路可有多快地转发来自发送器的数据，且此近似等于以字节每秒计的瓶颈带宽(如果忽略非数据IP包标头所需的例如40个字节的开销)。当发送器TCP的CWND在“缓慢起动”阶段持续以指数递增时，CWND实际上根据在每一连续RTT期间的返回ACK的数目而递增(在每一连续RTT期间不一定按指数加倍)，即，如果TCP的当前CWND为8千字节且发出8千字节(假定由最大发送器和窗口大小、具有足够返回ACK的充分“有效窗口”所允许)的数据区段，其中在下一RTT中仅6千字节返回且2千字节丢弃，那么假定在“缓慢起动”中，CWND现将仅仅递增到14千字节(不是加倍到16千字节)。只要现在递增的CWND大小(因此现在增加的有效窗口，并非由接收到的返回ACK的数目增加而导致)保持低于将导致传输速率超过可由瓶颈链路的带宽容量转发的速率的大小，那么将不会出现拥塞。但如果传输速率现在大于瓶颈链路带宽容量允许的传输速率，那么某些传输的包现在将开始在瓶颈链路处缓冲(因特网节点通常具有等效于约200-400ms的缓冲容量)。在发送器传输速率准确匹配于瓶颈链路带宽容量允许的传输速率的阶段，一旦CWND现在下一RTT处大小“加倍”且假定这里RTT保持在100ms左右，那么在此下一RTT中，等效于此额外超带宽容量的100ms的包需要在瓶颈节点处被缓冲。假定在连续RTT上的返回ACK的速率现在保持在最大瓶颈链路带宽容量或其周围(即，瓶颈链路继续以100％的链路带宽利用率转发数据)，那么发送器的CWND将在每一随后连续RTT中连续递增等于瓶颈链路带宽容量的量，每一连续RTT由于由递增的CWND(或递增的有效窗口)引入的连续的等效于(例如)100ms的量的额外经缓冲包通信量而比直接在前的RTT略微拖后，直到例如第4个连续RTT为止，此时瓶颈节点用完了缓冲区，因此导致包丢弃。发送器接着将可能在从接收器TCP接收到3个DUP ACK时快速重传丢弃的包，在此情况下甚至现在减半的CWND和SSThresh值仍将几乎不变地保持比相对小的接收器最大窗口大小值大得多-＞因而发送器TCP随后将继续以没有被这些包丢弃事件减少的相同先前速率进行传输，且在ACK以等于瓶颈链路带宽容量的速率返回的同时，发送器的传输速率现在将继续处于等于瓶颈链路带宽容量的准确最大速率(假定这等于或小于接收器的最大窗口大小)。应注意，如果尚未被接收器的3个DUP ACK快速重传请求解决，那么发送器也可仅在最小1秒的现有RFC默认最小时间周期之后RTO超时重传丢弃的包，但这些将非常少见：在此情况下，发送器的CWND仍将在仅几个RTT中非常快地指数增加，以重新达到/超过相对小的接收器最大窗口大小值(由“任意的”大Ssthresh值协助)。尽管周期性快速重传使CWND和Sstresh值减半，但发送器的CWND这里仍将“以指数方式”增长到非常大的值(趋向于“维持的”任意的大Ssthresh值)。应注意，一旦发送器TCP的CWND达到/超过接收器最大窗口大小，其随后将主要为其接收到的返回ACK自定时速率的份额，在任意时间其总速率至多等于瓶颈链路带宽容量，其因此规定了发送器TCP传输速率。在产生回复ACK时另一端的TCP响应变化量可将返回ACK的速率减少到低于瓶颈链路带宽容量的速率，在沿着所通过的路径的介入节点处的缓冲延迟(延长RTT)等可将对通过瓶颈链路的所有TCP流的总返回ACK速率减少到低于/小于瓶颈链路带宽容量的100％(因此将接收器最大窗口大小设定为比所需的最小大小大得多，以完全利用100％的瓶颈链路带宽容量，假定全部TCP会话中足以补偿此类变化量的相同无拥塞RTT将允许尽管有此类变化量而仍实现100％的瓶颈链路带宽利用率)。

这里可见，在发送器的最大窗口大小和CWND值可在任何时间为任意大(由“任意”大Ssthresh值来帮助维持此情况)，且在接收器最大窗口大小值相对小的情况下，利用上文“不需要的”但有意的“大缩放发送器窗口大小和相对小的接收器最大窗口方法”的端到端TCP连接在此处将趋向于等于瓶颈链路的带宽容量的稳定传输速率，即在这里传输速率或通过量曲线将展现接近100％的链路利用率水平的“矩形波形”。

常规的例如FTP的文件传输技术响应于任何包损失而显著减小数据速率，且不能维持长期的高速链路容量下的通过量。举例来说，假定包损失百分比为0.1％且等待时间为10ms，那么在城域网中的OC-3链路(155Mbps)上的单一FTP文件传送会稳定在22Mbps。

我们在这里可添加简单代码，从而仅检查在发送器TCP处从接收器TCP接收到的最新到达的ACK的ACK包间返回间隔大于(例如)300ms(也可由物理错误导致，不一定为拥塞丢弃：我们这里取了两者)以便发送器的本地截获软件向本地MSTCP产生3+DupNum个DUP ACK(其中ACK号＝来自接收器TCP的最新接收的ACK号，和/或SeqNo＝来自接收器TCP的最新接收的序列号字段)以预防超时传输速率减少。众所周知，传输的包中即使0.1％的物理错误破坏(非拥塞)也将严重限制通过量(在80％程度上)，参见http://www.asperasoft.com/technology-faspvftp.html#continental。

概述：

1.仅需要合并传入/传出包截获核心与每TCP流TCB

2.记录从本地MSTCP发送到远程终端的最新‘最大’SeqNo字段“lastsentSeqNo”

3.记录从远程终端接收的最新‘最大’传入包的ACKNo字段“lastrcvACKNo”(以及包的SeqNo“lastrcvSeqNo”)，以及接收时间“lastpktrcvtime”，和此完整包的副本“lastrcvpkt”

4.如果当前时间-lastpktrcvtime＞例如300ms且

lastsentSeqNo+1＞lastrcvACKNo

则发送3个“lastrcvpkt”(较容易，无需计算所产生的包的校验和：复制的SeqNo/复制的数据...等(如果存在于lastrcvpkt中)在导致3个DUP ACK快速重传时将仅被本地MSTCP忽略)

5.在软件初始化时，编辑TCP注册表(和/或视情况每个个别应用的自身网络接口缓冲区大小)，确保所有新的TCP请求大窗口缩放因数14和TCP窗口大小64K(即，最大1十亿字节)，优选地启用SACK，优选地无延迟ACK。

[参考：Google搜索术语‘set socket buffer override large scale windows size’(或类似的相关术语)，

www.psc.edu/networking/perf tune.html，

publib.boulder.ibm.com/infocenter/pseries/topic/com.ibm.aix.doc/aixbman/prftungd/2365a83.htm，

www.dslnuts.com/2kxp.shtml，

http://www.ces.net/doc/2003/research/qos.html，

forum.java.sun.com/thread.jspa？threadID＝596030&messageID＝

3165552，netlab.caltech.edu/FAST/

meetings/2002july/relatedWork.ppt，

www.ncne.org/research/tcp/debugging/firstpackets.html)

全部内容就是这些，这将很好地满足数据存储应用

注意：在两端都协商得到大窗口缩放因数与大窗口大小的情况下，每流TCP将非常快地将CWND值增大为例如1,024*1,500字节的MSS，即10RTT(例如，2.5秒)内1.5兆字节。在有不论是软件产生的(例如，预防RTO超时)还是来自远程终端的任何快速重传请求时，将CWND减半且将SSThresh设定为CWND/2将不会产生任何减小“有效窗口”的效果，SYNC/SYNC ACK/ACK之后的任何时间的“有效窗口”将始终为以下情况中的任一者

1.总是限于接收器的通告的接收窗口大小：接收器通常具有(例如)16千字节，且因此在所有后续包中，接收器将通告为‘1’的接收窗口大小(缩放移位14个位置＝16千字节)＝＞任何时间的本地发送器的传输速率将始终被设定为适合此接收器的通告的窗口大小16K且非常有效地由ACK固有的自定时特性进行“速率协调”(如我们过去几天已清楚了解的)。注意：CWND和发送器窗口大小可能任意大，且在拥塞控制方面不起任何进一步的作用(一旦CWND达到比接收器的最大窗口大小大得多的大小！！！，之后，其ACK自定时特征调节最大可能发送速率以适合可用瓶颈链路的带宽，但当然，接收器可继续动态地调节通告的接收器窗口大小以对发送器的传输速率进一步施加控制，或常驻于发送器端的截获软件可视情况动态地修改传入包的接收器窗口大小以对发送MSTCP的传输速率/“有效窗口”施加类似控制)，或

2.我们已将待协商的发送器的最大窗口大小故意过分设定为任意较大缩放窗口大小值(或仅仅较大的未缩放64K、经缩放256K...等值)，同时在协商期间将接收器的最大窗口大小仅稍许过分设定为(例如)比实际要求/需要的大4倍(例如设定为64K、256K...等，而不是通常要求/需要的最大默认值16K的大小)，使得尽管频繁地进行快速重传减半，但发送器的CWND和SSthresh(其通常设定为与协商的接收器最大窗口大小值相同)几乎总是维持大得多的值(比接收器的相对较小的受实际系统资源限制的通告的接收器窗口大小大得多的值)，从而确保非常有效的接近100％瓶颈链路利用率的方波波形：仅至多以瓶颈线路速率自定时返回的返回ACK的最大可能速率确保实现这一点，因为CWND和发送器窗口大小现均几乎总是始终比确保发送器TCP可以足够快的速率进行传输所需的特定发送器窗口大小值大许多数量级以100％利用所通过的瓶颈链路的带宽容量(这与众所周知的带宽延迟乘积有关，即众所周知的RTT*窗口大小等式)，另外在CWND已快速达到大于接收器的协商的窗口大小值的大小(例如上述64K、256K等)之后，此时发送器TCP随后将不再经由连续RTT期间的窗口大小增长来递增实际“有效窗口”使其超出接收器的协商的最大窗口大小(例如上述64K、256K等)，且因此随后仅将在接收到返回ACK流时才定时输出/发出更多包(此时返回ACK的最大速率始终限于瓶颈链路的带宽容量内)。

注意：在以上情况1和2下，截获软件(或TCP源代码)可始终将从远程接收器传入的包中的接收器窗口大小字段修改为任何所需的较小的最大值(不管是例如从最新记录的最小返回ACK间间隔和非拥塞RTT/OTT值或估计值...等中动态地导出，还是用户可依据对所通过的瓶颈链路的带宽容量的先前了解而指定特定值)，因此确保发送器TCP的有效窗口大小决不超过与所通过瓶颈链路的带宽容量匹配所需的大小等级→现无需借助于接收器的系统资源限制来限制接收器通告的动态窗口大小字段值，且发送器和接收器两者的最大窗口大小值可一起被协商为相同的任意非常大的缩放窗口大小值。

注意：我们可能希望/需要进一步确保从ftp的TCP数据传递信道建立时开始，发送器的CWND就明确地增大到足够大或非常大的值，否则在此初始阶段的包丢弃可能导致将发送器的SSThresh设定为当前初始的非常小的CWND值的一半；这可(例如)由截获软件通过存储若干(例如，10个)最初发送的包并执行未被接收的所述例如10个包中的任一者向远程接收器的实际重传来实现(即，在此时间期间检查传入的返回ACKNo以检测在远程接收器TCP处未接收到的丢失的包，并丢弃/修改这些到达的包或不将这些到达的包转发回到本地MSTCP，以防止此时本地MSTCP将Sstresh值重设为当前初始的非常小的CWND值的一半。)

注意：在发送器的TCP源代码可供直接修改的情况下，将非常简单：例如，此时仅需要修改源代码，使得Ssthresh值现‘永久地’固定为任意非常大的值，和/或发送TCP的最大发送器窗口大小现‘永久地’固定为任意非常大的值等(可能存在许多方式来实现所述目的...)。并且，所有方法/技术均可相应地经修改以作为基于接收器的控制(而不是基于发送器的控制)而运作。

注意：应进一步能够在不需要任何软件的情况下以非常基本的方式立即手动利用上述‘方波波形’技术：

1.相应地手动针对大窗口缩放、大窗口、SACK、无延迟ACK设定两个PC的注册表

2.这2个PC之间的大FTP

3.此处FTP的传输速率/通过量曲线应展示“恒定接近100％瓶颈链路利用率等级的方波波形”。

我们可能进一步希望增加最小包间延迟，以观察到的最新最小‘记录的’返回ACK间间隔发出常规数据包(以例如每秒字节为单位，其应对应于瓶颈链路的容量，可进一步例如仅从直接在前的规定时间间隔中导出/更新此值，例如每(例如)300ms进行导出/更新)，如果需要那么对数据包进行缓冲＝＝＞路由器处无‘突发缓冲’，其可引起不必要的瞬时拥塞包丢弃，而不是真实的拥塞。

此截获软件可能由于CWND的连续RTT指数递增而引起拥塞丢弃(当指数递增的CWND保持＝＜接收器通告的窗口大小，例如不管ACK自定时如何均允许传输速率加倍，同时先前已利用了100％的瓶颈链路带宽，一些用户可能甚至将实际物理接收缓冲器大小系统资源设定为相当大)。

应结合现有‘暂停’技术，即对于在‘超时’之外的每一返回ACK，‘暂停’最新最小“记录的”返回ACK间间隔(对应于瓶颈链路的容量)，即简单地不将下一即将发生的所截获的包向前转发到远程接收器TCP，如果规定的间隔期满(例如，1.8*最新最小记录的返回ACK间间隔)而在自从上一ACK以来在等于例如同一最新最小记录的返回ACK间间隔的周期，即最小返回ACK间间隔中没有接收到下一新的传入的返回ACK＝＝＞此时发送器TCP在由1.8*最新最小记录的返回ACK间间隔(例如90ms)之外返回的第一次发送的ACK‘暂停’触发之前仅可传输至多2个包(每一数据包经速率协调为发送之间最小的最小返回ACK间间隔(例如，50ms))＝＞软件自身不引起拥塞丢弃+外部因特网上可能的递增部署+TCP友好+即使当其它TCP引起包丢弃时也始终保持达到非拥塞等级传输速率(非跷跷板式)。可能进一步需要/希望实施缓冲器来存储等待转发到远程接收器TCP的截获的包和/或关于这些经缓冲的包的各种信息(例如，接收到缓冲器中的时间...等)并接着向本地MSTCP产生3个DUP ACK快速重传请求(以预防本地MSTCP处的RTO超时)，如果(例如)缓冲器队列中特定经缓冲包的等待时间接近例如1秒的标准RFC默认最小RTO时间周期，那么用任何最新的新‘快速重传’的包代替队列中的此特定经缓冲的包。

注意：替代TCP拥塞控制机制，在不必需要现有标准RFC滑动窗口/AIMD机制...等中的任一者，和/或作为截获软件(和/或直接TCP源代码修改)与现有标准RFC滑动窗口/AIMD机制...等并行工作的情况下，将是把直接在前的段落的‘到达ACK间间隔’传输速率协调技术‘与’传输速率暂停‘技术结合(以在自从前一ACK到达以来下一返回ACK在规定时间周期外到达时暂停/跳过转发到远程接收器的包)，并递增/递减MSTCP包产生速率(以使得可以较快递增/缓慢递减速率转发)，从而根据例如最新连续包之间的返回ACK间间隔的最新值和/或特定包的实际RTT值或OTT值(其应展示沿着所通过路径的拥塞缓冲的开始，或其完全不存在，极佳)进行调节，或者将现有标准RFC TCP的非常特有的现有AIMD机制(和/或连同缓冲等待转发到远程接收器的包，和/或向本地MSTCP产生3个DUP ACK快速重传请求以预防陈旧的排队数据包的RTO超时，和/或最新的新重传数据包代替缓冲区中排队的旧版本数据包，和/或事件列表接收时间/发送时间信息和/或每包RTT/OTT监视...等并行使用来实现返回ACK间间隔‘传输/暂停速率协调’技术)。在周期性规定时间周期中，上述方案可确保两个或较小数目的包可供一个接一个非常快地连续以第一英里链路的带宽所容许的可能速率向前转发到远程接收器，以确保所通过路径的瓶颈链路带宽容量的最新最佳估计值由后续到达的最新记录的最小返回ACK间间隔值持续更新(例如，在被一起向前转发前，等待直到两个或较小数目的数据包可用...等，注意，可在每秒字节而不是每秒某大小的数据包的更精细等级上进一步导出实际瓶颈链路的带宽容量，且传输速率协调和/或传输速率暂停技术可适于在知道待继续传输的即将发出的包大小的实际大小的情况下利用此导出的共同的更精细的每秒字节粒度)。此处的方案可利用自身设计出的算法来递增/递减协调的传输速率，这与现有的RFC的滑动窗口拥塞避免机制不同。此处的传输速率应展示出相同的恒定接近100％的瓶颈链路利用率等级的方波波形，且传输速率将总是在接近100％瓶颈链路利用率等级附近的非常小范围内摆动。

注意：此处本地截获软件可产生窗口大小更新包或修改从远程接收器TCP传入到本地MSTCP的包中的接收器窗口大小字段值(例如，‘0’或视需要非常小的值)，以例如当截获软件的转发缓冲包队列中的包的数目超过某一数目或总大小时，暂时‘阻止’(或减小本地MSTCP的包发送速率)本地MSTCP产生/发出新的包。这防止建立过大的包队列，所述过大的包队列可能引起本地MSTCP中的最终RTO超时。

大FTP转移改进

量化：简化：

为了实现最小50％通过量改进(例如，1MBS到1.5MBS，将存在来自其它因素的进一步的相当大的改进)，就在发送器传输速率达到最大线路速率时，发生恒定周期性包损失(和快速重传)：

(1)假定恒定周期性1/1000包损失率和200ms的RTT，最大窗口大小需要为200个包(300千字节)以传输全部内容并将速率调节为一秒1000个包：

SSthresh值由于连续快速重传减半的缘故而通常在1/2*最大窗口大小(100个包或300千字节)附近取值，CWND需要递增100个包(150千字节)以重新达到最大带宽传输速率＝＞需要100RTT(20秒)

最小链路的带宽需要为600kb/s以在20秒内传输1000个包(1,000*1,500*8/20)

(2)假定恒定周期性1/100包损失率和200ms的RTT，最大窗口大小需要为20个包(30千字节)以传输全部内容并将速率调节为一秒1000个包：

SSthresh值由于连续快速重传减半的缘故而通常在1/2*最大窗口大小(10个包或15千字节)附近取值，CWND需要递增10个包(15千字节)以重新达到最大带宽传输速率＝＞需要10RTT(2秒)

最小链路的带宽需要为600kb/s以在2秒内传输100个包(100*1,500*8/2)此‘方波波形’TCP将是TCP友好的，倘若通过瓶颈链路的TCP流全部由此类‘方波波形’流组成或由此类‘方波波形’流与现有标准RFC TCP流的混合物组成，那么对所有此类流/所有此类流混合物的返回ACK的总速率/总数目将仍限于不超过对应于所通过路径的瓶颈链路带宽容量的速率/数目→此‘方波波形’TCP流可以递增方式部署在外部因特网上，维持/保持其所达到的传输速率，而不管由其它现有标准RFC的TCP流引起的包丢弃和/或流混合物的‘锯齿状’效应和/或公共因特网拥塞包丢弃和/或BER包破坏(位错误率)，同时能够维持TCP对于所有此类‘方波波形’TCP流和/或其它现有标准RFC的TCP流均是友好的(注意：在任何情况下，新的TCP流可几乎始终利用网络节点缓冲器的容量来开始其传输速率增长)

在经修改TCP的情况下，如果链路的通信量开始被缓冲，其相应的回应RTT现将超过某一规定的乘数*特定源-目的地的非拥塞RTT值(针对特定包大小，通常由系统MTU大小或MSS大小决定)，且软件现可使每TCP流的传输在规定的‘暂停’间隔中暂停＝＞这确保在此‘暂停’间隔期间所有所通过的节点的缓冲器被立即清除掉此每TCP流的经缓冲包中的任一者(或等效物)＝＞因此将永远不会发生拥塞包丢弃！然而，始终存在物理传输错误的可能性，促使RTO超时和CWND重设为1MSS(这将极少发生且不会在很大程度上影响通过量性能的改进)，但我们也可将我们的‘基于接收器’的包到达间技术和3 DUP ACK快速重传方法以及之前段落的‘大缩放窗口大小’方法结合，来预防发送器RTO超时事件/预防发送器的传输速率减半或重设为‘0’。

因此，此处，每TCP流将不会RTO超时而降低其传输速率(CWND重设为1MSS)从而引起总是浪费一半的物理可用带宽的‘锯齿状’传输速率/通过量曲线，为了避免拥塞包丢弃所需的传输速率的等效减小现仅由‘暂停’间隔影响＝＞传输速率/通过量曲线现应展示物理带宽几乎总是接近100％利用率。

不利用经修改的TCP来预防上述‘锯齿状’现象的替代方法是设定发送器TCP的最大发送窗口大小(即，TCPWindowSize系统参数值)(和/或各种其它相关参数值)，使得发送器TCP的最大可能带宽延迟乘积(最大窗口大小/RTT)值决不会超过链路的物理带宽，因此不可能发生拥塞包丢弃，假定此TCP流是当时利用所述链路的唯一的流。当选择适当的最大TCPWindowSize值时，对于具有最大允许大小(由MTU值或MSS值决定)的包来说，沿着所通过的路径完全离开到达最低带宽链路上所花费的有限时间周期将需要被添加到特定源-目的地的(具有非常小的可忽略的包大小的)非拥塞ping RTT值，这提供了用于带宽延迟乘积等式中的最小RTT值(在实际生活中，考虑到由例如CPU ACK产生过程...等各种要素引起的变化量，实际RTT值将更大)：另外，如果返回ACK可能以捎带应答(piggy-backed)方式携带于常规数据包上(例如，如果接收器也在对称地发送数据)，那么返回的最大大小数据包沿着所通过的回程路径完全离开到达最低带宽链路上所需的有限时间将再次需要添加到上述值中，以提供用于带宽延迟乘积等式中的最小RTT值。此时选择性应答选项将增强性能，且延迟应答选项即使启用也不会产生任何实际影响，假定数据包流是连续的且假定对于具有最大允许大小的数据包来说，沿着所通过的路径/返回路径离开到达最低带宽链路上所花费的有限时间可忽略(即，最低带宽链路仍具有较大带宽容量，例如1,500字节数据包离开到达240kbs的下一前向链路上花费50ms，而1,500字节数据包离开到达56kbs的下一前向链路上花费大约250ms：在源-目的地之间具有非常小字节大小的ping包RTT(例如，50ms)的情况下，此类离开时间支配了构成用于最大窗口大小TCPWindowSize计算中的最小RTT值的计算的值)。

外部因特网上可以递增方式立即部署的TCP修改

当前，标准RFC TCP数据转移通过量在具有高拥塞丢弃率和/或高BER率(物理传输位错误率)的路径/网络上运行不良，在具有高RTT值和非常大的带宽路径的长距离粗管网络(fat pipes network，LFN)中尤其如此。恒定地波动的标准RFC TCP的固有AIMD(加法增加乘法减少)锯齿传输波形在物理链路/瓶颈链路的带宽容量的0％-大大高于100％之间浪涌，本身也可引起包丢弃。

当前，在如经由3 DUP ACK快速重传请求或RTO重传超时而通告的包损失事件发生时，TCP减半其拥塞窗口CWND大小，因此减半其传输速率。当前，TCP同样不能鉴别包丢弃事件的非拥塞相关原因(例如，BER影响)，且将所有包损失事件视为由路径/网络的拥塞引起。

仅具有1％总损失率的路径将减半可实现的TCP流的通过量是一个常见的经充分证明的现象。在亚洲典型的损失率为5％-40％，北美洲为2％-10％，如从http://internettrafficreport.com可了解。

这里概述对现有标准RFC的TCP SACK的改进修改，其可完全消除高损失率路径/网络上的所有上述不足，其可在外部因特网上以递增方式立即部署且基于以下普遍原理(或者步骤或子组成步骤/过程或其子组成过程的各种组合)也可以是TCP流友好的：

(1)在发生如3 DUP ACK通告的包丢弃事件时，此处经修改的TCP将仅需要将其拥塞窗口CWND大小减小对应于通告为损失/丢弃的总区段/包的字节数(传入的DUP ACK包中的ACK号字段(其触发快速重传和/或增加/扩大减半的CWND大小的后续多个DUP ACK)指示最初损失的包的序列号，而选择性应答字段将指示成功地无序接收的具有邻近序列号的块：即，ACKNo和最小SeqNoSACK的块之间的缺失间隙序列，以及SACK的块本身之间的缺失间隙SeqNo提供缺失的丢弃间隙包的序列号，且因此提供经指示被丢弃的字节总数)。而DUPACK内的最大SACKNo指示成功接收的最大SeqNo，且这视需要可用于相应地递增经修改的TCP的CWND大小(就像经修改的TCP的接收到的最大ACKNo现设定为触发快速重传的第三DUP ACK和/或后续多个DUP ACK内接收到的最大SACKNo，但仅出于增加CWND的大小/‘有效窗口’大小的目的/效果，且当然完全不是出于推进经修改的TCP的滑动窗口的左边缘的目的/效果：即，TCP的ACKNo字段的端到端语义将被完全保留为如现有标准TCP中另外规定的那样)，因此允许由经修改的TCP将更多区段/包作为被SACK而不是被ACK的而发送/注入到网络中，其方式相同于传入的ACKNo字段对现有标准TCP的有效窗口大小递增所产生的效果，但完全不同于推进滑动窗口的左边缘的效果(其将导致‘缺失间隙SeqNo’不再保持于可能再次被快速重传/RTO超时重传的当前窗口下可发送的数据的范围内：此时应注意，接收到的ACKNo的后续递增如果小于用于递增CWND/有效窗口大小的上述最大SACKNo，那么将不会再次产生增加经修改的TCP的CWND/有效窗口大小的效果，而是将产生推进经修改的TCP的滑动窗口的左边缘的效果)。

和/或

(2)在发生如第3 DUP ACK通告的包丢弃事件时，此处经修改的TCP流将仅需要确保其在网络中未完成传输的运行中字节(in-flight-byte)的总数(即，发送的所有包的总字节，包含在具有与当前第3 DUP ACK的ACKNo相同的SeqNo的携带数据的包被发送的时间与具有相同SeqNo的此当前第3 DUP ACK的到达时间之间传输到网络中的不管是携带数据的包还是不携带数据的控制包的封装/标头)现将被调节/减少为与此处计算出的数目相同的数目：在触发快速重传的此特定第3 DUP ACK的RTT期间传输到网络中的所传输的运行中字节的总数，即在具有与触发快速重传的第3返回DUP ACK的ACKNo相同的SeqNo的包的传输时间与此特定第3 DUP ACK的接收时间之间传输到网络中的字节的总数，除以被此特定第3 DUP ACK的RTT除的minRTT。

MinRTT是TCP流的端点之间实际总的拥塞的RTT的最新估计值，因此如果通过拥塞丢弃节点的所有流均是这种一致运作的经修改的TCP流，那么此处此特定节点随后应不会拥塞或接近拥塞：此处minRTT仅是到目前为止观察到的经修改的TCP流的所记录的最小RTT值，其将充当所述流的实际物理非拥塞RTT的最新最佳估计值(显然，如果所述流的实际物理非拥塞RTT是已知的或已预先提供，那么其应该或可以作为替代而被使用)。

在触发快速重传的此特定第3 DUP ACK的RTT期间传输到网络中的所传输的运行中字节的总数，即在具有与触发快速重传的第3返回DUP ACK相同的SeqNo的包的传输时间与此特定第3 DUP ACK的接收时间之间传输的所传输的运行中字节的总数，可通过维持由所发送的包的SeqNo和发送时间、此包的字节总数(包含封装/标头)的三个字段组成的按时间定序的事件条目列表(即，完全基于其被传输到网络中的次序)而导出。因此，具有特定应答号的第3 DUP ACK包的RTT值可被推导为此当前第3 DUP ACK的当前到达时间-具有与当前第3返回DUP ACK相同的SeqNo的携带数据的包的发送时间。且所传输的运行中字节的总数可被推导为具有与返回的第3 DUP ACK相同的SeqNo的事件列表的条目与事件列表的最后条目之间的所有条目的所有字节总数字段的总和。

可通过去除SeqNo＜第3 DUP ACK的ACKNo的所有条目而将此事件列表尺寸保持为较小。

代替计算所传输的运行中字节的总数的简化的替代方法将是，将其近似为所传输的最大SeqNo-在具有与当前返回第3 DUP ACK的ACKNo相同的SeqNo的数据包的传输/发送时接收到的最大ACKNo：这提供了运行中数据区段字节的总数，即不包含封装/标头/不携带数据的控制包的运行中纯数据区段。

对现有标准RFC的TCP源代码实施修改以在发生如第3 DUP ACK所通告的包丢弃事件时调节/减少网络中未完成传输的运行中字节的总数的各种可能方式是：

立即经由将拥塞窗口(即，CWND)大小减小为与在触发快速重传的此特定第3 DUP ACK的RTT期间传输到网络中的所传输的运行中字节的总数(即，在具有与触发快速重传的第3返回DUP ACK的ACKNo相同的SeqNo的包的传输时间与此特定第3 DUP ACK的接收时间之间传输到网络中的字节的总数)除以[被此特定第3 DUP ACK的RTT除的minRTT]四舍五入为最接近的字节相同的数目，来递减当前‘有效窗口’大小。这将导致适当数目的后续返回ACK，其由于拥塞而不再具有将新包定时输出到网络中的效果。

在任何新到达的返回ACK将能够将新包定时输出到网络中之前，窗口CWND大小需要递增适当数目的后续返回ACK以重新达到其先前大小：此处在能够定时输出新包之前所需的返回ACK的数目将是或通常对应于应答与CWND已被减少的字节数目相同数目的字节所需的返回ACK的数目。

或者，不利用上述减少过程，此处CWND将仅以以下比率递增：到达的第3DUP ACK的RTT/minRTT^*由此到达的第3 DUP ACK应答的所发送区段字节的数目，四舍五入为最接近的字节或分数进位(而不是通常标准RFC的TCP递增由到达的新ACK应答的所发送区段字节的数目)：这针对所有后续多个相同或递增的ACKNo DUP ACK或新ACK持续，直到实现减少，此时所述减少程序停止。注意，一些较旧的TCP实施方案可对于每一新到达ACK使CWND递增1SMSS，而不是递增由此到达的新ACK应答的所发送区段字节的数目，在此情况下，也可改为对于接收到每隔RTT/minRTT数目个到达ACK时使CWND递增1SMSS仅一次来实现减少程序(不管是DUP ACK还是新的ACK，均只是四舍五入为最接近的整数，例如，如果RTT/minRTT＝2.5，那么可每5个新ACK到达使CWND递增2)。这产生的效果是，使运行中字节减少过程平滑，因此在整个运行中字节减少过程中仍存在新包的适当减少的连续的传输和接收。

由RTO超时重传引起的拥塞丢弃/通告事件可为：

以与第3 Dup ACK或后续完全相同ACKNo的多个DUP ACK相同的方式处理(如上所述)，即促使运行中字节的减少过程去除经缓冲的常驻包而不重设/减小CWND大小。

或

以与现有标准RFC说明中精确相同的方式处理，即将CWND重设为1SMSS且重进入缓慢起动指数递增：但此处注意，由于Ssthresh值决不会已在经修改的TCP中减半，所以此处所述缓慢起动将快速增长而再次达到初始Ssthresh值(其将不会由任何连续快速重传事件减小)

此外，如果新计算不要求较大减少量(即，不要求产生较小的总运行中字节数)，那么后续拥塞丢弃通告事件，例如后续多个具有未改变的相同ACKNo的DUP ACK、具有新递增的ACKNo的第三DUP ACK(或甚至例如在第3 DUP ACK不触发快速重传的情况下通过TCP重传检测到的RTO超时重传)，必须允许现有‘运行中字节减少’过程/程序完成，否则此新过程/程序可视需要进行接管。(或者也可允许此过程/程序基于特定‘标记’的SeqNo返回在每RTT中仅开始一次，接着检查此RTT期间是否已存在任何拥塞丢弃通告事件)。

由于此处经修改的TCP可导出引起拥塞丢弃事件通告的特定返回ACK(或就在RTO超时重传之前的返回ACK)的RTT，所以经修改的软件可进一步鉴别上述相同事件是否实际上是‘假’拥塞丢弃通告，且如果这样就作出不同反应：即，如果与特定拥塞丢弃事件通告关联的RTT与端点的最新估计的非拥塞RTT相同(或如果事先已知/已提供)，或不同的程度甚至不会达到单个节点的以毫秒计的最小缓冲器容量等效量范围内的某一规定的变化量，那么此特定拥塞丢弃通告可恰当地改为被视为起因于物理传输错误/破坏/BER(位错误率)，且经修改的软件可简单地重传所通告的丢弃的区段/包，而无需引起/进入任何运行中字节减少过程。

此处应注意，不同于现有标准RFC的TCP，此处经修改的TCP将不必在由新的第3 DUP ACK/所述新的第3 DUP ACK之后后续的相同ACKNo的多个DUPACK和/或RTO超时重传导致拥塞丢弃通告事件时自动需要减少/减半/重设CWND大小：此处经修改的TCP仅需要不断有必要地在拥塞丢弃通告事件时适当减小CWND大小，以将未完成运行中字节的数目减少为适当导出的值。

注意，任何瓶颈链路将总是以瓶颈的物理线路速率向接收器TCP连续转发所发送的包，而不管瓶颈节点处的缓冲区占用水平和/或拥塞丢弃事件如何→因此，在RTT周期期间应答的/与在所有发送器TCP处接收到的返回ACK关联的所有字节的总和将几乎总是等于瓶颈链路的物理带宽(如果瓶颈带宽被完全利用)。还应注意，TCP的拥塞避免算法应争取将带宽利用率等级尽可能保持为接近瓶颈的链路带宽的100％，而不是现有标准RFC TCP的由于在发生拥塞丢弃通告事件时的CWND大小减半而引起的粗略的未充分利用。可设计出各种不同的运行中字节减少等级/减少量/减少比率演算法，且所述演算法也可基于发生拥塞丢弃通告事件和/或此类历史事件时的例如接收到的最大ACKNo和/或发送的最大SeqNo和/或CWND大小和/或有效窗口大小和/或RTT和/或minRTT...等各种其它参数(例如，允许某一容许水平的缓冲区占用，而不是完全清除所有缓冲区包/经修改的TCP流的‘额外’经缓冲的运行中字节...等)。

和/或

(3)因特网上TCP连接的物理瓶颈链路通常是接收器TCP的最后一英里传输媒介或发送器TCP的第一英里传输媒介：这些通常是56Kbs/128Kbs PSTN拨号连接或典型的256Kbs/512Kbs/1Mbs/2Mbs ADSL链路。在这些情况下，不管发送器TCP的传输速率如何快(现有标准RFC的TCP不可避免地通过在每一后续RTT中注入不断增多的字节来持续探测路径的带宽，从而在缓慢起动期间指数加倍CWND或在拥塞避免期间线性递增CWND)，瓶颈链路仅可以由其带宽限制的最大线路速率转发所有流的通信量→增加发送速率使其超过当前瓶颈链路的线路速率(当前瓶颈链路可依据网络的通信量而时常改变)将不会导致TCP流的任何超过瓶颈链路的物理线路速率的更高通过量。因此，此处的TCP可有利地经修改而不以大于瓶颈链路的最大可能物理线路速率的速率进行发送。这样做将仅仅导致在每一RTT期间发送的‘额外’的超过瓶颈链路的物理线路速率的量的包/字节不可避免地沿着TCP流的两个端点在某处被缓冲或丢弃。

这里是确定路径的瓶颈链路的物理带宽的若干可能程序中的一个实例性过程：

可容易地导出连续RTT值，因为现有标准RFC TCP已基于具有针对每一连续RTT周期的特定SeqNo的‘标记’的TCP包执行连续RTT值的计算/推导。

可通过首先记录或导出在此特定‘标记’的SeqNo包的RTT期间传输到网络中的所传输的运行中字节的总数，即在具有特定‘标记’的SeqNo的包的传输时间与其返回ACK(或经SACK的)时间之间传输的所传输的运行中字节的总数来导出每一连续RTT的通过率，所述总数可通过维持由所发送的包的SeqNo和发送时间、此包的字节总数(包含封装/标头)的三个字段组成的按时间定序的事件条目列表(即，完全基于其被传输到网络中的次序)而导出。因此，具有特定SeqNo的特定‘标记’的包的RTT值可被推导为此当前返回ACK(或经SACK的)的当前到达时间-具有特定‘标记’的SeqNo的携带数据的包的发送时间。且所传输的运行中字节的总数可被推导为具有与返回的第3 DUP ACK相同的SeqNo的事件列表的条目与事件列表的最后条目之间的所有条目的所有字节总数字段的总和。可通过去除SeqNo＜第3 DUP ACK的ACKNo的所有条目而将此事件列表大小保持为较小。代替计算所传输的运行中字节的总数的简化的替代方法将是，将其近似为所传输的最大SeqNo+此最大SeqNo包的数据字节数目-在第3 DUPACK的到达时接收到的最大ACKNo：这提供了运行中数据区段字节的总数，即不包含封装/标头/不携带数据的控制包的运行中纯数据区段。

或者，作为在具有特定‘标记’的SeqNo的包的传输时间与其返回ACK(或经SACK的)时间之间传输的所传输的运行中字节的总数的近似和/或简化，每一连续RTT的通过率计算/推导可基于特定‘标记’的包的SeqNo+特定‘标记’的包的数据有效载荷大小(以字节计)-在发送特定‘标记’的SeqNo包时接收到的最大ACKNo。

因此，此处RTT的通过率可计算为上文导出的在RTT周期/此RTT值(以秒计)期间传输到网络中的所传输的运行中字节的总数。

记录在所有RTT中达到的最大通过率值(下文中称为maxT)并对记录进行持续更新。还记录与达到最大通过率maxT的周期相关联的RTT值(下文中称为RTT_maxT)，以及与此达到最大通过率maxT的周期关联的所传输的运行中字节的总数(下文中称为In_Flights_BYTES_maxT)。

只要任何RTT周期内的通过率＝＜maxT，即此RTT周期内的通过率不变为＞maxT，且如果[此RTT周期期间的运行中字节的总数/In_Flights_BYTES_maxT]＞[此周期期间的RTT值(以毫秒计)/RTT_maxT(以毫秒计)]，那么现导出/获得瓶颈链路的物理带宽容量或线路速率。此处的基本原理是，因为如果此RTT周期内的运行中字节是(例如)与maxT周期关联的运行中字节的两倍，且此周期的RTT值(例如)保持与RTT-maxT相同(或小于两倍)，那么此RTT的通过率不超过maxT的原因是因为maxT已与瓶颈链路的物理带宽容量/线路速率相同，因此尽管此RTT周期期间存在更多运行中字节且此RTT值并未不成比例地增加，但限于瓶颈的线路速率的此RTT内的通过率不会增加为大于maxT。测试公式可进一步包含数学变化量容许值，例如，如果[此RTT周期期间的运行中字节的总数/In_Flights_BYTES_maxT]＞[此周期期间的RTT值(以毫秒计)/RTT_maxT(以毫秒计)]*变化量容许值(例如，1.05/1.10...等)

一旦导出/获得真实的瓶颈链路的物理带宽容量/线路速率(＝maxT)，经修改的TCP就可不再如现有RFC标准TCP的每RTT缓慢起动指数CWND递增/拥塞避免线性CWND递增(其总是不断导致不必要的拥塞包丢弃和/或突发包丢弃)中一样激进地持续探测路径的带宽。此时经修改的TCP随后可将任何后续下一RTT周期内的CWND大小(视需要和/或有效窗口大小)的任何后续递增限制为不大于[与达到maxT(其现等于瓶颈线路速率)时的maxT关联的CWND大小(视需要和/或有效窗口大小)*(上一个，即，最新RTT值(以毫秒计)/RTT-maxT(以毫秒计))的例如5％。如果(非常不可能)任何后续RTT内的通过率变为大于maxT，那么maxT将被更新且再次重复瓶颈线路速率确定过程。因此，经修改的TCP将不会不必要地激进递增CWND大小和/或有效窗口大小，使其超过保持瓶颈链路以此线路速率无空闲地工作所必需的大小，而引起拥塞丢弃和/或突发包丢弃。

或者，经修改的TCP可视需要对其包产生/向网络的包传输进行调速，即一旦maxT达到/变为等于瓶颈的真实线路速率，经修改的TCP仅以maxT瓶颈线路速率产生包/发送包：例如通过设定最小字节间转发间隔＝(1/(maxT/8))，否则视需要设定最小字节间转发间隔＝(1/(maxT/8))*2(因为此时CWND增长将至多是对先前RTT周期的CWND的大小指数加倍)。

此外视需要，经修改的TCP可确保包产生/包发送速率将总是处在相应的maxT速率(不管maxT已达到等于瓶颈的真实线路速率的速率还是仅仅为最新最大maxT)，而不是以返回ACK(或经SACK的)速率所允许的/‘定时’出的包产生/包发送速率发生，其经受如所描述的当发生拥塞丢弃通告事件时的‘额外’运行中字节的清除和/或丢弃的包的适当速率减少过程：即，视需要将使经修改的TCP以未受最新ACK(或经SACK的)的返回速率限制的最新maxT速率产生包/进行传输，除非需要实现适当的速率减少以清除/减少运行中字节和/或减小对应于丢弃的包的数目的速率(例如，当发生拥塞丢弃通告事件(其可为第3 DUP ACK和/或后续多个相同ACKNo的DUP ACK，和/或RTO超时重传)时，将(以等效的位/秒计)包产生/传输速率减小为例如maxT*minRTT/此周期的RTT值，或减小为maxT-此RTT期间丢弃的字节的数目*8)。

不直接改变现有TCP源代码的实施方案：

在不直接修改TCP源代码的情况下，以上段落中描述的本发明可实施为独立的TCP包截获软件/代理程序，其中所述软件保持一个滑动窗口中可传送的所转发的所有发送数据区段的副本，执行所有快速重传和/或RTO超时重传，和/或(根据maxT值)对从/向本地TCP向前转发截获的包进行速率协调，当发生拥塞丢弃通告事件时进行转发速率调节过程。

这里是此实施方案的概述，完全是为了提供所需步骤的概述，所述步骤可被改进/修改。另外任何细化的详细算法/编码步骤仅仅用于说明性概述目的，且可被改进/修改：

截获软件截获来自TCP/去往MSTCP的每个包。

软件根据升序SeqNo，将所有携带数据有效载荷的包的副本维持在经良好排序的列表条目中。

当发生第3 DUP ACK通告时，软件依据列表上具有与第3 DUP ACK和具有相同ACKNo的后续多个DUP ACK相同的SeqNo的数据有效载荷包副本条目执行快速重传。软件跟踪具有相同ACKNo值的DUP ACK的累积数目作为DupNum，进一步如选择性应答字段中的‘间隙’所指示而快速重传所有丢弃的包。软件通过将此包的ACKNo值递减为ACKNo-DupNum^*(例如)1,500来修改每个DUPACK的ACKNo，因此TCP永远不会接收具有相同ACKNo的任何DUP ACK→由于快速重传(其现将由软件来处理)的缘故，TCP决不会减小/减半CWND大小。软件不会减小任何CWND大小值(软件甚至不可存取此参数)。

软件结合了之前描述的一般原理中所概述的原理/过程/程序，或其组合/子成分。

此外；

软件甚至可代替MSTCP完全执行RTO超时重传(通过结合根据历史返回ACK的RTT值的RTO计算)：软件因此可在从TCP接收到用于转发的包时立即‘欺骗性ACK’每个单一包→TCP现甚至不进行RTO超时重传。当从TCP接收到包时，软件可进一步‘延迟’欺骗性ACK，作为控制TCP包产生/TCP包发送速率的技术。

替代修改TCP的CWND大小/有效窗口大小(甚至不可由软件存取)，软件可改为在软件本身内模拟‘镜像CWND机制/镜像有效窗口机制’，或改为以例如减少运行中字节(经由例如进行速率协调以控制/调节如largestRcvACKNo、largestSentSeqNo的其它参数值，确保其减法差值为所要求的大小...等)的其它等效方式产生同等效果(尽管这不是必需的所要求的特征)。

软件也可实施各种标准TCP技术，例如现有标准RFC中所界定的对每个所截获包的校验和验证、SeqNo回绕检测和比较、时间戳记回绕检测和比较...等

这里是关于软件设计的一些简单概述，其仅完全出于说明性目的，且可进行进一步校正/改进/修改和/或被完全不同地设计：

1.纯截获转发：

2.+校验和+回绕：

3.+仅快速重传被同样DUPACK的包副本，对于相同DUP ACKNo仅进行一次：

4.+快速重传所有包副本，对于相同DUP ACKNo仅进行一次：

5.+仅快速重传直至最大经SACK的‘间隙’的所有包副本，对于相同ACKNo的DUP ACK仅进行一次：

6.+@每一DUP ACK，仅快速重传直至最大经SACK的‘间隙’且＞LARGESTRTXSEQNo的所有包副本：(不希望软件不必要地针对每一后续相同ACKNo的DUP ACK和/或新递增的ACKNo的DUP ACK重复地快速重传多次，可记录/更新最大的快速重传的包的SeqNo，LargestRtxSeqNo，以便当接收后续相同ACKNo的DUP ACK时不再不必要地再发送已被快速重传的包。

稍后：

7.+包间转发间隔(由预知的瓶颈线路速率的用户输入确定)：

8.+如(7)中，使用最新估计的瓶颈线路速率而不是用户输入

9.+经由控制/调节包间转发间隔值而操作的TCP友好演算法

初始基本调速模块的简单概述：

将附加第1阶段调速模块规范(此规范仅执行至网络上的包传输的平滑化，仅此而已)：

1.使用户输入(以kbs计)瓶颈链路的带宽，例如SAN.exe B(例如512kbs)：这通常是发送器/用户的第一英里上传带宽，但有时可以是接收器的最后一英里带宽(如果用户不知道接收器的最后一英里的带宽，就输入用户的第一英里带宽：DSL订户的上传带宽通常比下载带宽小得多)

[随后软件可提供最新估计的值B，无需任何用户输入]

2.结合简单的调速模块，其确保最小字节间间隔转发，例如，如果转发大小为S1的包(例如，总长度1000字节，封装+标头+有效载荷)，那么要确保在转发下一大小为S2的包(例如，现为750字节)之前经过了1000字节(B/8)...且以此类推...总包大小S可从TCP标头中确定

3.所有待转发的包，不管是新的MSTCP包/快速重传/RTO重传...等，均首先被附加到仍待转发的包缓冲器；此缓冲器最好需要被较好地排序但无需‘无间隙’，来自MSTCP或软件快速重传的到达包被以升序的SeqNo次序附加/插入(即，因此快速重传/MSTCP RTO重传包在具有更大SeqNo的其它包之前首先被转发)。相同SeqNo的纯ACK/数据包将需要以其相对于彼此的到达次序进行插入。

(注意：此时MSTCP继续进行所有RTO重传)

[更后的规范加强：

可用于将字节字段中的总包长度添加到此仍待转发的列表中的包条目，以便于基于往返行程单一‘标记的包’的SeqNo...和往返行程完成之后后续的下一转发的包的SeqNo...等等，而对每一RTT内总共传输的字节进行计数。此实施调速所需的列表不同于此时在此第1阶段应被较好地排序但无需‘无间隙’的包副本列表。

只要仍待转发的缓冲器＞例如10千字节，那么就向MSTCP发送‘0’窗口更新，并将所有传入的包的窗口大小修改为‘0’并重计算校验和。

‘标记’包的SeqNo(以SYNC/SYNC ACK/ACK之后的第1包开始)/发送时间/将此转发的RTT总字节设定为＝此‘标记’包的长度，并立即开始对下一转发的RTT总字节(不包含此‘标记’包)进行计数。如果返回包的ACKNo＞‘标记’SeqNo，那么记录此RTT值(当前系统时间-发送时间)且记录此转发的RTT总字节。接着，选择下一‘标记’SeqNo作为最新转发的包的SeqNo(如果存在在先前‘标记’SeqNo返回之前转发的数据包(非纯ACK)，否则等待转发的下一数据包)等，且以此类推

(仅需要记录RTT值和此转发的RTT总字节的最新更新实例)。

软件应只有当DUPACK包是纯ACK(即，不携带数据)或携带数据的包设定了SACK标志时才递增DupNum计数(如果远程客户也发送数据，那么即使不存在丢弃我们也可开始获得许多相同SeqNo的包)。且递增另一可变DupNumData(具有相同SeqNo的数据有效载荷包的数目)并将具有相同SeqNo的所有传入的包修改为

- (Dup \overset{&OverBar;}{Num} + DupNumData) :

以与DupNum类似的方式更新DupNumData，且DupNum处理现需要区分纯DUPACK包与具有数据有效载荷的包。

可进一步使此处描述的所有方法和原理的各种组成特征结合到所说明的任一方法中而协作，各种拓扑网络类型和/或各种通信量/曲线分析方法和原理可进一步允许实现链路带宽的经济性。还应注意，在描述主体中不管何处出现的数字均仅旨在表示可能的值的特定实例，例如在RTT*1.5中，数字1.5可由适于所述目的和特定网络的另一设定值(但始终大于1.0)代替(例如0.1秒/0.25秒...等的感知周期)。另外说明的所有特定实例和数字均旨在传达根本思想、概念以及其相互作用，而不限于所采用的实际数字和实例。

上述实施例仅说明本发明的原理。所属领域的技术人员可作出将具体表现本发明的原理并落于本发明的原理内的各种修改和变化。

2005年10月11日编档

可递增部署的外部因特网NextGenTCP的简单实施方案的一些实例

背景材料

触发第三DUP ACK快速重传或触发RTO超时的包的最新RTT可容易从关于上次测量到的往返时间RTT的现存Linux TCB维持的变量获得。

最小所记录min(RTT)仅容易从现存Westwood/快速TCP/Vegas TCB维持的变量获得，但应足够容易编写几行代码以连续更新min(RTT)＝【min(RTT)，上次测量到的往返时间RTT】的最小值。而且在具有基于接收器的TCP修改/基于接收器的TCP速率控制的情况下，可利用OTT和min(OTT)来代替基于发送器的RTT和min(RTT)，其可从发送器的时间戳记选项受益，或基于接收器的TCP可利用包间到达技术，而非取决于确定OTT和min(OTT)的需要。

参考：

http://www.cs.umd.edu/～shankar/417-Notes/5-note-transportCongControl.htm：由Linnux TCB维持的RTT变量。

http://www.scit.wlv.ac.uk/rfc/rfc29xx/RFC2988.html：RTO计算。

Google搜索术语“tcp rtt variables”。

http://www.psc.edu/networking/perf_tune.html：调节Linux TCP RTT参数。

Google搜索：“tcp minimum recorded rtt”或“linux tcp minimum recorded rttvariable”。注意：TCP Westwood测量最小RTT。

Google搜索术语“CWND size tracking”、“CWND size estimation”、“Receiverbased CWND size tracking estimation”、“RTT tracking”、“RTT estimation”、“Receiver based RTT tracking estimation”、“OTT tracking”、“OTT estimation”、“Receiver based OTT tracking estimation”、“total in-flights-packets tracking”、“total in-flights-packets estimation”、“Receiver based total in-flight-packetstracking estimation”等。

初始简单实施方案思想

使用经修改的linux来验证测试：

在其最简单的足够形式下，仅需要修改1行并插入一个循环延迟代码(以“暂停”Linux TCP执行)：

1.在Linux快速重传模块代码中，在3个DUP ACK时不减半CWND，即CWND现在未改变(代替CWND＝CWND/2)。

2.同时，且在同一代码段位置处，简单地插入几行代码以使Linux TCP程序的执行“暂停”(模拟“暂停”)0.3秒。【仅稍后：好得多的是允许第一个DUPACK的包不受阻碍地被重传，且接下来在此同一位置仅设定300ms递减计数全局变量“Pause”，接着Linux TCP在其“最终包传输”代码段处检查此“Pause”变量＝0，以允许任何种类的传输(假定Linux实施“最终传输”队列以保持由此“Pause”暂停的包)

编写几行代码，以丢弃包并在发送包之前引入等待时间延迟，仅允许用户输入恒定周期性丢弃间隔和连续丢弃的数目(例如0.125和1，即每8个产生的包，丢弃1个包一次【等效于12.5％包损失率】，或0.125和3，即每8个产生的包丢弃3个连续的包一次【等效于37.5％包损失率】)，和RTT等待时间(例如200ms)。

代码仅需要基于丢弃间隔和连续丢弃数目而不向前转发，且将所有仍存在的包调度为比它们的接收本地系统时间晚例如200ms转发＝＝＞这些经调度以向前转发的仍存在的包需要被保持在队列中(具有它们自己个别的经调度向前转发本地系统时间)以向前转发到网络上。

可在10mbs LAN和调节到500kbs的无线路由器链路(记住将以太网设定为“半双工”模式)上，并在具有各种模拟损失率和等待时间的情况下，进行快速验证。在其最简单的足够形式下，仅需要修改1行并插入一个循环延迟代码(以“暂停”Linux TCP执行)：

2.同时，且在同一代码段位置处，简单地插入几行代码以使Linux TCP程序的执行“暂停”(模拟“暂停”)0.3秒。

在高损失率、高等待时间的外部因特网/LFN上的大文件传输SAN FTP现应显示接近100％的可用带宽利用率！可插入(例如)Shunra软件以模拟(例如)10％丢弃率和/或300ms等待时间，即模拟长距离高损失率，或简单地编写代码以丢弃包并在发送包之前引入等待时间延迟。还可容易地使用如NS2的模拟来验证此情况。

现在非常清楚，发送器TCP的CWND的目前大小(一旦获得)不会以任何方式导致拥塞丢弃，因为发送器TCP将仅精确地对应于返回ACK速率而注入新包：注意，这是CWND大小的加速瞬时增加(瞬时地将比返回ACK速率更多的包注入到网络中，例如指数递增而成倍于返回ACK速率，是包丢弃的主要原因：一旦CWND已达到无论多大的目前现存大小，其便将不导致比返回ACK速率更多的新包被注入到网络中，这仅可能在CWND的瞬时大小递增时发生)。

修改几行Linux源代码确实简单，在Windows上，仅需要首先使截获软件模块自MSTCP接管所有快速重传功能。为了在Windows中实施，需要截获每一传入/传出包并修改传入的DUP ACK的应答编号字段，所以MSTCP永远不会被通知/知道任何丢失包快速重传请求(我们的截获软件现完成所有的快速重传功能，而不是MSTCP)：此截获软件模块还可进一步自MSTCP接管所有RTO超时重传功能(可(例如)镜像MSTCP自己的RTO超时跟踪演算法，或设计新的经修改的所需演算法)。在截获软件模块现接管所有的现存MSTCP的DUP ACK快速重传和RTO超时重传功能的情况下，截获软件现可经由针对所截获的包，立即欺骗发送/临时停止回到MSTCP的SPOOF ACK，和/或将SPOOF ACK内的接收器窗口大小字段设定为“0”以停止MSTCP包产生，来完成对MSTCP新包产生/传输速率的总体控制。

在(例如)Linux/FreeBSD/Windows源代码中，应能够仅修正/插入几行以使此所示NextGenFTP以非常基础的方式工作：

1.在Linux 3个DUP ACK快速重传模块中，仅需要去除将CWND改变为CWND/2的代码行(即CWND现变为未改变)。所有其它代码行根本不需要被修正：例如SSthresh现保持设定为CWND(即针对每一RTT，TCP现仅加法增加1个区段，而不是指数加倍)。这本身现应显示接近100％链路利用率，即使在具有高丢弃率的LFN/外部因特网上(即此处显示为以非常粗糙的方式工作)。

为了帮助测试，可能需要使用类似Shunra的软件，其可引入％包丢弃且/或模拟路径等待时间，在发送侧处将此软件插入在NextGenFTP与网络之间，或编码类似的简单实用程序。

2.【可选但稍后明确需要】在例如3个DUP ACK的包丢弃事件时，NextGenFTP确实应“暂停”适当的间隔，以清除正被缓冲的所有其自己的“额外”发送的运行中的包(而所有的现存常规TCP/FTP均急剧地减半其CWND，从而导致严重的不必要的良好证明的通过量问题)。在(例如)Linux中，如果预先不知道实际真实未拥塞RTT或未拥塞OTT，仅需要插入一些代码以记录流的最小观察到的RTT的min(RTT)或min(OTT)，且在3个DUP ACK时使对网络的所有包注入“停止”(例如)0.3秒(这是等效的以秒计的最常见路由器缓冲区大小)或某一在演算地导出的周期(…稍后)【注意，还可代替暂停，仅将CWND设定为适当的对应的在演算地确定的值！例如使CWND大小减小{最新RTT值(或适当的情况下OTT)-记录的min(RTT)值(或适当的情况下min(OTT))}/min(RTT)的因数，或使CWND大小减小【{最新RTT值(或适当的情况下OTT)-记录的min(RTT)值(或适当的情况下min(OTT))}/最新RTT值】的因数，即，CWND现设定为CWND*【1-【{最新RTT值(或适当的情况下OTT)-记录的min(RTT)值(或适当的情况下min(OTT))}/最新RTT值】】，或将CWND大小设定为CWND*min(RTT)(或适当的情况下min(OTT))/最新RTT值(或适当的情况下OTT)等，视所设计的所需算法而定】。注意，min(RTT)是所记录的路径的未拥塞RTT的最当前估计值；

3.【可选但稍后明确需要】瓶颈链路的沿着流的路径的可用带宽可容易地被确定(已相当良好的证明，但与我们自己开发的技术相比不是完美的)，因此一旦已知/确定可用带宽的此上限，NextGenTCP其后便应不再导致CWND递增(不管指数加倍还是线性递增)＝＝＞一旦NextGenTCP以此所获得的上限速率传输，其便不再不必要地导致CWND递增而不必要地导致包丢弃！

初始简单实施方案思想(改进1)

为了使用经修改的linux来验证测试：在其最简单的足够形式中，仅需要修改1行并插入一个循环延迟代码(以“暂停”Linux TCP执行)：

1.在Linux快速重传模块代码中，在3个DUP ACK时不减半CWND，即CWND现未改变(代替CWND＝CWND/2)。

2.同时，且在同一代码段位置处，简单地插入几行代码以使Linux TCP程序的执行“暂停”(模拟“暂停”)0.3秒。【稍后：更好的是允许第一个包被重传，且接下来在此同一位置仅设定300ms的递减计数全局变量“Pause”，接着LinuxTCP在其“最终包传输”代码段处检查此“Pause”变量＝0，以允许任何种类的传输(假定Linux实施“最终传输”队列以保持由此“Pause”暂停的包)。

【仅稍后：更好的是允许第一个包被重传，且接下来在此同一位置仅设定300ms的递减计数全局变量“Pause”，接着Linux TCP在其“最终包传输”代码段处检查此“Pause”变量＝0，以允许任何种类的传输(假定Linux实施“最终传输”队列以保持由此“Pause”暂停的包)。

仅更稍后：这可能便利地由以下情况来实现/实施(仅作为建议)：

2.同时，且在同一代码段位置处，在此同一位置(正好在CWND现经修改成未改变，而不是CWND/2处)简单地设定300ms递减计数全局变量“Pause”，接着Linux TCP在其“最终包传输”代码段处检查此“Pause”变量＝0，以允许任何种类的传输，除了包的SeqNo＝＜最大发送的未应答SeqNo的情况(其可容易地从现存TCP参数获得，即只有当包为重传旧SeqNo包时，才允许包被向前转发，而不管“Pause”变量＞0。)

即Linux TCP可总是允许所有快速重传和/或RTO超时重传包被立即不受阻碍地向前转发，而不管CWND或有效窗口大小有什么限制(因为重传包不会以任何方式递增现存的运行中的包！但注意，而具SeqNo＞最大发送未应答SeqNo的向前转发新包可能增加现存的总的运行中的包)。

另一实施方案将简单地为在拥塞丢弃事件时不递减CWND以递减计数“Pause”变量(无论是固定的(例如300ms)间隔还是所导出的，例如最新RTT-min(RTT)间隔等)，且如果“Pause”变量＞0，那么不允许CWND递增＝＞其激进之处在于此实施方案不帮助减小被缓冲的额外运行中的包【且CWND可简单地总是未改变/未递减，而不是设定为“0”或最大.UNA.SeqNo-SEnt.UNA.SeqNo，结合步骤1和步骤2两者】。

还可当“Pause”变量＞0时，将此非递增部分引入到下文的早前实施方案中，因此返回ACK推进滑动窗口的左边缘将仅导致新的包(即SeqNo＞最大.Sent.SeqNo的包)被以对应于返回ACK-定时速率的同一速率注入，且不导致超过返回ACK-定时速率的速率的“加速”CWND递增/额外加速指数或线性新包注入。当递减计数“Pause”全局变量＞0时，Linux TCP应不递增CWND，即使传入ACK现推进滑动窗口左边缘，即Linux TCP可以与返回ACK-定时速率相同的速率将新的包注入到网络中，但不会“指数加倍”或“线性增加”到超过返回ACK-定时速率的速率(通过以下操作来容易地实施：修改所有CWND递增代码行以首先检查递减计数“Pause”是否＞0，如果是，那么不递增)，

而且，替代地，Linux修改可仅简单地要求：

1.在拥塞丢弃事件时，不改变/递减CWND值，且在随之的由拥塞丢弃事件触发的例如300ms的“暂停间隔”(或演算地导出的间隔，如最新RTT-min(RTT)…或max【最新RTT-min(RTT)，例如300ms】等)期间也不递增CWND＝＝＞在拥塞丢弃事件时，经修改的Linux TCP不会将新的“加速”包注入到网络中(即其中SeqNo＞largest.Sent.SeqNo)使得超过“触发的暂停间隔”期间的返回ACK定时速率【即CWND不会由推进滑动窗口的左边缘的返回ACK递增，即使CWND＜发送器/接收器最大窗口大小】。

和/或视情况

2.总是允许重传包(即具SeqNo＝＜larget.Sent.SeqNo的包)不受滑动窗口机制阻碍地向前转发。

对步骤1……做进一步改进，仅设定(例如)300ms“Pause”递减计数，将CWND设定为(Largest.SENT.SeqNo-SENT.UNA.SeqNo)并在递减计数之后恢复CWND…＝＝＞以此方式，Linux快速重传模块可“发出(stroke out)”由传入的相同SeqNo的多个随后DUP ACK的SACK字段指示的缺失间隙包，因为每一随后到达的多个相同SeqNo的DUP ACK均使CWND递增到Largest.SENT.SeqNo-SENT.UNA.SeqNo+1【而如果将CWND设定为“0”，可防止缺失间隙包的重传向前转发】＝＞仅仅步骤1修改本身便应可非常好地工作，而不需要步骤2，但在具有步骤1和步骤2修改的情况下，即使CWND被设定为“0”也没有太大关系；

将CWND设定为Largest.SENT.SeqNo-SENT.UNA.SeqNo与设定为“0”在防止“加速的”新的额外包被注入到网络中方面具有相同效应，但允许重传包(其中SeqNo＝＜Largest.SENT.SeqNo)不受阻碍地向前转发。

现存RFC的TCP源代码修改和简化测试概述：

测试平台应为“与未经修改的Linux TCP服务器相比)：

经修改的Linux TCP服务器【+(例如)2/5/20％模拟包丢弃+(例如)100/250/500ms RTT等待时间】-＞路由器-＞现存Linux TCP客户机。

路由器与客户机之间的链路可为500kbps，路由器可具有10或25包缓冲。发送器和接收器窗口大小为例如32/64/256千字节。

Linux TCP修改规范的建议：

(简单的技术通过设定CWND＝0来在(例如)300ms间隔期间实现“传输暂停”，用于容易的实用Linux修改实施方案)。

1.只要在拥塞丢弃事件(3个DUP ACK，其减半CWND，和使CWND复位为0的RTO超时)时现存Linux TCP乘法减小CWND(CWND＝CWND/2)的情况下，就代替地使CWND保持未改变，且仅设定300ms“Pause”递减计数，将CWND设定为(Largest.SENT.SeqNo-SENT.UNA.SeqNo)，并在递减计数之后恢复CWND，还应将SSThresh设定为原始CWND值，而不是被减半或Largest.SENT.SeqNo-SENT.UNA.SeqNo CWND值＝＞这正好等效于“暂停”0.3秒的容易实施方案。

【此处步骤2可为可选的，但优选地可在仅具有步骤1的测试之后被添加】

2.允许不受阻碍的任何重传包(其中SeqNo＝＜最大现存发送SeqNo)，不管CWND/有效窗口滑动窗口时槽的可用性：

在滑动窗口代码段，其中Linux TCP检查是否允许包被立即向前转发(即取决于是否Largest.SENT.SeqNo-SENT.UNA.SeqNo＜有效窗口大小)，如果包的SEqNo＝＜Largest.SENT.SeqNo(即重传包，其不应被阻碍向前转发)，可非常简单地插入代码以“绕过”此检查＝＞以此方式，Linux TCP重传模块可总是立即“发出”所有由第3 DUP ACK/随后的多个DUP ACK指示的“缺失间隙包”。【记住结合SeqNo绕回保护】。

关于Windows平台截获快速重传模块的有用提示

此模块(自MSTCP接管所有快速重传功能，并修改传入DUP ACK的传入ACKNo，因此MSTCP不会得知任何DUP ACK事件)应重传由传入的相同SeqNoDUP ACK的SACK字段指示的所有“缺失间隙包”，保存在此相同SeqNo的多个DUP ACK期间的所有重传的SeqNo的列表，且不会不必要地重传已在随后相同系列的SeqNo DUP ACK期间重传的SeqNo，除了在此“重传列表”上随后相同SeqNo DUP ACK现指示接收到重传的SeqNo包的情况：在此情况下，模块应仅再次重传“早前重传的缺失间隙包”(即已在重传列表上)，其SeqNo＜由新到达的相同SeqNo Dup ACK指示的所接收到的最大重传的SeqNo。

当然，在随后的新递增SeqNo的第3 DUP ACK上(SeqNo现不同且递增)，此模块可再次重传再度由传入的相同SeqNo的DUP ACK的SACK字段指示的所有“缺失间隙包”。

显然，相对于上述版本/演算法，随后版本中优选地进行以下操作：

1.只要现存Linux TCP在拥塞丢弃事件(3个DUP ACK，其减半CWND，和RTO超时，其使CWND复位到1)时乘法减小CWND(CWND＝CWND/2，或RTO超时时CWND＝1)，就代替地使CWND未改变，且仅设定(触发第3 DUP ACK快速重传或触发RTO超时的包的最新RTT-min(RTT)，300ms)的最小值为“Pause”递减计数，将CWND设定为1并在“Pause”递减计数(其可与“Pause”首次激活时具有完全不同的值)之后使CWND恢复到当前Largest.SENT.SeqNo-SENT.UNA.SeqNo，在递减计数之后还应将SSThresh设定为Largest.SENT.SeqNo-SENT.UNA.SeqNo值(如在“暂停”被触发时)，而不是被减半或设定为“1”CWND值＝＞这正好等效于“暂停”0.3秒的容易实施方案。

注意：以此方式，在“Pause”递减计数之后，经修改的Linux TCP将不会利用在“经触发的暂停”间隔期间累积的返回ACK定时而导致突然的“突发”传输而再次立即使链路拥塞丢弃：而是在“Pause”递减计数之后，接着仅以随后的返回ACK定时速率传输(即不包含在“暂停”间隔期间累积的任何返回ACK定时令牌。)

进一步也许更优选：1。

只要现存Linux TCP在拥塞丢弃事件(3个DUP ACK，其减半CWND，和RTO超时，其使CWND复位到1)时乘法减小CWND(CWND＝CWND/2，或RTO超时时CWND＝1)，就代替地使CWND未改变，且仅设定(触发第3 DUP ACK快速重传或触发RTO超时的包的最新RTT-min(RTT)，300ms)的最小值为“Pause”递减计数，将CWND设定为Largest.SENT.SeqNo-SENT.UNA.SeqNo【注意：设定此CWND值而不是1将允许所有重传包(即其中SeqNo＝＜Largest.SENT.SeqNo)不受滑动窗口时槽可用性阻碍地立即向前转发，但应注意，在“Pause”递减计数之后，当前的Lagest.SENT.SeqNo-SENT.UNA.SeqNo将仍总是与在“Pause”递减计数之前在CWND被代替地设定为“1”的情况下相同】，且在“Pause”递减计数(其可为与“暂停”首次激活时完全不同的值)之后使CWND恢复到当前Largest.SENT.SeqNo-SENT.UNA.SeqNo，在递减计数之后，还应将SSThresh设定为Largest.SENT.SeqNo-SENT.UNA.SeqNo值(如在“暂停”被触发时)，而不是被减半或设定为“1”CWND值＝＞这正好等效于“暂停”0.3秒的容易实施方案。

现存RFC的TCP源代码修改和简化测试概述(改进1)

仅仅此初始最简单步骤1TCP源代码修改就应可初始地证实接近100％的可用链路带宽利用率。

特定设定的测试平台应(与(例如)未经修改的Linux/FreeBSD/Windows TCP服务器相比)为：

经修改的Linux TCP服务器-＞(可使用IPCHAIN实施)模拟的10个包中丢弃1个包，200ms RTT等待时间(更优选)-＞路由器-＞现存Linux TCP客户机。

路由器与客户机之间的链路可为1mbs(更优选)，路由器可具有1mns^*(例如)所选择的0.3暂停值/8＝40千字节(即40个1千字节包)缓冲区大小。发送器和接收器窗口大小为64千字节(更优选)。

初始最简单1步骤Linux TCP修改规范的建议：

(简单技术通过设定CWND＝0来在(例如)300ms间隔期间实现“传输暂停”，用于容易的实用Linux修改实施方案)。

1.只要在拥塞丢弃事件(3个DUP ACK，其减半CWND和RTO超时，其使CWND复位为1)时现存Linux TCP乘法减小CWND(CWND＝CWND/2，或RTO超时时CWND＝1)，就代替地使CWND保持未改变，且仅将300ms设定为“Pause”递减计数，将CWND设定为1，并在递减计数之后，将CWND恢复到原始值，还应将SSThresh设定为原始CWND值，而不是被减半或设定为“1”CWND值＝＞这正好等效于“暂停”0.3秒的容易实施方案。

注意：这将使所有传输/重传的向前转发在第3 DUP ACK和RTO超时后的例如300ms(用以清除缓冲区)中停止，除了触发快速重传机制的第3个DUP ACK和RTO超时时的第1个重传包(这些总是由Linux TCP向前转发，而不管滑动窗口时槽可用性！)。而且一旦300ms递减计数完，由此300ms“暂停”挂起/停止的任何随后的多个快速重传包便将立即向前转发(只有在CWND尚未达到最大发送/接收窗口大小时，因为未递减CWND，所以CWND可能已超过最大发送/接收窗口大小，因此当300ms递减计数完时，由此300ms“暂停”挂起/停止的随后多个快速重传包将可能仅以与返回ACK-定时速率相同的速率被向前转发(然而碰巧包含在300ms暂停周期期间累积的任何返回ACK)＝＝＞此最简单的修改将已是Google/Yahoo/Amazon/Real Player等的“显著”商业成功。

现存RFC的TCP源代码修改和简化测试概述(改进2)：

1.只要在拥塞丢弃事件(3个DUP ACK，其减半CWND和RTO超时，其使CWND复位为1)时现存Linux TCP乘法减小CWND(CWND＝CWND/2，或RTO超时时CWND＝1)，就代替地使CWND保持未改变，且仅设定(触发第3 DUP ACK快速重传或触发RTO超时的包的最新RTT-min(RTT)，300ms)的最小值为“Pause”递减计数，将CWND设定为1，并在递减计数之后，将CWND恢复到原始值，还应将SSThresh设定为原始CWND值，而不是被减半或设定为“1”CWND值＝＞这正好等效于“暂停”0.3秒的容易实施方案。

注意：以此方式，如果包丢弃事件是由物理传输错误/BER触发，而不是由导致丢弃的预期的常见缓冲区完全耗尽(典型缓冲区大小为300ms)触发，那么经修改的Linux TCP根本不会不必要地“暂停”或停止任何向前转发：如果由BER导致包丢弃和链路被拥塞，那么“Pause”递减计数现将被准确地设定为0ms，而不是永远循环300ms的“暂停”。注意早前的模拟包丢弃事件的IPCHAIN方法根本不对应于拥塞或缓冲区完全耗尽事件。

然而，下文的早前修改规范将仍起作用，但测试平台现应改为：

具有多个(例如，5个)大FTP的未经修改的Linux TCP服务器经由1mbs链路和/或拥塞通信量产生器进入路由器1(或可甚至为每(例如)1.5秒产生周期性短300ms UDP拥塞突发)。(1mbs链路)

经修改的Linux TCP服务器-＞(1mbs链路)路由器1(1mbs链路)-＞现存Linux TCP客户机。

路由器与客户机之间的链路可为1mbs(更优选)，路由器可具有1mns^*(例如)所选择的0.3暂停值/8＝40千字节(即40个1千字节包)缓冲区大小。发送器和接收器窗口大小为64千字节(更优选)。注意：以此方式，任何包丢弃事件将总是严格对应于缓冲区完全耗尽场景，且“暂停”300ms现很有意义(或触发包的“暂停”间隔的RTT-min(RTT)，如果＝＜300ms，例如所部署的非常小的缓冲容量)。

最终：具有IPCHAIN的早前测试平台设置将在不递减CWND大小的情况下起作用，从而无需“暂停”＝＞显示100％的链路利用率，但是激进且非TCP友好的。

1.只要在拥塞丢弃事件(3个DUP ACK，其减半CWND和RTO超时，其使CWND复位为1)时现存Linux TCP乘法减小CWND(CWND＝CWND/2，或RTO超时时CWND＝1)，就代替地使CWND保持未改变，还应将SSThresh设定为未改变CWND值，而不是被减半或设定为“1”CWND值＝＞这本身确保接近100％的链路利用率，而不管丢弃速率和RTT等待时间。

基于接收器的可递增部署TCP友好外部因特网TCP

修改

可直接修改接收器TCP源代码(或类似地截获监视器可被调适以执行/工作以实现相同效果)，且甚至将对所有现存RFC的TCP起作用：

概述(还参见各种早前描述的技术t，和子组成技术)【注意：现在清楚，CWND大小(无论多大)在获得后本身不导致拥塞丢弃：CWND大小的加速瞬时增加(例如指数或线性增长)才是拥塞包丢弃(返回ACK-定时速率…)的主要原因。

1接收器TCP在发送3个DUP ACK后立即接着以演算法确定导出的数目/系列的多个相同SEQNo的DUP ACK(还可在演算地控制此类多个相同SeqNo的DUP ACK的发送速率，以控制发送器TCP的CWND大小，因此根据需要控制发送速率)，因此可控制发送器CWND大小(例如)以不在快速重传3个DUP ACK时减半…或在所规定的CWND大小根据接收器对路径拥塞等级(未拥塞/缓冲延迟的开始/超过某些值，拥塞包丢弃等)的检测而定时递增。可与各种早前技术(如大窗口大小，包间到达)结合以早期检测包丢弃，调节接收器窗口大小(例如“0”以完全暂停发送器的有效窗口大小传输速率，因此接收器窗口大小现控制发送器的有效窗口传输速率，而不是CWND)等。接收器还可利用发送器的CWND大小跟踪方法以帮助确定多个DUP ACK产生速率，还包含所产生的某些ACK中的1字节数据，因此发送器将通知接收器：在发送器TCP处确切接收到哪个DUPACK。

或

1.接收器TCP抑制发送某一早前接收到的SeqNo的ACK，因此现可使发送器TCP仅以接收器的产生多个相同Seqno ACK的速率(根据需要在演算地导出)传输(即发送器的CWND大小定时递增)，因此接收器可控制发送器的速率＝＞有效地，发送器TCP现几乎总是处于快速重传模式。在协商得到足够大的接收器和发送器窗口大小的情况下，1个相同SeqNo的多个DUP ACK可导致十亿字节被传送以完成，留在1相同SeqNo的DUP ACK系列中，或SeqNo可能递增到较大(或最大)SeqNo，其在有效窗口大小耗尽而“移位”发送器的窗口边缘之前的任何时间被成功地接收。(可与与各种技术结合以总是使发送器的CWND大小保持足够大)。

和/或

1.接收器TCP不产生3 DUP ACK，仅使发送器RTO超时以重传(优选地协商出足够大的窗口缩放大小以确保发送器的连续传输，而不被在较长RTO超时周期被触发之前挂起的未应答重传停止)，但发送器的CWND在RTO超时时复位为“0”或“1”，接收器需要这一操作以在检测RTO超时重传之后，经由许多接着的相同DUP ACK来确保发送器的CWND的快速指数递增恢复。

注意：

路由器可便利地将缓冲区设定为更小的量值…如50ms(见所公布的关于此类小缓冲设定值的经改进功效的google搜索研究报告)，而且RED机制可经调适以(例如)丢弃具有经缓冲包的任何流的(例如)第1缓冲包＝＝＞帮助实现此类因特网子集上的实时传输/TCP通信量输入速率。而且TCP可仅简单地调节/“暂停”以立即清除任何缓冲的开始/适当地递减CWND大小以允许清除任何缓冲的开始。

上述接收器TCP可优选地利用SACK字段来输送超过“夹住的”相同SeqNo的多个DUP ACK的系列的接收到的SEqNo的区块，还可利用进一步的SACK字段以输送偶尔的随后缺失“间隙”包(RFC允许3个区块被SACK且被SACK的SEqNo不会不必要地由现存RFC的TCP重传)。

此处，接收器TCP可利用“SACK字段的区块”，产生相同SeqNo的DUP ACK系列的“定时”“夹住”的SeqNo(因此控制发送器的滑动窗口的Snd.UNA值以控制有效窗口大小，以及控制所产生的相同SeqNo的多个DUP ACK的数目以控制发送器的CWND大小)，设定接收器窗口大小，跟踪发送器的CWND大小技术等，从而使接收器能够根据接收器对路径的拥塞开始/缓冲区耗尽包丢弃的监视来控制或“暂停”发送器的速率/有效窗口大小/CWND大小(在未拥塞时可与BER包丢弃相区分，如可在OTT时间中区分至此是否超过记录的min(OTT)…)

各种提示

可能有很多不同方式，和所述的子组成方法的各种不同组合来用以以很多各种也许更简单的方式来实施所需修改。例如，如果网络中所有TCP均被类似地修改，那么对于每一TCP发送器来说，仅“暂停”(或基于接收器的TCP导致发送器TCP“暂停”)(例如)最新RTT(或适当情况下的OTT)-记录的min(RTT)(或适当情况下的min(OTT))的间隔将非常容易，以确保在整个网络/因特网子集上的类似PSTN的传输质量。代替上述“暂停”，经修改的TCP每一者可将其CWND大小代替地减小到(例如)CWND*(最新RTT-min(RTT))/最新RTT，或减小到(例如)CWND*(最新RTT-min(RTT))/min(RTT)等，视所设计的所需算法而定…，例如以确保运行中的包的总数目被尽快立即减小，使得可完全清除(或仅使缓冲减小某些等级)可能导致或要求缓冲的任何额外运行中的包(多于链路的可用物理带宽容量可应付，而不导致缓冲的开始)，即确保所有随后的仍未完成的运行中的包现不会需要沿路径的缓冲(或仅使缓冲减小某些等级)。

在网络中的所有接收器TCP均如上文所述那样修改的情况下，只要RTT(或OTT)保持小于当前最新记录的min(RTT)(或当前最新记录的min(OTT))等，接收器TCP便可根据所设计的所需算法(例如在每RTT(或OTT)中多个DUP ACK速率的乘法增加和/或线性增加，经由其对相同SeqNo的多个DUP ACK系列的产生速率/间隔/临时停止等的完全控制，来对发送器TCP传输速率具有完整控制。另外，一旦RTT(或OTT)变得大于当前最新记录min(RTT)(或当前最新记录min(OTT)，即检测到拥塞开始，基于接收器的经修改的TCP(或截获软件/转发代理等)可“暂停”演算地设计的周期，且在此周期期间，基于接收器的经修改的TCP可“冻结”额外的DUP ACK的产生，除了需要用以匹配传入的新SeqNo包的DUP ACK(即针对每一传入的新SeqNo包产生1个DUP ACK)，这将允许减小/清除/防止额外发送器的总的运行中的包沿路径被缓冲。

基于接收器的TCP可包含(例如)将被包含在“所选的经标记的”DUP ACK中的1字节无用数据，以帮助接收器使用随后接收到的发送器的ACKNo和SeqNo等来检测/计算RTT/OTT/总的运行中的包等。

2005年11月21日编档

各种改进和提示

可递增部署的TCP友好的外部因特网100％链路利用率的数据存储传送NextGenTCP：

以最高等级，CWND现根本不减小。

容易使用Windows桌面“Folder string seach”实用程序来在所有子文件夹/文件中寻找CWND变量的每次出现......确切地说关于RTO超时......即使其拥塞被诱发，也根本不减小/复位CWND......，我们的修改现存RFC的规范的RTO超时算法伪代码将用以(用于“真实拥塞丢弃”指示)：

超时：/*乘法减小*/

记录的CWND＝CWND(但如果另一RTO超时在进行“暂停”期间发生，那么记录的CWND＝记录的CWND！/*不希望错误地导致减小CWND大小*/)

ssthresh＝cwnd(但如果另一RTO超时在进行“暂停”期间发生，那么SStresh＝记录的CWND！/*不希望错误地导致减小SSTresh大小*/)

计算“暂停”间隔并设定CWND＝“1*MSS”，并在“Pause”递减计数之后，恢复CWND＝记录的CWND；

我们的修改现存RFC的规范的RTO超时算法伪代码将用以(用于“非拥塞丢弃”指示)：

超时：/*乘法减小*/

ssthresh＝sstresh；

CWND＝CWND；

/*两者未改变！*/

仅需要确保经修改的RFC的TCP服从这些简短的简单规则：

1.永不减小CWND值，除了在“真实拥塞”指示时为了临时实现“暂停”(其后使CWND恢复到记录的CWND)。注意，在真实拥塞指示时(当第3个DUP ACK或当RTO超时时的最新RTT-min(RTT)＞(例如)200ms)，SSTresh需要被设定为预存在的CWND，因此随后的CWND递增为加法线性的。

2.如果非拥塞指示(当第3个DUP ACK或当RTO超时时的最新RTT-min(RTT)＜(例如)200ms)，针对快速重传和RTO超时模块两者，均不“暂停”且根本不允许现存RFC改变CWND值或SStresh值。

注意，在进行中的当前暂停(其仅可能由“真实拥塞”指示触发)，如果有的话，应被允许进行到递减计数完(针对快速重传和RTO超时模块两者)。

3.如果已有当前“暂停”在进行中，那么随后插入的“真实拥塞”指示现将完全终止当前“暂停”，并开始新的“暂停”(仅设定/重写新的“Pause”递减计数值)：

注意针对快速重传和RTO超时模块两者，记录的CWND现＝记录的CWND(而不是＝CWND)，且现SStresh＝记录的CWND(而不是CWND)。

非常简单的基础工作第1版本完整规范：仅几行非常简单的FREEBSD/LINUX TCP源代码修改

【起初需要设定非常大的初始化的min(RTT)值＝(例如)30,000ms，接着连续设定min(RTT)＝min(最新到达的ACK的RTT，min(RTT))】

1.1IF第3 DUP ACK，THEN

IF 3个DUP ACK快速重传时的最新返回的ACK的RTT-当前记录的min(RTT)＝＜(例如)200ms(即我们现在知道此包丢弃不可能由“拥塞事件”导致，因此不应不必要地将SStresh设定为CWND值)，THEN不改变CWND/SSTresh值(即甚至不设定CWND＝CWND/2也不将SSthrsh设定为CWND/2，如目前在现存快速重传RFC中所进行的那样)。

ELSE应将SSThresh设定为与此记录的现存CWND大小相同(而不是设定为CWND/2，如在现存快速重传RFC中)，且改为保存现存CWND大小的记录，并设定CWND＝“1*MSS”，并设定“Pause”递减计数全局变量＝(触发第3 DUPACK快速重传或触发RTO超时的包的最新RTT-min(RTT)，300ms)的最小值。

注意：设定CWND值＝1*MSS将导致包的所有向前转发的所需的临时暂停/停止(除第1个快速重传包重传包外)，以允许沿路径的缓冲包在TCP重新开始发送之前被清除】

ENDIF

1.2在“Pause”时间变量递减计数完之后，将CWND恢复到记录的先前CWND值(即发送器现在在“暂停”结束之后可重新开始正常的发送)。

2.1IF RTO超时，THEN

IF RTO超时时最新返回的ACK的RTT-当前记录的min(RTT)＝＜(例如)200ms(即我们现在知道此包丢弃不可能由“拥塞事件”导致，因此不应不必要地将CWND值复位为1*MSS)，THEN不将CWND值复位为1*MSS，也根本不改变CWND值(即甚至根本不复位CWND，如目前在现存RTO超时RFC中所进行的那样)。

ELSE应改为保存现存CWND大小的记录，并设定CWND＝“1*MSS”，并设定“pause”递减计数全局变量＝(RTO超时时的包的最新RTT-min(RTT)，300ms)的最小值。

注意：设定CWND值＝1*MSS将导致包的所有向前转发的所需的临时暂停/停止(除RTO超时重传包外)，以允许沿路径的缓冲包在TCP重新开始发送之前被清除】

2.2在“pause”时间变量递减计数完之后，将CWND恢复到记录的先前CWND值(即发送器现在在“暂停”结束之后可重新开始正常的发送)。

全部内容就是这些，现在完成！

背景材料

触发第3 DUP ACK快速重传或触发RTO超时的包的最新RTT容易在上次测量的往返时间RTT上从现存的Linux TCB维持的变量获得。最小所记录min(RTT)仅容易从现存Westwood/快速TCP/Vegas TCB维持的变量获得，但应足够容易编写几行代码以连续更新min(RTT)＝【min(RTT)，上次测量到的往返时间RTT】的最小值。

参考：

http://www.cs.umd.edu/～shankar/417-Notes/5-note-transportCongControl.htm：由Linnux TCB维持的RTT变量。<http://www.scit.wlv.ac.uk/rfc/rfc29xx/RFC2988.html>：RTO计算。Google搜索术语“tcp rtt variables”。<http://www.psc.edu/networking/perf tune.html>：调节LinuxTCP RTT参数。Google搜索：“linux TCP minimum recorded RTT”或“linux tcpminimum recorded rtt variable”。注意：TCP Westwood测量最小RTT。

注意：

1.上述“拥塞通知触发事件”可替代地界定为当最新RTT-min(RTT)＞＝指定间隔(例如)5ms/50ms/300ms等时(对应于由沿路径经历的缓冲引入的延迟高于并超过纯未拥塞RTT或其估计min(RTT))，代替包丢弃指示事件。

2.一旦由真实拥塞丢弃指示触发的“pause”已递减计数完，上述算法/方案可经调适以使得CWND现被设定为等于此瞬时“Pause”递减计数时间的总的未完成的运行中的包的值(即等于最新最大转发的SeqNo-最新最大返回ACKNo)＝＞这将防止源TCP产生包的突然较大突发，因为在“暂停”周期期间，可能存在接收到的很多返回ACK，其可已非常大程度地推进滑动窗口的边缘。

而且作为很多可能中的替代实例，CWND可最初根据触发“pause”递减计数的第3 DUP ACK快速重传请求而设定为未改变的CWND(而不是设定为“1*MSS”)，或设定为等于时间中的此瞬间的总的未完成的运行中的包的值，且进一步在“pause”已递减计数完时恢复到等于此瞬时总未完成的运行中的包的值【在此瞬时“pause”递减计数时间时，视情况，减去在“pause”递减计数之前接收到的额外相同SeqNo的多个DUP ACK(超过触发快速重传的初始3个DUPACK)的总数(即等于时间中的此瞬间的最新最大转发的SeqNo-最新最大返回ACKNo)】→经修改的TCP现可对应于在“暂停”间隔期间接收到的每一额外多个相同SeqNo的DUP ACK而向网络中发出新的包，且在“pause”递减计数之后，可视情况迟缓地“减慢”传输速率以清除沿路径的介入缓冲，当“pause”已递减计数完时，如果CWND现恢复为等于现在的瞬时总未完成的运行中的包减去在“pause”期间接收到的额外相同SeqNo的多个DUP ACK的总数的值。

另一可能实例是初始地在第3 DUP ACK快速重传请求触发“pause”递减计数时将CWND设定为“1*MSS”，且接着在“pause”已递减计数完时恢复为等于此瞬时总未完成的运行中的包减去额外相同SeqNo的多个DUP ACK的总数的值→以此方式，当“pause”递减计数时，经修改的TCP不会“突发”出新的包，而是仅对应于随后新的返回ACK速率而开始向网络中发出新的包。

3.上述演算法/方案的“pause”递减计数全局变量＝上述(触发第3 DUP ACK快速重传或触发RTO超时的最新RTT-min(RTT)，300ms)的最小值，可代替地设定为＝(触发第3 DUP ACK快速重传或触发RTO超时的最新RTT-min(RTT)，300ms，max(RTT))的最小值，其中max(RTT)为目前为止观察到的最大RTT。包含此max(RTT)是为了确保甚至在非常非常不可能的情况下(其中节点的缓冲容量极其小(例如在LAN或甚至WAN中))，“暂停”周期也不会不必要地设定得太大，例如指定的300ms值。而且代替上述实例性的300ms，可改为针对每一不同路径而在演算地动态地导出所述值。

4.允许实现可支持即刻可用有保证服务的网络(或仅无拥塞丢弃网络，和/或仅具有非常非常少的缓冲延迟的网络)的容易的普遍实施的简单方法是使网络中的节点处的所有(或几乎所有)路由器和交换机经修改/软件经升级以当节点开始缓冲通过的TCP流的包(即转发链路现100％被利用且总的通过的TCP流的“源”包开始被缓冲)时立即产生总数为3个的DUP ACK到通过的TCP流的源以向所述源指示减小其传输速率。或者，(例如)在转发链路达到(例如)95％/98％等的指定利用率等级，或一些其它指定触发条件时，可触发3个DUP ACK的产生。即使对应于3个伪DUP ACK的包实际上在目的地被正确地接收也没关系，因为从目的地到源的随后ACK将补救此情况。

所产生的3个DUP ACK包的字段含有最小所需的源和目的地地址和SeqNo(其可容易地通过检查现目前被缓冲的包来获得，注意3个伪DUP ACK的ACK字段是从所检查的经缓冲包的ACKNo获得或导出)。而3个伪DUP ACK的ACKNo字段可从(例如)交换机/路由器所保存的由目的地TCP针对特定单向源/目的地TCP流而产生的最新最大ACKNo的表获得或导出，或者，交换机/路由器可首先等待目的地-源包到达节点处，接着通过检查返回包的ACK字段来获得或导出3个伪DUP ACK的ACKNo字段。

类似于上述方案，现存RED和ECN等可类似地具有如上文概述那样修改的算法，从而允许实现可支持实时有保证服务的网络(或非拥塞丢弃和/或非常非常少缓冲延迟的网络)。

5.针对窗口的另一变型实施方案：

首先需要模块自MSTCP接管所有快速重传/RTO超时，即MSTCP不会看到任何DUP ACK或RTO超时：所述模块将简单地欺骗性应答来自MSTCP的每一截获的新包(仅稍后：在拥塞通知，(例如)3个DUP ACK或RTO超时时，且在需要时发送MSTCP“0”窗口大小更新，或将传入网络包的窗口大小字段修改为“0”，以暂停/减慢MSTCP包产生)。模块建立所转发的所有包的SeqNo/包副本/系统时间的列表(根据SeqNo良好地排序)，且根据此列表进行快速重传/RTO重传。列表上SeqNo＜当前最大接收到的ACK的所有项均将被去除，还去除所有经SACK的SeqNo。记住，需要在此模块中结合“SeqNo绕回”和“时间绕回”保护。

通过欺骗性应答所有的截获的MSTCP传出包，我们的窗口软件现根本不需要改变到MSTCP的任何传入网络包…MSTCP将简单地忽略所接收到的所有3个DUP ACK，因为它们现在已在滑动窗口之外(已被应答！)，也不会发送超时的包(已被应答！)，另外我们现总是可经由接收器窗口大小字段改变等来容易地控制MSTCP包产生速率。软件可通过在任何时间允许运行中的包的最大值等于模拟/跟踪的MSTCP的CWND大小来模拟MSTCP自己的Windows递增/拥塞控制/AIMD机制：作为(在很多可能性中的)总体概述实例，这可通过(例如)假定当尚未存在任何3 DUP ACK快速重传时，针对每一返回ACK，模拟/跟踪的伪镜像CWND大小在每一RTT中加倍，但一旦3 DUP ACK快速重传已发生，模拟/跟踪的伪镜像CWND大小在每RTT中现将仅递增1*MSS。软件将仅允许不大于模拟/跟踪的伪CWND大小的瞬时总未完成的运行中的包的最大值，且经由接收器窗口大小更新为“0”/将传入包的接收器窗口大小修改为“0”以在伪CWND大小被超过时“暂停”MSTCP传输来调节MSTCP包产生。

此窗口软件可接着总是通过跟踪最新最大向前转发的MSTCP包的SeqNo和最新最大网络的传入包的ACKNo(其差异给出未完成的运行中的包的总数，其相当好地对应于MSTCP的CWND值)，来跟踪或估计MSTCP CWND大小。此处的Window软件仅需要确保一旦运行中的包的总数目＞＝上文提及的CWND估计(或者从上述CWND估计和RWND和/或SWND导出的有效窗口大小)便停止对MSTCP的“自动欺骗性ACK”。

权利要求书(按照条约第19条的修改)

1.一种用于改进TCP和/或类TCP协议和/或其它协议的方法，所述方法能够完全地透过TCP/协议堆栈软件修正而无需任何其它网络组件的任何改变/重新配置且所述方法能够保证即刻可用服务PSTN传输品质的网络与无单一封包总是被拥塞丢弃，所述方法在检测到拥塞事件，例如拥塞包丢弃和/或返回ACK的往返时间RTT/单程时间OTT接近或超过某一门槛值，例如流路径的未拥塞RTT/OTT的已知值或它们的最新可用最好估计min(RTT)/min(OTT)时，经由发送器的数据传输中的完全或部分“暂停”/“停止”来避免和/或防止网络拥塞和/或从网络拥塞恢复。

2.一种用于改进TCP和/或类TCP协议和/或其它协议的方法，所述方法能够完全地透过TCP/协议堆栈软件修正而无需任何其它网络组件的任何改变/重新配置且所述方法能够保证即刻可用服务PSTN传输品质的网络与无单一封包总是被拥塞丢弃，所述方法包括(a)到(c)的任何组合/子集：

(a)充分利用新的实现/技术，使得TCP的滑动窗口机制的“有效窗口”和/或拥塞窗口CWND在尺寸方面不需要减小以避免和/或防止拥塞和/或从拥塞恢复；

(b)当检测到拥塞事件，例如拥塞包丢弃和/或返回ACK的往返时间RTT/单程时间OTT接近或超过某一门槛值，例如流路径的未拥塞RTT/OTT的已知值或它们的最新可用最好估计min(RTT)/min(OTT)时，经由发送器的数据传输中的完全或部分“暂停”/“停止”来代替地避免和/或防止拥塞和/或从拥塞恢复；

(c)代替或替代上述的(b)或与上述的(b)组合，将TCP的滑动窗口机制的“有效窗口”和/或拥塞窗口CWND值减小到至少部分地取决于检测到拥塞时的最新返回的往返时间RTT/单程时间OTT值，和/或特定流路径的已知未拥塞往返时间RTT/单程时间OTT或其最新可用最好估计min(RTT)/min(OTT)，和/或特定流路径的最新观察到的最长往返时间max(RTT)/单程时间max(OTT)而演算地导出的值。

3.一种用于能支持保证实际无拥塞服务的数据通信网络/因特网/因特网子集/私有因特网区段/WAN/LAN【下文称为网络】的方法，所述方法具有特征(a)到(f)的任何组合/子集：

(a)其中从所述网络内的源发送的所有包/数据单元均到达所述网络内的目的地，而没有单个包由于网络拥塞而丢弃；

(b)仅应用于需要有保证服务能力的所有包/数据单元；

(c)其中在被向前转发之前，截获并处理包/数据单元通信量；

(d)其中一个或一个以上发送源的通信量被截获、处理并向前转发，和/或仅在一个或一个以上起始发送源处截获、处理并向前转发包/数据单元通信量；

(e)其中发送源和/或接收目的地处的现存TCP/IP堆栈经修改以实现所述网络内的任何源-目的节点对之间的相同端到端性能结果，而不需要使用现存的QoS/MPLS技术，也不需要所述网络内的交换机/路由器软件中的任何一者被修改或促进实现所述端到端性能结果，也不要求在所述网络内的每个和每一节点间链路处提供无限带宽；

(f)其中，所述网络中的通信量主要包括TCP通信量，且在任何时间，例如UDP/ICMP等的其它通信量类型不超过，或将产生其它通信量类型的应用布置成不超过所述网络内的节点间链路的任何一者的总的可用带宽，其中如果例如UDP/ICMP…的其它通信量类型确实在任一时间超过所述网络内的节点间链路的任何一者的总的可用带宽，那么仅跨越所述网络内的因而受影响的节点间链路的源-目的节点对通信量在此时间期间将不一定能支持保证实际无拥塞服务，且/或从所述网络内的源发送、到达所述网络内的目的地的所有包/数据单元将不一定均到达，即包确实由于网络拥塞而被丢弃。

4.根据上述权利要求1-3中任一权利要求所述的方法，在所述方法中，协议的所述改进/修改在发送器TCP处实现。

5.根据上述权利要求1-3中任一权利要求所述的方法，在所述方法中，协议的所述改进/修改在接收器侧TCP处实现。

6.根据上述权利要求1-3中任一权利要求所述的方法，在所述方法中，协议的所述改进/修改在网络的交换机/路由器节点中实现。

7.一种其中协议的改进/修改是在如上述权利要求4-6中的任一权利要求中所指定的位置的任何组合中实现的方法。

8.一种其中协议的改进/修改是在如上述权利要求4-6中的任一权利要求中所指定的位置的任何组合中实现的方法，在所述方法中，现存“随机早期检测”RED和/或“明确拥塞通知”ECN经修改/适应以实行上述权利要求1-7中的任一权利要求所揭示的内容。

9.根据上述权利要求1-8中的任一权利要求所述或独立的方法，其中所述网络中的交换机/路由器的配置或设置或操作被调节，例如缓冲区大小调节，以实行上述权利要求1-8中的任一权利要求中所揭示的内容。

10.根据上述权利要求1-9中任一权利要求所述的方法，在所述方法中：

现存协议RFC经修改以使得发送器的CWND值现改为永不减小/递减，除了在检测到拥塞时临时实现发送器的数据传输的“暂停”/“停止”(例如，通过在“暂停”/“停止”期间临时设定发送器的CWND＝1*MSS，和在“暂停”/“停止”完成之后接着将发送器的CWND值恢复到例如“暂停”/停止之前的现存CWND值，或恢复到某一在演算地导出的值)：可将“暂停”/“停止”间隔设定为，例如，任意300ms或演算地导出的值，例如(触发第3 DUP ACK快速重传的返回ACK包的最新RTT或RTO超时时的返回ACK包的最新RTT，300ms)的最小值或演算地导出的值，例如(触发第3 DUP ACK快速重传的返回ACK包的最新RTT或RTO超时时的返回ACK包的最新RTT，300ms，max(RTT))的最小值

且/或

现存协议RFC经修改以使得SSThresh现改为设定成在触发“暂停”/“停止”的拥塞检测之前的现存CWND值，即随后的CWND递增将仅为超过CWND值的线性增加。

11.根据上述权利要求10所述的方法，在所述方法中，如果所述拥塞检测是由于例如物理传输错误或BER的非拥塞丢弃而导致，即不是由于拥塞包丢弃而导致，那么所述“暂停”/“停止”递减计数间隔将改为设定成“0”，即将不起始数据传输的任何实际“暂停”/“停止”，还注意，将允许在进行中的任何预先存在的当前“暂停”/“停止”正常地进行递减计数：如果，例如，当第3 DUP ACK触发快速重传时的最新返回的ACK的RTT或RTO超时时的最新返回的ACK的RTT-min(RTT)＜例如200ms，那么拥塞检测可归因于非拥塞原因。

12.根据上述权利要求10-11所述的方法，在所述方法中，如果已存在进行中的当前“暂停”/“停止”，那么随后的“真实”拥塞事件指示现将延长所述当前“暂停”/“停止”间隔，其仅为将目前“暂停”/“停止”递减计数值设定/重写为新值，例如，(触发第3 DUP ACK快速重传的返回ACK包的最新RTT或RTO超时时的返回ACK包的最新RTT，300ms，max(RTT))的最小值。

13.根据上述权利要求1-12中的任一权利要求所述的方法，在所述方法中：

所述网络中的节点处的任何一个或所有或几乎所有的路由器和交换机经修改/软件升级以立即产生到正通过的流的源的总数为3个的DUP ACK，以向所述源指示在节点开始缓冲正通过的TCP流的包(即转发链路现100％被利用，且总的正通过的TCP流的“源”的包开始被缓冲)时减小所述源的传输速率：所述3个DUP ACK的产生可替代地改为例如在转发链路达到例如95％/98％等的指定利用等级，或所指定的一些其它触发条件时被触发。

14. 根据上述权利要求1、2、7、9-13中任一权利要求所述的方法，在所述方法中：

现存RED和ECN的演算法可类似地如上述权利要求中任一权利要求中所含有的原理和方案中所概述地那样被修改，从而允许能支持实时有保证服务的网络(或无拥塞丢弃和/或具有非常少的缓冲延迟的网络)。

Claims

1.一种用于改进TCP和/或类TCP协议和/或其它协议的方法，所述方法在检测到拥塞事件，例如拥塞包丢弃和/或返回ACK的往返时间RTT/单程时间OTT接近或超过某一门槛值，例如流路径的未拥塞RTT/OTT的已知值或它们的最新可用最好估计min(RTT)/min(OTT)时，经由发送器的数据传输中的完全或部分“暂停”/“停止”来避免和/或防止网络拥塞和/或从网络拥塞恢复。

2.一种用于改进TCP和/或类TCP协议和/或其它协议的方法，所述方法包括(a)到(c)的任何组合/子集：

(b)仅应用于需要有保证服务能力的所有包/数据单元；

(c)其中在被向前转发之前，截获并处理包/数据单元通信量；

且/或

14.根据上述权利要求1、2、7、9-13中任一权利要求所述的方法，在所述方法中：