TCP三次握手，四次挥手，再次总结

---

TCP和UDP协议基础

1. 协议位置：TCP和UDP协议都属于传输层。
2. 数据类型：数据可以是文件、视频、图片等多种形式。
3. TCP传输过程：包括三次握手、数据传输确认、四次挥手。

---

三次握手

1. 第一次握手：客户端发送一个SYN包，询问是否建立连接。

2. 第二次握手：服务端同意连接，回复一个SYN+ACK包。

3. 第三次握手：客户端收到之后，回复服务端一个ACK包，连接建立。

为什么需要三次握手？

• 目的：防止失效的请求报文，重新传输到服务端，造成错误。

• 风险：如果仅有两次握手，滞留的SYN可能恢复连接，导致：

  • 服务端又发送一个SYN+ACK包，再次进入传输状态。
  • 这时，客户端认为是一条连接。
  • 服务端认为是两条连接。
  • 双方状态不一致。

• 三次握手优势：通过序号机制判断SYN+ACK是否有效或过期，确保连接一致。

---

数据传输阶段

1. 可靠性：TCP协议能解决丢包问题和乱序问题。

2. 过程：

   • TCP会建立缓冲区，复制数据并分割，头部拼接序列号和长度。
   • ACK包用于确认接收的数据，并告知发送端下一段数据的序列号。
   • 发送端可以一次发送多个数据包，接收端只需回复一次ACK。
   • ACK包通常不携带实际的传输内容。它仅用于确认已接收到的内容。

3. 丢包处理：

   第一步 - 检测丢失的300-399数据：

   • 接收端收到部分数据后，发现序列号300-399的数据未完整，于是发送ACK=300。
   • 发送端收到ACK=300后，会重传序列号为300-399的数据。

   第二步 - 检测丢失的600-699数据：

   • 接收端成功接收并确认了300-399数据后，对后续数据进行检查。
   • 接收端发现序列号600-699的数据丢失，因此发送ACK=600。
   • 发送端收到ACK=600后，重新发送600-699的数据。

   逐步确认：

   • TCP协议中，接收端每次确认都是基于当前成功接收的数据，并通过ACK通知发送端下一段需要的数据。
   • 这种累积确认机制确保了丢失数据的准确定位和可靠重传。

---

四次挥手

1. 第一次挥手：客户端发送FIN包，表示关闭连接，进入终止等待1状态。
2. 第二次挥手：服务端收到FIN后发送ACK包，进入等待关闭状态；客户端进入终止等待2状态。
   • 服务端此时还可以发送未发送的数据
   • 客户端还可以接受数据
3. 第三次挥手：服务端传输完数据后发送FIN包，进入最后确认状态。
4. 第四次挥手：客户端收到FIN包后回复ACK包，进入超时等待状态，确保对方已收到ACK。超时后关闭连接。

为什么需要超时等待？

• 防止ACK包丢失。
• 若ACK包丢失，服务端会再次发送FIN包，客户端重发ACK，确保连接关闭。

为什么四次挥手不能减少到三次？

若合并为三次（如服务器收到FIN后立即发FIN+ACK）：
■ 服务器可能仍有数据未发送完，导致数据丢失。
■ 客户端无法区分FIN和ACK的合并响应，可能误判连接状态。

---