Protocolo de Transferência de Arquivos Trivial - Trivial File Transfer Protocol

O Trivial File Transfer Protocol ( TFTP ) é um protocolo de transferência de arquivos lockstep simples que permite a um cliente obter ou colocar um arquivo em um host remoto . Um de seus principais usos está nos estágios iniciais de inicialização dos nós a partir de uma rede local . TFTP foi usado para este aplicativo porque é muito simples de implementar.

O TFTP foi padronizado pela primeira vez em 1981 e a especificação atual para o protocolo pode ser encontrada na RFC 1350.

Visão geral

Devido ao seu design simples, o TFTP pode ser facilmente implementado por código com uma pequena pegada de memória . É, portanto, o protocolo de escolha para os estágios iniciais de qualquer estratégia de inicialização de rede como BOOTP , PXE , BSDP , etc., ao direcionar de computadores com muitos recursos a computadores de placa única (SBC) e System on a Chip (SoC ) com recursos muito baixos ) Ele também é usado para transferir imagens de firmware e arquivos de configuração para dispositivos de rede como roteadores , firewalls , telefones IP , etc. Hoje, o TFTP praticamente não é usado para transferências pela Internet.

O design do TFTP foi influenciado pelo protocolo anterior EFTP , que fazia parte do pacote de protocolos PARC Universal Packet . O TFTP foi definido pela primeira vez em 1980 pelo IEN 133. Em junho de 1981, o Protocolo TFTP (Revisão 2) foi publicado como RFC 783 e posteriormente atualizado em julho de 1992 pela RFC 1350 que consertou, entre outras coisas, a Síndrome do Aprendiz de Feiticeiro . Em março de 1995, o TFTP Option Extension RFC 1782 atualizado posteriormente em maio de 1998 pelo RFC 2347, definiu o mecanismo de negociação de opções que estabelece a estrutura para as opções de transferência de arquivos a serem negociadas antes da transferência usando um mecanismo consistente com a especificação original do TFTP.

TFTP é um protocolo simples para transferência de arquivos, implementado em cima dos protocolos UDP / IP usando o conhecido número de porta 69. O TFTP foi projetado para ser pequeno e fácil de implementar e, portanto, carece da maioria dos recursos avançados oferecidos por sistemas mais robustos protocolos de transferência de arquivos. O TFTP apenas lê e grava arquivos de ou para um servidor remoto. Ele não pode listar, excluir ou renomear arquivos ou diretórios e não tem provisões para autenticação de usuário. Hoje, o TFTP é geralmente usado apenas em redes locais (LAN).

Detalhes

(W1) Solicitações do Host A para escrever

(W2) O servidor S reconhece o pedido

(W3) Host A envia pacotes de dados numerados

(R1) Solicitações do Host A para ler

(R2) Servidor S envia pacote de dados 1

(R3) O Host A reconhece o pacote de dados 1

No TFTP, uma transferência é iniciada pelo cliente emitindo uma solicitação para ler ou gravar um arquivo específico no servidor. A solicitação pode incluir opcionalmente um conjunto de parâmetros de transferência negociados propostos pelo cliente nos termos especificados pela RFC 2347. Se o servidor atender à solicitação, o arquivo será enviado em blocos de comprimento fixo de 512 bytes por padrão ou o número especificado no tamanho do bloco opção negociada definida pela RFC 2348. Cada bloco de dados transferidos, que geralmente é transportado em um único pacote IP para evitar a fragmentação do IP, deve ser confirmado por um pacote de confirmação antes que o próximo bloco possa ser enviado. Um pacote de dados com menos de 512 bytes ou a opção de tamanho de bloco acordada sinaliza o término de uma transferência. Se um pacote for perdido na rede, o destinatário pretendido atingirá o tempo limite e poderá retransmitir seu último pacote (que pode ser dados ou uma confirmação), fazendo com que o remetente do pacote perdido retransmita o pacote perdido. O remetente deve manter apenas um pacote disponível para retransmissão, uma vez que a confirmação da etapa de bloqueio garante que todos os pacotes mais antigos foram recebidos corretamente. Observe que ambos os dispositivos envolvidos em uma transferência são considerados remetentes e receptores. Um envia dados e recebe confirmações, o outro envia confirmações e recebe dados.

