TCP的滑动窗口机制,谈谈其设计演化过程(如何从无到有?从不可靠到可靠?)

理解TCP滑动窗口是如何工作的,对于理解TCP的其他知识是至关重要的。

相比于更为简单,同为传输层协议的UDP而言,TCP提供了对传输数据的质量保证。

在可靠性上,TCP确保传输的数据不丢失、不重复,也不会产生乱序。

同时,TCP还提供了流量控制,用于控制数据发送的速度,防止较快主机导致较慢主机的缓冲区溢出。

接下来,从不可靠的协议开始说起,看看TCP面向流的滑动窗口机制是如何演化而来的。

不可靠的协议

对于不可靠的协议(例如IP、UDP),当数据发出去之后,可能到达目的地,也可能丢失。

如果没有提供消息反馈的机制,那么发送方将无法获知数据是否已成功的送达目的地,因而也无法对丢失的数据进行重传。

没有消息反馈机制,是造成传输不可靠,没有流控的一个主要原因。

支持重传的确认机制

为了能够在一个不可靠协议的基础之上,进行可靠的数据传输,引入了消息反馈机制。

消息反馈

发送方发送一条信息,当接收方收到数据之后,给发送方返回一个接收成功的反馈信息。

简单的实现流程如下:

  1. 主机A给主机B发送一条消息;
  2. 主机B收到后,给主机A发送一条确认消息,告诉A消息已经被成功的接收了;
  3. 主机A在收到B的确认消息之后,就知道该消息已发送成功。

但是这个简单的机制,可能存在2个问题:

  1. 由于IP协议是不可靠的,实际上消息可能没有到达目的地。这样,主机A将会处于等待消息确认的状态,可能永远也收不到确认。
  2. 另一方面,也有可能主机B在收到了从A发送过来的消息之后,返回了确认消息,但这个消息却意外的丢失了。

以上2种情况,都有可能导致主机A一直处于等待确认消息的状态,但却永远也等不到。

超时重传

为了解决这个问题,当主机A发送一条消息之后,可以同时启动一个计时器。这个计时器的时间要足够长,让消息能够送达主机B,同时让确认消息也能够返回给主机A。

如果在确认消息到达主机A之前,计时器超时了。那么,主机A会认为发送消息的过程中遇到了问题(可能是丢失了,或者网络堵塞导致包延迟),于是就重传该消息。

由于这种对消息的确认机制,既包含了对消息已收到的确认应答,也包含了发生超时后对消息的重传,因此被称为支持重传的确认机制(PAR,Positive Acknowledgment with Retransmission)

基于PAR机制,能够给数据传输提供基本的可靠性保证

但PAR机制存在一个缺点,就是在任何时候,只能有一条消息是未被确认的。这会使得系统变得非常慢,因为后续消息的发送都得等待前一条消息的确认。

消息标识和发送限制

PAR机制比较适用于传输少量数据,或者交互不是很频繁的协议。由于PAR传输效率低下,因此也不适用于像TCP这样的协议。

为了解决传输效率低下的问题,引入了消息标识。

消息标识

当发送方发送消息的时候,为这个消息增加一个唯一标识。接收方在收到消息之后,返回的确认消息也带上该消息标识。

这样,发送方就可以针对不同的消息使用不同的标识。发送方可以同时发送多条消息,在收到确认消息之后,只要根据消息标识进行匹配,确认对应的消息即可。

以上,只是从发送方的角度,解决了发送方的发送速率问题(在任何时候,只能有一条消息是未被确认的)。

发送限制

我们再换个角度,原来是发送一个消息,接收方处理完,返回确认消息后,等待下一条消息。这个过程,对于接收方来说,并不会存在什么问题。

在引入消息标识之后,发送方可以同时发送多条消息了。但如果发送过快,接收方可能由于处理不过来,被压垮了。

因此,对于接收方来说,需要保证在自己能够正常接收处理数据的情况下,通过一种机制,来通知发送方尽量不要发送得太快,发送的数据尽量按照自己的处理能力来。

比较容易想到的,就是在接收方返回确认消息的时候,将接收方的发送限制信息带上,传递给发送方

发送方在收到确认消息中的发送限制字段时,就可以按照接收方的要求来控制自己的发送速率。

有了这个发送限制,接收方就可以根据自己的实际负载情况,进行动态反馈以调整发送速率,最优化发送性能。

增加了消息标识和发送限制之后,可以认为是PAR机制的一个增强版。

对于数据的传输,现在可以提供可靠性、效率和基本的数据流控了。

TCP面向流的滑动窗口确认

在增加了消息标识和发送限制之后,整个消息的发送和确认过程,已经较为完善了。

但从传输的”数据”的角度来看,前面我们讲的,其实都是面向消息的。也就是说,发送和确认都是以消息为单位。

而实际上,TCP是面向字节流的,本身并没有消息的概念。TCP传输的数据,我们通常称之为报文段。具体如何识别并组装为一条完整的消息,是应用层的工作。

正因为如此,TCP是以字节为单位来处理数据流的。如果要对TCP传输的数据做标识,那就需要一个字节给一个标识。

这样一来,TCP每次就只能发送一个字节的数据,然后每次也只能确认一个字节的数据,这显然是不合理的。既浪费带宽,又降低了发送效率。

TCP的设计者确实也没有这么做,而是将数据划分为一个个数据段,每次可以发送一段数据

对于每一段数据,使用一个序号来进行标识。每次确认数据的时候,也是确认一段数据而不是一个字节。

事实上,序号是报文段中数据字节的偏移量,表示数据字节的位置。

TCP缓冲区

设想一个场景,主机A和主机B建立了一个新的连接:

  1. 主机A有一个很大的数据字节流需要传输,但是主机B没有办法全部接收;
  2. 所以主机B限制主机A报文段能够传输的字节数大小,直到已发送的字节被确认;
  3. 主机B允许主机A发送更多的字节。

