De Wikipedia, la enciclopedia libre
  (Redirigido desde el protocolo de transferencia de archivos )
Saltar a navegación Saltar a búsqueda

El Protocolo de transferencia de archivos ( FTP ) es un protocolo de comunicación estándar que se utiliza para la transferencia de archivos informáticos desde un servidor a un cliente en una red informática . FTP se basa en una arquitectura de modelo cliente-servidor que utiliza conexiones de datos y control independientes entre el cliente y el servidor. [1] Los usuarios de FTP pueden autenticarse con un protocolo de inicio de sesión de texto sin cifrar, normalmente en forma de nombre de usuario y contraseña, pero pueden conectarse de forma anónima si el servidor está configurado para permitirlo. Para una transmisión segura que protege el nombre de usuario y la contraseña, y encripta el contenido, FTP a menudo está protegido conSSL / TLS ( FTPS ) o reemplazado por el Protocolo de transferencia de archivos SSH (SFTP).

Las primeras aplicaciones de cliente FTP fueron programas de línea de comandos desarrollados antes de que los sistemas operativos tuvieran interfaces gráficas de usuario y todavía se envían con la mayoría de los sistemas operativos Windows , Unix y Linux . [2] [3] Desde entonces, se han desarrollado muchos clientes FTP y utilidades de automatización para equipos de escritorio , servidores, dispositivos móviles y hardware, y el FTP se ha incorporado a aplicaciones de productividad, como los editores HTML .

En enero de 2021, la compatibilidad con el protocolo FTP se desactivó en Google Chrome (a partir de la versión 88), [4] y también se desactivó en otros navegadores importantes, como Firefox (a partir de la versión 88.0). [5]

Historia de los servidores FTP [ editar ]

La especificación original para el Protocolo de transferencia de archivos fue escrita por Abhay Bhushan y publicada como RFC  114 el 16 de abril de 1971. Hasta 1980, FTP se ejecutaba en NCP , el predecesor de TCP / IP . [2] El protocolo fue reemplazado posteriormente por una versión TCP / IP, RFC 765 (junio de 1980) y RFC 959 (octubre de 1985), la especificación actual. Varias normas propuestas modifican RFC 959 , por ejemplo, RFC 1579 (febrero de 1994) habilita FTP compatible con cortafuegos (modo pasivo), RFC 2228 (junio de 1997) propone extensiones de seguridad, RFC      2428 (septiembre de 1998) agrega soporte para IPv6 y define un nuevo tipo de modo pasivo. [6]

Descripción general del protocolo [ editar ]

Comunicación y transferencia de datos [ editar ]

Ilustración de cómo iniciar una conexión pasiva utilizando el puerto 21

FTP puede ejecutarse en modo activo o pasivo , lo que determina cómo se establece la conexión de datos. [7] (Este sentido de "modo" es diferente al del comando MODE en el protocolo FTP, y en su lugar corresponde a los comandos PORT / PASV / EPSV / etc.) En ambos casos, el cliente crea una conexión de control TCP desde un puerto N aleatorio, generalmente sin privilegios , al puerto de comando del servidor FTP 21.

  • En modo activo, el cliente comienza a escuchar las conexiones de datos entrantes del servidor en el puerto M. Envía el comando FTP PORT M para informar al servidor en qué puerto está escuchando. A continuación, el servidor inicia un canal de datos hacia el cliente desde su puerto 20, el puerto de datos del servidor FTP.
  • En situaciones en las que el cliente está detrás de un firewall y no puede aceptar conexiones TCP entrantes, se puede usar el modo pasivo . En este modo, el cliente usa la conexión de control para enviar un comando PASV al servidor y luego recibe una dirección IP y un número de puerto del servidor del servidor, [7] que el cliente luego usa para abrir una conexión de datos desde un cliente arbitrario. puerto a la dirección IP del servidor y el número de puerto del servidor recibido. [8]

Ambos modos se actualizaron en septiembre de 1998 para admitir IPv6 . En ese momento se introdujeron más cambios en el modo pasivo, actualizándolo al modo pasivo extendido . [9]

