[计算机网络]TCP连接为什么需要三次握手_多角度

通信的不可靠性，是需要多次确认的根本原因。
其一是现实环境中，发包成功率远不到100%，服务器端可能根本无法接受到请求。其二是即使服务器接收到请求，也可能拒绝连接。收到ACK后能确认的是，对方收到了请求，且同意该请求，因此可以放心进入连接状态。概率的角度来说，P(对方收到请求|收到对方ACK) = 1的条件概率，提供了可以进入连接状态的保证。
互通“心意”同时也完成了服务器和客户端的参数同步过程，例如握手包中除了标记SYN、ACK字段，也会告知对方自己的初始序列号。

为什么是三次而不是两次呢？
因为两次握手，我们是从客户端的角度考虑，实现了发送请求，得到回应。而想要确定双通道的通畅，服务器也需要经过同样的发送信息、得到回应的两次通信，保证自己对客户端请求的ACK正确发送到了客户端。三次握手之后，对任意一方来说，都是接收到去信的回信后才打开连接，所以实际上是两次“发信收信”的过程，只是客户端的回信和客户端的发信过程合并了。这一点从四次挥手中也可以看出。由于客户端结束通信后，服务器可能仍然有需要向客户端发送的数据，因此此时中间的ACK和去信功能无法合并到一次挥手中，因此两次“发信收信”又各自独立了。
我们生活中的“握手”不需要额外的第三次，是因为“握手”时两方是处于同一空间，即时的信息反馈下，两次“发信收信过程”合并成了一次“发信收信”。

另外通信轮次其实一定是要满足奇数轮要求。
三次握手情况下，如果一二次握手包丢失，客户端和服务器都不会进入连接状态；第三次包丢失，客户端进入连接状态，但是服务器仍然是空闲的。但是如果选择偶数握手，同样，除了最后一次包丢失时，之前的任意包丢失，服务器和客户端都会选择不进入连接状态；而最后一次包丢失，则会让服务器进入连接状态，而客户端没有需要发送的请求。服务器承载的是多个用户的服务工作，因此它进入错误的连接等待状态影响显然要更大，因为此时没有用户可以得到服务；而客户端进入错误的连接等待时，服务器可以接受其他的连接请求，提供服务。

为什么不是五次、七次或者更多呢？
资源节约原则：三次是能够知会双方的最小通信次数，如前所述，此时已经能够满足1的条件概率。并且，即使再向上递增到五次、七次握手，也无法保证信道的可靠性，即无法保证后续分组包能够正常递交。包的发送各自是独立的；连接建立之后的可靠通信，是通过超时重传等机制实现的，与进行了几次握手无关。