知道TCP连接的三次握手，但你知道为什么是三次吗？

TCP连接的三次握手

了解TCP协议的人都知道，TCP在建立连接的时候需要经过三次交互，俗称「三次握手」：

image.png

1. client端发送一个SYN段指明client打算连接的server端口，以及初始序号（ISN）
2. server发回包含server的初始化序号的SYN报文段作为应答，同时将确认序号（ACK）设置为client的ISN加1以对client的SYN报文段进行确认
3. client必须将确认序号（ACK）设置为server的ISN加1以对server的SYN报文段进行确认

完成这三次交互后，client与server端就可以建立起一个TCP连接，双方也可以通过该连接通道进行数据的交互，但是很多人也会有疑问，为什么一定要经过三次交互才能建立连接呢？这三次是必须的吗？如果是那是为什么呢？下面，我将来解答这个问题

一定需要三次握手吗？

要回答这个问题，我们首先想想TCP连接的目的，我想大家都知道，它的目的就是建立一个数据传输的通道，而一般建立一个通道需要哪些步骤呢？这里我们不妨举一个现实中的例子：建立客运线；我们都知道，在建立客运线线之前，客运线的起始站和终点站需要沟通，只有双方都同意了建立了这条线（TCP连接的建立）并协调相关的车位等资源（启用socket端口），才能有后续的汽车在这条线上运行（TCP数据传输），首先来看正常的路线是如何建立的（假设需要在A，B两个站之间建立客运线）：

1. A站：B站你好，我想和你建立客运线，请问你那边能为我腾一个车位出来吗？
2. B站：好的！
3. B站：A站你好，你那边返程的车位准备好了吗？
4. A站：返程的车位准备好了！

可以看到这里其实有四个阶段，但是由于第2和第3阶段都是由B站发往A站的信息，所以可以合并起来，流程简化如下：

1. A站：B站你好，我想和你建立客运线，请问你那边能为我腾一个车位出来吗？
2. B站：好的，另外，你那边返程的车位准备好了吗？
3. A站：返程的车位准备好了！

你看，2，3阶段合并后的流程是不是就是TCP连接的三次握手！，但既然我们的问题是「一定需要三次握手吗？」，所以我们可以进一步思考，既然2，3阶段可以合并，那么1，4阶段能不能合并呢？我们来看：

1. A站：B站你好，我想和你建立客运线，请问你那边能为我腾一个车位出来吗？另外，我这边已经为你腾出了返程的车位
2. B站：好的，车位就绪！

你瞧，客运线照样可以建立，没有任何问题，那么TCP的设计者为什么就一定要设计一个三次交互的方案呢？是他们的方案设计不够简洁吗？肯定不是，作为因特网的底层支撑，设计者们不会容许这么一个容许的方案存在的。

我们不妨再深入思考，这里通过建立客运线的场景模拟网络连接的建立时忽略了一个点，那就是网络报文在传输的时候可能会延迟或丢失，而上面两阶段交互的方案并没有考虑信息丢失的情况，现在我们假定A站和B站在进行交互的时候用的是飞鸽传书，双方沟通时默认一定时间内未收到回信即认为鸽子迷路了，就需要重发（模拟报文延时或丢失后的重发机制），那么在这种情况下，两阶段交互是否能正常工作呢？

1. A站：B站你好，我想和你建立客运线，请问你那边能为我腾一个车位出来吗？另外，我这边已经为你腾出了返程的车位
2. A站（未能及时收到回信，重发）：B站你好，我想和你建立客运线，请问你那边能为我腾一个车位出来吗？另外，我这边已经为你腾出了返程的车位
3. B站（响应重发的消息）：好的，车位就绪！
4. 运行一段时间后，客运线关闭（假设是临时路线）
5. 第一阶段丢失的那个信鸽此时将消息送到了，即：（B站你好，我想和你建立客运线，请问你那边能为我腾一个车位出来吗？另外，我这边已经为你腾出了返程的车位）
6. B站：好的，车位就绪！（这是一条死客运线，不会有车过来）

我们发现，在两阶段交互方案中，由于信鸽的延时送达，导致后续建立了一条本不该建立的连接，B站将不会迎来A站的汽车，而我们再看三阶段交互的方案：

1. A站：B站你好，我想和你建立客运线，请问你那边能为我腾一个车位出来吗？
2. A站（未能及时收到回信，重发）：B站你好，我想和你建立客运线，请问你那边能为我腾一个车位出来吗？
3. B站（响应重发的消息）：好的，另外，你那边返程的车位准备好了吗？
4. A站：返程的车位准备好了！
5. 运行一段时间后，客运线关闭（假设是临时路线）
6. 第一阶段丢失的那个信鸽此时将消息送到了，即：（B站你好，我想和你建立客运线，请问你那边能为我腾一个车位出来吗？）
7. B站：好的，另外，你那边返程的车位准备好了吗？
8. 由于此时A站并不想建立到B站的线，所以忽略该信息
9. B站没有收到A站的回应，所以也不会完成客运线的建立

可以发现，三阶段交互可以解决这种由于信息延时或失败导致的非真实意愿的连接的建立，对应到TCP的三次握手，其实就是为了应对已经失效的连接请求报文突然又传回到服务端而产生的错误场景，或者从另外一个角度看，如果网络传输质量一直处于理想状态的话（不存在延时或丢失），两次握手其实完全可以满足连接建立的需求，而三次握手是一种能应对网络不稳定情况的最简方案