Resumo

  • A RFC 3074 permitia que servidores DHCP cooperantes chegassem localmente à mesma decisão com base no identificador do cliente e em uma atribuição prévia de 256 buckets.
  • O hash distribuía a permissão para responder, não o trabalho observado: buckets sem servidor podiam deixar a requisição sem resposta, e esperar não provava que o cliente recebeu um lease.

Dividir respostas não é medir carga

Uma transmissão broadcast de DHCP pode chegar a vários servidores. Em 2001, a RFC 3074 propôs reduzir respostas duplicadas sem exigir mudanças nos clientes: cada servidor calcularia o mesmo hash para a transação e só responderia se o resultado pertencesse ao seu Hash Bucket Assignment (HBA).

O servidor usava primeiro a opção Client Identifier. Na ausência dela, recorria aos campos de comprimento e endereço de hardware do cliente, limitando a entrada aos primeiros dezesseis bytes. O hash de Pearson produzia um entre 256 valores. Um bitmap de 32 octetos indicava quais valores cada servidor atenderia; um relay BOOTP também podia associar buckets a identificadores de servidor e encaminhar os pedidos de forma seletiva.

Assim, a negociação recorrente entre servidores foi substituída por uma decisão de configuração inicial. A ideia nasceu como otimização do protocolo DHCP Failover, então ainda em desenvolvimento, e depois foi ampliada para servidores cooperantes e relays BOOTP. A economia pretendida era delimitada: evitar a troca de mensagens entre servidores em cada pedido, sem alterar o comportamento dos clientes.

Mas o percentual configurado não era uma leitura da CPU, da pressão sobre o pool, do tempo de resposta nem das concessões concluídas. A RFC explica que a parcela real pode variar em intervalos curtos e se aproximar do alvo à medida que o volume de requisições cresce. Isso descreve a distribuição das transações de clientes ao longo do tempo; não afirma que todas custem o mesmo nem que os servidores terminem com esforço igual.

Um bucket sem responsável podia significar silêncio

O limite mais importante está no bitmap, não na fórmula. A RFC 3074 diz que uma transação cujo resultado cai em um valor não atribuído pode ser inteiramente ignorada, e observa que isso pode ser desejável em certas situações. O silêncio, portanto, podia vir de uma escolha de configuração e não apenas da perda de pacotes.

O parâmetro opcional Delayed Service permitia que um servidor não selecionado respondesse depois de uma espera. É uma saída baseada em temporizador, não um consenso em tempo real nem a prova de que o servidor designado falhou. A RFC também deixa que as implementações tratem casos em que o servidor escolhido não está disponível ou não tem endereços adequados, sem prometer um resultado uniforme.

O relay deixa as etapas mais claras: ele pode enviar cada bucket a um servidor ou a um par primário-reserva que opera com outro mecanismo de failover. Seleção, encaminhamento, estado dos leases e uso final do endereço são fatos diferentes. A RFC 3074 especifica a seleção; não transforma o HBA em estado compartilhado de leases ou em comprovante ponta a ponta.

O Datatracker ainda lista a RFC 3074 como Proposed Standard do IETF. Isso registra a posição do documento, não adoção contemporânea. A RFC 8156, de 2017, define failover de DHCPv6 e transferência de leases após falha ou partição de rede. É um contraste limitado, não prova de que a RFC 3074 foi atualizada ou implantada.

A nota posterior de Heng Lu sobre “camadas da realidade” entra aqui como lente editorial, não como evidência de DHCP: separar regra escrita, configuração do operador, execução observada e resultado recebido pelo cliente. A contribuição histórica da RFC 3074 foi tornar calculável a elegibilidade para responder. Ela não tornou o desfecho do serviço autoevidente.

Fontes