HarmonyOS-ArkUI Web控件基础铺垫1-HTTP协议-数据包内容
HarmonyOS-ArkUI Web控件基础铺垫2-DNS解析
HarmonyOS-ArkUI Web控件基础铺垫3--TCP协议- 从规则本质到三次握手-CSDN博客
接上文，上文我们讲解了:
- 数据在四层网络岑层架构中流转方式
- 传输层存在的意义
- TCP协议具备的能力分析
- TCP数据包部分字段设计由来
- TCP建立连接的三次握手。
本文续上文讲。将TCP是如何断开连接的。
TCP的全双工
TCP连接是全双工的。双工的意思就是，同时可以进行信号的双向传输。也就是 A->B, 与 B->A可以同时发生。
我们在上文中其实提到过，TCP建立连接之前，会让操作系统为在内核区划分一些缓存。等到真正的建连之后，又会新建自己专门处理TCP事宜的缓冲区。这些缓存如果注意的话，您会发现均有一个，
- 发送缓冲区。
- 接收缓冲区。
开了俩缓冲区，就是为了更好的实现全双工！如图：
TCP协议，全生命周期中，都是按照全双工来处理的。包括三次握手这么早的操作也是全双工。 所以我们才会那么强调 发送包与响应包要--对得上，因为可能会收到"野包"！所以三次握手的时候，便强调了seq字段和ack字段的搭配规则，因为要用他们排除野包。
TCP断联，最主要断的是什么
TCP断开连接其实就是AB双方比较安全的不再对数据包进行处理的过程。确定了可以不再处理之后便可以释放自己本地的资源。我们知道了全双工这种支持，无论是A还是B，其代码运行时中必然会包含：
- 发送数据处理逻辑，以及运行时发送相关占用的资源，如内核中的发送缓冲区。
- 接收数据处理逻辑，以及运行时接收相关占用的资源，如内核中的接收缓冲区。
如下图所示，A和B如果他俩想断联，回收掉自己占用的资源，则必须打断二者通路：
而TCP中的断联，就是将这套全双工通路断联，也就是两个方向的传输全部断联！
断掉一个方向上的传输是由哪一方决定的？
答： 发送方！
断掉一个方向上的传输发起者，无非是发送方，和接收方。
- 假设发送方是发起者
- 发送方最了解自己的数据，什么时候结尾它最清楚！发完了就断联，也顺理成章。
- 假设接收方是发起者
- 接收方就是个被动接收者，着实不知道对方传来的数据是什么情况。 传没传完不知道，提前断联数据会丢失。 断联的太晚了，发送方数据早传输完了它还不断联，自己的资源被占用啥活也干不成。
综上，发起断联者必定是，发送方！
而 A 和 B这套系统里，因为是全双工工作， 他俩是互为发送方的！
仅断掉一个方向上的传输，怎么做？
那就是发送方向接收方发送一个数据， 这个数据里的内容可以让对方检测出，自己想要断掉这条连路，以后不会传输业务数据了！ 解决办法就是用 FIN 字段标记：
FIN为finish的缩写，表示发送方已经完成数据传输，并请求关闭连接。占用1个Bit位。其核心作用便是通知对端，本方向的数据传输已经结束了。
如图所示为单方向断掉连接发生的细节， 也是TCP四次挥手中，前两次挥手的细节！尤其要注意一下最左侧的红色备注，这个关系到对各个字段设置的理解：
上图中值得注意的是，第一次的挥手包， 我们的ACK=0， ack序列也是无效的。但是之后服务端处理的时候，它的ACK倒是1， ack也是正常的。 这是为什么呢？？如果您之前了解四次挥手，会晓得第三次挥手，服务端发过来的包ACK = 1 ！如下图为四次挥手的全部字段变化：
挥手 |
方向 |
SYN |
ACK |
FIN |
seq |
ack |
第一次挥手 |
A -> B |
0 |
0 |
1 |
a |
- |
第二次挥手 |
B -> A |
0 |
1 |
0 |
b |
a+1 |
第三次挥手 |
B -> A |
0 |
1 |
1 |
b+ n(半关闭数据长度) |
a+1 |
第四次挥手 |
A -> B |
0 |
1 |
0 |
a + 1 |
b+ n+ 1 |
因为断开联接是一个事务！不可被打断，不可被颠倒！
A第一次挥手的时候ACK=0， 既代表着A以后都不打算发送业务数据包了，这个包就是一个控制包，还是自己主动发起的！并且以此为TCP断开连接的起点。之后不容打断。。也就是假设A已经关闭了 A -> B的通路时候，万一收到一个包，这个包的格式正是服务端发起的第一次挥手包， 就直接被扔掉不予处理。避免混乱！
TCP全双工断联--四次挥手
到目前为止我们已经处理完一半了，如果具象化的话，现在A 和 B之间应是这样的场景！
也就是此时其实B仍然可以向A发数据的！可能有信息还没有传完，需要继续传输。 也可能也没什么数据好传了。但任务总有完成的那一刻。完工后便要发起 B -> A 方向的断联了！
接下来是第三次挥手和第四次挥手的流程：
四次挥手总结：
我们上文着重讲了下原理。下方为四次挥手的流程归纳：
第一次挥手（Client → Server）
字段值：SYN=0, ACK=0, FIN=1, seq=u, ack=v（无效）
- seq=u：u为客户端最后发送数据的下一字节序号（例：最后数据字节序号为100，则u=101）
- ACK=0：因主动发起关闭，无需确认对方数据
- FIN=1：触发关闭流程，占用1序列号（下次seq=u+1）
- 状态变化：Client →
FIN_WAIT_1
2. 第二次挥手（Server → Client）
字段值：SYN=0, ACK=1, FIN=0, seq=v, ack=u+1
- ack=u+1：确认客户端的FIN（FIN占1序列号，故+1）
- seq=v：v为服务器当前数据流位置（与客户端FIN无关）
- FIN=0：仅确认关闭请求，不立即关闭本方连接
- 状态变化：Server →
CLOSE_WAIT, Client →FIN_WAIT_2
3. 第三次挥手（Server → Client）
字段值：SYN=0, ACK=1, FIN=1, seq=w, ack=u+1
- seq=w：w = v + 半关闭期间数据长度（例：第二次挥手后发送80字节数据，则w=v+80）
- ack=u+1：仍为首次挥手的FIN确认（客户端无新数据）
- FIN=1：服务端数据发送完毕，关闭本方通道
- 状态变化：Server →
LAST_ACK
4. 第四次挥手（Client → Server）
字段值：SYN=0, ACK=1, FIN=0, seq=u+1, ack=w+1
- seq=u+1：首次挥手的FIN消耗序号u，故下一序号为u+1
- ack=w+1：确认服务端的FIN（FIN占1序列号，故w+1）
- ACK=1：必须置1以确认FIN
- 状态变化：Client →
TIME_WAIT（2MSL后关闭），Server →CLOSED
为什么挥手要四次
仍是一个八股问题。以下是贴的答案：
服务器在收到客户端的 FIN 报文段后，可能还有一些数据要传输，所以不能马上关闭连接，但是会做出应答，返回 ACK 报文段.
接下来可能会继续发送数据，在数据发送完后，服务器会向客户单发送 FIN 报文，表示数据已经发送完毕，请求关闭连接。服务器的ACK和FIN一般都会分开发送，从而导致多了一次，因此一共需要四次挥手。