为什么 Google.com 切换到 SPDY (HTTP/2+QUIC/35) 而不是 HTTP/2

Why did Google.com switch to SPDY (HTTP/2+QUIC/35) instead of HTTP/2

几天前我看到 Google.com 在使用 HTTP/2，但昨天我发现 Google.com 已经切换到 SPDY (HTTP/2+QUIC/35 ).

两个问题：

如您所知，HTTP/2 扩展了 SPDY，为什么 Google.com 回滚到 SPDY？
SPDY和SPDY有什么区别(HTTP/2+QUIC/35)?

你确定他们做到了吗？或者您用来显示此信息的工具 (this extension perhaps?) 是否选择这样显示？在 Chrome 的开发者工具中显示“网络”选项卡，看看 Chrome 真正认为它在说什么。

HTTP/2 是 SPDY 的标准版本，所以说 "SPDY-enabled (HTTP/2)" 是没有意义的。除非这意味着它可以与 SPDY ("SPDY-enabled") 通话，但在这种情况下选择与 HTTP/2 通话，因为这样更好吗？

最后，QUIC 是 Google 正在试验的一种新协议，它取代了 SPDY 和 HTTP/2 构建于其上的 TCP 网络层。所以两者都可以使用 QUIC 而不是 TCP，而且它通常比 TCP 更快（因此名称听起来像 "quick" 并且是 "Quick UDP Internet Connections" 的首字母缩写词）

http/2+quic/35不是Speedy，它是一种新的通信协议，基于UDP而不是TCP，命名为QUIC。

让我们引用 https://www.chromium.org/quic :

Key advantages of QUIC over TCP+TLS+HTTP2 include:

Connection establishment latency

Improved congestion control

Multiplexing without head-of-line blocking

Forward error correction

Connection migration

一个很好的演示文稿is available in this blog article。

事实上，整个 QUIC 项目都被用来以一种更加被动的方式绕过 TCP 标准。 Google 多年来一直在 QUIC 上进行实验，在 Chrome 数十亿用户的浏览器中透明地进行，现在切换到它默认，如果它有效（有回退通过 TCP 到 "classical" HTTP/2。

从开发者的角度来看，QUIC 有一个 HTTP/2 接口，具有它的所有功能。

据我所知，只有 LiteSpeed supports QUIC outside of Google - not the OpenLiteSpeed version yet (sadly) - and the go-based Caddy server。

为什么 Google.com 切换到 SPDY (HTTP/2+QUIC/35) 而不是 HTTP/2

Why did Google.com switch to SPDY (HTTP/2+QUIC/35) instead of HTTP/2

google-chrome

spdy

http2

quic