#.首先，要明白握手的目的是什么

可以将TCP双向通信的过程，看成两个单向通信过程的组合：

一次 “请求连接——确认”操作，可以确保一方做好了发送准备，另一方做好了接收准备，因此可以建议一个单向的连接；

一次 “请求关闭——确认”操作，可以确保一方发完了数据希望关闭发送，另一方收到请求关闭接收，最后关闭掉一个单向的连接。

    

        在建立连接时，是为了判断双方是否能够正常建立连接，即客户端—>服务端、服务端->客户端两个单向的收发都是正常的。

        而在关闭连接时，是为了判断双方是否应该关闭连接，即客户端—>服务端、服务端->客户端两个单向的收发是否应该关闭。

在握手过程中，每一端自己当然清楚自己这边的状态，关键是从过程中判断对方的状态。

#.一、建立TCP连接：三次握手协议

第一步，客户端向服务端发送请求；

服务端收到了客户端请求，因此服务端可以判断：客户端—>服务端单向收发正常。

第二步，服务端向客户端发送确认；

客户端收到了确认，因此客户端可以判断：

服务端正常收到了自己刚才的请求，所以，客户端—>服务端单向收发正常、服务端—>客户端单向收发正常。

于是客户端为连接分配相关资源，开始监听端口。     

第三步，客户端针对刚才收到的包发送确认；

服务端收到了这个确认包，因此服务端可以判断：客户端—>服务端单向收发正常、服务端—>客户端单向收发正常     

于是服务端未连接分配相关资源，开始监听端口。

其实在理想的网络环境下，只需要两次握手就行了，在上面第二步之后，客户端已经知道两个方向收到都是正常的了，它的确可以发送数据了。

但问题在于，网络环境并不总是理想的，在第一步客户端发送请求的过程有可能出现发送后迟迟收不到确认包而重发请求，如果之前已经过时的这个请求包真得彻底消散在网络传输中倒也罢了，但有时候它只是因为网络延迟到达服务端比较晚，过了一阵子时间后，可能又到达服务端了。如果这个旧的请求包到达的时间是在正常请求包到达之前，或者是在整个连接关闭之后才到达，那么服务端是无法判断这是过时请求的，服务端会正常发送确认，需要客户端来验明其过期的身份，然后告知服务端。

那么，如果是两次握手的话，一旦出现这种情况，服务端在第一步就会为连接分配资源，开始监听端口。但这是个过时的无效请求，客户端会抛弃掉，不会做对应的连接处理，也不会去发送数据。服务端会一直耗费资源傻等着。

如果是三次连接的话，多了客户端验证这一步，服务端能判断出这是一个无效请求，因此不会去做对应的资源分配。

二：关闭TCP连接：四次握手协议

为了以防万一，因为最后一个发往服务端B的确认包有可能丢失，等待两个最大报文生命周期是为了尽可能保障服务端能够收到一次确认包，避免服务单始终处在等待关闭发送的状态。

分析：

一个“最大报文时长”是TCP数据包在网络中存在的最长时间，超过这个时间报文会被丢弃掉。

客户端每次在收到服务端的“关闭请求”后开始计时，服务端一旦超时收不到客户端的确认包就会重发请求，而TCP协议中的确认超时时长应该不会超过“最大报文周期”，而重发的网络请求的传输时间也不超过“最大报文周期”，这样正常情况下，重发的请求在两个“最大报文周期”内应该能够到达客户端，客户端每次在收到服务端的“关闭请求”后又会重新开始计时两个“最大报文周期”，又会重复前面的过程。

这样，可以很大限度上保障服务端能收到一次确认包。（当然会有收不到的情况，所以应该会有别的超时机制来兜底。）