Linuxカーネル向けQUIC

• QUIC プロトコルを Linuxカーネル に正式統合する最初のパッチが提出された
• 既存の TCP が抱える限界点（遅延、head-of-line blocking、中間機器によるプロトコルの硬直化など）を改善することが目的
• QUIC は UDP ベースでマルチストリーム対応とエンドツーエンド暗号化機能を提供し、カーネルに導入されれば、より幅広いプラットフォームやハードウェアを活用できる可能性が高まる
• 初期のカーネル実装の性能は既存の TCP やカーネル TLS より低いと測定されたが、今後 ハードウェアオフロード と最適化によって性能向上が期待できる
• 現在 Samba、カーネルベースの SMB/NFS、curl などで対応の議論が活発に進んでいるが、メインラインへのマージにはなお時間を要する見込み

---

QUICプロトコル登場の背景とTCPの限界

• QUIC は、従来のインターネットで TCP が抱えてきたさまざまな問題を解決する目的で作られた
• TCP の接続過程で発生する 3-wayハンドシェイク による遅延、マルチストリーム対応の不十分さ、パケット損失に伴う head-of-line blocking 現象などによって、Web 利用体験が低下していた
• TCP のメタデータ は暗号化されないまま送信されるため情報漏えいのリスクがあり、インターネット上の ミドルボックス（中間機器） が接続情報を基にトラフィックをフィルタリングし、その結果 プロトコルの硬直化（ossification） が進んだ
• TCP の改善の試み（例: Multipath TCP など）も、既存の TCP に偽装しなければ正常に動作できない状況にある

QUICの特徴と技術的な利点

• QUIC は UDP 上で動作し、接続時に別途 3-way ハンドシェイクを必要とせず高速に接続を確立できる
• パケット損失がストリーム全体に影響しないよう、マルチストリーム 転送の設計が取り入れられている
• QUIC 関連の転送データ は常にエンドツーエンドで 暗号化（TLS ベース） され、中間機器は内部メッセージにアクセスできない
• UDP パケットが通過できるネットワーク環境であれば、QUIC も正常に動作可能

Linuxカーネル内へのQUIC統合パッチ概要

• 提出されたパッチでは IPPROTO_QUIC という新しいプロトコルタイプが導入され、既存の socket() システムコールを利用できる
• TCP と同様に bind()、connect()、listen()、accept() などのコールを使用できるが、その後の処理方式には違いがある
• TLS セッション管理および認証・暗号化処理 はユーザー空間で行われ、接続後に各端点で TLS ハンドシェイク が完了してはじめてデータ送受信が可能になる
• 初回接続後は TLS ネゴシエーション結果をキャッシュ し、2 つのシステム間で再接続する際の速度を大きく高められる

性能面の課題と見通し

• 提出された カーネル内 QUIC 実装 は、現時点では性能面で既存の カーネル TLS および TCP に劣る
  • インカーネル TLS と比べてスループットは 3 分の 1 以下で、暗号化を無効化した場合でも TCP と比べて最大 4 倍低いスループットとなった
• 原因として セグメンテーションオフロード未対応、送信経路での追加データコピー、ヘッダー暗号化処理などが指摘されている
• 今後 ハードウェアオフロード 対応が追加され、インカーネル実装が最適化されれば性能向上が期待される

採用状況と今後の展望

• Samba サーバー/クライアント、カーネル SMB および NFS ファイルシステム、curl など、さまざまな プロジェクトでインカーネル QUIC 対応の議論 が活発に進んでいる
• パッチは約 9,000 行規模で、現時点では低水準のサポートコードのみが含まれている。完全な実装は追加パッチで予告されている状態
• コードレビューとマージの議論は始まったばかりの段階であり、実運用までにはさらに時間を要する見込み
  • 最近 Homa プロトコルのカーネルマージに 9 か月で 11 回の提出が必要だった前例を見ると、QUIC についてもメインライン入りは 2026 年以降になると予想される