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

标签 google-chrome http2 spdy quic

几天前我看到 Google.com 正在使用 HTTP/2,但昨天我意识到 Google.com 已经切换到 SPDY (HTTP/2+QUIC/35)。

enter image description here

两个问题:

  • 如您所知,HTTP/2 扩展了 SPDY,为什么 Google.com 会回滚到 SPDY?
  • SPDY 和 SPDY (HTTP/2+QUIC/35) 有什么区别?
  • 最佳答案

    http/2+quic/35不是Speedy,它是一种新的通信协议(protocol),基于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 上的“经典”HTTP/2)。

    从开发人员的角度来看,QUIC 有一个 HTTP/2 接口(interface),具有它的所有功能。

    QUIC vs HTTP/2

    据我所知,只有 LiteSpeed支持 Google 以外的 QUIC - 不是 OpenLiteSpeed版本尚未(可悲) - 和 go-based Caddy server .

    关于google-chrome - 为什么 Google.com 切换到 SPDY (HTTP/2+QUIC/35) 而不是 HTTP/2,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/42639399/

    相关文章:

    iphone - Sencha Touch 2 中的 iPhone 上的 Google Chrome 无法使用停靠底部

    javascript - 如何使用扩展程序在 Google Chrome 中加载页面?

    node.js - 为什么 WebSocket 实现在传输多个文件时比 HTTP/2 Push 慢? (Node.js/围棋)

    nginx - 哪些 Web 服务器支持 HTTP/2

    ios - AFNetworking + CocoaSPDY 发送请求,没有得到响应

    javascript - 初始化时数组 'glued'

    java - RSelenium java.lang.IllegalStateException

    ssl - GOlang/https : timeout waiting for client preface

    java - 如何在 JDK8 上使用 SPDY 运行 Jetty?

    spdy - 如果服务器实现 spdy/3 而浏览器只支持 spdy/2 会发生什么?