El servidor responde a través de la conexión de control con códigos de estado de tres dígitos en ASCII con un mensaje de texto opcional. Por ejemplo, "200" (o "200 OK") significa que el último comando fue exitoso. Los números representan el código de la respuesta y el texto opcional representa una explicación o solicitud legible por humanos (por ejemplo, <Se necesita una cuenta para almacenar el archivo>). [1] Una transferencia en curso de datos de archivo a través de la conexión de datos se puede cancelar mediante un mensaje de interrupción enviado a través de la conexión de control.

FTP necesita dos puertos (uno para enviar y otro para recibir) porque fue diseñado originalmente para operar en el Programa de control de red (NCP), que era un protocolo simplex que utilizaba dos direcciones de puerto , estableciendo dos conexiones, para comunicaciones bidireccionales. Se reservó un puerto par y otro impar para cada aplicación o protocolo de la capa de aplicación. La estandarización de TCP y UDP redujo la necesidad del uso de dos puertos simplex para cada aplicación a un puerto dúplex, [10] : 15 pero el protocolo FTP nunca se modificó para usar solo un puerto, y continuó usando dos para compatibilidad con versiones anteriores. .

NAT y cruce de firewall [ editar ]

FTP normalmente transfiere datos haciendo que el servidor se conecte de nuevo al cliente, después de que el cliente envíe el comando PORT. Esto es problemático tanto para NAT como para firewalls, que no permiten conexiones desde Internet hacia hosts internos. [11] Para los NAT, una complicación adicional es que la representación de las direcciones IP y el número de puerto en el comando PORT se refieren a la dirección IP y el puerto del host interno, en lugar de la dirección IP pública y el puerto del NAT.

Hay dos enfoques para resolver este problema. Una es que el cliente FTP y el servidor FTP utilizan el comando PASV, que hace que se establezca la conexión de datos desde el cliente FTP al servidor. [11] Esto es ampliamente utilizado por los clientes FTP modernos. Otro enfoque es que NAT altere los valores del comando PORT, utilizando una puerta de enlace a nivel de aplicación para este propósito. [11]

Tipos de datos [ editar ]

Al transferir datos a través de la red, se definen cuatro tipos de datos: [2] [3] [6]

  • ASCII (TIPO A): se utiliza para texto. Los datos se convierten, si es necesario, de la representación de caracteres del host emisor a "ASCII de 8 bits" antes de la transmisión y (nuevamente, si es necesario) a la representación de caracteres del host receptor. Como consecuencia, este modo es inapropiado para archivos que contienen datos que no son texto sin formato.
  • Imagen (TIPO I, comúnmente llamado modo binario ): la máquina emisora ​​envía cada archivo byte por byte, y el destinatario almacena la corriente de bytes a medida que la recibe. (Se ha recomendado la compatibilidad con el modo de imagen para todas las implementaciones de FTP).
  • EBCDIC (TIPO E): se utiliza para texto sin formato entre hosts utilizando el juego de caracteres EBCDIC.
  • Local (TIPO L n ): diseñado para admitir la transferencia de archivos entre máquinas que no utilizan bytes de 8 bits, por ejemplo, sistemas de 36 bits como DEC PDP-10 . Por ejemplo, "TYPE L 9" se usaría para transferir datos en bytes de 9 bits, o "TYPE L 36" para transferir palabras de 36 bits. La mayoría de los clientes / servidores FTP actuales solo admiten L 8, que es equivalente a I.

Un Borrador de Internet vencido definió un TIPO U para transferir archivos de texto Unicode usando UTF-8 ; [12] aunque el borrador nunca se convirtió en un RFC, ha sido implementado por varios clientes / servidores FTP.

Tenga en cuenta que estos tipos de datos se denominan comúnmente "modos", aunque de manera ambigua esa palabra también se usa para referirse al modo de comunicación activo vs pasivo (ver arriba), y los modos establecidos por el comando MODE del protocolo FTP (ver abajo).

