TCP之滑动窗口协议(动画演示)

装载！！！！！！！至

CSDN博主的《解析TCP之滑动窗口(动画演示)》，网址：https://blog.csdn.net/yao5hed/article/details/81046945?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-3&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-3
CSDN博主的《TCP-IP详解：滑动窗口（Sliding Window）》，网址：https://blog.csdn.net/wdscq1234/article/details/52444277

该文章只是对两个文章的内容的总结，主体内容来自这两个部分。

b站上有一个视频比较nice的可视化了滑动窗口的机制。

来自于up主今天单词背了吗O_o 的tcp滑动窗口的完美解释，网址：https://www.bilibili.com/video/BV1FE411C7dk?from=search&seid=6007213953266071805

滑动窗口机制

1. TCP背景介绍
2. 滑动窗口引入
3. 滑动窗口机制的概念
4. 滑动机制
5. 滑动窗口机制的模拟程序

5.1 具体分析

6 对比滑动窗口和拥塞窗口

1. TCP背景介绍

从传输数据来讲，TCP/UDP以及其他协议都可以完成数据的传输，从一端传输到另外一端，TCP比较出众的一点就是提供一个可靠的，流量控制的数据传输，所以实现起来要比其他协议复杂的多，先来看下这两个修饰词的意义：

Reliability ，提供TCP的可靠性 ，TCP的传输要保证数据能够准确到达目的地，如果不能，需要能检测出来并且重新发送数据。
Data Flow Control ，提供TCP的流量控制 特性，管理发送数据的速率，不要超过设备的承载能力。
为了能够实现以上2点，TCP实现了很多细节的功能来保证数据传输 ，比如说 滑动窗口适应机制 ，超时重传机制，累计ACK等，这次先介绍一下滑动窗口的一些知识点 。

2. 滑动窗口引入

IP层协议属于不可靠的协议，IP层并不关心数据是否发送到了对端 ，TCP通过确认机制来保证数据传输的可靠性 ，在比较早的时候使用的是send–wait–send 的模式，其实这种模式叫做stop-wait模式 ，发送数据方在发送数据之后会启动定时器，但是如果数据或者ACK丢失，那么定时器到期之后，收不到ACK就认为发送出现状况，要进行重传 。这样就会降低了通信的效率，如下图所示，这种方式被称为 positive acknowledgment with retransmission (PAR)
在这里插入图片描述
滑动窗口机制可以优化一下PAR效率低的缺点 ，比如我让发送的每一个包都有一个id，接收端必须对每一个包进行确认，这样设备A一次多发送几个片段，而不必等候ACK，同时接收端也要告知它能够收多少，这样发送端发起来也有个限制。当然还需要保证数据发送的顺序性，尽量不要乱序。可以允许一段时间内的乱序情况，比如说先缓存提前到的数据，然后去等待需要的数据，但是如果一定时间需要的数据还没来就DROP掉，不管他，继续进行下一个步骤。

3. 滑动窗口机制的概念

滑动窗口实现了TCP流控制。首先明确滑动窗口的范畴 ：TCP是双工的协议 ，会话的双方都可以同时接收和发送数据。TCP会话的双方都各自维护一个发送窗口 和一个接收窗口 。各自的接收窗口大小取决于应用、系统、硬件的限制（TCP传输速率不能大于应用的数据处理速率）。各自的发送窗口则要求取决于对端通告的接收窗口 ，要求相同 。

滑动窗口解决的是流量控制 的的问题，就是如果接收端和发送端对数据包的处理速度不同，如何让双方达成一致。接收端的缓存传输数据给应用层，但这个过程不一定是即时的，如果发送速度太快，会出现接收端数据overflow，流量控制解决的是这个问题。

发送方的发送缓存内的数据 都可以被分为4类:

已发送，已收到ACK
已发送，未收到ACK
未发送，但允许发送
未发送，但不允许发送
其中类型2和3都属于发送窗口 。

接收方的缓存数据 分为3类：

已接收
未接收但准备接收
未接收而且不准备接收
其中类型2属于接收窗口。

窗口大小代表了设备一次能从对端处理多少数据 ，之后再传给应用层。缓存传给应用层的数据不能是乱序的，窗口机制保证了这一点。现实中，应用层可能无法立刻从缓存中读取数据。

4. 滑动机制

