O SAU passou a permitir que conexões HTTP/3 aceitas antes de uma recarga concluam o primeiro pedido. Testes da configuração candidata também verificaram a validade de tokens QUIC após recargas.
A configuração de borda do SAU passou a permitir que conexões HTTP/3 aceitas antes de uma recarga concluam o primeiro pedido. O ajuste importa para gestores públicos de saúde, equipes de operação de centrais do SAMU 192 e profissionais de TI porque permite que esse pedido prossiga enquanto a configuração do serviço é recarregada.
HTTP/3 é uma forma de comunicação entre aplicações e servidores. Ele usa QUIC, um protocolo de transporte que também participa da validação das conexões. Na prática, a mudança trata de um momento específico: uma conexão já aceita, mas cujo primeiro pedido ainda não foi enviado, pode completar esse pedido durante a recarga. Depois disso, o fluxo de encerramento gradual das conexões existentes continua sendo aplicado.
A configuração também passou a usar uma chave QUIC persistente. Ela mantém válidos tokens de validação emitidos antes da recarga, em vez de depender de uma chave que muda a cada recarga. Com isso, uma conexão que recebeu um token antes da troca de configuração pode apresentá-lo depois, sem que a validação dependa de gerar outro token. Os testes incluíram a verificação de um token emitido antes da recarga e apresentado ao novo processo após a saída do processo anterior.
Na configuração candidata, os ensaios registraram 754 chamadas ao longo de três recargas. Dois pedidos com duração aproximada de 25 segundos, um em HTTP/2 e outro em HTTP/3, foram concluídos. A documentação técnica também descreve testes específicos de recarga, primeiro pedido e preservação de tokens QUIC. Esses resultados dizem respeito à candidata testada; não constituem uma medida de desempenho geral.
O alcance da mudança é delimitado: ela se refere à recarga da configuração do serviço de borda. A documentação distingue esse procedimento da recriação do serviço, que pode interromper conexões. Portanto, o resultado comprovado é a continuidade de pedidos HTTP/3 já aceitos durante a recarga, não uma garantia de conexão ininterrupta em qualquer tipo de atualização.