Para archivos de texto (TIPO A y TIPO E), se proporcionan tres opciones de control de formato diferentes para controlar cómo se imprimirá el archivo:

  • Sin impresión (TIPO AN y TIPO EN): el archivo no contiene ningún carácter de control de carro destinado a una impresora
  • Telnet (TYPE AT y TYPE ET): el archivo contiene caracteres de control de carro Telnet (o en otras palabras, ASCII C0) (CR, LF, etc.)
  • ASA (TIPO AA y TIPO EA): el archivo contiene caracteres de control de carro ASA

Estos formatos fueron principalmente relevantes para las impresoras de línea ; la mayoría de los clientes / servidores FTP actuales solo admiten el control de formato predeterminado de N.

Estructuras de archivos [ editar ]

La organización de archivos se especifica mediante el comando STRU. Las siguientes estructuras de archivos se definen en la sección 3.1.1 de RFC959:

  • F o estructura FILE (orientada a flujo). Los archivos se ven como una secuencia arbitraria de bytes, caracteres o palabras. Esta es la estructura de archivos habitual en sistemas Unix y otros sistemas como CP / M, MSDOS y Microsoft Windows. (Sección 3.1.1.1)
  • Estructura R o RECORD (orientada a registros). Los archivos se ven divididos en registros, que pueden ser de longitud fija o variable. Esta organización de archivos es común en sistemas mainframe y de rango medio, como MVS, VM / CMS, OS / 400 y VMS, que admiten sistemas de archivos orientados a registros .
  • Estructura P o PAGE (orientada a páginas). Los archivos se dividen en páginas, que pueden contener datos o metadatos; cada página también puede tener un encabezado con varios atributos. Esta estructura de archivos se diseñó específicamente para los sistemas TENEX y, por lo general, no es compatible con otras plataformas. RFC1123 sección 4.1.2.3 recomienda que esta estructura no se implemente.

La mayoría de los clientes y servidores FTP actuales solo admiten STRU F. STRU R todavía se utiliza en aplicaciones de transferencia de archivos de mainframe y miniordenadores.

Modos de transferencia de datos [ editar ]

La transferencia de datos se puede realizar en cualquiera de estos tres modos: [1] [2]

  • Modo de transmisión (MODO S): los datos se envían como una transmisión continua, lo que evita que FTP realice cualquier procesamiento. Más bien, todo el procesamiento se deja en manos de TCP . No se necesita un indicador de fin de archivo, a menos que los datos estén divididos en registros .
  • Modo de bloque (MODO B): diseñado principalmente para transferir archivos orientados a registros (STRU R), aunque también se puede utilizar para transferir archivos de texto orientados a secuencias (STRU F). FTP coloca cada registro (o línea) de datos en varios bloques (encabezado de bloque, recuento de bytes y campo de datos) y luego lo pasa a TCP. [6]
  • Modo comprimido (MODO C): amplía el MODO B con compresión de datos mediante codificación de longitud de ejecución .

La mayoría de los clientes y servidores FTP actuales no implementan MODO B o MODO C; Los clientes y servidores FTP para sistemas operativos de mainframe y miniordenadores son la excepción.

Algunos programas de FTP también implementan un modo comprimido basado en DEFLATE , a veces llamado "Modo Z" después del comando que lo habilita. Este modo se describió en un borrador de Internet , pero no se estandarizó. [13]

GridFTP define modos adicionales, MODE E [14] y MODE X, [15] como extensiones del MODO B.

Comandos adicionales [ editar ]

Las implementaciones más recientes de FTP admiten el comando Modify Fact: Modification Time (MFMT), que permite a un cliente ajustar ese atributo de archivo de forma remota, lo que permite la preservación de ese atributo al cargar archivos. [16] [17]

Para recuperar una marca de tiempo de un archivo remoto, existe el comando MDTM . Algunos servidores (y clientes) admiten una sintaxis no estándar del comando MDTM con dos argumentos, que funciona de la misma manera que MFMT [18]

