Protocolos de transferência: do Kermit ao rsync

Por que os protocolos de transferência de ficheiros continuaram a mudar

Cada protocolo de transferência de ficheiros foi concebido para lidar com o modo de falha característico da sua década. O Kermit partia do princípio de que a linha iria corromper os seus bytes. O XMODEM e o ZMODEM partiam do princípio de que a ligação seria lenta e que cada minuto teria um custo. O FTP (file transfer protocol) partia do princípio de que a rede intermediária seria cooperante. O SSH partia do princípio de que seria hostil. Foi esta última suposição que prevaleceu. Por isso, atualmente, um VPS disponibiliza SFTP e rsync sobre SSH, e pouco mais.

Há uma razão para analisar este tema agora. O C-Kermit 11.0.506 foi lançado em 3 August 2026. É a primeira versão não beta desde o C-Kermit 9.0.302, lançado em 20 August 2011, e o protocolo que implementa foi concebido em May 1981. Quarenta e cinco anos são tempo suficiente para ver uma categoria inteira ser criada, normalizada, comprometida pela rede onde funcionava e, depois, absorvida pelo SSH.

Kermit, 1981: concebido para uma linha que consome os seus bytes

O Kermit foi criado em maio de 1981 no Columbia University Computer Center por Frank da Cruz e Bill Catchings. O nome vem de Kermit the Frog. Segundo o relato de Da Cruz, havia um calendário dos Muppets na parede enquanto o grupo tentava escolher um nome, e ninguém esperava que o programa se difundisse.

O problema que o Kermit resolveu não era a velocidade. O caminho entre um terminal e um mainframe não era um canal para bytes arbitrários. Era um dispositivo de caracteres com regras próprias. Podia ser de 7 bits. Podia funcionar em half-duplex. Podia ignorar caracteres de controlo ou interpretar um deles como um comando. Enviar um ficheiro binário sem alterações por esse caminho não funcionava.

Por isso, o design incorporou literalmente essas limitações. O histórico do Kermit Project enumera-as:

• pacotes curtos, porque a maioria dos mainframes não conseguia receber rajadas longas de dados provenientes de um terminal
• comunicação half-duplex com stop-and-wait, porque os mainframes IBM não suportavam comunicação full-duplex
• codificações imprimíveis para caracteres de controlo e para caracteres de 8 bits, porque nenhum dos dois podia passar pelo controlador de terminal do mainframe
• um checksum em cada pacote, confirmado pelo recetor, para que um pacote corrompido custasse uma retransmissão e não o ficheiro inteiro

O terceiro ponto é o mais interessante. O Kermit envia uma codificação do ficheiro segura para texto, em vez do próprio ficheiro. Um byte de controlo torna-se um caráter de prefixo seguido de um caráter imprimível, e um byte com o bit de ordem superior definido pode ser codificado da mesma forma numa ligação de 7 bits. Qualquer componente intermédio que só compreenda texto imprimível vê texto imprimível. O custo é o tamanho: um ficheiro binário aumenta durante a transmissão. Perante um front end de mainframe que, de outra forma, corromperia completamente a transferência, essa era a escolha correta.

Outra propriedade invulgar do Kermit é o seu âmbito. O XMODEM transferia um ficheiro entre duas máquinas que já tinham uma definição comum de ficheiro. O Kermit foi escrito como um denominador comum entre sistemas que não partilhavam essa definição, com conjuntos de caracteres, estruturas de registos e interpretações diferentes sobre o que termina uma linha de texto. Esse é o mundo descrito em a longa transição dos mainframes para os servidores cloud, e o Kermit representa a interoperabilidade antes de a camada de rede a tratar por si.

A Columbia terminou o seu patrocínio em 2011 e disponibilizou o C-Kermit sob a licença BSD revista de 3 cláusulas. Frank da Cruz manteve-se no projeto durante 44 anos, desde o design de 1981 até 2025. A versão 2026 é mantida pelo projeto OpenKermit, com John Goerzen a modernizar uma base de código C mais antiga do que a maioria das pessoas que agora a leem.

XMODEM e ZMODEM: quando o custo da ligação moldou o design

Ward Christensen escreveu MODEM.ASM em 1977, e o protocolo que introduziu foi o XMODEM. Em 1978, ele e Randy Suess colocaram o CBBS online, o primeiro sistema público de bulletin board. Christensen morreu em 11 de outubro de 2024.

