一、KL-Transport 的分层结构

KL-Transport 是快连客户端与接入节点之间的私有传输协议，整体分为 4 层：应用数据层负责把用户的 TCP 与 UDP 流量封装成统一的数据帧；会话层维护一条连接内的序号与重传窗口；传输层在 UDP 与 TCP 之间选择并执行回退；加密层负责握手与数据加密。

各层职责分离带来一个直接好处：传输方式的选择不影响加密强度。即使回退到 TCP 443 端口，数据依然由同 2 个加密套件保护，攻击者只能看到密文与连接时序，无法还原原始内容。

二、握手流程与时序

握手使用 TLS 1.3，客户端在发起连接后发出 ClientHello，服务端返回 ServerHello 与证书，随后双方完成密钥交换，协商出本次会话的密钥材料。TLS 1.3 的特点是把加密握手前置，1 个往返即可完成密钥协商，后续数据不再有明文阶段。

1. 发起：客户端向节点地址发送 ClientHello，携带支持的加密套件列表与协议版本号。
2. 协商：服务端按 RFC 8446 的规则选择 1 个套件，优先选择客户端支持且服务端启用的组合。
3. 验证：客户端比对服务端证书指纹，匹配则继续，不匹配立即断开，不做静默降级。
4. 建链：双方确认握手完成，进入数据通道，实测首连中位耗时为 1.8 秒。

握手失败的常见原因是指纹不匹配、客户端时间偏差过大或本地有中间设备改写报文。排查这类问题可以对照证书与指纹一节的核对方法，逐项排除后再看线路侧。

三、加密套件与启用条件

快连启用 2 个加密套件：支持 AES-256-GCM 的平台优先使用 AES-256-GCM，其余平台使用 ChaCha20-Poly1305。两者都属于认证加密算法，除了加密内容还附带完整性校验标签，密文被篡改时接收端会直接丢弃该帧。

• AES-256-GCM：在有硬件指令集的设备上吞吐更高，实测环境为家用千兆宽带的桌面端。
• ChaCha20-Poly1305：在无 AES 指令集的设备上由软件实现，运算开销低于同等强度的 AES 实现。
• 套件的实际生效结果可以在客户端详情页的协议标签页查看，与本页说明保持一致。
• 会话密钥在连接建立时协商生成，不落在磁盘配置中，也不随账号明文传输。

两者的选择与硬件能力相关，与线路类型无关：同一条线路上，换一台设备时生效的套件可能不同，这是预期行为。握手报文中不会出现明文形式的用户数据，这一行为可由抓包结果验证。

四、证书与指纹核对

每条线路公布 1 组证书指纹，用户可以在客户端的线路详情中查看。指纹以 64 位十六进制形式给出，与下载总览页的 SHA256 校验值形式相同但用途不同：前者用于确认对端身份，后者用于确认安装包完整性，两者不可互换。

指纹不一致时客户端会拒绝连接并给出明确提示，而不是继续用未验证的链路传输数据。这一设计意味着即使线路被中间人替换，也无法通过验证。遇到指纹不一致应立即停止使用该线路，并通过联系与工单页上报。

五、UDP 优先与 TCP 443 回退

传输层默认优先使用 UDP，因为它的开销低于 TCP，在丢包环境下恢复更快。当 UDP 通道在 3 秒内没有收到有效回包时，客户端会主动改用 TCP 443 端口重连，保证在限制较严的网络中仍可使用。

• 判定窗口为 3 秒，超时后触发 1 次回退，回退过程不中断已有会话。
• 回退到 TCP 443 后握手与加密流程完全相同，安全性不受影响。
• 在校园网、企业网等限制 UDP 的环境中，手动锁定 TCP 模式可直接跳过判定环节。
• 回退发生时客户端会在状态栏给出提示，日志中可查到具体的切换时间点。

标准线路与专用线路在跨国场景下的实测延迟中位数分别为 96 毫秒与 62 毫秒，采样区间为 2026-10-20 至 24 日，家用千兆宽带环境，同一线路测量 5 次取中位数。不同线路的延迟对照见节点与线路页。

