TCP的“三次握手”和“四次挥手”

TCP：传输控制协议。是一种面向连接的、可靠的、基于字节流的传输层通信协议。

建立TCP需要三次握手才能建立，而断开连接则需要四次握手。整个过程如下图所示：

 

三次握手过程：

第一次握手是在建立连接，客户端发送连接请求报文段，把标有SYN的数据包发送给服务器端即接收端。

第二次握手是服务器端接收到客户端标有SYN的报文段，同时发送标有SYN/ACK的数据包给客户端。并分配资源。

第三次握手是客户端接收到服务端标有SYN/ACK的数据包，向服务器端发送标有ACK的数据包。并分配资源。

四次挥手过程：

 第一次挥手

客户端设置seq和ack,向服务器发送一个FIN=1的报文段，此时，客户端进入FIN_WAIT状态，表示客户端没有数据要发送给服务端了。

第二次挥手

服务端收到了客户端发送的FIN报文段，向客户端回复了一个ACK的报文段。

第三次挥手

服务端向客户端发送FIN报文段，请求关闭连接，同时服务端进入LAST_ACK状态

第四次挥手

客户端收到服务端发送的FIN报文段后，向服务端发送ACK报文段，然后客户端进入TIME_WAIT状态。服务端收到客户端的ACK报文段后，关闭连接。此时，客户端等待2MSL（指一个片段在网络中的最大存活时间） 后依然没有得到回复，则说明服务端已正常关闭，这样客户端就可以关闭连接了。

【问题1】为什么连接的时候是三次握手，断开连接的时候却是四次挥手？

建立连接时，被动方服务器端结束CLOSED阶段进入“握手”阶段并不需要任何准备，可以直接返回SYN和ACK报文，开始建立连接。其中，ACK报文是用来应答的，SYN报文是用来同步的。

关闭连接时，当服务端收到客户端的FIN报文时，很可能不会立即关闭Socket，因为还有必要的数据需要处理。所以只回复一个ACK报文，告诉客户端，你发的FIN报文我收到了。只有等到服务端所有的报文都发完了，才能发送FIN报文给客户端，因此，不能一起发送，所以需要四次握手。

【问题2】为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？

为的是确认服务器端是否收到客户端发出的ACK确认报文

当客户端发出最后的ACK确认报文时，并不能确定服务器端能够收到该段报文。所以客户端在发送完ACK确认报文之后，会设置一个时长为2MSL的计时器。MSL指的是Maximum Segment Lifetime：一段TCP报文在传输过程中的最大生命周期。2MSL即是服务器端发出为FIN报文和客户端发出的ACK确认报文所能保持有效的最大时长。

服务器端在1MSL内没有收到客户端发出的ACK确认报文，就会再次向客户端发出FIN报文；

如果客户端在2MSL内，再次收到了来自服务器端的FIN报文，说明服务器端由于各种原因没有接收到客户端发出的ACK确认报文。客户端再次向服务器端发出ACK确认报文，计时器重置，重新开始2MSL的计时；

否则客户端在2MSL内没有再次收到来自服务器端的FIN报文，说明服务器端正常接收了ACK确认报文，客户端可以进入CLOSED阶段，完成“四次挥手”。

【问题3】为什么不能用两次握手进行连接？

三次握手的目的是：为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。

【问题4】如果已经建立了连接，但是客户端突然出现故障了怎么办？ 

TCP还设置了一个保活计时器，显然，客户端如果出现故障，服务端不能一直等下去， 白白浪费资源。服务器每收到一次客户端的请求之后都会重新复位这个计时器。时间通常是2小时，若两小时还没收到客户端的请求，服务端会发送一个探测报文段，以后每隔75秒发送一次，若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。