YiNotes

TCP流量控制

Jun 19, 202527 min read

TCP流量控制

TCP流量控制的基本概念
page=151

  • 00:02:36
  • TCP为应用程序提供了流量控制（Flow Control）机制，以解决因发送方发送数据太快而导致接收方来不及接收，造成接收方的接收缓存溢出的问题。
  • 流量控制的基本方法：接收方根据自己的接收能力（接收缓存的可用空间大小）控制发送方的发送速率。

流量控制与拥塞控制

  • 流量控制：解决的是发送方和接收方速率不匹配的问题，发送方发送过快接收方就来不及接收和处理。采用的机制是滑动窗口**的机制，控制的是发送了但未被 Ack 的包数量。
  • 拥塞控制：解决的是避免网络资源被耗尽的问题，通过大家自律的采取避让的措施，来避免网络有限资源被耗尽。当出现丢包时，控制发送的速率达到降低网络负载的目的。

流量控制是为了让接收方能来得及接收（端对端的通信），拥塞控制是为了降低整个网络的拥塞程度（全局性）

TCP流量控制方法

解决几个问题
传输的时候丢包，客户等着服务器发送，服务器等着客户应答

TCP流量控制的基本概念

滑动窗口（接收窗口）的建立

控制发送方发发送速率，要让接收方来得及接收，采用滑动窗口机制；

这里是服务端对客户的控制

案例满足这些假设

  • 网络不会拥塞（不考虑TCP的拥塞控制）
  • 在A和B建立TCP连接时，B告诉A：“我的接收窗口rwnd=400”，因此A将自己的发送窗口swnd也设置为400

也就是说，字节流的传输形式是选定的滑动窗口的大小中的内容

滑动窗口的控制机理

  • 当发送窗口发送满足，即需要等待 ACK 后才能继续发送；
  • 当数据丢失后，等待超时重传；
  • 当收到被接收的数据，响应给 A 后，其缓存会被删除；

客户从服务器确定发送窗口大小

B 对 A 进行流量控制，当其建立连接时，B 告诉 A, 其接收窗口大小为 400, 故 A 的发送大小为 400

蓝色部分是假设中确定的客户发送的每个的TCP数据报文段的大小，这是设置的，不是这个控制流程中可以决定的

窗口长度为4，发送1，剩下的3格是待发送的部分

发送中的seq


这里的第一个seq=1是数据的起始标号
后面的seq=101是数据第一次发送了100以后，新的起点

发送中滑动窗口里的数据出现了丢包

这里第三部分也就是说201-300这部分丢失了，还剩下301到400的部分可以发送，虽然没有等到信息，让客户确认这部分丢失了，客户的窗口里面还可以就发这个第四格

累计确认报文段

客户把滑动窗口内的内容全部发送出来以后
这里应该是用客户这里窗口的标记序号来做的识别，不用确认服务器确认每一个都收到了

这里服务器会给客户发送累计确认报文段
这个报文段满足一些格式 - 00:05:27

  • 确认标志位ACK被设置为1
    • 表示这是一个TCP确认报文段
  • 确认号设置为201
    • 表示201之前的都正确接收了

服务器调整窗口值


服务器把rwnd的值调整为300，表示主机B的接收缓存的可用空间只有300字节

客户滑动到调整过的窗口值

  • 先划过累计确认报文段中确认过的部分，也就是这里的白色部分
  • 接着把当前容纳内容的窗口值调整为300
  • 其中201-300号是已经发动但是路上丢包了，没有收到确认的部分，这里不能删除，因为有可能再把他们从窗口中拿出来超时重传
  • 发出去100的窗口大小
  • 直到窗口内所有值都发出去

触发超时重传

发送0窗口报文段

服务器这里没有缓存空间了，给客户发送0窗口报文
客户这里收到了这个0窗口以后，把滑动窗口置为0，两者进入了一种静止的状态

重启非0窗口的通知丢包

当服务器有了新的空间以后，准备告知客户，可以扩大发送窗口，发送新的字节流了
但是这个通知在传播途中丢失了
这会造成A一直等待B发送的非零窗口通知
而服务器又会一直等待客户发送的数据报文段

如果不采取措施，这将变成死循环

