-
-
-
当前HTTPS是绝对的主流，HTTPS 是在 HTTP 上增加了一层 TLS 协议 或 SSL 协议，HTTP 和 TLS 两者的相对分裂的关系，导致了HTTPS有着双倍的握手延迟，HTTP握手延迟 以及 TLS握手延迟 (它们有着各自的握手延迟)
-
在HTTP2中启动HTTPS需要3个RTT (Round Trip Time) 启动 以下⬇️是举出的例子 (TCP建立连接需要一个RTT，TLS建立连接需要两个RTT，TLS1.3对此有优化，在此不讨论)
(
- HTTP 客户端：我要和大哥说话！
- TCP 客户端默默对 HTTP 客户端说，我知道你很急，但你先别急。
- TCP 客户端：嗨！服务端，你在吗？
- TCP 服务端：嗨！客户端，我在，你在吗？
- TLS客户端：Hello！能给我把钥匙吗？
- TLS 服务端：Hello！给！你的钥匙！
- HTTP 客户端：终于到我了，我要 index.html!
)
因此，在真正进行客户端和服务端进行HTTP报文交互之前，就已经过去了3个RTT，而这个固定消耗，也同样很难在现有协议的基础上得到进一步改进，所以从这个角度来说我们也需要基于QUIC的HTTP3
-
-
-
不同版本的HTTP的连接模型
-
1.0 版本: 短连接模型 Short-lived connections
每个请求都会建立一个新的的连接，在返回响应后，该连接则会被销毁。新的请求则需要重新建立一个新的连接... 虽然可以通过指定keep alive来改为保持连接模式，但默认行为是短连接
-
1.1版本: 持久连接模型 Persistent Connection
在这个版本中keep alive成为了默认行为，只要不特别指定为短连接，就为默认保持连接一段时间，以实现连接重用，解决了重复建立连接的问题，但仍然存在着队头堵塞的问题，依旧影响着HTTP的性能。
HTTP1.1对队头堵塞问题最常见的方案 是同时发起多个HTTP连接，在多个请求分散在这多个HTTP连接上，这种方案确实可以缓解队头堵塞问题，但同时建立多条HTTP连接的开销是巨大的，尤其是使用HTTPS时，TLS在每条连接上都需要重新协商，在请求数量超过HTTP连接数量时仍然需要排队，HTTP连接的数量是有限的，服务器和客户端之间的带宽是固定的，当HTTP连接数量增长是，每条连接能分得的带宽就会变小，完成一个完整的HTTP请求的时间也会被拉长，在大部分情况下，浏览器会限制同一个域名下的HTTP连接数量，通常是6
-