TFTP define três modos de transferência: netascii, octeto e correio.

1. Netascii é uma forma modificada de ASCII , definida no RFC 764. Consiste em uma extensão de 8 bits do espaço de caracteres ASCII de 7 bits de 0x20 a 0x7F (os caracteres imprimíveis e o espaço) e oito dos caracteres de controle. Os caracteres de controle permitidos incluem o nulo (0x00), a alimentação de linha (LF, 0x0A) e o retorno de carro (CR, 0x0D). Netascii também requer que o marcador de fim de linha em um host seja traduzido para o par de caracteres CR LF para transmissão, e que qualquer CR deve ser seguido por um LF ou nulo.
2. O octeto permite a transferência de bytes brutos arbitrários de 8 bits, com o arquivo recebido resultando byte por byte idêntico ao enviado. Mais corretamente, se um host recebe um arquivo octeto e o retorna, o arquivo retornado deve ser idêntico ao original.
3. O modo de transferência de email usa a transferência Netascii, mas o arquivo é enviado a um destinatário de email especificando o endereço de email do destinatário como o nome do arquivo. A RFC 1350 declarou este modo de transferência obsoleto.

TFTP usa UDP como protocolo de transporte . Uma solicitação de transferência é sempre iniciada visando a porta 69, mas as portas de transferência de dados são escolhidas independentemente pelo remetente e pelo receptor durante a inicialização da transferência. As portas são escolhidas aleatoriamente de acordo com os parâmetros da pilha de rede, normalmente a partir do intervalo de portas efêmeras .

1. O host inicial A envia um pacote RRQ (solicitação de leitura) ou WRQ (solicitação de gravação) para o host S na porta número 69, contendo o nome do arquivo, o modo de transferência e, opcionalmente, qualquer opção negociada nos termos da RFC 2347.
2. S responde com uma opção ACK se opções foram usadas, e um pacote ACK (confirmação) para WRQ e diretamente com um pacote DATA para RRQ. O pacote é enviado de uma porta efêmera alocada aleatoriamente e todos os pacotes futuros para o host S devem ser direcionados para essa porta.
3. O host de origem envia pacotes de dados numerados para o host de destino, todos, exceto o último, contendo um bloco de dados de tamanho completo (padrão de 512 bytes). O host de destino responde com pacotes ACK numerados para todos os pacotes de dados.
4. O pacote de dados final deve conter menos do que um bloco de dados de tamanho normal para sinalizar que é o último. Se o tamanho do arquivo transferido for um múltiplo exato do tamanho do bloco, a fonte envia um pacote de DADOS final contendo 0 bytes de dados.
5. O receptor responde a cada DADOS com ACK numerado associado. O remetente responde ao primeiro ACK recebido de um bloco com DATA do próximo bloco.
6. Se um ACK eventualmente não for recebido, um temporizador de retransmissão reenvia o pacote de DADOS.

O TFTP sempre foi associado à inicialização pela rede. Uma das primeiras tentativas nesse sentido foi o Bootstrap Loading usando o padrão TFTP RFC 906, publicado em 1984, que estabeleceu o protocolo Trivial File Transfer Protocol padrão RFC 783 publicado em 1981 para ser usado como o protocolo de transferência de arquivo padrão para o carregamento de bootstrap. Foi seguido logo depois pelo protocolo Bootstrap padrão RFC 951 (BOOTP), publicado em 1985, que permitia a uma máquina cliente sem disco descobrir seu próprio endereço IP, o endereço de um servidor TFTP e o nome de um programa Network Bootstrap (NBP) a ser transferido por TFTP, carregado na memória e executado. O protocolo de configuração dinâmica de hosts padrão RFC 2131 (DHCP) publicado em 1997 aprimorou os recursos de BOOTP. Finalmente, o Preboot Execution Environment (PXE) versão 2.0 foi lançado em dezembro de 1998, e a atualização 2.1 foi tornada pública em setembro de 1999, contando com o TFTP como seu protocolo de transferência de arquivos. A Intel decidiu recentemente oferecer amplo suporte ao PXE dentro da nova especificação UEFI, estendendo o suporte TFTP a todos os ambientes EFI / UEFI.

