tcp三次握手，为什么不是两次，这个面试题到底该咋回答？

三次握手不是TCP独有的，所有的端到端的全双工通信要确认各自的发送和接受通道是畅通的，双发都至少需要两次交互，加起来就是4次。因为第二次被动方的确认回复和第三次的发送可以合并为一次，就变成三次交互了。

       3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。        现在把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，S收到了这个分组，并发 送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S 是否已准备好，不知道S建立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。

大概意思是防止已失效的连接请求到达服务器建立连接浪费资源。计算机网络谢希仁教材作出了解释。

假设A、B两方进行TCP握手 如果是两次握手A->B(第一次握手因为某些原因迟到了很久) A->B(A再次进行一次握手请求) B->(响应握手建立连接) 而此时第一次握手请求这个时候才到了B端，那么B端也要响应这个握手连接啊，于是就返回响应，但是这个时候的A已经将第一次的握手请求作废，所以这一条连接就纯属于浪费服务器的资源。 如果是三次握手 A->B(请求握手)、B->A(同意握手 但是不确定A能否收到这个同意握手的回应)、A->B(已收到回应 TCP连接建立)，如果A将第一次握手请求作废，那么就不会有第三次的握手，而TCP连接也不会建立起来 我的理解是这个样子的

https://mp.weixin.qq.com/s/rX3A_FA19n4pI9HicIEsXg 在快到页面中间的位置，很详细

1. 两次握手会出现， 当第一次发送信号在网络中被隔置，第二次再发此时建立链接，断开链接后第一次链接信号又到了，此时会导致建立连接 2. 另外就是三手握手保证的是让对方知道我已经知道了，两次不行

我一般是通过举例加上分析来回答。 生活中：小明、小李 小明：在吗？ 小李：在的（表示小李可以进行通信）（这就相当于是既应答了，也提问了） 小明：那个.....（表示小明现在也是在线的，因为可能上一步小李过了很久才回复小明，小明可能已经离线了） 可以进行数据通信了！！！！！！！ 再下来就是分析包序啥的，个人觉得这样表达的就比较清晰了 仅供参考，大佬轻喷！！！😂

源端需要知道自己发送无问题，自己接收无问题，对端发送无问题，对端接收无问题。 对端需要知道自己发送无问题，自己接收无问题，源端发送无问题，源端接收无问题。 一共8个问题 第一次解决了：6，7 第二次解决了：1，2，3，4，8 第三次解决了：5

我觉得可以从全双工这个角度+一端建立/断开链接需要一次请求响应，去解释，本来应该是四次，c->s一次请求响应，s->c一次请求响应，建立连接没有数据要传输，所以第二三次可以合为一次。总共就三次了。 两次只能确保c->s是建立了连接，无法保证s->c建立了连接。 同一挥手需要四次，也是因为两端传输数据不是同时完毕的，所以各负责各的。

我一般是从两次握手会引发的问题这个角度回答的

一个是死锁问题，一个是资源浪费问题。

两个将军问题，本质是在不可靠信道上通过交换信息达到一致是不可能的，一致就是双方都建立连接

m

三次握手，应该叫三次报文交换，实际上是确认通信双方的收发数据能力，确认序列号，二次握手就确认tcp连接的话，客户端的收发能力可以确认，服务端不知道自己发的数据客户端能否收到，用三次握手既可高效(中间的SYN,ACK合并一起发)，又可确保可靠。同理断开连接的四次挥手如果服务端已没有数据发送，也可退化成三挥