所以,每台主机都需要跟踪哪些字节已经发送了,哪些字节还没有发送,哪些已经确认了。这个流程,和前面以消息为单位的发送限制机制很类似。

为此,TCP引入了缓冲区的概念,将发送方的缓冲区,划分为四个部分。

发送方的缓冲区

如图所示,发送方的缓冲区,被划分为四个部分,具体说明如下。

第一部分:已发送,并且已确认的字节

(Bytes Sent And Acknowledged)

对应于图中的 Category #1 部分,从第1到第31个字节,共31字节。

第二部分:已发送,但尚未确认的字节

(Bytes Sent But Not Yet Acknowledged)

对应于图中的 Category #2 部分,从第32到第45个字节,共14字节。

第三部分:尚未发送,但可以立即发送的字节

(Bytes Not Yet Sent For Which Recipient Is Ready)

对应于图中的 Category #3 部分,从第46到第51个字节,共6字节。

这部分,代表发送方当前还可以发送的字节数,也是接收方当前还可以接收的字节数。

第四部分:尚未发送,并且还不能发送的字节

(Bytes Not Yet Sent For Which Recipient Is Not Ready)

对应于图中的 Category #4 部分,从第52到第95个字节,共44字节。

这部分字节,已经超出了接收方可以接收的最大窗口大小,因此暂不能发送。

发送窗口(Send Window)

黑色方框部分,表示发送窗口(Send Window),通常也简单的称为窗口。

发送窗口由两部分组成,对应于发送缓冲区的第二部分(Category #2,灰色方框内)和第三部分(Category #3,红色方框内)。

如图所示,发送窗口大小为20字节,第二、三部分分别为14字节和6字节。

窗口的左边缘为窗口的第1个字节(第32字节),右边缘为窗口的最后一个字节(第51字节)。

窗口的左边缘位置,决定了窗口的右边缘位置。左边缘是第一和第二部分的分界线,右边缘是第三和第四部分的分界线。

发送窗口的大小,决定了发送方可以同时发送的字节数,即未被接收方确认的字节数。

可用窗口(Usable Window)

可用窗口(Usable Window),对应于缓冲区的第三部分(Category #3),即发送方当前仍可以发送的字节数。

发送消息之后窗口的变化

如果在可用窗口内,发送了一些数据,将会改变发送窗口的位置,以及各部分的大小。

在上面的例子中,发送方的可用窗口为6字节。如果发送方将6个字节的数据发送出去,那么这6个字节将会变成未确认状态,合并到第二部分。

第二部分的范围变为,从第32到第51个字节,共20个字节。

而可用窗口,即窗口的第三部分,将变为0。这通常被称为零窗口(Zero Window)

发送方需要等到有新的确认包到达,才会有可用的窗口可以继续发送数据。

确认消息之后窗口的变化

接收方成功接收了数据之后,会给发送方返回一个确认包。在确认包中,包含了一个确认序号,用于通知发送方,在这个序号之前的数据都已经成功接收了。(确认序号的主要作用,是用来解决不丢包问题。通知接收端已经接收了哪些数据。)

假设,已发送未确认部分(第32到第45字节),是由4个TCP报文段进行传输的。每个报文段的范围分别为:

  • 第一段为32~34字节;
  • 第二段为35~36字节;
  • 第三段为37~41字节;
  • 第四段为42~45字节。

假设第一段、第二段和第四段,都已经成功的发送给接收方了。但是,第三段还没有送达。

那么,接收方将只能确认第一段和第二段,即第32到第36字节已经接收成功了。而对于第四段,还不能进行确认。

这是因为,TCP采用的是累积确认的机制,确认序号表示在这个序号之前(确认序号值减去1)的数据都已经被成功接收。

由于第三段接收方还没有收到,因此不能越过这部分,去确认第四段。否则,发送方会认为第三段也已经被成功的接收了。

(事实上,现在的TCP支持SACK机制,如果启用了,可以支持确认非连续的数据块。)

发送方在接收到确认包之后,窗口将会向右移动5个字节(第32到36共确认5个字节)。而第32到36字节,将会合并到第一部分,变为已发送已确认状态。

由于确认了5个字节,窗口右移之后,又新建了一个5个字节的可用窗口(第52到56字节)。

这个过程会在每次发送方接收到确认包时发生,然后窗口会进行相应的移动,以调整缓冲区各部分的大小。(滑动窗口很形象)

有了滑动窗口机制,就可以使用一个确认序号来确认一整段数据。这为TCP面向字节流的服务,提供了可靠性支持,并且不需要为每一个序号的确认而耗费时间。

丢失确认之后窗口的变化

发送方在发送了第52到56字节的数据之后,就停下来不再发送数据了。因为被卡在了第37到41字节上,这个范围的字节仍然没有返回确认包。

当然,和PAR机制类似的,TCP也支持超时检测和重传数据包。

因此,在计时器超时之后,发送方将重发已丢失的报文段,并希望这一次能够到达目的地。

非常不幸的是,TCP的累积确认机制,仍存在一个缺点,它并不会独立的确认每个报文段。

这意味着,TCP有可能会重复发送那些实际已经被接收方成功接收的报文段。

在我们的例子中,第四段(第42到45字节)已经被成功接收。但只要第三段没有被确认,当超时进行重发时,第四段也会被重发。

(完)


参考

http://www.tcpipguide.com/free/t_TCPSlidingWindowAcknowledgmentSystemForDataTranspo.htm

《TCP/IP 详解》卷1:协议

《趣谈网络协议》


---转载本站文章请注明作者和出处 二进制之路(binarylife.icu),请勿用于任何商业用途---

留下评论