Iniciar sesión [ editar ]

El inicio de sesión FTP utiliza un esquema normal de nombre de usuario y contraseña para otorgar acceso. [2] El nombre de usuario se envía al servidor mediante el comando USER y la contraseña se envía mediante el comando PASS. [2] Esta secuencia no está encriptada "en el cable", por lo que puede ser vulnerable a un ataque de rastreo de red . [19] Si el servidor acepta la información proporcionada por el cliente, el servidor enviará un saludo al cliente y comenzará la sesión. [2] Si el servidor lo admite, los usuarios pueden iniciar sesión sin proporcionar credenciales de inicio de sesión, pero el mismo servidor puede autorizar solo acceso limitado para dichas sesiones. [2]

FTP anónimo [ editar ]

Un host que proporciona un servicio FTP puede proporcionar acceso FTP anónimo . [2] Los usuarios suelen iniciar sesión en el servicio con una cuenta "anónima" (en minúsculas y distingue entre mayúsculas y minúsculas en algunos servidores FTP) cuando se les solicita el nombre de usuario. Aunque normalmente se pide a los usuarios que envíen su dirección de correo electrónico en lugar de una contraseña, [3] en realidad no se realiza ninguna verificación de los datos proporcionados. [20] Muchos hosts FTP cuyo propósito es proporcionar actualizaciones de software permitirán inicios de sesión anónimos. [3]

Diferencias con HTTP [ editar ]

HTTP esencialmente corrige los errores en FTP que lo hacían incómodo de usar para muchas pequeñas transferencias efímeras como son típicas en las páginas web.

FTP tiene una conexión de control con estado que mantiene un directorio de trabajo actual y otros indicadores, y cada transferencia requiere una conexión secundaria a través de la cual se transfieren los datos. En el modo "pasivo", esta conexión secundaria es de cliente a servidor, mientras que en el modo "activo" predeterminado, esta conexión es de servidor a cliente. Esta aparente inversión de roles cuando está en modo activo, y números de puerto aleatorios para todas las transferencias, es la razón por la que los firewalls y las puertas de enlace NAT tienen tantas dificultades con FTP. HTTP no tiene estado y multiplexa el control y los datos a través de una sola conexión de cliente a servidor en números de puerto conocidos, que pasa trivialmente a través de puertas de enlace NAT y es fácil de administrar para los firewalls.

Configurar una conexión de control FTP es bastante lento debido a los retrasos de ida y vuelta de enviar todos los comandos requeridos y esperar respuestas, por lo que es habitual abrir una conexión de control y mantenerla abierta para múltiples transferencias de archivos en lugar de soltar y volver a -establecer la sesión de nuevo cada vez. Por el contrario, HTTP originalmente eliminó la conexión después de cada transferencia porque hacerlo era muy barato. Si bien HTTP ha ganado posteriormente la capacidad de reutilizar la conexión TCP para múltiples transferencias, el modelo conceptual sigue siendo de solicitudes independientes en lugar de una sesión.

Cuando FTP se transfiere a través de la conexión de datos, la conexión de control está inactiva. Si la transferencia tarda demasiado, el cortafuegos o NAT pueden decidir que la conexión de control está muerta y dejar de rastrearla, interrumpiendo la conexión y confundiendo la descarga. La conexión HTTP única solo está inactiva entre solicitudes y es normal y se espera que dichas conexiones se interrumpan después de un tiempo de espera.

Compatibilidad con navegador web [ editar ]

Los navegadores web más comunes pueden recuperar archivos alojados en servidores FTP, aunque es posible que no admitan extensiones de protocolo como FTPS . [3] [21] Cuando se proporciona una URL de FTP, en lugar de HTTP , el contenido accesible en el servidor remoto se presenta de una manera similar a la que se usa para otro contenido web. Se puede ejecutar un cliente FTP con todas las funciones dentro de Firefox en forma de una extensión llamada FireFTP .

