Resumo

  • A RFC 3320 executa uma máquina virtual de descompressão independente e limitada para cada mensagem, mesmo quando o remetente fornece o programa a ser executado.
  • Uma descompressão bem-sucedida não autoriza estado duradouro: a aplicação precisa autenticar o resultado e fornecer um identificador válido de compartimento antes que novo estado seja salvo ou haja retorno ao compressor.

A compressão também transportava um programa

Publicada em janeiro de 2003, a RFC 3320 definiu Signaling Compression, ou SigComp, para protocolos de aplicação como SIP e RTSP. A proposta não dependia de instalar previamente o mesmo compressor em todos os participantes. O remetente podia selecionar um algoritmo e, quando necessário, incluir bytecode para a Universal Decompressor Virtual Machine (UDVM) do receptor executar. O destinatário precisava aceitar essa flexibilidade sem transformar uma computação controlada à distância em acesso irrestrito ao equipamento.

Isso muda a pergunta histórica. Não basta perguntar quantos bytes a compressão economiza; também é preciso perguntar que cálculo uma mensagem recebida pode provocar e que lembrança ela pode deixar no receptor. As RFCs não demonstram a adoção do SigComp nem medem economia de banda em redes operacionais. Elas definem uma fronteira: quem envia pode propor uma computação sob limites, enquanto quem recebe continua controlando os recursos e a memória que pode sobreviver à mensagem atual.

Cada mensagem recebe uma execução nova

Cada mensagem SigComp recebida inicia uma instância própria da UDVM. A memória para descompressão é limitada por mensagem e todo endpoint precisa oferecer pelo menos 2.048 bytes para essa finalidade. O número de instruções também depende do tamanho da mensagem e de cycles_per_bit: para n bytes, o máximo é (8*n + 1000) * cycles_per_bit, e o parâmetro não pode ser menor que 16. Esses limites valem para uma execução individual. Não são uma fórmula de consumo total do servidor nem uma garantia contra toda forma de negação de serviço.

A instância independente cria um limite de recuperação. Uma mensagem malformada ou que esgote o orçamento não prende automaticamente a próxima mensagem válida na mesma máquina virtual. O receptor não precisa operar como um único decodificador de fluxo cujo estado cresce indefinidamente. A especificação cria um reinício explícito, embora permita que estados selecionados sejam compartilhados entre mensagens. Reiniciar a execução e reter estado são mecanismos distintos, com controles próprios.

Descomprimir e guardar exigem permissões diferentes

O SigComp separa a memória temporária da descompressão da memória de estado alocada a um compartimento. A aplicação define esses compartimentos conforme o contexto de comunicação e pode fechá-los quando a relação termina. Um endpoint que não queira manter estado pode anunciar capacidade zero. Portanto, persistência não é requisito para decodificar a mensagem presente.

A regra decisiva aparece depois da descompressão. A aplicação recebe a mensagem reconstruída e pode autenticá-la conforme o protocolo e o contexto. Somente quando aceita associá-la a um identificador válido de compartimento a camada SigComp recebe autorização para criar estado naquele compartimento e enviar feedback ao compressor. Se não houver confiança suficiente, a aplicação não fornece um compartimento válido. A UDVM termina sem gravar o estado pedido e sem encaminhar o feedback.

Essa decisão semântica fica fora do decodificador. A máquina virtual pode mostrar que produziu bytes dentro dos limites; não pode decidir se a sinalização é autêntica, pertence ao diálogo esperado ou deve influenciar mensagens futuras. A aplicação tem o contexto e conserva a palavra final. A RFC 4896 esclareceu posteriormente a relação entre autenticação e criação de estado, reforçando que a saída do decodificador não é, por si só, um juízo de confiança.

Consultar estado existente é outro controle

Há uma dependência temporal: a aplicação talvez precise da mensagem descomprimida para autenticá-la, mas a própria descompressão pode se beneficiar de estado anterior. O SigComp trata o acesso a estado existente de modo distinto da autorização posterior da aplicação. Os identificadores de estado derivam de um hash dos bytes do estado; o receptor valida o identificador antes de expor esse conteúdo à UDVM. Depois, ainda cabe à aplicação autorizar ou não a criação de estado novo.

São perguntas diferentes: “esta mensagem pode ler um estado de compressão já estabelecido?” e “o conteúdo decodificado e autenticado pode criar ou alterar memória duradoura?”. Elas acontecem em momentos diferentes e dependem de evidências diferentes. Confundi-las pode parecer contraditório, quando na verdade a primeira etapa permite a descompressão sob controle e a segunda espera a avaliação semântica da aplicação.

Os documentos seguintes cobriram questões próximas

A RFC 3321 acrescentou operações estendidas e mecanismos de confirmação; em transporte não confiável, o emissor precisa considerar a confirmação antes de depender do estado remoto. A RFC 4077 descreveu uma resposta negativa para informar falhas de descompressão. A RFC 5049 definiu requisitos de SigComp para SIP, que não devem ser aplicados automaticamente a toda aplicação. A RFC 4464 é um guia, enquanto a RFC 4465 reúne testes extremos. Explicação, sinalização de falhas e perfis específicos ampliaram o projeto, mas esses documentos não provam adoção nem ganhos medidos.

A contribuição duradoura da RFC 3320 é a divisão de autoridade. A mensagem pode pedir uma computação limitada. A aplicação decide se seu significado merece tornar-se memória capaz de influenciar as mensagens seguintes. Ao manter as etapas separadas, o desenho torna visíveis o limite de recursos e o limite de confiança — e impede que “descomprimiu” vire silenciosamente “foi autorizado e guardado”.

Fontes