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 Reduction ）是旨在恢复期间提高发送数据的准确性。该算法确保恢复后的拥塞窗口大小尽可能接近慢启动阈值。在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连接
CUBIC是当前TCP标准的扩展。它与现有的TCP标准仅在发送方的拥塞控制算法上有所不同。特别地，它采用了三次函数代替了现有TCP标准中的线性窗口增加函数，提高了在高速长距离网络环境下的可扩展性和稳定性。CUBIC及其前身的算法已经被Linux作为默认算法使用了很多年。本文档提供了CUBIC的规范，以支持第三方实现，并通过对CUBIC性能的实验来征求社区反馈。
本文件不是互联网标准跟踪规范；它是为了提供信息而出版的。
本文档是Internet工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经收到了公众的审查，并已批准出版的互联网工程指导小组（IESG）。并非所有IESG批准的文件都适用于任何级别的互联网标准；见RFC 7841第2节。
有关本文件的当前状态、任何勘误表以及如何提供反馈的信息，请访问 https://www.rfc-editor.org/info/rfc8312 .
TCP在快速长距离网络中的低利用率问题在[K03]和[RFC3649]中有很好的描述。这个问题产生于在具有大带宽延迟积（BDP）的网络中，拥塞事件之后拥塞窗口的缓慢增加，在 [HKLRX06] 指出，即使在数百个数据包的拥塞窗口大小范围内，也经常观察到这个问题。这个问题同样适用于所有 Reno 风格的TCP标准及其变体，包括TCP-Reno[RFC5681]、TCP-NewReno[RFC6582][RFC6675]、SCTP[RFC4960]和TFRC[RFC5348]，它们使用相同的线性增加函数进行窗口增长，我们在下文中将它们统称为“标准TCP”（Standard TCP）。
CUBIC最初是在 [HRX08] 中提出的，它是对标准TCP拥塞控制算法的一种改进。本文档描述了CUBIC的最新规范。具体来说，CUBIC使用了一个CUBIC函数来代替标准TCP的线性窗口增加函数，以提高在快速和长距离网络下的可扩展性和稳定性。
Binary-Increase拥塞控制（BIC-TCP）[XHR04] 是CUBIC的前身，在2005年被Linux选为默认的TCP拥塞控制算法，已经被整个互联网社区使用了好几年。CUBIC使用了与BIC-TCP类似的窗口增加功能，在保持BIC-TCP的优势（如稳定性、窗口可伸缩性和RTT公平性）的同时，它在带宽使用方面比BIC-TCP更具攻击性和公平性。CUBIC已经取代BIC-TCP成为Linux中默认的TCP拥塞控制算法，并被Linux全局部署。通过在各种互联网场景中的广泛测试，我们相信CUBIC在全球互联网上的测试和部署是安全的。
在接下来的章节中，我们首先简要说明了CUBIC的设计原则，然后提供了CUBIC的确切规格，最后根据[RFC5033]中规定的指南讨论了CUBIC的安全特性。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必须”、“应”、“不应”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（且仅在所有大写字母出现时）应按照BCP 14[RFC2119][RFC8174]的规定进行解释，如下所示。
CUBIC遵循以下设计原则：
为了更好的网络利用率和稳定性，CUBIC [HRX08] 使用了一个三次函数来增加窗口，该函数根据距离上一次拥塞事件所经过的时间来计算窗口增加的大小。大多数替代标准TCP的拥塞控制算法都使用凸函数来增加拥塞窗口，而CUBIC算法同时使用凸函数和凹函数来增加窗口。在通过冗余ACK或显式拥塞通知（ECN Echo ACKs）[RFC3168] 检测到拥塞事件，使得窗口减小之后，CUBIC将检测到拥塞时的窗口大小记录为，并对拥塞窗口进行乘性减少。在进入拥塞避免阶段后，利用三次函数的凹形曲线（左边）增加拥塞窗口。三次函数的稳定点设置为，窗口大小在到达之前会遵循三次函数曲线持续增长。在窗口大小达到之后，三次函数进入到凸形曲线区域（右边），窗口大小开始沿着凸形区域增大。这种窗口调整方式（先凹后凸）提高了算法的稳定性，同时保持了较高的网络利用率[CEHRX07]。这是因为窗口大小几乎保持不变，围绕着形成一个稳态区域，此时网络利用率被认为是最高的。在稳态下，CUBIC的大多数窗口大小样本都接近于，从而提高了网络的利用率和稳定性。需要注意的是，那些仅使用凸函数来增加拥塞窗口大小的拥塞控制算法的在接近时窗口会剧烈增加，从而在网络饱和点附近引入大量的包突发，可能导致频繁的全局丢失同步（ global loss synchronizations ）。
CUBIC 通过建立 “TCP友好区域” ，使其在较小的 BDP 场景下，将每个流的公平性提升到标准TCP的水平。注意，标准TCP在短RTT和小带宽（或小BDP）网络下表现良好，但在具有长RTT和大带宽（或大BDP）的网络中，存在可扩展性问题。标准TCP的另一种拥塞控制算法设计为在每个流的基础上对标准TCP友好，必须在小型BDP网络中比在大型BDP网络中更有效地增加拥塞窗口。CUBIC 的侵略性主要取决于窗口缩减前的最大窗口大小 ，小BDP网络的小于大BDP网络。因此，CUBIC在小型BDP网络中增加拥塞窗口的力度小于大型BDP网络。因此，当 CUBIC 算法的三次函数增加拥塞窗口的力度小于标准TCP时，CUBIC 只遵循标准TCP的窗口大小，以确保 CUBIC 算法在小型BDP网络中至少达到与标准TCP相同的吞吐量。我们将 CUBIC 类似于标准TCP的区域称为“TCP友好区域”。
具有不同RTT的两个 CUBIC 流（ CUBIC flow ） 的吞吐量比率（ ratio ）与其RTT比率的倒数成正比，其中对于每一个流的吞吐量近似于其拥塞窗口的大小除以其RTT。具体地说，CUBIC在TCP友好区之外保持独立于RTT的窗口增长率，因此具有不同RTT的流在稳定状态下在TCP友好区之外 *** 作时具有相似的拥塞窗口大小。这种线性吞吐率的概念类似于高统计复用环境下的标准TCP，在这种环境下，数据包丢失与单个流量无关。然而，在低统计复用环境下，具有不同RTT的标准TCP流的吞吐量比与其RTT比的倒数成二次比例[XHR04]。CUBIC始终确保线性吞吐量比与统计复用的级别无关。这是对标准TCP的改进。虽然对不同RTT流的特定吞吐量比率没有共识，但我们认为在有线互联网下，使用线性吞吐量比率似乎比使用相等吞吐量（即，不同RTT流的相同吞吐量）或更高阶吞吐量比率（例如：低统计复用环境下标准TCP的二次吞吐率）更加合理。
为了在可扩展性和收敛速度之间取得平衡，CUBIC将乘性窗口递减因子设置为0.7，而标准TCP使用0.5。虽然这提高了CUBIC的可伸缩性，但这种决策的一个副作用是收敛较慢，特别是在低统计复用环境下。这种设计选择遵循了《高速TCP》（HSTCP）[RFC3649]一书的作者和其他研究人员（例如[GV02]）所做的观察：当前的互联网变得更加异步，丢失同步频率更低，统计复用率更高。在这种环境下，即使严格的乘增乘减（MIMD）也可以收敛。具有相同RTT的 CUBIC流 总是独立于统计复用收敛到相同的吞吐量，从而实现算法内公平性。我们还发现，在统计复用充分的环境下，CUBIC流 的收敛速度是合理的。
本文档中所有窗口大小的单位为最大段大小（MSS, Maximum Segment Size ）的段，所有时间的单位为秒。 cwnd 表示流的拥塞窗口大小， ssthresh 表示慢启动阈值。
CUBIC通过仅在接收到ACK时增加拥塞窗口来维持标准TCP的确认（ACK）时钟。它不会对TCP的快速恢复和重传进行任何更改，例如TCP NewReno [RFC6582] [RFC6675]。在拥塞避免期间，如果重复ack检测到数据包丢失或ack使用ECN Echo flags[RFC3168]检测到网络拥塞，CUBIC将更改标准TCP的窗口增加功能。假设在上一次拥塞事件中窗口缩小之前的窗口大小为。
CUBIC使用以下函数进行窗口的增加：
Eq. 1
其中 C 是一个常数，用于确定高BDP网络中窗口增加的侵略性， t 是从当前拥塞避免开始所经过的时间， K 是上述函数将当前窗口大小增加到所需的时间，如果没有进一步的拥塞事件，则使用以下公式计算：
Eq. 2
其中是CUBIC的乘性递减因子，即，当检测到拥塞事件时，CUBIC将其 cwnd 减少到。我们将在第4.5节讨论如何设置，在第5节讨论如何设置 C 。
当在拥塞避免期间接收到ACK时，CUBIC使用 Eq. 1 计算下一RTT期间的窗口增加率作为拥塞窗口的候选目标值，其中RTT是由标准TCP计算的加权平均RTT。
根据当前拥塞窗口大小 cwnd 的值，CUBIC以三种不同的模式运行：
下面，我们将描述CUBIC在每个区域采取的确切行动。
标准TCP在某些类型的网络中表现良好，例如，在短RTT和小带宽（或小BDP）网络下。在这些网络中，我们使用TCP友好区域来确保CUBIC至少达到与标准TCP相同的吞吐量。
根据[FHP00]中的分析，设计了TCP友好区。分析研究了加法因子为（每RTT增加一个窗口）、乘法因子为 （表示为）的加法增乘减（AIMD）算法的性能. 具体地说， 的平均拥塞窗口大小可以使用 Eq .3 （其中）来计算窗口大小，以此来实现与使用AIMD（1，0.5）的标准TCP相同的平均窗口大小。
Eq .3
基于上述分析，CUBIC使用 Eq. 4 来估计窗口大小（ ， 其中 ，）的 与 以及 ，它实现了与标准TCP相同的平均窗口大小。当在拥塞避免阶段收到 ACK 时，（ cwnd 可以大于或小于)，CUBIC 检查是否小于 。 如果小于，则 CUBIC 当前位于TCP友好区域，在每次收到ACK时， cwnd 应该设置为。
Eq .4
当在拥塞避免阶段接收到ACK时，如果CUBIC不在TCP友好区域并且 cwnd 小于，那么 CUBIC 处于凹区域。CUBIC算法处于次区域时，每收到一个ACK， cwnd 必须增加，其中使用 Eq. 1 计算。
当在拥塞避免阶段接收到ACK时，如果CUBIC不在TCP友好区域并且 cwnd 大于或等于 ， 那么 CUBIC 处于凸区域。凸区域表示自上一次拥塞事件以来，网络条件可能受到了干扰，这可能意味着在一些流离开之后，可用带宽会增加。由于因特网是高度异步的，所以在不引起可用带宽的重大变化的情况下，一定量的扰动总是可能的。在这个区域，CUBIC非常小心，非常缓慢地增加它的窗口大小。凸函数曲线确保窗口在开始时增长非常缓慢，并逐渐增加其增长率。我们也把这个区域称为“最大探测阶段”，因为CUBIC正在寻找一个新的。CUBIC算法处于次区域时，每收到一个ACK， cwnd 必须增加，其中使用 Eq. 1 计算。
当收到三次冗余ACK、检测到丢包或收到显示拥塞控制包时，检测到网络拥塞，CUBIC 通过如下步骤更新其、 cwnd 和 ssthresh ：
// save window size before reduction
// new slow-start threshold
// threshold is at least 2 MSS
// window reduction
将设置为一个大于 0.5 的值的副作用为收敛速度较慢。我们认为，虽然设置自适应的可以使得算法更快的收敛，但这将使得 CUBIC 的分析更加困难。这种自适应调整是将会在 CUBIC 的下一个版本纳入考虑。
为了提高 CUBIC 算法的收敛速度，我们在 CUBIC 算法中加入了一个启发式算法。当一个新的流加入网络时，如果现有的流已经使用了网络的所有带宽，那么网络中的现有流需要放弃一些带宽来允许新的流有一些增长的空间。为了加速现有流的带宽释放，应该实现以下称为“快速收敛”的机制。
通过快速收敛，当发生拥塞事件时，在拥塞窗口的窗口缩小之前，每个流会记住自己在更新之前最后一个的值，我们将其标记为。
在一个拥塞事件发生时，如果的当前值小于 ，则表示由于可用带宽的变化，该流的饱和点正在减小。然后我们允许这个流通过进一步减少来释放更多的带宽。此 *** 作有效地延长了此流增加其拥塞窗口的时间，因为减少会迫使流更早地达到饱和点。这使得新的流有更多的时间赶上它的拥塞窗口大小。
在超时的情况下，CUBIC遵循标准TCP来减少 cwnd [RFC5681]，与标准TCP[RFC5681]有一点不同的是，CUBIC 使用来设置 ssthresh 。
在超时之后的第一次拥塞避免期间，CUBIC使用 Eq. 1 增加其拥塞窗口大小，其中 t 是自当前拥塞避免开始以来经过的时间， K 被设置为0，并且被设置为当前拥塞避免开始时的拥塞窗口大小。
当 cwnd 不大于 ssthresh 时，CUBIC必须采用慢启动算法。在慢启动算法中，CUBIC可以在一般网络中选择标准TCP慢启动算法RFC5681，也可以在快速和长距离网络中选择有限慢启动算法RFC3742或混合慢启动算法HR08。
在CUBIC运行混合慢启动[HR08]的情况下，它可以退出第一个慢启动而不引起任何分组丢失，因此是未定义的。在这种特殊情况下，CUBIC切换到拥塞避免并使用 Eq. 1 增大其拥塞窗口大小，其中 t 是自当前拥塞避免开始以来经过的时间， K 被设置为0，并且设置为当前拥塞避免开始时的拥塞窗口大小。
目前市场上的数据分析工具还是比较多的，国内跟国外都有，我就介绍几款主流的给楼主。国外：
Tableau：自身定位是一款可视化工具，与Qlikview的定位差不多，可视化功能很强大，对计算机的硬件要求较高，部署较复杂。目前移动端只支持IOS系统。
Qlikview:最大的竞争者是Tableau，同Tableau和国内众多BI一样，是属于新一代的轻量化BI产品，体现在建模、部署和使用上。只能运行在windows系统，C／S的产品架构。采用内存动态计算，数据量小时，速度很快；数据量大时，吃内存很厉害性能偏慢。
Cognos：传统BI工具中最被广泛使用的，已被IBM收购。拥有强大的数据库平台、在数据管理、数据整合以及中间件领域专业功底深厚。偏 *** 作型，手工建模，一旦需求变化需要 重新建模，学习要求较高。
国内：
FineBI:帆软旗下的自助性BI产品，轻量化的BI工具，部署方便，走多维分析方向。后期采用jar包升级换代，维护方便，最具性价比。
永洪BI:敏捷BI软件，产品稳定性较高。利用sql处理数据，不支持程序接口，实施交由第三方外包。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）