一、KL-Transport 的分层结构

KL-Transport 是快连客户端与接入节点之间的私有传输协议，整体分为 4 层：应用数据层负责把用户的 TCP 与 UDP 流量封装成统一的数据帧；会话层维护一条连接内的序号与重传窗口；传输层在 UDP 与 TCP 之间选择并执行回退；加密层负责握手与数据加密。

各层职责分离带来一个直接好处：传输方式的选择不影响加密强度。即使回退到 TCP 443 端口，数据依然由同 2 个加密套件保护，攻击者只能看到密文与连接时序，无法还原原始内容。

二、握手流程与时序

握手使用 TLS 1.3，客户端在发起连接后发出 ClientHello，服务端返回 ServerHello 与证书，随后双方完成密钥交换，协商出本次会话的密钥材料。TLS 1.3 的特点是把加密握手前置，1 个往返即可完成密钥协商，后续数据不再有明文阶段。

1. 发起：客户端向节点地址发送 ClientHello，携带支持的加密套件列表与协议版本号。
2. 协商：服务端按 RFC 8446 的规则选择 1 个套件，优先选择客户端支持且服务端启用的组合。
3. 验证：客户端比对服务端证书指纹，匹配则继续，不匹配立即断开，不做静默降级。
4. 建链：双方确认握手完成，进入数据通道，实测首连中位耗时为 1.8 秒。

握手失败的常见原因是指纹不匹配、客户端时间偏差过大或本地有中间设备改写报文。排查这类问题可以对照证书与指纹一节的核对方法，逐项排除后再看线路侧。

三、加密套件与启用条件

快连启用 2 个加密套件：支持 AES-256-GCM 的平台优先使用 AES-256-GCM，其余平台使用 ChaCha20-Poly1305。两者都属于认证加密算法，除了加密内容还附带完整性校验标签，密文被篡改时接收端会直接丢弃该帧。

• AES-256-GCM：在有硬件指令集的设备上吞吐更高，实测环境为家用千兆宽带的桌面端。
• ChaCha20-Poly1305：在无 AES 指令集的设备上由软件实现，运算开销低于同等强度的 AES 实现。
• 套件的实际生效结果可以在客户端详情页的协议标签页查看，与本页说明保持一致。
• 会话密钥在连接建立时协商生成，不落在磁盘配置中，也不随账号明文传输。

两者的选择与硬件能力相关，与线路类型无关：同一条线路上，换一台设备时生效的套件可能不同，这是预期行为。握手报文中不会出现明文形式的用户数据，这一行为可由抓包结果验证。

四、证书与指纹核对

每条线路公布 1 组证书指纹，用户可以在客户端的线路详情中查看。指纹以 64 位十六进制形式给出，与下载总览页的 SHA256 校验值形式相同但用途不同：前者用于确认对端身份，后者用于确认安装包完整性，两者不可互换。

指纹不一致时客户端会拒绝连接并给出明确提示，而不是继续用未验证的链路传输数据。这一设计意味着即使线路被中间人替换，也无法通过验证。遇到指纹不一致应立即停止使用该线路，并通过联系与工单页上报。

五、UDP 优先与 TCP 443 回退

传输层默认优先使用 UDP，因为它的开销低于 TCP，在丢包环境下恢复更快。当 UDP 通道在 3 秒内没有收到有效回包时，客户端会主动改用 TCP 443 端口重连，保证在限制较严的网络中仍可使用。

• 判定窗口为 3 秒，超时后触发 1 次回退，回退过程不中断已有会话。
• 回退到 TCP 443 后握手与加密流程完全相同，安全性不受影响。
• 在校园网、企业网等限制 UDP 的环境中，手动锁定 TCP 模式可直接跳过判定环节。
• 回退发生时客户端会在状态栏给出提示，日志中可查到具体的切换时间点。

标准线路与专用线路在跨国场景下的实测延迟中位数分别为 96 毫秒与 62 毫秒，采样区间为 2026-10-20 至 24 日，家用千兆宽带环境，同一线路测量 5 次取中位数。不同线路的延迟对照见节点与线路页。