4.x 要求
Netty 项目由各种子模块组成。有关每个子模块的特定要求，请参阅其下面的特定部分。
通常，每个子模块的基本功能需要 Java 6+ 才能运行，需要 Java 7+ 才能编译。
此编解码器为 HTTP/2 协议 提供了一个实现，包括 HPACK。
尽管 HTTP/2 RFC 不要求使用 TLS，但如果使用 TLS，RFC 会强制执行要求 [1][2][3]。通过 TLS 传输的 HTTP/2 要求使用 ALPN 来协商使用 h2 协议。ALPN 是一个相当新的标准，对于尚不支持 ALPN 的系统，Netty（在可能的情况下）支持通过 NPN 进行协议协商。
目前，这是使用 Netty 进行 TLS 的推荐方法。
- 速度：在本地测试中，我们已经看到性能比 JDK 提高了 3 倍。GCM 是 HTTP/2 RFC 要求的唯一密码套件所使用的，其速度比 JDK 快 10-500 倍。
- 密码：OpenSSL 有自己的密码，不受 JDK 限制的影响。这允许在 Java 7 上支持 GCM。
- ALPN 到 NPN 回退：OpenSSL 可以同时支持 ALPN 和 NPN。Netty 的 JDK 实现仅在任何给定时间支持 ALPN 或 NPN，并且 NPN 仅在 JDK 7 中受支持。
- 与 Java 版本无关：不需要根据 JDK 更新使用不同的库版本。这是 Netty 使用的 JDK ALPN 和 NPN 实现的一个限制。
- OpenSSL 版本 >= 1.0.2（支持 ALPN）或版本 >= 1.0.1（支持 NPN）。
- netty-tcnative 版本 >= 1.1.33.Fork7 必须在类路径中。
- 支持的平台（对于 netty-tcnative）：
linux-x86_64、mac-x86_64、windows-x86_64。支持其他平台需要手动构建 netty-tcnative。
如果满足上述要求，Netty 将自动选择 OpenSSL 作为默认 TLS 提供程序。
请参阅 netty-tcnative wiki。
如果您无法使用 OpenSSL，那么替代方法是使用 JDK 进行 TLS。
Java 仅从版本 8u251 和 9 开始支持 ALPN 或 NPN。由于在较旧的 JDK 中缺乏支持，我们需要使用 Jetty-ALPN（或在 Java < 8 上使用 Jetty-NPN）OpenJDK 的启动类路径扩展。为此，添加一个引用 Jetty alpn-boot jar 路径的 Xbootclasspath JVM 选项。
java -Xbootclasspath/p:/path/to/jetty/alpn/extension.jar ...请注意，您必须使用 与您正在使用的 Java 版本相对应的 Jetty-ALPN jar 版本。
Java 7 不支持 HTTP2 RFC 推荐的密码套件。为了解决此问题，我们建议服务器尽可能使用 Java 8，或使用替代的 JCE 实现，例如 Bouncy Castle。如果这不可行，可以使用其他密码，但您需要确保您打算调用的服务也支持 HTTP/2 RFC 禁止的这些密码，并且已经评估了这样做的安全风险。
用户应注意，在 Java 8u60 之前，GCM 非常慢（1 MB/s）。使用 Java 8u60，GCM 快 10 倍（10-20 MB/s），但与 OpenSSL（~200 MB/s）相比仍然很慢，尤其是在支持 AES-NI（~1 GB/s）的情况下。GCM 密码套件是唯一符合 HTTP2 密码要求的可用套件。
SslContextBuilder 有一个 ApplicationProtocolConfig 的设置器，用于配置 ALPN 或 NPN。请参阅 HTTP/2 示例（用于 ALPN）和 SPDY 示例（用于 NPN）。