【TCP 协议3】提高效率的五大机制

---

前言

各位读者好, 我是小陈, 这是我的个人主页, 希望我的专栏能够帮助到你:
📕 JavaSE基础: 基础语法, 类和对象, 封装继承多态, 接口, 综合小练习图书管理系统等
📗 Java数据结构: 顺序表, 链表, 堆, 二叉树, 二叉搜索树, 哈希表等
📘 JavaEE初阶: 多线程, 网络编程, TCP/IP协议, HTTP协议, Tomcat, Servlet, Linux, JVM等(正在持续更新)

TCP 协议是一种有链接的可靠传输协议, 并且 TCP 设计的宗旨是保证可靠性的同时, 尽可能地提高传输效率, 因此 TCP 具有八大机制 :

• 1️⃣连接管理(三次握手 + 四次挥手)
• 2️⃣确认应答
• 3️⃣超时重传
• 4️⃣滑动窗口
• 5️⃣流量控制
• 6️⃣拥塞控制
• 7️⃣延迟应答
• 8️⃣捎带应答

记住 2~3 用来保证可靠性, 4~8 用来提高效率

上篇文章介绍了保证可靠性的确认应答机制和超时重传机制, 本篇主要介绍用来尽可能提升效率的滑动窗口与高速重传、流量控制、拥塞控制、延迟应答和捎带应答机制

• 需要明确, 为什么 TCP 有这么多机制呢 ?
  由于 TCP 可靠传输, 有链接的特性, 注定了传输效率是不如 (不可靠传输, 无连接的)UDP 的, 所以 TCP 为了尽可能的提高效率, 才有了本篇将要介绍的这五大机制
  但是这些机制也只是"补救措施", 即便是 TCP 设计出了这么多的机制想要兼顾可靠和效率, 大部分场景下的传输效率也是不如 UDP 的

---

提示：是正在努力进步的小菜鸟一只，如有大佬发现文章欠佳之处欢迎批评指点~ 废话不多说，直接上干货！

一、滑动窗口与高速重传

回顾上篇介绍过的确认应答机制, 如图 :

问题来了, 如果发送方每一次发送数据, 都需要等收到 ack 之后才发送吓一跳数据, 那么就会严重影响传输效率, 万一某一条消息发送失败就需要超时重传, 这更是雪上加霜

滑动窗口与高速重传机制就解决了上述问题

---

1, 什么是滑动窗口

📌滑动窗口实现了发送一个数据报之后, 无需等待 ack , 而是继续发送

可以理解为批量传输, 并且不再以一个数据报为单位等待 ack , 而是以多个数据报为单位 窗口大小 == 批量传输的个数(先假设为5)

可以看到, 发送方批量发送了 5 条数据, 接收方批量返回了 5 条 ack

• 为什么序列号为 5001 的数据报, 没有等来确认应答号为 5001 的 ack , 就发送出去了呢 ?

这其实就是窗口的"滑动"造成的, 下面看看窗口的滑动过程

• 假设一开始窗口大小为 5 , 一条数据的长度为 1000 字节, 所以窗口中的数据序列号为1 ~ 5000

• 当发送方收到了确认应答号为 1001 的 ack , 说明发送方 1001 之前的数据已经全部收到了, 该接收序列号为 1001 的数据了, 此时窗口就会往(下)后滑动

• 此时窗口中的数据序列号为 1001 ~ 6000

👉在窗口内的数据, 不需要等待 ack 就可以发送出去, 所以单位时间内原本只能发送一条数据, 由于滑动窗口机制, 就可以发送多条数据

---

2, 什么是高速重传

之前也介绍过了超时重传机制, 如果有数据没有发送成功, 需要重传数据来保证可靠性, 那么在滑动窗口的机制下, 万一发生了丢包应该如何处理 ?

上篇文章中介绍超时重传时说过, 数据报丢包和 ack 丢包都会触发重传机制

2.1, ack 丢包

📌如果少量 ack 丢包了, 不会重传, 只要下一条 ack 收到了就没有任何影响!!

如图, 虽然确认应答号为 1001 的 ack 丢包了, 但是 2001 的 ack 收到了, 这就说明接收方已经收到了序列号为 2001 之前的数据都收到了, 窗口直接从 1 ~ 5000 滑动到 2001 ~ 7000, 所以 1001 这条 ack 丢了也不影响

但是!! 如果是最后一条 ack 丢包了, 那就不可能有后续的 ack , 还是会触发超时重传机制

---

2.2, 数据丢包

📌如果是数据丢包了, 就需要高速重传机制

📌高速重传是指 : 如果发送方收到一条 ack 之后, 还连续收到三次这条 ack , 就会重发对应的数据, 由于没有等待时间, 没有对发送速率产生影响, 所以比超时重传更高效, 称作高速重传机制

高速重传过程如图 :

• 图中序列号为 1001 的数据丢包了, 虽然不影响后续的数据发送, 但是由于发送方没有接收到 1001 ~ 2000 这条数据, 所以即便收到了序列号为 3001 的数据, 也不能返回确认应答号为 3001 的 ack

如果返回 3001 的 ack 说明 3001 之前的都收到了, 但是 1001~2000 没有收到
所以接收方实际收到的数据是 1 ~ 1000 __2001 ~ xxxx, 中间"空缺"了一条数据

• 接收方只能继续发送确认应答号 1001 的 ack , 发送方连续三次收到之后, 说明 1001 ~ 2000 这条数据丢了, 于是重新发送

• 接收方收到重发的数据之后, 把"空缺的数据"补上了, 9001之前的数据都收到了, 所以返回确认应答号为 9001 的 ack

⚠️注意 !! 高速重传并没有完全取代超时重传, 如果发送的数据不多, 是不会采取滑动窗口机制的, 这时如果丢包, 还是需要超时重传, 高速重传只是在滑动窗口机制下的更优解

