连接与认证
点对点连接(Raft 端口 = 客户端端口 + 1000)的建立顺序与客户端端口完全相同。 协议内部没有专门的步骤来区分客户端和对端 —— 角色纯粹通过端口区分。
- TCP 连接 —— 发起拨号的一方始终是请求方
- 若服务器启用了 TLS,则进行 TLS 握手
- 一次认证握手——其规格(challenge、digest、 response)与客户端端口完全字节一致
- 此后进行带长度前缀的 RPC交换
流程
拨号节点
接收节点
TCP 连接 (Raft 端口 = 客户端端口 + 1000)
若服务器启用了 TLS,则进行 TLS 握手
challenge (SHA-256 ␣ nonce)
digest —— 使用 cluster_tokens 中的第一个 token 计算
对照整个 cluster_tokens 列表进行校验
此后是带长度前缀的 Raft RPC
请求响应共识 RPC(Raft)
与客户端端口的区别
| 项目 | 客户端端口 | Raft 端口 |
|---|---|---|
| 用于校验的 token 集合 | client_tokens | cluster_tokens |
| 发送的 token | 客户端配置的 token | cluster_tokens 中的第一个 token |
| 认证之后 | 以 \n 结尾的帧 | 带长度前缀的 RPC |
- 在接收方,校验会对照整个
cluster_tokens列表进行,因此你可以把新旧 token 同时列出,逐台滚动重启节点来实现零停机的 token 轮换 (见配置 (环境变量))。 - 启用 TLS 时,Raft 端口使用相同的证书。拨号方会对照
tls_ca(未设置时则为系统信任存储)校验对端证书;tls_skip_verify仅供测试使用。 - 认证失败时,连接会在
E auth_failed之后关闭 —— 与客户端端口相同。