カーネルTLSオフロード本番有効化｜NIC互換性確認と性能測定・切り戻し設計

カーネルTLSオフロードとは何か、なぜ本番で検討するのか

カーネルTLS（kTLS）オフロードは、TLSの暗号化・復号処理をカーネル空間もしくは対応NICのハードウェアに移譲する仕組みです。Linux 4.13 でカーネルTLSソケット（AF_KTLS）が導入され、Linux 4.18 以降でNICへのTX方向オフロードが整備されました。RX方向のオフロードはその後のカーネルで順次改善されており、2026年時点のメインラインでは TX/RX ともに実用的な状態です。

従来の TLS 処理はユーザー空間の OpenSSL がすべての暗号演算を担います。スループットが上がるにつれ、CPU の暗号化コストが顕在化します。kTLS オフロードを利用すると、対応 NIC であれば暗号化をハードウェアで処理するため、アプリケーション CPU の使用率を抑えながらスループットを維持できます。対応 NIC がない環境でも「カーネル内 TLS」としてゼロコピー送信パスが使えるため、一定のメリットがあります。

ただし、kTLS オフロードはすべての NIC・ドライバで動作するわけではありません。本番適用の前に互換性確認と性能測定を行うことが、安全な導入の前提です。

NIC互換性の確認手順

kTLS のハードウェアオフロードに対応する代表的な NIC は次のとおりです。

• NVIDIA/Mellanox ConnectX-5 以降（mlx5 ドライバ）
• Intel E810 シリーズ（ice ドライバ）
• Chelsio T6（cxgb4 ドライバ）
• Marvell FastLinQ 41000 シリーズ（qede ドライバ）

まずドライバが kTLS オフロードに対応しているかどうかを ethtool で確認します。

$ ethtool -k eth0 | grep tls
tls-hw-tx-offload: on
tls-hw-rx-offload: on
tls-hw-record: off [fixed]

tls-hw-tx-offload: on が表示されれば TX 方向のハードウェアオフロードが利用可能です。off [fixed] の項目は変更不可を意味します。

カーネルモジュール側では tls モジュールのロードを確認します。

$ lsmod | grep tls
tls                   114688  0

# ロードされていない場合
$ modprobe tls

次に、アプリケーション側の対応状況も確認が必要です。nginx は 1.21.4 以降で kTLS サポートが組み込まれており、OpenSSL は 3.0 以降で kTLS ソケットを自動的に検出します。アプリケーションのバージョンが古い場合は、まずアップデートを優先してください。

# OpenSSLのkTLS対応確認
$ openssl version
OpenSSL 3.3.2

$ openssl s_client -ktls -connect example.com:443 2>&1 | grep -i ktls

本番有効化の手順

kTLS の有効化はカーネルパラメータの変更と、アプリケーション設定の2段階で行います。

カーネル側の設定

カーネル 5.2 以降では net.ipv4.tcp_limit_output_bytes と kTLS の組み合わせで問題が出るケースが報告されています。適用前に現在の設定値を記録しておきます。

# 現状記録（切り戻し用）
$ sysctl net.ipv4.tcp_limit_output_bytes > /tmp/sysctl_before_ktls.txt

# tls モジュールの永続ロード
$ echo "tls" >> /etc/modules-load.d/ktls.conf

nginx での有効化

nginx の設定ファイルに sendfile on; と ssl_conf_command Options KTLS; を追加します。

http {
    sendfile on;
    ssl_conf_command Options KTLS;

    server {
        listen 443 ssl;
        ssl_certificate     /etc/nginx/certs/server.crt;
        ssl_certificate_key /etc/nginx/certs/server.key;
        ssl_protocols       TLSv1.3;
    }
}

設定後は nginx -t で構文確認を行い、systemctl reload nginx で反映します。TLSv1.3 と kTLS の組み合わせが最もオフロード効率が高く、TLSv1.2 では一部の暗号スイートが kTLS 非対応になる場合があります。

有効化の確認

オフロードが実際に機能しているかどうかは、ethtool の統計カウンタで確認できます。

$ ethtool -S eth0 | grep -i tls
tx_tls_encrypted_packets: 12450
tx_tls_encrypted_bytes: 18432000
tx_tls_ooo: 0
tx_tls_drop_no_sync_data: 0

tx_tls_encrypted_packets が増加していればハードウェアオフロードが動いています。tx_tls_ooo（out-of-order）が継続的に増加する場合は、パケット順序の問題が発生しているため調査が必要です。

性能測定の方法

有効化の前後で定量的な比較を行うことが、本番判断の根拠になります。以下は想定例として参考にしてください。実環境での数値は NIC の世代・ケーブル速度・サーバー負荷条件によって大きく異なります。

スループット測定（iperf3 + TLS）

# サーバー側
$ iperf3 -s --tls --tls-cert /etc/nginx/certs/server.crt \
           --tls-key /etc/nginx/certs/server.key