发送窗口只有收到发送窗口内字节的ACK确认 ，才会移动发送窗口的左边界。
接收窗口只有在前面所有的段都确认的情况下才会移动左边界 。当在前面还有字节未接收但收到后面字节的情况下，窗口不会移动，并不对后续字节确认。以此确保对端会对这些数据重传。
遵循快速重传、累计确认、选择确认等规则 。
发送方发的window size = 8192;就是接收端最多发送8192字节，这个8192一般就是发送方接收缓存的大小。

5. 滑动窗口机制的模拟程序

模拟程序，网址：http://www.exa.unicen.edu.ar/catedras/comdat1/material/Filminas3_Practico3.swf

稍微有缺陷 ：1. 丢包率如果设得太高，有时无论重发多少次都不能恢复正常 2. 窗口最大可为10，其实应该为9

明确发送端和接收端，发送A~S数据包 ，我们不会从头到尾分析，因为过程比较长。

简化了窗口大小，双方窗口大小都一直是4。
设置一定的丢包率，否则没什么值得分析的，包括sender发送的数据包和receiver回复的ACK包。
简化重传机制，出现丢包则直接重传，不等3个冗余ACK和超时。
既不是选择重传也不是退回N步，重传的包是随机的发。

5.1 具体分析

首先发送端发送A,B,C,D四个包，但是A,B丢失，只有C,D到达接收端。

接收端没有收到A，所以不回复ACK包。发送端重传A,B,C,D四个包，这次全都到达了。

接收端先获得A，发ACK包A，但是中途丢失；获得B后，根据累计确认的原则，发D的ACK包，然后窗口滑动。再次获得C,D后，连续回复2个D的ACK包，其中C对应的ACK包丢失。

发送端连收2个D的ACK包，说明4个包对方都已收到，窗口滑动，发E,F,G,H包，其中G包丢失。现在整个序列的状态：ABCD是已发送已确认，EFGH是已发送未确认，I~S是不能发送。

接收端先收到E，发ACK包；收到F后发F的ACK包；未收到G，还是发F的ACK包；收到H，还是发F的ACK包。不幸的是，三个ACK包全都丢失。

发送端收到E的ACK包，窗口向右滑动一位；然后再发送F,G,H,I，其中F丢失。
接收端获得I，因为没有G，只好回复F的ACK包。相继收到G,H包。

接收端根据累计确认，连发两个I包，其中H对应的丢失。窗口向右滑动。

发送端接收I的ACK包后，向右滑动四位。发送J,K,L,M四个包，后面不再分析。

从上面的过程中，我们可以得到以下结论： TCP连接是通过数据包和ACK实现的，我们作为第三者可以看到双方发包的过程，但接受者在收到之前不知道发送方发的是什么，同样的，发送方在收到ACK前也不知道对方是否成功接收。

发送方没有收到接收方发回的ACK，就不能向右滑动 。假设发送方向接收方发了ABCD就滑动，只要对方没收到A，就不能滑动，那么就会出现二者不同步的局面。
滑动窗口提高了信道利用率 ，TCP是发送报文段为单位的，假如每发一个报文就要等ACK，那么对于大数据包，等待时间就太长了。只要发送的报文在滑动窗口里面，不用等每个ACK回来就可以向右滑动。本例中，开始接收端空着AB，只有CD，此时不能滑动；之后接收到EF和H，直接向右滑动2位，不必等G到位。
窗口大小不能大于序号空间大小的一半 。目的是为了不让两个窗口出现交迭 ，比如总大小为7，窗口大小都为4，接收窗口应当滑动4，但只剩3个序号，导致两个窗口交迭。
有一种情况没出现 ：发送方发ABCD，接收方都收到然后向右滑动，但回复的ACK包全丢了。发送方未收到任何ACK， timeout后会重发ABCD，此时的接收方按累计确认的原则，收到ABCD后只会重发D的ACK，发送方收到后向右滑动。

6 对比滑动窗口和拥塞窗口

滑动窗口是控制接收以及同步数据范围的，通知发送端目前接收的数据范围，用于流量控制，接收端使用 。拥塞窗口是控制发送速率的，避免发的过多，发送端使用。因为tcp是全双工，所以两边都有滑动窗口 。
两个窗口的维护是独立的，滑动窗口主要由接收方反馈缓存情况来维护 ，拥塞窗口主要由发送方的拥塞控制算法检测出的网络拥塞程度来决定的 。

拥塞窗口控制sender向connection传输数据的速率，使这个速率为网络拥堵状况的函数。