Resumo

  • No exemplo delimitado de RFC 5390, uma solicitação SIP podia gerar até dezoito solicitações e dezoito respostas quando três servidores sobrecarregados, novas tentativas do proxy e retransmissões UDP se combinavam.
  • A indicação 503 não dizia com precisão qual recurso estava saturado, que carga residual ainda cabia nem a qual endereço, host ou URI se aplicava; por isso ela tanto podia replicar trabalho quanto retirar capacidade saudável.
  • Trabalhos posteriores separaram monitor, decisão de controle, feedback e atuador a montante. Recusar uma solicitação, instalar um limite e concluir uma chamada são fatos distintos.

A segunda porta não oferecia uma segunda capacidade

O comportamento original fazia sentido diante de uma falha localizada. RFC 3261 permitia que um servidor respondesse 503 por indisponibilidade temporária e, opcionalmente, usasse Retry-After para indicar uma pausa. O proxy podia procurar outro destino. Se somente uma máquina estivesse indisponível e a seguinte tivesse recursos independentes, a lista de alternativas preservaria serviço útil.

RFC 5390 escolheu uma condição diferente. S1, S2 e S3 já estavam sobrecarregados. O balanceador enviava a solicitação ao primeiro, recebia 503, seguia para o segundo e depois para o terceiro. Cada passagem exigia recepção, análise, agendamento e criação de uma resposta por um processador que já não conseguia executar o trabalho normal.

A lista tinha três nomes, mas não três saídas. Nenhuma tentativa introduzia capacidade nova. A lógica de failover tratava variedade de endereços como se fosse independência de recursos. Na prática, o mesmo trabalho percorria três pontos que compartilhavam a condição relevante: incapacidade de processá-lo naquele momento.

Um painel podia chamar esse percurso de sucesso operacional. Todas as alternativas foram tentadas; todos os servidores deram respostas válidas; o proxy cumpriu a regra. Ainda assim, a chamada não avançou e a carga oferecida não caiu. A conformidade de cada passo não provava recuperação do sistema.

Enquanto a recusa era preparada, o cliente fazia cópias

Um servidor sobrecarregado também pode demorar a dizer não. Durante esse intervalo, uma transação SIP sobre UDP retransmite. No cálculo de RFC 5390, havia quatro transações, contando o trecho entre cliente e proxy, e até sete retransmissões em cada transação UDP antes do timeout. Sob essas hipóteses, uma única solicitação original podia resultar em até dezoito solicitações e outras dezoito respostas.

Dezoito não é telemetria de uma operadora, média de mercado nem multiplicador universal. É o limite explicativo de uma topologia com três servidores, UDP, temporizadores e novas tentativas definidos no documento. Remover as condições e manter o número transformaria um exemplo rigoroso em manchete imprecisa.

O valor do exemplo está no método contábil. O custo de uma recusa inclui tudo o que surgiu enquanto ela era produzida e tudo o que a recuperação mandou fazer em seguida. Se a observabilidade conta apenas solicitações iniciais, retransmissões fabricadas pelo próprio sistema aparecem como demanda externa inédita.

Usar transporte confiável eliminava parte do multiplicador, não o erro de decisão. Sem retransmissões de segmentos TCP, o mesmo cenário ainda produzia três solicitações a jusante e quatro respostas. A rede continuava sem um fato essencial: os três destinos alternativos estavam presos à mesma escassez.

Um 503 comprovava uma decisão, não uma redução

A resposta 503 comprova que uma rota de processamento decidiu não concluir uma solicitação. Não comprova que a fila encolheu, que CPU voltou ao normal, que a origem reduziu a taxa, que outro destino está saudável ou que o usuário recebeu uma chamada. Esses são recibos posteriores.

Misturá-los torna possível declarar vitória pela métrica errada. Um servidor pode aumentar a vazão de respostas negativas e parecer mais responsivo, ao mesmo tempo que gasta todo o recurso restante rejeitando. O volume de códigos deixa de revelar se houve trabalho útil.

Por isso o primeiro requisito de RFC 5390 mirava useful throughput sob oferta muito acima da capacidade. Uma resposta não vale o mesmo que uma transação concluída. Uma transação concluída não vale automaticamente uma chamada bem-sucedida. Um BYE que encerra um diálogo pode liberar mais estado do que um INVITE novo consome ou preserva; misturar classes perde a consequência operacional.

