TCP的三次握手和四次挥手

基本概念

SYN（Synchronize Sequence Numbers，同步序列数字）：用于建立连接的同步信号。

SYN 序列号的作用是用于标识每个数据包中的字节流的起始位置。在 TCP 连接的建立过程中，双方会约定一个初始的序列号（标准的TCP连接中都是设置为初始序列号都是设置为1），相当于起始字节流的编号。每个数据包都附带有一个序列号字段，在传输过程中不断递增，用于指示数据包中字节的位置。

通过使用 SYN 序列号，双方能够确保数据包的顺序和完整性。接收方可以根据序列号信息验证数据包的顺序，并进行数据重组和重传操作。因此，SYN 序列号在 TCP 连接的建立和数据传输过程中起到了重要的同步和校验作用。
SEQ（Sequence Number）：用于标识发送方发送的数据包的序列号。

它是一个32位的无符号整数，序列号的作用是保证TCP连接中数据包的顺序性和可靠性。发送方在发送数据时，会为每个数据包分配一个唯一的序列号。接收方在接收到数据包后，可以通过序列号来确定接收到的数据包的顺序，并进行重组。
ACK（Acknowledgement，确认）：用于确认应答。

字段等于1的含义是，表示接收方已经正确地收到了对方发送的SYN（同步序列编号）字段。需要注意的是ACK字段并不是固定等于1的，它可以根据具体的场景和TCP协议的版本进行调整。但是在标准的TCP三次握手过程中，ACK字段等于1是一种常见的设置方式。
FIN（Finish，完成）：用于表示后面没有数据发送了，通常意味着连接的断开。

当一方希望关闭连接时，会发送一个带有FIN = 1的数据包给对方，表示自己不再发送数据了，并请求对方关闭连接。

三次握手

理解性记忆：想要别人回复都需要设置 SYN（SYN值为1），发送请求都需要设置 seq（seq值为接收请求 ACK 的值，上一次请求没有 ACK 就自己设置一个值），回复请求都需要设置 ACK（ACK的值为接收请求 seq 的值 + 1）。

总结就是：所有的请求都必须有 seq，非最后一次请求都必须有 SYN，非第一次请求都必须有 ACK 和 ack

每次握手的含义：
- 第一次握手：A发送消息给B，“我想当你男朋友，你愿意吗？”
- 第二次握手：B回复消息给A，“我愿意！”
- 第三次握手：A回复消息给B，“我现在知道你愿意当我女朋友了”，于是 A 和 B 建立了男女朋友关系
第一次握手，A表达了想和B建立连接的意愿；第二次握手，B表达了自己的意愿；第三次握手，A告诉B他已经知道了B的意愿。

PS：A（客户端，扮演男朋友角色），B（服务端，扮演女朋友角色）
现在我们再来推敲一下为什么必须是三次握手，不能是1次、2次或4次握手？
- 如果是一次握手，那么 A 只是表达了自己的意愿，并不知道 B 的意愿，所以他们无法直接就建立男女朋友关系，要不然你随便和一个陌生女孩表白，那你们就建立男女朋友关系了，这显然不太可能吧🤣；
- 如果是两次握手，那么A表达了自己的意愿，B也表达了自己的意愿，但是此时，A知道B的意愿，但B并不知道A是否知道知道自己的意愿，这样会存在安全隐患，以及出现脏连接¹，因为 B 并不知道 A 是否知道他是否知道自己的意愿，就会默认他知道自己的意愿，于是就进行了交往，但却殊不知 A 没收到 B 的请求，也就是 A 不知道 B 同意了自己的交往请求，于是 A 秉持着不在一个棵树上吊死的精神，移情别恋了，这就导致 B 后续的请求直接落了个空；
- 如果是四次握手，其实在第三次握手时就能够确保 A 和 B 都表达了自己的意愿，而 A 和 B 也都知道了双方的意愿，第四次握手就显得有些冗余了；
综上所诉，三次握手的是保障双方信息对等，同时避免出现连接超时导致出现脏连接的最少握手次数，多一次握手多余，浪费资源，少一次握手不安全，而握手三次不多不少刚刚好

现在再来讲一讲什么是脏连接，为什么两次握手就会导致出现脏连接，所谓的脏连接（Dirty Connection）是指在网络通信中，由于某种原因导致连接状态出现异常或错误的情况。

