Netty 專案包含各種子模組。針對每個子模組的特定需求，請參考以下它們特定的各章節。

一般而言，每個子模組的基本功能需要 Java 6+ 才能執行，Java 7+ 才能編譯。

此編解碼器提供 HTTP/2 協定 的實作，包括 HPACK。

儘管 HTTP/2 RFC 沒有要求使用 TLS，但如果使用 TLS，RFC 會執行需求 [1][2][3]。HTTP/2 over TLS 要求使用 ALPN 來協調 h2 協定的使用。ALPN 是一個相當新的標準，Netty（在可能的情況下）支援透過 NPN 針對尚未支援 ALPN 的系統進行協定協調。

這是目前推薦用於透過 Netty 執行 TLS 的方法。

1. 速度：我們在本地測試中看到，性能在 JDK 上提升了 3 倍。GCM 是唯一 HTTP/2 RFC 所需的密碼組所使用的，速度要快了 10-500 倍。
2. 密碼：OpenSSL 有自己的密碼，不受 JDK 限制的影響。這可以在 Java 7 上支援 GCM。
3. ALPN 至 NPN 回退：OpenSSL 可以同時支援 ALPN 和 NPN。Netty 中的 JDK 實作一次只能支援 ALPN 或 NPN，而 NPN 只在 JDK 7 中受支援。
4. 與 Java 版本無關：不需要根據 JDK 更新使用不同的函式庫版本。這是 Netty 所使用的 ALPN 及 NPN 實作中的限制。

1. OpenSSL 版本大於或等於 1.0.2 為 ALPN 支援，或版本大於或等於 1.0.1 為 NPN。
2. netty-tcnative 版本大於或等於 1.1.33.Fork7 必須在類別路徑中。
3. 受支援的平台（針對 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 進行啟動類別路徑延伸。為此，請新增一個 Xbootclasspath JVM 選項，用於參照 Jetty alpn-boot Jar 的路徑。

java -Xbootclasspath/p:/path/to/jetty/alpn/extension.jar ...

請注意，您必須使用 Jetty-ALPN Jar 的版本，該版本特別針對您使用的 Java 版本。

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 cipher 套件是唯一符合 HTTP2 cipher 需求的套件。