TCP协议格式如下：
解析：
- 序号：Seq序号，占32位，用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记；
- 确认序号：Ack序号，占32位，只有Ack标记为1时，确认序号才有效，Ack = Seq + 1；
- 标识位：共6个【URG、ACK、PSH、RST、SYN、FIN】，其中URG-紧急指针有效、ACK：确认序号有效、PSH-接收方应该尽快把这个报文提交应用层、RST-重置连接、SYN-发起一个新连接、FIN-释放连接。
TCP建立连接 三次握手：
解析：
- 第一次握手：客户端向服务器发送一个同步数据包请求建立连接，数据包中包含：初始序列号ISN，由客户端随机产生，确认号为0；
- 第二次握手：服务区收到同步数据包后，回给客户端一个同步确认，这个数据包中，序列号ISN是服务端随机产生的值，确认是客户端初始序列号+1；
- 第三次握手：客户端收到同步确认数据包后，在对服务器发送一个确认，数据包中，序列号为同步请求数据中的序列号，确认号为服务器初始序列号+1.
TCP释放连接 四次握手
1、客户端发起关闭连接：
解析：
四次握手的序列号和确认号：
（u，o）-- (v, u+1) --(w, u+1) -- (u+1, w+1)
- 第一次握手：客户端发送一个FIN后，通知服务端此时客户端没有数据需要发送了，Client进入FIN_WAIT_1状态；
- 第二次握手：Server收到FIN后，确认没有数据要接收和返回了，发送一个ACK给Client，确认序列号为收到序列号+1，Server进入Close_wait状态；
- 第三次握手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入Last_ack状态；
- 第四次握手：Client收到FIN后，Client进入Tiime_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入Close，完成。
2、双方同时发起主动关闭：
【问题1】：
为什么建立连接三次握手，而关闭是四次握手呢?
RE:因为建立连接时，服务端只需要回复ACK确认收到消息就可以了，而关闭连接时，第一次回复ACK是告知客户端我收到你的请求了，但服务端此时可能不会立即关闭SOCKET，只有确认关闭了才会在发送FIN。
【问题2】为什么关闭连接时，TIME_WAIT需要等待2MSL才返回CLOSE状态；
RE：虽然说4次握手完成后，就可以closed，但我们必须考虑网络不可靠，如果最后一个ack丢失，就需要在重新发送FIN，而这个等待时间时2MSL
长连接和短连接：
在HTTP的响应消息中，如果connect：closed -- 短连接， connection：keep-alive -- 长连接
长连接：
建立连接 -- 传输数据 --（保持连接） -- 传输数据 -- 关闭连接
短连接：
建立连接-传输数据-关闭连接 ... 建立连接 -- 传输数据 -- 关闭连接
长连接和短链接的应用场景：
由上面可知，长连接可以省去再次建立和关闭连接的时间，对于频繁请求资源的客户端，适用于长连接，不过存在一个问题，存活功能的探测周期太长，还有就是它知识探测TCP连接算是比较斯文的做法，如果遇到恶意连接时，保活功能就不够用了，在长连接的应用场景下，client一般不会主动关闭它们之间的连接，client和server之间连接如果一直不活动，会有一个问题，随着客户端的增加，连接数也在增加，占用资源；短连接的理解比较容易。对于开放的web网站，建议使用短连接，减少资源占用，对于专网客户端较少时，建议使用长连接，减少频繁请求建立连接。