TCP的三次握手和四次挥手实质就是TCP通信的连接和断开。
首先，要明白握手的目的是什么
可以将TCP双向通信的过程，看成两个单向通信过程的组合：
一次 “请求连接——确认”操作，可以确保一方做好了发送准备，另一方做好了接收准备，因此可以建议一个单向的连接；
一次 “请求关闭——确认”操作，可以确保一方发完了数据希望关闭发送，另一方收到请求关闭接收，最后关闭掉一个单向的连接。
在建立连接时，是为了判断双方是否能够正常建立连接，即客户端—>服务端、服务端->客户端两个单向的收发都是正常的。
而在关闭连接时，是为了判断双方是否应该关闭连接，即客户端—>服务端、服务端->客户端两个单向的收发是否应该关闭。
在握手过程中，每一端自己当然清楚自己这边的状态，关键是从过程中判断对方的状态。
一、建立TCP连接：三次握手协议
客户端：我要对你讲话，你能听到吗；
服务端：我能听到；而且我也要对你讲话，你能听到吗；
客户端：我也能听到。
…….
互相开始通话
过程分析：
第一步，客户端向服务端发送请求；
服务端收到了客户端请求，因此服务端可以判断： 客户端—>服务端单向收发正常。
第二步，服务端向客户端发送确认；
客户端收到了确认，因此客户端可以判断：
服务端正常收到了自己刚才的请求，所以， 客户端—>服务端单向收发正常、服务端—>客户端单向收发正常。
于是客户端为连接分配相关资源，开始监听端口。
第三步，客户端针对刚才收到的包发送确认；
服务端收到了这个确认包，因此服务端可以判断： 客户端—>服务端单向收发正常、服务端—>客户端单向收发正常
于是服务端未连接分配相关资源，开始监听端口。
为何要分三步握手，而不能是两步握手？
SYN:该字段被设置为1（即true），表示请求建立连接
FIN：该字段被设置为1（即true），表示请求关闭连接
seq:该字段为请求序列号，譬如为seq=x, 能够标示一个请求包，在众多包种区分其身份
ack:该字段为确认字段，譬如ack=x+1，表示已经收到对方发来的seq=x的请求包。
客户端通过ack可以判断，当前确认包是针对哪个请求包在做确认。
二：关闭TCP连接：四次握手协议
客户端：我说完了，我要闭嘴了；
服务端：我收到请求，我要闭耳朵了；
（客户端收到这个确认，于是安心地闭嘴了。）
…….
服务端还没倾诉完自己的故事，于是继续唠唠叨叨向客户端说了半天，直到说完为止
…….
服务端：我说完了，我也要闭嘴了；
客户端：我收到请求，我要闭耳朵了；（事实上，客户端为了保证这个确认包成功送达，等待了两个最大报文生命周期后，才闭上耳朵。）
（服务端收到这个确认，于是安心地闭嘴了。）
（发送方之所以要收到确认后才关闭发送，是怕接收方没收到自己的请求，避免自己关闭了发送，而接收方还一直傻等着去接收。）
客户端收到请求包后，为什么要等待两个最大报文生命周期后，才闭上耳朵呢？
为了以防万一，因为最后一个发往服务端B的确认包有可能丢失，等待两个最大报文生命周期是为了尽可能保障服务端能够收到一次确认包，避免服务单始终处在等待关闭发送的状态。
分析：
一个“最大报文时长”是TCP数据包在网络中存在的最长时间，超过这个时间报文会被丢弃掉。
客户端每次在收到服务端的“关闭请求”后开始计时，服务端一旦超时收不到客户端的确认包就会重发请求，而TCP协议中的确认超时时长应该不会超过“最大报文周期”，而重发的网络请求的传输时间也不超过“最大报文周期”，这样正常情况下，重发的请求在两个“最大报文周期”内应该能够到达客户端，客户端每次在收到服务端的“关闭请求”后又会重新开始计时两个“最大报文周期”，又会重复前面的过程。
这样，可以很大限度上保障服务端能收到一次确认包。（当然会有收不到的情况，所以应该会有别的超时机制来兜底。）
