为什么TCP连接三次握手而TCP断开连接四次分手？

需要明确一点的是TCP基于客户机-服务器模式，这点非常重要。

TCP的三次握手的由来：

客户机A要连接服务器B，首先A发起连接请求，然后B发出对这个连接请求的确认报文，当前的连接还没有完全建立，紧接着B发起对A的连接请求，然后A对B的连接请求进行确认，这样TCP连接才算建立完毕，现在应该算TCP连接进行了四次握手了把。

但是，可以观察到确认A的连接和B的连接请求没有必要分为两次发送，完全可以合并。所以B对A的连接请求的回复包括了SYN（连接请求）和ACK标志（确认连接），那么四次握手就合并成了三次握手了。

TCP的四次分手的由来：

首先，断开连接肯定需要4次分手，A向B请求断开，B对A的确认，B向A请求断开，A向B的确认，唯一需要明确的是这些分手能不能合并为一次分手的问题。肯定是不能合并的，因为服务器可能对客户机的断开连接确认后，还需要往客户机发送一些数据，所以并不能合并分手报文。如图。

为什么TCP需要三次握手开启连接？

       TCP需要可靠性的保障，在正式传送数据之前需要初始化两端的发送窗口与接收窗口的大小，需要确定发送字节的开始序号，完成上述的功能只需要两次握手即可，第三次握手的目的是为了防止第一个握手报文滞留在网络中造成服务器资源浪费。试想如果TCP是两次握手就建立连接，如果出现这样一种情况，客户端与服务器要建立连接，但是客户端的第一个握手报文超时了，然后客户端重传了第一个握手报文，随后客户端与服务器建立连接成功并完成了一次通信，连接关闭后第一个握手报文终于最后还是到达了服务器，如果基于两次握手就建立连接，那服务器对这个延迟的握手报文确认后就建立连接等待客户端发送数据的话就会造成资源的浪费，因为维持一个TCP连接是需要比监听需要更多内存资源的，客户端此时也不会再响应服务器的第二个握手报文，因为客户端已经认为连接结束了。

为什么TCP需要四次挥手结束连接？

       最终的目的还是基于可靠性的保证才需要四次挥手结束连接。试想如果TCP像UDP一样直接关闭连接，如果网络中还有数据包在传送，这就会造成丢包，挥手的过程其实就是对完整数据最后字节的确认。