java - netty 的处理程序/ssl 包的设计/架构？

Question

我一直在仔细查看 netty 处理程序/ssl 包:https://github.com/netty/netty/tree/4.1/handler/src/main/java/io/netty/handler/ssl

我注意到它依赖于少数外部项目来完成 SSL 的实际工作，我正试图弄清楚它们是如何组合在一起的。这是我发现的(到目前为止):

• BouncyCaSTLe(用于自签名证书？)
• Jetty(用于 ALPN？)
• TC Native(用于基于 OpenSSL/BoringSSL 的 SSLEngine？)
• Conscrypt(也用于基于 OpenSSL/BoringSSL 的 SSL 东西？)

所有这些部分如何组合在一起？我注意到 pom.xml 中的许多依赖项都标记为可选，因此不清楚这些依赖项中哪些是相互排斥的。

例如，我可以看出 Conscrypt 和 TC Native 的一种变体都将链接到 BoringSSL 的静态版本中，这被认为是不行的，那么这是否意味着在实践中您只能依赖 Conscrypt 或 TC Native？此外，我无法弄清楚 jetty 的哪一部分提供了正在使用的 ALPN 代码。

Netty 网站上是否有一个区域有像这样的系统方面的详细设计文档？想知道如何学习这个大型开源项目的设计，而不仅仅是在代码中闲逛。

谢谢!

Answer 1

BouncyCaSTLe 用于自签名证书和类似证书；这种依赖很容易避免。 Jetty ALPN、netty-tcnative 和 Conscrypt 都是可选的；您不必使用它们中的任何一个。

Jetty ALPN修改OpenJDK源码添加ALPN支持 Java 的 TLS 实现。这实际上只在执行 HTTP/2 时才需要。您可以使用 Jetty ALPN Agent 启用 Jetty ALPN .

Netty-tcnative 和 Conscrypt 也提供 ALPN 支持。但它们也快得多，尤其是在使用 AES GCM 时。它们是 OpenSSL、LibreSSL 或 BoringSSL 上的包装器，因此用已在许多其他语言中使用的相同库替换 Java TLS 实现。这也可以为 Java 带来新的安全特性。

您注意到有包含 BoringSSL 的静态版本；这允许在没有(最新的)OpenSSL 的 Windows 和 OS X 上轻松运行，并为 Debian 等 Linux 发行版带来更新的 TLS 功能(如 ALPN)。这对于用户与开发人员属于不同一方的更传统的应用程序真的很有用。

Conscrypt 已经在 Android 上存在了很长一段时间，但它对 OpenJDK 来说还很新，因此 Netty 支持也很新。从短期来看，netty-tcnative 比 Conscrypt 更受欢迎。不过，这种情况可能会迅速改变。

如果您使用的是 HTTP/2，那么了解 Jetty APLN、Netty-tcnative 和 Conscrypt 很重要。但大多数人最终只是想要更好的性能或 Java 实现不支持的特定 TLS 功能，因此开始使用 netty-tcnative。