---

前言

本人是一个普通程序猿!分享一点自己的见解,如果有错误的地方欢迎各位大佬莅临指导,如果这篇文章可以帮助到你,劳请大家点赞转发支持一下!

本文讲解了TCP在保证安全可靠的前提下，提高效率的五大机制。

---

一、TCP协议段与机制

TCP协议的特点

特点	说明
有连接	刻意保存对端的相关信息
可靠传输	尽全力将数据传输过去不是百分百成功，自己会知道数据传输是否成功
面向字节流	以一个字节为基本单位(一个数据可以分成几份 多次发多次收)
有接收缓冲区，也有发送缓冲区	后续文章介绍
大小不受限	对于要传输的数据大小没有要求
全双工	一条通信路径，双向通信。(可以同时发送和接收数据)

---

TCP报头结构

6位标志位

---

TCP协议的机制与特性

TCP的协议段格式，比UDP的协议段格式复杂一万倍！😵😵
所以他的机制与功能也比UDP更加强大！！😇😇

TCP对数据传输提供的管控机制，主要体现在两个方面： 安全和效率 。
这些机制和多线程的设计原则类似： 保证数据传输安全的前提下，尽可能的提高传输效率 。

TCP协议的机制与特性
1️⃣确认应答
2️⃣超时重传
3️⃣连接管理
4️⃣滑动窗口
5️⃣流量控制
6️⃣拥塞控制
7️⃣延时应答
8️⃣捎带应答
9️⃣面向字节流
🔟异常处理

• 1️⃣-5️⃣是TCP协议保证数据传输安全的 安全机制 。
• 6️⃣-8️⃣是TCP协议提高传输效率的 效率机制 。
• 9️⃣-🔟是TCP协议的 其他特性 。

---

二、TCP协议的 滑动窗口机制

TCP协议中确认应答机制，对每一个发送的数据段，都要给一个ACK确认应答。收到ACK后再发送下一个数据段。
这样做有一个比较大的缺点，就是性能较差。

如上图，如果在数据往返的时间较长的时候，等待数据送达后，还要再等待ACK，这一来一返的时间就浪费了，后面要发送的数据全都得等着排队，效率就不高。

---

因此为了在保证可靠传输的前提下尽可能的提高效率，就引入了 滑动窗口机制 。

如上图，规定可以批量传输数据(同时发送多个数据段)。
相当于有一个窗口，窗口里的数据都可以同时发送，这些数据段的大小加在一起等于窗口大小。

假设窗口大小为4000个字节，每条数据段的大小为1000字节。

同时发送4个数据段，然后等待ACK，等到了一个呢，就可以证明有1个大小为1000个字节的数据段，送到了，那么此时就是只有3个数据段，3000个字节大小的数据在发送中。

但是窗口大小为4000个字节，所以我还可以再同时发送1000个字节的数据。窗口向下移动，再发送一个数据大小为1000字节的数据段。

这就是滑动窗口的原理： 规定一个窗口可以同时发送多少数据，当有ACK返回，确定有多少数据送到了，就再发送多少数据，从而达到了提高效率的目的。 规当传输速度足够快时，那么窗口就变成了滑动，因此叫做窗口滑动。

---

那么如果发生了丢包怎么办？

第一种情况：ACK丢包了

如上图，前三个ACK都丢包了，那也毫无影响，只要第四个ACK送达了，就没啥，因为ACK中的确认序号就是告诉他，确实序号之前的字节都收到了，因此只要最后一个ACK没丢就没事。

如果是最后一个包丢了，或者是最后几个都丢了，那就会触发超时重传机制。TCP安全第一位

---

第二种情况：数据丢包了

此时采取的策略为：只重传丢了的数据，不丢的数据不重传。
这个策略也称之为快速重传。

如上图，第二个数据段丢了，那么 后续所有应答报文中的确认序号就会一直是1001(即索要1001及以后的数据)， 不会因为2001-3000送达而改变，会一直保持到1001以后的数据送到。

主机B当中会有一个接收缓冲区，采用特定的数据结构去组织这些收到的数据， 当1001-2000的数据送达时， 会自动排序调整位置。然后ACK中的确认序号就继续变为4001。

使用数据会从缓冲区当中拿数据，但是如果传输速度太快，那么缓冲区也会满。
如果缓冲区满了，你再发送过来数据，不会阻塞等待而是将你发来的数据直接丢掉，这就造成了效率浪费。

