1.序号：Seq序号,占32位，用来表示从TCP端向目的端发送的字节流，发送方发起数据时候对此进行标记。
2.确认号：Ack序号，占32位，只有ACK标志位1时，确认序号字段才有效，Ack=发起方Seq+1
3.标志位：六个 ACK(确认序号有效) RST(重置连接) PSH(尽快将这个包发往应用层)
FIN(释放一个连接) SYN(发送一个新连接)
TCP三次握手详解（握手之前，必须是一方主动打开，一方被动打开（假设是客户端主动发起的连接）） 握手之前，主动打开连接的客户端介绍CLOSED阶段，进入LISTEN阶段，被动打开的服务端也进入LISTEN状态
1.客户端向服务器发送一段TCP报文，其中标志位为SYN，序号为Seq：x，随后客户端进入SYN-SENT阶段
2.服务器收到来自客户端的TCP报文之后，结束LISTEN阶段，并返回一段TCP报文，其中标志位为SYN和ACK，标签确认客户端发的Seq序号有效，服务器能正常接收客户端发的数据，并同意创建连接。
确认号为Ack=x+1,表示收到了客户端的Seq序号并且将其值+1作为自己确认号Ack的值，随后服务器进入SYN-RCVD阶段 序号Seq=y
3.客户端收到来自服务器端的确认收到数据的TCP报文之后，明确了从客户端到服务器的传输是正常的，结束SYN-SENT阶段，并返回最后一段TCP报文
标志位ACK：确认服务器端同意连接的信号 序号为Seq=x+1， 表示收到服务器端的确认号Ack，并将其作为自己的序号值,确认号为Ack=y+1,表示收到服务端序号Seq，并将其值加一作为自己的确认号Ack的值 随后客户端进入ESTABLISHED阶段
为什么三次握手，返回时，ack值是seq加1（ack=x+1）？
1.回应一个确认报文，确认号为2000，意味着编号2000前的字节都接收完成，准备接收编号为2000及更多的数据
2.确认收到的序列，并且告诉发送端下一次发送的序列号从哪里开始
四次挥手
1.客户端想要释放连接，向服务端发送一段TCP报文，其中 标记位为FIN，表示请求释放连接，序号为Seq=U 随后客户端进入FIN-WAIT-1阶段，即半关闭阶段（停止客户端向
2.服务器收到了客户端发出的TCP报文，确认了客户端想要释放连接，随后服务端进入ESTABLISH阶段，进入CLOSE-WAIT阶段，半关闭状态，并返回一段TCP报文 标记位为ACK，表示已经收到客户端想要释放连接的请求 序号为Seq=V 确认号为ACK=U+1，表示是在收到客户端报文的基础上，将其序列号Seq值加一作为本段报文确认号ACK的值 随后服务器端开始准备释放服务器端到客户端方向上的连接 客户端收到服务器端发出的TCP报文后，确认了服务器收到了客户端发出的释放连接请求，随后客户端结束FIN-WAIT-1阶段，进入FIN-WAIT-2阶段
3.服务器端自从发出ACK报文之后，经过CLOSED_WAIT阶段，做好了释放服务器端到客户端方向上的连接准备，再一次向客户端发出一段TCP报文 标记位为ACK，FIN 表示 已经准备好释放连接了 序号 Seq= W 确认号 Ack = U+1：表示是在收到客户端报文的基础上，将其序列号Seq值+1作为本段报文确认号Ack的值 随后服务器端结束CLOSE-WAIT阶段，进入LAST_ACK阶段。并且停止在服务器端到客户端的方向上发送数据，但是服务器端仍然能过接收从客户端传输过来的数据
4.客户端收到从服务器端发出的TCP报文，确认了服务器端已经做好释放连接的准备，结束FIN-WAIT-2阶段，并向服务器发送一段报文 标记位ACK 表示 接受到了服务器准备释放连接的信号,序号Seq：U+1表示是在收到了服务器报文的基础上，将其确认号Ack的值作为本段序号的值 确认号 Ack=W+1 表示是在收到了服务器报文的基础上，将序列号Seq的值作为本段报文确认号的值 双方的确认号Ack和序号Seq的值，都是在彼此Ack和Seq值的基础上进行计算的，这样做保证了TCP报文传输的连贯性，一旦出现某一方发出的TCP报文丢失，便无法继续"挥手"， 随后客户端开始在TIME-WAIT阶段等待2MSL 为啥客户端要等到2MSL呢？ 为的是确认服务器端是否收到客户端发出的ACK确认报文 如果客户端在2MSL内，再次收到了来自服务器端的FIN报文，说明服务器端由于各种原因没有接收到客户端发出的ACK确认报文。客户端再次向服务器端发出ACK确认报文，计时器重置，重新开始2MSL的计时； 否则客户端在2MSL内没有再次收到来自服务器端的FIN报文，说明服务器端正常接收了ACK确认报文，客户端可以进入CLOSED阶段，完成“四次挥手”。