Na disciplina de camadas de realidade, o código visível, o estado material do servidor, a decisão do proxy e o resultado do usuário não são uma única coisa. Uma relação causal entre eles precisa ser demonstrada. O nome comum “proteção de sobrecarga” não cria essa demonstração.

O proxy superior percorreu o mesmo conjunto por outra entrada

RFC 5390 acrescentou um proxy acima de dois intermediários. P1 podia descobrir, depois de testar S1, S2 e S3, que o conjunto inteiro estava saturado. Porém esse conhecimento não voltava como estado de controle com escopo utilizável. O proxy superior experimentava P2, que visitava os mesmos três servidores novamente.

O grafo lógico ganhava um ramo; o grafo de dependências não ganhava recurso. Uma falha vinda de P1 podia significar uma condição de P1 ou uma condição dos servidores compartilhados atrás de P1 e P2. O receptor não tinha evidência suficiente para diferenciar. Evitar o encaminhamento de 503 para não atribuir ao proxy uma sobrecarga que não era dele também retirava a informação necessária para impedir a exploração repetida.

Redundância, portanto, não é contagem de endpoints. Dois front-ends apoiados pelo mesmo banco de dados indisponível constituem um domínio de falha para a operação que depende dele. Dois caminhos que terminam no mesmo tronco PSTN tampouco fornecem duas capacidades independentes.

Cada nova tentativa deveria carregar uma justificativa testável: qual recurso independente ela acrescenta? Sem essa resposta, “tentamos todos os servidores” descreve atividade, não diligência. A busca pode crescer enquanto a probabilidade de sucesso permanece zero.

Um escopo amplo demais também fechava portas saudáveis

A falta de contexto podia produzir o efeito inverso. RFC 5390 observou que RFC 3261 não tornava inequívoco se 503 se aplicava a um endereço IP, um nome de host ou uma URI. Algumas implementações usavam o nome do host. Quando DNS SRV fazia esse nome representar vários membros, o 503 de uma máquina podia retirar todo o grupo.

Nesse caso, a rede não ampliava carga sobre destinos ruins; ela abandonava capacidade boa. Uma observação local virava proibição coletiva. As duas falhas tinham a mesma origem: o receptor não sabia qual objeto a indicação descrevia.

REQ 18 exigiu escopo sem ambiguidade entre IP, host e URI. Escopo define autoridade. Um servidor pode relatar seu processador e sua fila. A simples emissão do mesmo código não lhe dá autoridade para declarar saturados os irmãos, o banco compartilhado, o nome DNS ou o serviço inteiro.

Uma trilha de controle precisa guardar o objeto observado, o instante, a duração, o vizinho que recebeu a indicação e o conjunto que o atuador realmente desativou ou reduziu. Um total de 503 não permite distinguir proteção correta de capacidade saudável ociosa.

O temporizador binário transformou dois servidores em pêndulo

Retry-After oferecia tempo para drenar uma fila, mas a atuação básica era tudo ou nada. No exemplo de dois servidores de RFC 5390, ambos operavam a plena capacidade. Quando S1 pedia pausa, o proxy levava todo o tráfego a S2. S2 recebia então aproximadamente o dobro do que podia tratar, respondia com sua própria recusa e devolvia a fila quando o temporizador de S1 expirava.

Cada observação local podia estar correta. A instabilidade surgia no mecanismo que traduzia a observação em deslocamento integral. A indicação não dizia qual parcela ainda poderia ser atendida nem qual taxa manteria o sistema em equilíbrio.

O documento limitou cuidadosamente essa conclusão. Com muitos clientes independentes, cada um oferecendo uma fração pequena, responder 503 apenas a alguns pode aproximar uma redução mais graduada. Portanto, o artigo não afirma que Retry-After sempre oscila. Ele demonstra que a regra básica não garantia convergência nas topologias que RFC 5390 precisava proteger.

REQ 7 passou a exigir graus de sobrecarga. REQ 21 pediu estabilidade quando a oferta voltasse abaixo da capacidade. O objeto de engenharia deixou de ser o texto de uma mensagem e passou a ser o comportamento de um circuito ao longo do tempo.

O mesmo código escondia causas que pediam ações opostas

Implementações também usavam 503 para falhas que não eram exaustão do processador SIP. Um gateway podia ter recursos de sinalização e não dispor de uma rota PSTN para aquela chamada. Um conjunto de front-ends podia estar saudável, mas depender de um banco indisponível. No primeiro caso, outra rota talvez funcionasse. No segundo, trocar de front-end repetiria a mesma falha.

