RFC 2187: a hierarquia de caches era uma relação de autoridade, não um mapa de distância

Resumo

• Na RFC 2187, parent e sibling eram papéis operacionais definidos sobretudo pelo tratamento de um MISS: ambos podiam servir um HIT, mas somente um parent podia continuar a busca de um objeto ausente.
• O ICP fornecia indícios locais para seleção de fonte. HIT, MISS, RTT, peso, timeout, multicast ou uma resposta recebida não codificavam por si mesmos a relação de autoridade nem garantiam o resultado posterior da transferência.
• A hierarquia dependia de configuração e controles nos dois lados. O solicitante classificava vizinhos; o remoto aplicava controles de acesso, inclusive a negação de trânsito em MISS para uma relação sibling.
• RFC 2186, RFC 2187 e RFC 9211 ocupam camadas diferentes: formato e opcodes do ICPv2; aplicação do ICP em uma hierarquia; e observabilidade HTTP de como caches trataram uma resposta.

A palavra hierarquia convida a um erro de leitura. É fácil imaginar uma árvore física: um cache “acima”, outro “ao lado”, e a distância entre eles determinando a próxima requisição. A RFC 2187, publicada em 1997 como documento Informational, descreve algo mais operacional. O ponto decisivo é quem pode fazer o quê quando o objeto procurado não está onde se esperava.

Um sibling podia fornecer um objeto que já tivesse em cache. Um parent também. Diante de um MISS, porém, os papéis se separavam: o sibling não deveria ser usado como trânsito para buscar o objeto adiante; o parent podia assumir essa função. Se nenhum vizinho adequado resolvesse a requisição, a origem continuava disponível como caminho distinto, salvo restrições como firewall.

A figura da RFC 2187 é explícita: o cache local pode obter HITs de siblings, HITs e MISSes de parents e certas requisições diretamente da origem. Isso não é um mapa de proximidade física. É uma descrição de permissões e alternativas de encaminhamento.

A própria RFC admite que um mesmo vizinho seja tratado como sibling para uma classe de requisições e como parent para outra. Restrições por domínio, método, cacheabilidade e listas de exclusão podiam mudar o caminho efetivo. O rótulo não era uma essência da máquina remota; era parte de uma política aplicada à requisição.

O relacionamento não vinha embutido no pacote

A separação entre a RFC 2186 e a RFC 2187 é essencial. A primeira descreve o formato e os campos das mensagens ICPv2, além de opcodes como ICP_OP_QUERY, ICP_OP_HIT, ICP_OP_MISS, ICP_OP_MISS_NOFETCH e ICP_OP_HIT_OBJ. Ela própria limita seu escopo ao wire format e deixa a aplicação do protocolo em caches Web para o documento companheiro.

A RFC 2187 observa que uma mensagem ICP não dizia se os dois caches tinham relação parent ou sibling. HIT ou MISS precisava ser interpretado com a configuração local. O pacote fornecia evidência sobre aquela consulta; a autoridade para agir vinha da política.

O solicitante definia como enxergar o vizinho e para quais requisições ele era elegível. O remoto precisava aplicar controles compatíveis. No exemplo da RFC, permitir HTTP e ICP inclusive para MISSes produz comportamento de parent. Para impor sibling, o remoto precisava negar acesso a MISSes. A RFC recomenda ainda que isso seja comunicado ao outro administrador, evitando que um lado suponha parent enquanto o outro aceita apenas sibling.

Logo, ver um vizinho responder não prova reciprocidade. Ver um HIT não prova que a mesma permissão vale para outra classe de requisição. Ver um MISS não transforma sibling em parent.

HIT era evidência útil, mas estreita

Para ICP_OP_HIT, o cache consultado verificava se a URL existia localmente e se a entrada seria considerada fresca por pelo menos mais 30 segundos segundo suas regras. Mesmo assim, a RFC reconhecia uma corrida: o objeto poderia ser removido antes da requisição HTTP subsequente. Se o peer fosse sibling e negasse MISS, o solicitante poderia receber erro apesar do HIT anterior.

Esse detalhe mostra o limite do sinal. HIT era uma afirmação sobre o estado que o cache acreditava ter naquele momento. Não garantia que a transferência posterior ocorreria nem que todas as exigências HTTP seriam satisfeitas.

A seção de “lições aprendidas” explica a lacuna. ICP e HTTP não carregavam a mesma informação; ICPv2 não expressava método HTTP nem várias condições relevantes ao caching. A RFC cita Pragma: no-cache, If-Modified-Since e recursos de Cache-Control como exemplos de semântica HTTP ausente. Por isso, até ICP_OP_HIT_OBJ podia entregar um objeto que não obedecesse a todas as restrições da requisição.

