【计算机网络】TCP三次握手，四次挥手以及SYN，ACK，seq，以及握手次数理解

TCP三次握手图解

---

描述

• 第一次握手：客户端请求建立连接，发送同步报文(SYN=1)，同时随机一个seq=x作为初始序列号，进入SYN_SENT状态，等待服务器确认

• 第二次握手：服务端收到请求报文，如果同意建立连接，则发送同步确认报文 (SYN=1，ACK=1)，确认号 ack=x+1，随机一个seq=y作为初始序列号，进入SYN_RECV状态

• 第三次握手：客户端收到服务端确认，发送确认报文(ACK=1)，确认号ack=y+1，序列号seq=x+1，双方都进入ESTABLISHED状态，完成三次握手

---

TCP 三次握手时各标志位（SYN、ACK、ack、seq）的变化

步骤	发送方	SYN	ACK	seq（序列号）	ack（确认号）	状态变化
① 第一次握手	客户端 → 服务器	1	0	x（随机初始值）	无	SYN_SENT（客户端等待服务器回应）
② 第二次握手	服务器 → 客户端	1	1	y（随机初始值）	x+1	SYN_RECV（服务器等待客户端确认）
③ 第三次握手	客户端 → 服务器	0	1	x+1	y+1	ESTABLISHED（连接建立成功）

---

各字段含义

• SYN（同步标志位）：用于建立连接，表示请求同步序列号。
• ACK（确认标志位）：表示确认前面接收到的数据。
• seq（序列号）：表示数据包的起始字节编号，保证数据按顺序传输。
• ack（确认号）：告诉对方你下一个数据要发的编号。

SYN 主要用于建立连接，ACK 用于确认数据，seq 和 ack 共同维护数据的顺序和完整性。

---

如何理解 TCP 的 seq（序列号）？

在 TCP 通信中，seq（序列号） 的作用是标识发送的数据字节流的顺序，确保数据包能按序到达，并且防止丢失和重复。

---

1. 在三次握手中的 seq 具体作用

在 TCP 三次握手 时，每一方都会选择一个随机的序列号 seq，作为自己即将发送数据流的起始编号，具体流程如下：

1️⃣ （第一次握手，客户端 → 服务器）

• 客户端 选择一个随机的初始序列号 x，并发送：

  SYN=1, seq=x
  

• 含义：请求建立连接，并告诉服务器，我的初始序列号是 x，从 x 号字节开始传输数据。

2️⃣ （第二次握手，服务器 → 客户端）

• 服务器 收到请求，同意建立连接，并选择一个自己的初始序列号 y，回复：

  SYN=1, ACK=1, seq=y, ack=x+1
  

• 含义：
  • seq=y：表示服务器选择的初始序列号是 y，数据从 y 号字节开始传输。
  • ack=x+1：告诉客户端：「我已经收到你的 SYN 请求，并确认你的序列号 x，下一次你发送数据时，请从 x+1 开始。」

3️⃣ （第三次握手，客户端 → 服务器）

• 客户端 收到服务器的确认后，回复：

  ACK=1, seq=x+1, ack=y+1
  

• 含义：
  • seq=x+1：客户端告诉服务器：「我将从 x+1 号字节开始发送数据。」
  • ack=y+1：告诉服务器：「我已经收到你的 SYN 请求，并确认你的序列号 y，你下次发送数据时，从 y+1 开始。」

✅ 至此，三次握手完成，双方建立可靠连接，可以开始数据传输。

---

结论

TCP 通过 seq（序列号）保证数据按顺序传输，不丢失，不重复，是 TCP 可靠传输的核心机制。
在三次握手中，seq 主要用于确定双方通信的起始位置，并避免历史连接数据混淆。

---

为什么需要三次握手，而不是两次？

如果只有两次握手，可能会导致历史连接请求的影响，从而引发服务器资源浪费或错误连接。

假设仅用两次握手：

1. 客户端发送 SYN（请求建立连接）
2. 服务器收到后直接发送 SYN-ACK 并建立连接
3. 但是客户端可能已经超时，不再理会这个连接

这样，服务器会一直等待客户端的数据，导致资源浪费，甚至出现**半连接（Half-Open Connection）**问题。因此，第三次握手（ACK） 能确保客户端确实收到了服务器的回应，并正式建立连接，避免这种情况。

• 情景：在双方两次握手即可建立连接的情况下，假设客户端发送 A 报文段请求建立连接，由于网络原因造成 A 暂时无法到达服务器，服务器接收不到请求报文段就不会返回确认报文段。

• 客户端在长时间得不到应答的情况下重新发送请求报文段 B，这次 B 顺利到达服务器，服务器随即返回确认报文并进入 ESTABLISHED 状态，客户端在收到 确认报文后也进入 ESTABLISHED 状态，双方建立连接并传输数据，之后正常断开连接。

• 此时姗姗来迟的 A 报文段才到达服务器，服务器随即返回确认报文并进入 ESTABLISHED 状态，但是已经进入 CLOSED 状态的客户端无法再接受确认报文段，更无法进入 ESTABLISHED 状态，这将导致服务器长时间单方面等待，造成资源浪费。

---

为什么是三次，而不是四次？

