应用层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 ）工作原理的图示。

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

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指南。

原文链接：

TLS Improvements Backported to Java 8

创作场景

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