http 1.1

在TCP3次握手后采用一次一送的方式接收文件。

例如拿到了index.html在根据html依次请求css,js文件。

如果其中一个文件丢失，可能对造成队头阻塞。

为了解决队头阻塞，http采用管线化的技术：单个链接可以发送多个请求。但是采用这个技术接收顺序必须与发送顺序相同。

解决方法

1.精灵图可以减少http的请求次数。

2.data URLs:将图片转为2进制放入到html中

3.域名分片：网站新开多个域，增加浏览器的并行下载数量

1.如果采用https的方式，tls会增加通信前的握手次数。

2.http每次发送前都要带有cookie，token等信息，增大开销

3.TCP慢启动

为了解决http1.1队头阻塞的问题

将http数据包封装成二进制的帧，加入了流标识符，表明顺序

接收顺序必须与发送顺序可以不同，接收与发送是独立开的

http1.1仅报文压缩，首部被压缩，而http2.0采用hpack将首部也压缩了。并且报文直接变成2进制的帧。

服务器提前将可能用到的文件都发送过去

http2只解决了http层面的队头阻塞问题，不能解决TCP层面的队头阻塞问题

http3将TCP与TSL的握手整合在一起，减少了来回带来的开销，如果是恢复会话不用握手，实现0rtt。

网络结构 http3.0 http - quic - udp - ip

http2.0 http - tls - tcp - ip

封装流程：

应用数据------quic流------quic帧------quic包

quic包里面有自己独立的号码，如果丢失了一个quic包，就直接重传该丢失的包，以此解决TCP的队头阻塞问题

关于TCP的队头阻塞问题：

如果TCP采用回退N帧的方法控制丢失重传，那么当发送队列的前序TCP报文丢失，则这个报文后面的所有报文都要重新发送，也就是要回退N帧

在TCP中仅用一组四元组即可标识出一个特定的连接，而对于基于UDP的quic协议来说，想要标识出特定的连接就想要使用Connection ID。

Connection ID的作用：

从wifi坏境下切换到手机4G，ip地址被改变了，用四元组就不太好用了，必须得重新握手恢复通话。而使用Connection ID依旧可以正常标识出连接，维持会话