TCP三次握手、四次握手过程，以及原因分析

TCP的三次握手和四次挥手实质就是TCP通信的连接和断开。

三次握手：为了对每次发送的数据量进行跟踪与协商，确保数据段的发送和接收同步，根据所接收到的数据量而确认数据发送、接收完毕后何时撤消联系，并建立虚连接。

四次挥手：即终止TCP连接，就是指断开一个TCP连接时，需要客户端和服务端总共发送4个包以确认连接的断开。

首先，要明白握手的目的是什么
可以将TCP双向通信的过程，看成两个单向通信过程的组合：
一次 “请求连接——确认”操作，可以确保一方做好了发送准备，另一方做好了接收准备，因此可以建议一个单向的连接；
一次 “请求关闭——确认”操作，可以确保一方发完了数据希望关闭发送，另一方收到请求关闭接收，最后关闭掉一个单向的连接。

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

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

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

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

客户端：我要对你讲话，你能听到吗；
服务端：我能听到；而且我也要对你讲话，你能听到吗；
客户端：我也能听到。
…….
互相开始通话

过程分析：
第一步，客户端向服务端发送请求；
               服务端收到了客户端请求，因此服务端可以判断： 客户端—>服务端单向收发正常。
第二步，服务端向客户端发送确认；
               客户端收到了确认，因此客户端可以判断：
                    服务端正常收到了自己刚才的请求，所以， 客户端—>服务端单向收发正常、服务端—>客户端单向收发正常。
               于是客户端为连接分配相关资源，开始监听端口。     
第三步，客户端针对刚才收到的包发送确认；
               服务端收到了这个确认包，因此服务端可以判断： 客户端—>服务端单向收发正常、服务端—>客户端单向收发正常     
               于是服务端未连接分配相关资源，开始监听端口。

为何要分三步握手，而不能是两步握手？

其实在理想的网络环境下，只需要两次握手就行了，在上面第二步之后，客户端已经知道两个方向收到都是正常的了，它的确可以发送数据了。
但问题在于，网络环境并不总是理想的，在第一步客户端发送请求的过程有可能出现发送后迟迟收不到确认包而重发请求，如果之前已经过时的这个请求包真得彻底消散在网络传输中倒也罢了，但有时候它只是因为网络延迟到达服务端比较晚，过了一阵子时间后，可能又到达服务端了。如果这个旧的请求包到达的时间是在正常请求包到达之前，或者是在整个连接关闭之后才到达，那么服务端是无法判断这是过时请求的，服务端会正常发送确认，需要客户端来验明其过期的身份，然后告知服务端。
那么，如果是两次握手的话，一旦出现这种情况，服务端在第一步就会为连接分配资源，开始监听端口。但这是个过时的无效请求，客户端会抛弃掉，不会做对应的连接处理，也不会去发送数据。服务端会一直耗费资源傻等着。
如果是三次连接的话，多了客户端验证这一步，服务端能判断出这是一个无效请求，因此不会去做对应的资源分配。

SYN:该字段被设置为1（即true），表示请求建立连接
FIN：该字段被设置为1（即true），表示请求关闭连接
seq:该字段为请求序列号，譬如为seq=x, 能够标示一个请求包，在众多包种区分其身份
ack:该字段为确认字段，譬如ack=x+1，表示已经收到对方发来的seq=x的请求包。
客户端通过ack可以判断，当前确认包是针对哪个请求包在做确认。

二：关闭TCP连接：四次握手协议
客户端：我说完了，我要闭嘴了；
服务端：我收到请求，我要闭耳朵了；
（客户端收到这个确认，于是安心地闭嘴了。）
…….
服务端还没倾诉完自己的故事，于是继续唠唠叨叨向客户端说了半天，直到说完为止
…….
服务端：我说完了，我也要闭嘴了；
客户端：我收到请求，我要闭耳朵了；（事实上，客户端为了保证这个确认包成功送达，等待了两个最大报文生命周期后，才闭上耳朵。）
（服务端收到这个确认，于是安心地闭嘴了。）
（发送方之所以要收到确认后才关闭发送，是怕接收方没收到自己的请求，避免自己关闭了发送，而接收方还一直傻等着去接收。）

客户端收到请求包后，为什么要等待两个最大报文生命周期后，才闭上耳朵呢？
为了以防万一，因为最后一个发往服务端B的确认包有可能丢失，等待两个最大报文生命周期是为了尽可能保障服务端能够收到一次确认包，避免服务单始终处在等待关闭发送的状态。
分析：
一个“最大报文时长”是TCP数据包在网络中存在的最长时间，超过这个时间报文会被丢弃掉。
客户端每次在收到服务端的“关闭请求”后开始计时，服务端一旦超时收不到客户端的确认包就会重发请求，而TCP协议中的确认超时时长应该不会超过“最大报文周期”，而重发的网络请求的传输时间也不超过“最大报文周期”，这样正常情况下，重发的请求在两个“最大报文周期”内应该能够到达客户端，客户端每次在收到服务端的“关闭请求”后又会重新开始计时两个“最大报文周期”，又会重复前面的过程。
这样，可以很大限度上保障服务端能收到一次确认包。（当然会有收不到的情况，所以应该会有别的超时机制来兜底。）