先对上一篇文章中标头和载荷部分进行补充说明：网络协议的基本结构是标头和载荷，网络协议在每一层都会将上一层的标头和载荷视为这一层的载荷，并添加自己的标头。
二、Web中的网络
- HTTP协议的基本结构示例：
红色部分是请求，蓝色部分是响应
1.请求部分
- 第一行也被称作起始行，包含了三个要素：GET / HTTP1.1
-
这三个要素分别代表了请求的方法，资源路径，及HTTP版本
- 之后的几行是头部，头部通过：表示，：左边是头部的名称，右边是头部的值。头部的名称不区分大小写
2.响应部分
- 响应的第一行是响应的状态行，包含三个部分：HTTP1.1 200 OK
-
这三个要素分别代表了HTTP版本，状态码，重要消息。重要信息是可以自定义的。
- 这张图很好地表明了HTTP网络协议的弊端，即请求-响应模式的情况下，只有当服务端完整的响应了客户端发出的前一个请求，客户端才可以发起第二个请求，这种模式导致网络利用率非常低（会造成队头堵塞问题）
- 在之后HTTP1.1中针对这种问题提出了HTTP管线模式（HTTP Pipelining），即客户端可一次性发出多个请求，服务端按照顺序进行答复；但这种模式也几乎没有人使用，因为这种模式对于提高网络效率的效果微乎其微，还可能造成一定的风险：当客户端一次性发送多个请求，服务端在传回信息时给出的最终信息回混杂在一起，使客户无法分辨答复属于哪个请求。
- 在HTTP2中引入了帧，即将多个HTTP请求拆入到各个帧里面，这样的话可以对每个数据包进行标识，不会再出现类似于HTTP1.1管线模式导致的结果不明的情况。
- 前三个字节是载荷长度，表示当前帧的载荷一共有多少个字节（1 byte = 8 bit）
- 第四个字节（Type）是帧的类型
- 第五个字节是类型对应的Flags（标志位）
- 第六到第九字节：第1位是保留位，第2-32位是流ID
- 剩下的所有字节则是当前帧的载荷
HTTP2:帧带来的额外好处
- 调整响应传输的优先级
- 头部压缩
- Server Push
这些功能都可以通过不同类型的帧来实现
HTTP2的小缺陷：
- 功能够多，但是处理速度很慢，于是产生了HTTP3
- 仍有可能发生队头堵塞，但是是发生在TCP中
HTTP3针对HTTP2的改进：QUIC
- Quick UDP Internet Connection
- 现存网络设备对TCP和UDP支持已僵化
- UDP不靠谱但是QUIC靠谱
- QUIC可以为除HTTP协议以外的应用层协议提供支持
- TCP、UDP、QUIC均为运输层协议，HTTP协议是应用层协议
