＜JavaEE＞ TCP 的通信机制（二） -- 连接管理（三次握手和四次挥手）

目录

TCP的通信机制的核心特性

三、连接管理

1）什么是连接管理？

2）“三次握手”建立连接

1> 什么是“三次握手”？

2> “三次握手”的核心作用是什么？

3）“四次挥手”断开连接

1> 什么是“四次挥手”？

2> 为什么需主动断开方要进入“TIME_WAIT”状态？

3> “TIME_WAIT”会等待多久？

4> “四次挥手”能否合并为“三次挥手”？

5> 被动断开方如果一直没有发送FIN，连接就一直不会关闭吗？

---

TCP的通信机制的核心特性

TCP的通信机制最核心的特性是可靠传输。
TCP至少通过以下机制来保证传输的可靠性，在保证可靠性的同时也采取一些机制来提升传输效率：
<1> 确认应答	<6> 阻塞控制
<2> 超时重传	<7> 延时应答
<3> 连接管理	<8> 捎带应答
<4> 滑动窗口	<9> 面向字节流
<5> 流量控制	<10> 异常情况处理

---

阅读指针 -> 《 TCP 的通信机制 -- 确认应答 和 超时重传 》＜JavaEE＞ TCP 的通信机制 -- 确认应答 和 超时重传-CSDN博客文章浏览阅读5次。介绍 TCP 的通信机制，确认应答和超时重传。https://blog.csdn.net/zzy734437202/article/details/135228875

---

三、连接管理

1）什么是连接管理？

连接管理是指，建立连接和断开连接。

在正常情况下，TCP需要经过“三次握手”建立连接，“四次挥手”断开连接。

2）“三次握手”建立连接

1> 什么是“三次握手”？

四个状态：

LISTEN：是TCP连接中，接收方监听等待接收连接的状态。

SYN_SENT：是TCP连接中，发送方第一次给接收方发送连接请求的状态。

SYN_RCVD：是TCP连接中，接收方收到连接请求并返回连接请求之后等待发送方应答的状态。

ESTABLISHED：是TCP连接中，连接准备就绪的状态。

两个数据报标志：

SYN：是同步报文段标志，用于请求建立连接。

ACK：确认标志，表示发来的数据已确认接收无误。

在正式建立TCP连接之前，需要通信的双方先完成三次特殊通信才能正式建立连接。

三次通信分别是：

<1> A端向B端发送SYN报文。

<2> B端成功接收A端发送的SYN报文，并返回ACK报文和SYN报文。至此可以确认A端发送功能正常。

<3> A端成功接收B端发送的ACK+SYN报文，并返回ACK报文。至此可以确认B端接收、发送功能正常，且A端接收功能正常。

2> “三次握手”的核心作用是什么？

<1> 测试当前通信路径是否通畅。

<2> 测试通信双方接收和发送的能力是否正常。

<3> 通信双方对一些通讯重要数据的协商。如序号、初始窗口大小等。

3）“四次挥手”断开连接

1> 什么是“四次挥手”？

六个状态：

FIN_WAIT_1：是TCP连接中，主动断开方第一次给对端发送断开连接请求的状态

CLOSE_WAIT ：是TCP连接中，被动断开方收到断开连接请求后，等待关闭连接的状态。

FIN_WAIT_2：是TCP连接中，主动断开方收到对端确认断开应答，等待对端发送断开连接请求的状态。

TIME_WAIT：是TCP连接中，主动断开方收到对端发送断开连接请求后，进入等待的状态。

LAST_ACK：是TCP连接中，被动断开方发送断开连接请求后，等待应答的状态。

CLOSING：是TCP连接中，通讯连接断开的状态。

两个数据报标志：

FIN：是结束报文段标志，用于通知对端，本端将结束通讯。

ACK：确认标志，表示发来的数据已确认接收无误。

在正式断开TCP连接之前，需要通信的双方先完成四次特殊通信才能正常断开连接。

四次通信分别是：

<1> A端向B端发送FIN报文。

<2> B端成功接收A端发送的FIN报文，并返回ACK报文。A端成功接收并继续等待B端FIN报文。

<3> B端发送FIN报文，A端成功接收。

<4> A端返回ACK报文。至此，B端在成功接收A端的ACK报文后，关闭连接。A端在等待一段时间没有其他情况后，关闭连接。

2> 为什么需主动断开方要进入“TIME_WAIT”状态？

TIME_WAIT是主动断开方在接收到对端的FIN报文后进入的状态。

在接收到这个FIN报文后，主动断开方会反馈一个ACK报文给对端。

如果这个返回的ACK报文丢失，被动断开方没有接收到，那么站在被动断开方视角，就是自己的FIN没有传达到。此时，被动断开方就会重新发送FIN报文。

主动断开方的TIME_WAIT状态，就是为了等待这一条可能发生的报文。但如果过了一段时间后，没有收到这条报文，主动断开方就会认为对端已经CLOSING，自然自己也就CLOSING了。

3> “TIME_WAIT”会等待多久？

MSL的概念：MSL是指TCP报文的最大生存时间，这个生存时间在每个系统上是不一样的，同时也是可以配置更改的。

TIME_WAIT状态会持续存在2MSL的时长。这个时长可以保证两个传输方向上尚未被接受或迟到的报文段都已经消失，同时也是理论上保证最后一个报文可靠到达。

简而言之，一来一回的报文最多存在这么长时间，这个时间内没收到，真的还有报文，也已经达到最大生存时间，报文就“消失”了。

4> “四次挥手”能否合并为“三次挥手”？

答案是不确定的，需要具体情况具体分析。

<1> 不会合并的场景。

将被动断开方的ACK和FIN分开传输的原因是，ACK应答报文是由系统内核响应的，而FIN是由应用程序代码调用close()方法触发的。

因此，两者的触发时间不同，且时间差距可能较大，并不适合合并在一起发送。

<2> 可能合并的场景。

在TCP众多机制中，为了控制窗口大小，提高传输效率，存在“延迟应答”的机制。这意味着，如果被动断开方的ACK报文还没发送时，触发了“延迟应答”的机制，那么后续的FIN报文就有可能和ACK报文合并发送。

5> 被动断开方如果一直没有发送FIN，连接就一直不会关闭吗？

主动断开方发送了FIN报文。被动断开方返回了ACK报文后，却一直没有发送FIN报文。

存在以下三种情况：

<1> 业务逻辑还未结束，被动断开方还在不断发送业务数据包给对端。

这种情况下，主动断开方可以感知对端还在通信，连接自然不会断开。

<2> 业务逻辑还未结束，被动断开方一直在处理业务，没有发送业务数据包给对端也没有发送FIN。

这种情况下，主动断开方无法感知对端是否还在。但是，TCP中还有“心跳包”机制，约定每隔一段时间通信双方就要进行一次没有业务数据的通信。因此，避免了一端还在处理数据，没来得及发送，另一端就断开了的情况。

<3> 被动断开方因为代码BUG或者通信问题，一直无法送达FIN。

这是一种异常情况，TCP也提供了一些处理异常情况的机制，如上文所说的“心跳包”机制等。因此，即使在异常情况下，连接仍然可以被关闭。

---

阅读指针 -> 《 TCP 的通信机制 -- 滑动窗口 》

＜JavaEE＞ TCP 的通信机制（三） -- 滑动窗口-CSDN博客介绍了 TCP 的通信机制 -- 滑动窗口https://blog.csdn.net/zzy734437202/article/details/135235928