在阅读HTTP / 2 RFC (#7540)和TLS-ALPN RFC (#7301)后，我仍然无法阅读 找出ALPN缺乏的预期行为。
假设我有一个使用HTTP / 2＆＃34; h2＆＃34; （通过TLS）与支持HTTP / 2的服务器通信，但不在＆＃34;服务器hello＆＃34;中发送ALPN扩展。 客户的预期行为是什么？
到目前为止，我见过的大多数客户都认为服务器不支持HTTP / 2并将连接降级为http / 1.1，但很少忽略（go-gRPC）继续使用HTTP / 2.
如果使用AWS Classic LB在客户端（＆＃34; h2＆＃34;）与服务器之间进行SSL终止（＆＃34; h2c＆＃34;），则此方案可能更实用。在此示例中，客户端发送值为＆＃34; h2＆＃34;的ALPN扩展，LB执行没有ALPN的SSL握手（正如他预期的那样），并且最终由于HTTP / 1.1降级而导致JAVA gRPC失败。
答案 0 :(得分：0)
完全取决于客户端和服务器。许多人仍然支持旧的NPN TLS扩展以获得SPDY和HTTP / 2支持，但官方规定只使用ALPN。
例如，在browser side上，Chrome，Firefox和Opera现在仅支持ALPN上的HTTP / 2，尽管他们都过去通过NPN支持它。在编写Safari时，IE和Edge仍然允许使用NPN或ALPN。
在服务器端，一些（例如Nginx）支持两者，而一些（例如Apache）仅支持ALPN。
我还会质疑“降级”的术语。 ALPN扩展是使用h2的请求，并且在发送单个HTTP消息之前作为TLS协商的一部分发生。所以它不是真正的降级，而是一次不成功的升级请求。
答案 1 :(得分：0)
要回答此问题，不使用alpn，但使用npn，仍然可以支持grpc。
两个澄清，