控制拥塞算法

Ⅰ 拥塞算法

基于包丢失检测的 Reno、NewReno 或者 cubic 为代表，其主要问题有 Buffer bloat 和长肥管道两种。和这些算法不同，bbr 算法会以时间窗口内的最大带宽 max_bw 和最小 RTT min_rtt，并以此计算发送速率和拥塞窗口

RTProp : round-trip propagation time BtlBW : bottleneck bandwidth，bbr 算法关于拥塞窗口的核心就是计算 BtlBW 和 RTprop，根据这两者值计算 BDP

bbr 算法输出 pacing_rate 和 cwnd 两个数据。pacing_rate 决定发包速率，cwnd 为窗口大小

TCP Tahoe 和 Reno

这两个算法是根据其第一次加入到4.3BSD的时间回溯命名的，两个名字对应自其第一次出现时BSD的代号，而代号分别取自太浩湖（Lake Tahoe）和其附近的城市里诺市

• Tahoe：如果收到三次重复确认——即第四次收到相同确认号的分段确认，并且分段对应包无负载分段和无改变接收窗口——的话，Tahoe算法则进入快速重传，将慢启动阈值改为当前拥塞窗口的一半，将拥塞窗口降为1个MSS，并重新进入慢启动阶段

• Reno：如果收到三次重复确认，Reno算法则进入快速重传，只将拥塞窗口减半来跳过慢启动阶段，将慢启动阈值设为当前新的拥塞窗口值，进入一个称为“快速恢复”的新设计阶段

Fast recovery

是Reno算法新引入的一个阶段，在将丢失的分段重传后，启动一个超时定时器，并等待该丢失分段包的分段确认后，再进入拥塞控制阶段。如果仍然超时，则回到慢启动阶段

TCP Vegas

至1990年代中期，TCP量度延迟和RTT都是以传输缓存中最后一个被传送的分段包为准。vegas通过度量传输缓存中每个传送分段包来代替只量度一个分段包，通过每次度量的平均值来增加拥塞窗口。该算法取名自内华达州最大的城市拉斯维加斯。不过由于一些资源公平性原因，该算法并没有在彼得森的实验室之外广泛部署。一些研究认为该算法和其他拥塞算法混合使用，可能会导致性能竞争不及其他算法。在各种TCP拥塞算法的比较研究中，Vegas被认为是最平滑的控制算法，其次为CUBIC

TCP New Reno

TCP New Reno是对TCP Reno中快速恢复阶段的重传进行改善的一种改进算法，其定义于RFC 6582，覆盖了原有在RFC 3782和RFC 2582的旧定义。

在Reno的快速恢复中，一旦出现3次重复确认，TCP发送方会重发重复确认对应序列号的分段并设置定时器等待该重发分段包的分段确认包，当该分段确认包收到后，就立即退出快速恢复阶段，进入拥塞控制阶段，但如果某个导致重复确认的分段包到遇到重复确认期间所发送的分段包存在多个丢失的话，则这些丢失只能等待超时重发，并且导致拥塞窗口多次进入拥塞控制阶段而多次下降。而New Reno的快速恢复中，一旦出现3次重复确认，TCP发送方先记下3次重复确认时已发送但未确认的分段的最大序列号，然后重发重复确认对应序列号的分段包。如果只有该重复确认的分段丢失，则接收方接收该重发分段包后，会立即返回最大序列号的分段确认包，从而完成重发；但如果重复确认期间的发送包有多个丢失，接收方在接收该重发分段后，会返回非最大序列号的分段确认包，从而发送方继续保持重发这些丢失的分段，直到最大序列号的分段确认包的返回，才退出快速恢复阶段。

New Reno在低错误率时运行效率和“选择确认”（Selective ACKnowledgement，SACK）相当，在高错误率仍优于Reno

TCP Hybla

TCP Hybla旨在消除由于高延迟地面线路或者卫星无线链路下导致的RTT过长而对TCP链接的影响。它通过对拥塞窗口动态分析来修改，来减少对RTT的性能依赖

TCP BIC 和 CUBIC

TCP BIC（Binary Increase Congestion control）旨在优化高速高延迟网络（即根据RFC 1072所定义的“长肥网络”（long fat network，LFN））的拥塞控制，其拥塞窗口算法使用二分搜索算法尝试找到能长时间保持拥塞窗口最大值的值。Linux内核在2.6.8至2.6.18使用该算法作为默认TCP拥塞算法。