持续计时器

  • 为了打破由于非零窗口通知报文段丢失而引起的双方互相等待的死锁局面，TCP为每一个连接都设有一个持续计时器。
  • 只要TCP连接的一方收到对方的零窗口通知，就启动持续计时器。
  • 当持续计时器超时时，就发送一个零窗口探测报文段，仅携带1字节数据。
  • 对方在确认这个零窗口探测报文段时，给出自己现在的接收窗口值。
  • 如果接收窗口值仍然是0，那么收到这个报文段的一方就重新启动持续计时器。
  • 如果接收窗口值不是0，那么死锁的局面就可以被打破了。

持续计时器的运行原理

A发送的零窗口探测报文段到达B时，如果B此时的接收窗口值仍然为0，那么B根本就无法接受该报文段，又怎么会针对该报文段给A发回确认呢？

实际上TCP规定：即使接收窗口值为0，也必须接受零窗口探测报文段、确认报文段以及携带有紧急数据的报文段。

如果零窗口探测报文段丢失了，还会打破死锁的局面吗？

回答是肯定的。因为零窗口探测报文段也有重传计时器， 当重传计时器超时后，零窗口探测报文段会被重传。

TCP的拥塞控制

拥塞-tcp

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

网络拥塞的衡量指标

拥塞控制的方法分类

开环控制

  • 试图用良好的设计来解决问题。
  • 从一开始就保证问题不会发生。
  • 一旦系统启动并运行起来，就不需要中途修正
  • 当网络的流量特征可以准确规定且性能要求可以事先获得时，适合使用开环控制。

互联网环境下基本上不使用开环控制

闭环控制

当网络的流量特征不能准确描述或者当网络不提供资源预留时，适合使用闭环控制。
因特网采用的就是闭环控制方法。

基于反馈的控制方法，包括以下三个部分：
监测网络拥塞在何时、何地发生。
把拥塞发生的相关信息传送到可以采取行动的
地方。
调整网络的运行以解决拥塞问题。

根据拥塞信息的反馈形式，可将闭环拥塞控制算法分为2种

进行拥塞控制是需要付出代价的

可能需要在节点之间交换信息和各种命令，以便选择拥塞控制的策略并实施控制，这样会产生额外开销。
可能需要预留一些资源用于特殊用户或特殊情况，这样就降低了网络资源的共享程度。

然而，为了确保网络性能的稳定，不会因为输入负载的增长而导致网络性能的恶化甚至出现崩溃，使用拥塞控制而付出一定的代价是值得的

显式反馈算法

从拥塞节点（即路由器）向源点提供关于网络中拥塞状态的显式反馈信息

拥塞控制并不仅仅是运输层要考虑的问题。显式反馈算法就必须涉及网络层。虽然一些网络体系结构（如ATM网络）主要在网络层实现拥塞控制，但因特网主要利用隐式反馈在运输层实现拥塞控制。

隐式反馈算法

源点自身通过对网络行为的观察（例如超时重传或往返时间RTT）来推断网络是否发生了拥塞。TCP采用的就是隐式反馈算法。

拥塞的四种控制方法

明确四个概念：

  • 接受窗口
  • 发送窗口
  • 拥塞窗口
  • 慢开始门限

  • 发送方维护一个拥塞窗口 cwnd 的状态变量，取决于网络的拥塞程度（动态变化）
  • cwnd 的维护原则：只要网络没有出现拥塞， 拥塞窗口就再增大一些，但只要网络出现拥塞，拥塞窗口就减少一些。
  • 判断网络出现拥塞的依据：没有按时收到应当到达的 TCP 确认报文段而产生了超时重传。
  • 发送方维护一个慢开始门限 ssthresh 状态量：

不考虑拥塞控制：swnd = rwnd
不考虑流量控制：swnd = cwnd

  • 当 cwnd < ssthresh 时，使用慢开始算法。
  • 当 cwnd > ssthresh 时，停止使用慢开始算法而改用拥塞避免算法。
  • 当 cwnd = ssthresh 时，既可使用慢开始算法，也可使用拥塞避免算法。

慢开始

拥塞避免

快重传

快恢复

拥塞控制流程图

TCP拥塞控制与网际层拥塞控制的关系

  • 00:44:47
    网际层中路由器对 IP 数据报的丢弃策略对 TCP 的拥塞控制影响最大

