TCP流量控制主要由基于接收方确认的滑动窗口机制和基于网络情况的发送方的拥塞控制算法来实现！
TCP流量控制主要涉及滑动窗口，拥塞控制算法，RTT(Round-Trip Time,往返时间)，RTO(Retransmission Timeout,重传超时)计算等等。
滑动窗口通常认为是接收方反馈给发送方的流量和重传控制(不考虑网络)；拥塞控制算法通常认为是发送方的流量控制算法(考虑网络时延丢包等)；RTT计算会影响到RTO计算及影响某些拥塞算法运行结果；RTO计算会涉及到超时重传定时器设置。
滑动窗口(sliding window)是数据传输时接收方通告窗口给发送方，然后发送方根据窗口决定一次发送多少数据的机制，本质是ARQ(Automatic Repeat Request, 停等协议)，滑动窗口一方面利用接收方确认报文反馈的窗口大小控制每次发包个数，另一方面根据接收方确认报文确认号判断数据帧重传，滑动窗口仅通过接收方反馈的信息进行流量控制，不会考虑网络带宽延迟等因素。
ARQ主要有连续ARQGo-Back-N和选择ARQSelective Repeat两种，TCP中使用Go-back-N，Selective Repeat作为可选实现。Go-back-N和Selective Repeat区别在于，Go-back-N一次发包只有一个定时器，中间出现丢包，则丢的包之后的所有包都需要重传，Selective Repeat一次发包需要和包个数一样的定时器数量，中间出现丢包则仅重传丢失的那个包，简单来说Go-back-N比较耗网络带宽，Selective Repeat比较耗计算资源。
两种ARQ滑动窗口发送过程可参考如下网站的动画：
TCP滑动机制原理可简述为：TCP发送方包含一个发送窗口，按序列号发送数据包，TCP接收方根据收到的包回复确认包，TCP发送包根据收到的确认包中通告窗口反馈来动态调节发送窗口大小、滑动窗口右移并发送后续的数据包。
如下tcpipguide网站TCP滑动窗口描述，TCP发送方发送缓存区分为4块区域:已发送已确认、已发送未确认、未发送接收方已准备好和未发送接收方未准备好，TCP接收方接收缓存区分为3块区域:已接收已确认、未接收被允许发送、未收到发生方可能未发送。
Linux内核4.x中滑动窗口代码示例，大体可以看出来和tcpipguid网站中描述一致：
TCP流量控制中RTT及RTO计算是一个很重要的问题，ARQ中针对丢包都需要超时重传，超时的设置就会涉及到RTO，RTO设置过短(<2RTT)则可能导致不必要的重传(丢的包可能在传输马上能到)，超时重传时间设置过长则可能影响TCP通信效率(一直在等丢的包重传过来)，RTO计算需要基于RTT，RTT计算值直接影响RTO，不少拥塞算法也和RTT直接相关，TCP流端到端的RTT和RTO都不是一个固定的值，都是一段时间网络中端到端的估算值，随着时间和网络的变化而变化。
网络就像高速公路网，时而拥堵时而畅通无阻，对应在网络里就是RTT抖动，如何计算RTT和RTO直接影响重传进而影响通信效率，其计算也经过长时间的理论和实践过程。
最初Phil Karn和Craig Partridge提出SRTT(Smoothed RTT,估算重传时间)和RTO计算如下:
后来Jacobson 和 Karels做了一定的修正，最终形成RFC6298
偏差) ，RTO计算公式，具体如下:
Linux内核4.x中SRTT计算代码如下：
Linux内核4.x中RTO计算代码：
由于滑动窗口仅考虑接收方的接收能力不考虑网络因素，网络带宽是共享的，网络延时是抖动的，网络的变化带来的问题势必会造成整个系统的崩溃，这就像两个火车站运输货物，仅考虑火车站的容纳量，不考虑火车轨道的承载能力，火车车次发的再多可能也是堵在轨道上，还可能导致轨道系统瘫痪。
拥塞控制算法是发送方根据当前网络情况调整发包速率的流量控制机制，TCP中拥塞控制算法发展至今，从经典的reno到google近年来提出的bbr，期间不断有新的拥塞控制算法提出来，拥塞控制也形成了如下RFC。
RFC5681
以linux内核为例，最新的内核版本内部实现了十多种拥塞控制算法实现，包括一些比较新的算法实现(比如bbr)，linux较早版本内核使用reno，linux 2.6.8以后默认采用bic算法，linux 2.6.19以后又默认使用了cubic算法，目前linux 5.x依然默认使用cubic算法， windows同样也是支持多种拥塞控制算法的，目前windows11默认也是使用cubic算法。
TCP拥塞算法整体框架基本一致，以经典的TCP reno拥塞控制算法(教科书通常讲的版本)进行简要介绍，TCP拥塞控制RFC5681规定都包含慢启动、拥塞避免、快重传、快恢复阶段，这又涉及到几个基本参数(cwnd、ssthresh)，cwnd指拥塞窗口的大小，决定了一次发送多少数据包，ssthresh指慢启动阈值。
慢启动
慢启动阶段分为两种，一种是流刚开始cwnd RFC3465 RFC3742 首次慢启动最初初始ssthresh都是设置为一个很大的值，这样直到丢包才会进入拥塞避免，后又出现了hystart优化(混合慢启动)，比如预测出理想的ssthresh，从而让首次慢启动不至于丢包才进入拥塞避免(丢包代价太大)。 拥塞避免 当cwnd>=ssthresh时会进入拥塞避免阶段，cwnd会随着RTT呈线性增长，这个起始是比较保守地试探最大网络能力，不至于网络崩溃。 快重传 拥塞避免阶段当收到3个连续ACK，表明可能出现了丢包，表明网络出现轻微拥堵，这个时候会进入快重传阶段，ssthresh会设置为0.5 * cwnd，cwnd会设置为ssthresh+3MSS，进行数据包重传进入快恢复阶段。 快恢复 快恢复阶段如果重传数据包后如果依然收不到新数据包ACK而且RTO超时了，表明网络并没有恢复，就会重新进入慢启动阶段，ssthresh会设置为0.5 * cwnd，cwnd会设置为初始值，如果收到了新数据的ACK包，表明网络已恢复，cwnd会设置为ssthresh，进入拥塞避免阶段。 reno拥塞控制算法状态图如下 reno算法iperf打流wireshark抓包io图如下: 拥塞控制算法主要是基于网络丢包和延迟(RTT)来实现，所以有的算法丢包敏感，有的算法延迟敏感，有的结合丢包和延迟，不同的算法主要的区别可能在于拥塞避免阶段如何去拟合理想发送速率曲线又不至于丢包，如下 关于不同拥塞算法对比。 拥塞算法网络反馈需要修改点应用场景公平性准则(New) RenoLoss——DelayVegasDelaySenderLess lossProportionalHigh SpeedLossSenderHigh bandWidth＜/td>BICLossSenderHigh bandWidth＜/td>CUBICLossSenderHigh bandWidth＜/td>C2TCP[10][11]Loss/DelaySenderUltra-low latency and high bandWidth＜/td>NATCP[12]Multi-bit signalSenderNear Optimal PerformanceElastic-TCPLoss/DelaySenderHigh bandwidth/short & long-distanceAgile-TCPLossSenderHigh bandwidth/short-distanceH-TCPLossSenderHigh bandWidth＜/td>FASTDelaySenderHigh bandWidth＜/td>ProportionalCompound TCPLoss/DelaySenderHigh bandWidth＜/td>ProportionalWestwoodLoss/DelaySenderLJerseyLoss/DelaySenderLBBR[13]DelaySenderBLVC, BufferbloatCLAMPMulti-bit signalReceiver, RouterVMax-minTFRCLossSender, ReceiverNo RetransmissionMinimum delayXCPMulti-bit signalSender, Receiver, RouterBLFCMax-minVCP2-bit signalSender, Receiver, RouterBLFProportionalMaxNetMulti-bit signalSender, Receiver, RouterBLFSCMax-minJetMaxMulti-bit signalSender, Receiver, RouterHigh bandWidth＜/td>Max-minREDLossRouterReduced delayECNSingle-bit signalSender, Receiver, RouterReduced loss 这里还要提一下TCP流的公平性问题，有的拥塞算法可能会存在带宽抢占，基于延时相关的算法就很容易出现，因为是基于RTT来抢占带宽，RTT越小占用则更多，比如有两条TCP流，TCP流中延迟更小的会抢占更多的带宽，甚至完全占有所有带宽，其他流都无法正常工作。比如reno和bic都存在抢占问题，cubic是通过3次曲线来探测理想带宽，和RTT无关联，公平性做得较好。 如上图使用reno算法，使用iperf打流到两个不同服务端，stream2延时低直接抢占了大部分带宽 如上图使用cubic算法，同样使用iperf打流到两个不同服务端，steam2延时低抢占带宽则没有那么严重 Linux 2.6.x内核版本具体可参考 进行拥塞算法选择，最新的linux 5.x内核多支持了几种，内核代码Kconfig中也有简要描述，顺便提一下mptcp内核也包含了多路径场景的几种拥塞算法。 Linux 4.x内核中支持的tcp拥塞算法，默认使用cubic： Linux mptcp v0.95内核支持的mptcp拥塞算法： Linux4.x内核中拥塞算法扩展时参考struct，拥塞算法主要重写里面函数来实现： Linux4.x内核cubic算法重新如下函数来实现：
