Ticketing
文档

连接与认证

点对点连接(Raft 端口 = 客户端端口 + 1000)的建立顺序与客户端端口完全相同。 协议内部没有专门的步骤来区分客户端和对端 —— 角色纯粹通过端口区分

  1. TCP 连接 —— 发起拨号的一方始终是请求方
  2. 若服务器启用了 TLS,则进行 TLS 握手
  3. 一次认证握手——其规格(challenge、digest、 response)与客户端端口完全字节一致
  4. 此后进行带长度前缀的 RPC交换

流程

拨号节点
接收节点
TCP 连接 (Raft 端口 = 客户端端口 + 1000)
若服务器启用了 TLS,则进行 TLS 握手
challenge (SHA-256 ␣ nonce)
digest —— 使用 cluster_tokens 中的第一个 token 计算
对照整个 cluster_tokens 列表进行校验
此后是带长度前缀的 Raft RPC
请求响应共识 RPC(Raft)

与客户端端口的区别

项目客户端端口Raft 端口
用于校验的 token 集合client_tokenscluster_tokens
发送的 token客户端配置的 tokencluster_tokens 中的第一个 token
认证之后\n 结尾的帧带长度前缀的 RPC
  • 在接收方,校验会对照整个 cluster_tokens 列表进行,因此你可以把新旧 token 同时列出,逐台滚动重启节点来实现零停机的 token 轮换 (见配置 (环境变量))。
  • 启用 TLS 时,Raft 端口使用相同的证书。拨号方会对照 tls_ca (未设置时则为系统信任存储)校验对端证书;tls_skip_verify仅供测试使用
  • 认证失败时,连接会在 E auth_failed之后关闭 —— 与客户端端口相同。