TCP协议采取了哪些机制来进行拥塞控制

最初的TCP协议只有基于窗口的流控制（flow control）机制而没有拥塞控制机制，流控制是一种局部控制机制，其参与者仅仅是发送方和接收方，它只考虑了接收端的接收能力，而没有考虑到网络的传输能力；而拥塞控制则注重于整体，其考虑的是整个网络的传输能力，是一种全局控制机制。 拥塞控制机制使得TCP连接在网络发生拥塞时回退（back off），也就是说TCP源端会对网络发出的拥塞指示（congestion notification）（例如丢包、重复的ACK等）作出响应。 针对TCP在控制网络拥塞方面的不足，后来又提出了“慢启动”（Slow Start）和“拥塞避免”（Congestion Avoidance）算法。 TCP Reno版本增加了“快速重传 ”（Fast Retransmit）、“快速恢复”（Fast Recovery）算法，避免了网络拥塞不严重时采用“慢启动”算法而造成过大地减小发送窗口尺寸的现象，这样TCP的拥塞控制就由这4个核心部分组成。 近几年又出现TCP的改进版本如NewReno和选择性应答（selective acknowledgement，SACK）等。

拥塞控制与流量控制两者之间由3点不同，相关介绍具体如下：

一、两者的特点不同：

1、拥塞控制的特点：拥塞控制基 于 终端的资源控制仅需设定一条规则，即可限定每台终端的带宽使用上限，同时可以设定每台终端的会话数量，防止由一病毒等原囚造成的网络资源耗尽。

2、流量控制的特点：流量控制基于内容进行会话识别可以通过高速的深层协议分析，识别每一个网络会话所属的应用，可以针对某种协议进行拦截或者制定相应的带宽分配策略，而传统的路由器和防火墙等网络设备只能根据端口进行最初级的识别。

二、两者的主要方法不同：

1、拥塞控制的主要方法：拥塞控制的主要控制方法有缓冲区域分配法、分组丢弃法、定额控制法。

2、流量控制的主要方法：流量控制的最主要方法，是引入QoS的概念，从通过为不同类型的网络数据包标记，从而决定数据包通行的优先次序。

三、两者的实质不同：

1、拥塞控制的实质：到达通信子网中某一部分的分组数量过多，使得该部分网络来不及处理，以致引起这部分乃至整个网络性能下降的现象，严重时甚至会导致网络通信业务陷入停顿，即出现死锁现象。

2、流量控制的实质：一种利用软件或硬件方式来实现对电脑网络流量的控制。用于控制调制解调器与计算机之间的数据流，具有防止因为计算机和调制解调器之间通信处理速度的不匹配而引起的数据丢失。

参考资料来源：百度百科-拥塞控制

参考资料来源：百度百科-流量控制

tcp_conn_v3模块是基于TCP的拥塞控制
基于TCP的拥塞控制可参考下面的链接
>基于包丢失检测的 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

这两个算法是根据其第一次加入到43BSD的时间回溯命名的，两个名字对应自其第一次出现时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内核在268至2618使用该算法作为默认TCP拥塞算法。

CUBIC则是比BIC更温和和系统化的分支版本，其使用三次函数代替二分算法作为其拥塞窗口算法，并且使用函数拐点作为拥塞窗口的设置值。Linux内核在2619后使用该算法作为默认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 Reduction ）是旨在恢复期间提高发送数据的准确性。该算法确保恢复后的拥塞窗口大小尽可能接近慢启动阈值。在Google进行的测试中，能将平均延迟降低3~10%，恢复的超时减少5%。PRR算法之后作为Linux内核32版本的默认拥塞算法

TCP BBR

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

QUIC Quick UDP Internet Connections

QUIC旨在提供几乎等同于TCP连接的可靠性，但延迟大大减少。它主要通过两个理解>流量控制和拥塞控制的区别
TCP的流量控制和拥塞控制看上去是两个比较相近的概念，容易产生混淆。但事实上，他们在期望的目标和使用的方法是完全不同的。
流量控制解决的是发送方和接收方速率不匹配的问题，发送方发送过快接收方就来不及接收和处理。采用的机制是滑动窗口的机制，控制的是发送了但未被Ack的包数量。
拥塞控制解决的是避免网络资源被耗尽的问题，通过大家自律的采取避让的措施，来避免网络有限资源被耗尽。当出现丢包时，控制发送的速率达到降低网络负载的目的。
流量控制
流量控制是通过滑动窗口来实现的。 滑动窗口分为发送端窗口和接收端窗口。
窗口有大小限制，窗口大小是接收端用来告诉发送端目前接收端能接收的最大字节数。
窗口的大小在TCP协议头里，大小为16位。然而在TCP协议的可选项里，还可以定义窗口的比例因子，因此实际的窗口大小可以超过64KB。窗口的含义实际上就是接收缓冲区的大小。
发送窗口维护了发送端发送的已被接收端ACK的序号，以及已经发送的最大序号，这样就可以知道还能发送多少的新数据。
接收窗口维护了已经ACK的序号，以及所有接收到的包序号。
窗口大小在特定的一次连接通信过程中，大小是不变的。而滑动窗口是一种机制，滑动窗口的大小在发送端代表的是可发送的数据大小，在接收端代表的是可接收的数据大小，它们是动态变化的。
拥塞控制
拥塞控制是通过拥塞窗口来实现的。拥塞窗口指发送端在一个RTT内可以最多发送的数据包数。
拥塞控制一般包括慢启动、拥塞避免两个阶段。
慢启动阶段是从1开始指数增长到限定大小的过程。
拥塞避免阶段时超过限定大小之后线性增加的过程，以及发现丢包后将拥塞窗口改为1，并把限定大小减半的过程。
扩展资料
流量控制是端到端的控制，例如A通过网络给B发数据，A发送的太快导致B没法接收(B缓冲窗口过小或者处理过慢)，这时候的控制就是流量控制，原理是通过滑动窗口的大小改变来实现。
拥塞控制是A与B之间的网络发生堵塞导致传输过慢或者丢包，来不及传输。防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不至于过载。拥塞控制是一个全局性的过程，涉及到所有的主机、路由器，以及与降低网络性能有关的所有因素。

---