华为、华三、思科高级网络工程师必经之路(3)我们的爱如同TCP连接，始终可靠，永不掉线——TCP可靠性排序机制、确认机制和重传机制以及流控--流量控制机制保姆级别详解

盛透侧视攻城狮

发布于 2024-12-25 09:43:04

9000

代码可运行

文章被收录于专栏：超前沿网络空间安全全栈学习宝典超前沿网络空间安全全栈学习宝典

运行总次数：0

代码可运行

TCP----传输控制协议

TCP的可靠性

1. 排序机制

TCP保证数据按顺序到达接收端。由于数据在网络中可能会通过不同的路径传输，因此不同的数据包可能会到达接收端的顺序不一致。排序机制的作用是确保数据按发送的顺序被正确接收。

具体实现：

每个数据段都有序列号：每个TCP数据段（Segment）都包含一个序列号，这个序列号标识该数据段在整个数据流中的位置。接收方通过序列号来判断数据包的顺序。
接收方按序列号重组数据：接收方会根据序列号对收到的数据进行排序。如果接收到的数据包的顺序与预期不符，接收方会将其缓存在接收缓冲区，等待缺失的包到达。接收方只会将按顺序到达的数据交给上层应用。

如果接收方发现某个数据包的序列号不对或者缺失，它会将该信息反馈给发送方（通过确认机制），发送方会进行相应的重传。

MTU---最大传输单元

MSS---最大段长度----TCP分段--->该参数是需要在TCP建立握手过程中通过前两次SYN报文段来进行协商确定。

如果在本地进行了分段操作，则不需要进行分片操作——原因如下：

1.1.认识一下 IP层的分片机制

在网络中，数据往往需要在多个网络节点（例如路由器）之间传输。当数据包的大小超过某个网络层的最大传输单元（MTU，Maximum Transmission Unit）时，它会被分片。分片是由IP层（互联网协议）完成的，目的是确保数据能够在网络中顺利传输，尤其是在不同的网络链路上，MTU值可能有所不同。

分片的作用：当一个大的IP数据包无法在某个网络中传输时，它会被拆分成多个小的片段。这些片段会单独通过网络传输，并且每个片段都会携带必要的信息，标识它是完整数据包的一部分以及它的顺序。接收端收到这些分片后，会根据分片的标识重新组合成原始的数据包。
IP分片的局限性：IP分片机制主要是为了解决数据包在通过不同网络链路时的大小问题，但它并不考虑数据的顺序控制。IP分片后的数据包依然可能乱序到达，因此，IP层的分片和重新组装并不保证数据的可靠传输和顺序性。

1.2.了解 TCP如何避免分片操作

当TCP应用程序向网络传输数据时，它会将数据拆分成适合网络传输的“TCP段”或“数据段”。如果这些数据段本身很大，且超过了物理网络中某个链路的MTU（最大传输单元），那么这些数据段就需要在IP层进行分片。然而，TCP协议本身有一个**最大段大小（MSS，Maximum Segment Size）**的概念，它定义了TCP段的最大尺寸。MSS通常会被设置为小于网络MTU的大小，避免数据段在IP层被进一步分片。

分段与分片的区别：
- 分段：是应用层（如TCP）将数据流按大小拆分成多个较小的部分。每个分段都有自己的TCP头部，包含序列号、确认号等信息。
- 分片：是IP层针对超出MTU大小的IP数据包进行拆分，并在每个分片中包含分片相关的控制信息（如分片偏移、标识符等）。

因此，TCP会在发送数据时提前控制数据段的大小，以确保每个数据段适合于网络的最大传输单元，避免在IP层发生额外的分片操作。换句话说，TCP通过适当的分段操作保证每个数据段都不会超过MTU大小，从而避免了IP层的分片需求。

1.3. 综上（1,2）所述为什么本地进行分段操作时不需要再进行分片操作？

本地进行分段操作指的是，TCP协议在数据传输之前就将应用数据分成多个适当大小的数据段，确保每个TCP数据段不会超过网络链路的MTU。

控制数据段大小：在TCP连接建立时，发送方会基于网络路径的MTU和MSS（最大段大小）来调整分段的大小。通过这种方式，发送的数据段大小始终小于或等于网络的MTU，从而避免了分片的发生。这样，IP层在收到这些数据段时，不会需要再进行分片操作。
避免IP层分片：如果TCP本地分段确保数据段小于MTU，则IP层在处理这些数据段时不需要进行额外的分片，因为每个数据段本身就已经适合网络传输的最大单位。

2.确认机制和重传机制

2.1. 重传机制

TCP的重传机制是保证数据丢失情况下能够成功传输的关键。由于网络中可能会出现数据丢失、错误或延迟，TCP需要提供一种机制来检测丢失的包并重新发送。 具体实现：

