三次握手四次挥手

• 2020 年 6 月 28 日
• 筆記

一直都知道 TCP 建立连接时需要三次握手，释放连接时需要四次挥手，也大概能说出整个过程，但是一直对其中的设计思想理解不深，停留在“只可意会，不可言传”的阶段。这次写一篇博客尝试将其中的思想表达出来。

TCP 建连三次握手

首先解释一下每个步骤的作用：
1、a 时刻，A 准备就绪，发送 SYN 包给 B，尝试建立连接
2、b 时刻，B 收到 A 发来的 SYN 包，知道 A 要请求建连，回 SYN ACK 包，告诉 A 自己收到了建连请求，可以建连了
3、c 时刻，A 收到了 B 的回复，知道 B 准备好了，链路通畅，可以发送数据了。回  ACK 告知 B 收到了 B 的回复，下面要开始发送该数据了
4、d 时刻，B 收到了 A 的回复，知道 A 接下来要发数据了。至此，AB 双方都确认整个链路已经可靠了，接下来可以发送数据了。

为什么要多次确认呢？为什么不可以 A 上来就直接发送数据给 B 呢？
这里首先要明确一点，TCP 是传输层的协议，是建立在物理层、数据链路层、网络层之上的协议，而底层的网络是不可靠的，可能路由出问题，可能网关出问题，可能网线出问题，A 没法保证自己发出来的消息 B 一定能收到，所以一定要反馈机制，即 ACK，这样才能在不可靠的网络层智商构建可靠的传输层。

类比一下生活中的例子，可以帮助我们理解
示例1，假设我们在火车上打电话，通话质量很差，我们的通话过程可能会是下面这样：

AB 双方首先需要确认彼此都能挺到对方的声音，也就是保证电话通道是可靠的，之后才会开始说正事。如果一上来就直接说正事，可能 A 说完之后 B 根本就没有听到。
实际打电话过程中，如果遇到了断线的情况，双方可能需要进行多次“握手”确认。

示例2，假设我们给刚认识的人第一次打电话，通话过程可能是下面这样：

AB 双方都要确认对方的身份，也就是保证通话是在跟自己人进行，确保电话通道是可靠的，不是跟骗子通话，然后才会开始说正事。如果一上来没有确认身份，不能保证通道是跟自己人进行的，那直接说出重要的事，很可能就泄漏了机密。

总之，握手过程的最终目的就是保证双方都准备就绪，通路是可靠的，之后就可以放心的发送重要数据了。

那为什么一定是三次呢，为什么不是两次或者四次呢？
先来说一下为什么不能少。
一次可以吗？不可以。设想一下，A 对 B 说：我要给你发数据。然后不等 B 的回复，接下来就开始发数据了。这时候根本不能保证 B 已经准备好了，那 A 发出来的数据就没法保证 B 一定能收到。联想生活中的场景，你隔着很远的距离向对方喊话：我要把苹果扔给你。然后不关心对方有没有听到，就直接扔了，那最终的结果通常就是对方接不到苹果，因为对方可能根本没有收到消息。
两次可以吗？不可以。设想一下，A 对 B 说：我要给你发数据，然后 B 收到消息后给 A 回复：收到，A 在收到 B 的回复后开始发送数据。这时候 A 端是可以准备就绪的，但是 B 端不知道 A 端当前的状态。因为 B 在收到 A 的消息的时候，可能已经过去了很长时间，B 在回消息的时候，A 可能已经不在线了，此时 B 是不能直接发数据的。如果 A 再给 B 回一个 ACK，B 就可以确认当前链路状态了，这就变成了三次握手。

接下来说一下为什么不是四次。既然三次已经可以保证建立可靠通信，就不需要额外的一次交互了。

下面是几个生活中相关的示例：

 TCP 断链四次挥手
1、a 时刻，A 向 B 发出 FIN 包，表示自己没有数据要发送了
2、b 时刻，B 收到 FIN 包，回复 FIN ACK，表示收到了 A 的 FIN 包，不会再接收 A 的数据了
3、B 在发完 FIN ACK 后，可能还有数据要发给 A，这个数据是不能停止发送的，有数据还是需要继续发送
4、d 时刻，B 发完了数据，也发出 FIN 包，告诉 A 自己的数据发完了，不再发送数据了
5、e 时刻，A 收到了 B 的 FIN 包，知道 B 也没有数据要发送了，回复 FIN ACK。此时，连接可以断开了

建连只需要交互三次，断连却需要四次，这是为什么呢？其实断开连接和建立连接还是不一样的。建连的时候，只要双方都告知对方自己准备好了就可以，但是断连的时候，一方提出要断开连接，不再发数据，另一方不能立即断开，因为这一方可能还有数据要发送，直到数据全部发送完成后才能确认断开。

下面是几个生活中相关的示例：

以上是对于三次握手、四次挥手的简单介绍，里面没有更详细的状态介绍，之后的博客会介绍，这里先放两张图。
TCP 三次握手

TCP 四次挥手