21天 - 说说 TCP 的四次挥手？TCP 的粘包和拆包能说说吗？说说 TCP 拥塞控制的步骤？

• 说说 TCP 的四次挥手？

  TCP 协议是一种面向连接的、可靠的、基于字节流的传输层通信协议，它通过著名的 “三次握手” 来建立连接。相对地，TCP 协议通过四次挥手来断开连接。以下是四次挥手的详细过程：

  第一次挥手（Client → Server）

  • 步骤描述：客户端发送一个带有FIN标志位的数据包给服务器，表示客户端已经没有数据要发送了，希望关闭连接。此时，客户端进入FIN_WAIT_1状态。
  • 状态变化：客户端从ESTABLISHED状态变为FIN_WAIT_1状态。
  • 数据传输：客户端停止发送数据，并发送FIN包。

  第二次挥手（Server → Client）

  • 步骤描述：服务器收到客户端的FIN包后，发送一个带有ACK标志位的数据包作为应答，表示已经收到了客户端的关闭请求。服务器进入CLOSE_WAIT状态。
  • 状态变化：服务器从ESTABLISHED状态变为CLOSE_WAIT状态。
  • 数据传输：服务器发送ACK包，确认序号为收到的序号加1。

  第三次挥手（Server → Client）

  • 步骤描述：服务器在完成自己的数据发送后，也发送一个带有FIN标志位的数据包给客户端，表示服务器也没有数据要发送了，希望关闭连接。服务器进入LAST_ACK状态。
  • 状态变化：服务器从CLOSE_WAIT状态变为LAST_ACK状态。
  • 数据传输：服务器发送FIN包。

  第四次挥手（Client → Server）

  • 步骤描述：客户端收到服务器的FIN包后，发送一个带有ACK标志位的数据包作为应答，表示已经收到了服务器的关闭请求。客户端进入TIME_WAIT状态，等待一段时间后，连接正式断开。
  • 状态变化：客户端从FIN_WAIT_1状态变为TIME_WAIT状态，最后变为CLOSED状态。
  • 数据传输：客户端发送ACK包，确认序号为收到的序号加1。

  总结

  • 客户端：发送FIN → 收到ACK → 发送ACK → 收到ACK → 进入TIME_WAIT → 进入CLOSED
  • 服务器：收到FIN → 发送ACK → 发送FIN → 收到ACK → 进入CLOSED

  通过这四次挥手，TCP 连接被优雅地断开，确保了数据传输的完整性和可靠性。

• TCP 的粘包和拆包能说说吗？

  在 TCP 通信中，粘包和拆包是两个常见的问题，它们是由于 TCP 协议的特性所导致的。TCP 是一种面向连接的、可靠的、基于字节流的传输层通信协议，它将数据视为一连串的字节流，而不关心数据的边界。这就可能导致了粘包和拆包的现象。

  粘包（Packet Coalescing）

  粘包是指当多个小的数据包连续发送时，TCP 可能会将这些小包合并成一个较大的数据包进行传输。这通常是为了提高网络传输效率，减少发送和接收的次数。然而，这对于接收端来说，可能会导致难以区分不同的数据包，因为接收端无法直接知道每个小包的边界。

  拆包（Packet Fragmentation）

  拆包是指一个较大的数据包在传输过程中被分割成多个较小的数据包。这通常发生在数据包的大小超过了网络中某个设备的 MTU（最大传输单元）时。拆包后的数据包在到达接收端时需要重新组装，这同样可能导致数据的边界问题。

  解决方法

  为了解决粘包和拆包的问题，通常需要在应用层协议中添加额外的机制来明确数据的边界。以下是一些常见的解决方法：

  1. 固定长度的消息格式

  • 原理：规定每条消息的长度为固定值。接收端根据这个固定长度来读取数据，从而避免粘包和拆包的问题。
  • 示例：如果每条消息的长度固定为 100 字节，那么接收端每次读取 100 字节的数据，就可以正确地解析出每条消息。

  2. 添加特殊分隔符

  • 原理：在每条消息的末尾添加一个特殊的分隔符（如换行符 \n、回车符 \r 或其他自定义的特殊字符）。接收端在读取数据时，根据这个分隔符来判断消息的边界。
  • 示例：在发送数据时，在每条消息后添加 \n，接收端在读取数据时，每当遇到 \n 就认为是一条完整的消息。

  3. 长度前缀

  • 原理：在每条消息的前面添加一个表示消息长度的字段（如 2 字节或 4 字节的长度信息）。接收端先读取长度字段，然后根据这个长度来读取完整的消息。
  • 示例：如果每条消息的前面 2 字节表示消息的长度，接收端先读取这 2 字节，得到长度值后，再读取相应长度的数据，从而正确解析出消息。

  4. 使用自定义的协议头

  • 原理：设计一个自定义的协议头，包含消息的长度、类型等信息。在每条消息的前面添加这个协议头，接收端根据协议头中的信息来解析消息。
  • 示例：协议头可以包含消息长度、消息类型等字段，接收端根据协议头中的消息长度来读取消息内容。

  通过以上方法，可以在应用层对数据进行适当的处理，从而解决 TCP 通信中的粘包和拆包问题，确保数据的正确解析和处理。

