前言：
三次握手可以说在程序界可以说是非常高频的词汇了。很多人都知道TCP协议是很多协议的基础，这个协议的通信方式类似于三次握手。那么为什么是三次？而不是四次？也不是两次呢？
图示
image.png
表格介绍
首先A端B端两台计算机。我们用一张表格表现通信状态(我们使用Y代表可以通信，N代表不能通信)
初始状态两个计算机的表格都是N不可通信
| 计算机 | A=>B | B=>A |
|---|---|---|
| A | N | N |
| B | N | N |
我们认为只有当A端和B端都认为A=>B,B=>A可以通信时，才是一个可以通信的状态。不然就无法保证通信交流能够成功
所以只有当表格变为下表才OK
| 计算机 | A=>B | B=>A |
|---|---|---|
| A | Y | Y |
| B | Y | Y |
逐步分析
事件1：
A端发起对B端的通信
这时候，A端不知道B端能不能收到，B也不知道有没有人请求过来了。所以这个时候通信表格没有变化
事件2：
B端接收到了A端的通信，那么B端可以知道A=》B的通信是没有问题
那么表格就发生了变化
| 计算机 | A=>B | B=>A |
|---|---|---|
| A | N | N |
| B | Y | N |
事件3：
随后B端发起通信回复A端，告知A端自己已经收到请求
由于B端不知道A能否接收成功，所有B端表格无变化
A端也不知道B端能否收到并回复，所以A端表格还是初始状态
事件4：
A端接收到了B端的回复，那么A端可以得知，A=>B成功，B=>A成功，所以A端表格变为
| 计算机 | A=>B | B=>A |
|---|---|---|
| A | Y | Y |
| B | Y | N |
事件5：
A端再次发起通信告知B端自己已经收到了B端发起的通信
此时A虽然知道B可以接收到他的通信
但是B端不知道他发起对A的通信是否成功
所以表格还是没有变化
事件6：
B端成功接收到A端的回复
由此B端知道B=》A可以通信
表格修改为
| 计算机 | A=>B | B=>A |
|---|---|---|
| A | Y | Y |
| B | Y | Y |
结语
由此可见，我们TCP协议的三次握手是在保证通信可行下的最少通信次数。如果是两次握手，便无法100%保证可以通信。如果使用四次握手，就浪费了通信的时间和次数。性能上不如三次握手来的高效
如果有写的不对的地方，希望大神指正。谢谢
以上
