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

原文链接:

TLS Improvements Backported to Java 8

原文 

https://www.infoq.cn/article/uKcr70FUSOeFPMvwVZgC

本站部分文章源于互联网,本着传播知识、有益学习和研究的目的进行的转载,为网友免费提供。如有著作权人或出版方提出异议,本站将立即删除。如果您对文章转载有任何疑问请告之我们,以便我们及时纠正。

PS:推荐一个微信公众号: askHarries 或者qq群:474807195,里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

转载请注明原文出处:Harries Blog™ » Java 8 已反向移植 TLS :软件所有者可通过 HTTP/2 进行通信

赞 (0)
分享到:更多 ()

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址