参考文章：https://blog.csdn.net/qq_38950316/article/details/81087809

文章目录

• 1、TCP头部结构
• 2、三次握手
• 3、四次挥手
• 4、为什么TCP连接的时候是三次？两次是否可以？
• 5、为什么TCP连接的时候是三次，关闭的时候却是四次？
• 6、TIME_WAIT和CLOSE_WAIT的区别在哪?
• 7、为什么客户端发出第四次挥手的确认报文后要等2MSL的时间才能释放TCP连接？
• 8、如果已经建立了连接，但是客户端突然出现故障了怎么办？
• 9、三次握手过程中可以携带数据吗？
• 10、各种状态的含义

---

1、TCP头部结构

在介绍三次握手与四次挥手之前我们先来了解一下TCP的头部结构是什么样的。

TCP头部的最大长度为60字节，其中包括TCP报文固定长度20字节+可变字节(最大40字节)，具体结构如下：

在认识三次握手与四次挥手之前我们必须要直到以下字段及含义：

• 序号：seq，占32位，用来标识从发送端到接收端发送的字节流。
• 确认号：ack，占32位，只有ACK标志位为1时，确认序号字段才有效，ack=seq+1。
• 标志位：
  • SYN：发起一个新连接。
  • FIN：释放一个连接。
  • ACK：确认序号有效。

在学习三次握手四次挥手后我们需要能流畅描述三次握手的流程及其中的字段含义作用的同时还需要记住每次握手时接收端和发送端的状态。

2、三次握手

在三次握手中发送端有CLOSED、SYN-SENT、ESTABLISHED三种状态，接收端有CLOSED、LISTEN、SYN-RCVD、ESTABLISHED四种状态。

三次握手过程如下图：

假设发送端为客户端，接收端为服务端。开始时客户端和服务端的状态都是CLOSE。

• 第一次握手：客户端向服务端发起建立连接请求，客户端会随机生成一个起始序列号x，客户端向服务端发送的字段中包含标志位SYN=1，序列号seq=x。
• 第一次握手前客户端的状态为CLOSE，第一次握手后：客户端的状态为SYN-SENT（等待一个匹配的连接请求），此时服务端的状态为LISTEN（等待从任何远端TCP 和端口的连接请求）。
• 第二次握手：服务端在收到客户端发来的报文后，会随机生成一个服务端的起始序列号y，然后给客户端回复一段报文，其中包括标志位SYN=1，ACK=1，序列号seq=y，确认号ack=x+1。
• 第二次握手前服务端的状态为LISTEN，第二次握手后服务端的状态为SYN-RCVD（等待连接请求确认），此时客户端的状态为
  SYN-SENT。
• 第三次握手：客户端收到服务端发来的报文后，会再向服务端发送报文，其中包含标志位ACK=1，序列号seq=x+1，确认号ack=y+1。
• 第三次握手前客户端的状态为SYN-SENT，第三次握手后客户端和服务端的状态都为ESTABLISHED（表示一个打开的连接，接收到的数据可以被投递给用户）。

需要注意的一点是:

1. 第一次握手，客户端向服务端发起建立连接报文，会占一个序列号。
2. 但是第三次握手，同样是客户端向服务端发送报文，这次却不占序列号.
3. 所以建立连接后，客户端向服务端发送的第一个数据的序列号为x+1。

3、四次挥手

客户端在四次挥手过程中有ESTABLISHED、FIN-WAIT-1、FIN-WAIT-2、TIME-WAIT、CLOSED等五个状态，服务端有ESTABLISHED、CLOSE-WAIT、LAST-ACK、CLOSED等四种状态。

四次挥手过程如下图：

假设客户端首先发起的断开连接请求

• 第一次挥手：客户端向服务端发送的数据完成后，向服务端发起释放连接报文，报文包含标志位
  FIN=1，序列号seq=u。此时客户端只能接收数据，不能向服务端发送数据。
• 第二次挥手：服务端收到客户端的释放连接报文后，向客户端发送确认报文，包含标志位ACK=1，序列号seq=v，确认号ack=u+1。此时客户端到服务端的连接已经释放掉，客户端不能像服务端发送数据，服务端也不能向客户端发送数据。但服务端到客户端的单向连接还能正常传输数据。
• 第三次挥手：服务端发送完数据后向客户端发出连接释放报文，报文包含标志位FIN=1，标志位ACK=1，序列号seq=w，确认号ack=u+1。
• 第四次挥手：客户端收到服务端发送的释放连接请求，向服务端发送确认报文，包含标志位ACK=1，序列号seq=u+1，确认号ack=w+1。

4、为什么TCP连接的时候是三次？两次是否可以？

答：不可以，主要从以下两方面考虑（假设客户端是首先发起连接请求）：

