QUIC 仅适用于 HTTP/2,不适用于 HTTP/1.1。
HTTP/1.1 在其一个 TCP 连接上一次发送一个请求。浏览器打开 6-8 个连接以允许某种程度的并行化,但除了那个 hack,HTTP/1.1 基本上是同步的——您发送一个请求并且在该请求得到全部响应之前不能再次使用该连接。所以 HTTP/1.1 有一个Head of Line (HOL) 阻塞问题,因为缓慢或延迟的响应会阻塞连接,因此它不能用于可以响应的资源。
HTTP/2 是一种二进制、多路复用协议,这基本上意味着请求和响应被拆分为可以在单个 TCP 连接上发送并混合在一起的数据包。这很好,因为 TCP 连接在 Internet 上相对昂贵,因为建立 TCP 连接需要时间,在此基础上可能设置 HTTPS,然后将 TCP 慢启动速率限制窗口建立到最佳大小。因此 HTTP/2 能够通过一个 TCP 连接发送和接收多个 HTTP 请求和响应是一项巨大的改进,并在 HTTP 级别解决了 HOL 阻塞问题。
不幸的是,HOL 阻塞问题从 HTTP 层转移到了 TCP 层。TCP 是有保证的协议 - 如果单个 TCP 数据包丢失,则重新请求它,整个连接等待丢失的数据包返回。这很棒,因为更高级别的协议(如 HTTP)可以在此基础上构建,而无需担心检查片段是否已完成或是否以正确的顺序完成 - TCP 会处理这些。这样做的缺点是像 HTTP/2 这样的协议可能不需要这种严格级别的保证。如果服务器同时在一个连接上发送 6 个 HTTP/2 响应,并且一个 TCP 数据包被丢弃,那么它只会针对其中一个响应 - 理论上其他 5 个可以继续发送,然后由浏览器。但是 TCP 禁止这样做。
因此,QUIC 旨在通过用基于 UDP 的协议替换 TCP 部分来解决这个问题,该协议保证在流级别而不是连接级别进行交付。这可以通过增强 TCP 来完成,但它是如此嵌入到许多服务器、客户端、操作系统、网络基础设施......等等,因此更容易在 UDP 上构建。最终从中学到的东西可能会被纳入 TCP。在此之前,QUIC 允许快速实验和创新,因为 UDP 非常非常轻量级,并且它的任何添加(例如交付保证)基本上都是在用户空间领域实现的,而不是无法升级的较低级别的内部。QUIC 最终可能会用于 HTTP 以外的协议,但目前这是它的主要用例。
所以 QUIC 有效地替代了 TCP 部分,但它也需要改变 HTTP/2 的底层部分,这意味着它还需要实现中间 TLS 部分。解释它的位置的最佳图表是这个图表(取自这个演示文稿):
我之前已经成功地使用 QUIC 运行 HTTP1.1。
我严重怀疑这一点。根据上面的解释,QUIC 仅在 HTTP/2 之类的多路复用协议上才有意义。也许 Chrome 曾经调用它QUIC
而不是HTTP/2 + QUIC
,但它总是使用 HTTP/2(或其类似的前身 SPDY)。
此外,HTTP/2 实际上只改变了消息在网络上的发送方式。在更高的层次上,正如 Web 开发人员和用户所使用的那样,它的行为方式通常与 HTTP/1.1 相同,具有相同的动词(GET、POST... 等)和 HTTP 标头(大部分)。因此,由于 QUIC 只是改进了那些 HTTP/2 消息在网络上的发送方式,而不是更高级别的“HTTP”协议,因此讨论或衡量 HTTP/1.1 如何优于 QUIC(如果确实存在的话)确实没有意义不同于基于 QUIC 的 HTTP/2 - 因为基于 QUIC 的 HTTP/1.1 基本上会变成基于 QUIC 的 HTTP/2。
最后,当 QUIC 完成标准化(与通常称为 gQUIC 的非标准 Google QUIC 版本相反)时,它将使用 HTTP/2 的修改版本,称为 HTTP/3。目前浏览器将只使用 gQUIC 和 HTTP/2。