O proxy via o mesmo símbolo em mundos causais diferentes. Tentar de novo podia salvar a chamada ou ampliar desperdício. Parar podia proteger o sistema ou abandonar uma alternativa saudável. REQ 6 pediu uma indicação explícita de que a causa era sobrecarga. REQ 8 e REQ 9 preservaram as duas margens: não insistir contra destino sobrecarregado ou desconhecido, sem impedir trabalho de um destino realmente apto.

REQ 14 acrescentou orientação clara de nova tentativa, sobretudo para estabelecimento de conexão e registro depois de reinício. Causa, escopo, quantidade e validade temporal não são sinônimos. Quando o protocolo os comprime num código geral, o receptor precisa inventar a política ausente.

Uma especificação inicial mínima funciona melhor quando não reivindica mais autoridade do que possui. O elemento a jusante descreve uma condição local. O elemento a montante continua responsável pelo tráfego que envia. O intercâmbio comum coordena, mas não dissolve essas responsabilidades.

O controle posterior separou quatro trabalhos

RFC 6357 descreveu o processador SIP protegido, um monitor, uma função de controle, o feedback e um atuador a montante. O monitor mede. A função decide o que comunicar. O feedback atravessa a relação. O atuador reduz, atrasa, rejeita ou redireciona antes que trabalho excedente alcance o recurso raro.

Separar funções torna o defeito localizável. O monitor pode medir corretamente e o feedback chegar vencido. A mensagem pode chegar e o atuador não instalar nada. O atuador pode cumprir um volume total e escolher as classes erradas para descarte. A taxa pode cair sem restaurar resultado porque a dependência oculta continua indisponível.

RFC 6357 também explicou que rejeição local consome recurso e não impede sozinha congestion collapse. Ela serve como última linha, não como substituta da ação antecipada. O excesso deve ser contido antes de entrar no processador que já está tentando sobreviver.

RFC 7339 colocou depois a informação de sobrecarga na entrada Via superior, entre vizinhos. Como o cliente adjacente consome esse Via, o feedback tem alcance por salto. oc expressava redução no algoritmo padrão baseado em perda; oc-validity limitava sua vida; oc-seq ordenava atualizações; oc-algo identificava a família. A presença dos parâmetros não prova que o atuador obedeceu nem que todos os saltos da chamada estavam cobertos.

Percentual e teto de taxa eram promessas diferentes

RFC 7339 exigiu suporte a controle baseado em perda. O servidor podia pedir que um cliente reduzisse a proporção encaminhada. Era um contrato leve, mas o número aceito ainda acompanhava a carga oferecida: se a oferta crescesse, sua fração permitida também poderia crescer.

RFC 7415 adicionou um método opcional baseado em taxa. O servidor fornecia uma quantidade máxima de solicitações por unidade de tempo para um cliente, mantida até nova atualização. Isso criava um teto entre mensagens, com o custo de maior estado e decisão por emissor.

Nenhum valor era promessa de conclusão. Um limite de 150 solicitações por segundo não assegurava 150 transações terminadas nem 150 chamadas. Misturas de mensagens podiam ter custos diferentes, e o cliente continuava escolhendo localmente quais solicitações ocupavam a cota.

O recibo precisa, portanto, separar feedback recebido, sequência e validade, limite instalado, carga oferecida, carga encaminhada, classe selecionada, transação completa e resultado do diálogo. Cumprir um percentual ou uma taxa pode salvar CPU e ainda descartar mensagens de encerramento que liberariam estado valioso.

O limite da evidência

O conjunto congelado comprova o texto e o status Informational de RFC 5390, os problemas de implantação ali descritos e a arquitetura posterior de RFC 6357, RFC 7339 e RFC 7415. Ele não comprova adoção atual por operadora, fornecedor ou produto. Também não demonstra que uma interrupção real seguiu o modelo das dezoito solicitações.

O número dezoito permanece ligado a três servidores, transações UDP, retransmissões e timeout. O pêndulo de dois servidores descreve relações com poucos emissores grandes, não todos os padrões de distribuição. Um 503 visto em produção tampouco identifica sozinho a causa.

O invariante que pode ser transportado é mais estreito: recusar não é reduzir. Uma afirmação de controle precisa mostrar o recurso medido, o alcance causal, o feedback vigente, a atuação a montante, a política local e o trabalho útil resultante. Sem essa cadeia, há prova de um erro válido, não de recuperação.