1. 流量控制（滑动窗口）
TCP 利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率，保证接收方来得及接收。 接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为 0，则发送方不能发送数据。
发送端和接收端各自有自己的滑动窗口。
1.1 滑动窗口
发送窗口
- 已经发送并且确认的 TCP 段（已经发送并确认）；
- 已经发送但是没有确认的 TCP 段（已经发送未确认）；
- 未发送但是接收方准备接收的 TCP 段（可以发送）；
- 未发送并且接收方也并未准备接受的 TCP 段（不可发送）。
接收窗口
- 已经接收并且已经确认的 TCP 段（已经接收并确认）；
- 等待接收且允许发送方发送 TCP 段（可以接收未确认）；
- 不可接收且不允许发送方发送 TCP 段（不可接收）。
1.2 滑动流程
B告诉A的窗口大小，rwnd=20 我的窗口大小20。ack=31 下一次给老子发31。
B 窗口内，数据未按序到达，只能现在缓存中。因为 B 只能按正确顺序发送ACK。
如果 A 一直没有收到 ACK，还有超时重传机制。
注意点
- 因为是全双工通信，发送端和接收端都有自己的发送窗口和接收窗口。
- A的窗口大小不一定和 B 的一样。
- B 的不按时序达到的数据如何处理， tcp 没有规定。1：直接丢弃, 简单, 效率差 2：缓存在窗口内, 等到收到连续了后, 再 ACK。
- 为了增加效率, tcp 要求接收方 B 。1：累计确认，多个一起确认。 2：捎带确认，发数据顺便确认，不经常发生 3：不能太晚确认, 要不然 A 就超时重传。
- 零窗口检测。滑动窗口没有缓存了， 也必须要接收检测或紧急报文。
2. 拥塞机制（四个算法控制拥塞窗口）
拥塞控制就是为了防止过多的数据注入到网络中，这样就可以使网络中的路由器或链路不致过载。流量控制往往是点对点通信量的控制，是个端到端的问题。流量控制所要做到的就是抑制发送端发送数据的速率，以便使接收端来得及接收。
为了进行拥塞控制，TCP 发送方要维持一个 拥塞窗口(cwnd) 的状态变量。拥塞控制窗口的大小取决于网络的拥塞程度，并且动态变化。发送方让自己的发送窗口取为拥塞窗口和接收方的接受窗口中较小的一个。
TCP 发送方A的发送窗口 = min (A的自身拥塞窗口，TCP接收方B的接收窗口)
2.1 四个算法
1. 慢开始算法 （二倍增加）
发送的报文少。虽然名字叫做慢开始，但是增长的速度非常快。
2. 拥塞避免算法（每次+1）
是线性增长，试试啥时候拥塞，尝试拥塞的底线。
3. 快重传算法
B 数据未按序到达，就一直发送想要的序号，一直提醒 A让提早重传。
- B要求 A 你快重传, 不要等计时器到了
- B立即发送确认, 如果不是正确顺序到达, 就发送之前正确顺序的重复确认(为了提醒 A)
- A 收到了3个连续的重复确认, 就应该立即重传
4. 快恢复算法
- 将ssthresh和 cwnd都调整为当前窗口的一半，他俩相等了再执行拥塞避免算法。
2.2 拥塞窗口变化流程
- 首先确认拥塞窗口大小 cwnd，和一个 慢开始变量 ssthresh。
- 假设刚开始 cwnd=1，ssthresh=16。
- cwnd < ssthresh 走慢开始算法，每次收到 ack, 就+1, 然后 +2, + 4, + 8 , 有种指数增长概念。
- cwnd > ssthresh，cwnd c超过了16，走拥塞避免算法。 每次+1， 收到后再+1。
- cwnd = 24 的时候，突然出现了丢包情况，认为拥塞。
- 将 ssthresh=cwnd/2 （12），cwnd=1。
- 慢开始算法继续开始，周而复始。
2.3 快重传和快重复
有时候丢包是网络问题，并不是拥塞。但是你认为拥塞，直接让窗口变1了怎么办? 使用快重传和快恢复算法，避免拥塞窗口直接变1。
- 快重传
启用快重传机制。
B 直接给 A 发送3个重复确认。
发送方 A 收到了3个重复确认, 说明不是拥塞, 不用慢开始算法, 执行快恢复算法。
- 快恢复
快恢复算法，直接将拥塞窗口和ssthresh等于当前的拥塞窗口的一半。
因为相等，继续执行拥塞避免方法。
3. 头脑风暴
- 流程控制的是滑动窗口，拥塞控制的是拥塞窗口。
- 判断拥塞依据，是 A 没有收到 B 的 ACK， A自己发生了超时重传。
- 拥塞控制一共有4个算法，慢开始，拥塞避免，快重传，快恢复。