O protocolo original tem um limite de tamanho de arquivo de transferência de 512 bytes / bloco x 65535 blocos = 32 MB. Em 1998, esse limite foi estendido para 65535 bytes / bloco x 65535 blocos = 4 GB pela opção de tamanho de bloco TFTP RFC 2348. Se o tamanho de bloco definido produz um tamanho de pacote IP que excede o MTU mínimo em qualquer ponto do caminho de rede, fragmentação e remontagem de IP ocorrerá não apenas adicionando mais overhead, mas também levando à falha total de transferência quando a implementação minimalista da pilha IP no BOOTP ou ROM PXE de um host não implementar (ou falhar em) implementar a fragmentação e remontagem IP. Se os pacotes TFTP devem ser mantidos dentro do Ethernet MTU padrão (1500), o valor do tamanho do bloco é calculado como 1500 menos cabeçalhos de TFTP (4 bytes), UDP (8 bytes) e IP (20 bytes) = 1468 bytes / bloco, isso dá um limite de 1468 bytes / bloco x 65535 blocos = 92 MB. Hoje, a maioria dos servidores e clientes suporta rollover de número de bloco (contador de bloco voltando a 0 ou 1 após 65535), o que dá um tamanho de arquivo de transferência essencialmente ilimitado.

Como o TFTP utiliza UDP, ele deve fornecer seu próprio transporte e suporte de sessão. Cada arquivo transferido via TFTP constitui uma troca independente. Classicamente, essa transferência é realizada em etapa de bloqueio, com apenas um pacote (um bloco de dados ou uma 'confirmação') alternativamente em voo na rede a qualquer momento. Devido a esta estratégia de bloco de dados único, em vez de enviar uma quantidade maior de blocos de dados ininterruptos antes de pausar a transferência para aguardar o reconhecimento correspondente (janela), o TFTP fornece baixo rendimento, especialmente em links de alta latência . A Microsoft introduziu o TFTP em janela no Windows 2008 como parte de seus Serviços de Implantação do Windows (WDS), em janeiro de 2015 a Opção do Windowsize TFTP RFC 7440 foi publicada. Isso melhora substancialmente o desempenho para coisas como inicialização PXE sem o efeito colateral de fragmentação de IP às vezes observado na opção Blocksize RFC 2348

Considerações de segurança

TFTP não inclui login ou mecanismos de controle de acesso. Deve-se ter cuidado ao usar TFTP para transferências de arquivos onde autenticação, controle de acesso, confidencialidade ou verificação de integridade são necessários. Observe que esses serviços de segurança podem ser fornecidos acima ou abaixo da camada em que o TFTP é executado. Deve-se tomar cuidado também com os direitos concedidos a um processo do servidor TFTP para não violar a segurança do sistema de arquivos do servidor. O TFTP geralmente é instalado com controles de forma que apenas os arquivos com acesso de leitura público estejam disponíveis por meio do TFTP. Também listar, excluir, renomear e gravar arquivos via TFTP normalmente não são permitidos. As transferências de arquivos TFTP não são recomendadas onde as limitações inerentes do protocolo podem levantar questões de responsabilidade intransponíveis.

Documentação de padrões IETF

Veja também

• Protocolo de Transferência de Arquivo Simples
• Ambiente de execução de pré-inicialização

Referências