【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✿✿ヽ(°▽°)ノ✿
原文地址：https://blog.csdn.net/2301_81949860/article/details/154070841
免责声明：本站文章内容转载自网络资源，如侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！