A partir de 2019, los principales navegadores como Chrome y Firefox están desaprobando la compatibilidad con FTP en diversos grados. [22] Google lo eliminó por completo en Chrome 88. [23] A partir de 2019, Mozilla estaba discutiendo propuestas, incluida la eliminación solo de la compatibilidad con implementaciones de FTP antiguas que ya no están en uso para simplificar su código. [24] [25] A partir de abril de 2021 y la versión 88.0 de Firefox, Mozilla deshabilitó el soporte de FTP para Firefox y estaba planeando eliminarlo por completo en una versión posterior. [26]

Sintaxis [ editar ]

La sintaxis de la URL de FTP se describe en RFC 1738 , tomando la forma: (las partes entre corchetes son opcionales). ftp://[user[:password]@]host[:port]/url-path

Por ejemplo, la URL ftp://public.ftp-servers.example.com/mydirectory/myfile.txt representa el archivo myfile.txt del directorio mydirectory en el servidor public.ftp-servers.example.com como un recurso FTP . La URL ftp: // user001: [email protected]/mydirectory/myfile.txt agrega una especificación del nombre de usuario y la contraseña que se deben usar para acceder a este recurso.

Se pueden encontrar más detalles sobre cómo especificar un nombre de usuario y contraseña en la documentación de los navegadores (por ejemplo, Firefox [27] e Internet Explorer [28] ). De forma predeterminada, la mayoría de los navegadores web utilizan el modo pasivo (PASV), que atraviesa más fácilmente los cortafuegos de los usuarios finales.

Ha existido alguna variación en la forma en que los diferentes navegadores tratan la resolución de rutas en los casos en que hay un directorio de inicio no raíz para un usuario. [29]

Seguridad [ editar ]

FTP no fue diseñado para ser un protocolo seguro y tiene muchas debilidades de seguridad. [30] En mayo de 1999, los autores de RFC 2577 enumeraron una vulnerabilidad a los siguientes problemas: 

  • Ataque de fuerza bruta
  • Ataque de rebote de FTP
  • Captura de paquetes
  • Robo de puertos (adivinar el próximo puerto abierto y usurpar una conexión legítima)
  • Ataque de suplantación
  • Enumeración de nombre de usuario
  • DoS o DDoS

FTP no cifra su tráfico; todas las transmisiones son en texto sin cifrar y los nombres de usuario, contraseñas, comandos y datos pueden ser leídos por cualquier persona capaz de realizar la captura de paquetes ( rastreo ) en la red. [2] [30] Este problema es común a muchas de las especificaciones del Protocolo de Internet (como SMTP , Telnet , POP e IMAP ) que se diseñaron antes de la creación de mecanismos de cifrado como TLS o SSL. [6]

Las soluciones comunes a este problema incluyen:

  1. Usar las versiones seguras de los protocolos inseguros, por ejemplo, FTPS en lugar de FTP y TelnetS en lugar de Telnet.
  2. Usar un protocolo diferente y más seguro que pueda manejar el trabajo, por ejemplo, el protocolo de transferencia de archivos SSH o el protocolo de copia segura .
  3. Usando un túnel seguro como Secure Shell (SSH) o una red privada virtual (VPN).

FTP sobre SSH [ editar ]

FTP sobre SSH es la práctica de tunelizar una sesión FTP normal a través de una conexión Secure Shell. [30] Debido a que FTP usa múltiples conexiones TCP (inusual para un protocolo TCP / IP que todavía está en uso), es particularmente difícil hacer un túnel a través de SSH. Con muchos clientes SSH, intentar configurar un túnel para el canal de control (la conexión inicial de cliente a servidor en el puerto 21) protegerá solo ese canal; cuando se transfieren datos, el software FTP en cada extremo establece nuevas conexiones TCP (canales de datos) y, por lo tanto, no tiene protección de confidencialidad o integridad .

De lo contrario, es necesario que el software de cliente SSH tenga un conocimiento específico del protocolo FTP, para monitorear y reescribir los mensajes del canal de control FTP y abrir de forma autónoma nuevos reenvíos de paquetes para canales de datos FTP. Los paquetes de software que admiten este modo incluyen:

  • Tectia ConnectSecure (Win / Linux / Unix) [31] del paquete de software SSH Communications Security

