简述tcp的流量控制【TCP协议中的流量控制和拥塞控制研究毕业论文】
毕业设计 (论 文) TCP协议中的流量控制和拥塞控制研究 院 别 数学与统计学院 专业名称 信息与计算科学 班级学号 学生姓名 指导教师 年 月 日 TCP协议中的流量控制和拥塞控制研究 摘 要 计算机网络技术是当今发展最迅速的计算机技术之一，而保证网络稳定可靠运行的关键是计算机网络协议。TCP协议作为网络协议中的核心协议之一，其重要性更是不言而喻，因而对于该协议的研究与完善是促进网络发展的重要手段之一。
随着互联网规模和互联网应用的快速增长，网络拥塞和数据冲突问题已引起人们密切的关注。拥塞控制与流量控制技术针对网络中的拥塞和数据冲突而成为网络领域的核心技术。其中流量控制的对象是接收端，目的是使发送端的发送速率不超过接收端的接收能力；
拥塞控制的对象是网络环境，目的是使负载不超过网络的传送能力。
TCP的流量控制主要依赖于滑动窗口，通过流量约束，减少接收端出的数据流失，提高发送效率，充分利用接收端资源。
TCP的拥塞控制主要原理依赖于一个拥塞窗口(cwnd)来控制，窗口值的大小就代表能够发送出去的但还没有收到ACK的最大数据报文段，显然窗口越大那么数据发送的速度也就越快，但是也就越可能使得网络出现拥塞，如果窗口值为1，那么就简化为一个停等协议，每发送一个数据，都要等到对方的确认才能发送第二个数据包，显然数据传输效率低下。TCP拥塞控制算法就是要在这两者之间权衡，选取最的cwnd值，从而使得网络吞吐量最大化且不产生拥塞。
本文首先对TCP协议的发展做了简要的概述，然后分析了TCP协议的报文段格式和结构，TCP的数据传输过程，接着讨论了TCP的流量控制机制，最后针对TCP的重点部分拥塞控制进行了分析，讨论了几个TCP拥塞控制算法。
关键词：TCP协议，流量控制，拥塞控制 The Flow Contral and Congestion Control in TCP Protocol Abstract Computer network technology is one of the most rapidly developing of computer technology today,and the computer network protocols is the key to ensure the network is stable and re liable operation. TCP protocol, as one of the core protocols of the network protocol,is vary important, so to research and improve the protocol is one of the important means to promote the development of the network. With the rapid growth of Internet scale and the Internet application, network congestion and data conflict problem has aroused the concern of the people closely. Congestion control and flow control technology, according to the theory of network congestion and data conflict has become the core technology in the field of network. The flow control object is the receiver, the purpose is to make the sending rate does not exceed the capacity at the receiving end. Congestion control object is the network environment, the purpose is to make the transfer of a loaded with no more than the network capacity. TCP flow control is mainly depended on the sliding window, by flow constraints, and reduce the loss of data at the receiving end, to improve the transmission efficiency, make full use of the receiver. The main principle of TCP congestion control relies on a congestion window (cwnd) to control the window size value represents the ability to send out but not yet received the maximum data packet ACK Duan, clear window, so the greater the speed of data sent the faster, but also more likely to make the network congestion occurs, if the window is 1, then reduced to a stop such agreement, each sending a data, must wait for confirmation of the other party can send a second packet, the data clearly transmission efficiency is low. TCP congestion control algorithm is to balance between these two, choose the best cwnd value, allowing the network to maximize throughput and does not create congestion. Firstly, the development of the TCP protocol a brief overview, and then analyzed the structure of TCP protocol, TCP data transfer process, followed by a discussion of the TCP flow control mechanism, the key part of the final for the TCP congestion control are analyzed, discussed Several TCP congestion control algorithm. Key Words :TCP protocol, Flow control,Congestion control 目 录 1 绪论 1 1.1 TCP的发展过程与设计目标 1 1.1.1 TCP的发展过程 1 1.1.2 TCP的设计目标 1 1.2 论文结构 2 2 TCP协议 3 2.1 TCP的报文段 4 2.1.1 TCP的报文格式 4 2.1.2 TCP报文封装 5 2.2 TCP的数据传输 6 2.2.1 TCP连接的建立 6 2.2.2 TCP连接的释放 7 3 TCP协议中的流量控制 8 3.1 滑动窗口 8 3.2 可变窗口流量控制实例分析 8 4 TCP的拥塞控制 10 4.1 拥塞产生的原因 10 4.2 重发定时器管理 11 4.2.1 RTT的估算 12 4.2.2 RTO的计算 12 4.3 TCP 拥塞控制所采用的机制 13 5 TCP拥塞控制算法 17 5.1 TCP 的早期实现 17 5.2 TCP Tahoe 17 5.3 TCP Reno算法 17 5.4 TCP New-Reno 18 5.5 TCP SACK 19 5.6 TCP Vegas 20 结 论 22 致 谢 23 参考文献 24 附 录 25 1 绪论 计算机网络是计算机和通信密切结合的产物，近些年来得到了迅速的发展，已逐渐成为信息社会的基石。网络协议是计算机中不可缺少的的一个重要组成部分，它是计算机和计算机之间以及计算机和其他设备之间进行数据通信的必要条件。TCP协议作为重要的网络协议也是有了很大的发展。
1.1 TCP的发展过程与设计目标 认识来源于实践，而认识的最终目标也正是服务于实践。只有了解TCP的发展历史以及相应的设计目标，我们才能对TCP拥有较为全面的认识，从而更好地研究TCP技术，满足越来越高的应用需求。
1.1.1 TCP的发展过程 互联网最初源于美国国防部的ARPANET计划。上世纪60年代中期正是冷战的高峰，美国国防部希望有一个命令和控制网络，以确保在核战争的条件下幸免于难，而传统基于电路交换的电话网络则过于脆弱。国防部指定其下属的高级研究计划局解决这个问题，从而诞生ARPANET，其最大特点是采用无连接的端到端报文交换服务。到了80年代中期，演变为互联网。TCP协议最初只是作为NSFNET的程序规范，即RFC 793，这也是最早的较为完整且齐全的TCP规范。这个规范简单描述了如何进行主机到主机的可靠传输，并描述了传输控制协议执行的功能，相应的实现程序及程序接口。TCP协议在设计之初就被赋予了很高的使命，需要成为报文交换计算机网络和这些网络互联系统中的高可靠性传输协议。需要明确的是，网络中的可靠传输包括两方面：首先是数据的正确，由于以前的传输介质质量很差，所以在传输层及以下各层协议中都实现了校验和计算；
其次是数据的完整保序，这个特性需要TCP执行复杂的操作来实现，通常我们强调TCP的可靠传输时主要指后者。
1.1.2 TCP的设计目标 在TCP设计之初，网络技术刚刚起步，相应的硬件设施只能达到很低的水平，应用需求也十分简单，诸多因素导致TCP协议的设计目标从开始就已经先天不足。在设计TCP协议时，由于人们对网络，尤其是对大型互联网络缺乏本质的认识，从而遗漏了许多TCP协议应该具备的重要特征。例如，我们现在熟知的拥塞控制，在最初协议设计中就没能得到体现。
TCP最初的设计目标只是在进程间提供可靠、安全的逻辑链路，并在此基础之上提供可靠的传输服务。需要强调的是，TCP对网络并不做任何假设，它的主要功能就是提供可靠的逻辑链路。为了能够在不可靠的网络上进行可靠的通信，协议必须提供如下功能：能够进行基本的数据传输、保证数据的可靠性、进行适当的流量控制、维护通信状态的集合、使用并行多路技术以及保证通信的优先级 和安全性。
1.2 论文结构 本文主要围绕下列问题展开研究：
1．TCP的结构和数据传输过程 2．TCP的流量控制机制 3．TCP的拥塞控制与拥塞控制算法 2 TCP协议 TCP 协议是目前互联网上应用最广泛的传输层协议。它主要提供端到端可靠的字节流传送服务。
TCP 是一个面向连接的协议，即在端系统进行数据传输之前要建立连接，连接属于全双工方式(即数据可以在两个方向上同时进行传输)。TCP 在不可靠的IP 网络层上提供可靠的数据传输服务，即所有被传输的数据最终都应到达接收端。在TCP 中，接收端对其所接收的每一个分组都进行确认，在一定时间范围内没有得到确认的分组会被发送方重新进行发送。接收端如果收到一个重复的分组，将会丢弃该分组，如果收到乱序的分组，则对这个分组进行重新排序。每个分组都会有自己对应的序列号，发送方可以通过分组确认报文获得接收端所希望接收的下一个分组的序列号。当通信双方均有数据要发送时，TCP 可以将确认信息放在数据分组中发送以减少控制信息带来的额外流量。TCP协议对数据单元的传输及重传策略，对于网络的拥塞状况有着深刻的影响。
概括来说，TCP 协议为应用层提供了以下服务：
1．流交付服务:TCP 协议允许发送进程以字节流的形式来传递数据，而接收进程也把数据作为字节流来接收。这样，TCP 协议使得两个进程好像在一个假想的“管道”中传送两个进程的数据。
2．全双工服务:即数据可在同一时间双向流动。每一个TCP 端系统都有发送缓存和接收缓存，而两个方向都可以发送报文段。
3．面向连接服务:TCP 通过一条虚拟连接来传送数据。当TCP 报文被封装成IP 分组后，每一个分组可以走不同的路径来到达目的端，因此收到的IP 分组可能会乱序，可能会丢失，或者受到损伤，并可能经过重传。但是TCP 创建了面向流的环境，它负责按顺序将完整的数据交付给应用程序。
4．流量控制:流量控制定义了发送端在收到从接收端发来的确认之前可以发送的数据量。TCP 协议在缓存上定义了一个窗口，缓存是用来暂时存放从应用程序传递来并准备发送的数据，TCP 发送端就根据这个窗口的大小来发送数据。这就是所谓的滑动窗口机制。
5．差错控制:TCP 是可靠的传输层协议，这就表示，当应用程序把数据流交付给IP 层后，TCP协议应当把数据流按顺序，没有差错，没有损伤地交付给另一个应用程序。为了实现差错控制，TCP 协议采用了以下几种机制：检测受到损伤的、丢失的、失序的和重复的数据包；
在检测到差错后，能够纠正差错。
6．拥塞控制:互联网由许多网络和连接设备组成。发送端发送的分组要经过多个路由器后才能到达最后的接收端。路由器为了保证链路的利用率，一般都会提供缓存来暂时存储突发到达的分组，但是当路由器接收过多的分组时，就可能导致路由器缓冲区溢出，即该路由器节点发生拥塞，部分分组就会被丢弃。当发送端重传这些分组时，会造成更加严重的拥塞，以致于使网络瘫痪。因此我们必须在端系统采用一些拥塞控制机制来保证网络不会发生拥塞，同时又能充分利用网络的链路资源。TCP协议采用了慢启动，拥塞避免等算法来对网络拥塞进行控制，从而在一定程度上保证网络的稳定运行。
2.1 TCP的报文段 2.1.1 TCP的报文格式 TCP 软件在两台计算机之间传输的数据单元称为报文段(segment)。通过报文段的交互来建立连接、传输数据、发出确认、通告窗口大小及关闭连接。图2.1表示出了TCP 报文段的格式，每个报文段分为两个部分：首部和数据。报文段既可以用来建立连接，也可以运载数据和应答。
TCP源端口号（16位） TCP目标端口号（16位） 序列号（32位） 确认序列号（32位） 首部长度（4位） 保留 （6位） URG ACK PSH RST SYN FIN 窗口大小（16位） 校验和（16位） 紧急指针（16位） 选项和填充 数据区 图2.1 TCP报文段格式 TCP报文段首部固定部分各字段的意义如下：
源端口和目的端口：各占2个字节，是传输层与高层的接口。
序列号：占4字节，是本报文段所发送的数据部分第一个字节的序号。在TCP输送的数据流中，每一个字节都有一个顺序号。例如，在一个报文段中，序号为300，而报文中的数据为100字节，那么，在下一个报文段中，其顺序号就是400。由此可见，TCP是面向数据流的。
确认序列号：占4字节，是期望收到对方下次发送数据的第一个字节的序号。
首部长度：占4bit，它指出以32bit 为单位的TCP 报文段首部的长度。在首部字段后面是6bit的保留字段，是为将来的应用而保留的，目前置为0。
紧急比特URG：当URG = 1时，表明此报文段应该尽快发送，而不要按照原来的排队顺序发送。它通常与紧急指针(位于第5个32bit 字段中的后一半)配合使用，紧急指针指出在本报文段中的紧急数据的最后一个字节的序号。紧急指针使接收方可以知道紧急数据共有多长。需要注意的是，即使窗口大小为0时也可发送紧急数据。
确认比特ACK：只有当ACK = 1时确认序号字段才有意义。当ACK = 0时，确认序号无意义。
急迫比特PSH：当PSH = 1时，表明请求远地TCP将本报文段立即传送给其应用层，而不要等整个缓冲区都填满之后再向上交付。
复位比特RST：当RST = 1时，表明出现严重差错，必须释放连接，然后再重新建立连接。
同步比特SYN：在连接建立时使用。当SYN = 1而ACK = 0时，表明这是一个连接请求报文段。对方若同意建立连接，则应在发回的报文段中使SYN = 1和ACK = 1。因此SYN置为1，就表示这是一个连接请求或连接接受报文，而ACK 比特的值用来区分是哪一种报文。
终止比特FIN：用来释放一个连接。当FIN = 1时，表明欲发送的字节串已经发完，并请求释放传输层连接。
窗口：占2字节。窗口字段提供端到端的流量控制，它表示在确认了字节之后还可以发送多少个字节。此字段值为0是合法的，表示它已经收到了包括确认号减1(即己发送的所有报文段 )在内的所有报文段，但当前接收方急需暂停。之后通过发送一个带有相同确认号和滑动窗口字段非零值的报文段来恢复原来的传输。
校验和：占2字节。校验和字段覆盖的范围包括首部、数据和概念上的伪TCP首部之和。
选项和填充：占2字节。为可选部分，用于TCP具体选项。填充的作用是确保首部大小是一个32位的整倍数。
2.1.2 TCP报文封装 如图2.2所示，TCP报文段封装在IP数据报中，然后再封装成数据链路层中的帧，并通过物理层传输到数据的接收端，在接受端数据链路层剥去帧的首部，然后送到接收端的网络层，剥去IP首部再发送到传输层，所剩下的就是发送段的TCP报文段。
IP首部 TCP首部 TCP数据 IP报文段 TCP报文段 图2.2 报文段的封装 2.2 TCP的数据传输 2.2.1 TCP连接的建立 TCP以全双工的方式传输数据。当两个机器重的两个TCP建立连接候，他们都能够同时向对方发送报文段。这就表示，在任何数据传输之前，每一方都必须对通信进行初始化，并得到对方的认可，即TCP的连接。TCP的连接建立称为“三次握手“。1.客户发送第一个报文段，SYN报文段，在这个报文段中只有SYN标志置1。这个报文段的作用是使序号同步。客户端选择一个随机数SEQ作为第一序号，并把这个序号发给服务器。2.服务器发送第二个报文段，即SYN+ACK报文段，其中有两个标志置为l。这个报文段有两个目的，一个是使用SYN同步初始序号，另一个是服务器使用ACK标志确认已经从客户端收到的SYN报文段，同时给出期望从客户端收到的下一个序号。3.客户端发送第三个报文段。这仅仅是一个ACK报文段。它使用ACK标志和确认号字段来确认收到了第二个报文。
实例分析：
SYN = 1，SEQ = 800 SYN=1，ACK=1，SEQ=1500，ACK=801 ACK = 1，SEQ = 1501，ACK = 801 主机A 主机B 连接请求 图2.3 TCP连接的建立 下面我们以主机A和主机B两个应用程序为例来分析。如图2.3所示。这个过程从服务器开始。主机A告诉它的TCP，它已经准备好接受连接，这叫做被动打开。主机B发送请求叫做主动打开。A的TCP向B的TCP发出连接请求报文段，其首部中的同比特SYN应置1，同时选择一个序号X，我们选取X = 800，表明在后面传输数据的第一个数据字节的序号是X+1，即为801。B的TCP收到连接请求报文段后，如同意则发回确认。在确认报文段中将SYN和ACK都置1，确认号为X+1，即为801，同时为自己选择一个序号Y，令Y = 1500。A的TCP收到B的确认后，要向B给出确认，其ACK置1，确认号为Y+1，即为1501，自己的序号为X+1，为801。
2.2.2 TCP连接的释放 参加交换数据的双方的任何一方都可以关闭连接。当一方向的连接被终止时，另一方还可以继续向对方发送数据。建立一个连接需要三次握手，终止连接要经过四次握手。
FIN = 1，SEQ = 1001 ACK = 1，SEQ = 1700,ACK = 1002 FIN=1，ACK=1,SEQ=1700，ACK=1002 主机A 主机B 释放链接 ACK = 1，SEQ = 1002，ACK = 1701 确认 确认 图2.4 TCP连接的释放 实例分析：
如图2.4所示，主机A的应用进程先向其TCP发送连接释放请求，并且不再发送数据。TCP通知对方要释放从A到B这个方向的连接，将发往主机B的TCP报文段首部的FIN置1，其序号X等于前面已传送过的数据的最后一个字节的序号加1，为X = 1001。主机B的TCP收到释放链接通知后发出确认，其序号为Y = 1700，确认号为X+1，即1002，同时通知高层应用进程，应用进程通知TCP释放连接。B发出的连接释放报文段必需将FIN和ACK置1，并使其序号仍为Y，重复上次发送的ACK = X+1。A对此确认，将ACK置1，ACK=Y+1 = 1701，自己的序号是X+1为1002。
3 TCP协议中的流量控制 如果发送端发送的数据过多或者数据发送速率过快，致使接收端来不及处理，则会造成数据在接收端的丢弃。为了避免这种现象的发生，通常的处理办法是采用流量控制，即控制发送端发送的数据量及数据发送速率。时期不超过接收端的承受能力，这个能力主要指接收端的缓存和数据处理速度。
流量控制是与点到点的通信量有关的，是针对端系统中资源受限而设置的。主要解决快速发送方与慢速接收方的问题。流量控制的目的是在有限的接收端承受能力的情况下，通过流量约束，减少接收端出的数据丢失，提高数据发送效率，充分利用接收端资源。
3.1 滑动窗口 TCP的特点之一是提供体积可变的滑动窗口机制，支持端到端的流量控制。TCP的窗口以字节为单位进行调整，以适应接收方的处理能力。处理过程如下：首先，在TCP连接阶段，双方协商窗口尺寸，同时接收方预留数据缓冲区；
其次，发送方根据协商的结果，发送符合窗口尺寸的数据字节流，并等待对方的确认；
最后，发送方根据确认信息，改变窗口的尺寸。
1 100 101 200 201 300 301 400 401 500 501 600 发送窗口 已发送并被确认 已发送但未被确认 可继续发送 不可发送 指针 图3.1 滑动窗口 图3.1表示发送窗口为400字节，发送端已发送300字节的数据，但是只收到对前100字节的确认，同时窗口的大小不变，现在发送端还可以发送200字节。
3.2 可变窗口流量控制实例分析 设主机A向主机B发送数据，如图3.2所示，双方规定窗口值是400。再设每一个报文段是100字节长，序号的初始值为1。主机B进行3次流量控制，第一次将窗口减少为300字节，第二次减为200字节，最后一次减为08字节，即不允许发送数据。
SEQ = 1 SEQ = 101 SEQ = 201，丢失 ACK=201，WIN=300 SEQ = 301 SEQ = 401 SEQ = 201 ACK=501，WIN=200 SEQ = 501 ACK = 601，WIN = 0 A还能发送200字节 A还能发送200字节 丢失了序号201—300的数据 允许A还能发送300字节（序号201—500数据） A还能发送200字节（序号301—500数据） A还能发送100字节（序号401—500数据） A超时重发（201—301字节数据） 允许A再发送200字节 A还能发送100字节（序号501—700数据） 序号600以前数据都收到不允许A再发送 主机A 主机B 图3.2 可变窗口流量控制 4 TCP的拥塞控制 拥塞是一种持续过载的网络状态，此时用户对网络资源（缓存空间、链路带宽容量和中间节点的处理能力等）的需求超过了其固有的容量。网络的性能 (功率、往返时间RTT、吞吐量)与负荷的关系可以用图4.1来说明。可以看出当负荷较小时，网络吞吐量和资源功率（资源功率＝吞吐量/响应时间）随负荷的增长的以指数增长，RTT随负荷的增长略有上升，当负荷到达膝点时，功率到达最大值，在此之后吞吐量的增长远远慢于负荷的增长，RTT迅速上升，功率快速下降，若继续增长负荷，则存在丢包的可能。负荷到达崖点时，吞吐量达到最大值，功率到达最小值。RTT以指数增长，系统处于拥塞状态。膝点指资源功率到达最大值的负荷量。崖点指资源功率下降到最小值且开始丢包时的负荷量。因此膝点是最为理想的工作点，拥塞控制就是采用某种策略或机制，保持网络工作在正常的状态下，也就是使网络经常工作在崖点左侧的区域内。若一种控制机制使得网络工作在膝点附近，该方法称为拥塞避免；
若一种控制机制使网络工作在崖点或崖点以后的网络回复至膝点前后，该方法称为拥塞恢复。
图4.1 网络性能与负荷之间的关系 4.1 拥塞产生的原因 随着通信和计算机技术的成熟和发展，互联网规模的增长，网络用户和网络应用都在快速地增长，人们对包括话音、文字、数据、图像等多种媒体通信的需求不断增大。在计算机网络中有许多网络资源，如链路的容量、交换节点中的缓冲区和处理机等，如果在某段时间，用户(端系统)加于网络的负载大于网络资源容量和处理能力，就会产生拥塞，网络的性能就要变坏。若网络中的许多资源同时产生拥塞，网络的性能就要明显变差，整个网络的吞吐量将随输入负载的增大而下降，表现为数据包时延增加、丢弃概率增大、上层应用系统性能下降等。
总的来说，资源紧缺和资源的不合理利用时产生拥塞控制的直接原因，具体表现在：
1．存储空间不足：几个输入数据流共同需要同一个输出端口，在这个端口就会建立排队。如果没有足够的存储空间存储，数据包就会被丢弃。对突发数据流更是如此。增加存储空间在某种程度上可以缓解这一矛盾，但如果路由器有无限存储量时，拥塞只会交得更坏，而不是更好，因为在网络里数据包经过长时间排队完成转发时，它们早己超时，源端认为它们已经被丢弃，而这些数据包还会继续向下一个路由器转发，从而浪费网络资源，加重网络拥塞。
2．带宽容量不足：低速链路对高速数据流的输入也会产生拥塞。根据香农信息理论，任何信道带宽最大值即信道容量 (N为信道白噪声的平均功率，S为信源的平均功率，B为信道带宽)。所有信源发送的速率R必须小于或等于信道容量C。如果R>C，则在理论上无差错传输就是不可能的，所以在网络低速链路处就会形成带宽瓶颈，当其满足不了通过它的所有源端带宽要求时，网络就会发生拥塞。
3．处理器处理能力弱、速度慢也能引起拥塞：避免拥塞的发生，对以上原因需综台考虑。拥塞虽然是由于网络资源的稀缺引起的，但单纯增加资源并不能避免拥塞的发生。定程度时，只会加重拥塞，而不是减轻拥塞，是因为当报文段经过长时间排队完成转发时，它们很可能早己超时。从而引起源端超时重发，而这些报文段还会继续传输到下一路由器，从而浪费网络资源，加重网络拥塞。事实上，缓存空间不足导致的丢包更多的是拥塞的“症状”而非原因。另外，增加链路带宽及提高处理能力也不能解决拥塞问题。
单纯地增加网络资源之所以不能解决拥塞问题，是因为拥塞本身是一个动态问题，它不可能只靠静态的方案来解决，而需要网络协议在网络出现拥塞时保护网络的正常运行，即需要对网络的可能拥塞进行控制。
拥塞一旦发生往往会形成一个不断加重的过程，如不加控制，就会影响网络的性能，严重的情况甚至会使整个网络发生瘫痪。所以，拥塞控制是网络中必不可少的机制。
4.2 重发定时器管理 重发定时器管理是TCP拥塞控制中的一个关键技术。
TCP每发送一个报文段，就设置一次计数器。只要计时器设置重传时间到而还没有收到确认，就要重传这一报文段。重传时间间隔的取值(RTO)直接影响到发送端对网络的反应情况。取值太小，会造成不必要的重传，从而浪费网络资源：取值太大，对报文段丢失的反应就会很迟缓。RTO的值与RTT(Round Trip Time)有很大的关系。所以，正确估算RTT的值并合理地选择RTO的值对TCP的性能有重要影响。
4.2.1 RTT的估算 整个端到端路径的往返时间RTT(Round Trip Time)指从源端发出一个报文段到收到相应的确认之间的时间间隔。RTT 包括正向和反向路径中各跳的链路时延(传输时延和物理传播时延)和中间结点的处理时延(排队、路由查找、转发)。RTT 随着各个中间结点的排队情况不同，表现出一定的随机性。如果中间结点使用较长的队列，RTT 的变化会很大。一种计算RTT 的方法就是对观察到的一些报文段的往返时间简单地取平均，但是，通常我们希望对更近期的采样值给予更大的权值，因为它们更可能反映将来的行为，因此，常用的_种技术为指数平均法。其平滑RTT 的值的计算如下：
其中SRTT(K)是前K个报文段的平滑往返时间估值：α是指数平均的权值(0<α<1)，α 越小，给予更迸的观察值的权值就越大，通常α的取值为7/8，此时，将几乎所有的权重都给了最近10个左右的观察值。
4.2.2 RTO的计算 对RTO的计算主要有三种方法；
RTT方差估计(Jacobson算法)、指数RTO退避和Karn算法。
1．RTT方差估计：
最初的TCP规约试图通过对RTT估值乘以一个常数因子B(通常取B=2)的方法确定RTO的值，但在稳定环境中RTT的方差很低，用上述方法得到的RTO就不必要的取得太高；
而在不稳定的环境中，p取值为2可能并不足以防止不必要的重传。RTT方差估计是通过平滑RTT方差的倍数与平滑往返时间之和来确定定时器的取值，它可以更有效的计算RTO的值。完整的算法表达如下：
采样平滑偏差：
平滑偏差：
重发定时器：
一般情况h的取值为1/4，ƒ的取值为4。
经验证明，此算法可以显著提高TCP的性能。
2．指数RTO 退避：如果TCP的发送端在一个报文段上发生超时，它就必须重传这个报文段。考虑到超时可能是由于网络拥塞引起的，为了给网络足够的时间从拥塞中恢复，一个更明智的策略是TCP源端在同一报文段重传时增加其RTO，这被称为退避过程 (backoff process)。实现RTO退避的一种简单的方法是对一个报文段的每次重传都将RTO乘以一个常数值，即: 。这就使得RTO随每次重传而指数增长。q通常取2，此时称之为二进制指数退避(binary exponential backoff)。
3．Karn 算法：假定一个报文段发生超时而必须重传，如果随后收到了—个确认，那么就有两种可能：
1）报文段第一次传输的ACK。这种情况下，RTT 仅比期望的更长一些，但却是网络状况的精确反映。
2）是第二次传输的ACK。
TCP源端并没有办法区分这两种情况。如果发生的是第二种情况而TCP实体只是简单地将RTT算成是从第一次传输到收到ACK这段时间，那么这个时间就比实际的RTT要长得多。将这个错误的RTT输入到Jacobson算法中会产生太高的SRTT和RTO。另外，这个效果会向前传播许多次迭代，因为一次迭代产生的SRTT值是下一次迭代的输入值。
一种更糟的方法是将RTT算成从第二次传输到收到ACK这段时间。如果这个ACK实际上是对第一次传输的ACK，那么我们测得的RTT值就比实际值小许多。从而导致SRTT和RTO值太小。这可能产生正反馈效应，引起更多的重传和更多的错误测量。
Karn算法采用以下规则解决了这个问题：
1）要使用对重传报文段测得的RTT更新SRTT和SDEV。
2）在重传时使用等式计算退避RTO。
3）后续各报文段使用退避RTO值，直到收到了一个对未被重传报文段的确认为止。当一个对未被重传报文段的确认收到以后，Jacobson算法又被激活，用来计算将来的RTO值。
4.3 TCP 拥塞控制所采用的机制 为了更好的进行拥塞控制，TCP主要采用以下四种机制：慢启动、拥塞避免、快速重传和快速恢复。
1．慢启动：
当连接刚建立或超时时，进入慢启动阶段。当新建TCP连接时，拥塞窗口被初始化为一个数据包大小。源端按cwnd大小发送数据，每收到一个ACK确认，就增加一个数据包发送量，这样慢启动阶段cwnd随RTT呈指数级增长。
慢启动采用逐渐增大cwnd的方法，可以防止TCP在启动一个连接时向网络发送过多的数据包而造成不必要的数据丢失和网络拥塞，并且它还能够避免采用单纯的AIMD算法造成的吞吐量增加过慢的问题。
为了防止cwnd的无限制增长引起网络拥塞，引入一个状态变量：慢启动门限值ssthresh。
当cwnd<ssthresh时，使用上述的慢启动算法，cwnd随RTT呈指数增长。
当cwnd>ssthresh时，使用拥塞避免算法，减缓cwnd的增长速度。
当cwnd=ssthresh时，既可使用慢启动算法也可使用拥塞避免算法。
2．拥塞避免：
当发现超时或收到3个相同ACK确认帧时，网络发生了拥塞(主要因为由传输引起的数据包损坏和丢失的概率很小(<l％))。此时就进入拥塞避免阶段。慢启动门限值(ssthresh)被设置为当前拥塞窗口大小的一半；
如果超时，拥塞窗口被置1。如果此时cwnd<=ssthresh，TCP就重新进入慢启动过程；
如果cwnd>ssthresh，TCP就执行拥塞避免算法，此时，cwnd在每次收到一个ACK时只增加1／cwnd个数据包，这样，在一个RTT内，cwnd将增加1，所以在拥塞避免阶段，cwnd不是呈指数增长，而是线性增长。
3．快速重传和快恢复阶段：
在拥塞避免阶段，当数据包超时时，cwnd被置为1，重新进入慢启动阶段，这会导致过大地减小发送窗口尺寸，降低TCP连接的吞吐量。因此，引入了快速重传和快速恢复机制。
在快速重传阶段，当源端收到3个或3个以上重复的ACK时，就判定随后的数据包丢失，应该立刻重传，进入快速恢复阶段。
在快速恢复阶段，设置为ssthresh=cwnd/2；
重传丢失的报文段；
设置cwnd=ssthersh+n（n为已经收到的重复报文段的个数）；
收到非重复ACK时，置cwnd＝ssthresh，转入拥塞避免阶段；
如果发生超时重传，则置ssthresh为当前cwnd的一半，cwnd＝1，重新进入慢启动阶段。这种方法避免了数据包超时后就重新进入慢启动阶段，提高了TCP连接的吞吐量。
实例分析：
下面通过几个实例分析一下TCP拥塞控制的几个阶段。
1．慢启动和拥塞避免的实例 先假设窗口的单位为报文段，当TCP连接进行初始化时，将拥塞窗口置为1，即cwnd=1。慢开始门限的初始值设置为8，即ssthresh=8。发送端的发送窗口win不能超过拥塞窗口cwnd和通告窗口awin中的最小值。假定通告窗口awin足够大，因此发送窗口win的数值等于拥塞窗口cwnd的数值。在执行慢启动算法时，拥塞窗口cwnd=1。以后发送端每收到一个对新报文段的确认ACK，就将cwnd+1，开始下一次传输。当cwnd增长到慢开始门限值ssthresh时，即cwnd=8时，改为拥塞避免算法。假定拥塞窗口的数值增长到了12时，网络出现超时，则更新ssthresh=6，拥塞控制窗口cwnd=1，执行慢启动算法。当cwnd=6时改为拥塞避免算法。
16 12 8 4 0 2 4 6 8 10 12 14 16 18 ssthress=8 更新后ssthress=6 控制窗口cwnd 传输次数 进入拥塞避免 进入拥塞避免 超时 图4.2慢启动和拥塞控制的实例 上图4.2中发送了3次收到3个ACK后控制窗口cwnd达到了慢开始门限值ssthresh=8，进入了拥塞避免阶段，又传输了4次，当cwnd=12时，网络发生拥塞，执行拥塞避免算法。使cwnd=1，ssthresh=6再开始慢启动阶段，当cwnd=6时进入拥塞避免阶段。
2．快重传和快恢复的实例 假定发送端发送了A1—A4，4个报文段，当接收端收到A1，A2，A3后就发出确认ACK2，ACK3，ACK4。由于网络拥塞使A4丢失了，接收端收到下个A5发现序号不对，但仍收下放在缓存中，同时发出确认ACK4。发送端接着发送A5，A6，接收端收到后还要分别发送重复的ACK4。这样发送端收到了4个ACK4，其中3个是重复的，发送端就断定有分组丢失了立即重传A4，同时进入快恢复阶段。设置ssthresh=ssthresh/2，cwnd=ssthresh+3，如果还可以发送就继续发送A7，若收到新的报文段的ACK8，则将设置 cwnd=ssthresh。
16 12 8 4 0 2 4 6 8 10 12 14 16 18 ssthress=8 更新后ssthress=6 控制窗口cwnd 传输次数 进入拥塞避免 收到新的报文段ACK 收到3个重复ACK并快速重传 快速恢复 图4.3 快重传和快恢复的实例 上图4.3在cwnd=12时收到了3个重复的ACK，发送方断定有分组丢失开始重传，进入快速恢复阶段，使ssthresh=cwnd/2=6，cwnd=ssthresh+3=9。再经过一次传输收到新报文段的确认ACK，将cwnd设置为cwnd=ssthresh，进入拥塞避免阶段。
5 TCP拥塞控制算法 TCP协议经过多年的发展，有了多种具体的实现。TCP从第一个实现到现在，不断得到改进。现有的TCP拥塞控制算法主要有Tahoe、Reno、New--Reno、SACK和Vegas。其中，Tahoe、Reno、New-Reno和SACK是基于AIMD(Additive Increase Multiplicative Decrease)机制来改变拥塞窗口cwnd的大小，而Vegas是通过观察以前TCP连接中RTT值的改变情况来控制cwnd的大小。
5.1 TCP 的早期实现 早期TCP使用简单的停止等待协议，每发送一个报文，都要等待确认后，才能顺序发送下一报文，因此效率很低，且在等待确认后，网络资源也不能得到充分的利用。另外，还必须等重传计时器超时，才能重新发送丢失的报文，对网络拥塞未采取有效的措施。
5.2 TCP Tahoe 1988年，Jacobsen改进了原来的TCP机制，提出了Tahoe算法。在早期实现的基础上，Tahoe加入了慢启动、拥塞避免和快速重传机制。对重发定时器的取值也进行了改进。并具有 RTT估计和差错恢复的功能。Tahoe的基本思想是探测网络的可用带宽，在拥塞时急剧降低数据发送速率 (即：在丢失报文段重传之后，将cwnd的值降为1，将ssthresh置为cwnd/2后，重新进入慢启动阶段)。
Tahoe算法存在着不足之处：在收到3个重复ACK或在超时的情况下，Tahoe置cwnd为1，然后进入慢启动阶段。这一方面会引起网络的激烈振荡，另一方面大大降低了网络的利用率。
5.3 TCP Reno算法 针对Tahoe算法的不足之处，1990年Jacobson在Tahoe的基础上提出了改进算法Reno。改进主要有两个方面：一是对于收到连续3个重复ACK，算法不经过慢启动，而直接进入拥塞避免阶段；
二是增加了快速重传/快速恢复机制。具体实现过程为：
1．收到三个重复的ACK，进入快速重传/快速恢复，此时ssthresh设置为当前拥塞窗口的一半。
2．重传丢失的数据包，并置cwnd＝cwnd＋n (n为收到的重复ACK数)。
3．发送新的数据包。
4．当收到非重复的ACK时，cwnd＝ssthresh。
5．进入拥塞避免阶段。
从上面的过程可以看出，Reno在收到3个重复ACK后，就转入快速重传/快速恢复阶段；
而遇到超时时，Reno和Tahoe一样进入慢启动阶段。
但是如果在一个发送窗口内有多个包丢失时，该算法不能有效恢复出来。
5.4 TCP New-Reno 1996年在Reno的基础上提出了New-Reno算法。对Reno的快速恢复机制进行了改进，以避免一个窗口内发生多个报文段丢失的情况下传输性能的下降。在Reno中，发送端只要收到对重传报文段的确认就结束快速恢复过程；
New-Reno则是在收到对该窗口所有报文段确认之后才退出快速恢复过程，从而避免出现多个丢失造成的cwnd连续减小。因此，New--Reno比Reno能更好的保证网络的稳定性。
New-Reno与Reno的不同仅在于步骤1(下面所述)中变量“recover”的引入，以及步骤5中收到部分或新的确认ACK后的处理方式。New-Reno中定义了一个“快速恢复过程”，其快速重传和快速恢复机制可以概括为如下五步：
1．当TCP发送端收到第三个重复的ACK并且发送端还没有处于快速恢复阶段时，用下式设置ssthresh的值。然后用变量“recover”记录此时传送的最大序列号。
2． TCP发送端重传丢失的报文段并设置cwnd的值为：cwnd=ssthresh+3×MSS。这将人为的按已经离开网络的报文段数目和接收端已经缓冲的数据量来扩充拥塞窗口。
3．对每次接收到的额外的重复ACK，将cwnd增大MSS字节。这将人为的扩充拥塞窗口以反映其它已经离开网络的报文段。
4．如果cwnd和接收端的通告窗口的值允许的话，TCP发送端发送下一个报文段。
5．当下一个确认新报文段的ACK到达时(此ACK可能是由步骤2中的重传引发的确认，或者是稍后的一次重传引起的)：
如果这个ACK确认了直到并包含序列号为“recover”的报文段，那么这个ACK确认了TCP发送端在丢失报文段的第一次传送和第三个重复ACK接收之间发送的所有报文段。TCP发送方可以设置cwnd的值为：
此处ssthresh是步骤1中的值(步骤l中的发送窗口是TCP进入快速恢复阶段时的值：而步骤5中的发送窗口是TCP退出快速恢复阶段时的值)。
如果这个ACK不是对所有并包含到序列号为“recover”报文段的确认，那么这个ACK就是一个部分确认。在这种情况下，TCP发送端并不退出快速恢复过程，而是立即重传部分确认ACK中指示的第一个没有确认的报文段。这和Reno处理部分确认的方式不同，Reno在收到一个部分确认ACK后立即退出快速恢复过程。如果还有任何其他重复ACK随后到达，New-Reno发送端重复执行上面的步骤3和4。于是，当一个发送窗口中有多个报文段丢失时，New-Reno不需等到超时重发定时器超时就能从多个报文段的丢失中恢复。TCP发送端在每个往返时间内重发一个丢失的报文段，直至重发了所有丢失的报文段为止。New-Reno一直处于快速恢复阶段直到发送端在进入快速恢复之前发出的所有报文段都被确认为止。
5.5 TCP SACK 1996年还提出了Reno的另一改进SACK算法。它利用SACK报文段中的选项对接收报文进行确认。根据SACK选项的确认信息，发送端可以确知哪些报文段已被接收，从而只重传那些实际丢失的报文段，这就有利于发送端从单个窗口内丢失多个报文段的环境中快速的恢复。
SACK用到两种TCP选项：授权选项和SACK选项。
授权选项只在连接建立时使用。此选项包含在SYN报文中被发送，表示此连接可以用SACK 选项。它占两个字节，其格式为：
Kind=4 Length=2 典型的SACK算法是对Reno算法的一种简单改进，它们在扩大和减小拥塞窗口上使用的都是相同的机制。在TCP中增加SACK并不改变拥塞控制的基本机制，SACK不但实现了Tahoe和Reno在报文段失序时的健壮性，而且必要时仍然使用重发定时器的超时重发机制来进行恢复。
SACK和Reno的主要差别在于，当多个报文段从一个数据发送窗口丢失时采取的对策。SACK和Reno一样，一般当TCP发送端收到3个重复的ACK时就进入快速恢复阶段，发送端重发在传输过程重丢失了的报文段，并把拥塞窗口减小一半。在SACK的快速恢复算法中，SACK保持了一个变量pipe用来表示当前在传输路径上的报文段的估计数量。在这一点上SACK与Reno的实现机制不同。当pipe小于拥塞窗口大小时，发送端只发送新的或已重发过的数据。当发送端发送一个新报文段或重发一个老报文段时，pipe值增l；
而当发送端接收了一个带SACK选项的重复AEK时，表明新数据己被接收者接收，pipe值减1。用pipe变量可将何时发送报文段和发送哪个报文段分离开来。
如果有一个重发的报文段丢失，SACK可以在重发定时器超时后察觉，从而重发丢失的报文段，然后再进入慢启动阶段。而在收到一个“恢复ACK”，确认了再进入快速恢复时出现的所有数据后，发送端就退出快速恢复阶段。另外，SACK发送端对在快速恢复阶段收到的“恢复ACK”还使用了特殊的处理方法：对这些ACK，发送端对pipe变量值每次减2，而不是减l。
5.6 TCP Vegas 1994年提出了Vegas算法。与前几种算法不同，Vegas是一种通过检测网络流量来避免拥塞的拥塞控制算法。Vegas的策略是调整信源的发送速率使得传输路径上的路由器中缓存少量的分组。它主要从三个方面对TEP拥塞控制基本机制进行了改进；
重传机制、拥塞避免机制和慢启动机制。
1．新的重传机制：
Vegas对Reno的重传机制做了以下扩充：首先，Vegas读取并记录每次报文段发送时的系统时钟。当一个 ACK到达时Vegas再次读取时钟，并用此时间与相应报文段记录的时间戳来计算RTT值。然后，Vegas用这个更精确的RTT估值来决定在下面两种情况下的重传：当收到一个重复的ACK时，Vegas就检测“当前时间一相应报文段的发送时间”的差值是否大于超时值，若大于超时值，发送端重传此报文而不需要等收到三个重复的ACK后才做出反应，所以能更及时的做出反应。同时也避免进入这样一种状态：发送端永远收不到三个重复的ACK。从而不得不依赖定时器的超时而进行重发。
当收到一个非重复的ACK时，如果这是重传之后收到的第一或第二个确认，Vegas就再次检测报文段发送后的时间间隔是否大于超时值，若大于超时值就重传此报文段，这样就会知道在早先重传之前可能丢失的其它的报文段，而不需要等待第一个重复的ACK到达才觉察。
2．改进的拥塞避免机制：
Vegas的目标是保持网络中恰当数量的额外数据。显然，如果一个连接发送过多额外数据会就导致拥塞，如果一个连接发送过少的额外数据，它就不能在有可用带宽的条件下快速的增加。Vegas的拥塞避免是基于网络中额外数据估计量的变化，而不是基于丢失报文的现象。其具体实现如下：
它定义了期望(expected)和实际(actual)吞吐量。期望吞吐量代表在没有也现网络拥塞的情况下此连接的可用带宽；
实际吞吐量代表此连接当前可用带宽。每收到一个ACK后，发送端按1式计算期望和实际吞吐量之间的差值diff：
其中，basertt为测得最小的RTT值：artt为平均测得的RTT值。Vegas定义了两个阈值α(触发窗口增加)和β(触发窗口减小)，目的是使发送端在一个RTT之内有效地控制diff的值，以 便使实际的吞吐量接近期望的吞吐量。在此阶段拥塞窗口的变化由下式决定。
Vegas通过以上方法控制网络出现拥塞，减小丢失率。
3．改进的慢启动机制：
为了在慢启动阶段可以检测和避免拥塞，Vegas做了以下改进：它采用了一种更谨慎的方法来增加窗口的大小，在一条链路建立之时，每经过两个RTT将窗口指数增加，在两个 RTT之间，cwnd保持不变从而可以对实际和期望速率进行有效的比较。当实际速率比期望的少一个缓存时，Vegas从慢启动模式变为线性增加/减小模式。此改进有效的减少了在慢启动阶段报文段丢失的发生。
结 论 综上所述，TCP协议以其安全可靠的传输特性在网络发展中占有重要位置，对其的研究也有很大的必要。随着高速网络的发展以及有线无线等多种网络的混合，传统TCP协议已经显示出了不少弊端，对于其在新型网络时代中的改进迫在眉睫，尤其是它的拥塞控制算法的改进对于提高TCP性能有很大帮助。
随着网络技术的不断发展，网络传输速率以及传输量的不断增加，对于TCP的未来趋势我们可以看出延时的测量将对TCP的性能产生越来越大的影响，通过硬件的加速来提高协议性能也是值得研究的方面。
致 谢 参考文献 附 录 译文1 Simulation-based Comparisons of Tahoe, Reno, and SACK TCP Kevin Fall and Sally Floyd In this paper we illustrate some of the benefits of adding selective acknowledgment (SACK) to TCP. Current implementations of TCP use an acknowledgment number field that contains a cumulative acknowledgment, indicating the TCP receiver has received all of the data up to the indicated byte. A selective acknowledgment option allows receivers to additionally report non-sequential data they have received. When coupled with a selective retransmission policy implemented in TCP senders, This work was supported by the Director, office of Energy Re-search, Scientific Computing Staff, of the U.S. Department of Energy under considerable savings can be achieved Several transport protocols have provided for selective acknowledgment (SACK) of received data. These include NETBLT , XTP, RDP and VMTP. The first proposals for adding SACK to TCP were later removed from the TCP RFCs (Request For Comments) pending further research. The cur-rent proposal for adding SACK to TCP is given in [MMFR96]. We use simulations to show how the SACK option define in [MMFR96] can be of substantial benefits relative to TCP without SACK. Without SACK, Reno TCP has performance problems when multiple packets are dropped from one window of data. These problems result from the need to await a retransmission timer expiration before re-initiating data flow. Situations in which this problem occurs are illustrated later in this paper. Not all of Reno＇s performance problems are a necessary consequence of the absence of SACK. To show why, we implemented a variant of the Reno algorithms in our simulator, called New-Reno. Using a suggestion from Janey Hoe, New-Reno avoids many of the retransmit timeouts of Reno without requiring SACK. Nevertheless, New-Reno does not perform as well as TCP with SACK when a large number of packets are dropped from a window of data. The purpose of our discussion of New-Reno is to clarify the fundamental limitations of the absence of SACK. In the absence of SACK, both Reno and New-Reno senders can retransmit at most one dropped packet per round-trip time, even if senders recover from multiple drops in a window of data without waiting for a retransmit timeout. This characteristic is not shared by Tahoe TCP, which is not limited to retransmitting at most one dropped packet per round-trip time. However, it is a fundamental consequence of the absence of SACK that the sender has to choose between the following strategies to recover from lost data: 1 retransmitting at most one dropped packet per round-trip time, or 2 retransmitting packets that might have already been successfully delivered. To illustrate the advantages of TCP with SACK, we show simulations with SACK TCP, using the SACK implementation in our simulator. SACK TCP is based on a conservative extension of the Reno congestion control algorithms with the addition of selective acknowledgments and selective retransmission. With SACK, a sender has a better idea of exactly which packets have been successfully delivered as compared with comparable protocols lacking SACK. Given such information, a sender can avoid unnecessary delays and retransmissions, resulting in improved throughput. We believe the addition of SACK to TCP is one of the most important changes that should be made to TCP at this time to improve its performance. In Sections 2 through 5 we describe the congestion control and packet retransmission algorithms in Tahoe, Reno, New-Reno, and SACK TCP. Section 6 shows simulations with Tahoe, Reno, New-Reno, and SACK TCP i n scenarios ranging from one to four packets dropped from a window of data. Section 7 shows a trace of Reno TCP taken from actual Internet traffic, showing that the performance problems of Reno without SACK are of more than theoretical interest. Finally, Section 8 discusses possible future directions for TCP with selective acknowledgments, and Section 9 gives conclusions. 基于重传的TCP仿真介绍 在这篇论文中，我们将介绍使用选择重发(sack)选项的TCP协议的益处，拥塞控制，算法一般分为两类：基于窗口的和基于位率的拥塞控制算法，基于窗口的控制算法是通过源端限制数据报的传送，并且不应答。这种机制在源端不需对发送的数据进行整形，它的优点在于易于实现，并对内在的由于限制最大量数据量所造成的不良影响能进行控制，然而，基于位率的控制算法，要对即将发送的流量进行整形，以防止爆发数据流的出现。这种算法的优点在于如果源端的传输率和网络匹配，那么就缩减了交换机所需的缓存区。
许多传输协议提供选择重传选项中描述的TCP快速恢复算法的典型实现，TCP数据发送端在发生一个超时重传时仅仅重传一个数据包，或者当三个重复确认到达时触发快速重传算法。单单一个超时重传可能导致许多 数据包的重传，但是每次Reno快速重传算法的启用仅仅导致一个数据包的重传。
因此，当多个数据包从一个数据窗口中丢失并且触发快速重传和快速恢复算法时，问题 就会产生。在这种情况下，如果SACK选项可用，TCP发送端在快速恢复期间就有足够的信 息来决定重传哪个数据包，不重传哪个数据包。这篇文档仅对不能使用TCP选择确认(SACK) 选项的TCP连接适用。
在没有SACK的情况下，TCP发送端在快速恢复期间只能得到很少的信息来作出重传决 定。从三个重复确认中，发送端推断出一个数据包丢失了，并且重传那个声明了数据包。在 这之后，数据发送端可能接收到另外的重复确认，因为在发送端进入快速重传时，数据端确 认已经发送的附加数据包。
在多个数据包从一个数据窗口中丢失这种情况下，当发送端从对重传的数据包(就是第 一次进入快速重传时重传的数据包)的一个确认时，它获得第一条可用新信息。如果只有一个数据包丢失了，对这个重传的数据包的确认将确认所有进入快速重传(在没有重新排序的 情况下)之前发送的数据包。但是，当有多个数据包丢失时，对此重传数据包的确认将确认一些而不是所有在快速重传之前发送的数据包。我们称这个包是一个部分确认。
和许多其它的建议一起，[Hoe95]建议在快速恢复期间TCP数据发送端通过推断声明的 数据包已 经丢失和重传那个数据包的方式响应一个部分确认。
为了说明使用选择重传(sack)TCP协议的好处，我们仿真了TCP SACK 使用网络仿真器。并且TCP SACK 是TCP Reno 的适当扩展。
解决拥塞是采用基于窗口的端到端的算法，以前主要有两种：Tahoe 和Reno。分别对通过重复应答者收到重复应答时，一律认为网络发生了拥塞，而Reno在收到重复的应答时却认为网络可能是暂时的而不是持久的拥塞，Reno可能导致在同一窗口中出现多个数据包被丢失的现象。Tahoe 包括慢启动、拥塞避免和快速重传等几个主要阶段。后来随着网络技术的发展，在Reno算法的基础上，出现了New Reno 算法。
译文2 The Algorithm of Congestion Control 1．Tahoe TCP Modern TCP implementations contain a number of algorithms aimed at controlling network congestion while maintaining good user throughput. Early TCP implementations followed a go-back-n. model using cumulative positive acknowledgment and requiring a retransmit timer expiration to re-send data lost during transport. These TCPs did little to minimize network congestion. The Tahoe TCP implementation added a number of new algorithms and refinements to earlier implementations. The new algorithms include Slow-Start, Congestion Avoidance, and Fast Retransmit. The refinements include a modification to the round-trip time estimator used to set retransmission timeout values. All modifications have been described elsewhere. The Fast Retransmit algorithm is of special interest in this paper because it is modified subsequent versions of TCP. With Fast Retransmit, after receiving a small number of duplicate acknowledgments for the same TCP segment (dup ACKs), the data sender infers that a packet has been lost and retransmits the packet without waiting for a retransmission timer to expire, leading to higher channel utilization and connection throughput. 2．Reno TCP The Reno TCP implementation retained the enhancements incorporated into Tahoe, but modified the Fast Retransmit operation to include Fast Recovery. The new algorithm prevents the communication path (“pipe”) from going empty after Fast Retransmit, thereby avoiding the need to Slow-Start to refill it after a single packet loss. Fast Recovery operates by assuming each dup ACK received represents a single packet having left the pipe. Thus, during Fast Recovery the TCP sender is able to make intelligent estimates of the amou nt of outstanding data. In Reno, the sender＇s usable window becomes other gateways that fail to monitor the average queue size) until the number of dup ACKs reaches tcprexmtthresh, and thereafter tracks the number of duplicate ACKs. Thus, during Fast Recovery the sender “inflate” its window by the number of dup ACKs it has received, according to the observation that each dup ACK indicates some packet has been removed from the network and is now cached at the receiver. After entering Fast Recovery and retransmitting a single packet, the sender effectively waits until half a window of dup ACKs have been received, and then sends a new packet for each additional dup ACK that is received. 3．New-Reno TCP We include New-Reno TCP in this paper to show how a simple change to TCP makes it possible to avoid some of the performance problems of Reno TCP without the addition of SACK. At the same time, we use New-Reno TCP to explore the fundamental limitations of TCP performance in the absence of SACK. The New-Reno TCP in this paper includes a small change to the Reno algorithm at the sender that eliminates Reno＇s wait for a retransmit timer when multiple packets are lost from a window. The change concerns the sender＇s behavior during Fast Recovery when a partial ACK is received that acknowledges some but not all of the packets that were out-standing at the start of that Fast Recovery period. In Reno, partial ACKs take TCP out of Fast Recovery by “deflating” the usable window back to the size of the congestion window. In New-Reno, partial ACKs do not take TCP out of Fast Recovery. Instead, partial ACKs received during Fast Recovery are treated as an indication that the packet immediately following the acknowledged packet in the sequence space has been lost, and should be retransmitted. Thus, when multiple packets are lost from a single window of data, New-Reno can recover without a retransmission timeout, retransmitting one lost packet per round-trip time until all of the lost packets from that window have been retransmitted. New-Reno remains in Fast Recovery until all of the data outstanding when Fast Recovery was initiated has been acknowledged. The implementations of New-Reno and SACK TCP in our simulator also use a “maxburst” parameter. In our SACK TCP implementation, the “maxburst” parameter limits to four the number of packets that can be sent in response to a single incoming ACK, even if the sender＇s congestion window would allow more packets to be sent. In New-Reno, the “maxburst” parameter is set to four packets outs ide of Fast Recovery, and to two packets during Fast Recovery, to more closely reproduce the behavior of Reno TCP during Fast Recovery. The “maxburst” parameter is really only needed for the first window of packets that are sent after leaving Fast Recovery. If the sender had been prevented by the receiver＇s advertised window from sending packets during Fast Recovery, then, without “maxburst” , it is possible for the sender to send a large burst of packets upon exiting Fast Recovery. This applies to Reno and New-Reno TCP, and to a lesser extent, to SACK TCP. In Tahoe TCP the Slow-Start algorithm prevents bursts after recovering from a packet loss. The bursts of packets upon exiting Fast Recovery with New-Reno TCP are illustrated in Section 6 in the simulations with three and four packet drops. Bursts of packets upon exiting Fast Recovery with Reno TCP are illustrated in. 4．SACK TCP The SACK option follows the format in [MMFR96]. From [MMFR96], the SACK option field contains a number of SACK blocks, where each SACK block reports a non-contiguous set of data that has been received and queued. The first block in a SACK option is required to report the data receiver＇s most recently received segment, and the additional SACK blocks repeat the most recently reported SACK blocks [MMFR96]. In these simulations each SACK option is assumed to have room for three SACK blocks. When the SACK option is used with the Timestamp option specified for TCP Extensions for High Performance, then the SACK option has room for only three SACK blocks [MMFR96]. If the SACK option were to be used with both the Timestamp option and with T/TCP (TCP Extensions for Transactions), the TCP option space would have room for only two SACK blocks. The 1990 “Sack” TCP implementation on our previous simulator is from Steven McCanne and Sally Floyd, and does not conform to the formats in [MMFR96]. The new “Sack1”implementation contains major contributions from Kevin Fall, Jamshid Mahdavi, and Matt Mathis. The congestion control algorithms implemented in our SACK TCP are a conservative extension of Reno＇s congestion control, in that they use the same algorithms for increasing and decreasing the congestion window, The SACK TCP implementation in this paper, called “Sack1”in our simulator, is also discussed in. and make minimal changes to the other congestion con-trol algorithms. Adding SACK to TCP does not change the basic underlying congestion control algorithms. The SACK TCP implementation preserves the properties of Tahoe and Reno TCP of being robust in the presence of out-of-order packets, and uses retransmit timeouts as the recovery method of last resort. The main difference between the SACK TCP implementation and the Reno TCP implementation is in the behavior when multiple packets are dropped from one window of data. 拥塞控制中的算法 1．Tahoe TCP TCP Tahoe指的是1988年加入Van Jacobson提出的慢启动、拥塞避免和快速重传算法之后的4.3BSD或类似的TCP实现版本。正如RFC793所要求的，Tahoe采用了递增式肯定重传策略和“go-back-n“模型(滑动窗口算法)。在慢启动阶段，拥塞窗口(cwnd)随着确认的到来以指数方式递增(这种以ACK来触发TRANSMIT的机制，被VJ称为“ACK clocking“，或“self-clocking“)，直到到达阀值ssthresh(slow start threshold)；
之后TCP进入拥塞避免阶段，cwnd每隔RTT以线性方式递增1个单位。如果连续收到3个重复确认，TCP不等重传定时器溢出，马上重传丢失的报文段，这称为快速重传；
之后TCP返回慢启动状态。早期的TCP实现算法是基于积极响应并通过重传来重发丢失的数据，当丢包时，TCP减小拥塞窗口，并重传被丢失的分组，然而在使用网络拥塞达到最小方面，这些算法的性能很差。TCP Tahoe 参考了早期的实现方法，并增加一些算法，包括慢启动：窗口大小以指数速度增加；
拥塞避免：窗口的大小以一个线形速度增加；
快速重传：从一个丢包的状态恢复而不需要等待重传定时器的超时。Tahoe 还包括对往返时间估计量的修改，这一参数的准确估计是非常重要的，因为它被用来设置重传超时定时器的基值，此外，Tahoe引入快速重传机制，即当接受者收到几个对同一TCP报文的相同应答时，发送方就推断已经发生了丢包，而没有必要的等到重传定时器超时，并且重传相应的包，提高了信道的利用率。
2．Reno TCP TCP Reno在快速重传之后进入快速恢复(而不是TCP Tahoe采用的慢启动)。VJ给出的原因是，接收方发送重复确认不仅仅意味着有报文段丢失了，还意味着有(其它的)报文段离开了网络，到达了接收方的缓冲区(self-clocking)，也就是说，网络“管道”空出了新的位置，这样TCP可以继续发送新的报文段(当然cwnd应该减小一些)。另一个不进入慢启动的原因是，dup ACKs的到达已经使得发送方的确认“时钟”得到了同步。快速重传和快速恢复通常一起实现：1. 收到第3个重复确认之后，令 ssthresh = max(FlightSize/2，2*SMSS)；
2. 重传丢失的报文段，并令cwnd = ssthresh +3；
3. 对每个dupACK，cwnd += SMSS，此时，窗口大小允许的话发送一个报文段；
4. 当确认了新数据的ACK到达时，令cwnd=ssthresh，即进入拥塞避免状态。
TCP Reno在一个窗口中的多个报文段同时丢失的情况下会出现性能问题，因为此时引起TCP退出快速恢复的“确认了新数据的ACK”没有确认进入快速重传之前丢失的所有报文段。其它丢失的报文段会使得TCP不断执行快速重传和快速恢复，而cwnd和ssthresh亦会多次被减半，大大降低了吞吐量。
Reno修改了Tahoe的快速重传为快速恢复(指由三个重复的应答判断有包丢失时，仅使窗口值减半)新的算法防止通信管道在快速重传之后变为空，因而避免了慢启动在单包丢失之重填。快速重传主要决定于收到的重复应答数目的初始门限值，一旦达到了门限值，发送方就重传一个数据包，同时使拥塞窗口减半，与Tahoe的慢启动不同，Reno的发送方用额外到达的应答来为后续包定时。发送方的可用窗口变为发送窗口与拥塞窗口的最小值，因而在快速恢复中，发送方根据收到的重复的应答来变动自己的窗口。相应地，每个重复应答表示有一些包已被移出网络，并且现在已经到达接收方。在进入快速恢复阶段并重发一个数据包后，对应每一个额外重复地应答传出一个新包，当接受到新数据地应答时，发送方退出快速恢复阶段并设置Ndup为0。
Reno的理想情况是在一个窗口中单包丢失时，Reno 发送方在每一个往返时间中最多重传一个包，但是它在同一个窗口中出现多包丢失时可能出现的问题。
3．New Reno TCP TCP NewReno修改了TCP Reno的快速恢复算法，以处理一个窗口中的多个报文段同时丢失时出现的“部分确认”(partial ACKs，它在快速恢复阶段到达并且确认了新数据，但它只确认了进入快速重传之前发送的一部分数据)。在这种情况下，TCP Reno会退出快速恢复状态，等待重传定时器溢出或者dup ACKs的到达，但是TCP NewReno并不退出快速恢复状态，而是 (1)重传紧接着那个partial ACK之后的报文段，(2)cwnd-=partial ACK确认的新数据，cwnd+=SMSS，(3)对第一个(另一个建议是每一个)partial ACK，复位重传定时器。
New Reno 做了一个变化，即当多包丢弃时，去掉了Reno的等待重传定时器，在快速恢复的阶段，当发送端收到一个部分应答来表征一些包而不是所有包，在这个阶段的起始时间没有被成功传送。在Reno中，部分包通过减少可用窗口至拥塞窗口大小以使TCP退出快速恢复。在New Reno 中，部分应答的包已经丢失，需要重传。New Reno 的恢复不需要重传超时，每个往返时间重传一个包直到所有的数据包被传完。New Reno 保持在快速恢复状态，直到在快速恢复阶段初始化未被成功传送的数据全被响应。
4．SACK TCP 前面这几种算法，在单包丢弃时，效果是不错的，但如果在同一个窗口下同一个数据窗口下，它们的性能都有比较大的局限性。后来出现了基于选择应答(sack)的算法，它较好的解决了在同一个数据包丢失的问题，这种算法的基本原理是这样的：SACK算法中，有一个称作选择域(option)的数据段：SACK的选择域的数据段，ACK中的SACK域包含一定数量的SACK块，每一个SACK块都记录了信宿端接收或缓存的非连续分组。SACK块的多少因应用和需要的不同而有所不同。与Reno相似，当发送端收到prexmtthresh个重复的ACK时，重发丢失的分组，并将拥塞窗口减半，进入快速恢复过程。期间，SACK维护了一个称为“pipe”的变量用来估计出现在网络中的分组数。当“pipe”小于拥塞窗口的大小时，发送端发送新的或需要重发的分组，并将变量“pipe”加一。当发送端接收了一个带SACK选项的重复ACK，表明新分组已被接收端接收，pipe变量减一。Pipe变量的使用将何时发送与发送哪一个分组有效的解偶。当发送端被许可发送分组时，依次将发送丢失列表中记录的分组。如果没有这样的分组，而接收端的通报窗口又足够大，则发送端将发出新的数据分组。
当重传分组本身被丢弃后，SACK用重传超时来探测丢失，再次重传后进入慢启动过程，在确认了所有出现在进入快速恢复阶段的分组后，发送端将从快速恢复中退出。TCP SACK 与TCP Reno最主要的区别是在多个数据包丢失的情况下进行拥塞避免的方式的不同。