Ticketing
ドキュメント

接続と認証

ピア間の接続(Raftポート = クライアントポート + 1000)は、クライアントポートとまったく 同じ順序で確立されます。プロトコル内にクライアントとピアを区別する手順はなく、 役割は純粋にポートだけで区別されます。

  1. TCP接続 — 発信側は常にリクエスト側
  2. サーバーがTLSを有効にしていればTLSハンドシェイク
  3. 認証ハンドシェイクを1回 — 仕様(チャレンジ、ダイジェスト、 応答)はクライアントポートとバイト単位で同一
  4. 以降は長さプレフィックス付きRPCのやり取り

フロー

発信ノード
受信ノード
TCP接続 (Raftポート = クライアントポート + 1000)
サーバーがTLSを有効にしていればTLSハンドシェイク
チャレンジ (SHA-256 ␣ nonce)
ダイジェスト — cluster_tokensの最初のトークンで計算
cluster_tokensリスト全体と照合
ここから先は長さプレフィックス付きRaft RPC
リクエストレスポンス合意形成RPC(Raft)

クライアントポートとの違い

項目クライアントポートRaftポート
検証に使うトークンセットclient_tokenscluster_tokens
送信されるトークンクライアントが設定したトークンcluster_tokens先頭のトークン
認証後\n終端のフレーム長さプレフィックス付きRPC
  • 受信側の検証はcluster_tokensリストの全体と照合するため、新旧のトークンを一緒に 並べておき、ノードを1台ずつ順にローリングすることで、無停止のままトークンを ローテーションできます(設定 (環境変数))。
  • TLSが有効な場合、Raftポートも同じ証明書を使います。発信側はピアの証明書をtls_ca (未設定ならシステム信頼ストア)と照合します。tls_skip_verifyテスト専用です。
  • 認証に失敗すると、E auth_failedの後に接続が 閉じられます — クライアントポートと同様です。