HTTP/2 绝对是未来的趋势，因为它现在是 HTTP 协议的标准。正如我们在Can I use 中看到的，70.15% 的浏览器支持 HTTP/2。但是 HTTP/2 太新了，有浏览器只支持 HTTP/1.x，也有很多服务器只支持 HTTP/1.x。我知道客户端可以使用 HTTP 升级机制来协商一个适当的协议来与服务器通信。例如，如果服务器支持 HTTP/2，他们的通信协议将切换到 HTTP/2，否则，使用 HTTP/1.x。但是这只适用于客户端使用的浏览器同时支持HTTP/2和HTTP/1.x的情况吧？
但是，如果只支持 HTTP/1.x 的浏览器上的用户想要与仅支持 HTTP/2 的服务器通信怎么办？服务器会忽略请求还是将错误发送回用户？
如果仅支持 HTTP/2 的浏览器上的用户想要与仅支持 HTTP/1.1 的服务器通信怎么办？我在想这个过程可能是这样的：用户向服务器发送连接前言，服务器无法识别请求，因此用户可能会收到连接错误消息。是这样吗？
或者有没有只支持 HTTP/2 的浏览器？
【问题讨论】：
重要的是要考虑到 HTTP/2 的大多数实现通过 TLS 1.2 和 ALPN 协议（应用层协议协商）使用它。因此客户端只需启动标准 TLS 连接。作为此类通信的一部分，客户端向服务器发送“Client Hello”以及一些信息：
就像：“嗨，汤姆！我是鲍勃。我会说德语、俄语和英语。我们聊聊吧”。服务器发送“Server Hello”：
“嗨，鲍勃！我建议说德语或英语”。然后客户端再发送一条短消息“OK，那我们说德语吧”，他开始说德语，而无需等待服务器的任何响应：
整个通信如下图所示
因为客户端和服务器都只使用 TLS 1.2 开始通信，双方都知道。它们在协议协商之后开始主要通信。因此，您所描述的问题在实践中是不存在的。
【讨论】：
如果浏览器只支持 HTTP/1.1，而服务器只支持 HTTP/2，则它们无法通信。服务器将无法识别客户端发送的内容（特别是没有连接前言，服务器按照规范将其视为连接错误），并将关闭连接。
“只支持HTTP/2的浏览器”不存在；如果它们支持 HTTP/2，它们也支持 HTTP/1.1。但是我们假设存在这样的浏览器。
在后一种情况下，服务器将看到连接前言并且无法识别PRI 方法。在这种情况下，服务器具体做什么取决于服务器。它可能会返回一个400 Bad Request，或者可能只是关闭连接，或者它可能会触发内部服务器错误。
【讨论】：
我尝试使用curl --http1.1 -i 访问仅限 http2 的服务器，这就是我得到的结果
HTTP/1.0 403 Forbidden
Content-Type: text/plain
Unknown ALPN Protocol, expected `h2` to be available.
If this is a HTTP request: The server was not configured with the `allowHTTP1` option or a listener for the `unknownProtocol` event.
【讨论】：