发送窗口与可用窗口:
整个过程关键的操作在于接收方允许发送方一次能容纳的未确认的字节数。这称为发送窗口,有时也称为窗口。该窗口决定了发送方允许传送的字节数,也是2类和3类的字节数之和。因此,最后两类(接收方准备好而尚未发送,接收方未准备好)的分界线在于添加了从第一个未确认字节开始的窗口。本例中,第一个未确认字节是32,整个窗口大小是20。
可用窗口的定义是:考虑到正在传输的数据量,发送方仍被允许发送的数据量。实际上等于第3类的大小。左边界就是窗口中的第一个字节(字节32),右边界是窗口中最后一个字节(字节51)。概念的详细解释看下图。
![image004.jpg](https://i-blog.csdnimg.cn/blog_migrate/fd726f2bfcde680ebb0c8b7fd17a9ad4.png)
可用窗口字节发送后TCP类目与窗口大小的改变:
当上图中第三类的6字节立即发送之后,这6字节从第3类转移到第2类。字节变为如下:
1. 已发送已确认字节1至31。
2. 已发送但尚未确认字节32至51。
3. 未发送而接收方已Ready字节为0。
4. 未发送而接收方Not Ready字节52至95。
![image005.jpg](https://i-blog.csdnimg.cn/blog_migrate/62d8fc2d5d3bcdfe1f1b955792882353.png)
确认处理以及窗口缩放:
过了一段时间,目标设备向发送方传回确认信息。目标设备不会特别列出它已经确认的字节,因为这会导致效率低下。目标设备会发送自上一次成功接收后的最长字节数。
例如,假设已发送未确认字节(32至45)分为4段传输:32-34,35-36,37-41,42-45。第1,2,4已经到达,而3段没有收到。接收方只会发回32-36的确认信息。接收方会保留42-45但不会确认,因为这会表示接收方已经收到了37-41。这是很必要的,因为TCP的确认机制是累计的,只使用一个数字来确认数据。这一数字是自上一次成功接收后的最长字节数。假设目标设备同样将窗口设为20字节。
当发送设备接收到确认信息,则会将一部分第2类字节转移到第1类,因为它们已经得到了确认。由于5个字节已被确认,窗口大小没有改变,允许发送方多发5个字节。结果,窗口向右滑动5个字节。同时5个字节从第二类移动到第1类,5个字节从第4类移动至第3类,为接下来的传输创建了新的可用窗口。因此,在接收到确认信息以后,看起来如下图所示。字节变为如下:
1. 已发送已确认字节1至36。
2. 已发送但尚未确认字节37至51。
3. 未发送而接收方已Ready字节为52至56。
4. 未发送而接收方Not Ready字节57至95。
![image006.jpg](https://i-blog.csdnimg.cn/blog_migrate/80c2973c4f9994d1f065a994bfe92351.png)
每一次确认接收以后,这一过程都会发生,从而让窗口滑动过整个数据流以供传输。
处理丢失确认信息:
但是丢失的42-45如何处理呢?在接收到第3段(37-41)之前,接收设备不会发送确认信息,也不会发送这一段之后字节的确认信息。发送设备可以将新的字节添加到第3类之后,即52-56。发送设备之后会停止发送,窗口停留在37-41。
TCP包括一个传输及重传的计时机制。TCP会重传丢失的片段。但有一个缺陷是:因为它不会对每一个片段分别进行确认,这可能会导致其他实际上已经接收到的片段被重传(比如42至45)。