Resumo

  • ACK Delay descreve a espera intencional entre receber o maior pacote reconhecido e enviar o ACK.
  • latest_rtt é formado pela observação local bruta antes de qualquer ajuste por ACK Delay.
  • A leitura correta depende de ack_delay_exponent, da fase do handshake, de max_ack_delay e do piso min_rtt.

É fácil transformar uma correção de protocolo em uma falsa medição. Um pipeline mede o intervalo entre o envio e a chegada do ACK, decodifica ACK Delay, subtrai o valor e publica o restante como latência de rede. A conta pode ser útil para o algoritmo de transporte, mas a etiqueta é forte demais. ACK Delay é um relato do receptor sobre uma espera intencional sob seu controle. Não mede diretamente propagação, filas da rede, latência em um único sentido ou todo o tempo gasto no host remoto.

O escopo do campo é específico. Ele se refere ao intervalo entre o recebimento do pacote com o maior número de pacote reconhecido e a transmissão do ACK. Não há um valor separado para cada pacote coberto pelas ACK ranges, nem o campo deve ser lido como se cobrisse todos eles. Atrasos fora do controle do endpoint, como tempo no caminho do sistema operacional antes do processamento QUIC, não entram automaticamente. A espera causada pela indisponibilidade de chaves pode ser incluída segundo as regras, mas isso não a transforma em um cronômetro de processamento do host ou da aplicação.

O emissor calcula primeiro latest_rtt usando a hora local de envio do maior pacote recém-reconhecido que solicita ACK e a hora local de chegada do ACK. O sample bruto contém o intervalo completo observado. O ACK Delay só é usado depois, no cálculo de smoothed_rtt e rttvar. O valor codificado precisa de ack_delay_exponent e dos parâmetros de transporte corretos. O expoente padrão é 3; max_ack_delay é expresso em milissegundos e tem padrão de 25 ms, mas padrões não substituem o contexto negociado da conexão.

min_rtt é calculado apenas a partir de observações locais e não é reduzido pelo ACK Delay informado pelo par. Ele oferece uma proteção contra subestimação causada por um relatório incorreto; não é uma medida de latência de rede pura nem de caminho de ida. Depois da confirmação do handshake, o emissor usa o menor valor entre o ACK Delay decodificado e max_ack_delay do par, sem permitir que o resultado fique abaixo de min_rtt. Antes da confirmação, max_ack_delay não funciona como teto; atrasos maiores podem surgir, inclusive por falta de chaves disponíveis.

Um excesso não tem causa única comprovada. Depois da confirmação, o algoritmo trata o que supera max_ack_delay como parte efetiva do atraso do caminho, mas a observação não separa latência do agendador do par, perda de ACK anteriores e receptor fora de conformidade. A proteção do pacote autentica a origem do campo, não sua exatidão. Também não prova processamento da aplicação, resposta do serviço, conclusão durável ou resultado de negócio.

O registro operacional deve manter fatos separados: identidade da conexão e do caminho, espaço de números, maior pacote recém-reconhecido e hora de envio, chegada e processamento do ACK, latest_rtt bruto, campo e valor decodificado de ACK Delay, ack_delay_exponent, max_ack_delay do par, estado do handshake, min_rtt, teto e piso aplicados, sample ajustado, smoothed_rtt, rttvar e PTO. Registre também ACK ranges, disponibilidade de chaves, processamento local, evidência de ACK perdido e qualquer medição de aplicação. Observado, relatado e derivado não são sinônimos.