为什么 HTTP/2 不使用不同的 URI 前缀，而不是使用向后兼容支持或 HTTP/1.x 使 HTTP/2 复杂化？

Question

为什么 HTTP/2 的人决定重新使用 HTTP/1.x 的 URI 前缀（即http://...）并且——为了区分这两种协议——使 HTTP/2 复杂化，以便它处理向后的兼容性?

如果我们只使用一个 URI 来完成它的工作，而不是让一个协议复杂化来做向后兼容的回退事情，那不是更好吗？

如果http://....etc 使用 HTTP/1.x，而 http2://.... 使用 HTTP/2，会不会很好？

这样我们就不需要在 HTTP/2 中向后兼容。相反，浏览器可以决定它应该采用“http://”前缀还是“http2://”前缀。如果你问我，更好/更清洁的分离。或者更好的是，关心的网站会在旧的 http:// 上设置自己的重定向器到新的 http2://...

Answer 1

我可以尝试用其他人回答您的问题吗：

如果可能，您为什么不希望完全向后兼容，以限制用户、开发人员...等所需的更改？

好的，它可能会使 http/2 的实现对于 Web 服务器和浏览器稍微复杂一些，但可以轻松采用，这不仅可以抵消这一点。

你的建议我能想到的一些问题：

1. 用户需要决定使用哪种协议。或者 Web 服务器需要在检测到支持时重定向（如何？）。或者浏览器需要自动尝试 http/2 版本以查看站点是否支持（慢）。如果网站还没有完全实现 http/2 怎么办（参见下面关于不同内容的评论）。

2. 它打开了站点的两个不同版本的可能性（类似地，某些 https 版本的站点与 http 版本不同）。这有优点（可以根据协议优化内容）和缺点（可维护性、对用户的困惑、对 SEO 的影响……等等），但老实说，我想说的缺点更多。

3. 任何具有完全合格资源（css、js、图像...等）的网页都需要重写或遭受额外的重定向，从而导致速度变慢。或者浏览器需要知道自动升级它们 - 这可能意味着首先测试资源是否可以通过 http/2 使用，如果没有则回退到 http/1.1。如上所述，这会导致速度变慢或获取错误资源的可能性。这在从第三方站点（例如 CDN 等）加载资源时尤其复杂。书签和每篇印有 URL 的文献（广告、名片等）也存在类似问题。

4. cookie 应该跨协议吗？我们已经遇到了从 https 到 http 的 cookie 的噩梦，所以这会使情况更加复杂。

5. 理论上，整个互联网上的每个网络路由器和交换机都需要升级，然后才能通过 http/2 为单个站点提供服务。虽然这有点夸张，而且毫无疑问会有解决方法，但 Web 浏览器仅支持 http/2 而不是 https 的主要原因之一是防止在不理解 http/2 之间出现管道和切换问题。由于 http/2 仅通过 https 提供服务，并且每个包的内容都是加密的，所以中间的开关不需要知道在该加密下使用的是什么协议，只需像 http/1.1 一样将其路由https 包。

当我们从 http/1.0 迁移到 http/1.1 时，我们没有更改协议，那么为什么要使用 http/2？诚然，我们使用了 https，但这导致了它自己的混乱（见下文）。

最终，当前系统可以正常工作。据估计，平均而言，升级到 http/2 的服务器将通过 http/2 提供至少 50% 的流量（考虑到浏览器支持，这对我来说似乎很低）。如果不让它变得如此无缝，那将永远不会发生。大多数用户甚至没有意识到他们使用的很多网站都是 http/2 - 这就是应该的方式！除非绝对必要，否则对普通用户隐藏所有低级技术实现。事实上，出于这个原因，有理由完全隐藏协议（大多数非技术人员不使用它，他们当然不理解它）。

关于这一点，多年来，有些人一直在谈论使 https 成为 http 的默认设置，并在 https 不存在时回退，出于同样的原因，这并没有获得足够的关注。它会破坏太多东西。