当有多个客户端都向路由器发送大量 IP 数据报时：

  1. 接收缓存溢出而导致尾部丢弃
  2. TCP 报文段的这些发送方产生超时重传，这将导致它们将拥塞窗口 cwnd 的值陡降为 1，因此发送窗口 swnd 的值也降低为 1，并且进入 TCP 拥塞控制的慢开始阶段，称为全局同步
  3. 全网的通信量骤降，而在网络恢复正常后，其通信量又突然增大很多

尾部丢弃策略

路由器的输入缓存（可看作缓存队列，以下简称为队列）通常都按照“先进先出FIFO” 的规则来处理到达的IP数据报。由于队列长度总是有限的，因此当队列已满时，之后再到达的所有IP数据报都将被丢弃，这就叫作尾部丢弃策略.

主动队列管理-AQM

  • 为避免网络中出现全局同步问题，使用主动队列管理（Active Queue Management，AQM）。
  • 即在路由器的队列长度达到某个阈值但还未满时就主动丢弃 IP 数据报，而不是要等到路由器的队列已满时才不得不丢弃后面到达的 IP 数据报
  • 应当在路由器队列长度达到某个值得警惕的数值时，也就是网络出现了某些拥塞征兆时，就主动丢弃到达的 IP 数据报来造成发送方的超时重传，进而降低发送方的发送速率，因而有可能减轻网络的拥塞程度，甚至不出现网络拥塞。
  • 主动队列管理AQM可以有不同的实现方法，其中曾流行多年的就是随机早期检测（Random Early Detection，RED），也称为随机早期丢弃（Random Early Drop，RED或 Random Early Discard，RED）。
  • 路由器需要维护两个参数来实现RED：队列长度最小门限和最大门限。当每一个IP数据报到达路由器时，RED就按照规定的算法计算出当前的平均队列长度。
  • 若平均队列长度小于最小门限，则把新到达的IP数据报存入队列进行排队。
  • 若平均队列长度大于最大门限，则把新到达的IP数据报丢弃。
  • 若平均队列长度在最小门限和最大门限之间，则按照某一丢弃概率p把新到达的IP数据报丢弃（这体现了丢弃IP数据报的随机性）。

TCP可靠传输的实现

TCP的发送窗口，也就是滑动窗口是以字节为单位的

ackn在选择重传协议与TCP协议中并不完全相同

在选择重传协议中， ackn表明序号到n为止的数据已正确接收，现在期望收到序号为n+1的数据
在TCP协议中， ackn表明序号到n-1为止的数据已正确接收，现在期望收到序号为n的数据

根据确认报文段中的 和 这两个字段来构造发送端口，确认发送的信息的长度的大小ack表示，希望收到的下一个数据的序号是31,30之前都是正确接收的
rwnd表示，接收方的接收窗口的大小

发送窗口

发送窗口中的数据，有这些特点

  • 发送方在没有收到接收方确认的情况下，可以把序号落入发送窗口内的数据依次全部发送出去。
  • 发送窗口内的序号已经用完时，发送方在未收到接收方发来确认的情况下，不能再发送新的数据
  • 凡是已经发送过的数据，在未收到确认之前都必须暂时保留，以便在超时重传时使用
  • 序号落在发送窗口内的已发送数据，如果迟迟收不到接收方的确认，则会产生超时重传

前沿-发送窗口

前沿前端是不允许发送的部分
page=231
发送窗口前沿的移动情况：

  • 前移→（通常情况）
  • 不动
    • 情况1：没有收到新的确认，接收方通知的窗口大小也没有改变。
    • 情况2：收到了新的确认，但接收方通知的窗口缩小了，使发送窗口的前沿正好不动。
  • 向后收缩（接收方通知的窗口变小了）（强烈不建议进行这个操作）

后沿-发送窗口

后沿后面是已发送且受到确认可以删除的部分
page=231
发送窗口后沿的移动情况：

  • 不动 （没有收到新的确认）
  • 前移→ （收到新的确认）

发送窗口的标记和维护

  • 00:06:20
    针对下图中的状态，如何处理

HINT

