4.xの要件
Nettyプロジェクトは、様々なサブモジュールで構成されています。各サブモジュールの具体的な要件については、以下のそれぞれのセクションを参照してください。
一般的に、各サブモジュールの基本機能は、実行にはJava 6以上、コンパイルにはJava 7以上が必要です。
このコーデックは、HTTP/2プロトコルとHPACKの実装を提供します。
HTTP/2 RFCはTLSの使用を必須としていませんが、TLSを使用する場合には要件が適用されます[1][2][3]。TLS経由のHTTP/2は、h2プロトコルの使用をネゴシエートするためにALPNの使用を義務付けています。ALPNは比較的新しい標準であり、Nettyは（可能な限り）ALPNをまだサポートしていないシステムのためにNPNを介したプロトコルネゴシエーションをサポートしています。
現在、NettyでTLSを使用するための推奨アプローチです。
- 速度：ローカルテストでは、JDKよりも3倍の性能向上が見られました。HTTP/2 RFCで要求される唯一の暗号スイートで使用されているGCMは、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実装の制限です。
- ALPNサポートにはOpenSSLバージョン1.0.2以上、NPNにはバージョン1.0.1以上が必要です。
- クラスパスに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でのサポートがないため、OpenJDKにはJetty-ALPN（またはJava 8未満の場合はJetty-NPN）bootclasspath拡張機能を使用する必要があります。そのためには、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を使用するか、Bouncy Castleなどの代替JCE実装を使用することをお勧めします。これが現実的ではない場合、他の暗号を使用することは可能ですが、呼び出す予定のサービスもこれらの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のsetterがあり、ALPNまたはNPNの設定に使用されます。HTTP/2の例（ALPN）とSPDYの例（NPN）を参照してください。