# クライアント側（10秒間、並列4ストリーム）
$ iperf3 -c 192.168.1.10 --tls -t 10 -P 4

TLS ハンドシェイクのオーバーヘッドを除くために、測定は数回実行して安定した値を採用します。

CPU使用率の比較

負荷をかけながら perf top または sar -u 1 で CPU 使用率を観察します。kTLS オフロード前後で __aes_crypt_ctr や aesni_cbc_dec などの暗号関連シンボルがどの程度 CPU を消費しているかを比較します。

# 暗号化関連のカーネル関数の CPU 消費を確認
$ perf top -p $(pgrep nginx) --sort cpu,symbol | grep -E "aes|tls|crypt"

想定例として、10GbE NIC で kTLS TX オフロードを有効にした場合、高スループット時の CPU 使用率が kTLS なしと比較して減少する傾向がある一般的なケースが報告されています。ただし、環境によっては効果が限定的な場合もあるため、自環境での測定が必須です。

レイテンシへの影響確認

スループットが改善しても、レイテンシが悪化しないかも確認します。wrk や hey を使ったHTTPS負荷テストで p95・p99 レイテンシを計測し、許容範囲内であることを確認します。

$ wrk -t4 -c100 -d30s https://192.168.1.10/
Running 30s test @ https://192.168.1.10/
  4 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.23ms    0.45ms   8.12ms   89.54%
    Req/Sec    20.45k     1.23k   24.56k    72.00%

切り戻し設計と注意点

kTLS を有効化してから問題が発覚した場合の切り戻しは、比較的シンプルです。nginx の設定から ssl_conf_command Options KTLS; を削除して reload するだけで、アプリケーションレベルでは無効化できます。

# nginx 設定から KTLS オプションを削除後
$ nginx -t && systemctl reload nginx

# tls モジュールをアンロードしたい場合（依存確認後）
$ lsmod | grep tls
$ rmmod tls

切り戻し手順を事前に文書化し、変更管理のチケットに含めておくことが重要です。また、以下の点は本番適用前に必ず把握しておきます。

• TLSセッション再利用（session resumption）との干渉： TLSv1.3 の 0-RTT と kTLS の組み合わせは、一部のカーネルバージョンで予期しない挙動を示す事例が報告されています。ステージング環境で検証を行ってください。
• パケットキャプチャの制約： kTLS オフロードが有効な場合、tcpdump で取得したキャプチャはカーネル内での暗号化後のデータになります。デバッグ時に平文が確認できなくなるため、デバッグ用の証明書/キー管理を事前に整備しておきます。
• コンテナ環境での考慮： コンテナから NIC のハードウェアオフロードを利用するには、ホストの NIC を SR-IOV などで割り当てるか、ホスト側のカーネル TLS を経由する構成が必要です。コンテナ内からは ethtool 統計が見えない場合があります。
• よくあるつまずき： OpenSSL のビルド時に enable-ktls オプションが有効になっていないと、共有ライブラリとして配布された OpenSSL でも kTLS が使われません。openssl version -f で OPENSSL_USE_KTLS フラグを確認します。

2026年現行環境での差分と動向

2026年時点で主要ディストリビューションのデフォルトカーネルは以下のような状況です。

• Ubuntu 24.04 LTS（HWE含む）： カーネル 6.8 系が標準。tls モジュールはデフォルトでビルド済み。mlx5 ドライバの TX/RX オフロードは安定稼働しています。
• RHEL 9.x / AlmaLinux 9.x： カーネル 5.14 系ベース。kTLS 自体は動作しますが、RX オフロードはアップストリームほど成熟していない場合があります。kpatch との組み合わせは事前確認が必要です。
• Debian 12 (Bookworm)： カーネル 6.1 系。backport カーネルを利用することで新しいドライバの恩恵を受けやすくなります。

OpenSSL 3.x 系は現在ほぼすべての主要ディストリで標準採用されており、kTLS の自動検出が有効な状態で配布されています。一方、BoringSSL（Chrome/Androidのフォーク）や wolfSSL を使うシステムでは対応状況が異なるため、個別確認が必要です。

NVIDIA BlueField DPU（データプロセッシングユニット）を利用する構成では、kTLS のオフロード先をサーバー CPU ではなく DPU アームコアに向ける構成も可能です。この場合は mlx5 ドライバの追加設定とオフロードポリシーの定義が必要で、運用の複雑度が上がります。まずは汎用 kTLS TXオフロードで効果を測定してから、高度な構成を検討するアプローチが現実的です。

カーネル TLS オフロードは、導入のハードルが下がってきた一方で、「どの層でデバッグするか」「どの NIC 機能を信頼するか」という運用上の判断が伴います。互換性確認・性能測定・切り戻し手順の3点を事前に整備することが、本番適用を安全に進める上で欠かせません。