首页手记为什么TCP建立连接协议是三次握手，而关闭连接却是四次...

为什么TCP建立连接协议是三次握手，而关闭连接却是四次握手呢？

标签：

Java 操作系统

看到了一道面试题：“为什么TCP建立连接协议是三次握手，而关闭连接却是四次握手呢？为什么不能用两次握手进行连接？”，想想最近也到金三银四了，所以就查阅了相关资料，整理出来了这篇文章，希望对你们有所帮助。

TCP 连接

我们先来补一下基础什么是 TCP 协议？传输控制协议（ Transmission Control Protocol, TCP ）是种面向连接、确保数据在端到端间可靠传输的协议。面向连接是插在发送数据前，需要先建立一条虚拟的链路，然后让数据在这条链路上“流动”完成传输。

TCP 是可靠的，会尽自己最大的努力去完成数据传输，TCP 协议比较复杂，可以看下面这张 TCP 协议的报文头图片：

内容非常的丰富，跟我们今天要讨论的连接协议相关的就是中间那六个状态位： URG、ACK、PSH、RST、SYN、FIN ，都置为 1 表示有效，在这六个当中，我们主要关注重点关注 ACK、SYN、FIN 这三个。下面解释一下这三个状态位：

ACK：用于对收到的数据进行确认，所确认的数据由确认序列号表示。

SYN：用作建立连接时的同步信号

FIN：表示后面没有数据需要发送，通常意昧着所建立的连接需要关闭了。

好了，到这里，TCP 的基础知识我们就知道了，下面我们就来看看为什么
是三次握手，而不是四次或者两次，为了让你更好的理解，我把知乎上一个高赞特别形象的比喻放在这里，希望对你有所帮助。

两次和四次都会出现问题，三次就刚刚好，希望这张图能够让你更好的理解为什么是三次握手。

我们已经知道了 TCP 协议是三次握手，为什么是三次握手呢？我们先来看看下面这张 TCP 协议建立连接的时序图。

总体来说就是呼叫、应答、回应，我们来详细的介绍每一步：

第一步： A 机器向 B机器发出一个数据包并将 SYN 设置为 1 ，表示希望建立连接。这个包中的序列号假设是 X。
第二步： B 机器收到 A机器发过来的数据包后，通过 SYN 得知这是一个建立连接的请求，于是发送一个响应包并将 SYN 、ACK 标记都置为 1。假设这个包中的序列号是 y ，而确认序列号必须是 x+l ，表示收到了发过来的 SYN，TCP 中， SYN 被当作数据部分的一个字节。
第三步： A 收到的响应包后需进行确认，确认包中将 ACK ，并将确认序列号设置为 y+ ，表示收到了来自B 的 SYN

经过这三步之后，两台服务器就建立连接了，可以进行通信数据传输了。为什么要三次握手呢？主要是为了信息对等和防止出现请求超时导致脏连接。

第一是为了保证两台机器信息对等，确保两台机器都没有什么问题：

只有三次握手之后才能够保证两台服务器都完全没有问题，各自具备发报和收报能力。

第二是防止出现请求超时导致脏连接，看下面这张图：

为什么会出现脏连接？因为TTL 网络报文的生存时间往往都会超 TCP 请求超时时间，如果两次握手就可以创建连接，传输数据并释放连接后，第一个超时的连接请求才到达 B 机器的话，B 机器会以为是 A 创建新连接的请求，然后确认同意创建连接。因为 A 机器的状态不是 SYl_SENT ，所以直接丢弃了 B 的确认数据，以致最后只是 B 机器单方面创建连接完毕。

三次握手就可以解决这个问题，因为需要 A 服务器确认了才真正的建立了连接。

TCP 四次挥手

上面介绍了 TCP 协议连接，有连接就有断开，相对于三次连接，断开却需要四次挥手，怎么理解呢？先看下面这个场景：

A：B 啊，我不想玩了。

B：哦，你不想玩了啊，我知道了。

这个时候，还只是 A 不想玩了，也即 A 不会再发送数据，但是 B 能不能在 ACK 的时候，直接关闭呢？当然不可以了，很有可能 A 是发完了最后的数据就准备不玩了，但是 B 还没做完自己的事情，还是可以发送数据的，所以称为半关闭的状态。

这个时候 A 可以选择不再接收数据了，也可以选择最后再接收一段数据，等待 B 也主动关闭。

B：A 啊，好吧，我也不玩了，拜拜。

A：好的，拜拜。

这就是一个完整的关闭连接，在这个关闭的过程中，一共说了四句话，我们也称之为四次挥手。跟建立连接一样，断开时也是用状态来表示，下面是断开的时序图：

我们结合上面的时序图和场景再来分析一下 TCP 断开过程。

当 A 说“不玩了”，A 就进入 FIN_WAIT_1 的状态，B 收到“A 不玩”的消息后，发送知道了，B 就进入 CLOSE_WAIT 的状态。

A 收到“B 说知道了”，就进入 FIN_WAIT_2 的状态，如果这个时候 B 直接跑路，则 A 将永远在这个状态。虽然 TCP 协议里面并没有对这个状态的处理，但是 Linux 有，可以调整 tcp_fin_timeout 这个参数，设置一个超时时间，最后 A 也会关闭的。

如果 B 没有跑路，发送了“B 也不玩了”的请求到达 A 时，A 发送“知道 B 也不玩了”的 ACK 后，从 FIN_WAIT_2 状态结束，按说 A 可以跑路了，但是最后的这个 ACK 万一 B 收不到呢？则 B 会重新发一个“B 不玩了”，这个时候 A 已经跑路了的话，B 就再也收不到 ACK 了，因而 TCP 协议要求 A 最后等待一段时间 TIME_WAIT，这个时间要足够长，长到如果 B 没收到 ACK 的话，“B 说不玩了”会重发的，A 会重新发一个 ACK 并且足够时间到达 B。

要求 A 等待 TIME_WAIT还有一个原因就是防止产生混乱，A 直接关闭了，但是这个时候 B是不知道的，可能在 A 关闭之前 B还发送了很多数据包，如果这时候 A 的端口被一个新的应用占用了的话，那么新的应用就会接收到上个连接中 B发送过来的数据包，这样就混乱了，虽然这个数据包是无效的，但是等待 TIME_WAIT 可以是一个双保险，因而也需要等足够长的时间，等到原来 B 发送的所有的包都死翘翘，再空出端口来。

以上就是 TCP 协议三次握手，四次挥手的原因，希望这篇文章对您的学习或者工作有所帮助，如果您觉得文章不错，还请您帮忙点个赞和转发，谢谢。