kTLS：TLS 加密为什么有一部分可以交给 Linux 内核？

HTTPS 数据传输要经过 TLS 加密。许多系统里，TLS 握手、证书验证、密钥协商和记录层数据处理都由用户态库完成。Linux Kernel TLS（kTLS）提供另一种分工：在连接已经建立后，可以把 TLS 记录层的加解密交给内核，让数据传输更直接地接入内核 I/O 路径。

握手和数据传输是两件事

TLS 握手需要验证对端身份、协商算法并生成会话密钥；这部分通常仍由用户空间的 TLS 库负责。握手完成后，应用可以把连接状态和密钥等必要信息交给内核，内核据此封装或解封装 TLS 记录。发送文件时，kTLS 也能与某些高效 I/O 路径配合，减少数据在用户态与内核态之间来回复制的机会。

可把它类比为机场：用户态 TLS 库负责核验旅客证件、决定航线和签发通行凭证；kTLS 则让机场内部的货运流水线接手已经批准的货物。职责交接之后，数据仍受 TLS 记录保护，但不必每一步都回到应用进程中处理。

kTLS 不会自动承担证书验证、主机名检查、握手安全和应用身份判断。若用户态正确完成握手后把错误密钥交给内核，传输仍可能失败或不安全。支持的密码套件、连接方向、内核版本、应用框架和网卡卸载能力也会影响可用功能。

还要区分 kTLS 与 TLS 硬件卸载。kTLS 表示记录层处理可以在内核中进行；若网卡进一步支持加密卸载，才可能由设备硬件承担部分计算。前者是软件架构分工，后者是硬件能力，二者可以组合但并非同义词。

它适合大型文件服务、代理和高吞吐网络程序等场景，但收益要通过实际负载测量。kTLS 的关键是“把数据面的一部分交给内核”，而不是把整个安全协议栈一键搬家。只要握手、密钥和记录层职责被清楚区分，才容易判断它是否值得启用。