O XMODEM é praticamente tão pequeno quanto um protocolo pode ser. Os dados são transferidos em blocos de 128 bytes. Cada bloco contém um checksum de um byte, que corresponde à soma dos 128 bytes de dados módulo 256. O recetor confirma cada bloco ou pede que seja enviado novamente. A razão dessa estrutura é económica. Numa linha dial-up, paga-se pelo tempo de utilização, por isso um erro na linha deve custar um bloco, e não a transferência inteira.

A limitação está na mesma descrição. O XMODEM espera uma confirmação depois de cada 128 bytes. Chuck Forsberg explicou isso claramente na especificação do ZMODEM: "O tamanho curto dos blocos reduz o débito quando são usados com sistemas de timesharing, redes com comutação de pacotes e circuitos via satélite." É a latência que prejudica o stop-and-wait, não a largura de banda. Cada viagem de ida e volta é tempo de inatividade numa linha cujo uso está a ser cobrado.

O YMODEM surgiu depois, e Ward Christensen criou o nome em 1985. A sua contribuição foi a transferência em lote. O emissor indica o nome e o tamanho do ficheiro antes dos dados, por isso vários ficheiros podem ser transferidos numa única sessão e o recetor sabe onde termina cada um.

O ZMODEM é a resposta de Chuck Forsberg, escrita na Omen Technology. A especificação é a revisão de 14 de outubro de 1988 e afirma que "o ZMODEM foi desenvolvido para o domínio público ao abrigo de um contrato com a Telenet". A Telenet operava uma rede pública de dados com comutação de pacotes, e esse contrato reflete-se no design. O ZMODEM faz escape dos caracteres de controlo da rede para que uma rede de pacotes no percurso não os consuma. Marca o início de cada frame com uma sequência única de caracteres, em vez de inferir os limites dos frames a partir do silêncio, por isso recupera de ruído sem esperar pelo fim de um timeout. Também tem uma retoma explícita, por isso uma transferência interrompida recomeça no ponto onde parou.

Mais importante, deixa de esperar. A própria especificação descreve-o assim: "Na prática, o ZMODEM usa o ficheiro inteiro como janela". O emissor transmite continuamente e só para quando o recetor comunica um problema. É a mesma ideia que o TCP codifica na sua janela, alcançada a partir da direção oposta por alguém que observava um modem permanecer inativo.

Por que as duas conexões do FTP envelheceram tão mal

O FTP é mais antigo do que todos eles. O RFC 114, “A File Transfer Protocol”, é datado de 16 April 1971 e foi escrito por A. Bhushan.

O detalhe importante é que o RFC 114 considerou o design com duas conexões e o rejeitou. Bhushan avaliou “usar dois links full-duplex, um para informações de controlo e outro para dados” e concluiu: “Recomendamos usar uma única conexão full-duplex para a troca de dados e informações de controlo.” A separação surgiu mais tarde. O RFC 354, datado de 8 July 1972, afirma que “os dados e ficheiros são transferidos apenas através da conexão de dados”, enquanto os comandos seguem por uma conexão Telnet separada. O RFC 959, de October 1985, de Postel e Reynolds, é a versão que continua a ser implementada por todos.

O RFC 959 também fixou as portas. A porta de dados predefinida do servidor é “a porta adjacente à porta da conexão de controlo (ou seja, L-1)”, que é a porta 20 quando a conexão de controlo usa a porta 21.

A parte que não sobreviveu foi esta. No modo original do FTP, o servidor abre a conexão de dados de volta para o cliente. Um cliente atrás de NAT (network address translation) não tem um endereço que o servidor consiga alcançar, e um cliente atrás de uma firewall não aceita conexões de entrada. Por isso, a conexão de dados nunca chega e a transferência fica bloqueada assim que é solicitado um diretório ou ficheiro. A resposta foi PASV, que o RFC 959 define como um pedido para o servidor “escutar numa porta de dados (que não seja a sua porta de dados predefinida) e aguardar uma conexão, em vez de iniciar uma ao receber um comando de transferência”. O servidor responde com o endereço e a porta aos quais o cliente deve ligar-se:

PASV
227 Entering Passive Mode (203,0,113,10,195,80)

