三次握手四次分离总结三次握手
首先，客户端发送请求连接的消息。 在这种情况下，SYN=1，ACK=0，并且有初始seq编号x。 该消息不能携带数据，但SYN消息不能携带数据。 但是，也消耗一个序列号，客户端的连接状态为syn_sent；
服务器端在收到请求消息后发送确认消息。 此时，通过ACK=1使确认号码有效。 此时的确认编号为x 1，表示成功接收到x 1以前的数据，并发送了自己的seq编号y。 SYN=1，服务器侧的连接状态为syn_rcvd；
客户端在收到确认消息后，也响应确认消息。 此时的确认消息可以携带数据，但如果不携带数据则不消耗序列号。 在该消息块内，ack=x 1、ACK=1、seq=y 1，完成三次握手，双方状态为established；
此处为什么客户端发送确认报文后，客户端还需再一次确认呢？由于存在这种情况，网络拥塞，来自第一个客户端的请求消息延迟。 客户端在丢包定时器时间内没有收到服务端的确认，判断为刚刚发送的请求数据包丢失。 因此，客户端再次发送请求消息，服务端成功发送确认消息建立连接，但不久延迟的请求分组到达服务端。 此时，如果服务端返回确认数据包，则服务端识别为建立了新的连接，但客户端未发送请求消息，因此不响应服务端的确认数据包，服务端识别为建立了新的连接，客户端
4次爆红
如果客户端以FIN=1开始断开连接，并且当前序列号为seq=x，则客户端进入fin_wait状态以等待来自服务端的确认消息；
服务端收到断开请求，立即响应确认消息，确认ACK=1，确认号码ack为x 1，x以前的消息接收成功，服务端当前号码为y，此时客户端进入fin_wait2状态，服务器
此时，客户端进入半个封锁状态并且停止数据的发送，但是仍然可以接收数据。 服务端可能还有未发送的数据。 当最后的数据发送结束时，服务端发送释放消息，FIN=1，确认号ack还是上次确认消息的号x 1、ACK=1，当前号w。 此时服务端进入close_wait状态，等待客户端的确认消息；
客户端收到发布消息后，发送确认消息，ACK=1、
ack=w 1，当前序列号比上次发送的断开请求消息增加1x1，此时客户端进入close_wait状态，等待2msl后断开连接。
为什么客户端发送服务端释放报文的确认后还需要等待2MSL(最长报文段寿命)？客户端需要验证服务端是否收到了自己的确认消息，这样服务端就不会在没有收到客户端的确认消息的情况下等待客户端的确认来消耗资源如果在此时间内再次收到来自服务端的释放消息，则表示以前发送的确认消息服务端无法正常接收，再次发送确认消息，重置time_wait计时器。
另外还存在一种情况：客户端与服务端已经成功建立连接了，但是突然客户端出故障了为了防止服务端继续等待客户端的响应，服务端使用激活计时器来控制与客户端的断开，每次收到客户端的数据时，服务端都会激活如果在激活计时器的时间内没有收到来自客户端的数据，服务器将自行断开连接。 正常激活计时器默认为2小时。