常见的导致出现脏连接的情况有：
- 网络中断或故障：当网络中断或发生故障时，连接可能会被意外中断，但是连接的状态却没有及时更新。这导致连接状态变为脏连接，无法正常传输数据。
- 服务器或客户端崩溃：如果服务器或客户端在连接过程中崩溃或异常终止，连接状态可能无法正确清理和关闭，从而产生脏连接。
- 防火墙或网络设备问题：防火墙或其他网络设备配置不正确、软件故障或过滤规则错误等问题可能导致连接被错误地阻塞或终止，造成脏连接。
- 应用程序错误：应用程序编码错误、资源管理问题或逻辑错误可能导致连接处理不当，使连接处于脏的状态。
脏连接的危害：
- 占用服务器资源：脏连接可能占用服务器资源，如内存、CPU等，导致性能下降。
- 数据传输异常：脏连接可能导致数据丢失、错乱甚至数据冲突。
- 安全隐患：脏连接可能被黑客利用进行未授权访问、攻击或其他恶意行为。

如果我们采用了两次握手，客户端发送请求给服务端，服务端收到客户端的请求，由于省掉了第三次握手，所以此时服务端在接收到客户端的请求之后单方面认为客户端接收到了自己的回复，服务端开启了TCP连接（此时的连接变成了半双工²连接了，而TCP是全双工³连接），但此时客户端可能并没有接收到服务端的连接，此时服务端的回复就有可能被第三发截取，从而造成安全事故。（这个单向的TCP连接是一个脏连接，因为它处于一个异常的连接状态）

注意：并不是说使用三次握手就能完全避免脏连接，只是说通过三次握手能大幅度降低脏连接发生的概率

四次挥手

理解性记忆：请求需要断开连接时，必须设置 FIN（FIN值为1），发送请求都需要设置 seq（seq值为接收请求的 ACK 值，如果是第一次请求就自己设置一个值），回复请求都需要设置 ACK（ACK 的值为接收请求 seq 的值 + 1）

总结就算：所有请求都必须有 seq，断开连接的请求需要设置 FIN（一次FIN断开一半），非第一次请求都必须有 ACK 和 ack

每次挥手的含义：
- 第一次挥手，A发送请求给B，“我想和你中断关系，你同意吗？”
- 第二次挥手，B发送请求给A，“我同意了，断开连接前，你先等我收拾一下我的东西，然后回娘家”
- 第三次挥手，B发送请求给A，“我东西收拾好了，回娘家了”
- 第四次挥手，A发送请求给B，“知道了”（客户端真是一个无情无义的渣男🤣，关系建立是他提出的，关系结束也是他提出的）
第一次挥手，A表达了自己要中断夫妻关系的意愿；第二次挥手，B了解了A的意愿同时表达了自己的意愿；第三次挥手，B表达了自己已经东西回娘家的准备；第四次挥手表示A告诉B，自己已经知道他收拾好东西了（这个第四次握手和之前的第三次挥手作用是类似的）

PS：A（客户端，扮演老公角色），B（服务端，扮演老婆角色）
为什么一定是四次挥手，不能是1次、2次、3次、5次？
- 如果我们少了第二次挥手，直接进行第三次挥手，那么此时服务端B可能就准备释放一些资源，同时将之前一些准备好的资源发送给A，但是由于缺少第二次挥手，客户端A并不知道此时服务端B已经释放了一些资源，此时数据请求还是双向的，客户端还可以会发送一些请求给服务端B，但是服务端已经关闭了资源，这就导致了请求异常；第二次挥手是为了给服务端预留关闭资源和释放资源的时间，这个时间端数据只能是服务端B发送给客户端A，客户端A不能发送数据给服务端B，不然就会发生异常导致连接无法正常关闭；
- 如果我们少了第三次挥手，那就更加离谱了，B还没完全关闭释放资源，客户端A就直接单方面断开连接了，这就导致了还有一些没有发送出去的资源的浪费；
- 如果我们少了第四次挥手，这个就和之前的第三次握手是一样的，容易出现脏连接，即：服务端B在没有确定客户端A已经收到自己（资源关闭完成的）请求时进行了单方面的连接断开，而如果此时B的请求在中断发生了丢失，就会导致A一直处于等待状态，造成资源浪费
其实这个和之前的三次握手是差不多的，这里就只简单介绍一下，首先我们需要明确四次挥手是能够保障信息对等，同时避免数据的丢失和资源的浪费的最少挥手次数，挥手次数过少，信息不对等，容易出现数据丢失和资源浪费，挥手次数过多浪费资源，而四次不多不少刚刚好O(∩_∩)O
为什么第四次挥手客户端需要等待 2*MSL（报文段最长寿命）时间后才进入 CLOSED 状态？

客户端A发送给服务端B的ACK请求，可能会发生丢失，此时服务端B会重新发送请求，而网络中报文的最大生存时间通常是 2mls，也就是说如果服务端 B 在 2mls 后没收到客户端A 的确认请求，就会重新发送 FIN 请求（也就是关闭连接请求）。如果客户端A此时没有这个 2mls 的等待时间直接关闭，就会出现 A 关闭连接，但是 B 一直无法收到 A 的 ACK 出现脏连接（也就是一直向A发送FIN请求）