Essa resposta significa host 203.0.113.10, porta 195 vezes 256 mais 80, ou seja, 50000. Leia-a novamente e o problema estrutural torna-se evidente. O endpoint da segunda conexão é anunciado dentro do payload da primeira. Um dispositivo NAT ou uma firewall não consegue encaminhar essa conexão sem analisar o canal de controlo e abrir a porta indicada. O Linux inclui um helper de connection tracking que faz exatamente isso. O helper só funciona enquanto a conexão de controlo estiver em texto simples. Por isso, proteger o FTP com TLS (transport layer security) impede que o middlebox que tornava o FTP utilizável veja o conteúdo necessário.

Essa é a lição do FTP numa frase. O protocolo tornou a rede participante no protocolo. Um protocolo que precisa que a rede o compreenda não consegue sobreviver numa rede que deixa de confiar nele.

O fim está documentado. O Firefox removeu o suporte para FTP na versão 90, em July 2021. O Chrome removeu o código de FTP no Chrome 95, em October 2021.

rcp e os r-commands: confiança por nome de host

O 4.2BSD, lançado em 1983 pela Berkeley com financiamento da DARPA, trouxe o rcp, o rsh e o rlogin. Estes comandos foram concebidos para um campus com máquinas Unix na mesma rede, e o modelo de autenticação reflete esse contexto. Um host declarava qual utilizador estava a fazer o pedido. Se /etc/hosts.equiv ou o ~/.rhosts de um utilizador indicasse que esse host era confiável, a declaração era aceite e não era pedida qualquer palavra-passe.

É importante descrever o mecanismo de forma direta, porque é precisamente a razão pela qual estes comandos desapareceram. A confiança baseava-se num endereço e numa declaração. Ambos eram transmitidos pela rede em texto simples. Qualquer pessoa no caminho podia lê-los e forjá-los. Esse modelo fazia sentido no ambiente descrito em o caminho do Unix ao Linux, onde a rede era um edifício. Deixou de fazer sentido assim que a rede passou a ser a internet.

O rcp acertou na interface. Origem, destino, concluído. Não era necessário abrir uma sessão, negociar um modo de transferência ou configurar uma segunda ligação. O seu funcionamento é semelhante ao de cp, com dois-pontos no caminho. Essa interface sobreviveu ao protocolo em quatro décadas.

O SSH absorve toda a categoria

Em 1995, Tatu Ylonen, então investigador na Helsinki University of Technology, escreveu o SSH em resposta a um ataque de captura de palavras-passe na rede da universidade. Em julho de 1995, lançou-o como software livre com o código-fonte. No final desse ano, a estimativa era de cerca de 20,000 utilizadores em 50 países. Em dezembro de 1995, fundou a SSH Communications Security para continuar o desenvolvimento.

A licença tornou-se mais restritiva nas versões seguintes. Por isso, os programadores do OpenBSD criaram um fork da última versão distribuída sob uma licença livre, ssh 1.2.12. A importação inicial ocorreu em 26 de setembro de 1999. O OpenSSH 1.2.2 foi lançado com o OpenBSD 2.6 em 1 de dezembro de 1999. Esse fork é um caso compacto de por que motivo os termos das licenças de código aberto são importantes na prática, porque a implementação de SSH que quase todos utilizam atualmente descende da única versão cuja licença ainda o permitia.

Depois do SSH existir, a transferência de ficheiros deixou de ser um problema separado. Um fluxo autenticado e cifrado que transporta vários canais já fornece o que os protocolos mais antigos tinham de implementar por conta própria: integridade, ordenação e um segundo canal de dados que não precisa de uma segunda ligação TCP. Se estes mecanismos forem novos para si, comece por compreender o que o SSH realmente é antes de continuar.

Surgiram duas ferramentas a partir dele. scp era o protocolo de comunicação do rcp executado dentro de uma sessão SSH. Por isso, herdou exatamente a linha de comandos do rcp. O SFTP tem um design diferente: é um protocolo de ficheiros completo, com listagem de diretórios, atributos de ficheiros e acesso aleatório, transportado num canal SSH. O SFTP nunca se tornou uma RFC. O draft do IETF, draft-ietf-secsh-filexfer, chegou à versão 13 em 18 de julho de 2006 e depois expirou. O OpenSSH implementa a versão 3 desse draft. O protocolo seguro de transferência de ficheiros mais utilizado no mundo é uma revisão numerada de um draft abandonado. E funciona.

O protocolo scp legado também foi entretanto retirado. O OpenSSH 8.8, lançado em 26 de setembro de 2021, avisava que "uma versão futura próxima do OpenSSH mudará o scp(1), fazendo com que utilize SFTP por predefinição em vez do protocolo scp/rcp legado". O OpenSSH 9.0, lançado em 8 de abril de 2022, concretizou essa alteração: "Esta versão muda o scp(1), fazendo com que utilize o protocolo SFTP por predefinição em vez do protocolo scp/rcp legado."

