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 主要用于确定双方通信的起始位置，并避免历史连接数据混淆。
为什么需要三次握手，而不是两次？
如果只有两次握手 ，可能会导致历史连接请求的影响，从而引发服务器资源浪费或错误连接。
假设仅用两次握手：
- 客户端发送 SYN（请求建立连接）
- 服务器收到后直接发送 SYN-ACK 并建立连接
- 但是客户端可能已经超时，不再理会这个连接
这样，服务器会一直等待客户端的数据，导致资源浪费，甚至出现**半连接（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 ？
主要有两个原因：
-
确保 ACK 报文能够到达服务端，从而使服务端正常关闭连接。
第四次挥手时，客户端第四次挥手的 ACK 报文不一定会到达服务端。服务端会超时重传 FIN/ACK 报文，此时如 果客户端已经断开了连接，那么就无法响应服务端的二次请求，这样服务端迟迟收不到 FIN/ACK 报文的确认，就无法正常断开连接。
MSL 是报文段在网络上存活的最长时间。客户端等待 2MSL 时间，也就是两次报文发送时间：
假设客户端在传最后的ACK报文，但是没有发给服务端，然后服务端在这1MSL中没有接到客户端的ACK报文，于是再次发送FIN报文耗时1MSL打到客户端，刚好2MSL，客户端可以重新回应，而不至于在不等这2MSL的情况下直接关机
如果服务端重发的 FIN 没有成功地在 2MSL 时间里传给客户端，服务端则会继续超时重试直到断开连接。
-
防止已失效的连接请求报文段出现在之后的连接中。
TCP 要求在 2MSL 内不使用相同的序列号。客户端在发送完最后一个 ACK 报文段后，再经过时间 2MSL，就可以保证本连接持续的时间内产生的所有报文段都从网络中消失。这样就可以使下一个连接中不会出现这种旧的连接请求报文段。或者即使收到这些过时的报文，也可以不处理它。
TIME-WAIT 状态过多会产生什么后果？怎样处理？
-
服务端： 短时间内关闭了大量的Client连接，就会造成服务器上出现大量的TIME_WAIT连接，严重消耗着服务器的资源，此时部分客户端就会显示连接不上。
-
客户端：客户端TIME_WAIT过多，就会导致端口资源被占用，因为端口就65536个，被占满就会导致无法创建新的连接。
-
解决办法：
-
服务端：设置 SO_REUSEADDR 套接字选项来避免 TIME_WAIT状态，此套接字选项告诉内核，即使此端口正忙（处于TIME_WAIT状态），也请继续并
重用它。 -
客户端：动态选择不同的源端口，避免因 TIME-WAIT 过多导致端口耗尽