Também não era uma declaração de identidade autenticada. A RFC 2187 registra que ICPv2 não tinha campos de autenticação e discute respostas falsificadas. Um terceiro podia tentar inserir uma resposta falsa antes da legítima, induzindo escolha ou rejeição de um vizinho. Em multicast, ingressar no grupo tampouco concedia confiança; respostas de endereços não configurados como vizinhos deveriam ser ignoradas.

Portanto, participação multicast não provava autorização; HIT não provava identidade; objeto retornado não provava conteúdo seguro. O próprio documento considera ICP_OP_HIT_OBJ especialmente sensível porque carrega dados do objeto.

Medição e autorização eram coisas diferentes

Quando não havia HIT, a seleção entre parents acrescentava outra camada. A RFC 2187 descreve o primeiro parent a responder MISS, pesos configurados e, em algumas versões do Squid, RTT até a origem. Se o cache local também medisse RTT e estivesse mais perto da origem que os parents, podia recuperar diretamente do servidor.

Esses mecanismos mostram que “mais perto” era contingente. Um peso podia fazer com que o “primeiro” parent considerado não fosse literalmente a primeira resposta. A própria RFC observa que o parent mais próximo não era necessariamente aquele que o operador queria usar. Seleção misturava medição e preferência.

A RFC 3143 mostra por que isso importava. Um sibling de baixa latência e baixa largura de banda podia responder antes de outro de maior latência, embora o segundo pudesse entregar objetos grandes mais rapidamente. Algoritmos baseados no primeiro peer a responder, portanto, não otimizavam necessariamente a recuperação para o usuário.

Assim, atraso medido não prova menor custo de entrega; resposta mais rápida não prova melhor throughput; peso representa preferência configurada, não uma propriedade objetiva da rede. E nenhum desses sinais cria a autorização de trânsito que define parent.

A RFC 3040 reforça outro limite. ICP consulta a presença de recursos em proxies, mas não carrega os cabeçalhos HTTP associados. O documento observa que falsos cache hits podem ocorrer, por exemplo quando o objeto está presente, mas não acessível a um sibling. “Existe” e “pode ser servido nesta relação” são afirmações distintas.

Timeout, firewall e multicast eram política de implantação

Como ICP era usado sobre UDP, respostas podiam se perder. As implementações descritas na RFC 2187 instalavam timeout; quando respostas esperadas não chegavam, ainda era preciso escolher uma fonte conforme a configuração. Ausência de resposta era evidência local de indisponibilidade ou congestionamento, não prova definitiva de falha permanente.

Firewalls mudavam as opções. Sem essa barreira, a falta de respostas de peers podia levar ao acesso direto à origem. Atrás dela, a origem talvez não fosse alcançável, obrigando a escolha de um parent. O mesmo silêncio ICP, portanto, produzia ações diferentes conforme a arquitetura do operador.

Multicast também não eliminava essa responsabilidade. Um cache podia enviar consultas ao grupo e receber múltiplas respostas, mas a RFC observa que o número esperado variava e que qualquer máquina capaz de ingressar no grupo não deveria ser automaticamente confiada. Escopo, TTL, vizinhos conhecidos e política de aceitação continuavam sob controle administrativo.

A hierarquia não era descoberta pela rede. Era operada sobre a rede.

Escolha, entrega e observabilidade pertencem a etapas diferentes

A RFC 9211 trata de outra etapa. Ela define o campo HTTP Cache-Status, destinado a indicar como caches trataram uma resposta e sua requisição, podendo registrar HIT, encaminhamento, TTL e outras informações ao longo de uma cadeia.

Isso não é a função da RFC 2187. ICP ajudava a decidir para onde tentar ir em seguida dentro de uma política de peers; Cache-Status relata tratamento de uma resposta. Seleção prospectiva e observabilidade posterior não são a mesma evidência.

Também seria indevido usar a RFC 2187 como explicação da economia moderna de CDN. As seis fontes aqui usadas não oferecem base para inferir preços, contratos, margens, incentivos comerciais atuais ou resultados de negócio de redes contemporâneas. O documento histórico descreve uma estrutura de decisão técnica.

Da mesma forma, ICP não é sinônimo de cache-control genérico. A própria RFC 2187 destaca lacunas entre a informação de ICP e a semântica HTTP. Regras de cacheabilidade, validação ou controle de resposta pertencem a outro nível. Usá-las para decidir quando consultar peers não as transforma em declaração de relação parent/sibling.

O valor da RFC 2187 está nessa separação. O protocolo dizia algo limitado sobre uma consulta; a política dizia quem era elegível para quê; HTTP determinava a transferência; e as condições de rede podiam mudar entre etapas. Quando “vizinho”, “HIT”, “mais próximo” ou “sucesso” são tratados como prova total, afirma-se mais do que as fontes permitem.