Derivados [ editar ]

FTPS [ editar ]

FTPS explícito es una extensión del estándar FTP que permite a los clientes solicitar el cifrado de sesiones FTP. Esto se hace enviando el comando "AUTH TLS". El servidor tiene la opción de permitir o denegar conexiones que no soliciten TLS. Esta extensión de protocolo se define en RFC 4217 . FTPS implícito es un estándar obsoleto para FTP que requería el uso de una conexión SSL o TLS. Se especificó utilizar puertos diferentes a los de FTP simple. 

Protocolo de transferencia de archivos SSH [ editar ]

El protocolo de transferencia de archivos SSH (cronológicamente el segundo de los dos protocolos abreviado SFTP) transfiere archivos y tiene un conjunto de comandos similar para los usuarios, pero utiliza el protocolo Secure Shell (SSH) para transferir archivos. A diferencia de FTP, cifra tanto los comandos como los datos, lo que evita que las contraseñas y la información confidencial se transmitan abiertamente a través de la red. No puede interoperar con el software FTP.

Protocolo de transferencia de archivos trivial [ editar ]

El Protocolo de transferencia de archivos trivial (TFTP) es un FTP simple de pasos de bloqueo que permite a un cliente obtener un archivo o colocarlo en un host remoto. Uno de sus usos principales es en las primeras etapas de arranque desde una red de área local , porque TFTP es muy simple de implementar. TFTP carece de seguridad y de la mayoría de las funciones avanzadas que ofrecen los protocolos de transferencia de archivos más sólidos, como el Protocolo de transferencia de archivos. TFTP se estandarizó por primera vez en 1981 y la especificación actual del protocolo se puede encontrar en RFC 1350 . 

Protocolo simple de transferencia de archivos [ editar ]

El Protocolo simple de transferencia de archivos (el primer protocolo abreviado SFTP), según lo definido por RFC 913 , se propuso como un protocolo de transferencia de archivos (no seguro) con un nivel de complejidad intermedio entre TFTP y FTP. Nunca fue ampliamente aceptado en Internet , y ahora el IETF le asigna el estatus de Histórico . Se ejecuta a través del puerto 115 y, a menudo, recibe las iniciales SFTP . Tiene un conjunto de comandos de 11 comandos y admite tres tipos de transmisión de datos: ASCII , binario y continuo. Para sistemas con un tamaño de palabra que es un múltiplo de 8 bits, la implementación de binario y continuo es la misma. El protocolo también admite el inicio de sesión con ID de usuario y contraseña, carpetas jerárquicas y administración de archivos (incluido el cambio de nombre , eliminación , carga , descarga , descarga con sobrescritura y descarga con anexo ).

Comandos FTP [ editar ]

Códigos de respuesta de FTP [ editar ]

A continuación se muestra un resumen de los códigos de respuesta FTP que puede devolver un servidor FTP . Estos códigos han sido estandarizados en RFC 959 por el IETF. El código de respuesta es un valor de tres dígitos. El primer dígito se utiliza para indicar uno de los tres posibles resultados: éxito, fracaso o para indicar un error o una respuesta incompleta: 

  • 2yz - Respuesta exitosa
  • 4yz o 5yz - Respuesta de falla
  • 1yz o 3yz - Error o respuesta incompleta

El segundo dígito define el tipo de error:

  • x0z: sintaxis. Estas respuestas se refieren a errores de sintaxis.
  • x1z - Información. Respuestas a solicitudes de información.
  • x2z - Conexiones. Respuestas referidas al control y conexiones de datos.
  • x3z: autenticación y contabilidad. Respuestas para el proceso de inicio de sesión y procedimientos contables.
  • x4z: no definido.
  • x5z: sistema de archivos. Estas respuestas retransmiten los códigos de estado del sistema de archivos del servidor.