这就引出了另外两个个效率机制：流量控制机制与拥塞控制机制。

---

三、TCP协议的 流量控制机制

流量控制机制也对保证可靠传输有一定作用。

窗口滑动机制，提高了效率。但是接收缓冲区的空间也有限，如果接收缓冲区满了，那么再传输数据也是丢包，此时还不如传的慢一点。

所以啊就有了流量控制机制。

流量控制机制： 让报文中携带一个"窗口大小"这样的字段，来进行流量控制，只有ACK标志位为1时，即ACK报文才会生效 。

"窗口大小"的作用：建议发送方的滑动窗口大小(建议不是一定，但是作用也很大)

接收缓冲区满了，即"窗口大小"为0： 发送方暂停发送，每隔一段时间发一个窗口探测报文，如果"窗口大小"不是0了，就继续发送。

---

四、TCP协议的 拥塞控制机制

一条数据由一台设备发送到另一台设备中，这中间序列经过一系列的中间节点(很多个交换机和路由器)。

如果传输路径上的任何一个节点的发送能力遇到瓶颈(收发数据太多等问题)，那么对经过这个节点的数据的传输速率都会产生明显的影响。
即数据传输的快不快，取决于整体路径上最慢的节点(木桶效应)。

拥塞控制： 衡量中间节点(传输路径上发送方与接收方之外的节点)的传输能力，得出一个拥塞窗口大小 ，来避免因为个别节点拉跨而带来的效率浪费。

因为网络环境复杂，每次传输可能走的路径都不同，且各个节点的传输能力也不是一成不变的(用户多时，可能就慢，用户少时，可能就快)。
因此拥塞窗口的计算方法是实验法：通过实验的方式，找到一个合适的发送速率，实现动态平衡。

拥塞窗口的计算方法：
1️⃣：开始时，以一个小速率来传输数据。
2️⃣：如果没有发送丢包，慢慢加快这个速率。
3️⃣：如果出现丢包，立即把速率再减小。
4️⃣：重复2️⃣3️⃣。

感兴趣的朋友可以去搜一下具体的计算方法。

“窗口大小” 取 流量控制(衡量接收方的处理能力) 与 拥塞控制(衡量中间节点的处理能力) 这两个中最小的那一个。

---

五、TCP协议的 延时应答机制

延时应答机制：将确认应答机制中的ACK应答报文，延时发送。

为什么延时发送ACK会提高效率呢？

TCP中决定传输效率的关键元素是"窗口大小"。
"窗口大小"取决与流量控制与拥塞控制。
而流量控制就取决于接收方的接收缓冲区。

这里咱们要搞清楚一个事情：
发送方一直发送数据(一直生产)，而应用程序一直从接收方的接收缓冲区中读取数据(一直消费)。

如果立刻返回ACK，那么ACK的"窗口大小"假设为n
如果稍微等一会会，那么等的这一会，应用程序就会在这一会中消费一些数据，因此再返回ACK，那么"窗口大小"就大概率会比n大。

所以通过延时一会发送ACK，使得ACK中的"窗口大小"变大一点，传输速率也就快一点。

不是所有的包都可以延迟应答

• 数量限制：每隔N个包就应答一次（操作系统不同N也各有差异）
• 时间限制：超过最大延迟时间就应答一次

---

六、TCP协议的 捎带应答机制

捎带应答机制是基于延时应答机制开发的。

一般客户端服务器模型都是一问一答的形式。 即客户端发送一个请求request，服务器返回一个响应response。

正常流程：

1️⃣客户端向服务器发送一个request。
2️⃣服务器收到reques，并返回一个应答报文ACK
3️⃣服务器返回一个response
4️⃣客户端收到response，并返回一个应答报文

基于延时应答于捎带应答机制:

1️⃣客户端向服务器发送一个request。
2️⃣服务器收到reques(延时应答，让ACK暂缓发送)
3️⃣服务器返回一个 (response+ACK)报文 (如果response在ACK发送前就计算完毕，那么就会触发捎带应答机制，把response与ACK合并)
4️⃣客户端收到(response+ACK)报文，并返回一个应答报文

四次挥手有可能是三次挥手也与上述流程相同。

发送一个一定比发送两个快，所以效率得到了提高。

---

总结

以上就是今天要讲的内容，本文分享了TCP协议的五大效率机制，讲述了TCP在保证安全可靠的前提下是如何提高效率的，尽管如此，TCP的效率仍然没有UDP快，保证安全可靠必然会牺牲一部分效率。