CUBIC则是比BIC更温和和系统化的分支版本，其使用三次函数代替二分算法作为其拥塞窗口算法，并且使用函数拐点作为拥塞窗口的设置值。Linux内核在2.6.19后使用该算法作为默认TCP拥塞算法

TCP Westwood和Westwood+

TCP Westwood改良自New Reno，不同于以往其他拥塞控制算法使用丢失来测量，其通过对确认包测量来确定一个“合适的发送速度”，并以此调整拥塞窗口和慢启动阈值。其改良了慢启动阶段算法为“敏捷探测（Agile Probing）”，和设计了一种持续探测拥塞窗口的方法来控制进入“敏捷探测”，使链接尽可能地使用更多的带宽。Westwood+使用更长的带宽估计间隔和优化的滤波器来修正Westwood对ACK压缩场景对带宽估计过高的问题。通过以上改良，TCP Westwood系列算法在有线网络和无线网络的拥塞控制上获取平衡，尤其研究中针对于无线通信网络上

Compound TCP

复合TCP（Compound TCP）是微软自己实现的TCP拥塞控制算法，通过同时维护两个拥塞窗口，来实现在长肥网络有较好的性能而又不损失公平性。该算法在Windows Vista和Windows Server 2008开始广泛部署，并通过补丁的方式回溯支持到Windows XP和Windows Server 2003。在Linux上也有一个旧版本的移植实现

TCP PRR

TCP PRR（TCP Proportional Rate Rection ）是旨在恢复期间提高发送数据的准确性。该算法确保恢复后的拥塞窗口大小尽可能接近慢启动阈值。在Google进行的测试中，能将平均延迟降低3~10%，恢复的超时减少5%。PRR算法之后作为Linux内核3.2版本的默认拥塞算法

TCP BBR

TCP BBR（Bottleneck Bandwidth and Round-trip propagation time）是由Google设计，于2016年发布的拥塞算法。以往大部分拥塞算法是基于丢包来作为降低传输速率的信号，而BBR则基于模型主动探测。该算法使用网络最近出站数据分组当时的最大带宽和往返时间来创建网络的显式模型。数据包传输的每个累积或选择性确认用于生成记录在数据包传输过程和确认返回期间的时间内所传送数据量的采样率。该算法认为随着网络接口控制器逐渐进入千兆速度时，与缓冲膨胀相关的延迟相比丢包更应该被认为是识别拥塞的主要决定因素，所以基于延迟模型的拥塞控制算法（如BBR）会有更高的吞吐量和更低的延迟，可以用BBR来替代其他流行的拥塞算法，例如CUBIC

QUIC Quick UDP Internet Connections

QUIC旨在提供几乎等同于TCP连接的可靠性，但延迟大大减少。它主要通过两个理解HTTP流量的行为来实现这一点：

第一个变化是在连接创建期间大大减少开销。由于大多数HTTP连接都需要TLS，因此QUIC使协商密钥和支持的协议成为初始握手过程的一部分。 当客户端打开连接时，服务器响应的数据包包括将来的数据包加密所需的数据。

QUIC使用UDP协议作为其基础，不包括丢失恢复。相反，每个QUIC流是单独控制的，并且在QUIC级别而不是UDP级别重传丢失的数据。这意味着如果在一个流中发生错误，协议栈仍然可以独立地继续为其他流提供服务

QUIC包括许多其他更普通的更改，这些更改也可以优化整体延迟和吞吐量

每个数据包是单独加密的，因此加密数据时不需要等待部分数据包。 在TCP下通常不可能这样做，其中加密记录在字节流中，并且协议栈不知道该流中的更高层边界。这些可以由运行在更上层的协议进行协商，但QUIC旨在通过单个握手过程完成这些

QUIC的另一个目标是提高网络切换期间的性能，例如当移动设备的用户从WiFi热点切换到移动网络时发生的情况。 当这发生在TCP上时，一个冗长的过程开始了：每个现有连接一个接一个地超时，然后根据需要重新创建。期间存在较高延迟，因为新连接需要等待旧连接超时后才会创建。 为解决此问题，QUIC包含一个连接标识符，该标识符唯一地标识客户端与服务器之间的连接，而无论源IP地址是什么。这样只需发送一个包含此ID的数据包即可重新创建连接，因为即使用户的IP地址发生变化，原始连接ID仍然有效

QUIC在应用程序空间中实现，而不是在操作系统内核中实现。当数据在应用程序之间移动时，这通常会由于上下文切换而调用额外的开销。 但是在QUIC下协议栈旨在由单个应用程序使用，每个应用程序使用QUIC在UDP上托管自己的连接

