> [!abstract] 概要（abstract 日本語訳） > インターネット上でより多くのプライベート情報や機微データが転送されるにつれ、安全なエンドツーエンド通信の重要性が高まっている。残念ながら、現在の SSL 展開はセキュリティや個人情報保護が求められる限られたドメインに留まっている。普及率の低さは主にサーバサイドの重い暗号計算オーバーヘッドに起因し、インターネット上のプライバシーコストは現実的には高価なハードウェア SSL アクセラレータに直結している。 > > 本論文では、コモディティプロセッサを用いた高性能 SSL アクセラレーションを提案する。まず、現代の GPU が汎用 SSL アクセラレータとして容易に転用できることを示す。GPU の大規模並列性を活用することで、最先端の CPU を超える SSL 暗号演算の高速化を達成する。次に、AESNI や NUMA などの最新ハードウェア機能のトレードオフを慎重に活用し、高スループットと低レイテンシの両立を実現する透過的 SSL プロキシ SSLShader を構築する。評価では、RSA の GPU 実装が最速 CPU 実装比 22.6〜31.7 倍の性能向上を示す。SSLShader はコモディティサーバ1台で小ファイルにおいて 29K TPS、大ファイルにおいて 13 Gbps のスループットを達成し、これらの数値は高級商用 SSL アプライアンスに匹敵する。 ## 論文情報 - **タイトル**: SSLShader: Cheap SSL Acceleration with Commodity Processors - **著者・所属**: Keon Jang（KAIST）、Sangjin Han（KAIST）、Seungyeop Han（University of Washington）、Sue Moon（KAIST）、KyoungSoo Park（KAIST） - **媒体**: NSDI '11（8th USENIX Symposium on Networked Systems Design and Implementation） - **発表**: 2011-03-30、Boston, MA, USA - **論文 PDF**: http://www.usenix.org/events/nsdi11/tech/full_papers/Jang.pdf - **スライド**: http://www.usenix.org/events/nsdi11/tech/slides/jang.pdf ## 問題設定 **入力と出力**: HTTPS ワークロード（ハンドシェイク重視の小ファイル TPS、大ファイルスループット）を対象に、コモディティサーバ 1 台での SSL 処理スループットとレイテンシを最大化する。 **問題の核心**: 2011 年時点の SSL 普及率は全アクティブサイトの 0.5% 未満（登録証明書数が 100 万件強）。原因はサーバサイドの暗号計算コスト——最速 CPU 単一コアでも 1024-bit RSA での SSL 処理は 2K TPS 未満なのに対し、同コアの平文 HTTP は 10K TPS 以上。ハードウェア専用 SSL アクセラレータカードは高価（数千ドル）で中小規模のサービスへの普及を阻む。 **前提条件**: NVIDIA GTX580（Fermi アーキテクチャ、512 コア、1.5 GHz）などの汎用 GPU が利用可能であること。TLS_RSA_WITH_AES_128_CBC_SHA が対象暗号スイート。 ## 提案手法 ### 1. GPU 向け RSA 並列化 RSA のサーバサイド処理は秘密鍵復号（式 `M = C^d mod n`）であり、大数演算（k = 1024〜4096 ビット）が計算ボトルネック。GPU での並列化に 3 階層のアプローチを適用する。 **メッセージレベル並列性**: 複数の RSA 暗号文メッセージを独立にバッチ処理し、GPU コア全体に分散する。 **CRT（中国剰余定理）**: `M1 = C^(d mod (p-1)) mod p`・`M2 = C^(d mod (q-1)) mod q` の 2 つの k/2 ビット指数演算に分割して並列化。計算量は単純な k ビット演算の約 1/8。 **MP（多精度）並列モンゴメリ乗算**: O(s²) の逐次アルゴリズムを O(s) の並列アルゴリズムに置換。2 フェーズで実行——フェーズ 1 は s×1 の部分積を並列累積（キャリーを別配列で管理）、フェーズ 2 はキャリーが 0 になるまで繰り返し加算（平均 1〜2 回で収束）。 **CLNW（定長非ゼロウィンドウ）**: 512 ビット指数演算での乗算回数を 768 回から 607 回に削減（21% 削減）。 **GPU 固有の最適化** (Figure 3 に 9 段階の積み上げ効果を掲載): 1. `M · n` 計算の 1 ループへの統合 2. `T + M · n` の乗算ループへのインターリーブ 3. ワープ充足率向上（16 スレッド→複数メッセージ担当） 4. ループアンローリング（CUDA `#pragma unroll`） 5. 分岐発散の算術演算への置換 6. 64 ビットワード採用（スレッド数・ループ反復の半減） 7. 共有メモリバンク競合の回避（配列パディング） 8. コアループの命令レベル最適化（RAW 依存排除） 9. ポスト指数演算のオフロード（MRC、整数-オクテット変換、PKCS#1 デパディング） ### 2. AES と HMAC-SHA1 の GPU 実装 **GPU AES-CBC**: - CBC モードは「暗号化はブロック間依存あり→逐次」「復号は独立→並列可能」の非対称性 - ルックアップテーブルを共有メモリに事前ロード（グローバルメモリ比 100 倍高速） - ラウンドキーは事前展開ではなくオンデマンド導出（グローバルメモリアクセス削減） **AES-NI（AES New Instructions）**: Intel の x86 拡張命令セット。`AESENC` / `AESDEC` 1 命令で AES 1 ラウンドを処理。ソフトウェア実装比 2.5〜6 倍高速。AES-NI が有効な場合、GPU の AES アドバンテージはデータ転送コストで相殺されるため、CPU が他処理でボトルネックになる場合か AES-NI 非対応の場合のみ GPU AES が有効。 **GPU HMAC-SHA1**: - SHA-1 は前ラウンド依存があるため同一フロー内での並列化は不可 - 中間バッファを 320 バイト（事前計算版）から 64 バイト（オンデマンド計算）に削減してレジスタ収納 - ループアンローリングとインデックス定数化でコンパイラのレジスタ割り付けを誘導 - ナイーブ実装比約 100% 改善 ### 3. SSLShader アーキテクチャ **基本設計** (Figure 6): - イベント駆動スレッドベース。CPU コア 1 個につき 1 ワーカースレッドを生成 - 各スレッドは SSL コネクションを受け付けから処理まで担当（コア間キャッシュバウンシング回避） - GPU 1 枚につき 1 GPU インターフェーシングスレッドを生成 - 暗号演算タイプ（RSA / AES / HMAC-SHA1）ごとにワーカースレッド固有の入力キューを保持 - キューサイズが閾値を超えたら GPU インターフェーシングスレッドに転送してバッチ起動 **バッチ閾値** (Table 2): | 演算 | 最小閾値 | 最大閾値 | |------|---------|---------| | RSA 1024-bit | 16 | 512 | | AES128-CBC 復号 | 32（AES-NI 時: 2048） | 2048 | | AES128-CBC 暗号化 | 128（AES-NI 時: 2048） | 2048 | | HMAC-SHA1 | 128 | 2048 | 最小閾値 = GPU が単一 CPU コアを超え始める点。最大閾値 = ピークスループット達成点。 **オポチュニスティックオフロード（§5.2）**: 低負荷時は GPU バッチ待ちのレイテンシ増加を防ぐため CPU で処理し、高負荷時は GPU にオフロードするアダプティブアルゴリズム。ワーカースレッドは全ワーカーの同種演算数を確認し、最小閾値を超えていれば GPU へ転送。AES-NI 有効時は最小閾値を最大閾値と同値に設定し、CPU が本当に飽和した場合のみ GPU を使う。優先度ベーススケジューリングはスタベーションと不安定なスループットを招くため採用しない。 **NUMA 対応 GPU 共有（§5.3）**: - GPU を複数スレッドから同時に使うと高いコンテキストスイッチオーバーヘッドが生じる - GPU 共有を同一 NUMA ノード内のスレッドのみに限定 - イントラ NUMA: スレッドで実装（キュー共有が速い） - インター NUMA: プロセスで実装（ソケット作成・クローズの競合を避けるため） **非同期並列実行（§5.4）**: CUDA Compute Capability 2.0 の並列カーネル実行と DMA コピーオーバーラップを活用。GTX580 では最大 16 ストリームが同時実行可能。小バッチサイズで効果が最大（アイドル GPU コアの有効活用）、大バッチでも 30〜60% 改善（DMA とカーネル実行のオーバーラップ）。 ## 新規性——既存研究との対比 | アプローチ | 限界 | SSLShader との差異 | |-----------|------|------------------| | CPU クラスタリング | コスト・管理オーバーヘッドが線形増加 | 単一コモディティサーバで同等性能 | | ハードウェア SSL アプライアンス | 1 枚 2000 ドル超、特定アルゴリズム固定 | GPU は汎用・柔軟・コスト 1/4 | | Harrison & Waldron の GPU RSA | O(s log s)、最終集約で並列性浪費、レイテンシ 131 ms | 本実装は O(s)、レイテンシ 13.7 ms で同じカード GTX580 上で 2.3 倍スループット | | Batch RSA（Fiat's algorithm） | 4 演算バッチで 2.5 倍のみ | 数百演算のバッチで 22〜31 倍 | | tcpcrypt | プロトコル再設計が必要 | 既存 SSL/TLS をそのまま利用可能 | ## 実験設定 - **サーバ**: Intel Xeon X5650（ヘキサコア 2.66 GHz）×2 ソケット + 24 GB メモリ + NVIDIA GTX580 ×2（512 コア、1.5 GHz、1.5 GB RAM） - **OS**: Ubuntu Linux 10.04、CUDA Driver v256.40、Intel ixgbe v2.1.4 - **バックエンド**: lighttpd v1.4.28（12 ワーカプロセス）、同一マシン上で実行 - **比較対象**: lighttpd + OpenSSL 1.0.0 パッチ版（IPP 7.0 AES-NI + 最新 RSA/SHA-1 最適化済み） - IPP 7.0 は OpenSSL デフォルト比で RSA +55%、AES +10%、HMAC +22% - **クライアント**: Apache ab（レート制限拡張）、2.66 GHz Intel Nehalem クアッドコア×7 台 - **評価指標**: HTTPS TPS（小ファイル 43 バイト）、バルクスループット（4 KB〜64 MB）、レスポンス時間 CDF ## 実験結果 ### RSA マイクロベンチマーク（Table 1 / Figure 4） | キーサイズ | CPU 単コア（ops/s） | GTX580 MP ピーク（ops/s） | 速度向上 | |-----------|-------------------|--------------------------|---------| | 512-bit | 13,924 | 322,167 | **23.1×** | | 1024-bit | 3,301 | 74,732 | **22.6×** | | 2048-bit | 438 | 12,044 | **27.5×** | | 4096-bit | 67 | 1,661 | **31.7×** | 1024-bit ピーク時のレイテンシは 13.7 ms（512 メッセージバッチ）。GTX580 単体での性能は 3 ソケットのヘキサコア Xeon に相当。 ### AES・HMAC-SHA1 マイクロベンチマーク（Figure 5） | 実装 | AES-CBC 暗号化 | AES-CBC 復号 | HMAC-SHA1 | |------|--------------|------------|-----------| | GPU（GTX580）+ 転送コスト込み | 8.8 Gbps | 10.0 Gbps | 31 Gbps | | GPU（GTX580）転送コスト除外 | 21.9 Gbps | 33.9 Gbps | 124 Gbps | | CPU 単コア（AES-NI なし） | 1.3 Gbps | – | – | | CPU 単コア（AES-NI あり） | 5 Gbps | 15 Gbps | – | GPU AES（転送込み）は AES-NI 非対応 CPU 比 6.5〜7.4 コア相当。**AES-NI ありでは GPU は 1〜2 コアで追い越される**ため、AES-NI が利用可能な場合は CPU に任せるのが合理的。 ### SSL ハンドシェイク性能（Figure 8） | RSA キー | lighttpd + OpenSSL | SSLShader | 向上率 | |---------|-------------------|-----------|--------| | 1024-bit | 11.2K TPS | **29K TPS** | **2.5×** | | 2048-bit | 3.6K TPS | **21.8K TPS** | **6.0×** | 2048-bit での大幅改善が重要——2010 年に 768-bit RSA が解読され、NIST は 2011 年時点で 2048-bit を推奨しており、安全な運用実態における性能改善として意義が大きい。 CPU 使用率内訳（oprofile、1024-bit RSA、16K 同時クライアント時、Table 3）: - カーネル NIC ドライバ: 2.32% - カーネル（TCP/IP スタック含む）: **60.35%**（コネクション受付がボトルネック） - SSLShader 本体: 5.31% - libc（メモリコピーなど）: 9.88% - IPP + libcrypto（暗号演算）: 12.89% 暗号演算は CPU 時間の 13% に留まり、ボトルネックはマルチコアスケールしない Linux カーネルのコネクション受付にある。 ### レスポンス時間分布（Figure 9） 低負荷（1K TPS）時: lighttpd 中央値 2 ms、SSLShader 中央値 3 ms（プロキシオーバーヘッド +1 ms 程度） 高負荷（29K TPS / 1K 同時クライアント）時: SSLShader の 50 パーセンタイル 39 ms・99 パーセンタイル 64 ms に対し、11K TPS の lighttpd は 76 ms・260 ms——**より低い TPS のまま SSLShader より遅い** ### バルクデータ転送性能（Figure 10） | 設定 | ピークスループット | 備考 | |------|----------------|------| | lighttpd（AES-NI あり） | 16.0 Gbps | 64 MB 超で頭打ち | | SSLShader（AES-NI あり） | **13 Gbps** | 4 MB 超でプロキシオーバーヘッドが支配的 | | SSLShader（AES-NI なし） | 8.9 Gbps | lighttpd 9.6 Gbps をわずかに下回る | 4 MB 未満の小〜中コンテンツでは SSLShader が 1.3〜2.2 倍高速。4 MB 超ではプロキシのデータコピー（CPU 時間の 30%）と割り込み処理（20%）がボトルネックになり lighttpd が逆転。典型 Web オブジェクト・メールが 100 KB 未満であることを考慮するとトレードオフは許容範囲。 ### 性能/コスト比較（Table 4、2011 年 2 月時点価格） | ハードウェア | 価格 | RSA（ops/s/$） | AES-ENC（Mbps/$） | SHA-1（Mbps/$） | |------------|------|----------------|------------------|-----------------| | Xeon X5650 | $996 | 19.9 | 30.6 | 20.2 | | Core i7 920 | $288 | 45.8 | 18.9 | 46.5 | | GTX580 | **$499** | **185.3** | 21.3 | **62.3** | | CN1620（SSL カード） | $2,129 | 30.5 | 2.8 | 2.8 | GTX580 は SSL アプライアンスカード（CN1620）比で RSA 性能/ドルが **6.1 倍**。ハードウェア SSL アクセラレータ（7K〜200K RSA ops/s）に匹敵しつつ、価格は 1/4 以下。 ## 考察 **GPU は RSA に特に有効**。RSA は独立した大数演算であり GPU の SIMD 大規模並列性と相性が良い。一方 AES は AES-NI があれば CPU 処理が GPU を凌駕し、HMAC-SHA1 はフロー内依存で並列化が制限される。この非対称性が「RSA は GPU、AES は CPU（AES-NI）」という役割分担設計の根拠。 **Linux カーネルのコネクション受付がボトルネック**。1024-bit RSA ではスループット上限が GPU の RSA 処理能力でなくカーネルのコネクション受付（CPU 時間の 60%）で決まる。GPU のアイドル容量が残っている。 **GPU-CPU 統合（AMD Fusion 等）が課題解決の鍵**。当時のネックである GPU-CPU 間 DMA 転送コストは CPU 内蔵 GPU で解消されると期待。 ## 強み / 弱点・課題 **強み**: - GPU を SSL アクセラレータとして転用する実用的なエンドツーエンドシステムを実証 - 暗号演算の役割分担（RSA=GPU、AES=AES-NI CPU）という実践的な設計判断 - オポチュニスティックオフロードによるレイテンシ・スループットの両立 - 透過的プロキシ設計で既存サーバを無変更で前段展開可能 - 性能/ドルで SSL 専用カードを大幅に上回る **弱点・課題**: - プロキシのデータコピーオーバーヘッドが大ファイル転送でボトルネック（4 MB 超で lighttpd に逆転） - Linux カーネルのコネクション受付がマルチコアスケールせず 1024-bit RSA 性能の天井を決める - GPU AES は AES-NI あり CPU に劣るため AES-NI 非対応環境や CPU 飽和時のみ有効 - 小バッチサイズでの GPU レイテンシ（1024-bit で最低 3.8 ms）は低負荷時のオポチュニスティックオフロードで回避しているが、超低レイテンシが要件の場合は制約 ## 関連 - [[Keon Jang]] — 第一著者、KAIST - [[Sangjin Han]] — 共著者、KAIST - [[Seungyeop Han]] — 共著者、University of Washington - [[Sue Moon]] — 共著者、KAIST - [[KyoungSoo Park]] — 責任著者、KAIST - [[KAIST]] — 主著者所属機関 - [[SSL TLS アクセラレーション]] — 本論文が扱う中核概念 - [[GPU最適化]] — GPU 並列化手法の関連概念 - [[@2020__NSDI__AccelTCP - Accelerating Network Applications with Stateful TCP Offloading]] — 同グループによる後続研究（NIC オフロード）