转载

Java 8 已反向移植 TLS ：软件所有者可通过 HTTP/2 进行通信

应用层 TLS 协商的改进已经被反向移植到 Java 8 中，这使得客户端能够利用 HTTP/2 的网络能力。在此之前，需在 Java 9 及更高版本上才能使用该功能。

这一变化对老的客户端来说是一个重要的增强，因为 New Relic 最近的“ Java 状态 ”报告显示：85％的系统都是运行在 Java 8 上。该反向移植，最初是作为 JEP 244 随 Java 9 一起发布的，它使得在 Java 8 系列中更新的客户端能够通过请求 HTTP/2 流量与最新的非 Java 系统进行通信。如果不进行更新，这些客户端将被迫采用旧的 TLS 结构，或服务端应用程序必须在其前面采用一个 SSL 终结器来支持较新的应用程序协议。 KeyCDN 已经发布了一个有关应用层协议协商（ Application Layer Protocol Negotiation ）工作原理的图示。

每种技术在很多生产系统中都已经使用了好些年。

Java 8 于 2014 年 3 月首次发布
HTTP/2 于 2015 年 5 月实现标准化
包含此功能的 Java 9 于 2017 年 9 月发布

HTTP/2 是建立在一个名为 SPDY 的 Google 驱动计划之上。尽管底层 SPDY 的工作在 Java 8 的时间框架内是可用的，但是在 Java 9 发布之前，还没有可用的正式行业标准。在 HTTP/2 之前，SPDY 是一个由 Google 驱动的活动，可以在无通知的情况下，随时更改或取消。

云分析师 Corey Quinn 调侃过 Google 对诸如在线讨论等产品的支持，“我只是不明白为什么 Zoom 是事实上的视频会议解决方案，而不是 Google Meet、Hangouts、Duo、Allo、Talk、Hangouts Chat、GTalk、Buzz、Wave、Messages、Spaces、Voice……” Google Meet 之后的每个项目都取消了 Google 聊天服务。Quinn 随后又上传了一张 Google 标识“G”上画有一只恶作剧的鹅的照片，他说：“故意贬低事物。你这只讨厌的鹅。”作为 HTTP/2 协议的主要领导者，Google 直到与形成该标准的同行技术组织进行了管理良好的协调之后，才逐步淘汰 SPDY。随后，该功能被包含在后续的主要 Java 版本中。

应用层协议协商（Application Layer Protocol）可以在客户端和服务器应用程序之间实现更好的压缩，从而可以在客户端问候握手期间根据适当的协议进行交换和解码。

不熟悉 TLS 内部工作原理的开发人员可以利用不同的在线工具（例如 Hardernize ）来提供“红色 - 琥珀色 - 绿色“的安全指标。这些工具并不关注 TLS 和算法配置的个别实践，而是评估服务器的响应和 TLS 的握手信息，以确定是否有其他问题，例如算法的可用性、证书密钥的强度、HTTP 的报头或服务器管理员和安全专业人员感兴趣的其他来源。

希望利用 TLS 改进的运营团队可以通过公共的 Java 8 提供程序（例如 AdoptOpenJDK）获得反向移植。希望利用此共呢个的开发团队应该考虑遵循标题为“ 从 Java 8 到 11 ”的 Microsoft 指南。