Chromium的网络堆栈同时打开QUIC和传统TCP连接，并在QUIC连接失败时以零延迟回退到TCP连接

Ⅱ tcp拥塞控制算法包括

拥塞控制的算法有：慢开始、拥塞避免、快重传、快恢复。
慢开始和拥塞避免发送方维持一个拥塞窗口的状态变量，其大小取决于网络的拥塞程度，动态地变化，而发送窗口一般取拥塞窗口和对方给出的接收窗口之间的最小值。慢开始算法的核心是从小到大逐渐增大拥塞窗口的数值。

Ⅲ tcp如何实现拥塞控制

TCP拥塞控制是传输控制协议（英语：Transmission Control Protocol，缩写TCP）避免网络拥塞的算法，是互联网上主要的一个拥塞控制措施。它使用一套基于线增积减模式的多样化网络拥塞控制方法（包括慢启动和拥塞窗口等模式）来控制拥塞。在互联网上应用中有相当多的具体实现算法。

在TCP中，拥塞窗口（congestion window）是任何时刻内确定能被发送出去的字节数的控制因素之一，是阻止发送方至接收方之间的链路变得拥塞的手段。他是由发送方维护，通过估计链路的拥塞程度计算出来的，与由接收方维护的接收窗口大小并不冲突。

1、慢开始算法：

简单的说，开始传输时，传输的数据由小到大递增到一个值(即发送窗口由小到大(指数增长)逐渐增大到拥塞窗口的数值)。

2、拥塞避免算法：

数据发送出去，并发到接收方发回来的确认收到，拥塞窗口每次值加1地线性增大。

3、快重传算法：

数据传输时(数据被分成报文，每个报文都有个序号)，中间的一部分丢失接收方没收到，接收方连续接到后面的数据，则发回对丢失前的数据的重复确认，这样发送方就知道有部分数据丢失了，于是从丢失出重传数据。

4、快恢复算法：

快恢复是与快重传配合的算法，在发生数据丢失时，发送方收到接收方发回的三个重复确认信息时，就把每次传输的数据量减为原来的一半，拥塞窗口也修改为这个值,然后又开始拥塞避免的算法。

Ⅳ tcp拥塞控制常用算法

tcp拥塞控制常用算法方法如下
TCP协议有两个比较重要的控制算法，一个是流量控制，另一个就是阻塞控制。TCP协议通过滑动窗口来进行流量控制，它是控制发送方的发送速度从而使接受者来得及接收并处理。而拥塞控制是作用于网络，它是防止过多的包被发送到网络中，避免出现网络负载过大，网络拥塞的情况。拥塞算法需要掌握其状态机和四种算法。拥塞控制状态机的状态有五种，分别是Open，Disorder，CWR，Recovery和Loss状态。四个算法为慢启动，拥塞避免，拥塞发生时算法和快速恢复。和TCP一样，拥塞控制算法也有其状态机。当发送方收到一个Ack时，LinuxTCP通过状态机(state)来决定其接下来的行为，是应该降低拥塞窗口cwnd大小，或者保持cwnd不变，还是继续增加cwnd。