El tercer dígito del código de respuesta se utiliza para proporcionar detalles adicionales para cada una de las categorías definidas por el segundo dígito.

Ver también [ editar ]

  • Comparación de software de cliente FTP
  • Comparación de paquetes de software de servidor FTP
  • Comparación de protocolos de transferencia de archivos
  • Curl-loader : software de código abierto de carga / prueba de FTP / S
  • Protocolo de intercambio de archivos (FXP)
  • Protocolo de servicio de archivos (FSP)
  • FTAM
  • FTPFS
  • Lista de comandos FTP
  • Lista de códigos de retorno del servidor FTP
  • Transferencia de archivos administrada
  • OBEX
  • Acceso a archivos compartidos
  • Envoltorio TCP

Referencias [ editar ]

  1. ↑ a b c Forouzan, BA (2000). TCP / IP: Conjunto de protocolos (1ª ed.). Nueva Delhi, India: Tata McGraw-Hill Publishing Company Limited.
  2. ↑ a b c d e f g h i j Kozierok, Charles M. (2005). "La Guía de TCP / IP v3.0" . Tcpipguide.com.
  3. ↑ a b c d e Dean, Tamara (2010). Red + Guía de redes . Delmar. págs. 168-171.
  4. ^ "Desaprovechamientos y eliminaciones en Chrome 87" . Consultado el 18 de noviembre de 2020 .
  5. ^ "Firefox 88.0, vea todas las funciones nuevas, actualizaciones y correcciones" . Consultado el 23 de abril de 2021 .
  6. ↑ a b c d Clark, MP (2003). Redes de datos IP e Internet (1ª ed.). West Sussex, Inglaterra: John Wiley & Sons Ltd.
  7. ^ a b "FTP activo frente a FTP pasivo, una explicación definitiva" . Slacksite.com.
  8. ^ RFC 959 (estándar) Protocolo de transferencia de archivos (FTP). Postel, J. y Reynolds, J. (octubre de 1985). 
  9. ^ RFC 2428 (estándar propuesto) Extensiones para IPv6, NAT y modo pasivo extendido. Allman, M. y Metz, C. y Ostermann, S. (septiembre de 1998). 
  10. ^ Stevens, W. Richard (1994). TCP / IP Illustrated, Volumen I . 1 . Reading, Massachusetts, EE.UU .: Addison-Wesley Publishing Company. ISBN 0-201-63346-9.
  11. ↑ a b c Gleason, Mike (2005). "El protocolo de transferencia de archivos y su firewall / NAT" . Ncftp.com.
  12. ^ Klensin, John. Extensión FTP TYPE para texto internacionalizado . Proyecto de identificación-klensin-ftpext-typeu-00 . Consultado el 9 de junio de 2020 .
  13. ^ Preston, J. (enero de 2005). Desinflar el modo de transmisión para FTP . IETF . Proyecto de identificación-preston-ftpext-deflate-03 . Consultado el 27 de enero de 2016 .
  14. ^ Allcock, W. (abril de 2003). "GridFTP: Extensiones de protocolo a FTP para Grid" (PDF) .
  15. ^ Mandrichenko, I. (4 de mayo de 2005). "Descripción del protocolo GridFTP v2" (PDF) .
  16. ^ "Comando FTP MFMT" . support.solarwinds.com . 11 de octubre de 2018.
  17. ^ "Comandos FTP: DSIZ, MFCT, MFMT, AVBL, PASS, XPWD, XMKD | Serv-U" . www.serv-u.com .
  18. ^ "Comando MDTM FTP" . support.solarwinds.com . 11 de octubre de 2018.
  19. ^ Príncipe, Brian. "¿Deben las organizaciones retirar el FTP por motivos de seguridad?" . Semana de la seguridad . Semana de la seguridad . Consultado el 14 de septiembre de 2017 .
  20. ^ RFC 1635 (informativo) Cómo utilizar FTP anónimo. P. y Emtage, A. y Marine, A. (mayo de 1994). 
  21. ^ Matthews, J. (2005). Redes informáticas: protocolos de Internet en acción (1ª ed.). Danvers, MA: John Wiley & Sons Inc.
  22. ^ Abrams, Lawrence (26 de noviembre de 2018). "Los desarrolladores de Chrome y Firefox tienen como objetivo eliminar la compatibilidad con FTP" . bleepingcomputer.com . Consultado el 26 de enero de 2020 .
  23. ^ Sneddon, Joey (26 de enero de 2021). "Resumen de versiones de Linux: GParted, Lightworks, Google Chrome y más" . omgubuntu.co.uk . Consultado el 30 de enero de 2021 .
  24. ^ "1574475 - Eliminar el soporte de FTP" .
  25. ^ "Dejar de admitir FTP - Estado de la plataforma Chrome" .
  26. ^ "Vea las novedades de Firefox: versión 88.0 de Firefox" . mozilla.org . 19 de abril de 2021 . Consultado el 20 de abril de 2021 .
  27. ^ "Acceso a servidores FTP | Cómo | Ayuda de Firefox" . Support.mozilla.com. 5 de septiembre de 2012 . Consultado el 16 de enero de 2013 .
  28. ^ Cómo ingresar la contraseña del sitio FTP en Internet Explorer en Wayback Machine (archivado el 2 de julio de 2015) Escrito para las versiones 6 de IE y anteriores. Podría funcionar con versiones más nuevas.
  29. ^ Jukka "Yucca" Korpela (18 de septiembre de 1997). "URL de FTP" . "Informática y comunicación" (jkorpela.fi) . Consultado el 26 de enero de 2020 .
  30. ^ a b c "Protección de FTP mediante SSH" . Nurdletech.com.
  31. ^ "Componentes de la plataforma de garantía de la información (sección Tectia ConnectSecure)" . ssh.com .

