滑动窗口,TCP的流量控制机制

TCP 协议与包括 UDP 在内的其他传输层协议的主要差别在于:数据传输质量UDP 协议将数据发送出去之后就不管了,但 TCP 还会对已发送的数据进行跟踪,以防丢失。这样就有效地实现了 TCP 协议的两个关键特性:

  • 可靠性reliability ),保证数据可靠送到目的地(如有丢失,必须能够检测出来,并重传);
  • 流量控制flow control ),控制数据发送速度,以免冲垮接收方;

为实现这两个设计目标,TCP 协议引入了所谓的 滑动窗口sliding window )机制。理解滑动窗口机制,是掌握 TCP 协议的关键,也是学习其他 TCP 知识的前提。本节带领大家将滑动窗口机制一举拿下!

UDP局限性

UDP 数据包完全依赖 IP 包进行网际传输,可以看作是加上端口号的 IP 包而已。因此,UDP 协议的传输质量完全取决于 IP 包。由于 IP 协议只是一种“尽力而为”的网络协议,不能保证可靠性,因而 UDP 也是不可靠的。

由于网络链路问题,IP 包在传输的过程中随时可能丢包,承载在其上的 UDP 包也肯定会丢。如上图,发送方通过 UDP 协议给接收方发送 4 个数据报,其中承载数据③的 IP 包丢失了,但双方均不知情。

一个数据报发送出去后,可能会到达目的地,也可能不会。由于发送方无法从接收方那得到任何反馈,因而无法保证可靠性,流量控制就更别提了。因此,我们需要在 IP 协议之上,引入额外的机制,来处理丢包问题。

确认机制

由于 IP 协议缺乏反馈机制,为保证可靠性,TCP 协议规定:当接收方收到一个数据后,必须回复 ACK 给发送方。这样发送方就能得到反馈,如果数据发出去后很长时间都没有收到 ACK 确认,说明数据很有可能已经丢失了。

一旦数据在传输过程中丢失,发送方必须重传。因此,TCP 每次发送数据后,都会启动一个定时器。如果定时器超时还没收到对方确认,TCP 就会重新发送数据。我们来看一个例子:

图中左边是发送方待发送字节流状态,字节流中每个字节都有一个序号,假设从零开始。数据颜色代表发送状态:

  • 灰色,表示已经发出去而且收到对方确认的数据;
  • 蓝色,表示已经发出去但还未收到确认的数据;
  • 绿色,表示还未发送的数据(包括未来要发但此刻还不存在的数据);

刚开始时,发送方已经成功发送了前 5 个字节,如灰色部分所示。随后它开始发送数据①,其实序号为 5 ,总共 5 个字节。再啰嗦一句,起始序号 5 保存在 TCP 报文段中的序号字段;而数据长度 5 无须保存,TCP 可以根据 IP 包数据长度和 TCP 头部长度来计算。

发送方在发送数据的同时,启动了一个计时器。这些数据虽然已经发送出去了,但还没收到对方确认,因而处于蓝色状态。随后它收到接收方发来的确认,状态转为灰色,万事大吉!注意到,确认号是最后一个字节加一,也就是下一个数据的起始序号。

紧接着,发送方又发出了数据②,首字节序号为 10 ,总共 4 个字节。这次比较背,数据②在传输过程中丢失了!发送方等到计时器超时都没收到确认,因此它将数据重新发送一次,并再次启动计时器。

这时,数据②仍维持蓝色不变,因为发送方还没收到确认。等数据成功送达对方,并收到对方的确认后,数据转成灰色状态。待发送字节流颜色不断交替,滚滚向前。

接收缓冲区

由于承载 TCP 报文段的 IP 包是独立路由的,可能走不同的网络路径,无法保证一定按照发送顺序送达目标主机。 TCP 协议需要向上提供连续字节流传输服务,如果报文段错序到达,TCP 必须根据序号重新排列数据。

另一方面,数据到达后目标主机后,接收方应用程序可能忙于其他事情,无法及时处理。鉴于这两个点,TCP 接收方需要在内存中准备一个接收缓冲区,用于临时保存数据。

TCP 报文段到达后,数据先临时保存在缓冲区中,位置由序号决定。当相邻的数据均达到后,组成连续字节流提交给应用程序。当应用程序将数据取走后,缓冲区中的副本就可以删除。如果应用程序忙于其他任务,数据则继续缓存在缓冲区中。

