TCP的流量控制

  • 一般来说，我们总是希望数据传输得更快一些，
    • 但如果发送方把数据发送得过快，接收方就可能来不及接收，这就会造成数据得丢失。
  • 流量控制（flow control）就是让发送方的发送速率不要太快，要让接收方来得及接收。
  • 利用滑动窗口机制可以很方便地在TCP连接上实现对发送方地流量控制。

具体内容太难记笔记了，回去看视频吧。
https://www.bilibili.com/video/BV1c4411d7jb?p=60&spm_id_from=pageDriver

TCP的拥塞控制

  • 在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络性能就要变坏。这种情况就叫做拥塞。
    • 在计算机网络中的链路容量（带宽）、交换节点中的缓存和处理机等，都是网络的资源。
  • 若出现拥塞而不进行控制，整个网络的吞吐量将随输入负荷的增大而下降。

image.png

  • 四种拥塞控制方法：慢开始，拥塞避免，快重传，快恢复。

  • 介绍拥塞控制算法的基本原理，先假定如下条件：

    • 数据是单方向传送，而另一个方向只传送确认。
    • 接收方总是有足够大的缓存空间，因而发送方发送窗口的大小由网络的拥塞程度来决定。
    • 以最大报文段MSS的个数为讨论问题的单位，而不是以字节为单位。

  • 发送方要维护一个叫做拥塞窗口cwnd的状态变量，其值取决于网络的拥塞程度，并且动态变化。

    • 拥塞窗口cwnd的维护原则：只要网络没有出现拥塞，拥塞窗口就增大一些，但只要网络上出现拥塞，拥塞窗口就减小一些。
    • 判断出现网络拥塞的依据：没有按时收到应当到达的确认报文（即发生超时重传）。
  • 发送方将拥塞窗口作为发送窗口。
  • 发送方还要维护一个叫做慢开始门限ssthresh状态变量：
    • 当cwnd<ssthresh时,使用慢开始算法；
    • 当拥塞窗口大于时，停止使用慢开始算法，改用拥塞避免算法；
    • 当等于时，既可以用慢开始算法，也可以使用拥塞避免算法。

慢开始算法

  • 传输轮次：发送方给接收方发送数据报文段后，接收方给发送方发回响应的确认报文段。一个传输轮次所经历的时间，其实就是往返时间，往返时间并非恒定数值。
  • 发送方每收到一个对新报文段的确认时，就把拥塞窗口值加1，然后开始下一轮传输。
  • 当拥塞窗口值达到慢开始门限值，开始改用拥塞避免算法。
  • 拥塞窗口是几，就能发送几个数据报文

  • 慢开始是指一开始向网络注入的报文段少，并不是指拥塞窗口cwnd增长速度慢。

    拥塞避免算法

  • 随着传输轮次增加，拥塞窗口值没轮次线性加1.

  • 重传计时器超时
    • 判断网络很可能出现了拥塞， 进行以下工作：
      • 将ssthresh值更新为发生拥塞时cwnd值的一半。
      • 将拥塞窗口值减小为1，并重新开始执行慢开始算法。
      • 当拥塞窗口值到达新的ssthresh值时，停止使用慢开始算法。
  • 拥塞避免并不是指能完全避免拥塞，而是指在拥塞避免阶段将拥塞窗口控制位按现行规律增长，使网络比较不容易出现拥塞。
  • 慢开始和拥塞避免算法是1988年提出的TCP拥塞控制算法（TCP Tahoe版本）
  • 1990年又增加了两个新的拥塞控制算法（改进TCP的性能），这就是快重传和快恢复（TCP Reno版本）
    • 有时，个别报文段会在网路中丢失，但实际上网络并未发生拥塞。
      • 这将导致发送方超时重传，并误认为网络发生了拥塞。
      • 发送方把拥塞窗口cwnd又设置为最小值1，并错误地启动开始算法，因而降低了传输效率。
    • 采用快重传算法可以让发送方尽早知道发生了个别报文段的丢失。

快重传

  • 所谓快重传，就是使发送方尽快进行重传，而不是等超时重传计时器时再重传。
    • 要求接收方不要等待自己发送数据时才进行捎带确认，而是要立即发送确认。
    • 即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认。
    • 发送方一旦收到3个连续的重复确认，就将响应的报文段立即重传，而不是等待该报文段的超时重传计时器超时再重传。

image.png
比如上图，M3丢失，接收方重复确认M2三次，发送方重传M3，然后接收方确认M6，标识6以前的都正确接收了。

  • 对于个别丢失的报文段，发送方不会出现超时重传，也就不会误认为出现了拥塞（进而降低拥塞窗口cwnd为1）.使用快重传可以使整个网络的吞吐量提高约20%。

快恢复

  • 发送方一旦收到3个重复确认，就知道现在只是丢失了个别的报文段。于是不启动慢开始算法，而执行快恢复算法。
    • 发送方将慢开始门限ssthresh值和拥塞窗口cwnd值调整为当前窗口的一半；开始执行拥塞避免算法。
    • 也有的快恢复实现是把快恢复开始时的拥塞窗口cwnd值再增大一些，即等于新ssthresh+3。
      • 既然发送方收到3个重复的确认，就表明有3个数据报文段已经离开了网络；
      • 这3个报文段不再消耗网络资源而是停留在接收方的接收缓存中；
      • 可见现在网络中不是堆积了报文段，而是减少了3个报文段。因此可以适当把拥塞窗口扩大些。

TCP超时重传时间的选择

  • 超时重传时间的选择是TCP最复杂的问题之一
  • 超时重传RTO的值，应该略大于往返时间RTT的值：
    • 小了，会引起不必要的重传
    • 大了，网络中的空闲时间增大
  • 不能直接使用某次测量得到的RTT样本来计算超时重传时间RTO。因为每一次往返时间可能都不一样。
  • 利用每次测量的到的RTT样本，计算加权平均往返时间RTTs（又称为平滑的往返时间）。
    • 新的RTTs = (1-α) 旧的RTTs + α 新的RTT样本。
    • 若α很接近0，新样本对RTTs影响不大
    • 反之，就反之。
    • RFC6298建议时间是1/8.
  • 用这种方法得出的加权平均往返时间RTTs就比测量出的RTT值更加平滑。
  • 显然，超时重传时间RTO应略大于加权平均往返时间RTTs。
  • RFC6289建议使用下式计算超时重传时间RTO：

image.png
image.png

  • 往返时间RTT的测量比较复杂

    一个问题：A给B发的报文丢失了，超时重传后，收到了B的确认报文，A怎么确定这个确认报文是对原报文段的确认还是对重传报文的确认呢？
    image.png
    另一个问题：A给B发数据报，B给A发确认报文，由于某种原因，B的确认报文迟到了，这就引起了A对之前发送数据报的超时重传。A收到迟到的报文后，无法判断其是对原报文的确认还是对重传报文的确认。

  • 针对出现超时重传时无法预测往返时间RTT的问题，Karn提出了一个算法：在计算加权平均往返时间RTTs时，只要该报文重传了，就不采用其往返时间RTT，进而超时重传时间RTO也不会重新计算。

    • 引起了新的问题。报文段的时延突然增大了很多，并且之后很长一段时间都会保持这种时延。因此在原来得出的重传时间内，不会收到确认报文段。于是就重传报文段，但根据karn的算法，不考虑重传的报文段的往返时间样本。这样，超时重传时间就无法更新。这会导致报文段反复被重传。
  • 要对Karn算法进行修正。方法是：报文段每重传一次，就把超时重传时间RTO增大一些。典型的做法是将新RTO的值取为旧RTO的值的2倍。