三次握手四次挥手

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

 

 

 

TCP 建连三次握手

首先解释一下每一个步骤的做用：
一、a 时刻，A 准备就绪，发送 SYN 包给 B，尝试创建链接
二、b 时刻，B 收到 A 发来的 SYN 包，知道 A 要请求建连，回 SYN ACK 包，告诉 A 本身收到了建连请求，能够建连了
三、c 时刻，A 收到了 B 的回复，知道 B 准备好了，链路通畅，能够发送数据了。回  ACK 告知 B 收到了 B 的回复，下面要开始发送该数据了
四、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 断链四次挥手
一、a 时刻，A 向 B 发出 FIN 包，表示本身没有数据要发送了
二、b 时刻，B 收到 FIN 包，回复 FIN ACK，表示收到了 A 的 FIN 包，不会再接收 A 的数据了
三、B 在发完 FIN ACK 后，可能还有数据要发给 A，这个数据是不能中止发送的，有数据仍是须要继续发送
四、d 时刻，B 发完了数据，也发出 FIN 包，告诉 A 本身的数据发完了，再也不发送数据了
五、e 时刻，A 收到了 B 的 FIN 包，知道 B 也没有数据要发送了，回复 FIN ACK。此时，链接能够断开了

建连只须要交互三次，断连却须要四次，这是为何呢？其实断开链接和创建链接仍是不同的。建连的时候，只要双方都告知对方本身准备好了就能够，可是断连的时候，一方提出要断开链接，再也不发数据，另外一方不能当即断开，由于这一方可能还有数据要发送，直到数据所有发送完成后才能确认断开。

 

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

 

 

 

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

 

 

 

TCP 四次挥手