Resumo

  • Na prova de conceito da RFC 2348, transferir um arquivo de 2,25 MB levou 23,85 segundos sem gateway intermediário com blocos de 512 octetos e 4,90 segundos com blocos de 8.192.
  • O bloco ficou 16 vezes maior, mas o tempo medido caiu cerca de 80%, não 16 vezes. A própria RFC avisa que fragmentação e remontagem passam a pesar quando o bloco excede o MTU do caminho.

O TFTP original trocava velocidade por simplicidade: um bloco de dados, uma confirmação e só então o próximo. Os 512 octetos do formato básico eram adequados a dispositivos pequenos, inclusive máquinas sem disco que inicializavam a partir de uma ROM limitada. Em uma LAN com quadros maiores, porém, cada confirmação e cada pausa podiam consumir uma parcela relevante do tempo.

Em maio de 1998, a RFC 2348 criou a opção negociável blksize. A RFC 2347 já havia estabelecido o mecanismo: o cliente acrescenta a opção ao pedido de leitura ou gravação e o servidor pode responder com um OACK. Para o tamanho do bloco, o servidor só pode aceitar um valor igual ou menor que o solicitado; não pode iniciar uma opção que o cliente não pediu. O cliente usa o valor confirmado ou encerra a transferência. Um servidor antigo pode ignorar a opção e continuar com o TFTP normal. A extensão preservava a compatibilidade, sem obrigar todos os equipamentos a mudar ao mesmo tempo.

A faixa permitida vai de 8 a 65.464 octetos de dados por bloco, sem contar o cabeçalho TFTP de quatro octetos. A RFC usa 1.428 octetos como exemplo de cálculo a partir do MTU Ethernet, descontando os cabeçalhos TFTP, UDP e IP. É um exemplo, não uma configuração universal. Acordar um tamanho entre os dois processos TFTP não prova que todos os enlaces e túneis do trajeto conseguem transportar o datagrama sem fragmentá-lo.

A RFC publicou uma prova de conceito com condições específicas: dois sistemas HP-UX 9000, Ethernet pouco carregada, modo octet e arquivos de 2,25 MB. Cada resultado era a média de cinco transferências, com e sem um gateway intermediário. Com blocos de 512 octetos, os tempos foram 23,85 e 37,05 segundos; com 8.192, 4,90 e 6,15 segundos. Em termos de tempo decorrido, isso equivale a cerca de 4,87 vezes menos tempo no caminho sem gateway e 6,02 vezes no caminho com gateway; as quedas foram aproximadamente 79,5% e 83,4%.

O «16x» da tabela comparativa é a proporção entre tamanhos: 8.192 dividido por 512. Não quer dizer que a transferência ficou dezesseis vezes mais rápida. A redução de cerca de 80% bate com os tempos médios publicados. Tamanho de bloco, quantidade de pacotes e tempo total são medidas diferentes. Ainda assim, o ganho é expressivo: blocos maiores reduzem pacotes de dados, confirmações, esperas e trabalho de enquadramento e processamento por pacote.

A ressalva aparece ao lado do resultado. Se o bloco passa do MTU do caminho, fragmentação e remontagem IP acrescentam custo; quanto mais gateways, mais perceptível pode ser a penalidade. O bloco eficiente no Ethernet do teste talvez não se encaixe depois de um enlace menor ou de uma encapsulação. O experimento não avaliou uma variedade de caminhos da Internet, não mostrou a dispersão estatística e não determinou um tamanho ótimo geral. É um resultado de protótipo sob condições declaradas, não um levantamento de implantações.

Mais tarde, a RFC 7440 definiu windowsize, que permite enviar vários blocos seguidos antes de esperar uma confirmação. Tamanho de bloco e profundidade da janela são controles distintos. A RFC 8900, muito posterior, trata da fragilidade da fragmentação IP na operação; não prova que o teste de 1998 tenha falhado. O próprio aviso original é suficiente: um valor negociado não certifica o caminho inteiro.

A lição histórica da RFC 2348 é mais precisa que «maior é sempre melhor». Um protocolo pequeno podia negociar uma unidade de transferência adequada à rede, medir um ganho importante em condições explícitas e registrar a fronteira de MTU que poderia corroê-lo. O número não era mágico; era um ponto de partida para medir o caminho usado de fato.

A especificação básica está na RFC 1350. As opções contemporâneas de timeout e tamanho de transferência estão na RFC 2349, úteis para separar o blksize de outros parâmetros negociáveis.