• 说说 TCP 拥塞控制的步骤？

TCP 拥塞控制是 TCP 协议为了提高网络性能、避免网络拥塞而采用的一系列算法。以下是 TCP 拥塞控制的主要步骤和算法：

1. 慢开始（Slow Start）

• 目的：慢开始的目的是在 TCP 连接建立之初，通过逐渐增加拥塞窗口的大小来探测网络的可用带宽，避免网络出现拥塞。
• 过程：
  • 初始时，拥塞窗口（cwnd）被设置为一个较小的值，通常是 1 个最大报文段（MSS）的大小。
  • 每当收到一个ACK确认，拥塞窗口就会增加 1 个 MSS 的大小。这意味着每经过一个往返时间（RTT），拥塞窗口会呈指数级增长。
  • 这种指数增长会一直持续，直到拥塞窗口达到一个称为慢开始阈值（ssthresh）的值。

2. 拥塞避免（Congestion Avoidance）

• 目的：当拥塞窗口增长到慢开始阈值后，进入拥塞避免阶段。此时，拥塞窗口的增长方式从指数增长变为线性增长，以更谨慎地探测网络的拥塞情况。
• 过程：
  • 在拥塞避免阶段，每当收到一个 ACK 确认，拥塞窗口会增加 1/cwnd 个 MSS 的大小。这意味着每经过一个 RTT，拥塞窗口会增加 1 个 MSS 的大小。
  • 这种线性增长会一直持续，直到网络出现拥塞的迹象。

3. 快速重传（Fast Retransmit）

• 目的：快速重传是一种机制，用于在检测到数据丢失时快速重新发送丢失的数据，减少因等待超时重传而导致的延迟。
• 过程：
  • 当发送方收到三个重复的 ACK 确认（即同一个序列号的 ACK 被收到三次），它认为对应的报文段可能已经丢失。
  • 发送方立即重传丢失的报文段，而不需要等待重传计时器超时。
  • 同时，发送方将慢开始阈值设置为当前拥塞窗口的一半，并将拥塞窗口重置为 1 个 MSS，进入慢开始阶段。

4. 快速恢复（Fast Recovery）

• 目的：快速恢复是在快速重传之后进入的一个阶段，用于更有效地恢复拥塞窗口的大小，避免网络长时间处于低效利用状态。
• 过程：
  • 在快速重传后，发送方进入快速恢复阶段。此时，拥塞窗口被设置为慢开始阈值的一半。
  • 发送方每收到一个 ACK 确认，拥塞窗口会增加 1 个 MSS 的大小。
  • 当拥塞窗口达到慢开始阈值时，发送方退出快速恢复阶段，进入拥塞避免阶段。

总结

TCP 拥塞控制通过慢开始、拥塞避免、快速重传和快速恢复这四个步骤，动态调整拥塞窗口的大小，以适应网络的拥塞情况，提高网络性能和数据传输的可靠性。这些算法共同作用，使得 TCP 能够在不同的网络条件下有效地利用带宽，减少丢包和重传，提供可靠的端到端数据传输服务。