Ⅳ TCP拥塞控制

  在计算机网络中的链路容量（即带宽）、交换节点（如路由器）中的缓存和处理机等，都是网络的资源。在某段时间内，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏，从而导致吞吐量将随着输入负荷增大而降低。这种情况就叫做 拥塞 。通俗来说，就跟交通拥堵性质一样。

  网络拥塞的原因有很多，如交换节点的 缓存容量太小、输出链路的容量和处理机的速度 。

   拥塞控制就是防止过多的数据注入网络中，这样可以使网络中的路由器或链路不致于过载 。拥塞控制是一个 全局性的过程 。涉及网络中所有的主机、所有的路由器，以及与降低网络传输性能有关的所有因素。

  拥塞控制和流量控制的关系密切，但是 流量控制往往是指点对点的通信量控制 ，是个 端对端 的问题。流量控制所要做的就是抑制发送方发送数据的速率，以便使接收端来得及接收。

  TCP进行拥塞控制的算法有四种，即 慢开始（slow-start）、拥塞避免（congestion-avoidance）、快重传（fast retransmit）、快恢复（fast recovery） 。

  为了讨论问题方便，提出以下假定：

  拥塞控制也叫做 基于窗口 的拥塞控制。为此，发送方维持一个叫作 拥塞窗口cwnd （congestion window）的状态变量。 拥塞窗口的大小取决于网络的用谁程度，并且动态的变化。发送方让自己的发送窗口等于拥塞窗口 。

  接收方窗口值rwnd和拥塞窗口值cwnd的区别：

  发送方控制拥塞窗口的原则是：只要网络没有出现拥塞，拥塞窗口就可以再扩大一些，以便让更多的分组发送出去，如果网络出现了拥塞，就必须将拥塞窗口减小一些，以减少分组的发送。 判断网络拥塞的依据就是出现了超时 。

  慢开始算法的思路：刚开始发送数据时，不一下向网络中注入大量数据，而是先探测一下，即 由小到大逐渐增大发送窗口 ，也就是说， 由小到大逐渐增大拥塞窗口数值 。

  慢开始算法具体规定：刚开始发送数据时，先把拥塞窗口cwnd根据 发送方的最大报文段SMSS （Sender Maximum Segment Size）数值的大小设置为不超过2-4个SMSS的数值。在 每收到一个对新的报文段的确认后，可以把拥塞窗口增加最多一个SMSS的数值 。用这样的方法逐步增大发送方的拥塞窗口rwnd，可以使分组注入到网络中的速率更加合理。

  下面举例说明一下，虽然实际上TCP是用字节数作为窗口大小的单位，但为了方便描述，下面使用报文段的个数来作为窗口的大小的单位，并且假设所有的报文段大小相等。

  所以， 慢开始算法每经过一个传输轮次（transmission round），拥塞窗口cwnd就加倍 。

  注：在TCP实际运行时，发送方只有收到一个确认就可以将cwnd加1并发送新的分组，并不需要等一个轮次所有的确认都收到后再发送新的分组。

  从上面可以看出，慢开始算法虽然起始的窗口很小，但是每过一个轮次，窗口大小翻倍，呈指数爆炸增长，所以必须要对其进行一个限制，防止其增长过大引起网络拥塞。这个限制就是 慢开始门限ssthresh 状态变量。慢开始门限ssthresh的用法如下：

  拥塞避免算法的思路是让拥塞窗口cwnd缓慢增大，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是像慢开始阶段那样加倍增长。因此在拥塞避免阶段就有 “加法增大”AI （Additive Increase）的特点。这表明在拥塞避免阶段，拥塞窗口cwnd 按线性规律增长 ，比慢开始算法的拥塞窗口增长速率缓慢得多。

  下面用一个具体的例子来说明拥塞控制的过程，下图假设TCP发送窗口等于拥塞窗口，慢开始初始门限设置为16个报文段，即ssthresh = 16。

  在拥塞避免阶段，拥塞窗口是按照线性规律增大的，这常称为 加法增大AI 。无论在慢开始阶段还是拥塞避免阶段，只要出现一次超时（即出现一次网络拥塞），就把慢开始门限值 ssthresh 设置为当前拥塞窗口的一半，这叫做 乘法减小 MD （Multiplication Decrease）。

  当网络频繁出现拥塞时，ssthresh 值就下降的很快，以大大减少注入网络中的分组数。

   快恢复算法 ，如果发送方连续接收到3个冗余ACK，发送方知道现在只是丢失了个别的报文段，此时调整门限值 ssthresh为当前拥塞窗口的一半，同时设置拥塞窗口 cwnd为新的门限值（发生报文段丢失时拥塞窗口的一半），而不是从1开始。

   TCP对这种丢包事件的行为，相比于超时指示的丢包，不那么剧烈 ，所以对于连续收到3个冗余ACK，拥塞窗口不会从1开始开始。

Ⅵ 简述拥塞控制的四种基本算法

慢开始,拥塞避免,快重传,快恢复.
首先要明白什么TCP协议可靠传输,还有什么是拥塞窗口:表示当前发送数据的上限,但是它会根据网络好坏状况动态改变.
慢开始:简单的说,开始传输时,传输的数据由小到大递增到一个值(即发送窗口由小到大(指数增长)逐渐增大到拥塞窗口的数值).
拥塞避免:数据发送出去,并发到接收方发回来的确认收到,拥塞窗口每次值加1地线性增大.
快重传:数据传输时(数据被分成报文,每个报文都有个序号),中间的一部分丢失接收方没收到,接收方连续接到后面的数据,则发回对丢失前的数据的重复确认,这样发送方就知道有部分数据丢失了,于是从丢失出重传数据.
快恢复:快恢复是与快重传配合的算法,在发生数据丢失时,发送方收到接收方发回的三个重复确认信息时,就把每次传输的数据量减为原来的一半,拥塞窗口也修改为这个值,然后又开始拥塞避免的算法.