我一直在密切关注netty handler / ssl包：https://github.com/netty/netty/tree/4.1/handler/src/main/java/io/netty/handler/ssl
我注意到它依赖于少数外部项目来完成SSL的实际工作，而我正在尝试理解它们如何组合在一起。这是我发现的（到目前为止）：
所有这些作品如何组合在一起？我注意到pom.xml中的许多deps标记为可选，因此不清楚这些依赖项中哪些是互斥的。
例如，我可以说，Conscrypt和TC Native的一个变体都会在BoringSSL的静态版本中链接，这被认为是否定的，所以这是否意味着在实践中你只依赖于Conscrypt或TC Native？另外，我无法弄清楚jetty的哪个部分提供正在使用的ALPN代码。
Netty网站的某个区域是否有像这样的系统方面的详细设计文档？想知道如何学习这个大型开源项目的设计，而不仅仅是在代码中徘徊。
谢谢！
答案 0 :(得分：0)
BouncyCastle适用于自签名证书和类似证书;依赖性很容易避免。 Jetty ALPN，netty-tcnative和Conscrypt都是可选的;你不必使用它们中的任何一个。
Jetty ALPN修改OpenJDK源以向Java的TLS实现添加ALPN支持。这实际上只在执行HTTP / 2时才需要。您可以使用Jetty ALPN Agent启用Jetty ALPN。
Netty-tcnative和Conscrypt 也提供ALPN支持。但它们也快得多，尤其是在使用AES GCM时。它们是OpenSSL，LibreSSL或BoringSSL的包装器，因此将Java TLS工具替换为许多其他语言中已使用的相同库。这也可以为Java带来新的安全功能。
您注意到有静态版本包含BoringSSL;这样就可以轻松地在没有（最新）OpenSSL的Windows和OS X上运行，并且可以将更新的TLS功能（如ALPN）引入到像Debian这样的Linux发行版中。对于更多传统应用程序而言，真正非常有用，因为用户与开发人员不同。
Conscrypt已经在Android上存在了很长一段时间，但它对OpenJDK来说还是一个新手，因此Netty的支持也很新。对于短期而言，netty-tcnative将优于Conscrypt。但这可能会迅速改变。
如果您正在使用HTTP / 2，那么了解Jetty APLN与Netty-tcnative vs Conscrypt非常重要。但大多数人最终只是希望获得更好的性能或某些TLS功能不受Java实现的支持，因此开始使用netty-tcnative。