【JavaEE初阶】TCP核心机制4——滑动窗口

TCP的前三个机制（确认应答，超时重传，连接管理）都是为了保证可靠性，但是，保证可靠性的代价就是传输效率会降低

每传输一个数据都要等对方应答（效率低下）

那我们直接批量传输不就行了嘛！

滑动窗口

窗口大小：不需要等待，可以连续发送的最大数据量

那能否一直发呢？

• 那肯定是不能啊，那相当于没有可靠传输了

那下一组怎么发呢？

• 策略一：等这一组所有的ACK都回来再发第二组->这样做，花的时间会更久
• 策略二：收到一个ACK就发下一条 （可行！）

每收到一个ACK，直接就发下一个数据了

问题：那有可能中间的ACK先到啊，那怎么处理，要跳过前面的发中间的吗？

• 我们先要明确一个前提，数据到缓冲区是会先排序的，对方内核会从前往后依次发回ACK应答
• 如果是2001比1001的ACK先回来，可能是因为2001回来的道路相对1001比较畅通，但是，我们一看到2001回来了，就知道，1001也收到了，可能还没到
• 窗口直接往后走两个格子即可

窗口越大，批发量越多，效率就越高

但是滑动窗口是在可靠传输的基础上，提高效率的

• 这种提高效率只是亡羊补牢
• 引入可靠性，就会使效率产生折损
• 引入滑动窗口，只是让这种折损更小一些
• 但是效率这方面是不可能比UDP高的

使用滑动窗口的过程中，当然也会丢包~

情况一：数据包已抵达对端，但ACK丢了

情况一示意图

• 图中所示的情况 6个包丢了3个，
• 丢包率达到50%，已经是相当恐怖的数字了，说明网络有严重问题
• 但是，此时发送端不用做任何处理，因为后一个ACK可以涵盖前面的ACK（因为前面的ACK发出才会发后一个ACK，所以后一个ACK到了说明前一个ACK已经发出）

情况二：数据包直接丢了，根本没到达对端

针对不同情况下的重传机制：

• 超时重传：传输的数据量少，没有构成滑动窗口批量传输的形式->超时重传
• 快速重传：传输数据量多，形成滑动窗口的情况下的重传机制->快速重传

END✿✿ヽ(°▽°)ノ✿