设置三个指针来维护窗口中数据的序号

  • P1指针：指向发送窗口内已发送但还未收到确认的第一个数据的序号
  • P2指针：指向发送窗口内还未发送的第一个数据的序号
  • P3指针：指向发送窗口前沿外的第一个数据的序号
    page=237
    这样就可以用P1、P2和P3这三个指针来描述发送窗口的相关信息:
  • 小于P1的就是已发送并已收到确认的部分
  • 大于等于P3的就是不允许发送的部分
  • P3 - P1 = 发送窗口尺寸
  • P2 - P1 = 已发送但还未收到确认的字节数量
  • P3 - P2 = 允许发送但当前还未发送的字节数量（又称为可用窗口或有效窗口）

接收窗口

  • 00:08:36
    接收窗口中接收到了不是按序到达的数据，怎么处理
    像是这个图中，应该从31接收到41，但是，有的部分丢了，只接收到了窗口中的一部分，就是这个32和33这两块

TCP可靠传输的琐碎细节


page=253
对于TCP可靠传输的实现，还需要做以下补充说明

  • 虽然发送方的发送窗口是根据接收方的接收窗口设置的，但在同一时刻，发送方的发送窗口并不总是和接收方的接收窗口一样大，这是因为：
    • 网络传送窗口值需要经历一定的时间滞后，并且这个时间还是不确定的
    • 发送方还可能根据网络当时的拥塞情况适当减小自己的发送窗口尺寸
  • 对于不按序到达的数据应如何处理，TCP并无明确规定
    • 如果接收方把不按序到达的数据一律丢弃，那么接收窗口的管理将会比较简单，但这样做对网络资源的利用不利，因为发送方会重复传送较多的数据
    • TCP通常对不按序到达的数据先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付上层的应用进程
  • TCP要求接收方必须有累积确认（这一点与选择重传协议不同）和捎带确认机制。这样可以减小传输开销。接收方可以在合适的时候发送确认，也可以在自己有数据要发送时把确认信息顺便捎带上
    • 接收方不应过分推迟发送确认，否则会导致发送方不必要的超时重传，这反而浪费了网络资源。TCP标准规定，确认推迟的时间不应超过0.5秒。若收到一连串具有最大长度的报文段，则必须每隔一个报文段就发送一个确认
    • 捎带确认实际上并不经常发生，因为大多数应用程序很少同时在两个方向上发送数据
  • TCP的通信是全双工通信。通信中的每一方都在发送和接收报文段。因此，每一方都有自己的发送窗口和接收窗口。在谈到这些窗口时，一定要弄清楚是哪一方的窗口

TCP超时重传时间RTO的选择

  • 00:00:29
    超时重传时间RTO应该略大于往返时间RTTO
  • RTO < RTTO（RTO小于RTTO）
    • 超时重传时间（RTO）小于往返时间 RTT 时，将会引起报文段不必要的重传，使网络负荷增大
  • RTO >> RTTO（RTO大于RTTO）
    • 若设置远大于往返时间，会使网络的空闲时间增大，降低了传输效率

TCP下很难确定一个RTO值

  1. 主机 A 所发送的报文段可能只经过一个高速率的局域网
  2. 也可能经过多个低速率的网络协议
  3. 并且每个 IP 数据报的转发路由还可能不同

RTO的确认方法

[!错误做法]
不能直接使用略大于某次测量得到的往返时间RTT样本的值作为超时重传时间RTO

[!解题核心]
利用每次测量得到的RTT样本计算加权平均往返时间RTTs，这样可以得到比较平滑的往返时间

RTO的计算公式

page=261
建议使用下式来计算超时重传时间RTO

RTT超时重传时间的测量分析

page=263
往返时间RTT的测量是比较复杂的

  • 00:05:39

    当出现以下问题时，无法推测 RTT 时间，故再计算TRRs时，只要报文段重传了，即不采用该RTT样本

TCP的选择确认-SACK

page=271
在之前介绍 TCP 的快重传和可靠传输时，TCP接收方只能对按序收到的数据中的最高序号给出确认，当发送方超时重传时，接收方之前已收到的未按序到达的数据也会被重传。

能否设法只传送缺少的数据而不重传已经正确到达、只是未按序到达的数据呢

TCP可以使用选择确认协议（Selective ACK, SACK）

Graph View

Backlinks