超时重传：如果发送方在一个预定的时间内没有收到接收方的确认（ACK），它会认为该数据包丢失或出现了其他错误，随后会重传该数据包。这个超时是由发送方的“重传计时器”控制的。若在计时器超时之前收到确认，则不进行重传。超时重传的时间间隔是动态调整的，通常采用“加倍间隔”的策略，即每次超时后，重传间隔会增加，直到成功接收到确认。TCP使用一种叫做自适应重传算法（例如：TCP的慢启动、拥塞控制）来优化超时重传的时间。
快速重传：如果接收方发现丢失的包（通过序列号的跳跃）并且收到的连续数据包中有重复的确认号，它会发送多个重复确认（重复ACK）。当发送方收到三个重复确认时，它会立刻重传丢失的数据包，而无需等待重传计时器超时。这种机制被称为快速重传，它能够减少数据包丢失后等待的时间，提高效率。
在快速重传机制中，并不是因为RTO时间到达从而触发重传机制，该重传机制是根据对端的反馈信息进行重传，当连续3三收到相同的ACK报文时，发送端会重传数据。这3个连续的ACK报文被称为冗余ACK。
快速恢复：与快速重传结合使用，快速恢复机制用于在发生丢包时，通过减小拥塞窗口（窗口大小）来快速调整TCP连接的拥塞控制状态，以恢复到正常的传输状态。快速恢复机制一般通过调整TCP的拥塞控制算法来实现，如慢启动与拥塞避免等。

2.2. 确认机制

TCP使用确认机制（Acknowledgment）来确保数据的可靠传输。每当接收方收到数据包时，它会发送一个确认消息，告诉发送方该数据包已经成功接收。 具体实现：

确认号（Acknowledgment Number）：接收方在返回的TCP包中会包含一个确认号，这个确认号表示接收方期望接收的下一个字节的序列号。也就是说，确认号是“下一个期望字节”的序列号，确认号表示前面所有数据已经成功接收。 例如，如果接收方已经成功接收到序列号为1000到2000的数据，它会向发送方发送一个确认号2001，表示它已经成功接收了序列号小于2001的数据。
累积确认：TCP的确认机制是累积确认的，意味着如果接收方确认了某个序列号（比如2001），它也隐含地表示所有之前序列号的数据包都已成功接收。接收方不会为每个数据段单独发送确认，而是按照序列号的累积情况发送一个确认号。
延迟确认：为了提高网络效率，接收方可能会延迟确认，即在短时间内合并多个数据包的确认，减少网络负载。这也使得发送方不会因为过早的确认而频繁发送数据包。

注意：选择确认机制也是需要进行协商的。

3.什么是流控---流量控制机制

3.1流量控制的背景

在网络通信中，接收方的缓冲区容量是有限的。如果发送方的数据流速过快，而接收方来不及处理这些数据，接收方的缓冲区可能会被填满，进而导致数据丢失或者需要丢弃多余的数据。因此，必须有一种机制来控制发送方的发送速率，确保接收方的缓冲区不会被溢出。
TCP的流量控制是端到端的机制，通过在发送方和接收方之间动态调整窗口大小，来避免过多的数据被发送到接收方，直到接收方有足够的空间来存储和处理这些数据。

3.2. 流量控制的核心概念：滑动窗口（Sliding Window）

TCP流量控制的机制基于滑动窗口协议（Sliding Window Protocol）。这个协议用于动态控制数据的传输速率，确保发送方不会超出接收方的缓冲区容量。 滑动窗口的工作原理：

接收窗口（Receiver Window）：接收方的接收窗口（也叫窗口大小）是接收方的可用缓冲区大小，它告诉发送方当前接收方可以接收多少数据。接收方在发送ACK报文时，会告诉发送方它的接收窗口的大小。接收方的接收窗口大小会随着它处理数据的进度而变化。
发送方窗口：发送方基于接收方的窗口大小来调整自己的发送速率。发送方窗口的大小不能超过接收方报告的接收窗口的大小，也不能超过发送方的缓冲区大小。
滑动窗口的动态变化：随着接收方处理数据并释放缓冲区空间，接收方的接收窗口会增大，发送方可以继续发送更多的数据。如果接收方的接收窗口变小，发送方则必须减少发送的数据量，直到接收方有足够的空间可以接收更多的数据。

3.3窗口大小体现在缓存区的大小

TCP要求发送方依据接收窗口rwnd来控制数据的发送量。rwnd等于接收方接收缓存大小减去已存数据量大小。即rwnd变量是可变的。

如下图所示：

1. 发送窗口的概念

发送窗口：是指发送方在没有收到确认的情况下，可以连续发送的数据量。它由一个左边界和一个右边界界定，表示一个字节序列的范围。
左边界（left edge）：表示已经发送并被确认的数据的最右边界。
右边界（right edge）：表示发送窗口的最右边界，即发送方可以发送的数据的最大序列号。

2. 缓存区与发送窗口的关系

缓存区：在 TCP 中，发送方和接收方都有缓存区。发送方的缓存区用于存储待发送的数据，而接收方的缓存区用于存储接收到的数据。
发送窗口大小：直接反映了发送方缓存区中可以用来存储待发送数据的大小。

3. 图片中的示例

窗口大小：图中显示的发送窗口大小为 20 字节。这意味着发送方在没有收到确认的情况下，可以连续发送 20 字节的数据。
缓存区的划分
- 已发送已确认的数据（#1）：在左边界左侧，表示已经发送并且被接收方确认的数据。这些数据已经从发送方的缓存区中移除。
- ** 已发送但未确认的数据（#2）：在左边界和右边界之间的蓝色区域，表示已经发送但尚未收到接收方确认的数据。这些数据仍然在发送方的缓存区中。
- 即将发送的数据（#3）：在右边界左侧的绿色区域，表示可以立即发送的数据。这些数据在发送方的缓存区中等待发送。
- 未发送数据（#4）：在右边界右侧的黄色区域，表示由于接收方没有足够的缓存空间，不能发送的数据。这些数据在发送方的缓存区中等待发送机会。