Conexão e Autenticação
Uma conexão par-a-par (porta Raft = porta do cliente + 1000) é estabelecida na exata mesma ordem que a porta do cliente. Não há etapa dentro do protocolo para distinguir cliente de par — os papéis são diferenciados puramente pela porta.
- Conexão TCP — o lado que disca é sempre o requisitante
- Handshake TLS, se o servidor tiver TLS ligado
- Um handshake de autenticação — a especificação (challenge, digest, resposta) é idêntica byte a byte à da porta do cliente
- Troca de RPC com prefixo de comprimento a partir daí
Fluxo
Nó que disca
Nó receptor
conexão TCP (porta Raft = porta do cliente + 1000)
handshake TLS, se o servidor tiver TLS ligado
challenge (SHA-256 ␣ nonce)
digest — calculado com o primeiro token em cluster_tokens
verificado contra toda a lista cluster_tokens
RPCs Raft com prefixo de comprimento a partir daqui
requisiçãorespostaRPC de consenso (Raft)
Como Difere da Porta do Cliente
| Item | Porta do cliente | Porta Raft |
|---|---|---|
| Conjunto de tokens usado para verificar | client_tokens | cluster_tokens |
| Token enviado | o token que o cliente configurou | o primeiro token em cluster_tokens |
| Após a autenticação | quadros terminados em \n | RPC com prefixo de comprimento |
- Do lado receptor, a verificação checa contra a lista inteira de
cluster_tokens, então você pode listar tokens antigos e novos juntos e reiniciar os nós um de cada vez para rotacionar os tokens com zero downtime (Configuração (Variáveis de Ambiente)). - Com o TLS ligado, a porta Raft usa o mesmo certificado. O lado que disca verifica o certificado do par contra
tls_ca(ou o repositório de confiança do sistema, se não definido);tls_skip_verifyé apenas para testes. - Em caso de falha de autenticação, a conexão fecha após
E auth_failed— igual à porta do cliente.