我正在尝试使用HTTP / 2,HTTP1.1,QUIC和TCP在Chromium中进行一些测试。我想尝试不同的协议组合。我在浏览器中遇到了一些非常奇怪的行为。当我想尝试HTTP1.1 + QUIC时,我用以下方式启动浏览器:
chromium-browser --disable-http2 --enable-quic
我可以在chrome:// net-internals /看到HTTP2被禁用且QUIC已启用。但是,当我向支持HTTP2和QUIC的服务器发出Web请求时,我得到:
为什么会说如果在Chrome:// net-internals /?
中明确说出http2 enabled: false
,就会使用HTTP / 2
我之前已成功使用QUIC运行HTTP1.1。 QUIC是否已更新为仅适用于HTTP / 2?或者'协议' -field显示错误的协议?
我很乐意,如果其他人成功使用QUIC和HTTP1.1
非常感谢!
答案 0 :(得分:1)
QUIC仅适用于HTTP / 2,对HTTP / 1.1没有意义。
HTTP / 1.1在其一个TCP连接上一次发送一个请求。浏览器打开6-8个连接以允许某种程度的并行化,但除了该黑客之外,HTTP / 1.1基本上是同步的 - 您发送请求并且在该请求完全响应之前不能再次使用该连接。因此,HTTP / 1.1有Head of Line (HOL) blocking problem作为缓慢或延迟的响应将阻止连接,因此它不能用于可以响应的资源。
HTTP / 2是一种二进制multiplexed协议,它基本上意味着请求和响应被分成数据包,这些数据包可以在单个TCP连接上发送并混合。这很好,因为TCP连接在因特网上相对昂贵,因为有时间设置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部分之间实现。解释它的最佳图表是此图(取自this presentation):
我之前已成功使用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 which will be called HTTP/3的修改版本。目前浏览器只使用gQUIC和HTTP / 2.
答案 1 :(得分:0)
如果您想要快速测试,请前往 https://http3.is。
这是一个由fastly创建的测试网站。