【JavaEE】网络原理---TCP协议的易懂图文详解（确认应答、超时重传、连接管理、滑动窗口、流量控制）

一、TCP协议

TCP，即Transmission Control Protocol，传输控制协议。人如其名，要对数据的传输进行一个详细的控制。

1.1 TCP协议格式

（为了方便排版这样化的，我们从上到下依次理解）

二、TCP原理

2.1 确认应答

确认应答是实现可靠性的最核心机制！！

引例：

为了解决上述问题，我们给信息标号：

这样就能清楚的分出各自的应答

而我们真实的TCP传输数据时也是这样的，引入了“序号”和“确认序号”

这就是确认应答机制

比如下面两台主机的传输：

2.2 超时重传

如果一切都顺利的话，就可以直接确认应答了，确认应答机制保证了可靠性

可是我们网络传输需要经过很多节点，其中任何一个节点出现问题，都会导致丢包

作为发送方会判定，如果出现丢包，就会重新再发一遍，即超时重传机制

这时候你可能有一个疑问：
上面的（2）情况下，数据重复传了两次，接收方得到重复的数据！！这种情况不会有什么问题吗？

不会！！！！

TCP协议会在接收缓冲区中根据我们数据的序号来进行自动去重，保证应用读到的数据只有一份！

假如同时有多个包丢失，TCP怎么确定超时时间？

上面介绍的这两种机制就是TCP可靠性的基石！！！

2.3 连接管理

下面详细说具体执行过程：

三次握手：

四次挥手：

可能这里大家会有疑问：为什么三次握手和四次挥手都是四次交互，而握手可以合并为一次，挥手却不行呢？

2.4 滑动窗口

刚才我们讨论了确认应答策略，对每一个发送的数据段，都要给一个ACK确认应答。收到ACK后再发送下一个数据段。
这样做有一个比较大的缺点，就是性能较差。尤其是数据往返的时间较长的时候。

想要提高效率，就需要缩短等待时间，批量发送数据！

一次发多条数据，一次等待多个ACK，提高效率

上述批量传输数据的过程就称为“滑动窗口”

注意：

上述的滑动窗口都是基于无丢包的情况下工作的，如果批量发送的过程中出现丢包怎么办？

2.5 流量控制

接收端处理数据的速度是有限的。如果发送端发的太快，导致接收端的缓冲区被打满，这个时候如果发送端继续发送，就会造成丢包，继而引起丢包重传等等一系列连锁反应。
因此TCP支持根据接收端的处理能力，来决定发送端的发送速度。这个机制就叫做流量控制

具体如何控制？

过程演示：

上述过程就达成了类似阻塞的效果

2.6 拥塞控制

前面介绍的滑动窗口的大小取决于流量控制，其实还取决于拥塞控制

那如何”拥塞控制机制“时如何衡量传输路径的处理能力的呢？

具体过程请看下面图解：

2.7 延时应答

前面知道了”确认应答“保证了TCP的可靠性，在这个前提下，我们能不能同时提高点效率？

通过延时应答就可以

为什么把ACK延时发送就可以提高效率？

2.8 捎带应答

捎带应答是基于延时应答的一种机制

捎带应答是什么意思呢？下面我们来看：

2.9 面向字节流

2.10 异常情况