Resumo

  • STREAM localiza uma faixa de bytes em um fluxo ordenado usando stream ID, offset e campos de codificação.
  • A transmissão, a recuperação de perdas e a entrega à aplicação não preservam os limites da trama STREAM original.
  • Mensagens e transações exigem enquadramento do protocolo de aplicação, parsing e comprovante de processamento.

O erro operacional começa quando uma evidência de transporte recebe um significado que pertence à aplicação. Um exportador mostra uma trama STREAM aparentemente completa, e o painel transforma essa observação em uma requisição concluída. A trama apenas indica que uma faixa de bytes foi codificada para uma posição em um fluxo específico. Ela não declara que esses bytes formam uma mensagem.

RFC 9000 trata os streams como fluxos ordenados de bytes expostos às aplicações. O receptor usa o stream ID e o Offset para posicionar os dados. Essa ordenação vale dentro de um único stream. Dados de streams diferentes não adquirem uma ordem global só porque uma captura os apresenta em determinada sequência. A ordem do arquivo não é a ordem de execução da aplicação.

OFF, LEN e FIN pertencem à codificação do transporte. OFF indica se existe um campo Offset; sem ele, os dados começam no offset zero. LEN indica se existe Length; sem ele, os dados ocupam o restante do pacote. FIN marca a fronteira final de bytes do stream, e o tamanho final resulta do offset e do comprimento dos dados. Nenhum desses campos define a sintaxe da aplicação, um delimitador de registro ou o sucesso de uma operação.

Quando ocorre uma perda, QUIC não retransmite o pacote inteiro nem recria a divisão original das tramas. As informações do stream são enviadas novamente em novas tramas STREAM. Uma nova trama pode cobrir outra faixa e ainda carregar os mesmos bytes lógicos. A forma da primeira trama, portanto, não é uma identidade permanente de mensagem. Faixas duplicadas podem chegar e ser descartadas; os bytes no mesmo offset não podem mudar. Conteúdo diferente na mesma posição seria uma violação do protocolo.

O endpoint receptor DEVE ser capaz de armazenar dados de stream fora de ordem até o limite de controle de fluxo anunciado, para reconstruir o fluxo ordenado. Uma implementação pode, separadamente, expor informações sobre dados fora de ordem à aplicação; essa exposição é opcional e não é um requisito do QUIC. QUIC não impõe um modelo de mensagens. Um protocolo superior pode distribuir uma mensagem por várias tramas, colocar várias estruturas na faixa transportada por uma trama ou transportar apenas parte de uma estrutura maior.

FIN pode encerrar o envio sem provar que os dados são válidos, foram analisados, aceitos, executados ou gravados de forma durável.

O registro operacional deve manter separados o identificador e o horário da observação, a direção dos endpoints, o packet number space e o packet number, o stream ID e a direção, o offset, o comprimento codificado ou a regra do restante do pacote, a impressão digital da faixa de bytes, FIN e o tamanho final quando conhecido, o tratamento de faixas duplicadas, o rastreamento da retransmissão, a evidência de ACK, a conclusão da remontagem, o identificador de frame ou registro do protocolo de aplicação, o resultado do parser, o recibo de processamento e o resultado durável do negócio.

Quando o conteúdo bruto não for necessário, use uma impressão digital que preserve a privacidade. Esse registro é uma recomendação operacional, não um requisito do QUIC.

O limite da prova é estreito. STREAM demonstra que uma faixa de bytes foi codificada para um fluxo específico. O processamento autenticado pode contribuir para demonstrar a recepção no endpoint de transporte. Isso não prova mensagem, requisição, resposta, execução, confirmação durável ou sucesso. Também não prova ordem entre streams. Limites de mensagem, tamanho final, faixas de dados criptográficos e evidência de ACK são questões distintas.