JEP 244: TLS Application-Layer Protocol Negotiation Extension | TLS 应用层协议协商扩展
摘要
扩展 javax.net.ssl 包以支持 TLS 应用层协议协商（ALPN）扩展，该扩展提供了在 TLS 连接中协商应用协议的手段。
动机
为了支持希望在同一传输层端口上使用多个应用层协议的 TLS 客户端和服务器，ALPN 扩展允许客户端提供其支持的应用层协议列表（按优先级排序）。服务器可以选择一个广告的客户端协议，并告诉客户端将在 TLS 连接中使用哪个协议。
这个 TLS 扩展的一个重要用户将是 HTTP/2客户端（JEP 110），它将实现 HTTP/2。
描述
此功能定义了公共 API，以协商可以在给定的 TLS 连接上传输的应用层协议。在初始 TLS 握手期间，在客户端和服务器之间传递协议名称。
TLS 应用程序可以使用扩展的 SSLParameters 类在给定的连接上获取和设置它可以支持的应用层协议列表。TLS 实现还使用此类来检索应用程序声明的协议名称。
默认行为是选择启用的应用程序协议值的服务器最优交集值。
服务器应用程序还可以外部扫描初始明文 ClientHellos 以为此连接选择适当的 ALPN 协议值。此决定可能基于提供的 TLS 协议，密码套件，服务器名称指示值等。然后，服务器应用程序可以：
- 如果支持它，则选择提供的协议之一，
- 决定远程提供的和本地支持的 ALPN 值是互斥的，或者
- 完全忽略扩展。
服务器可能根据连接中可用的应用程序协议更改连接参数，例如广告的服务器证书。
在 SSL / TLS 握手开始后，SSLSocket / SSLEngine上有新方法允许应用程序查询是否已经选择了 ALPN 值（getHandshakeApplicationProtocol()）。
一旦 TLS 握手完成，应用程序可以使用 getApplicationProtocol() 方法检查已协商出哪个协议。
建议的设计遵循 JDK 8 中引入的 服务器名称指示扩展（JEP 114） 所使用的类似 API 方法，但不同的是，ALPN 值与连接而非 SSLSession 相关联。
测试
- 客户端实现应能够与支持 HTTP / 2 和 SPDY 的 Web 服务器一起使用（例如，Apache / mod_spdy，Jetty 等）。SPDY 日益不重要，因为 HTTP / 2 是其公开替代品。SPDY 实现很快就会变得很少。我们当然将使用 JEP 110 中的新 HTTP / 2 客户端进行测试。
- 服务器端实现应针对能够使用 ALPN 的众所周知的 TLS 客户端实现进行测试（例如，GnuTLS，NSS，OpenSSL（beta）和 Microsoft SChannel 8.1）。我们目前不计划引入任何支持 ALPN 的服务器端应用程序。在这里的大多数测试将是一些简单的 TLS 握手并检查协商的值。