quic的拥塞控制

quic的可靠传输，quic每次收到ACK确认，都会更新RTT。一个ACK可以确认一段范围内的包没有丢失。ACK包中还有一个字段叫delay，可以记录服务器收到包后过了多久才发送出这个ACK，用于更精准的计算RTT。
quic的丢包检测也是基于ACK确认，每次收到ACK都会进行如下检测，确认丢包，1.超过报文阀值，比当前ACK确认的包发送还早kThreshold时间的包还没返回确认。2.超过时间阀值，这个时间与RTT相关。

PTO(Probe Tome Out):用于尾帧丢失和ACK丢失，发送方发送一个数据后启动一个PTO定时器，时间跟RTT相关，超时未接受到ACK，会主动发送探测报文，督促对方告知接受报文的情况。

tcp使用的拥塞控制是Reno(Tohoe与之类似，乘性降低比之激进)，对于同一个包，重复收到三个相同的ACK，认为是丢包了。tcp的cubic也与之类似。tcp是正向确认，如果3丢了，那么它收到4，5，6时不会传递3丢失的ACK，也不会传递4，5，6的ACK，而是每次发送2的ACK，这样发送端就知道3丢了。这时4,5,6也已经在接收端的缓存中，等待3来进行排序。发送端可能会持续发送789…，但如果接收端没有收到3,没有返回3的ACK，发送端发送完窗口内的数据后，就无法滑动窗口。

当一个链路维持在BDP状态时，拥有最小的时延和最大的带宽。
BDP=minRTT X 瓶颈带宽(delivery rare)
minRTT 和瓶颈带宽(delivery rare)是相互独立的，并且不停变换的，因为可能随时有新的连接进入链路发送数据。quic在每次收到ACK时，都会更新这两个值。
gm-quic并不限制使用算法，预留了接口可以自己添加，因为拥塞算法相对比较独立。

什么时TCP的队头阻塞：
TCP采用正面确认和超时重传保证可靠传输。一个包发送后，必须收到ACK确认它已经接收成功，才会发送下一个包。因此一个包持续没有收到ACK，不停的超时就会不停的重新传这个包，这就导致后面要发送的包阻塞住了。这是形象的理解，真实的情况是，TCP一次可以发送一个窗口的包，但需要这个窗口的包都收到确认，才会滑动窗口，发送下一个窗口。http2用复用tcp来解决它，但对于堵住那一路，还是有对头阻塞。
quic是如何解决队头阻塞的
它使用udp，但不会因为没有收到ACK，就阻塞在那里不发送，会一直发。但并不是不管理丢包，它也是可靠传输，也是正面确认和超时重传。已发送的数据都在缓存里，只有收到ACK，才会释放对应的缓存，没有释放的超时重传。它不管是否是重传包，Packet Number都是递增的，在接受段通过StreamID和Offset字段来确认这个是之前丢失的重传包。
拥塞cwnd(=swnd)：它是一个发送端维护的动态变量，如果网络没有发送拥塞它会一直增大。其实可以理解为它最终会等于BPD。
ssthresh：这两个慢启动阶段和拥塞避免阶段的分界点，我们就叫“慢启动门限。
慢启动流程：cwnd开始为1,ssthresh为16,每次收到一个ACK，就把cwnd加上收到ACK的数量。swnd是发送窗口，它就等于cwnd，cwnd是几，就代表能发送多少数据。

慢开始和拥塞避免阶段是1988年提出的TCP(TCP Tahoe版本)，它丢包后会进行超时重传，1990年又增加了两个阶段，快重传和快恢复，称为TCP Reno版本。它对于丢失的数据包不再等到超时了再启动超时重传，而是连续收到三个重复报文ACK，就启动重传。叫快重传，然后进行快恢复，这样能有效利用带宽，增加吞吐量。

BBR的带宽探测阶段PROBE_BW：

pacing是间隔5毫秒的间隔发送
在TCP算法中(Cubic/Reno等)并没有平稳发送的说法，BBR算法后来引入了平稳发送的概念，不只解决了发送多少的问题，还解决了发送速率的问题，具体实现是使用cwnd控制发送数量，发送速度使用漏桶算法控制。BBR算法中的cwnd与TCP算法不同，TCP算法中的cwnd是对网络状态的模拟，分为发送窗口和接收窗口，而BBR算法只有发送窗口，且cwnd = 2*BDP。

ProbeRTT并不适用实时音视频领域，因此可以选择直接去除，或者像BBR V2把probe RTT缩短到2.5s一次，使用0.5xBDP发送。
“Goodput” 是一个衡量网络性能的术语，它描述了在特定时间内成功传输的有效数据量。与吞吐量（Throughput）不同，吞吐量通常指的是网络连接的总数据传输速率，包括重传的数据，而 Goodput 专注于实际成功传输且不需要重传的有效数据量。

结果输出-pacing rate和cwnd

首先必须要说一下，bbr的输出并不仅仅是一个cwnd，更重要的是pacing rate。在传统意义上，cwnd是TCP拥塞控制算法的唯一输出，但是它仅仅规定了当前的TCP最多可以发送多少数据，它并没有规定怎么把这么多数据发出去，在Linux的实现中，如果发出去这么多数据呢？简单而粗暴，突发！忽略接收端通告窗口的前提下，Linux会把cwnd一窗数据全部突发出去，而这往往会造成路由器的排队，在深队列的情况下，会测量出rtt剧烈地抖动。

TLS加解密前需要多包进行完整性验证。
•基于丢包的带宽评估•基于延时的带宽评估 •Goog-REMB和•Goog-TCC