Lectura adicional [ editar ]

  • RFC  697 - Comando CWD de FTP. Julio de 1975.
  • RFC  959 - Protocolo de transferencia de archivos (FTP) (estándar). J. Postel, J. Reynolds. Octubre de 1985.
  • RFC  1579 - (Informativo) FTP compatible con firewall. Febrero de 1994.
  • RFC  1635 - (Informativo) Cómo utilizar FTP anónimo. Mayo de 1994.
  • RFC  1639 - Operación FTP sobre registros de direcciones grandes (FOOBAR). Junio ​​de 1994.
  • RFC  1738 - Localizadores uniformes de recursos (URL). Diciembre de 1994.
  • RFC  2228 - Extensiones de seguridad FTP (estándar propuesto). Octubre de 1997.
  • RFC  2389 - (Estándar propuesto) Mecanismo de negociación de funciones para el Protocolo de transferencia de archivos. Agosto de 1998.
  • RFC  2428 - Extensiones (estándar propuesto) para IPv6, NAT y modo pasivo extendido. Septiembre de 1998.
  • RFC  2577 - Consideraciones de seguridad de FTP (informativo). Mayo de 1999.
  • RFC  2640 - (Propuesta de estándar) Internacionalización del Protocolo de transferencia de archivos. Julio de 1999.
  • RFC  3659 - Extensiones (estándar propuesto) a FTP. P. Hethmon. Marzo de 2007.
  • RFC  5797 - (Estándar propuesto) Registro de extensiones y comandos FTP. Marzo de 2010.
  • RFC  7151 - (Estándar propuesto) Comando HOST del protocolo de transferencia de archivos para hosts virtuales. Marzo del 2014.
  • Registro de extensiones y comandos FTP de IANA : el registro oficial de extensiones y comandos FTP

Enlaces externos [ editar ]

  • Redes de comunicación / Protocolo de transferencia de archivos en Wikilibros
  • Probador en línea del servidor FTP Autenticación, cifrado, modo y conectividad.
  • Servidores FTP anónimos por código de país TLD (2012): "Internet poco convencional - Acceso público - FTP" . www.jumpjet.info . 2012 . Consultado el 16 de enero de 2020 .