O motivo explica uma parte do conhecimento tradicional. O protocolo scp antigo expandia os curingas dos nomes de ficheiros remotos entregando-os à shell remota. Por isso, os utilizadores aprenderam a colocar entre aspas todos os metacarateres num caminho remoto. As notas da versão 8.8 afirmam que o scp sobre SFTP "já não exige este uso de aspas meticuloso e frágil". Assim, num servidor atual, scp é um cliente SFTP com a linha de comandos do rcp. A interface de 1983 sobreviveu. O protocolo de comunicação de 1983 não.

rsync, 1996: enviar a diferença, não o ficheiro

Andrew Tridgell e Paul Mackerras anunciaram o rsync em 19 de junho de 1996 na Australian National University, juntamente com o relatório técnico TR-CS-96-05, "The rsync algorithm".

Todos os protocolos anteriores procuravam uma forma de transferir um ficheiro sem o corromper. O rsync procurava saber quanto desse ficheiro o outro lado já tinha. O relatório apresenta como objetivo uma "ligação de comunicação bidirecional com baixa largura de banda e elevada latência" e pretende identificar "partes do ficheiro de origem que são idênticas a alguma parte do ficheiro de destino", para enviar apenas as partes que não correspondem.

Vale a pena compreender o mecanismo, porque ele explica o comportamento do rsync. O recetor divide a cópia existente em blocos de tamanho fixo e calcula dois checksums por bloco: um fraco e barato, e outro forte e dispendioso. Envia essa lista ao emissor. O emissor desliza uma janela sobre o seu próprio ficheiro, um byte de cada vez, e atualiza o checksum fraco de forma incremental. É isso que torna viável uma verificação byte a byte. Uma correspondência fraca é depois confirmada através do checksum forte. As correspondências confirmadas tornam-se referências a blocos. Tudo o resto é enviado como bytes literais. O recetor reconstrói o ficheiro a partir das referências aos blocos que já possui e dos literais que acabou de receber.

Se inserir um byte no início de um ficheiro grande, uma ferramenta de diferenças simples terá de enviar o ficheiro inteiro, porque todos os offsets mudaram. A janela deslizante encontra os mesmos blocos nos novos offsets, por isso o rsync envia um byte mais os dados de controlo. É por isso que o rsync continua a ser a ferramenta adequada para um diretório que será copiado mais do que uma vez.

Dois comportamentos surpreendem frequentemente os utilizadores, e ambos estão documentados no manual. Primeiro, o rsync não calcula checksums dos ficheiros para decidir se deve analisá-los. Por predefinição, ele "encontra os ficheiros que precisam de ser transferidos através de um algoritmo de verificação rápida que procura ficheiros cujo tamanho ou hora da última modificação tenha mudado". Um ficheiro cujo conteúdo mudou, mas cujo tamanho e timestamp permaneceram iguais, é ignorado. --checksum altera esse comportamento e faz com que ambos os lados leiam integralmente todos os ficheiros candidatos. Segundo, o algoritmo de diferenças está desativado por predefinição quando ambos os caminhos são locais, porque ler e calcular checksums de duas cópias na mesma máquina custa mais do que copiar os bytes. A poupança só existe quando a ligação é a parte lenta.

O que você realmente usa num VPS e porquê

A versão curta: SFTP para alguns ficheiros; rsync sobre SSH para um diretório que vai copiar novamente.

Ambos usam SSH, por isso herdam a verificação da chave do host e a encriptação sem configuração adicional. São cinquenta anos de trabalho comprimidos num padrão predefinido. Os autores do Kermit tiveram de assumir que a ligação iria corromper dados, por isso integraram somas de verificação e retransmissões no protocolo. Atualmente, o TCP trata disso. Christensen e Forsberg tiveram de assumir que cada byte custava dinheiro, por isso integraram a retoma e o streaming. Atualmente, o algoritmo delta do rsync trata disso e fá-lo melhor. Os autores do FTP assumiram uma rede de hosts cooperantes, e essa é a única dessas suposições que se revelou falsa de uma forma que nenhum trabalho no protocolo poderia corrigir.

Que utilidade ainda têm os checksums

A palavra "checksum" desempenhou três funções diferentes ao longo desta história, e elas não são intercambiáveis.

Os checksums por pacote do Kermit e do XMODEM detetavam corrupção durante a transmissão. Atualmente, o checksum do TCP e a correção de erros na camada de ligação cobrem essa função. Por isso, nenhuma ferramenta moderna de transferência lhe pede para se preocupar com esse detalhe.

Os checksums de blocos do rsync não respondem à pergunta "estes dados estão corretos?". Respondem à pergunta "já tem este bloco?". Nesse contexto, um checksum forte é uma chave de pesquisa, não uma declaração sobre a origem do ficheiro.

A terceira função é a única que continua a depender de si. Um checksum publicado para um ficheiro de uma release responde a uma pergunta que o TLS não consegue responder. O TLS prova que comunicou com o servidor correto. Não prova que o ficheiro correto estava nesse servidor e não oferece qualquer garantia para um ficheiro obtido de um mirror. É por isso que os checksums e as assinaturas de releases ainda justificam esses trinta segundos. O hábito é fácil de criar: verifique o checksum de cada transferência que instalar.

Tudo o resto nesta história foi resolvido pela camada inferior. Essa função não foi, porque nunca foi um problema de rede.

FAQ

O FTP ainda é seguro para utilizar numa VPS?

Não. O FTP simples envia as credenciais e o conteúdo dos ficheiros em texto simples, por isso qualquer pessoa no caminho consegue ler ambos. Também depende de uma firewall que analise o canal de controlo, o que deixa de ser possível assim que o canal de controlo é cifrado com TLS. Os browsers já o abandonaram: o Firefox removeu o suporte para FTP na versão 90, em julho de 2021, e o Chrome removeu o código na versão 95, em outubro de 2021. Utilize SFTP sobre SSH, que precisa de uma porta e não requer um equipamento intermédio com conhecimento do protocolo.

Porque é que o FTP precisa de um modo passivo?

Porque, no modo original do FTP, o servidor abre a ligação de dados de volta para o cliente. A RFC 959 define a porta de dados predefinida do servidor como "a porta adjacente à porta da ligação de controlo (ou seja, L-1)", portanto a porta 20 quando o controlo está na porta 21. Um cliente atrás de NAT (tradução de endereços de rede) não tem um endereço que o servidor consiga alcançar, por isso essa ligação nunca chega e a transferência fica bloqueada. O PASV inverte a direção: o servidor fica à escuta e responde com um endereço e uma porta dentro de uma resposta 227 Entering Passive Mode, para o cliente estabelecer a ligação.

O scp ainda utiliza o seu próprio protocolo?

Não desde o OpenSSH 9.0, lançado em 8 de abril de 2022, que "muda o scp(1) da utilização do protocolo scp/rcp legado para a utilização do protocolo SFTP por predefinição". O OpenSSH 8.8 anunciou a alteração em setembro de 2021. A diferença visível está no quoting. O protocolo antigo expandia os wildcards remotos ao passá-los para a shell remota, mas o protocolo baseado em SFTP não o faz. Por isso, os caminhos que dependiam dessa expansão da shell comportam-se agora de forma diferente.

Quando é que o rsync é melhor do que o scp para uma VPS?

Quando vai copiar a mesma árvore mais do que uma vez. O rsync envia apenas as partes de cada ficheiro que o destino ainda não tem, por isso a segunda cópia é muito mais barata do que a primeira. Para um único ficheiro que o destino nunca viu, scp e rsync transferem aproximadamente os mesmos bytes, e o scp é mais simples. Tenha em conta que, por predefinição, o rsync decide o que deve analisar com base no tamanho e na hora de modificação. Por isso, um ficheiro cujo conteúdo mudou sem que o tamanho e o timestamp mudassem precisa de --checksum antes de o rsync o detetar.

Porque é que o Kermit codificava os ficheiros como texto imprimível em vez de enviar bytes diretamente?

Porque a ligação a que se destinava era uma linha de terminal para um mainframe, e não um canal de bytes. Essas ligações podiam ser de 7 bits, e o controlador de terminal do mainframe processava os caracteres de controlo em vez de os transmitir. O Kermit codificava os bytes de controlo e os bytes com o bit superior definido como caracteres imprimíveis, para impedir que algo no caminho reagisse a eles. A codificação aumenta o tamanho dos ficheiros binários durante a transmissão, mas era a opção correta face a uma transferência que, de outro modo, chegaria corrompida.