TCP报文常用：
Seq序号：占32位，用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记
确认序号：Ack序号，占32位，只有ACK标志位为1时，确认序号字段才有效，Ack=Seq+1
标志位：
- SYN：发起一个新连接
- ACK：确认序号有效
- FIN ：释放一个连接
一.TCP的三次握手
三次握手：建立TCP连接 即建立一个TCP连接时 需要客户端和服务端发送三个包确认连接的建立
- 完成TCP三次握手，客户端和服务端开始传递数据
- TCP连接如果保持 则不会有多次三次握手的产生
第一次握手：客户端将标识位SYN设置为1 并且随机产生一个字节流值seq=J，并将该数据包发送给服务器，客户端进入SYN_SENT状态,等待服务器确认
(客户端询问服务器是否可以使用)
第二次握手：服务器接收到数据包后，通过SYN=1知道客户端要求建立连接 ，服务器设置SYN=1，ACK=1，ack=J+1 来随机产生一个seq=k，将该数据包发送给客户端
来确认请求连接 服务端进入SYN_REVD状态
(服务器告诉浏览器可以使用)
第三次握手：客户端接收到确认后 检查ack是否为J+1 ACK=1 如果正确 则将标识位ACK=1 ask=K+1发送给服务端 服务端检查数据包是否正确 如果正确则建立连接，并且客户端和服务端都进入ESTABLISHED状态 完成三次握手 随后客户端和服务端读可以建立连接啦
(客户端二次告诉服务器明白啦 接下来可以进行请求）
二，TCP的四次挥手
四次挥手：终止TCP连接 即断开一个TCP连接时 需要客户端和服务端共发送4个包确认断开连接
情况一：一方主动关闭，另一方被动关闭
第一次挥手：客户端发送一个FIN 用来关闭客户端和服务端的数据传送 客户端进入FIN_WINT_1状态
第二次挥手：服务端收到FIN后 发送一个ack给客户端 确认序号为收到序号M+1 服务器进入CLOSE_WAIT状态
第三次挥手：服务端发送一个FIN 用来关闭服务端到客户端的数据传输 服务端进入LAST_ACK状态
第四次挥手：客户端收到FIN后 发送一个ACK给服务端 确认序号为N+1 服务端进入CLOSED状态 完成四次挥手
情况二：同时发起主动关闭
为何要三次握手？
为了防止服务端对客户端开启较多的无用连接，而导致的服务器的开销
网络传输有延时（有时候距离较远）如果说客户端发送包给服务器 服务器直接创建TCP连接返回内容给客户端 如果中间数据包丢失 客户端有超时时间关闭重新发送数据包 而服务端不清楚客户端连接是否成功 开启多次TCP请求
为何三次握手四次挥手？
服务端在监听状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。而关闭连接时，当收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，自己也未必全部数据都发送给对方了，所以自己可以立即close，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，自己ACK和FIN一般都会分开发送
三.查看浏览器中TCP长连接还是短连接
TCP的连接分为长连接和短连接。
长连接：指在一个TCP连接上可以连续发送多个数据包，在TCP连接保持期间，如果没有数据包发送，需要双方发检测包以维持此连接，
一般需要自己做在线维持。连接→数据传输→保持连接→数据传输→保持连接→……→关闭连接 (减少多次TCP的三次握手和四次挥手)
短连接：短连接是指通信双方有数据交互时，就建立一个TCP连接，数据发送完成后，则断开此TCP连接。 连接→数据传输→关闭连接
检查F12->Network->头信息
HTTP和TCP的联系？
同一个TCP连接中可以发送很多HTTP请求 一个HTTP请求一定在某一个TCP里面发送的
在HTTP1.1中 同一个TCP连接里面连续发送多个请求 但是要按照顺序返回 前一个等待时间过长 后面依旧要排队 串行影响效率
在HTTP2中 同一个TCP连接里面连续发送多个请求不再需要按照顺序来进行返回处理 可以同时返回第一个里面的数据 和第二个里面的数据 并行处理 更大限度使web效率质的提升
对于长连接如何查看HTTP请求里需要的TCP数量？
步骤：检查F12->Network->Name/Status栏->右健->勾选Connection ID(TCP链接的id) //记得提前勾选Disable catch禁止缓存
HTTP1.1 同一域名连续发送6条HTTP请求 建立6个TCP 从7个开始前面6个谁先加载完成 就复用谁的TCP连接
HTTP2 同一域名可以共用同一个TCP 性能会有质的飞跃