今天大概看了一下这个知识点，用自己的语言来描述一下。
TCP连接的三次握手
准备：服务器首先创建一个传输控制块，并且使自己处于监听状态，等待客户端发来的请求
第一次握手：客户端首先创建一个传输控制块TCB，然后向服务器发送一个连接请求报文段，这时报文段的SYN需要置为1，同时给自己分配一个序列号x，并且把seq置为x，发送给服务器。
第二次握手：服务器接收到客户端传来的报文段后，要发送一个确认报文，同样确认报文的SYN控制为需要置为1，并且要给自己分配一个序列号y，再把seq置为y，同时再把ACK控制为置为1，ack置为x+1，表示确认报文，返回给客户端。
第三次握手：当客户端收到来自服务器的确认报文时，客户端仍要向服务器给出确认消息，此时将ACK置为1，seq置为x+1，ack置为y+1。因为TCP的标准规定，ACK可以携带数据，如果ACK报文不挟带数据，则不消耗序列号，因此，下一报文的序列号seq仍然是x+1。报文发送给服务器，同时TCP连接建立，客户端进入ESTABLISHED状态。
服务器再次接收到来自客户端的报文后，也进入ESTABLISHED状态，双方可进行数据传送。
断开连接的四次挥手
通信双方的任何一方都可以主动发起挥手请求。
主动发起挥手请求的一方称为A，被动接收的称为B
第一次挥手：若A主动发起挥手，说明A已经没有数据要传输了，此时A将发送一个关闭连接的报文段，将FIN字段置为1，seq等于上一个数据报的序列号加一，这里假设为u，发送给B
第二次挥手：B接收到A请求的关闭连接报文段时，会对A的报文段进行确认，即将ACK置为1，seq置为v（上个一报文段序列+1），ack=u+1，发送给A。但是因为此时B的数据可能还未发送完毕，所以B在发送完对A的确认报文后会继续给A发送数据。
第三次挥手：A接收到B的确认信息后，TCP连接进入半关闭状态，即A可以继续接收B发来的数据。当B的数据也发送完毕以后，会向A发出一个关闭连接的确认报文，即FIN置为1，ACK置为1，seq置为w（上个报文序列号+1），ack置为u+1①，A发送的请求关闭报文序列+1（u+1），ACK字段置为1，发送给A，然后B进入CLOSED状态
第四次挥手：A接收到B的关闭报文后，要发送一个确认信息，ACK置为1，seq为u+1，ack为B的关闭连接报文序列号+1，同时不是立即关闭而是进入TIME-WAIT状态，等待规定的2MLS②时间，才可彻底关闭连接进入CLOSE状态。
在此期间，B接收到A的确认信息后就会进入CLOSED状态。
解释：
①为什么此时的seq仍未u+1呢？其实在上面的三次握手时已经提到过，TCP规定，如果确认报文，及ACK=1时不携带数据，则不消耗序列号。
②MLS：即最长报文段寿命,RFC建议设置为两分钟。
为什么要等待2MLS时间？
（1）因为要等待确认B收到了A的确认信息。
（2）使旧的报文段（即已失效的连接请求报文段）彻底消失在连接中。