影响 HTTP 网络请求的因素：
- 带宽
- 延迟
HTTP 的瓶颈
- 单路连接（一个TCP 连接只能包含一个 http 请求），请求低效
- HTTP 只允许由客户端主动发起请求
- HTTP 头部冗余
兼容 HTTP 基础功能追加协议
-
Websocket
http 协议
AJAX 轮询（需要服务器高响应）
客户端定时发送请求给服务端，服务端对每次请求都进行响应返回
Long Poll（需要服务器高并发）
采取阻塞模型，客户端定时发送请求给服务端，服务端接收到请求后，直到有消息改变才响应返回
websocket 协议
服务端可以主动推送消息给客户端
-
SPDY（已经消失在茫茫的历史长河中了） 在 TLS 与 HTTP 中间添加了一个 SPDY 的会话层 ，是对于 HTTP 的增强
增强
- 多路复用（一个TCP 连接可包含多个 http 请求，并且能设置请求优先顺序），请求优化
- 支持服务器推送数据（推送网页资源）
- 压缩了 HTTP 头
- 强制使用 SSL 传输协议
-
HTTP2.0（基于SPDY 核心） 性能增强核：二进制分帧
- 首部压缩（第一次请求将请求头切割成一个个首部帧，放入首部流中传输。当第二请求过来，比对两次请求的首部帧，只有不同的首部帧才放入首部流中进行传输）
- 多路复用（将多个请求的请求头和请求体分割成一个个帧，在放入流中进行传输，传输到服务器后，每个帧就根据帧头部顺序排列形成数据）
- 并行双向字节流（并行发送多个响应和请求）
- 请求优先级
-
HTTP3.0（基于QUIC 协议） 由下至上层级不同于 HTTP 2.0 的结构：IP ——> TCP ——> TLS ——> SPDY——> HTTP HTTP 3.0 的结构变化：IP ——> UDP ——> QUIC ——> SPDY ——> HTTP
HTTP 2.0 痛点：
- 如果传输过程中出现丢包，线路等待回传期间会造成头部阻塞，传输效率甚至比不上 HTTP 1.1
- 建立连接的握手延迟大（TCP底层原因） QUIC 解决方案：
- 0 RTT（缓存会话上下文）
- 没有头部阻塞的多路复用 特性：传输数据流的每个包中不仅包含自己的内容，还包含部分其他包的信息，如果传输过程中丢了一个包，可以靠其他包的冗余数据计算出丢失包的内容，不需要数据重传。（缺点是只能丢一个包，如果丢包数量超过一个，就只能重传）
-
WebDev 协议（因为使用场景过少，基本消失在茫茫的历史长河中了） 用于线上实时编辑文件网盘