三次握手让双方确认通信能力：

所谓确认通信能力就是双方都确认对方和自己的收发能力正常

• 在第一次握手 A确认自己可以发，B确认A可以发，自己可以收，发

• 第二次，A确认自己可以发可以收，B可以收可以发，但是此时B还不能确认A可以收，

• 所以有了第三次，此时，双方都确认对方和自己的收发能力正常

如果是四次握手：

• 额外的一次确认没有实际意义，因为三次握手已经确保了双方的通信能力。

• 额外的开销会降低效率，没有必要增加额外的握手步骤。

结论：

• 两次握手不够安全，可能导致服务器误认为连接已建立。

• 三次握手足够确保双方都能正常通信，并防止历史连接问题。

• 四次握手是多余的，没有额外的安全或可靠性提升，因此 TCP 采用三次握手。

---

TCP四次挥手图解

描述

• 第一次挥手：客户端向服务端发送连接释放报文（FIN=1，ACK=1），主动关闭连接，同时等待服务端的确认。
  序列号 seq = u，即客户端上次发送的报文的最后一个字节的序号 + 1
  确认号 ack = k, 即服务端上次发送的报文的最后一个字节的序号 + 1
• 第二次挥手：服务端收到连接释放报文后，立即发出确认报文（ACK=1），序列号 seq = k，确认号 ack = u + 1。
  这时 TCP 连接处于半关闭状态，即客户端到服务端的连接已经释放了，但是服务端到客户端的连接还未释放。这 表示客户端已经没有数据发送了，但是服务端可能还要给客户端发送数据。
• 第三次挥手：服务端向客户端发送连接释放报文（FIN=1，ACK=1），主动关闭连接，同时等待 A 的确认。
  序列号 seq = w，即服务端上次发送的报文的最后一个字节的序号 + 1。
  确认号 ack = u + 1，与第二次挥手相同，因为这段时间客户端没有发送数据
• 第四次挥手：客户端收到服务端的连接释放报文后，立即发出确认报文（ACK=1），序列号 seq = u + 1，确认号为 ack = w + 1。

此时，客户端就进入了 TIME-WAIT 状态。注意此时客户端到 TCP 连接还没有释放，必须经过 2*MSL（最长报文段寿命）的时间后，才进入 CLOSED 状态。而服务端只要收到客户端发出的确认，就立即进入 CLOSED 状态。可以看到，服务端结束 TCP 连接的时间要比客户端早一些。

---

为什么连接的时候是三次握手，关闭的时候却是四次握手？

服务器在收到客户端的 FIN 报文段后，可能还有一些数据要传输，所以不能马上关闭连接，但是会做出应答，返回 ACK 报文段.

接下来可能会继续发送数据，在数据发送完后，服务器会向客户单发送 FIN 报文，表示数据已经发送完毕，请求关闭连接。服务器的ACK和FIN一般都会分开发送，从而导致多了一次，因此一共需要四次挥手。

为什么客户端的 TIME-WAIT 状态必须等待 2MSL ？

主要有两个原因：

1. 确保 ACK 报文能够到达服务端，从而使服务端正常关闭连接。

   第四次挥手时，客户端第四次挥手的 ACK 报文不一定会到达服务端。服务端会超时重传 FIN/ACK 报文，此时如 果客户端已经断开了连接，那么就无法响应服务端的二次请求，这样服务端迟迟收不到 FIN/ACK 报文的确认，就无法正常断开连接。

   MSL 是报文段在网络上存活的最长时间。客户端等待 2MSL 时间，也就是两次报文发送时间：
   假设客户端在传最后的ACK报文，但是没有发给服务端，然后服务端在这1MSL中没有接到客户端的ACK报文，于是再次发送FIN报文耗时1MSL打到客户端，刚好2MSL，客户端可以重新回应，而不至于在不等这2MSL的情况下直接关机

   如果服务端重发的 FIN 没有成功地在 2MSL 时间里传给客户端，服务端则会继续超时重试直到断开连接。

2. 防止已失效的连接请求报文段出现在之后的连接中。

   TCP 要求在 2MSL 内不使用相同的序列号。客户端在发送完最后一个 ACK 报文段后，再经过时间 2MSL，就可以保证本连接持续的时间内产生的所有报文段都从网络中消失。这样就可以使下一个连接中不会出现这种旧的连接请求报文段。或者即使收到这些过时的报文，也可以不处理它。

---

TIME-WAIT 状态过多会产生什么后果？怎样处理？

• 服务端： 短时间内关闭了大量的Client连接，就会造成服务器上出现大量的TIME_WAIT连接，严重消耗着服务器的资源，此时部分客户端就会显示连接不上。

• 客户端：客户端TIME_WAIT过多，就会导致端口资源被占用，因为端口就65536个，被占满就会导致无法创建新的连接。

• 解决办法：

• 服务端：设置 SO_REUSEADDR 套接字选项来避免 TIME_WAIT状态，此套接字选项告诉内核，即使此端口正忙（处于TIME_WAIT状态），也请继续并
  重用它。

• 客户端：动态选择不同的源端口，避免因 TIME-WAIT 过多导致端口耗尽

---

https://github.com/0voice