还有一个问题, 上述的窗口大小是我假设为 5 , 真实的传输过程中 TCP 是如何确定窗口大小的呢? 其实是根据流量控制 + 拥塞控制结合而来的,

---

二、流量控制

之前讲了这么多, 数据如何发送如何重发, 甚至如何批量发送…这都是围绕发送方展开的, 我们好像还没有讨论过, 接收方能否承受的住???

可想而知, 如果发送方发的太快, 接收方顶不住了, 就接收不了数据了呀

接收方由于压力太大而接收不了数据, 就会把原本该接收的数据直接丢弃, 就会非常可惜的触发重传机制, 造成网络资源的浪费

流量控制机制解决了上述问题

1, 什么是流量控制

📌是指, 接收方在返回 ack 时, 会向发送端通知自己可以接收多少数据(缓冲区的剩余容量), 告诉发送方自己的底线, 于是发送方的滑动窗口大小确保不超过这个值

• 滑动窗口的大小也不是固定的, 如果接收方的接收缓冲区即将溢出, 会通知发送方把滑动窗口调小
• 如果接收方的接收缓冲区满了, 就无法继续进行通信, 必须等待接收缓冲区里的数据被应用层读取
• 等到接收方可以接收数据了, 会给发送方发送窗口更新通知, 如果发送方等不及了, 就会主动给接收方发送窗口探测报文

📌接收方给发送方通知的窗口大小, 称作流量控制窗口

综上, 流量控制这个机制有效避免了发送方一次性发送过大/过多的数据导致接收方无法接收的情况

---

三、拥塞控制

一般来说, 计算机网络处在一个共享的环境, 极有可能因为其他主机的通信导致网络拥堵

这就是之前说的"丢包"的原因之一

由于滑动窗口机制, 可以使得发送方批量发送多条数据, 如果在通信刚开始就发送较多数据, 可能会导致网络拥堵甚至瘫痪, 所以 TCP 采用拥塞控制机制来检测发送方的窗口大小

1, 什么是拥塞控制

📌两台主机的通信需要经过很多交换机和路由器, 拥塞控制就是用来探测这一路上的交换机和路由器的传输能力, 通过实验的方式, 找到当前网络环境下能够承受的发送数据量大小, 这个数据称作拥塞窗口

• 发送方从很小的值开始发送数据, 先以指数函数形式增长拥塞窗口大小, 到达一定阈值时, 变为线性增长
• 发生丢包, 超时重传, 然后把拥塞窗口调到很小的值重新开始探测
• 先以指数函数形式增长拥塞窗口大小, 到达一定阈值(每次丢包之后阈值都会变小)时, 变为线性增长
• 发生丢包, 超时重传, 然后把拥塞窗口调到很小的值重新开始探测

综上, 拥塞窗口和流量控制窗口的较小值, 作为当前发送方的窗口大小

---

四、延迟应答

如果要追求效率的话, 难道不是应答的速度越快越好吗 ? 这样发送方就可以更快的发送接下来的数据了, 为什么延迟应答不但不耽误事儿, 反而会提高效率 ?

在流量控制机制中介绍过, 发送方返回的 ack (应答)中, 也是带有流量控制窗口大小的, 而流量控制窗口的大小取决于接收缓冲区剩余的空间

• 如果发送方每一次都是立刻应答 , 就有可能此时接收缓冲区中的数据还没有被读走, 导致剩余空间不多
• 如果延迟一会再应答, 有可能这段时间内, 缓冲区的数据已经被读走了, 导致剩余空间充足

1, 什么是延迟应答

并非是每一个 ack 都等待一会儿再发给发送方, 前面也讲了滑动窗口中, 少量的 ack 丢包也没关系, 所以 TCP 传输数据时, 绝大多数情况都是每收到两个数据报, 返回一个 ack

📌正是由于少返回一次ack, 所以才有了 “延迟” 的效果

当然, 延迟的时间不能太久, 否则可能会让发送方误以为 ack 丢包, 从而触发重传机制

---

五、捎带应答

1, 什么是捎带应答

📌是指 TCP 数据报中即包含 ack, 又包含数据

通过捎带应答, 可以减少收发的数据量减少, 减轻计算机的负荷, 节省网络资源

如果每次接收数据之后都立即返回 ack , 就无法实现捎带应答, 所以延迟应答是实现捎带应答的前提

比如之前介绍过的四次挥手, 就有可能在捎带应答的机制下变成三次挥手

当然这里触发捎带应答的前提是, ack 和 fin 的发送时间差, 小于延迟应答的"延迟时间"

当时的文章里介绍过, 发送 ack 是由系统内核完成的, 而 fin 是由代码决定发送时机

---

总结

以上就是本篇的全部内容, 主要介绍了滑动窗口与高速重传、流量控制、拥塞控制、延迟应答和捎带应答机制, 这五个机制尽可能地提高了 TCP 协议传输时的效率

• 滑动窗口实现了单位时间内, 可以无需等待 ack 就可以发送多条数据, 并且少量的 ack 丢了也不影响, 如果有数据丢包, 高速重传机制可以比超时重传更快的进行补救
• 流量控制实现了探测接收方能承受的"流量控制窗口"大小
• 拥塞控制实现了探测传输路径上能承受的"拥塞窗口"大小

滑动窗口 = min (流量控制窗口, 拥塞窗口)

• 延迟应答实现了尽可能等待"流量控制窗口"变大
• 捎带应答实现了减少收发数据报的次数

如果本篇对你有帮助，请点赞收藏支持一下，小手一抖就是对作者莫大的鼓励啦😋😋😋~

---

上山总比下山辛苦
下篇文章见