TCP 协议一般由操作系统内核实现,应用程序只需通过系统调用发送/接收数据,完全不用关心序号或 ACKTCP 数据到达后,内核先将其保存于接收缓冲区,再通知应用程序读取。

我们来看一个新例子,这次站在接收方的角度,考察数据流在接收缓冲区中的状态:

  1. 刚开始时,接收方缓冲区已接收了 5 字节数据,但应用程序尚未读取;
  2. 发送方又发来 5 字节数据,接收方回复 ACK ,数据保存在缓冲区,应用程序仍未读取;
  3. 与此同时,接收方通告窗口大小为 5 字节,表示自己还能接收 5 字节数据(超过缓冲区就会溢出);
  4. 应用程序将缓冲区中的 10 字节数据全部读取,接收方通告新窗口大小为 15 字节;
  5. 发送方又前后发来两份数据,分别是数据②和数据③,大小均为 4 字节;
  6. 其中,数据②在网络中丢失了;
  7. 数据③顺利到达,接收方根据序号将其保存在缓冲区中,并回复 ACK ,确认号和窗口均不变;
  8. 由于数据②尚未到达,未能组成连续数据提交给应用程序;
  9. 因长时间没收到 ACK ,发送方重传数据②(数据③也被重传,因为 ACK 只确认 10 以前的数据);
  10. 数据②顺利到达,接收方将其保存在缓冲区中,并回复 ACK (注意确认号,数据③也一并确认了);
  11. 数据②和数据③组成连续数据,可以提交给应用程序读取;

综上所述,接收缓冲区主要起到两个关键作用:

  • 应用进程繁忙时暂存数据
  • 数据乱序到达时重排数据

流量控制

接收缓冲区大小是有限的,如果应用进程处理缓慢,发送方还拼命发送,最终肯定会压垮接收方。因此,当缓冲区有变化时,接收方应该通过 窗口大小 字段,将它的剩余大小告知发送方。

接收方通告的窗口大小通常称为 通告窗口advertised window ),可缩写为 awnd 。它起到约束发送方发送速度的作用:

  • 如果接收方应用进程繁忙,迟迟未读取缓冲区里的数据,那么窗口大小将慢慢变小;
  • 当窗口大小降为零,发送方就停止发送新数据;

通过通告窗口,发送方可以实时感知接收方缓冲区的状态,然后根据缓冲区剩余空间动态调整发送速度,这就是 TCP流量控制flow control )机制。

滑动窗口

重新站在发送方的角度,来考察数据的发送状态,可以分为四种:

  1. 已发送且已确认,这部分已经发送完毕,可以忽略;

  2. 已发送但未确认,这部分可能在网络中丢失,数据必须保留以便必要时重传;

  3. 未发送但可发送,这部分接收方缓冲区还有空间保存,可以发出去;

  4. 未发送且暂不可发送,这部分已超出接收方缓冲区存储空间,就算发出去也没意义;

注意到,第②和第③部分加起来就刚好是接收方缓冲区大小,如图红框部分。红框的左边缘由接收方的最后一个 ACK 确认决定,而长度由接收方通告的窗口大小决定,它规定了当前发送方能发送的最大数据量。

当发送方收到对方的 ACK ,意味着有数据已成功到达接收方,窗口左边缘将向右移动:

当接收方应用进程将数据从缓冲区取出后,向接收方通告新的窗口大小,这时窗口右边缘向右扩张:

随着双方通信的进行,由 已发送但未确认 以及 未发送但可发送 这两部分数据组成的窗口将不断向右移动,因此被形象地称为 滑动窗口sliding window ),TCP 流量控制机制也因此被称为滑动窗口机制。

总结

  • TCP 双方实现接收确认机制,保证数据可靠传输;
  • 接收方引入缓冲区实现数据重排,以及在应用进程繁忙时暂存数据
  • 接收方通过窗口大小字段实时通告缓冲区剩余空间;
  • 发送方根据接收方通告的窗口大小,控制发送速度,以免冲垮接收方;
  • 由最新 ACK 和通告窗口大小划定的数据区域称为 通告窗口 ,发送方据此实现 流量控制

【小菜学网络】系列文章首发于公众号【小菜学编程】,敬请关注: