Protocolos de transferencia: de Kermit a rsync

Por qué los protocolos de transferencia de archivos siguieron cambiando

Cada protocolo de transferencia de archivos se diseñó para hacer frente al tipo de fallo de su propia época. Kermit asumía que la línea corrompería los bytes. XMODEM y ZMODEM asumían que la conexión era lenta y que cada minuto tenía un coste. FTP (file transfer protocol) asumía que la red intermedia colaboraba. SSH asumía que era hostil. Esta última suposición fue la que se impuso. Por eso, hoy un VPS ofrece SFTP y rsync sobre SSH, y muy poco más.

Ahora hay un motivo para revisar esta historia. C-Kermit 11.0.506 se publicó el 3 de agosto de 2026. Es la primera versión que no está en fase beta desde C-Kermit 9.0.302, publicada el 20 de agosto de 2011. El protocolo que implementa se diseñó en mayo de 1981. Cuarenta y cinco años bastan para ver cómo se inventa y estandariza toda una categoría, cómo la red sobre la que se ejecuta la deja obsoleta y cómo finalmente SSH la absorbe.

Kermit, 1981: diseñado para una línea que consume los bytes

Kermit se creó en mayo de 1981 en el Columbia University Computer Center por Frank da Cruz y Bill Catchings. El nombre procede de Kermit the Frog. Según el relato de da Cruz, había un calendario de los Muppets en la pared mientras el grupo intentaba pensar en un nombre, y nadie esperaba que el programa se extendiera.

El problema que resolvía Kermit no era la velocidad. La ruta entre un terminal y un mainframe no era un conducto para bytes arbitrarios. Era un dispositivo de caracteres con sus propias reglas. Podía ser de 7 bits. Podía funcionar en semidúplex. Podía consumir caracteres de control o interpretar uno de ellos como un comando. Enviar un archivo binario sin modificarlo no funcionaba.

Por eso, el diseño incorporó esas restricciones de forma explícita. El historial del propio Kermit Project las enumera:

• paquetes cortos, porque la mayoría de los mainframes no podía aceptar grandes ráfagas de datos entrantes desde un terminal
• semidúplex con espera después de cada paquete, porque los mainframes IBM no admitían comunicación dúplex completa
• codificaciones imprimibles para los caracteres de control y para los caracteres de 8 bits, porque ninguno de los dos tipos podía atravesar el controlador de terminal del mainframe
• una suma de comprobación en cada paquete, con respuesta del receptor, para que un paquete corrupto costara una retransmisión y no el archivo completo

El tercer punto es el más interesante. Kermit envía una codificación del archivo que sólo contiene texto seguro, no el archivo en sí. Un byte de control se convierte en un carácter de prefijo seguido de un carácter imprimible, y un byte con el bit alto activado puede codificarse de la misma forma para un enlace de 7 bits. Todo lo que haya en el trayecto y sólo entienda texto imprimible recibe texto imprimible. El coste es el tamaño: un archivo binario aumenta de tamaño durante la transmisión. Frente a un frontend de mainframe que, de otro modo, alteraría por completo la transferencia, era una compensación adecuada.

La otra propiedad poco habitual de Kermit es su alcance. XMODEM transfería un archivo entre dos máquinas que ya coincidían en lo que era un archivo. Kermit se diseñó como el mínimo común denominador entre sistemas que no coincidían, con distintos juegos de caracteres, distintas estructuras de registros y distintas ideas sobre qué marca el final de una línea de texto. Ese es el mundo que se describe en el largo cambio de los mainframes a los servidores cloud, y Kermit representa cómo era la interoperabilidad antes de que la capa de red se encargara de ella.

Columbia puso fin a su patrocinio en 2011 y publicó C-Kermit bajo la licencia BSD revisada de 3 cláusulas. Frank da Cruz continuó en el proyecto durante 44 años, desde el diseño de 1981 hasta 2025. La versión de 2026 la mantiene el proyecto OpenKermit, con John Goerzen encargado de modernizar una base de código C más antigua que la mayoría de las personas que la leen actualmente.

XMODEM y ZMODEM: cuando el coste telefónico determinaba el diseño

Ward Christensen escribió MODEM.ASM en 1977, y el protocolo que introdujo es XMODEM. En 1978, él y Randy Suess pusieron CBBS en línea, el primer sistema público de tablón de anuncios. Christensen murió el 11 de octubre de 2024.

XMODEM es casi tan pequeño como puede ser un protocolo. Los datos se transfieren en bloques de 128 bytes. Cada bloque contiene una suma de comprobación de un byte: la suma de los 128 bytes de datos módulo 256. El receptor confirma cada bloque o solicita que se vuelva a enviar. La razón de este diseño es económica. En una línea de acceso telefónico se paga por tiempo, así que un error de línea debe costar un bloque y no toda la transferencia.

La debilidad aparece en esa misma característica. XMODEM espera una confirmación después de cada 128 bytes. Chuck Forsberg lo explicó claramente en la especificación de ZMODEM: "La longitud corta de los bloques reduce el rendimiento cuando se usa con sistemas de tiempo compartido, redes de conmutación de paquetes y circuitos vía satélite". La latencia, no el ancho de banda, es lo que perjudica al método de parada y espera. Cada ida y vuelta deja la línea inactiva mientras el tiempo de conexión sigue facturándose.

Después llegó YMODEM, nombre acuñado por Ward Christensen en 1985. Su aportación fue la transferencia por lotes. El emisor indica el nombre y el tamaño del archivo antes de los datos, de modo que varios archivos pueden transferirse en una sola sesión y el receptor sabe dónde termina cada uno.

ZMODEM es la respuesta de Chuck Forsberg, escrita en Omen Technology. La especificación es la revisión del 14 de octubre de 1988 y afirma que "ZMODEM se desarrolló para el dominio público bajo un contrato con Telenet". Telenet operaba una red pública de datos con conmutación de paquetes, y ese contrato se refleja en el diseño. ZMODEM escapa los caracteres de control de red para que una red de paquetes intermedia no los consuma. Marca el inicio de cada trama con una secuencia de caracteres única, en lugar de inferir los límites de las tramas a partir del silencio, por lo que puede recuperarse del ruido sin esperar a que expire un tiempo de espera. También incluye una reanudación explícita, de modo que una transferencia interrumpida continúa desde el punto en que se detuvo.

Lo más importante es que deja de esperar. La propia especificación lo describe así: "ZMODEM utiliza, en la práctica, todo el archivo como ventana". El emisor transmite continuamente y sólo se detiene cuando el receptor informa de un problema. Es la misma idea que TCP codifica en su ventana, alcanzada desde la dirección contraria, por alguien que observaba un módem permanecer inactivo.

Por qué las dos conexiones de FTP envejecieron tan mal

FTP es más antiguo que todos esos sistemas. El RFC 114, «A File Transfer Protocol», está fechado el 16 de abril de 1971 y fue escrito por A. Bhushan.

El detalle importante es que el RFC 114 consideró el diseño de dos conexiones y lo rechazó. Bhushan valoró «usar dos enlaces full-duplex, uno para la información de control y otro para los datos» y concluyó: «Recomendamos usar una única conexión full-duplex para intercambiar tanto los datos como la información de control». La separación llegó después. El RFC 354, fechado el 8 de julio de 1972, establece que «los datos y los archivos se transfieren únicamente mediante la conexión de datos», mientras que los comandos viajan por una conexión Telnet independiente. El RFC 959, de octubre de 1985, escrito por Postel y Reynolds, es la versión que todavía implementan todos.

El RFC 959 también fijó los puertos. El puerto de datos predeterminado del servidor es «el puerto adyacente al puerto de la conexión de control (es decir, L-1)», que es el puerto 20 cuando la conexión de control usa el puerto 21.

Esta es la parte que no sobrevivió. En el modo original de FTP, el servidor abre la conexión de datos hacia el cliente. Un cliente detrás de NAT (traducción de direcciones de red) no tiene una dirección a la que el servidor pueda conectarse, y un cliente detrás de un firewall no acepta conexiones entrantes. Por tanto, la conexión de datos nunca llega y la transferencia se bloquea en cuanto se solicita un listado o un archivo. La respuesta fue PASV, que el RFC 959 define como una solicitud para que el servidor «“escuche” en un puerto de datos (que no sea su puerto de datos predeterminado) y espere una conexión en lugar de iniciarla al recibir un comando de transferencia». El servidor responde con la dirección y el puerto a los que se debe conectar:

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

Esa respuesta significa host 203.0.113.10 y puerto 195 multiplicado por 256 más 80, es decir, 50000. Léala de nuevo y el problema estructural resulta evidente. El extremo de la segunda conexión se anuncia dentro de la carga útil de la primera. Un dispositivo NAT o un firewall no puede permitir esa conexión a menos que analice el canal de control y abra el puerto que aparece allí. Linux incluye un helper de seguimiento de conexiones que hace exactamente esto. El helper sólo funciona mientras la conexión de control está en texto claro. Por tanto, envolver FTP en TLS (seguridad de la capa de transporte) deja ciego al dispositivo intermedio que hacía posible usar FTP.

Esa es la lección de FTP en una frase. Hizo que la red participara en el protocolo. Un protocolo que necesita que la red lo entienda no puede sobrevivir en una red que deja de confiar en él.

El final está documentado. Firefox eliminó la compatibilidad con FTP en la versión 90, en julio de 2021. Chrome eliminó el código de FTP en Chrome 95, en octubre de 2021.

rcp y los r-command: confianza basada en el nombre de host

4.2BSD, publicado en 1983 por Berkeley con financiación de DARPA, incorporó rcp, rsh y rlogin. Se diseñaron para un campus con máquinas Unix conectadas a una misma red, y el modelo de autenticación lo refleja. Un host afirmaba qué usuario realizaba la llamada. Si /etc/hosts.equiv o el ~/.rhosts del usuario indicaban que ese host era de confianza, se aceptaba la afirmación y no se solicitaba ninguna contraseña.

El mecanismo debe explicarse claramente, porque esa es la razón por la que estos comandos han desaparecido. La confianza se basaba en una dirección y una afirmación. Ambas viajaban por la red en texto claro, por lo que cualquiera que estuviera en el trayecto podía leerlas y falsificarlas. Ese modelo tenía sentido en el entorno descrito en el recorrido de Unix a Linux, donde la red era un edificio. Dejó de tener sentido en cuanto la red pasó a ser internet.

Lo que rcp hacía bien era la interfaz. Origen, destino y listo. No había que abrir una sesión, negociar un modo de transferencia ni establecer una segunda conexión. Se comporta como cp con dos puntos en la ruta. Esa interfaz sobrevivió a su protocolo durante cuatro décadas.

SSH abarca toda la categoría

En 1995, Tatu Ylonen, entonces investigador en la Helsinki University of Technology, escribió SSH como respuesta a un ataque de captura de contraseñas en la red de la universidad. Lo publicó como software libre con su código fuente en julio de 1995. A finales de ese año, la estimación era de unos 20,000 usuarios en 50 países. En diciembre de 1995 fundó SSH Communications Security para continuar su desarrollo.

La licencia se volvió más restrictiva en versiones posteriores. Por eso, los desarrolladores de OpenBSD bifurcaron la última versión con licencia libre, ssh 1.2.12. La importación inicial se realizó el 26 de septiembre de 1999. OpenSSH 1.2.2 se distribuyó con OpenBSD 2.6 el 1 de diciembre de 1999. Esta bifurcación es un caso práctico y conciso de por qué importan las condiciones de las licencias de código abierto, porque la implementación de SSH que utiliza casi todo el mundo desciende de la única versión cuya licencia todavía lo permitía.

Cuando apareció SSH, la transferencia de archivos dejó de ser un problema independiente. Un flujo autenticado y cifrado con varios canales ya proporciona lo que los protocolos anteriores tenían que implementar por separado: integridad, orden y una segunda ruta de datos que no necesita una segunda conexión TCP. Si estos mecanismos son nuevos para usted, empiece por entender qué es realmente SSH antes de continuar.

De SSH surgieron dos herramientas. scp era el protocolo de comunicación de rcp ejecutado dentro de una sesión SSH. Por eso heredó exactamente su línea de comandos. SFTP tiene un diseño diferente: es un protocolo de archivos completo, con listado de directorios, atributos de archivos y acceso aleatorio, transportado por un canal SSH. SFTP nunca se convirtió en un RFC. El borrador del IETF, draft-ietf-secsh-filexfer, alcanzó la versión 13 el 18 de julio de 2006 y después caducó. OpenSSH implementa la versión 3 de ese borrador. El protocolo seguro de transferencia de archivos más utilizado del mundo es una revisión numerada de un borrador abandonado, y funciona.

El protocolo heredado de scp también se retiró. OpenSSH 8.8, publicado el 26 de septiembre de 2021, advertía que "una versión próxima de OpenSSH cambiará scp(1) del uso del protocolo heredado scp/rcp al uso de SFTP de forma predeterminada". OpenSSH 9.0, publicado el 8 de abril de 2022, lo hizo: "Esta versión cambia scp(1) del uso del protocolo heredado scp/rcp al uso del protocolo SFTP de forma predeterminada".

El motivo explica parte de la tradición. El protocolo antiguo de scp expandía los comodines de nombres de archivo remotos al pasárselos al shell remoto. Por eso se aprendió a poner entre comillas dobles todos los metacaracteres de una ruta remota. Las notas de la versión 8.8 indican que scp mediante SFTP "ya no requiere este entrecomillado delicado y frágil". Por tanto, en un servidor actual, scp es un cliente SFTP que utiliza la línea de comandos de rcp. La interfaz de 1983 sobrevivió. El protocolo de comunicación de 1983 no.

rsync, 1996: enviar las diferencias, no el archivo

Andrew Tridgell y Paul Mackerras anunciaron rsync el 19 de junio de 1996 en la Australian National University, junto con el informe técnico TR-CS-96-05, «The rsync algorithm».

Todos los protocolos anteriores planteaban cómo mover un archivo sin corromperlo. rsync planteó cuánto de ese archivo ya tenía el otro extremo. El informe define el objetivo como «un enlace de comunicaciones bidireccional de bajo ancho de banda y alta latencia», y busca identificar «las partes del archivo de origen que son idénticas a alguna parte del archivo de destino», para enviar sólo las partes que no coinciden.

Conviene entender el mecanismo porque explica el comportamiento de rsync. El receptor divide su copia existente en bloques de tamaño fijo y calcula dos sumas de comprobación por bloque: una débil y rápida, y otra fuerte y costosa. Envía esa lista al emisor. El emisor desplaza una ventana sobre su propio archivo, un byte cada vez, y actualiza incrementalmente la suma débil. Esto es lo que hace viable un análisis byte a byte. Después, la coincidencia débil se confirma mediante la suma fuerte. Las coincidencias confirmadas se convierten en referencias a bloques. Todo lo demás se envía como bytes literales. El receptor reconstruye el archivo a partir de referencias a los bloques que ya tiene y de los literales que acaba de recibir.

Si se inserta un byte al principio de un archivo grande, una herramienta de diferencias básica tiene que enviar todo el archivo porque todos los desplazamientos han cambiado. La ventana deslizante encuentra los mismos bloques en sus nuevos desplazamientos, de modo que rsync envía un byte más la información de control. Por eso rsync sigue siendo la herramienta adecuada para un directorio que se copiará más de una vez.

Hay dos comportamientos que suelen sorprender, y ambos aparecen en el manual. Primero, rsync no calcula sumas de comprobación de los archivos para decidir si debe examinarlos. «Busca los archivos que deben transferirse mediante un algoritmo de comprobación rápida (de forma predeterminada), que busca archivos cuyo tamaño o fecha de última modificación hayan cambiado». Si el contenido de un archivo cambia mientras su tamaño y su marca de tiempo permanecen idénticos, rsync lo omite. --checksum cambia este comportamiento y hace que ambos extremos lean por completo todos los archivos candidatos. Segundo, el algoritmo de diferencias está desactivado de forma predeterminada cuando ambas rutas son locales, porque leer y calcular sumas de comprobación de dos copias en una misma máquina cuesta más que copiar los bytes. El ahorro sólo existe cuando el enlace es la parte lenta.

Qué se usa realmente en un VPS y por qué

La versión corta: SFTP para unos pocos archivos y rsync sobre SSH para un directorio que vaya a copiar de nuevo.

Ambos usan SSH, por lo que heredan la verificación de claves de host y el cifrado sin configuración adicional. Eso condensa cincuenta años de trabajo en una configuración predeterminada. Los diseñadores de Kermit tuvieron que asumir que la línea podía corromper los datos, así que incorporaron sumas de comprobación y retransmisiones al protocolo. TCP hace eso ahora. Christensen y Forsberg tuvieron que asumir que cada byte costaba dinero, así que incorporaron la reanudación y la transmisión continua. El algoritmo delta de rsync hace eso ahora y lo hace mejor. Los autores de FTP asumieron una red de hosts cooperantes, y esa es la única de esas suposiciones que resultó ser falsa de una forma que ningún trabajo adicional en el protocolo podía corregir.

Qué aportan todavía las sumas de comprobación

La palabra "checksum" ha desempeñado tres funciones distintas a lo largo de esta historia. No son intercambiables.

Las sumas de comprobación por paquete de Kermit y XMODEM detectaban la corrupción durante la transmisión. Hoy, la suma de comprobación de TCP y la corrección de errores de la capa de enlace cubren esa función. Por eso ninguna herramienta moderna de transferencia le pide que se ocupe de ella.

Las sumas de comprobación de bloques de rsync no responden a la pregunta «¿estos datos son correctos?». Responden a «¿ya tiene este bloque?». En este caso, una suma de comprobación robusta es una clave de búsqueda, no una afirmación sobre el origen del archivo.

La tercera función es la que todavía debe realizar usted. Una suma de comprobación publicada para un archivo de una versión responde a una pregunta que TLS no puede responder. TLS demuestra que se comunicó con el servidor correcto. No demuestra que el archivo correcto estuviera almacenado en ese servidor y no sirve de nada para un archivo que descargó desde un mirror. Por eso todavía merece la pena dedicar treinta segundos a las sumas de comprobación y las firmas de las versiones. Además, es fácil convertirlo en un hábito: compruebe la suma de comprobación de cada descarga que instale.

Todo lo demás de esta historia se resolvió en la capa inferior. Esa función no se resolvió allí porque nunca fue un problema de red.

FAQ

¿Sigue siendo seguro usar FTP en un VPS?

No. FTP sin cifrado envía las credenciales y el contenido de los archivos en texto claro, por lo que cualquiera que intercepte la conexión puede leer ambos. También depende de un firewall que analice su canal de control, pero eso deja de ser posible en cuanto se cifra el canal de control con TLS. Los navegadores ya lo eliminaron: Firefox retiró la compatibilidad con FTP en la versión 90, en julio de 2021, y Chrome eliminó el código en la versión 95, en octubre de 2021. Use SFTP sobre SSH. Sólo necesita un puerto y ningún dispositivo intermedio que conozca el protocolo.

¿Por qué FTP necesita un modo pasivo?

Porque, en el modo original de FTP, el servidor abre la conexión de datos hacia el cliente. RFC 959 establece que el puerto de datos predeterminado del servidor sea «el puerto adyacente al puerto de la conexión de control (es decir, L-1)», por lo que es el puerto 20 cuando el control usa el puerto 21. Un cliente detrás de NAT (traducción de direcciones de red) no tiene una dirección a la que el servidor pueda conectarse. Por eso, esa conexión nunca llega y la transferencia se bloquea. PASV invierte la dirección: el servidor queda a la escucha y responde con una dirección y un puerto dentro de una respuesta 227 Entering Passive Mode para que el cliente se conecte.

¿scp sigue usando su propio protocolo?

No desde OpenSSH 9.0, publicado el 8 de abril de 2022, que «cambia scp(1) del protocolo heredado scp/rcp al protocolo SFTP de forma predeterminada». OpenSSH 8.8 anunció el cambio en septiembre de 2021. La diferencia visible está en las comillas. El protocolo antiguo expandía los comodines remotos al pasarlos al shell remoto. El protocolo basado en SFTP no lo hace. Por tanto, las rutas que dependían de esa expansión del shell se comportan de otra forma.

¿Cuándo es rsync mejor que scp para un VPS?

Cuando vaya a copiar el mismo árbol más de una vez. rsync sólo envía las partes de cada archivo que el destino todavía no tiene, por lo que la segunda copia cuesta mucho menos que la primera. Para un único archivo que el destino nunca ha recibido, scp y rsync transfieren aproximadamente los mismos bytes y scp es más sencillo. Recuerde que, de forma predeterminada, rsync decide qué debe examinar según el tamaño y la hora de modificación. Por eso, un archivo cuyo contenido haya cambiado sin que cambien su tamaño ni su marca de tiempo necesita --checksum antes de que rsync pueda detectarlo.

¿Por qué Kermit codificaba los archivos como texto imprimible en lugar de enviar bytes sin procesar?

Porque la conexión para la que se diseñó era una línea de terminal hacia un mainframe, no un canal de bytes. Esos enlaces podían ser de 7 bits y el controlador de terminal del mainframe actuaba sobre los caracteres de control en lugar de transferirlos sin cambios. Kermit codificaba los bytes de control y los bytes con el bit alto activado como caracteres imprimibles para impedir que cualquier elemento intermedio reaccionara ante ellos. La codificación aumenta el tamaño de los archivos binarios durante la transferencia, pero era una compensación adecuada frente a una transferencia que, de otro modo, llegaría dañada.