1. 假设建立TCP连接仅需要两次握手，那么如果第二次握手时，服务端返回给客户端的确认报文丢失了，客户端这边认为服务端没有和他建立连接，而服务端却以为已经和客户端建立了连接，并且可能服务端已经开始向客户端发送数据，但客户端并不会接收这些数据，浪费了资源。如果是三次握手，不会出现双方连接还未完全建立成功就开始发送数据的情况。
2. 如果服务端接收到了一个早已失效的来自客户端的连接请求报文，会向客户端发送确认报文同意建立TCP连接。但因为客户端并不需要向服务端发送数据，所以此次TCP连接没有意义并且浪费了资源。

5、为什么TCP连接的时候是三次，关闭的时候却是四次？

答：因为需要确保通信双方都能通知对方释放连接。

1. 假设客户端发送完数据向服务端发送释放连接请求，当客户端并不知道，服务端是否已经发送完数据，所以此次断开的是客户端到服务端的单向连接。
2. 服务端返回给客户端确认报文后，服务端还能继续单向给客户端发送数据。
3. 当服务端发送完数据后还需要向客户端发送释放连接请求。
4. 客户端返回确认报文，TCP连接彻底关闭。

所以断开TCP连接需要客户端和服务端分别通知对方并分别收到确认报文，一共需要四次。

6、TIME_WAIT和CLOSE_WAIT的区别在哪?

答：默认客户端首先发起断开连接请求，从上图可以看出：

• CLOSE_WAIT是被动关闭形成的，当客户端发送FIN报文，服务端返回ACK报文后进入CLOSE_WAIT。
• TIME_WAIT是主动关闭形成的，当第四次挥手完成后，客户端进入TIME_WAIT状态。

7、为什么客户端发出第四次挥手的确认报文后要等2MSL的时间才能释放TCP连接？

答：其中MSL的意思是报文的最长寿命，可以从两方面考虑：

1. 客户端发送第四次挥手中的报文后，再经过2MSL，可使本次TCP连接中的所有报文全部消失，不会出现在下一个TCP连接中。
2. 考虑丢包问题，如果第四挥手发送的报文在传输过程中丢失了，那么服务端没收到确认ack报文就会重发第三次挥手的报文。如果客户端发送完第四次挥手的确认报文后直接关闭，而这次报文又恰好丢失，则会造成服务端无法正常关闭。

可靠的实现TCP全双工连接的终止；
允许老的重复分节在网络中消逝。

8、如果已经建立了连接，但是客户端突然出现故障了怎么办？

答：如果TCP连接已经建立，在通信过程中，客户端突然故障，那么服务端不会一直等下去，过一段时间就关闭连接了。具体原理是TCP有一个保活机制，主要用在服务器端，用于检测已建立TCP链接的客户端的状态，防止因客户端崩溃或者客户端网络不可达，而服务器端一直保持该TCP链接，占用服务器端的大量资源(因为Linux系统中可以创建的总TCP链接数是有限制的)。

保活机制原理：设置TCP保活机制的保活时间keepIdle，即在TCP链接超过该时间没有任何数据交互时，发送保活探测报文；设置保活探测报文的发送时间间隔keepInterval；设置保活探测报文的总发送次数keepCount。如果在keepCount次的保活探测报文均没有收到客户端的回应，则服务器端即关闭与客户端的TCP连接。

9、三次握手过程中可以携带数据吗？

答：第三次握手的时候可以携带数据的，第一次、第二次握手不可以携带数据。

• 假如第一次握手可以携带数据的话，如果有人要恶意攻击服务器，那他每次都在第一次握手中的 SYN 报文中放入大量的数据，然后疯狂着重复发 SYN 报文的话，这会让服务器花费很多时间、内存空间来接收这些报文。也就是说，第一次握手不可以放数据，其中一个简单的原因就是会让服务器更加容易受到攻击了。
• 第一次、第二次握手都有SYN报文所以第一次、第二次握手都不可以携带数据。
• 而对于第三次的话，此时客户端已经处于 ESTABLISHED 状态。对于客户端来说，他已经建立起连接了，并且也已经知道服务器的接收、发送能力是正常的了，所以能携带数据也没啥毛病。

10、各种状态的含义

• CLOSED：不在连接状态（这是为方便描述假想的状态，实际不存在）
• LISTEN：等待从任何远端TCP 和端口的连接请求。
• SYN_SENT：发送完一个连接请求后等待一个匹配的连接请求。
• SYN_RCVD：发送连接请求并且接收到匹配的连接请求以后等待连接请求确认。
• ESTABLISHED：表示一个打开的连接，接收到的数据可以被投递给用户。连接的数据传输阶段的正常状态。
• FIN_WAIT_1：等待远端TCP 的连接终止请求，或者等待之前发送的连接终止请求的确认。
• CLOSE_WAIT：等待本地用户的连接终止请求。
• FIN_WAIT_2：等待远端TCP 的连接终止请求。
• LAST_ACK：等待先前发送给远端TCP 的连接终止请求的确认（包括它字节的连接终止请求的确认）。
• CLOSING：等待远端TCP 的连接终止请求确认。
• TIME_WAIT：等待足够的时间过去以确保远端TCP 接收到它的连接终止请求的确认。