TCP详细解析

原创已于 2024-10-01 11:29:30 修改 · 910 阅读

本内容遵循CC 4.0 BY-SA版权协议

于 2024-07-29 21:09:14 首次发布

在这里插入图片描述

我最近开了几个专栏，诚信互三！
====> |||《算法专栏》：：刷题教程来自网站《代码随想录》。|||
====> |||《C++专栏》：：记录我学习C++的经历，看完你一定会有收获。|||
====> |||《Linux专栏》：：记录我学习Linux的经历，看完你一定会有收获。|||
====> |||《C#专栏》：：记录我复习C#的经历，深度理解，查漏补缺，不定期更新。|||
====> |||《计算机网络专栏》：：记录我学习计算机网络，看完你一定会有收获。|||

TCP保证可靠性的原理

TCP是可靠传输的，而保证数据在网络中的可靠传输是通过超时重传和快重传来实现的。
1).超时重传：当发送方发送的数据在网络中丢包，或者接收方发送的ACK报文在网络中丢包时，超过一段特定的时间，就会重新传递在网络中丢失的数据。
在这里插入图片描述
快重传在滑动窗口后讲解。

TCP滑动窗口解析

发送方和接收方都存在一个抽象的窗口，在该窗口内的值可以一次性发送/接收。
在讲解滑动窗口前，我们需要先了解序号和确认序号的意义。
1).序号：代表即将发送数据的开始位置，其意义代表在接收方接收到报文后，序号可以将TCP乱序的数据重新排序完整。
2).确认序号：代表在确认序号前的所有报文都以及完全收到，比如说ACK=1461，则代表1461到1号的所有数据都收到了。
如下图。
在这里插入图片描述
比如说，左方一次性发送了序号为{1，1461，2921，4381，5841}的数据报，说明这些数据是在左方的发送滑动窗口内的，此时，结合丢包的可能，就存在两种可能。
1).当滑动窗口左侧的数据丢失，未收到ACK报文，则此时滑动窗口不移动，，并且不论后面的报文是否发送到接收方，接收方发送的ACK报文的确认序号都是第一个报文之前的那个报文的确认序号。
2).当滑动窗口中间的数据丢失，未收到ACK报文，则此时滑动窗口移动， 如下图所示
在这里插入图片描述

可以这么认为，接收到的seq_ack就是窗口左指针需要移动到的位置。

当接收方连续收到同一个seq_ack报文三次后，会发送快重传机制，此时不用等待超时重传，直接重发，当接收到的seq_ack报文不够三次，则会出发超时重传，这两者相辅相成。
在重传完成并且接收方接收到后，则发送之前以及完全收到的报文的seq_ack。
由上述可知，窗口值是可以变化的，但窗口值只能增加。
同时，滑动窗口的存在，可以允许中间某些报文的回复报文未收到。
在这里插入图片描述

窗口大小由两个因素决定，一个是TCP报文中的窗口值，另一个则是拥塞窗口值，关于拥塞窗口值，下面在讲。
比如当服务器接收数据的能力较差，那么服务器的接收缓冲区的剩余内容就没有了，那么返回报文的TCP窗口值就是零了，客户端就无法发送数据了，当服务端窗口增大后，会返回一个携带新窗口值的大小，如果该报文丢失了，则客户端就无法知道服务端窗口已经扩大了，这样就会陷入窗口的死锁。
1).解决该问题的方法。
只要TCP一方接收到零窗口报文，就会启动一个计时器，当计数器到后，就会发送窗口探测报文。
在这里插入图片描述

TCP拥塞控制

当网络中的访问用户过多，网络中可能会拥塞，导致许多报文在转发过程中丢失等等，对方接收到的报文太少，发送方发出了过多的超时重传机制，就代表网络当前拥塞了。
任何在网络中进行通信的主机，在内核中会维护一个拥塞窗口，它是一个整数，在启动的时候，采用慢启动的方式，每次启动都从1开始，随后按照指数增加，比如第一次发送了一个报文，接收到一个ACK报文，窗口变为2^1，随后发送两个报文，接收到两个ACK报文，随后窗口变为2 ^ 2，随后发送4个报文，以此类推…
当窗口的值到达某个阈值（ssthresh）后，则开始使用拥塞避免方法，按照线性发送数据，如下图。
在这里插入图片描述
当某个拥塞窗口值发生了大量超时重传时，则此在开始下一轮慢启动，并且更新阈值（ssthresh）为上一次发生了大量超时重传时拥塞窗口值的二分之一。
当某个拥塞窗口值发生了快重传时，此时不会开始下一轮慢启动，而是更新阈值（ssthresh）为上一次发生了快重传时拥塞窗口值的二分之一。

为什么要存在慢启动及拥塞避免

我们发现，慢启动在开始的时候，拥塞窗口值非常小，由于滑动窗口的值是由拥塞窗口和TCP报文的窗口值决定的，所以如果拥塞窗口值非常小，则可能导致在开始的时候，发送的数据非常少，影响C/S间的数据传输，同时，慢启动是按照指数级增长的，这是为了快速回复正常的C/S间的数据传输，而在到达ssthresh后，进入拥塞避免状态，这是为了防止指数爆炸。