•丢包重传（NACK），可以容忍10%的丢包
TCP的流控：随着窗口进一步缓慢增加，终于有一天，网络还是遇到了丢包的情况，我们就会假定这是拥塞造成的。这个时候我们一方面会进行超时重传或者快速重传，另一方面也会把窗口调整到更小的范围。
超时重传，往往意味着拥塞情况更严重，我们的策略也会更激进一些，会直接将 ssthresh 设置为重传发生时窗口大小的一半，而窗口大小直接重置为 0，再进入慢启动阶段。
快速重传，如果我们连续 3 次收到同样序号的 ACK，包还能回传，说明这个时候可能只是碰到了部分丢包，网络阻塞还没有很严重，我们就会采用柔和一点的策略，也就是快速恢复策略。

慢开始：开始发送1个包，一个rtt后收到这个包，再次发送两个包，一个rtt后收到确认两个包，开始发送2+2=4个包，之后发送8,16,32。每轮以乘2的速度发送。
拥塞避免阶段：如发送16个包，一个rtt后收到16个包确认，发送17个，再收到确认发送18个，每次+1发送。
丢包分为两种（Reno同时有这两种机制）：
连续三个重复ack，此时快重传丢了的包，并且快恢复指新的cwnd是之前的一半，ssthresh也为之前的cwnd一半。有些实现是cwnd之前的一半+3，是考虑到网络中已经后三个ack出来了，需要补上，但3个不同，也是近似一半。之后再进行拥塞避免阶段，还是每轮RTT，cwnd+1。
超时重新传（称TIO）：cwnd为0，ssthresh为原来cwnd的一半，然后重新开始慢启动。
tcp的发送都没有pacer，都是每个RTT一起发完，因此cwnd其实也就是每个RTT的发送量。
以上参考：【第5期】TCP协议拥塞控制（Congestion Control）原理

可以看到丢包率1%的时候，cubic几乎没有有效吞吐量。

目前GCC控制算法在实时音视频领域占据主流，但WebRTC的GCC算法仍然有一些局限性：以上参考：https://cloud.tencent.com/developer/article/1521881

由上两图我们来探讨bbr的收敛速度问题，对编码器的发送码率设置的收敛过程，一轮增益系数大概7个，五个1，1.25，0.75，1.25x1.25x1.25=1.9 0.75x0.75x0.75=0.42，每个增益系数持续一个RTT，因此3轮x7RTT=21个RTT。因此经过21个RTT，inflight的数据量已经降为原来的一半。那么在这个过程中，编码器的码率就已经是原来的1/2了，因为只有码率是之前的一半，管道中的数据量才有可能下降到一半。因此管道中的数据量下降到一半时，此时码率一定小于原来的1/2，再加上拥塞，码率会更小一点，但为了维持此时的BDP，码率还得上升为之前的1/2。
因此我们可以说21个RTT过程中，码率已经矫枉过正的变化，最后为码率变为之前的1/2，或者2倍。

拥塞排空之后会进入探测带宽阶段，探测最大带宽的方法是在10个RTT中观测到的最大带宽。
针对BBR应用在实时音视频领域遇到的问题，目前已经有不少解决方案。对于收敛速度慢的问题来说，BBR V2提出在Probe Down一次排空到位（inflight < BDP），另外还可以随机化6个1x平稳发送周期，缩短排空所需要的时间。对于抗丢包能力不足的问题来说，目前BBR算法的抗丢包能力是足够的，但在一些极端网络条件下可以把丢包率补偿到pacing rate，有效提升抗丢包能力。
BBR算法在具备一些优势的同时也存在一定的缺点，比如原始的BBR算法收敛性受到pacing gain周期影响，带宽突降的时候，BBR需要多个轮次才会降到实际带宽。这其中的原因是BBR每轮只能降速一次，而pacing gain的6个RTT的保持周期大大加长了这个时间。由于pacing gain上探周期的1.25无法抵消掉25%以上的丢包，这会造成带宽反馈持续下降，BBR吞吐量就会断崖式下跌。
bbr的官方论文，连接，可以看到从20M突然下降到10M，bbr收敛用时2s。

WebRTC防止拥塞的根基是有准确的带宽评估方法。它提供了两种带宽评估方法，一种是基于丢包的带宽评估，另一种是基于延时的带宽评估。而基于延时的评估方法又分为接收端（Goog-REMB）和发送端（TCC，transportCC）的带宽评估方法，目前默认采用的是Goog-TCC方法，因为其相对来说更为精准。

这个图有点问题，两边应该是直线。
cubic的原理：在reno丢包时，而是记下此时的cwnd记为Wmax，然后执行reno的快重传，之后不再执行reno的快恢复，而是比快恢复上升更快的速率，快速到达Wmax。cubic的改进是比bic更快的速率到到Wmax，它是一个三次方的上升，bic是直线斜上升，它的两头都比bic上升的快。然后比bic在Wmax的停留时间更长，之后比bic更快的速率上升。bic和cubic改进了reno高带宽填充更慢的情况。在慢启动和快速恢复阶段，cubic和reno相同，cubic和bic都是在reno的拥塞避免阶段改变了如上图的曲线。reno总共就三个阶段，慢启动，拥塞避免，快恢复。

ECN(网络辅助信息拥塞控制)原理：
目标数据发送数据后，经过某个路由器，在这个路由器发送拥塞，此时路由器在ip曾给数据包置位，接收端收到识别后，发给发送端的tcp包头置位，告知你发送的数据在网络上拥塞了，此时接收端拆tcp包识别后，减少发送量，并在tcp包里告诉发送端，你的反馈我收到了。以上参考：3.7.2 拥塞控制算法之 ECN 的第2部分 （共2部分）

无线网路的信号衰减，会造成丢包。如下参考：无限网络丢包原因

liveVideoStack 袁荣喜

google：quiche
kiloLink使用的:picoquic